hans_meine at gmx.net
Mon May 30 13:45:39 BST 2005
On Monday 30 May 2005 14:12, Eva Brucherseifer wrote:
> Right now we go the all or nothing approach in KDE - take it all or leave
> it. The result is, that many go the "take nothing and do everything
> yourself" approach. At least that is how it looks like from the outside.
> As a coder I hate reimplementing things, that are already in KDE, but which
> I cannot use due to circumstances.
Let me throw another 2 cents into this discussion, stressing one of these
"circumstances": AFAICS, one of the major differences between pure Qt and
KDE applications is that the latter are using a whole lot of files whose
locations on disc are managed by the KDE framework.
In other words, when porting one of my KDE3 application to Windoze (I was
forced to ;-(( ), I realized that many of the seemingly small classes I used
actually depend on KInstances and thus basically everything else. I had a
hard time stripping down KDE classes, basically:
- KFileDialog depends on too many things to bring it to work on Windoze, but
that's OK AFAICT, and can just be substituted by QFileDialog. Unfortunately,
the syntax for directory filters is different and has to be mapped.
- KGUIItems depend on the whole icon loading stuff, and thus on global KDE
configuration - I decided to remove all KGUIItems-related stuff because of
that. That's been a cowardish decision and unfortunately meant to use
QActions instead of KActions, too. OTOH, the whole XMLGUI code depended on
that, and it seemed more feasible at that time to re-implement the
menu/toolbar-buildings code with pure Qt. I would like to know whether we
can prevent that with KDE4.
- KColorButton: seemingly harmless, but uses KGlobalSettings::dndEventDelay()
(and KColorDialog, did not bother to port that either)
- I wrote a dummy KDebug substitute, because that depends on lots of stuff
- KDialog depends on e.g. Xinerama stuff and KApplication (for the caption)
- KDialogBase depends on KGlobalSettings::buttonLayout, KGuiItem, KURLLabel
and so on..
My biggest obstacles were the whole icon-loading scheme which is deeply
manifested in KDE classes (but has it's very good reasons to exist and has no
counterpart in Qt) and global settings, which all depend on a persistent
setup. (Disclaimer: I have no clue about Windoze and its' standard way to
store configuration, if there is one.)
This is by no means meant as criticism (to the contrary, the fact that KDE
comes with so many interacting helpful little classes and widgets was the
reason for me to use KDE in the first place), but I just wanted to tell you
about some of my difficulties. (I repeatedly thought: "OK, now let's take
KDoubleNumInput, that can't possibly depend on anything... argh. KLocale for
the number formatting.." ;-) )
I sincerely hope that all these problems vanish (I mean, someone makes them
vanish ;-) ) with KDE4.
Have a nice day,
More information about the kde-core-devel