Re: GNOME and non-linux platforms (release team please stand up)

[David Zeuthen <david fubar dk>]

On Wed, 2009-07-22 at 17:36 -0400, Colin Walters wrote:
> On Wed, Jul 22, 2009 at 5:07 PM, David Zeuthen<david fubar dk> wrote:
> 
> I agree with a lot of what you say, except:
> 
> >  b. Everything in the core platform _needs_ to work on all three major
> >    platforms:
> >    - POSIX/X11
> 
> This isn't a platform really.  Which is really the entire debate here.
>  They're enough, along with maybe a file monitoring API, to write the
> classic "shared Unix server desktop, complete with file manager,
> clock, and panel".  But beyond that - enterprise (let alone consumer)
> laptops in particular, no way.

No, but it's a starting point. Just like GUnixVolumeMonitor is a
starting point. And the same way GFileMonitor has a FAM backend (that
FreeBSD is still using as far as I can tell). People can fill in the
blanks with better implementations.

> If you guys working on DeviceKit-* are willing to have different
> backends, then that sounds fine.  It's not a complete answer, but it
> fills in the massive gap that removing HAL left.  If not, then we have
> to think about the story GNOME is going to tell here.  

We might but it's a lot of work. It is probably worth it.

> Maybe it just
> ends up being gnome-power-manager isn't even added to the session if
> there's no DK-power, and vendors have to fill in that gap on their
> own, i.e. it'd be renamed gnome-dk-power-manager, and someone else
> could come by and add a different daemon.

It's important to make a clear distinction between apps and the G stack.
For something like storage handling, every app needs it for the file
chooser. And for things being able to implement a file manager. So we
implement just enough of it in the G stack so it is useful.

For example, Nautilus basically (that's a big basically, but...) only
depends on GLib and GTK+ right now. But we don't offer enough API in the
G stack to write e.g. Palimpsest Disk Utility - e.g. if you want to
write a formatting tool, partitioning utility, whatever you need to
depend on something outside the platform. It just means that ISVs can
only write file managers and not advanced disk utilities. And that's
fine.

For power management, maybe we only offer basic API in the G stack to do
what apps need: E.g. inhibit system suspend / inhibit screensaver. And,
again, that's completely fine. We don't expect ISVs to be able to
implement complete desktop environments.

For Bluetooth, another Linux only thing for now, the answer is the same;
we probably don't need Bluetooth specific APIs - mostly because we
already abstract the useful Bluetooth stuff in GVfs and PulseAudio.

For Audio, it is basically the same. Apps don't really *need* to care
about whether it's Pulse/OSSv4 or whatever. They are supposed to be
using GStreamer *anyway*. So we probably don't need to provide any API
in the G stack except for things things like libcanberra which is
already portable to whatever.

Anyway, my main point is this: the POSIX/X11 target isn't so much about
making "GNOME, the desktop" run on POSIX/X11. It's about making apps
*built* for "GNOME, the desktop", e.g. apps using only the G stack (e.g.
GLib / GTK+ / GStreamer / Clutter / Webkit / whatever) run on any random
POSIX/X11 system. Or any random Win32 or OS X system.

In *addition* we could require that the basic desktop shell (core apps
such as Nautilus, gnome-panel - gnome-shell in the future) needs to be
pure apps - e.g. only rely on the G stack. We'd probably want that even
if it means the basic desktop shell would run in degraded mode (e.g.
missing functionality).

This would of course also means that some apps that people think of as
"core GNOME apps", such as gnome-power-manager wouldn't really be pure
apps (only using the G stack) insofar they would have strong deps on
things outside the G stack (e.g. devkit-power). Again, that's completely
fine.

It's all about how we *frame* it

 - G Stack (runs on any target)
   - gtk+/glib/gstreamer/clutter/webkit/whatever
 - G apps (can only depend on the G stack)
   - panel, file manager, desktop shell
 - Value add apps (may be OS specific)
   - disk utility / formatting / etc.
   - power manager
   - volume control (highly OS specific)

In my view this is very close to how things actually work. If we made
something like this official we wouldn't have to waste time arguing
whether the volume control is depending on PulseAudio or not.... of
course it would leave vendors not shipping PulseAudio in the cold, but
then again, these vendors can just work on their own volume control (or
take the GStreamer one) and do whatever they want. That's completely
fine.

So all in all, this is basically proposing shifting more responsibility
to the OS vendor. e.g. it would make it more difficult to get GNOME
working out of the box unless you are willing to ship the latest bits.
I, for one, think that is a *good* thing. Either you swim or you sink.

      David