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

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

This should clarify some things in my previous post.
-Ben

The cause of the problem (developers/companies sticking to qt and not using 
kde's core libs) stems from the fact that they want to port to windows.  

The number of developers using qt only and not kde is not small.  Whenever I 
would give a Qt seminar at school once kde was found to be non-cross 
compatible the majority of students (windows based of course) interest in kde 
dropped.  I have seen a large number of qt only based open source 
applications who do not have the time to work on their apps let alone keep 
two branches.  When asked about kde they time and time again tell me that 
they are thinking about it, but then tell me that they are going to stick 
with qt only so that it will compile on windows.

The reason why kde wont benefit from a "qtkdelib" is that for most of the 
application developers, having the file dialog the same as kde is all that 
matters, having the default select clicking in a treelist be double click 
isn't.  It is the little thing, icons, focus etc that will through off the 
user as they move from kde application to qt application whom will look 
similar, but behave differently.

What I fear is that open source developers will stick to Qt simply so that 
they can compile their app on windows sacrificing any features kde could add 
to them.  Thus makeing the kde desktop "broken" (like how netscape has a 
different copy paste sceme then every other app in unix. It is "broken" to 
most first year cs students here at school until they figure it out).

The kdelibs encompass many things.  A set number of them, KApplication, 
KTextView, etc are little more then small additions to Qt widget so that they 
can better incorperate into the desktop.  These core widget specific items 
are what make up the look and feel of the application (default double 
clicking in a treelist for example)  Putting these classes in a seperate 
library that can compile on windows will allow commercial/noncommercial 
developers to use them.  On the windows side KFileDialog etc would simply 
pass right to the QFileDialog (and windows file dialog) while on the unix 
side it would have our kde file dialog.  Then when these apps are combined 
with kde they will behave similarly with the rest of the desktop.  Then when 
these application wish to add kde specific library functionality (kspell for 
example) there are only a few ifdefs that are easy to manage rather then the 
nightmare of hundreds of little ifdefs (surrounding kmainwindow and 
qmainwindow for example).  These new ifdef additions do not effect the ui, 
but only effect the features in the app (spell checker, ssl, khtml, etc).

Having a simply small ui library concisting of all of the KAction, etc 
classes that was cross-compilable with windows would allow people not to 
worry about which library to base the application on and simply the kde one.  
They would then feel more at home when wanted to add more specific kde 
features on the unix side.  And even if they didn't add any specific kde 
features it would still work and feel right along with the kde apps.

The problem is developers and companies not wishing to utilize kdelibs simply 
because they wish to cross-port.  Lets remove that problem for them.

-Benjamin Meyer
[prev in list] [next in list] [prev in thread] [next in thread]