My goal is to create a software development kit for KDE, which makes it as easy as possible to write KDE applications. The main target audience are third party developers, who want to create desktop applications. The entry barrier should be as low as possible. There should no special knowledge about KDE, development processes on Linux, or familiarity with the community be required.
I thought a bit about how to best approach the creation of a KDE SDK. This lead me to the following design decisions:
- The SDK will be delivered as a sofware appliance. I'll probably make a VMware image and a live CD for a start. This makes it easy to use it everywhere, independent of operating system or other system constraints. It also makes it easy to set up a very well-defined environment for the SDK, so that all components play well together and don't interfere with other parts of an existing system.
- As a base for the appliance I'll use openSUSE, because this provides not only a great base system, but with the openSUSE Build Service and SUSE Studio it also provides excellent tools for creating and distributing appliances.
- The UI of the KDE SDK will be based on Qt Creator. The main reasons for this choice are that it provides a pretty clean and simple UI, and that it's easy to hack, as the code is pretty straightforward and it's conveniently hosted in git on gitorious.org.
- Application programming language will be C++. Some of the script languages might be easier to grasp, especially for beginners, but for KDE and Qt C++ really is the native language. Documentation, examples, and most code is in C++, so it's most easy to get help how to do things. It also avoids the complication of having the extra level of a language binding.
- Integrated documentation. There is lots of documentation floating around in various places. The SDK needs to integrate that in some way and provide pointers to what's relevant and helpful.
- Integration of online services. There are lots of online resources and services, for example documentation in Wikis and other web sites, mailing lists, IRC channels, web sites like kde-apps.org, or web services for development like gitorious, the openSUSE Build Service, or SUSE Studio. The SDK should integrate these as far as possible, so that the user gets the full benefit of all these community supported services. Maybe the SDK could even be basically stateless, so that all data is held online, and it doesn't matter with which instance of the SDK and from where you are using it.
- Full software life cycle support. Developing applications is not only about writing the code. The code has also to be packaged and deployed to the user. There is a rich infrastructure to do all that, so the SDK should make use of it and support stuff like creating packages of the application, and publishing them at the places, where they can be found and used by end users.
- Version control is essential. So the SDK will support git and gitorious.org out of the box. This should be done in an as transparent way as possible, which guides the user through a defined workflow, so the user gets the benefits of version control, but doesn't suffer from complexities of the underlying system.
If you are interested in helping with creating a KDE SDK, let me know. I would be happy to team up with others to get this project done.
Brillant idea! Kudos!ReplyDelete
Great intiative, but I would urge you to consider including the PyQt alternative. The main reason is mentioned by you and besides there are quite a few non-beginner python hackers out there.ReplyDelete
I think there are quite a few tutorials out there and they may just need some restructuring and updating. I am quite new to python and KDE myself, but would be happy to lend a hand if you decide to include the possibility.
As Snirp said, please please please don't lock us Python people out - I've learned Py just to code apps in Qt (well PyGame too) and would hate to be left out. I'd also like to lend any help I can if you include PyQt.ReplyDelete
Well, first make the Python case with the QtCreator guys. Then it shouldn't be a problem including Python.ReplyDelete
As I see it, Qt is currently not interested in adding python themselves. There may be some 3rd-party efforts underway to develop a python plugin (http://lists.trolltech.com/pipermail/qt-creator/2009-March/002225.html).
It is inevitable to arrive at some stage, but not worthwile to hold up development of the "KDE SDK". Guess we will have to make do with C++ for now.
I wonder why you are not suggesting to use KDevelop as the main UI. As this is a KDE SDK and not a Qt SDK I would expect that the project specific tool is choosen.ReplyDelete
I use the new version in for my daily work and my opinion is that this is the best C++-IDE available for Linux.
Great! It's a pity that you can't install it to /opt/kde-sdk-1.0, but it's a nice project indeed that will solidify the offer.ReplyDelete
I think at a KDE-SDK made up of "kdelibs" (splitted in sub-libs) + other High Quality libs + KDE Creator (customized version of QtCreator).
Release 1.0 should be stable, not necessarily complete ;-) [the less features, the less crashes!]
See this mockups for the KDE Creator side of the equation (if any):
Do you intend to include building for windows support?ReplyDelete
Please considere including KAppTemplate frol kdesdk which provides a GUI wizard to generate templates to start programming easily. This is a light application but very useful! The templates can also be used in KDevelop by the way.ReplyDelete
Not sure abuot QtCreator and cmake: is cmake well integrated in QtCreator?
This is a great idea! Looking forward to the results!ReplyDelete
You talk about using gitorious... so is the target audience writing an open source app?ReplyDelete
@Ian: Remember that Qt Software also started out using Gitorious internally. Gitorious != Gitorious.org.ReplyDelete
@annma: using kapptemplate (or its templates at least) for Qt Creator is something I was planning to look into.ReplyDelete
@Snirp: Python certainly is a good option for application development. To keep things simple I had to make a choice, though, and C++ just is the most mainstream solution in Qt and KDE land. But as I said I'm willing to revisit this question later.ReplyDelete
@Christoph_Bartoschek: Qt Creator is simpler than KDevelop, that fits my goal to keep things simple very well. It also seems to be more stable than KDevelop 4. Part of this project will be to make Qt Creator more KDEish, so that it shouldn't make a big difference.
@maninalift: Windows support would be great, but is currently out of my scope.
@annma: I'm a regular user of kapptemplate, so I certainly will consider it for creating application templates. cmake support in Qt Creator exists. Still have to see how good it is.
@Ian_Monroe: Good question. I think one of my unconscious design decisions is to target free software development. Shouldn't be difficult to adapt it to proprietary development.
Why only to focus on application developers alone? Why not some new guy who want to contribute small bug fixes? Actually new development is easy as there are no dependency. To make bugfixes, the user has to check-out source code, compile, resolve dependency etc. This is where a pre-build SDK would come handy.
I'm not so sure if creating a SDK as a Live-CD or VMware image is such a good idea.Sure it probably will suite some use cases but I think it is not flexible enough, at least not from my point of view. Maybe I missed something/Don't follow your lead.. But what if:ReplyDelete
1. I want to create a app based on kdelibs where I also want to include some other lib not included on the cd/image?
2. I want to use my specially configured editor/dev tools tha I normally use?ReplyDelete
thuswa: Just installed those packages in the VM. It's easier to set up one editor than setting up the whole KDE development environment. I think the idea is great.ReplyDelete
Cornelius: Will it include SVN snapshots of all parts of KDE, so you can just SVN up and develop against head of e.g. kdegames?
@HPC: Thanks. I missed the point that the image obviously wouldn't be read-only. Sorry...ReplyDelete
its a good idea..and i hope finally it will break the entry barrier for people like me..ReplyDelete
Is Qt Creator ready for such usage? It doesn't have even directories hierarchy support yet.ReplyDelete
After seeing this:ReplyDelete
I have to say KDESDK should have KDevelop. It just has better features to get into KDE development and it showcases the power of KDE much better. Very sad Qtcreator was picked.