[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Qt-only KDE applications
From:       Benjamin Meyer <icefox () mediaone ! net>
Date:       2002-01-23 10:59:04
[Download RAW message or body]

<rant>
 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*.
</rant>

 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. <off topic> 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. </off topic> 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. <insert ovious (sp?) 
reasons> 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. <rant> 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.</rant> 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. 
[prev in list] [next in list] [prev in thread] [next in thread]