Introduction and toolkit abstraction

[Alexander Neundorf]

On Tuesday 14 September 2004 20:36, Sean Middleditch wrote:
> On Tue, 2004-09-14 at 20:13 +0200, Alexander Neundorf wrote:
> > On Wednesday 01 September 2004 12:03, you wrote:
> > > Hi,
> > >
> > > >Bascially, if we take a KDE applications or a Gnome application, we
> > > > can divide it in two parts :
> > > >1. some dialogs that are just very simple calls to the API, like the
> > > > file open dialogs
>
> You've obviously not used the APIs in question, then.  There is a lot of
> work involved in doing even something like selecting a file.  What is
> the default path?  What file types should be displayed?  Preview widget?
> Any extra options in the dialog?  Selecting a file or a folder?  Save vs
> load?  

Well, I would consider these features quite basic, i.e. they should be 
supported by all file dialogs.
In Qt you have e.g. QString QFileDialog:: getOpenFileName(const QString& 
startWith, const QString& filter, QWidget* parent, const char* name, const 
QString& caption, QString* selectedFilter, bool resolveSymlinks)

It's a simple static function and covers most options.
I think it gets harder once you use e.g. the file dialog non-modal, or add 
special stuff to it. Then the wrapping can easily break.

> Will the GTK+ dialog allow users to browse using KIOSlaves so KDE
> apps can save files there?  Will the Qt/KDE dialog allow users to browse
> using gnome-vfs so GNOME apps can save files there?  

Well, the dialogs "simply" should return an URL which is understood by both 
KDE and Gnome apps. It should not matter that much how the url is loaded 
finally.

> Nobody is putting even an ounce of actual thought into this cross-
> toolkit nonsense, and just spouting off some lofty abstract ideas based
> on very little fact or experience.

Come on.
Doing some work so that the different apps could have e.g. common dialogs is a 
worthy goal. With supporting the file dialog and the printing dialog a lot 
would already be achieved.

...

> Even then you have big problems without adding a lot of work to the mix.
> For example, integrating main loops.  And the fact that the dialogs
> often expect the app to use most of the same support code for VFS
> access, printing, etc.
>
> > Having an abstraction lib even for only some dialogs won't become a real
> > success, I'm afraid. Every toolkit will still have its own unique
> > features, and the developer working with this toolkit will probably
> > prefer to use the advantages of his toolkit instead of using the wrapper
> > function which provide only the lowest common denominator.
>
> *bing*  Thank you.  ;-)

I had another idea: how about making the file dialog (and maybe the printing 
dialog too) a desktop wide service ? You ask it via dcop/dbus/... and 
something like a desktopdialogserver provides the dialogs to the user. Then 
even cli-apps could work with a file dialog (uhh, strange).
(I also have the impression that the file dialogs mutate more and more to file 
managers. Couldn't the file manager be used as a file selector in some way ?)

Bye
Alex
-- 
Work: alexander.neundorf at jenoptik.com - http://www.jenoptik-los.de
Home: neundorf at kde.org                - http://www.kde.org
      alex at neundorf.net               - http://www.neundorf.net