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

[David Zeuthen <david fubar dk>]

On Wed, 2009-07-22 at 15:50 -0400, Colin Walters wrote: 
> On Wed, Jul 22, 2009 at 3:10 PM, Colin Walters<walters verbum org> wrote:
> >
> > I think it makes sense to continue to have GNOME work in the basic
> > "POSIX+X11" mode, i.e. gnome-power-manager just calls exit(0) if
> > devicekit-power isn't running.  But beyond that is hard.
> 
> I should add that despite it being hard, the different interests here
> should try to have a constructive conversation about it.
> 
> Some of this is more easily divisible than others; nothing directly
> depends on nm-applet, and most projects using say
> org.freedesktop.NetworkManager already have it conditional, and it's
> not hard to do.  For other things like detecting a webcam device and
> using it...well...hard.

Exactly.

FWIW, I've been advocating for a while that, for example, GStreamer
should aim to provide everything an application needs - ie. a complete
framework. This came up when Cheese was being ported from HAL to use
libgudev for device discovery. Now, the actual device interaction
already happened in GStreamer, e.g. you use the v4l source and pass it a
device file. But device detection etc. was missing. Having all that in
GStreamer will make Cheese easily portable to Solaris, Windows, OS X and
so on (and AFAICT these changes are happening in GStreamer so kudos to
these guys).

On a more general note, the way I'd like our platform story to end up is
that GLib, GTK+ and GStreamer are the three only (sets of) libraries
that people end up using. We're there already for storage/io devices
(GVolumeMonitor) and networking (the networking/resolving bits that
recently landed in GIO).

The way it works for storage/io is through GIO extension points:

 - The interface library (GIO) provides default implementations
   (GUnixVolumeMonitor, GWin32DirectoryMonitor for example)

 - Modern desktop operating systems can be replace implementations
   with in 3rd party packages. We do this in GVfs - there's a HAL
   based volume monitor that works on Linux, FreeBSD and Solaris.

In fact, thanks to this separation it was relatively straightforward to
just make GIO use DeviceKit-disks instead of HAL. And Solaris and
FreeBSD can keep using the HAL monitor while modern Linux distros switch
to the DeviceKit-disks based on.

(In fact, if the Solaris folks don't want to go through the effort of
porting DeviceKit-disks (it's *hard* to port right now, something I as
the maintainer will need to be involved in fixing), they can simply just
write their own GVolumeMonitor implementation.)

Another benefit of this separation is that we are less dependent on
changes in one particular operating system. This is doubly-plus
important in Linux where our current code depends on certain kernel
API / details that are not stable. A concrete example is the proposed
libata transition from the SCSI layer to the block layer. If each and
every app had to look at sysfs themselves, we'd be in porting hell.

To sum up, I guess I'm trying to say a couple of things here

 1. We need to make our core libraries genuinely useful - e.g. we
    can't have them only do half of what apps need (e.g. Cheese)

 2. We need to actually have some documentation telling app developers
    _what_ the core platform is. We have some of this already but,
    at least in my eyes, there's still too many libraries of varying
    quality.

For 2., my view is very simple. 

 a. Our platform is GLib, GTK+ and GStreamer (and probably cool things
    like Clutter when it's 1.0)

 b. Everything in the core platform _needs_ to work on all three major
    platforms:
    - POSIX/X11
    - Windows
    - OS X

 c. Additional desktop integration is welcome (e.g. DeviceKit-disks
    based volume monitor) but things need to work without it

Now, GLib, GTK+ and GStreamer aren't yet complete enough to do a
complete desktop. But if you look at what's going on the past few years
we are definitely going in this direction:

 - GIO landed
 - GNIO landed
 - Discussion/concrete code for GConf replacement (GSettings in GLib)
 - Discussion/concrete code for G-ish D-Bus library in GLib
 - Some people want power management interfaces in GTK+ - again,
   this can already be done with extension points
   - (e.g. the POSIX/X11 would ENOTSUP, Linux would use devkit-power,
      Win32 would use the Win32 API, OS X would use the OS X API)

and so on. Oh, and there are some loose ends here like authorization,
keyring and so on - we'd need to figure out what to do with them. And
someone probably would want a HTML/JS stack too (maybe add WebKit to the
stack, I don't know).

So this is the vision: GLib/GTK+/GStreamer (and Clutter) is the proposed
stack. And the proposal is that this stack runs on at least POSIX/X11,
Win32, OS X. And that the stack is easily extensible so it works well
under Linux, Solaris providing someone writes implementations of
well-defined interfaces.

Again, all this is not really a radical _new_ idea - I mean, most of
this is already happening. But I think it would be good to have a very
clear and simple document saying this is where we are going. That is, if
people agree with this vision (points a. through c. above).

Anyway, my couple of hundred cents on this.

     David