Redefining kdelibs and kdebase

Lubos Lunak l.lunak at
Mon Aug 29 09:19:00 BST 2005

Dne ne 28. srpna 2005 22:41 Christoph Cullmann napsal(a):
> On Sunday 28 August 2005 22:31, Kevin Krammer wrote:
> > On Sunday 28 August 2005 21:32, Simon Hausmann wrote:
> >
> > [snip]
> >
> > > The customizations I see are mostly simple GUI elements. Check boxes,
> > > comboboxes, some labels with no interaction between them. We could use
> > > a simple piece of XML to describe options like these, send them to the
> > > other process and in the reply get the chosen options.
> >
> > Sounds doable, but I am not sure how responsive this would be.
> > Like when doing something like this:
> > - user selects file
> > - information about newly selected file gets transmitted to application
> > - application updates XML description of additional elements
> > - XML description transmitted to dialog
> > - dialog parses XML and updates extra widgets
> Aehm, beside if this is doable in any speedy way, consider how this will
> harm the KDE Platform as development target, this takes away the normal way
> we have in C++ to modify a dialog by subclassing and introduces a completly
> other kde specific and complicated way :( This for sure won't make the KDE
> platform for developers a more interesting platform.

 Actually, since as Simon points out the GUI elements in the file dialogs are 
just some dumb simple widgets with non-complicated functionality, this 
doesn't need to be the case. I think it's possible to "wrap" e.g a whole 
QCheckBox so that its functionality can be reproduced out-of-process but to 
the application it's still just a QCheckBox. So if you want to customize a 
QFileDialog you should be able to simply create all those widgets and the 
out-of-process thingy could be done internally.

 In fact I have something that could be considered almost a proof-of-concept 
implementation of this, having KDE dialogs for Qt-only apps without modifying 
the apps. "Almost" meaning it's far from really being usable and it's barely 
convincing it can work, but I believe it can be done.

> > > *) Mozilla/Firefox,, Gtk applications could just fire
> > > off their request on d-bus and the user would see the nice KDE file
> > > dialog when running inside KDE
> >
> > Would be nice indeed.
> Same possible with my design ;) A wrapper around kdelibs stuff we want to
> export for the ISV's and others, which needs just to cover this small parts
> and could be bound to kdelibs stuff via dbus to avoid linking.

 So we're going to expect everybody to make their apps also to use our way, 
but we ourselves won't be willing to do the same in the other direction?

Lubos Lunak
KDE Developer
l.lunak at     l.lunak at

More information about the kde-core-devel mailing list