[Open Office] Generic desktop adapter (proposal & prototype)

[nf2]

Jan Holesovsky wrote:

>Hi Norbert,
>
>On Monday 28 November 2005 14:40, nf2 wrote:
>
>  
>
>>Perhaps this is interesting for you. I would like to get some
>>feedback from people which have practical experience with integrating
>>3rd party applications like openoffice.org into desktop environments.
>>
>>The aim of the "Generic dasktop adapter" is to provide a standardized
>>interface between applications and desktops (for filechoosers and VFS).
>>The concept is simple: Applications load the appropriate desktop-adapter
>>with dlopen(), depending on the desktop they are running in:
>>
>>     * libdadapt-kde-1.0.so
>>     * libdadapt-gnome-1.0.so
>>     * libdadapt-xyz-1.0.so
>>    
>>
>
>Basically, it is the same what OOo does for its desktop integration, so in 
>fact, this is a solved issue ;-)  But I understand what you mean by your 
>proposal in general.
>  
>
I see. Perhaps OpenOffice.org is a bad "use case" for the "Generic 
Desktop Adapter.", because it is such an imporant application that 
desktop bindings are beeing developed and mantained. Plus it has a 
toolkit and a component architecture which makes such bindings possible 
(Which is not true for the average Gtk+ or Qt application.)

But still... Linux has a big "there is no standardized desktop API" 
problem. Especially for applications which are not that popular. I think 
it should be possible to write an application for Linux/Unix, without 
targeting a certain desktop.

>OpenOffice.org does the desktop integration through so-called 'vclplugs' for 
>the theming of widgets, or through its component architecture (UNO) for the 
>Gnome/KDE file dialogs, or address books.  But the principle is the same, 
>dlopening appropriate .so's according to the desktop it runs in.  OOo does 
>not need a common (Gtk+ + Qt) main loop for this, it uses just the features 
>that are currently available.
>
>The main problem I see with your approach is that you will have to support 
>each and every feature the target application uses.  E.g. in case of OOo, 
>file dialog is not just two simple calls like ShowTheFileDialog() and 
>GiveMeTheSelectedFiles(); OOo has to have full control over the dialog, like 
>adding new widgets there, modifying content of them according to the selected 
>files, and more.  I believe other applications will have other special wishes 
>and needs, so my opinion is that this would be a maintainance nightmare.
>  
>
There might be workarounds for that:

1) The application just pops up a second dialog after the file-dialog 
(like Gimp does it for the jpeg/png compression settings)

2) The application pops up it's own dialog showing the special widgets 
(preview, additional options,...). This dialog has a "choose file" 
button, which opens the file-chooser provided by the generic desktop 
adapter.

3) Nicer: The Generic Desktop Adapter provides the file-chooser as 
XEmbed widget (working like KParts. Dmitry M. Shatrovs GParts demo shows 
that such things are possible).

Or, perhaps an "adavanced" file-dialog can be served by the 
desktop-adapter, which covers most of the "special" wishes. By using 
modules, named interfaces and LVariants as communication media, it's 
quite easy to extend the functionality of the desktop-adapter without 
breaking compatibilty.

The file-dialog requirements of Openoffice don't seem that sophisticated 
and it might be possible to standardize them and make them available to 
other applications too. It seems it's just

* choosing from a list of filters or filter groups
* a document version selector, which could be fed by a callback.
* a "read only" checkbox
* a preview area, which could also be implemented by picking up a pixmap 
with a callback.

Norbert