On Thu, 2010-02-18 at 13:57 -0500, Colin Walters wrote: > On Thu, Feb 18, 2010 at 1:46 PM, Ted Gould <ted gould cx> wrote: > > Yes, I think GTK/glib is a good place. One of the big blockers is the > > requirement for DBus, > > Yes, clearly having glib-dbus in the stack today would help a lot; > however gvfs already has an internal (private) connection, we can > figure this out. I think having an internal non-public API would not > be too hard. > > If it'll help move things along here I think I can schedule some of my > time for this relatively soon, basically just move gvfs/gdbusutils.c > to glib/gio/gbus-private.c. Ah, okay. I didn't realize that dbus was in gio, seems obvious now that you told me :) > > I think that, as long as the APIs are really similar, porting from > > libappindicator to the GAppIndicator (or whatever) shouldn't be too > > difficult. That being said, how can we make sure the APIs are really > > similar? > > Assuming the design doesn't change, any API delta (as long as it's not > too egregious) is less interesting than the simple inertia effect of > having created a lot of patches for various projects, and patching > them again, even if it's almost a sed job. Yes, I would hope that it wouldn't need to change much. I'm not sure how to guarantee that though. "I here by mandate no one can disagree with me" rarely works ;) I think that the API is probably a little bit off topic for this list though, so I'd invite everyone interested over the Ayatana list to hash through it a little bit more. http://launchpad.net/~ayatana I haven't yet put together of list of ideas for what to do in the next phase of development, so it would be a great time to get everyone's ideas to make sure their requirements are taken into account. --Ted
Attachment:
signature.asc
Description: This is a digitally signed message part