Hi, On Tue, Mar 3, 2009 at 1:19 PM, David Zeuthen <da...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
