From kde-core-devel Wed Jan 23 14:50:24 2002 From: Benjamin Meyer Date: Wed, 23 Jan 2002 14:50:24 +0000 To: kde-core-devel Subject: Re: Qt-only KDE applications X-MARC-Message: https://marc.info/?l=kde-core-devel&m=101188226430859 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