Re: gnome desktop integration library

[Havoc Pennington <hp redhat com>]

Jonathan Blandford wrote:
> Right now, there are three major uses for GTK+:
>
> * the GNOME Desktop toolkit (rich desktop experience)
> * a cross-platform toolkit (LCD approach)
> * an embedded platform (pick-and-choose)

It's a bit of a false choice; I don't think the LCD approach is required 
in a cross-platform toolkit. If the nature of one platform really 
requires doing xyz in most apps, but xyz cannot be done on all 
platforms, an API that contains feature tests 
("gtk_platform_has_foo()"), or an API in a platform specific header 
("gdkx.h"), is imo _right_. Just because it's a little grotty doesn't 
mean GTK should be all purity of essence and leave the problem dumped in 
the laps of app developers.

To me the path GTK+ is obviously on, in practice, is that it's written 
to be a desktop toolkit, and people use it in embedded by subsetting it 
or hacking it up a little. Which seems fine; I think Qt pretty much has 
the same model, with perhaps more attention to providing tools for the 
subsetting and hacking.

> Right now, GTK+ is walking a delicate balance between these three
> things.

But, assuming it's a required choice - for the first two, is it GTK+ 
walking the delicate balance, or is it *almost all the important apps* 
and the *GNOME desktop itself* in terms of user experience?

Aren't Firefox, OO.org, GIMP, AbiWord, etc. also walking that balance?

Isn't GNOME effectively restricted from diverging too much from the 
"normal" behavior of a desktop, because in practice all the apps (and at 
this stage, users) expect it to be largely similar to other platforms?

Even ignoring Windows, just the freedesktop.org specs (EWMH, autostart, 
menus) all assume a fairly standard desktop.

My point is, it's not like GNOME is going to radically diverge from what 
can be cross-platform. Once you make the macro-level decisions like the 
desktop has a panel with an app launcher menu, there's a task list, each 
window has a menu, apps consist of document windows and dialogs, etc. 
then things are fairly locked and loaded. You aren't talking about 
suddenly changing to another model sometime.

Here are some tradeoff options as I see it:
 - allow apps to be mostly cross-platform. take advantage of basic
   "standardness" of GNOME.
 - make big, fundamental changes in GNOME platform vs. others.
   require all apps to be fundamentally GNOME-specific.
   Don't support running cross-platform apps. Take advantage
   of ability to do strong unique user experience for GNOME.
   e.g. OLPC is doing this, right? with Sugar.
 - gratuitously have distinct API for GNOME platform, making big
   pain for app developers, but have user experience be the
   "standard" one anyway.

The last is both the lazy/default thing to do, and the stupidest, if it 
isn't obvious.

>  There are some features that work in the first case, but not
> the other two (such as the proposed 'Open With...' dialog).

Why not? Thunderbird and Firefox on Windows have an Open With dialog, so 
obviously apps have a use for it (and it's possible to implement it).

> Since we
> can't quite resolve it or don't have the time to do the work to handle
> all worlds.

The don't have time argument leads to a libno-time-to-port-to-windows 
which kind of sucks as a way to organize the platform. Didn't GTK used 
to have a policy that stuff went in for X and the Windows team had to 
keep up? It was a little harsh, but given the fact that nobody else knew 
how to code the Windows bits, maybe the only feasible approach.

Havoc