.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ross Burton
Sent: Friday, October 19, 2007 2:01 AM
To: Alp Toker
Cc: Simon McVittie; gtk-devel-list; dbus-list; Havoc Pennington
Subject: Re: using dbus in the platform
On Thu, 2007-10-18 at 20:20 +0100, Alp Toker wrote
On Thu Oct 18 22:08, Alp Toker wrote:
Anyway, I'm going to leave further discussion in this thread to
application developers and distributors, since my opinions are always
going to be biased towards standardisation of D-Bus as a protocol rather
than an implementation, which may or may not
On Thu, 2007-10-18 at 20:20 +0100, Alp Toker wrote:
The Hiker project (http://www.hikerproject.org/), a mobile application
framework based around GTK+, uses ALP IPC
(http://www.hikerproject.org/doc/html/group___a_l_p___i_p_c.html).
ALP IPC is an abstraction layer. One of the implementations
Hi,
The point about toolkit vs. app framework I think is perfectly
debatable, but is best debated on its own, and considering lots of
things besides dbus, imo. I won't try to start that thread by laying out
a comprehensive position statement or anything. There is already some
stuff on Project
Hi,
Simon McVittie wrote:
I'm not convinced Gtk+ is the place to be experimenting with D-Bus
integration. Can't we do the experimentation in a libgdesktopbus or
libgnomebus or something, with convenience API for single-instance,
notifications, etc., that hides libdbus, and if it turns out
Havoc Pennington wrote:
[a lot of intelligent stuff about using dbus in our stack]
As an Xfce developer, I'm usually one of the first to be wary and
skeptical when large new bits of functionality are added to glib and gtk
(we try to use lightweight libraries with as few dependencies as
Havoc Pennington wrote:
Hi,
Simon McVittie wrote:
I'm not convinced Gtk+ is the place to be experimenting with D-Bus
integration. Can't we do the experimentation in a libgdesktopbus or
libgnomebus or something, with convenience API for single-instance,
notifications, etc., that hides
Brian,
I think you might have joined this discussion from the wrong angle.
There is no real debate that using D-Bus makes sense for traditional
desktop environments. NDesk, another GTK+ desktop environment,
implements dozens of Freedestkop standards, including several fdo D-Bus
specs.
The
amounting to ENOSYS) on platforms (perhaps NDesk) where a particular
action does not make sense. If NDesk is enough different from the
GNOME/KDE/XFCE setup, then GTK+ would have to treat it like Windows or
another platform, perhaps not using dbus there, rather than treating all
X11 scenarios
{Whoops, re-send. I brain-farted and addressed to the wrong mailing list!}
Alp Toker wrote:
I think you might have joined this discussion from the wrong angle.
There is no real debate that using D-Bus makes sense for traditional
desktop environments. NDesk, another GTK+ desktop
Reading my mail now, I've noticed it's perhaps a bit heated. Would like
to apologise for that, it's been a long day.
Though I still think your proposed show_help() abstraction is ugly, I
should also mention that DataModel.cs is pretty neat and I have no doubt
in your general competence ;-)
Hi,
Brian J. Tarricone wrote:
As for multiple implementations, why can't gtk have a simple pluggable
IPC module, sorta like the IM modules or GtkFileSystem? I know, I know,
it's one more layer of potentially-unneeded abstraction, one more API
that needs to be carefully designed since it
Havoc Pennington wrote:
Hi,
Alp Toker wrote:
2) GTK+ has a dependency on dbus, on X11 only, for desktop
integration features to work. (See list of examples above.) By
dependency I mean specifically:
- dbus.h is not included in gtk.h
- gtk or gdk contains interfaces such as settings,
Hi,
The concerns you raised are:
- multiple implementations of dbus protocol are extra overhead
- multiple connections to the bus from a single process are extra
overhead
- multiple connections may be confusing semantically
Well, there is a proposal on the table to avoid multiple
Hi,
Alp Toker wrote:
2) GTK+ has a dependency on dbus, on X11 only, for desktop
integration features to work. (See list of examples above.) By
dependency I mean specifically:
- dbus.h is not included in gtk.h
- gtk or gdk contains interfaces such as settings, notifications,
single
Havoc Pennington wrote:
I want to propose moving forward on this front. Here is a strawman approach.
1) Create a GLib main loop integration library, separate from
dbus-glib (dbus-glib should now depend on this main loop integration
library). Note the distinction between a framework
Hi,
Various bits of the GNOME platform are ending up off to the side or
not integrated into gtk properly due to the dbus dependency.
(previously whining about this at
http://lists.freedesktop.org/archives/dbus/2007-August/008238.html)
Examples of features that do or could use dbus, which should
On 9/28/07, Havoc Pennington [EMAIL PROTECTED] wrote
Sounds like a fine strategy, and I believe one that has been
implicitly agreed on by most people for some time; thanks for writing
it down so clearly and calling for action. We have been seeing these
integration points that need dbus come up
18 matches
Mail list logo
