Redefining kdelibs and kdebase

[Simon Hausmann]

On Sunday 28 August 2005 14:28, Kurt Pfeifle wrote:
> On Saturday 27 August 2005 11:30, Simon Hausmann wrote:
> > On Saturday 27 August 2005 11:35, Andras Mantia wrote:
> > > > applications that are included with this package.  Your average
> > > > application shouldn't have dependancies to KDE desktop unless they
> > > > are a component such as a screen-saver or panel applet.  Once
> > > > libraries such as KIO are portable then they should be moved into
> > > > frameworks.
> > >
> > > [...]
> > >
> > > > -KDEPrint
> > > > -KFileDialog
> > >
> > > Will be hard to not depend on KFileDialog (and KDEPrint), no?
> >
> > The idea is to run the file dialog, print dialog, etc. out of process.
> > 'Our' implementation of the file dialog can reside in KDE workspace and
> > all that is in KDE framework is an interface to launch the dialog.
>
> Hmmm.... re. printing there is not *the* print dialog. KDEPrint provides
> the option to individual apps to add customizations to the kprinter dialog,
> which may add more features to the printing.
>
> For examples look at and compare what the print dialogs of kate, konqueror
> and kcron look like (click "Options >>" to expand the simpler dialog mode).
>
> Wouldnt these additional, application-specific features be lost by
> implementing your proposal?

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.

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.

*) On OS X users /expect/ to see the simple finder window.

*) 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

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.

Simon