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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list