Redefining kdelibs and kdebase

[Christoph Cullmann]

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.

>
> > It's not as flexible as the current solution where you get access to the
> > widget, but on the other hand think of the advantages from a user's
> > perspective:
> >
> > (this is beyond your specific concern, but I'll take the opportunity to
> > use this reply to stress the advantage of the approach in general)
> >
> > *) Imagine kmail on windows, let the user attach a file. You really do
> > want to see the windows file dialog there. Same for printing.
>
> Well, I see the adantage of KDE as a desktop provider :)
> KDE applications on Windows would then be restricted to the possibilities
> of the Windows file dialog and could offer features like remote file access
> only on KDE, thus giving KDE an advantage in competing with other desktop
> providers.
Yes, and consider: our apps even follow some HIG, why waste the time for 
having a own HIG and all and than throw this all away with having completly 
non-HIG conform dialogs in KDE apps.

>
> > *) Mozilla/Firefox, OpenOffice.org, 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.

>
> > I admit we do loose a little bit of flexibility, but in my opinion we
> > would gain a lot, without changing the common case where applications
> > just use the static functions to get a file path or to fire up a print
> > dialog.
>
> I am a bit afraid we move into a situation wrapper toolkits like wxWidgets
> or SWT are in, i.e. only be able to guarantee least denominator
> functionality
Exactly :(
This all won't help KDE, this may help QT, but not the KDE platform, because 
we are no consistent platform any longer.

cu
Christoph