Qt4addons module?

[Hans Meine]

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,
  Hans