tag:blogger.com,1999:blog-7888156866269720289.post4045063139751420330..comments2023-11-05T11:15:45.570+01:00Comments on Linux, Games, Programming, and some other random stuff: Busting KDevelop mythsscummoshttp://www.blogger.com/profile/12133795109922287229noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-7888156866269720289.post-20566871198382530142015-05-22T01:15:37.691+02:002015-05-22T01:15:37.691+02:00Why in the world would you want C++ and clang-C++ ...Why in the world would you want C++ and clang-C++ support at the same time? You will not even notice the difference as a user.<br /><br />For Python 2 and 3, yes, it's unfortunate, but my time and motivation to work on this is limited. Partially because of people like you who cannot voice objective, informed criticism.scummoshttps://www.blogger.com/profile/12133795109922287229noreply@blogger.comtag:blogger.com,1999:blog-7888156866269720289.post-51969749615692279232015-05-21T23:58:14.014+02:002015-05-21T23:58:14.014+02:00KDevelop doesn't allow C++ and clang support n...KDevelop doesn't allow C++ and clang support nor does it support Python 2 and 3, you have to pick one.<br /><br />What a piece of garbage.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7888156866269720289.post-1572742700979777702013-05-02T13:47:09.237+02:002013-05-02T13:47:09.237+02:00"the new system" is more than five years..."the new system" is more than five years old. And still people keep referring to the old one.scummoshttps://www.blogger.com/profile/12133795109922287229noreply@blogger.comtag:blogger.com,1999:blog-7888156866269720289.post-70756513053415941752013-05-02T09:46:20.097+02:002013-05-02T09:46:20.097+02:00It's a quick way to get some new users to your...It's a quick way to get some new users to your system "that has *nothing* to do with the old, I guess? It's not a good longer-term strategy.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7888156866269720289.post-90177167798948153632013-05-01T11:13:48.284+02:002013-05-01T11:13:48.284+02:00Well, it's not like "hm, we have run out ...Well, it's not like "hm, we have run out of minor version numbers, let's rewrite everything so we can increase the major one", it's more like "hm, our framework sucks, let's make it better" ... "ok, everything has changed, time for a major version number increase".<br /><br />So I think there's two factors in not breaking everything: The first one is, don't do it, i.e. if you change something, do it gently, and only release it when it's done. Of course, if that is possible, it's great, but unfortunately it isn't always possible (well, waiting for it to be ready always is, but you can't always prevent a full rewrite). The second one is, your framework needs to be in an acceptable state. If you have a horrible API and nobody wants to work with it any more, then at some time it will be less work to rewrite stuff than to keep the old API, or gradually improve it. If your API is somewhat okay, then you can probably prevent full rewrites for a pretty long time by doing continous improvement, like KDE 5 (KF5) does. By the way, half of KF5 is already done and the other half is planned pretty exactly, and it's not going to break anything significant (see http://community.kde.org/Frameworks/Epics).<br /><br />Cheersscummoshttps://www.blogger.com/profile/12133795109922287229noreply@blogger.comtag:blogger.com,1999:blog-7888156866269720289.post-56533962624979565622013-05-01T06:13:59.526+02:002013-05-01T06:13:59.526+02:00> Yes. I think KDE 4.0 was the best example in ...> Yes. I think KDE 4.0 was the best example in history which<br />> has shown this. :D<br />> I guess if the same people would be doing it again, they'd<br />> probably do it differently. But it has happened, and we<br />> have survived it. :)<br /><br />Actually, the issue predates KDE 4.0. Gnome 2.0 was a similar mess (which got me to switch to KDE 3 for some time), and later we got an even worse mess with gnome 3.0 (I'm now on XFCE). At this point, I'm starting to doubt that developers really learn from past mistakes. Or maybe they just get replaced by new developers who weren't there for the previous mess. So I'm fully expecting the same to happen for KDE 5.0 and Gnome 4.0.<br /><br />> It has happened, everyone has learned from it, and now<br />> everything is working nicely again.<br /><br />I probably won't switch back to it, but if indeed KDev 5 shows that developers learned from past mistakes, then that'll be a pleasant surprise (and a model for the gnome folks). Jean-Marc Valinhttp://jmvalin.ca/noreply@blogger.comtag:blogger.com,1999:blog-7888156866269720289.post-1277593483394235592013-05-01T03:08:58.695+02:002013-05-01T03:08:58.695+02:00> Well, that point is definitely valid for a KD...> Well, that point is definitely valid for a KDE developers<br />> environment. However, maybe the website should be clearer<br />> about KDevelop being targeted mainly at KDE development <br />> rather than a general-purpose IDE<br />But it is not. We just happen to support the tools commonly used for KDE development best. None of the things we do is specifically optimized towards KDE -- just the choice of tools we support is. Granted, we have a few select features (signal/slot code completion for example) which are specific to Qt; there's nothing for KDE though.<br />Yes, CMake is used for building KDE. But it's not like it was KDE's very own build tool or anything, tons of other projects use it (for example blender, compiz, boost, inkscape, MySQL, just to name a few). The same goes for all the other things we support, although most are probably so standard that nobody will complain anyways (C++, gdb, make, git).<br /><br />> (autotools is still more popular overall).<br />Popularity is a difficult thing to measure, and in my world autotools is not a very popular build system nowadays. Most projects I follow have switched to something different by now, and I know very few new projects which decide to use autotools. I'd say it's pretty much dying, and I'd also say this was just as predictable back in 2008.<br /><br />> If that is indeed the case, it would be a nice<br />> change from the KDE and Gnome tradition of throwing <br />> everything away on every major release.<br />I can definitely say that nothing of relevance gets thrown away for KDE 5. :)<br /><br />> Unfortunately, I think history has shown that no matter<br />> what you say about your project, distros *will* ship a<br />> new .0 release when it comes out.<br />Yes. I think KDE 4.0 was the best example in history which has shown this. :D<br />I guess if the same people would be doing it again, they'd probably do it differently. But it has happened, and we have survived it. :)<br /><br />> Well, at least it would have increased the likelihood<br />> of distros actually shipping both KDevelop and KNewIDE<br />> for a while rather than have KDevelop3 suddenly being<br />> replaced by something that's not ready. Still not ideal,<br />> but at least a smoother transition.<br />Yes. But, one of the things I wanted to emphasize in my post is that this was a relevant thing to talk about five years ago. People bringing this topic up at each KDevelop release started annoying me, because it just doesn't matter if there was a smooth transition between KDev 3 and KDev 4 any more. It has happened, everyone has learned from it, and now everything is working nicely again. So I'd prefer if people would stop complaining about it. ;)<br /><br />Cheers,<br />Sven<br /><br />scummoshttps://www.blogger.com/profile/12133795109922287229noreply@blogger.comtag:blogger.com,1999:blog-7888156866269720289.post-29678980327299466192013-05-01T02:32:13.328+02:002013-05-01T02:32:13.328+02:00> The reason KDevelop 4 didn't support auto...> The reason KDevelop 4 didn't support autotools was that everyone<br />> around KDE effectively stopped using it since at least 2008. <br /><br />Well, that point is definitely valid for a KDE developers environment. However, maybe the website should be clearer about KDevelop being targeted mainly at KDE development rather than a general-purpose IDE (autotools is still more popular overall).<br /><br />> The 3 -> 4 step was very painful, and nothing similar is<br />> going to happen again anytime soon. Everyone knows it was<br />> a difficult transition for both users and developers, and<br />> everyone wants to avoid doing it again.<br /><br />If that is indeed the case, it would be a nice change from the KDE and Gnome tradition of throwing everything away on every major release.<br /><br />> Part of the 3 -> 4 problem was that people expected 4.0<br />> to be usable as a desktop environment, which it was not.<br />> It was meant as a "we freeze our API now" release.<br /><br />Unfortunately, I think history has shown that no matter what you say about your project, distros *will* ship a new .0 release when it comes out. Of course, the fact that version 3 had been mostly unmaintained for a while probably didn't help. Personally, I prefer calling the API-freeze version a beta or RC.<br /><br />> Yes, I think that would have saved us from a lot of<br />> confused and annoyed users. Instead we would of course<br />> have "how could you discontinue this awesome project"<br />> people, but those wouldn't be associated with KDevelop 4<br />> at least.<br /><br />Well, at least it would have increased the likelihood of distros actually shipping both KDevelop and KNewIDE for a while rather than have KDevelop3 suddenly being replaced by something that's not ready. Still not ideal, but at least a smoother transition.<br /><br />CheersJean-Marc Valinhttp://jmvalin.ca/noreply@blogger.comtag:blogger.com,1999:blog-7888156866269720289.post-25166330713729353062013-04-30T09:55:09.131+02:002013-04-30T09:55:09.131+02:00You have some fair points, and I'm not going t...You have some fair points, and I'm not going to argue about them since I understand why you bring them up. Let me just make some remarks:<br /><br />> The main reason I switched from KDevelop 3 to Eclipse/CDT<br />> was lack of autotools support in KDevelop 4.<br />The reason KDevelop 4 didn't support autotools was that everyone around KDE effectively stopped using it since at least 2008. So there was little interest in having it supported, and being a quite low-manpower-project, KDevelop had to focus on a few things it wanted to do. Autotools support wasn't very high on the list.<br /><br />> So even if KDevelop 4.5 ended doing everything I wanted,<br />> I likely wouldn't switch back because I'd know (or at least<br />> expect) I'd have to go through the painful steps above again for <br />> KDevelop 5.<br />The 3 -> 4 step was very painful, and nothing similar is going to happen again anytime soon. Everyone knows it was a difficult transition for both users and developers, and everyone wants to avoid doing it again. For version 5 of the KDE frameworks for example, there is of course some restructuring, but source compatibility will be mostly maintained (except some few select things), so it's very unlikely there will be any major application rewrites.<br />Part of the 3 -> 4 problem was that people expected 4.0 to be usable as a desktop environment, which it was not. It was meant as a "we freeze our API now" release.<br /><br />> Personally, I think developers should have simply renamed<br />> the project to avoid confusing people (and especially distros) <br />> into thinking that KDevelop 4 was in any way related to KDevelop > 3.<br />Yes, I think that would have saved us from a lot of confused and annoyed users. Instead we would of course have "how could you discontinue this awesome project" people, but those wouldn't be associated with KDevelop 4 at least.<br /><br />Cheers<br /><br />scummoshttps://www.blogger.com/profile/12133795109922287229noreply@blogger.comtag:blogger.com,1999:blog-7888156866269720289.post-19299694054799359952013-04-30T03:15:49.186+02:002013-04-30T03:15:49.186+02:00The main reason I switched from KDevelop 3 to Ecli...The main reason I switched from KDevelop 3 to Eclipse/CDT was lack of autotools support in KDevelop 4. But there's also a more fundamental issue of CADT development model.<br /><br />In your post, you write: "There was problems with stability in the 4.1 era (wich was years ago), and there's a bug in some Qt versions before 4.8.3 which made it crash too, but the current version is perfectly stable." Well, the problem is that KDevelop 3 stopped being improved long before KDevelop 4.0 got released and even then you admit it took mode time before KDevelop 4 was "usable". What it means for a user is that you go through these steps:<br />1) Having an IDE you like<br />2) Having an IDE you still like, but that's effectively unmaintained<br />3) Being forced (by your distro unless you want to deal with a lot of pain) to use an IDE that's not ready (KDevelop 4.0)<br />4) Adapt to a new IDE which is eventually usable, but no longer supports what you were using before.<br /><br />So even if KDevelop 4.5 ended doing everything I wanted, I likely wouldn't switch back because I'd know (or at least expect) I'd have to go through the painful steps above again for KDevelop 5. Personally, I think developers should have simply renamed the project to avoid confusing people (and especially distros) into thinking that KDevelop 4 was in any way related to KDevelop 3.Jean-Marc Valinhttp://jmvalin.ca/noreply@blogger.com