[Portland] Thoughts on the integration tasks

[Billy Biggs]

  Hi Martin, hope this reply isn't too long...  We should probably just
pick some issue and get to the bottom of it (like, fonts) and avoid too
much philosophy, so if you decide not to reply to any of this I won't
take it to mean that you agree or disagree with me ;)


Martin Konold (martin.konold at erfrakon.de):

> So what is the common cross desktop way of query of the default fonts?
> (So that we simply can document it!)

  widget = gtk_window_new ();
  style = gtk_widget_get_style (widget);
  font = pango_font_description_copy (gtk_style_get_font_desc (style));

  and

  font = QApplication::font (0);

  Both are documented to return the default application font, and so I
want to see them both return the same font.  My point with the XSETTINGS
thing is that I think this is achievable.

> BTW: How do you expect Java programmers to use the XSETTINGS protocol?

  You mean Swing programmers?  I don't know how fonts work in that
toolkit, but with any sort of ISV library you'd need to have a Java
implementation, and it would likely need some native code, so you're
already in trouble.  Swing clearly already gets the default application
fonts right on Mac and Win32, so they should be able to honour XSETTINGS
as well just as easily as using a new ISV library.

> I don't want to go that far. But look for example at a standard Java/Swing.
> [...]
> It looks and works very different from a users point of view. Actually if you 
> for example use this Java dialog on a KDE desktop you will be disappointed in 
> many respects including missing bookmarks and shortcuts.
> 
> http://aseigo.blogspot.com/2005/07/kdes-file-dialog-is-movie-player.html

  My understanding is that the Swing UI system has traditionally looked
out of place on other platforms as well, but that it has a theming API
which tries to match the platform look as much as possible.  I'm not
sure if they have a native file dialog API similar to QFileDialog's
static functions though.  In new branches my understanding is that
they're using the GTK+ look-and-feel through the GtkStyle API.

  For rich content in the file dialog you're screwed, but I'm not sure
how you could help a Swing application in this way without giving them a
huge wad of code to open a KDE dialog, and having Swing applications use
that, which may not be feasible.  Furthermore, there are some tricky
issues: you need to have the file dialog opened through RuDI or whatever
to be parented correctly (TRANSIENT_FOR hints set right), and you need
the UI of the spawning app to have the correct modality, etc.  So this
quickly gets toolkit specific.

> So maybe it would make sense if Eclipse could adapt itself to the environment 
> it is running in. E.g. I expect that Eclipse is using Mac-like keybindings on 
> Mac OS and Windows like keybindings on Windows while I also expect that 
> eclipse offers keybindings which fit to the desktop environment on Unix e.g. 
> CDE, GNOME and KDE.

  This is exactly the issue.  We currently have keybinding differences
for Win32, Mac, and UNIX, and would rather not have to maintain and test
separate keybindings for GNOME vs KDE.  It's really hard to detect which
one you're under, for example, and there has traditionally been pressure
to not have these sort of desktop switches in application code (see the
"desktop-open" thread on xdg-list).

  This is already an issue though without per-application keybindings.
Ctrl+F1 is the standard "Help" keybinding under GTK+, but this doesn't
work under kwin for obvious reasons.

> >   - keybindings for standard widgets aren't always consistent either
> 
> You mean that GNOME/KDE use different keybindings for similar tasks within 
> similar widgets?

  Yes.  Look at a tree widget, which has a ton of standard keybindings.
Try shift right/left, keypad *, and typeahead search, and compare the
behaviour between GTK+ and Qt/KDE applications.

> >   - drag-and-drop interop and standard formats
> There is a spec for D&D. 
> 	http://www.newplanetsoftware.com/xdnd/

  I'm aware of this standard but my understanding was that many complex
data types still don't work properly, but I could be wrong on this and
it may just be bugs in our drag-and-drop transfer types.

> >   - dialog button ordering - I think there is now an XSETTINGS
> I just checked
> http://standards.freedesktop.org/xsettings-spec/xsettings-spec-0.5.html

  Unfortunately, this just documents the protocol, not which settings
are honoured by GTK+.  For example, Net/CursorBlinkTime,
Net/DndDragThreshold, and Gtk/ButtonImages (whether to show images on
buttons) are all interesting.  I was thinking of, I think,
Gtk/AlternativeButtonOrder, but I'm not sure if this is right.

> >   - kwin versus metacity behaviour is always fun :)
> 
> Is this due to lack of specification?

  Specification helps but of course the problem is worse.  From recent
history, check out these two bugs:

    http://bugs.eclipse.org/bugs/show_bug.cgi?id=119743
    http://bugs.eclipse.org/bugs/show_bug.cgi?id=113618

  I mean, I put it on the list because anything that makes them act more
similar would be awesome (kwin to stop centering all dialogs even when
asked not to, metacity and kwin to agree on how a splash screen or tool
window hint should behave, etc), what really hurts us is that these WMs
are both buggy and expose different timing issues, and it's hard to
catch these bugs and work around them with two WMs to test.

  -Billy