Re: Merging gio into glib

[Alexander Larsson <alexl redhat com>]

On Wed, 2007-11-14 at 16:32 +0000, Alp Toker wrote:
> Alexander Larsson wrote:
> > This seem like a totally backwards implementation. You're enforcing a
> > weird non-native dependency on dbus for windows. A better approach would
> > be to have a platform independent api for notification (possibly in
> > Gtk). This api would then have a unix implementation, and a win32
> > implementation. There is no reason at all for the win32 implementation
> > to use dbus. If there is no exposed win32 apis for doing notification
> > the best approach would imho be to implement those using win32 native
> > APIs (i.e. DCE/COM/OLE, not depending on dbus at all).
> >   
> 
> D-Bus over named pipes on Windows solves the same issues as D-Bus over 
> UNIX sockets, and provides an elegant solution for porting necessary 
> Freedesktop infrastructure to Windows without having to write a whole 
> new platform, which nobody's going to do. I've worked extensively with 
> OLE, COM and even DDE (guessing that's what you meant), and don't really 
> understand what you're suggesting we do with them, and why D-Bus isn't a 
> better choice.

Lets not use overloaded words like platform. But in essence, the current
goal for Gtk+ is to be a stack of libraries with APIs that contain
everything that a "typical" UI application needs (apart from the domain
specific stuff). This includes drawing pretty stuff, showing windows,
adding menus and buttons to windows, printing, loading and saving files.
It also should probably include storing application preferences and let
you inhibit the screensaver while e.g. showing a presentation. This
should be possible in the normal API, without using any platform
specific stuff, and the the library should do its best to implement the
features such that they work well with the native applications on the
platform it runs on (or degrades gracefully). This involves e.g. using
native printer dialogs and drivers, and using whatever means the system
has of inhibiting screensavers.

Now, exactly what functionality is required for "typical" apps is kinda
subjective. It also changes over time as new features become important.
I'm personally not sure that notification should be part of it (because
its not a well standardised UI, its not supported on some platforms, and
because popups are a gigantic PITA in general). 

However, if we for some reason decide to implement notification in Gtk+
and add a platform independent API for doing notification and we would
need to implement this on windows. Given that win32 has no native API
for this, how would one do that in a way that makes sense for windows
users? I don't think that adding a dependency on an external library
like dbus on win32 makes much sense. Instead (and I'm not an experienced
win32 developer so this might be wrong) I would make a small executable
and ship it with Gtk+, this would register some COM object in the
registry, and Gtk would instantiate it as a singleton via some
CoCreateWhateverExW() call. Then it would use standard win32 IPC
mechanism to tell this process to display notifications (I believe this
would use DDE).

Its not like an implementation of this using dbus wouldn't work. Its
just that it pulls in extra dependencies that are not common on windows
and as such are not very native (needs more setup, complicates build,
etc). However, on unix/linux, dbus is turning into part of the platform
infrastructure and standards, so there it makes sense to use it (by
linking to it behind the scenes, just like we'd link to the COM libs on
windows).