From kde-core-devel Wed Jan 23 10:59:04 2002 From: Benjamin Meyer Date: Wed, 23 Jan 2002 10:59:04 +0000 To: kde-core-devel Subject: Qt-only KDE applications X-MARC-Message: https://marc.info/?l=kde-core-devel&m=101188223730745 Ok first off before even commenting on the idea I would like to loudly complain about the kde about box. It has several issues that need to be addressed. (I am referring to the standard one that everyone uses, not the far and few between custom ones) The about is made up of 3 tabs, 2 of which I have major qualms about. In Authors tab lists information about the authors, but does it is such a way that it becomes too long. I can't recall a single about about (using the kde about box) that could hold all of the developers info. One possible change would be to have the e-mail placed next to the name of the person. There are many different ideas of how to re-arrange it, but you get the idea. Next, the License agreement tab, why can't wrap around be used? Either turn it on or for default gpl and lgpl format it to fit the default kdeabout size. Maybe these issues are why not even all of the kde apps use the kde about *cough* utilities *cough*. Ok, lets talk about this QT/KDE lib. First off I am glad that this discussion is being had. It is something that has been brewing for a long time and needs to be talked about. Is a qt/kde lib a good thing? With this qt/kde library developers would then think that it is ok to stick entirly to qt and never move to kde. Right from that alone it would cause more hurt then help. Also it is presuming that TrollTech will be releasing a non-commercial windows 3.0 license. Who says they have to? Who says they have to release 3.1. (just go and try to get the mac version...) If anything the non-commercial package is probably hurting them financially in the market that they are making money mostly in (windows duh) and if I was in the marketing department I would certently (sp?) dangle "free" old versions of qt-windows for people to try out. Ok, but for the argument we are going to assume that they will continue to release non-commercial packages for if they didn't then this whole lib would be for not. Let us now look at the alternative. This alternative it to clean up kdelibs so that it will port on windows (and mac?). We are not talking about the kdebase, but kdelibs. This will require the code to be gone over and cleaned up to be more compliant etc which will also practicly be a code review. Doing this will be worth its weight in gold. You want to know why? Because then all of the little qt-only developers will then see that they can get all of the kde functionality (not just the stuff in the qt/kdelib) and still have cross platform compatibility. They will then care more about kde, help out with it etc. Heck with kdelibs ported someone might port kdebase! How cool would it be to have the kde desktop on windows? Porting kdebase would be more work, but something that can be done. Trolltech did most of the work with abstracting qt and it only makes sense to try to get kdelibs for windows first. I am surprised that someone hasn't tried already. And I hear that person in the back who says kde-cygwin is here. Here I am laughing back at you. Tell any average person that you have to install an "emulator" to run the app and they will almost laugh at you too. cygwin is not the answer. Qt runs natively on windows so why can't kdelibs? Also we would also be relying on 2 other sources (qt and cygwin) for portability. Having it be as simply as a recompile is a much better solution. What do we see in every other dot.kde.org story? Some dude asking the developers to speed up the apps. Adding another library is not the way to do that! Just think if we had this lib so that the windows users could run kde apps. I can just see the 10 million posts asking why is "kde" slow for them. Doesn't matter that it is qt only they saw some kde thing somewhere... Back in the day developers wrote qt only apps because more people would install qt apps the kde apps (yah people are morons). Now the license issues is just about forgotten and more and more people are using kde. So it is time to port to kde right? Wrong, along the way qt dangled this little cross compatibility thing in our faces. Our little linux app suddenly was usable on our friends, parents, girlfriends parents, etc machines. Granted we didn't get much of any developer support from windows users (can you please add this huge ass feature for free, yesterday? Oh and thanks for the app! -anon user), but having your mom run your little xyz app on her work machine and her pride when she can show everyone (even if she never uses it) was worth it. So why should I port my app to kde? I could try ifdefing all over, but doing that will only make things worse. If we make this library then we will be like Microsoft in just applying a layer over hacks rather then fixing the real problems (think 16 bit days). What is worse is the fact that all of this new code means new bugs. Tightening, cleaning house and removing old code is better then adding new items if possible. In QT 3.0 there is a settings class called QSettings. It does something very similar to KConfig... Is the kde group going to drop KConfig and use QSettings? No (correct me if I am wrong), should it? Yes. Why? Because it is just another splinter, another layer, another level of confusion. Developers do not need the anoyance of deciding which one to choose. (re-read this paragraph with your own personal k* vs q* class annoyance) If I could honestly choose I would say that a lot of the duplication that KDElibs does should be ripped out and given to Trolltech to incorporate into QT as a gift of thanks for all of the free work they have done in qt. Heck this would remove a layer of virtual functions and make all kde apps just that little bit more faster, haha! (and even if we couldn't do that for legal reason fazing out the kde class should be the next option) If this qt/kde lib were to be made then we should ditch the kdelib. Why you ask? Because the point of this is to give applications a very similar look at feel, but if there are two different libs kdelibs and qt/kdelibs then there will always be differences no matter how hard we try. Lets talk about new developer. How about commercial developers? They all only use qt and don't even think about using kde. Now if the kdelibs were cross compilable then they would link to them and simply distribute both libs. (back to the 2 libs issue, but nonless) There are some developers who have qt and kde apps with ifdefs, but it is time consuming, anoying and creates messy code. Even then they choose to use the qt class over the kde one every time just to make their job easier. This means that their app doesn't look exactly like other kde apps. Small, but in the end it shows. Remember Corel? Remember how they had some dude go around and make everyone clean up their apps to act the same? Remember how just yesterday you read about that _again_ in some magazine as a reason why kde comes off so clean? If this library solves that completely why would we need kdelib, why not break apart kdelibs into a cross platform section and another part that is for "kde apps"? Oh wait, but then developers wouldn't use the "kde apps" library which is were we are right now. The library is only a temporary solution to the problem. Adding yet another layer will do kde little good. Heck when I read this story my first though was hey I can now port my kde app *from* kde to qt and use this little lib for the fun gui stuff. Course I would rip out a lot of extra kde functionality, but I get to compile on windows! I am sure that I am not the only developer who thought this before even finishing the title of the article. This library wont convice any qt developer to port their app over to kde, if anything it will stall them even longer if not forever. This only hurts kde users. I am willing to bet anyone that the qt/kdelib will cause more apps to be written qt only then kde only. Granted it may make the kde desktop larger, but it will only cause in the end someone porting kdelibs. The kde group has to either merge their kde code in qt (give it to them?) or make sure that the kdelibs works everywhere that the qtlibs work to stop this compitition of which library to compile for. What we are really talking about is a replacement for kdelibs, but then we are back to where we started aren't we? I vote to either a) make kdelibs cross compilable or b) Donate kdelib code to trolltech/etc and begin to faze out kdelibs in favor of qtlibs or something like that. Maybe Trolltech will include the kdelibs into the QTlib if we ask them nicely so then anyone who downloads the qtlib will get both. :) Choice B is probably the harder to do of the two (rewriting it all? contacting all of the authors? setting up so that patches in the future are signed over to trolltech?, etc), but in the long run will benefit *everyone* much better then any hack. KDE was ment to be a desktop envoirment, not a core widget lib (although we did start making one at one point) And for those that don't want to give up their code to trolltech you can remind them that as long as trolltech is around it will go into the GPL version of the code along with their own commercial version. I hate people that complain about the gpl qt code and how they can't sell their own little apps without giving away the source. They want to use something for free and make money off it. They sound like my friends who sell crappy windows shareware using a warzed version of vc++ and still complain. Maybe this is what should be the target for KDE4.0 The removal of the classes that are extensions of what QT already has and only have classes that QT doesn't have. Maybe have someone at trolltech who will add the core widget stuff that kde needs to QT. KDE is about the desktop and not the widget set. Something must be done. -Benjamin Meyer P.S. I am sure that someone out there will pick apart some little sentence in the middle of this in an attempt to flame me back. Before you do *please* think first if what I really meant and get across sloppily at 2am and then make constructive critizim on that not my horrible english spelling skills. Oh and don't bother repyling to my rants for I will ignore you, they are offtopic.