News emerged recently that Qt Software (formerly Trolltech) were working on their first IDE
for Qt, code named Project Greenhouse. Today saw the release of the
first technical preview under the name Qt Creator. The initial
release is binary only, and under the terms of the Qt preview license,
but the final release will be released with source code under a GPL
compatible license. The initial release is available for Linux, Mac OS
X and MS Windows. Read on for a users review.
The Greenhouse project began as a research project within Trolltech.
We are told that the design is entirely plugin based, suggesting that
ultimately we will have the ability to add support for new languages,
debuggers etc. The documentation suggests a plugin for the CMake build
system used by KDE is in the works. At the moment things are a little
too bare for the benefits of this approach to be readily apparent, but
it is a sensible approach to take when developing an IDE.
Unusually for the dot, I have decided to look at the Windows install of
Qt Creator. The reason I have chosen to do this is that I have tried to
get applications working with the open source Qt version for Windows
before with little success, it has always been more trouble than I have
time for. Hopefully the combined Qt+IDE+Mingw package will make this
a pretty painless experience, which will bode well for future work on
KDE on the windows platform.
The initial download for Windows is pretty huge, over 200MB, however
since this includes the compiler and run time environment as well as
Qt and the IDE itself that is something I can live with. The installer
is a standard windows-style setup.exe and is pretty much idiot proof
(if rather slow).
The inital screen you see when running the IDE is very bare in
comparison to other IDEs - a basic page with a button to get to the
getting started guide. There is a sidebar on the left with some pretty
self-explanatory buttons and a menu bar but unusually there is no
toolbar at all, let alone the common sight of an overwhelming
collections of icons.
The getting started guide itself is pretty weak right now, and is
definitely alpha quality. The switch from a very clean initial view
to the fairly ropey tutorial with a massive index of the entire Qt
documentation on the left is jarring. Rather than cheating by reading
the docs, let's just dive right in and write something, how hard can
I will begin with the obvious - create a new project. We have a number
of choices of project type, but let's go with a GUI application. I
note here that the dialog starts as an OK/Cancel style dialog then
seems to change to a wizard, this could do with some work. I will call
the project DotDemo. I have chosen to include the Webkit module as well
as the basic Qt modules, as these will be required for what I want
this project to do. The final screen of the wizard is for project
management, but is totally disabled and the file names are off the
edge of the dialog - fair enough, this is alpha code.
Now we have got a basic project, let's see if the IDE provided shell will
build on its own. Clicking the big 'Build&Run' button on the left
brings up the build settings rather than actually building or
running, I discovered that you need to use the 'Play' arrow button
there instead. The result is a small progress bar in the sidebar
saying building. The resulting app is pretty unimpressive, but the
generated code has built and run successfully - a good start.
Double clicking the mainwindow.ui file in the file view brings up the
familiar sight of Designer embedded in the IDE. Since my usual demo
is a browser, I have dragged a QWebView into the view and added a
layout. This works as expected, and a click of the 'Play' button later
I have a working minimal browser application. Not bad since I haven't
written any C++ yet!
At the moment, Qt Creator seems to have quite a few rough edges in the
UI department and more missing features than I can count, but this is
looking like it is something worth watching. This is the first time
I have got the open source version of Qt on Windows to do anything
useful despite having previously got working code from Visual C++,
and having lots of experience developing with Qt on Linux. Qt Creator
certainly looks like it could lower the bar for Qt development on
Windows, and if the CMake suppport mentioned in the documentation is
added then this could be a useful tool for KDE developers.
Too bad Qt Software didn't decide to push KDevelop instead of reinventing the wheel. Now we have two "beta" IDEs instead of one "finished" powerful one :-(
But I hope KDevelop and Qt Creator will go on nicely and I will have a replacement for KDevelop3 pretty soon ;-)
Well, as much as I'd like to see KDevelop succeed.... QtCreator to me is already much more stable, and debugging actually works!
In stead of adding new functionality KDevelop should focus on stabilizing. In our company Kdevelop didn't pass 'the test' because of issues like stability and poor debugging capabilities.
> "Now we have two "beta" IDEs..."
No, we have a "first technical preview" (so not even beta) of an IDE with a radically different approach than KDevelop) and an IDE that was almost dead at the time that Qt Creator was started, but now seems to be alive again, still with the same goals that are different from Qt Creator.
I am sure that Qt Creator will lose its rough edges (would be nice if you could eloborate about them Rich, even if they are numerous) and if the KDevelop team keeps up pushing like they seemed to do in the last months, they will likely also end up with something useful.
Now for which concept can win more users: We will see about that. But it's really important to see that those are not about two camps working on the same thing but about solving the same problem with two totally different approaches. Ultimately the users (and by 'users' I mean 'developers') will decide on which approach is the better one.
Sure, here are some of the issues I noticed:
- Missing tooltips on the buttons in the sidebar, initially they don't seem to do anything but aren't greyed out.
- Project names with spaces in seem to cause problems
- opening a file in the editor, i seem to have an empty drop down to the right on the one listing the open files.
- Switch between method declaration/definition is enabled even when you didn't click on a method.
- Setting for the default editor are not inherited by the C++ editor (eg. setting it to visualise whitespace).
- Can't right click on class name and get to the docs.
- Can't print a selection.
- Switching between build types has radio behaviour but displays as checkbox items in the build settings view.
- No project editor, you just end up editing the .pro file in a text edit field in the IDE. (eg. if you want to add a module to the project).
- The Output view is rather weak.
None of these are massive issues, but they definitetly made it feel rough to me.
Please report those on the feedback mailing list, where we collect feedback and can respond to it.
Btw: Nice article, Richard, although I sense a tenor of "I really don't want to like this project, but unfortunately I cannot seem find any real major flaws with it." Is this just the typically KDE-project negativeness towards anything new? Or me being overprotective towards a new baby?
You are absolutely right that this is alpha code and has rough edges. The GUI itself is only halfway done. You will see heavy development on it in the coming month.
Just a few quick additions/answers to the points you made:
- "Can't right click on a class name and get to the docs"
Oh you context menu people! Simply press F1. You are right of course, there's a lot more missing from the menus currently.
- "Switching between build types has radio behaviour but displays as checkbox items in the build settings view."
Funny checkable treewidget items. We all want itemviews-ng.
- "No project editor, you just end up editing the .pro file in a text edit field in the IDE. (eg. if you want to add a module to the project)."
That's a feature, and a lesson learned from all of us who (still) use text editors. Real-world pro-files are too complicated to be messed up by an IDE. Without Creator, you would edit the file, too. If you integrated the current KDE build system, you would do exactely the same. I hate it when IDEs force you to let them mess with the build scripts. Convenience wizards would be nice, and maybe that's what you would like to see, but hiding the pro-file-syntax completely behind some clumsy form GUI would annoy people more than it would help. My opinion only.
- "Project names with spaces in seem to cause problems"
That's a terrible qmake limitation, you will have it with every IDE that uses qmake.
Could you sort me out a posting account for the Qt Software news server? The application page at http://trolltech.com/newsapply.html still says "The registration form for our mailing lists [sic] is currently offline, give us a day or two and it will be back in action."
> although I sense a tenor of "I really don't want to like this project, but
> unfortunately I cannot seem find any real major flaws with it." Is this just
> the typically KDE-project negativeness towards anything new? Or me being
> overprotective towards a new baby?
I think you're being a bit overprotective here, but I'm not a big fan of IDEs in general. I was pleasantly surprised by this one, especially the fact the GUI was nice and simple rather than having enough buttons to run a space ship. :-) I think the fact that I was able to go from installing the app to geting a working browser without any major issues or needing to resort to the documentation speaks for itself.
Interesting comment about the project editor. I can definitely see your point, as that is something I've hated in Visual Studio when I've used it in the past. I think the fact that I'm not that familiar with qmake's .pro files was the problem, so I had to look up what the module was called when I needed to go back and change the QT += line.
Regarding the issue with spaces, sounds like a case for QValidator. :-)
I forgot to say that'll be reporting stuff to the preview list once I've had a chance to look at the app in more detail over the weekend. Don't forget I had yesterday evening to play with it and write the review, so I'm sure there's stuff I missed.
>> I think the fact that I'm not that familiar with qmake's .pro files was the problem, so I had to look up what the module was called when I needed to go back and change the QT += line.
Sounds like the best of both worlds would be a manual pro file editor with very aggressive code completion for the qmake syntax.
Yes, that would certainly help me.
>> Is this just the typically KDE-project negativeness towards anything new? Or me being overprotective towards a new baby?
That would be the latter.. Since when is the KDE project negative towards new ideas?
Personally I think Qt Creator is a godsend, if it's half-decent. The major problem with Qt is that none of the IDEs are any good. I can't justify paying for Visual Studio (although I have a commercial Qt license) so the Visual Studio integration is not useful to me, KDevelop is too buggy and cluttered to use, text editor + command line is a bit too primitive, Edyuk usually either fails to compile or fails to run for me, same with Monkey Studio. QDevelop is decent, but has some annoying bugs and seems to be largely unmaintained in the past 6 months, and Eclipse is a bloated pig that takes over everything and loves to crash when I use it with the Qt integration.
>> That's a terrible qmake limitation, you will have it with every IDE that uses qmake.
Any chance of that being fixed? I've run into lots of qmake issues with spaces (like LIBS paths)
> Personally I think Qt Creator is a godsend, if it's half-decent.
> The major problem with Qt is that none of the IDEs are any good.
> I can't justify paying for Visual Studio (although I have a
> commercial Qt license) so the Visual Studio integration is not
> useful to me, KDevelop is too buggy and cluttered to use, text
> editor + command line is a bit too primitive
"Personally I think Qt Creator is a godsend"
Me too, and I think it's logo should be that "Heroes" sign because of this
> That's a feature, and a lesson learned from all of us who (still) use text
> editors. Real-world pro-files are too complicated to be messed up by an IDE.
> Without Creator, you would edit the file, too. If you integrated the current
> KDE build system, you would do exactely the same. I hate it when IDEs force
> you to let them mess with the build scripts. Convenience wizards would be
> nice, and maybe that's what you would like to see, but hiding the
> pro-file-syntax completely behind some clumsy form GUI would annoy people
> more than it would help. My opinion only.
Cool that I'm not the only one with this opinion :-)
For trivial things, clicking stuff together is ok, but then don't expect it to be portable (and if it's just to another Linux install).
For anything which should also build on a different machine, the developer has actually to think about what he does, not only in the programming part, but also the building part. This shouldn't be hidden from him.
About the cmake support in the new IDE: how do you do this ?
In the cmake developer's opinion the right way would be to work with project files generated by cmake, not to try to parse cmake files.
And if you need something from cmake (e.g. a new makefile-based project file generator) let me know or even better join on the cmake mailing list :-)
Alex (cmake guy, you know)
Very cool, Alex, working on this together would be great. Daniel T. will probably be the one to follow up here.
Effectively, all Qt Creator needs from a project plugin is some basic information on the project:
- all source files that are part of the project
- all include paths
- the compiler (so we can ask it for the standard include paths)
- the build environment (defines for the preprocessor)
- the command to start the build
- the targets (so we can run or debug it)
everything else is added sugar. The best would be if we defined a standard xml format for Creator. You let cmake generate it, we read it, and everybody is happy.
I wonder how hard it would be to make a .pro generator for cmake.
This is all stuff cmake can easily provide, no problem :-)
Regarding project files and their edition with IDEs, I agree. Build system related files at the end of the day are nothing more than scripts written in a domain specific language and it always struck me as odd that so many programmers can't stand editing text build files despite that they spend most their time editing code.
I've been using almost exclusively visual studio at work for the past ten years, yet I hate UI based build systems.
So far, I think Qt Designer has great potential. It's incredibly fast and have a clean UI, which are the two most appealing things for me in an application.
I just want to note one thing: the idea of having an IDE manage your buildsystem files is something that I think that comes from the days of automake/autoconf, etc. When I had to learn Qt/KDE development, understanding the buildsystem was even worse than learning C++. :-(
I'm happy that Qt and KDE are now far away from autotools.
> an IDE with a radically different approach than KDevelop
I do not see too much differences. Well - ok. The GUI is pretty different. But to be honest, the main parts of an IDE are not related to the GUI. And Qt Software could have influenced KDevelop4's GUI in a large extend.
The most importand features in my opinion is "code navigation". And the best basis for this is a "model" (AST) of the application.
To bad these two programs do not even share this model (like using clang?).
> an IDE that was almost dead
For me KDevelop seemed to be pretty much alive the last two years.
Too bad 2 contributors (Roberto, Harald) where "lost". But they are Qt Software guys...
About the rough edges: As long as qmake is the basis, I will not likely test it (using cmake at work and home). Qt Creator really needs to be more general. Support for STL containers (as currently the Qt containers) in the debugger whould be nice for example.
I doubt Qt Creator will ever evolve from an Qt-only tool to a general IDE. Supporting Eclipse was a better choice, but they dropped it.
And yes, competition is always a good thing. But I'd say there already is enough competition (netbeans, eclipse, vi, emacs, visual studio, xcode, code blocks, ...).
And KDevelop could really need some more manpower. With the help of Qt Creator's team, we would have a pretty cool IDE _today_.
> I doubt Qt Creator will ever evolve from an Qt-only tool to a general IDE.
> Supporting Eclipse was a better choice, but they dropped it.
If I understand the FAQ for Qt Creator right, they don't drop supporting Eclipse:
"Is Qt Creator a replacement for Eclipse? Why didn't you rather improve Eclipse/CDT?"
"... We will certainly continue to develop and improve our Eclipse integration ..."
They continue to develop "Eclipse integration". But they stopped improving CDT itself...
> And Qt Software could have influenced KDevelop4's GUI in a large extend.
Influencing a grass-root KDE project to a large extend? The pure thought makes me smile:) Have you ever tried that? Has it ever been tried? You can always get people to accept adding stuff, true, but to target a different user group, or to focus? Good luck. It takes more discussion time and work to get two people aligned who do not want to be aligned than it takes to replicate the coding work of those two guys.
> As long as qmake is the basis, I will not likely test it
Yes, that makes sense. No point in trying out whether you would want to contribute the CMake project manager.
> And KDevelop could really need some more manpower. With the help of Qt Creator's team, we would have a pretty cool IDE _today_.
Aha, that was the core of the poodle! KDevelop is so great that we at Qt Software must work with it, but has so little man power that it doesn't get where it wants to get. Don't you see the contradicion? What you are really saying is: "write the software I want, not the software you want."
> Supporting Eclipse was a better choice, but they dropped it.
Who is "they"? What did I miss again? "Better choice" for whom?
Guys, please relax, we simply announced some more free software. Nobody is going to take anybody's favorite toy away.
> Influencing a grass-root KDE project to a large extend?
KDevelop4 wanted to simpilfy it's GUI. And I'd guess that the discussion about KDevelop's GUI was about at the same time when you startet Qt Creator.
That's why I think it would have been easier for Trolltech to influence KDevelop's GUI.
> Yes, that makes sense. No point in trying out whether you would want to contribute the CMake project manager.
I' currently pretty busy (besides posting here ;-). So I hoped to be able to test it with my code in just a few minutes.
Before contributing to Qt Creator, I'll rather start helping KDE again...
> "write the software I want, not the software you want."
Exactly. Pretty selfish - I know.
> Who is "they"? What did I miss again? "Better choice" for whom?
> Guys, please relax, we simply announced some more free software. Nobody is going to take anybody's favorite toy away.
Ok - my big picture is a really powerful cool full featured C++ IDE for Linux. I'd hope for cool code navigation tools, powerful refactoring tools, helpful metric analysers included, a smart debugger, fast, ...
Currently there is no such IDE for Linux (and hardly any other platform). KDevelop is the tool I think is/will come closest to my dream. Eclipse will maybe.
Qt Creator won't, as I doubt it to be a C++ IDE but will always stay a Qt IDE "only".
Some Trolls contributed to KDevelop before. So I hoped to see more of this to see my goal reached sooner than later. That's why I may be a little dissapointed - sorry for that.
But maybe you proove me wrong and Qt Creator becomes a "general C++ IDE". Or maybe KDevelop and Qt Creator work together.
If I'd work in a Qt only world, Qt Creator would definitely be a cool tool.
>> But I'd say there already is enough competition (netbeans, eclipse, vi, emacs, visual studio, xcode, code blocks, ...).
The problem is that all those projects suck for developing C++/Qt code. And even after years and years of development they're not getting any better. I think there's a lot to be said for a dedicated tool optimized for Qt. This brings the IDE to an XCode level cleanliness and quality. Eclipse is a good example of being so generic that it's way too stupidly complicated and massive.
> And Qt Software could have influenced KDevelop4's GUI in a large extend.
Well, but there's a natural potential for conflict there. I'm a bit more cynical now that I'm running a company myself.
If you release products to support your main product at a company you usually have exactly one goal: sell more of your main product.
A well designed accessory product for Qt would do just that. In fact, for the most part, that's true with KDevelop as well -- I don't think it's unreasonable to view KDevelop as a tool to increase development of KDE applications, with some notably different dynamics.
Now, what happens when there's a conflict between something that would be better for KDE and something that would increase Qt adoption? Well, somebody loses. And if it's the product designer of a company, they're presumably none-too-happy.
I can seriously see where the Trolls are coming from on this since in the company I founded a few months back we're going to OSS some of our stuff at some point -- but we don't right now precisely because we don't have time to deal with the community. It'd probably slow our development down by a factor of 2 or 3. I don't mean that as a bad thing about the OSS community -- but right now we have the luxury of not caring about bugs that don't affect our usage, making decisions with other people's goals in mind and reviewing their thoughts and patches. (Incidentally, I've got a lot of might-someday-be-OSS-code that I've written personally that's never seen the light of day for the same reason. Learned my lesson there.)
So if I were managing this situation at then Trolltech, I would ask: How much effort would it take to get KDevelop with Qt 4 to the point where we need it, including factoring in a slowdown for community processes? How far away from an ideal Qt IDE would that be? How would that compare to the amount of time needed to develop one in-house?
And given that it sounds like there are only a few people hacking on KDevelop, I'd very likely have made the same decision as Trolltech.
A lot of times when we're looking at companies working with OSS we forget that they're companies. They're often filled with people that are passionate about OSS, but their primary goal is naturally commercial success.
In a community that itself has produced, say, three text editors, it's hard to fault a company for developing something that competes with a KDE app if they see that as being to their advantage.
Well, the "goals" seem to be exactly the same.
Our plans for KDevelop4 are:
- Excellent C++ support
- Only shipped with the really important, "stable" parts
- Of course, good Qt support
So either the Qt Creator developers have not read the kdevelop mailing-list for a long long time, or their IDE is really just another case of NIH syndrom..
I don't know how much of Qt Creator has been written from scratch, but to me this seems like a big waste of manpower, given the fact that if there were only one or two full-time developers supporting KDevelop4, we'd have a really excellent cross-platform IDE right now.
That sounds like a good plan, but after 11 years of programming, 8 of them using Qt, i realize, actually there is no good IDE at all, and it will be not. For someone who need very detail customizing level in the project KDevelop is not suitable, Eclipse too, especially with the CDT. The reason is always very same, I don't have custom make support. Everything I can swallow, but messing with makefiles without feedback is disaster. Alex, no offense, I like idea about cmake, but cmake is not always a solution, integration of the 3rd party library (for example). After so many years of experience I'm using Kate and self made make files, GNU compatible, believe or not, that gives me the best efficiency.
Because I was a fan (still in the soul) of KDevelop, I suggest to concentrate work on good project support, that's IDE for. So flexible make files, interactive editing, or at least prompt a warning, and drop support of qmake or cmake at all. The only right standard is GNU make, and yes, it is cross-platformed. Support of C++ specific is not so matter, i don't need IDE to be cross reference of my classes, i need one who can handle project, till than kate+term make the deal.
Not wanting to go too far off topic - but how messed up does a third party library have to be before using it with CMake is difficult?
And when using custom Makefiles, how does Eclipse CTD make that any harder than Vim or Emacs?
If you're having that much trouble with custom Makefiles, then it sounds like you're doing something fundamentally wrong.
You didn't get my point. I never said Eclipse makes my work harder, Eclipse is, however, great tools, but not for CDT, not for me anyhow. I no need to use Eclipse if I need to do the work manually, I don't need IDE to be just an editor.
And Eclipse doesn't have possibility to integrate new files in custom make file, doesn't call any script for that. So if you want to have your own hierarchy of the files, targets and objects you cannot use Eclipse, if you know the way than enlighten me please!
I don't do anything fundamentally wrong. It is a nature of diversity.
And yes, 3rd party library messes, because they have they own makefiles, so integration of that targets are impossible without sub-projecting, and not to mention some of them cannot be integrated as Eclipse project without serious work.
What is point to have CMake which calls "make -f Makefile" as a target? I will rather than use GNU make, at least I keep syntax the same. Again, I never said CMake is bad or whatsoever in that direction.
KDevelop has custom makefile support, always had, and always will have. So you can write the makefiles by yourself, or let them be written by whatever tool you like. If you don't want the goodies KDevelop has to offer, then that's your problem. ;)
Yes it has custom make file support, but than automatism is gone, KDevelop serves just like an editor, for that I don't need KDevelop because it already uses Kate parts. There where no support for custom made scripts like:
* Inserting new file
* Deleting old file
* Renaming targets
For that I need to edit make files by my self, so KDevelop helps luck in this case, always did. Everything could be done, it is just scripting, user point what scripts want to execute in those cases.
No need to be catchy here, I tried to be constructive, because I made the weakest point of KDevelop, and that is project support. If that targets you, sorry it's your problem, as I mentioned I don't use KDevelop any more ;)
What's the difference? Either way, none of them will ever be as powerful as vim is :).
kate now has a vi mode and since kdevevop uses katepart it also gets it ;)
emacs has a vi mode too.
Nice. I lolled.
Trolltech wanted a crossplatform IDE. As great as KDevelop is, I can't quite call it crossplatform, because it's such a pain to get running on Windows or Mac. But even if it weren't a pain, KDE is a huge dependency to foist onto non-KDE users.
1 Gb of software that needs to be patched, compiled, patched again _before_ kdelibs gets installed. Then about 400 Mb or so for the kdelibs and other stuff itself. Then finally we have kdevelop's dependencies to get through and then _if we're lucky_ KDevelop itself.
So "huge" here comes in at about one and a half gigs of fat for non-KDE users. And we're not even talking about the "huge" time dependency that comes into it. And after all that's done you have an IDE. This is on OS X btw.
For 900 Mb on OS X, Apple gives me an IDE, debugger, multiple compilers, profiling software, proper API doc indexing (with more available for download at the mere push of a button). So with KDevelop we're getting about half a gig more for 5 times less (by my count). Now Apple's a company and can provide all that but that's beside the point. The point is "KDE is a huge dependency to foist onto non-KDE users."
I've got only a 40Gb drive on my laptop, with two OS partitions. Which means room is a bit tight. I know that terabytes are selling for dimes these days, but frugality was still a virtue last I heard. So if kdelibs/kdebase-runtime isn't needed by an app, why make it a requirement? (speaking in general here, not directed at kdevelop, which obviously leverages lots of kdelibs goodness).
I see nothing at all wrong with plain vanilla Qt applications. If greenhouse can provide 90% of the KDevelop's functionality without being tied to KDE, I say more power to it! And it's still a Qt app so it will integrate nicely with KDE.
I've got nothing against KDevelop, and I think it's one of KDE's shining jewels. But it's not going to be for everyone, with the large footprint is one of the reasons.
Yep, KDevelop, been using it for many years (since 1.0 actually) and it is the same thing over and over again. Version 1.0, get's 80% usable - then forked between a group that wants a rewrite and a group that wants a port to the latest Qt. Same happened again from version 2 to 3, Harry from TT might still remember this...
Now I would say that KDevelop-3.5.3 *is* actually very usable and way better than switching between terminal and kate/kwrite or running gdb from the command line. QMake project management has it's quirks and you do have to protect your .pro files. Code completion works, Robe (another TT guy) did a tremendeous job stabilizing all that. Debugging with gdb works, heck you could now even get idb to work with it. QT Documentation works, you can right click on a class name and jump to docs. All of it makes me choose it over Studio 2005 for porting our app from Qt3 to Qt4...
One problem with KDevelop always was that the commercial distros have ancient version of this program, e.g. RHEL4, RHEL5 come with very old versions, and that KDevelop has gained a undeserved bad reputation through that.
But since yet another rewrite is in the making I am waiting to see whether TT can deliver. Given Matthias' track record (LyX, KDE, Qt) - how can it not!!!
Much will likely depend on whether TT will actually "eat their own dog food". If TT developers were to use this and had the possibility to contribute to its code base, this could quickly become a nice platform independent IDE.
I hear there was lots of positive feedback at the dev days this week.
The big C++ support/code-completion workover on KDevelop 3.5.3 has been done by me, before we started working on KDevelop4. And I can promise that KDevelop4 already now is far better than all that. From what I see Qt Creator looks like a slicker version of KDevelop3, it seems to have nearly exactly the same feature set. The next generation of KDevelop will be far above that, of course unless nokia pumps tons and tons more of resources into their app. Which IMO is a big duplication and waste. Bot apps have nearly the same goals from what I see.
David, thanks for the correction. I have honestly not followed who does what and lost track of who developes KDevelop. You deserve much credit, the code-completion in KDevelop3 does work great now!!!
When will KDevelop4 be in a a comparably usable state as KDevelop3 is?
Lets forget the fact that the Trolls understand their Toolkit better than KDE's.
There is still a world of difference distributing a KDE app and a Qt app. Watching the Amarok developers package Amarok for OS X and Windows makes me cringe. Distributing Last.fm is hard enough, but at least we only depend on Qt.
Not to mention it is not even currently technically feasible to distribute KDE applications on all platforms!
the solution is not to say "you can't use these additional (and often better than alternative solutions) libraries", the solution is to fix packaging of kdelibs on those other platforms.
and that would be a hell of a lot less work than writing an IDE, to give some sense of actual scope here (versus your Godzilla-is-coming presentation of it ;)
And who would be doing the fixing? The developers on those other platforms? Not likely.
Until KDE fixes kdelibs so that it's in a state to be packaged properly on those platforms (frameworks anyone?) packaging will suck, uptake will be next to zero, and KDE apps will have a hard time gaining. Which sucks because some of them are actually pretty awesome (when finally running on those other platforms)
> frameworks anyone ?
Yes, there are people interested in getting frameworks for OSX. E.g. me (the buildsystem maintainer) and Ranger Rick (the OSX porter).
We didn't have them with KDE <= 4.1 since we required cmake 2.4.5 there, and creating frameworks is supported since cmake 2.6.0.
There are just two problems left:
-doing it in a way compatible to what we did until now
I think it won't get done for 4.2, but we will have a closer look at it for 4.3.
Sorry I didn't mean to sound so extremist.
However, it certainly is currently true that distributing a KDE application on the big three is painful. And that is much less true of distributing a Qt application.
Distribution is a rubbish task. Nobody wants to do it. Because it is embarrassing to get wrong. And it is not programming.
So we all look to what is easiest as part of our decision in which toolkit to pick.
This is why nobody chooses to write cross platform apps in GTK, or wxWidgets. We all pick Qt. And, at this point, we don't pick KDElibs.
I must say that I'm a big fan of KDevelop and I have used it since the beta days in '99. I have used it mainly for C++, Perl and Bash stuff with good results.
I really hope that KDevelop will continue to live and I hope that I can get some time to contribute to the system in a not to far future. For me, KDevelop not perfect at all, but it is IMHO the best IDE in the Open Source Community.
A big thanks to the KDevelop team and the work they have done.
And of course: A big welcome to QT Creator. You're existence will probably make KDevelop even better while being a great IDE on your own. :-)
Yes, people reinvent too much wheels.
QDevelop, Monkey Studio, and so on. Too much IDEs, too little features!