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

List:       kde-core-devel
Subject:    Re: Qt-only KDE applications
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2002-01-24 17:27:18
[Download RAW message or body]

On Wed, Jan 23, 2002 at 05:59:04AM -0500, Benjamin Meyer wrote:
> <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>

Make a patch then ;-) The problem won't fix itself magically ;-)

>  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 

I think this depends on the point of view. From a users point of
view the aplication will move to kde, just like it does move to
Windows when compiled with Qt/Win. And that is a good thing (for the
user as well as for KDE) . I think Matthias is very right when saying 
that KDE is just another platform for Qt.

> 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.

Guessing, guessing, guessing :)

>  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 

I think there are multiple reasons why noone hasn't tried, yet.

a) it is a painful platform IMHO (msvc++ has so many embarassing
   compiler bugs that it's not funny anymore, but maybe I'm just
   fastidious ;)

b) porting requires knowledge. Complete knowledge about kdelibs,
   knowledge about lots of the base unix APIs, knowledge about Qt
   (including internals, as not few parts of kdelibs rely on
   internal Qt stuff) and last but not least win32 to a certain
   degree.

c) Money. You have to pay $$$ for the compiler.
   (yes, you can get the borland compiler as commandline tool for
   free but the non-commercial edition of qt/win doesn't work with
   bcc but requires msvc++)

It is much more fun to work under Linux or any other Unix where you
can get the tools for developing for KDE for free, where lots of
applications are available in source, making it easier to learn. And
most important: It's a working thing. You can start hacking your
application, adding features, things that are fun when you do them
in your spare time. In contrast to fighting with operating system
bugs, compiler bugs and spending hours in reading man pages and
msdn.com for figuring out how to map certain functionality.

I don't think porting 'KDE' to Windows makes sense. I think it makes
sense to port maybe the one or other application. To Qt.

> 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.

I agree that cygwin probably not a solution for users.

>  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...

I don't think that this one library, to be used by Qt application
will make a significant difference in performance.

>  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.

Right, and this is where Matthias' approach comes into play, and
it's an approach that might give an excellent result while being
fairly easy to implement.

>  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. 

You mean a small wrapper library means lots of new bugs? Did you see
the API that is in discussion for wrapping?

> 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 

I strongly disagree. QSettings might have a 'similar' name to
KConfig, but it works fundamentally different in quite some aspects.
KConfig provides a lot more features that QSettings. It knows about
things like immutable entries, the concept of merging files,
configurable backends, rollbacks and whatnot. These you cannot
implement by simply 'inheriting' from QSettings.

> 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.

kdelibs contains functionality that can't just be 'given to
Trolltech for inclusion in Qt' . There are features that cannot be
'ported' (take kio for example) . kdelibs is different, kdelibs is a new 
platform. Please take a close look at what this set of libraries provides. 
Yes, there are some oddities and perhaps duplications, but I believe the 
majority of this module is a good chunk really good additions, additions 
that make KDE a platform, not a widget set on top of Qt.

>  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) 

Tell me: Why would a commercial developer developing a Qt based
application want to use the KDE file dialog on Windows?

He might want to use something like kio, but why 'port' kio (if
possible at all) when the operating system already ships with the
necessary functionality out of the box, making shipping of yet
another library pointless when you can get the same result (I guess
an even better result, think of obeying things like proxy settings,
etc.) by adding another level of indirection, a small level,
something like libqtkde :)

> 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 

Right.

>  What we are really talking about is a replacement for kdelibs, but then we 
> are back to where we started aren't we?

I don't think it makes sense to replace this platform.


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