[Portland] Thoughts on the integration tasks

[Lubos Lunak]

On Thursday 08 December 2005 05:19, Billy Biggs wrote:
>   Hi!  I work on the SWT widget toolkit, part of the Eclipse project.
>
>   I took a look at the PortlandIntegrationTasks list and it seems to me
> that many of the things on this list are already well covered by
> existing APIs used by running applications.  For example, GTK+, Qt, and
> Motif all have a concept of a default application font, and it is well
> understood how to query it.  For MIME system integration, KMimeType and
> GNOME-VFS are mostly well established (if they'd stop breaking!).   :)

 Yes, Gtk, Qt and Motif have a concept of a default font, it's just that it's 
not the same default font.

>   Rather than design a new ISV support library, it may be more
> productive to identify and address the abundant low-hanging fruit in
> desktop interoperability.

 In Rudi's case, as I see it, the thing to be designed would be only the API 
itself (the IPC), not a library. Then toolkits like Qt and Gtk could use it 
directly, while for others who wouldn't want to do this there could be a 
simple library (that'd be more or less just simple IPC<->plain C wrapper). I 
don't think that suggesting XSETTINGS is really different from it, you need 
to find out what to communicate and how to communicate it. In the Rudi case 
this is description of the IPC calls and the IPC mechanism respectively, in 
the XSETTINGS case this is description of the various XSETTINGS keys and the 
(already existing) XSETTINGS mechanism.

> For fonts and other system settings, the 
> XSETTINGS protocol was designed and used by GTK+ with the intention of
> promoting interopability, and it was capitalized on by XFCE, but it
> seems it was never implemented in KDE/krdb.  I'm sure that the other way
> around, having gnome-settings-daemon manage KDE fonts, would be equally
> beneficial and likely as simple.

 No, Qt/KDE don't use it AFAIK. I'm not sure why, the spec looks quite 
sensible to me when reading it, I have a very vague feeling it had something 
to do with TrollTech not liking it for some reason, but it's really a very 
vague feeling.

 However I think XSETTINGS cannot do that much, since it appears to be only 
passive. It can tell you the default font or the button ordering but it's not 
going to open the right application for a specific file, disable the 
screensaver or similar things that require activity from the desktop.

>   Even for the file dialog, if the toolkit dialog ever looks out of
> place, that seems like a bug in the dialog.  However, I tend to think
> that the "file dialog problem" is maybe less important than its status
> as canonical-interop-issue would indicate.  When presented with a novel
> dialog, users can at least see that it's different and can deal with it,
> and furthermore it's not uncommon for applications to customize the file
> dialog in some way.  The killer interop issues are the more subtle ones
> anyway:
>
>   - WM keybindings aren't standardized, and their union takes over a
>     very large range of "nice" keybindings.  This makes it really hard
>     to select sane default keybindings in Eclipse that don't conflict
>   - keybindings for standard widgets aren't always consistent either

 You should have at least 36 free keybindings ( Ctrl+<A-Z,0-9> ). But I have 
to admit it wouldn't occur to me this could be an interoperatibility problem.

>   - input method selection and control, and the general problem of the
>     appearance of the right-click menu on any text input widget
>   - drag-and-drop interop and standard formats

 There's no problem with drag&drop AFAIK, only with standard formats (well, 
and the fact that often people get things wrong).

>   - dialog button ordering - I think there is now an XSETTINGS setting,
>     can KDE just set this property, and honour it in return?

 I think the question should be about XSETTINGS in general, not just one 
specific setting. I don't know, perhaps, if there's nothing better.

>   - kwin versus metacity behaviour is always fun :)

 If I remember well it's usually just you assuming too much about how a WM 
works, or plain bugs. I don't think there's anything related to WMs that 
needs special care. If you have farther requirements for WM functionality, 
there's the WM spec list.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/