[Desktop_architects] Re: Desktop Services

[Michael Sweet]

Martin Konold wrote:
> Am Dienstag, 20. Dezember 2005 20:25 schrieben Sie:
> 
> Hi Michael,
> 
>>> E.g. KDE offers a file open dialog with preview capabilities. This
>>> capability is build into the dialog without a call back to the
>>> application calling the dialog.
> 
> I should be more careful with my wording. With call back I don't mean any kind 
> of traditional callback like in GUI programming.
> 
>> But what if you have a file format which is not supported/recognized
>> by the desktop you are using?  Does the ISV have to write plug-ins
>> for every desktop (assuming it supports generic preview images), or
>> do you just "do without" when the user chooses a different desktop
>> than you developed for?
> 
> The idea is that applications offer the desktop an interface (e.g. via a plain 
> commandline option) to provide the preview capabilities. 

Hmm, have you done any prototyping to see what the performance of this
approach will be like?  What about caching a la the FD.o Thumbnail
standard?

> This means that the applications offers it "preview" capabilities to the 
> desktop during installation time.
> 
> It is then the job of the Linux Desktop to make use of this preview capability 
> which is not limited to the file dialog but which shall also be taken 
> advantage of in the filemanager etc.

To be usable in the file manager application, this needs to be very
fast.  I'm not saying that this can't be made fast, but I'll humbly
suggest that you do some prototyping to come up with a set of sample
applications that provides sufficient performance.  Also, I'd recommend
talking with the GNOME and KDE folks who already have done a lot of
work on this...

>> IMHO, this will just lead ISVs to develop their own file choosers or
>> not use RUDI because they can't reliably provide previews and other
>> features (i.e. "open document with Word 95 filter instead of Word 2003",
>> for files that share extensions and are not otherwise detectable, like
>> the "open as" choose in the Gimp file chooser...)
> 
> IMHO this would be a poor choice because this custom dialogs has many 
> disadvantages including the lack of generic preview capabilities for the 
> desktop. 

Sigh.  Nothing should prevent a custom dialog from using the base
services to grab the preview image, etc. for a file.  I.e. there should
be a common set of APIs, not specific to a particular toolkit, which
provide access to this stuff and which can be used by any toolkit to
provide a similar user experience.

What you have said so far sounds like you want a monolithic "common
UI" interface which is used by all of the toolkits and ISVs,
preventing customization or tailoring beyond what you want to provide.

What I am saying is that your common UI interface will call out to the
KDE/GNOME/whatever "standard" dialogs, which will then use other
desktop-neutral APIs to provide access to common desktop resources
(previews/thumbnails, MIME types, file associations, etc.)  I also
expect that the various toolkits will provide their own APIs which
call out to the desktop-neutral APIs, as they already provide their
own custom stuff (we'll just be reducing the amount of duplicated
code...)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com