Re: GtkApplication and argc/arv
Hi, On Sat, Feb 26, 2011 at 9:35 AM, David Zeuthen wrote: > but if someone writes a nice dbus-daemon(1) patch, we > would probably accept it, right? > I suppose... if they had enough test coverage to prove it actually worked ... Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)
Hey, On Sat, Feb 26, 2011 at 10:26 AM, Paul Davis wrote: > On Sat, Feb 26, 2011 at 10:00 AM, David Zeuthen wrote: >> Hi, >> >> Just for the record, there's no reason that GDBus cannot be made to >> work very nicely on Win32 or any other platform we care about. GDBus >> (and D-Bus itself) was designed with this goal in mind. > > what functionality is (G)D-Bus supposed to be providing on other > platforms? my impression has been that on linux it provides stuff that > both OS X and Windows already provides (plus or minus a detail or > two). if that impression is correct, why would anyone run (G)D-Bus on > those platforms? if its not correct, what is the functionality that > (G)D-Bus is offering to linux that is missing from those platforms? if > you're talking about just a portable API to interact with various > system services and notifications, then fine, but that's a bit > different than talking about D-Bus itself, i think. Yes, on the free desktop we use D-Bus a lot in system services (udisks, upower etc.) and in the sessions to implement the desktop itself (notifications, session management etc.) - neither of which (portable) apps should use. Instead apps should use the interfaces in GLib/GTK+. For example, instead of speaking to udisks directly, the app should use GVolumeMonitor which on Linux uses udisks and on Win32 uses the native APIs. Ditto for pretty much everything else. > just to be clear: i'm a big fan of the functionality that D-Bus (at > least the system bus and maybe the session bus too) has made possible > on linux. i just don't understand why anyone would imagine using it on > other platforms. One place where D-Bus is useful is for an app to provide a remote control interface so e.g. 3rd party apps can control it / interact with it. The app just says: use interface org.App.Bar on object /org/App/bar on the name org.App.FooApp on the session bus. But, yeah, D-Bus isn't all that useful for apps as is it to build an OS... I'd argue it would still be nice to have GDBus working *out of the box* in Win32 and OS X. Someone just need to do the work - it's already 99% done... David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)
On Sat, Feb 26, 2011 at 10:00 AM, David Zeuthen wrote: > Hi, > > Just for the record, there's no reason that GDBus cannot be made to > work very nicely on Win32 or any other platform we care about. GDBus > (and D-Bus itself) was designed with this goal in mind. what functionality is (G)D-Bus supposed to be providing on other platforms? my impression has been that on linux it provides stuff that both OS X and Windows already provides (plus or minus a detail or two). if that impression is correct, why would anyone run (G)D-Bus on those platforms? if its not correct, what is the functionality that (G)D-Bus is offering to linux that is missing from those platforms? if you're talking about just a portable API to interact with various system services and notifications, then fine, but that's a bit different than talking about D-Bus itself, i think. just to be clear: i'm a big fan of the functionality that D-Bus (at least the system bus and maybe the session bus too) has made possible on linux. i just don't understand why anyone would imagine using it on other platforms. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)
Hi, Just for the record, there's no reason that GDBus cannot be made to work very nicely on Win32 or any other platform we care about. GDBus (and D-Bus itself) was designed with this goal in mind. That is to say, it is possible to make a Win32 build of GLib where GDBus works as expect in both peer-to-peer mode (this already works, GDBus supports e.g. the nonce-tcp: transport) and in session bus mode (including autospawning the bus if necessary and talking to other apps etc.) FWIW, the latter clearly includes shipping a copy of dbus-daemon.exe along with the GLib libraries which you already need to ship as part of your app. It also includes D-Bus spec work to find the address of the bus - right now this is *undocumented* (that is, http://dbus.freedesktop.org/doc/dbus-specification.html does not mention how) but I had this working at some point, see http://cgit.freedesktop.org/~david/gdbus-standalone/commit/?id=44c8871c5c27337dc1905a0b4c9d35d46eb2144a http://people.freedesktop.org/~david/gdbus-win32.png If someone wants to work on this, I'd recommend 1. Get the missing pieces into the spec (the DBusAutolaunchMutex and DBusDaemonMutex stuff). 2. Make "dbus-launch --autolaunch= --binary-syntax --close-stderr" a supported and official D-Bus interface - because with this 3rd party D-Bus implementations (like GDBus) can simply use that to launch the message bus (e.g. not have to care about where to get the bus address, be it in the X server, the Windows registry, OS X's launch or whatever). Note: on the free desktop we actually rely on this to work http://git.gnome.org/browse/glib/tree/gio/gdbusaddress.c?id=2.28.0#n1012 3. Ship dbus-daemon.exe and dbus-launch.exe (and possibly other bits from the dbus-1 package) along with the GLib libraries on Win32 (and ditto on OS X) Bottom line: D-Bus support can (relatively easily) be made to work on all the platforms that we care about in GLib and GTK+. Which means that it's actually fine to have a *hard* dependency on D-Bus in GApplication if we wanted. Of course it's a lot easier to not use D-Bus because in reality Win32 and OS X resources in the GLib and D-Bus projects are just not there. And for other reasons, it's probably better to use native frameworks for application uniqueness *anyway* - for example, on Win 7 you want to use the native APIs for better shell integration. David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
Hey, On Fri, Feb 25, 2011 at 2:28 PM, Havoc Pennington wrote: > So upstream's advice is, don't restart, because apps won't handle it. > > If you want to fix all the apps, you can do so. There are no > dbus-daemon changes required. If you really wanted to handle the "dbus package got upgraded, let's switch to running the new code asap" use-case (which is the core thing people want to do), I think a nicer solution is to make dbus-daemon(1) exec(2) a new copy of itself passing all state (including fds with existing connections) to the new copy. I think init(1) does that. Of course, this is nasty business, you have to establish and maintain a stable restart-protocol... Of course this doesn't handle the case where dbus-daemon(1) segfaults but the other solution (handle restarts in apps) doesn't cover more interesting cases like dbus-daemon(1) hanging or otherwise malfunctioning. Either way, I personally think the whole "problem" is a gigantic waste of time to discuss so I usually avoid discussing it ... for me, it's totally a non-issue if you just accept that the Core OS is more than just code running in ring 0 and that we don't support this for the OS kernel either (yes, we all know about ksplice, no need to bring it up). So when people complain I tell them to write that dbus-daemon(1) patch if they want and that usually makes them go away. > (fwiw, g_bus_own_name() in gdbus could in theory make it considerably > easier to handle bus restart, assuming gdbus itself handles it.) Early versions of the gdbus code actually did that... but it made the code a lot more complex than it needed to be (resubmitting match rules, invalidating assumptions about the unique name being constant etc. etc.)... then I decided that the issue can (and I think, should) be fixed in the dbus-daemon(1) if you really want to... I, for one, don't care - but if someone writes a nice dbus-daemon(1) patch, we would probably accept it, right? David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
