Re: glib dbus bindings notes
- From: Havoc Pennington <hp pobox com>
- To: David Zeuthen <david fubar dk>
- Cc: gtk-devel-list <gtk-devel-list gnome org>, "dbus lists freedesktop org" <dbus lists freedesktop org>
- Subject: Re: glib dbus bindings notes
- Date: Tue, 3 Mar 2009 23:30:27 -0500
Hi,
On Tue, Mar 3, 2009 at 1:19 PM, David Zeuthen <david fubar dk> wrote:
> So I think maybe we want
>
> GBusLowlevelConnection
>
> that is useful for all languages and then
>
> GBusConnection
>
> for the C/GObject binding. But that's ugly. Ideas?
Maybe there's a ProxyManager or something which is higher level than
Connection? Or maybe the wrapper object on connection is the
high-level thing and then on lower level it's just DBusConnection
itself with some private data hanging off it, more like
hippo-dbus-helper?
> I guess your suggestion really is that EggDBusBus should be written by
> hand so we can put some extra client-side business logic into it; e.g.
> points 3. and 4; single instance, --replace support, all that jazz. And
> also make sure it can be bound to other languages like C without looking
> weird.
I probably didn't realize this file was generated.
My experience in apps is that almost all proxies require a wrapper
object; I usually have a "model" object representing the actual state
I'm tracking and then it keeps itself up-to-date with the remote state
using a proxy to make method calls and get changed signals. Anyway,
this seems like potentially another instance of the pattern, where
there might be a local Bus object which internally has a proxy for
talking to the remote bus, but keeps local state.
> macro or something. I don't know. I just don't think it's realistic to
> remove sync calls, by the same token, should we remove all the sync
> calls in GIO? I don't think so.
I've gotten more extreme on this over the years.
I had a rant at the bottom of http://log.ometer.com/2008-09.html
Basically my current opinion is that synchronous code in the main
thread of a GUI app should never ever get through patch review.
But... synchronous _APIs_ are still needed, so you can put them in
threads ;-) e.g. that's how GIO works, the async stuff calls the sync
stuff ...
I guess ultimately we have to allow app developers to shoot themselves
in the foot on this.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]