Introduction and toolkit abstraction

[Sean Middleditch]

On Tue, 2004-09-14 at 21:59 +0200, Alexander Neundorf wrote:
> 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.

Except it already has some things GTK+'s dialog doesn't like a "resolve
symlinks."  (Who the heck would actually want that option??)  And how
does the filter string work?  Is it a list of MIME types?  Extensions?
Does it need the name of the type too, or is it looked up automatically?
What is the caption exactly?  How do we pass in the "parent" widget when
we're dealing with two (and you guys are only talking about Qt and GTK,
shame on you, there are many other Free Desktop toolkits) totally
different widget systems?  Do you just ignore the parent widget and then
ignore the fact that that'll break a lot of window management issues?

> 
> > 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.

Except that KIOSlaves and gnome-vfs do not support the same set of
protocols, use different names for some of the same protocols, and in
general aren't actually all that compatible.

You'd need either a common VFS layer (which wouldn't be a bad idea at
all, and would have a hell of a lot more real world use than a couple
dialogs that would just feel alien in the application anyhow), or make
the dialogs support a least common denominator - which isn't much.

Don't forget authentication.  It'd be really annoying if the file dialog
required you to authenticate to some service to browse it, then the app
required you to authenticate to access the file.

And of course that's all only the file dialog.  What about the print
dialog?  That could be a real mess.  What other dialogs do you want to
integrate?  Is file and print all?  Would integrating those _reaaally_
be worth all the hassle?  Especially given that dozens and dozens of
other dialogs would still look, act, and feel different, the apps would
still look, feel, and act different, etc?

> 
> > 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.

And you're doing *exactly* what I just claimed you were - aiming for a
lofty goal without actually having any real workable solution.

You can't just pop-up a dialog from another toolkit and expect it to
ever work.  There is just far, far too much other infrastructure that
the dialogs expect the apps to be using.

If you don't believe me, feel free to stop debating and prove me wrong.
Honestly, I won't mind.  ~_^

(BTW, you cut out my alternate proposal - I was interested in your
thoughts on it.)

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

That has almost as many problems as merging the code bases.  You have
the exact same API and LCD problems.  You've only just added even more
infrastructure and bloat.

Shell scripts can already use file dialogs, btw.  Look at Zenity.  I'm
sure Qt/KDE has an equivalent.  A lot of very nice and usable graphical
utilities can be written in shell script.  Of course, those aren't CLI
scripts... ;-)

> (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 ?)

The file manager as the file selector is something that many people
would like to see.  In terms of opening a file, that's already what it
does.  You browse the file, click/double-click on it, and there you go.
It's open.  Many (most?) apps also let you drag-n-drop a file from the
file manager to the app window to open it.

For saving files, things get a little tricker.  The UI needs to be
figured out precisely.  ROX uses a technique where you type in the name
of the file, then drag an icon into your file manager to save it.  Given
the accessibility issues with drag-n-drop, I don't at all care for that
solution, but I'm sure someone somewhere has other ideas on how this
could work.

> 
> Bye
> Alex
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.