On Wed, 2009-07-22 at 17:36 -0400, Colin Walters wrote: > On Wed, Jul 22, 2009 at 5:07 PM, David Zeuthen<da...@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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list