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

[David Zeuthen <david fubar dk>]

On Wed, 2009-07-22 at 23:29 +0100, Bastien Nocera wrote:
> On Wed, 2009-07-22 at 18:17 -0400, David Zeuthen wrote:
> > 
> > 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.
> 
> Actually, not quite. The BlueZ D-Bus API is already an abstraction of
> the Bluetooth specs. You could implement that same API in another daemon
> for use on other Bluetooth stacks.

Yeah. But right now it is Linux only und so weiter... If someone ports
Bluez to other platforms, or reimplements, then, hey, great, they can
take advantage of all the cool Bluez integration you have written. That
alone should be reason enough for them to do it. But things like this
just don't happen over night. It took 2+ years for a Solaris backend for
HAL to surface and another year or so for the FreeBSD backend.

My main point really is that we need to stop thinking of GNOME as a
whole desktop environment that will run everywhere and solve every
problem known to man. We need to stop bickering about really OS-specific
things such as volume controls. We need to make a distinction between
applications (the thing people actually use) and OS-specific conduits
(audio volume control, formatting a disk).

We need to focus hard on providing a set of rich, but lean and tightly
controlled (e.g. solid maintainers needed), introspectable libraries so
people can write useful _applications_ in their favorite language. And,
ideally, for any target. And, more ideally, so apps are relocatable (cf.
the recent thread on gtk-devel-list).

Further, we need to design these APIs so they are extendable. We want to
provide baseline functionality for the X11/target (GUnixVolumeMonitor)
while at the same time take advantage of the latest and greatest
OS-specific software (DeviceKit-disks monitor).

(And, for those of you still reading, GIO/GVfs is an _excellent_ example
of how to do this. Alex really got this right.)

That set of APIs will provide a good foundation so people can innovate
in areas like GNOME Shell, Sugar, whatever without having to worry about
a lot of things.

(Of course we still need to care about system integration, e.g. the
whole DeviceKit-{disks,power}, PackageKit, Pulseaudio, Bluez story. But
it really shouldn't be anything that affects the G stack except that it
might optionally use parts of it in certain place. And we might use it
in apps that are not pure G apps - e.g. Bluez desktop integration,
Volume Control, Palimpsest and so on.)

     David