Re: External Dependency Proposal: libappindicator
- From: Bastien Nocera <hadess hadess net>
- To: Danielle Madeley <danielle madeley collabora co uk>
- Cc: GNOME Desktop Developers Mailing List <desktop-devel-list gnome org>
- Subject: Re: External Dependency Proposal: libappindicator
- Date: Mon, 22 Feb 2010 00:25:32 +0000
On Mon, 2010-02-22 at 11:18 +1100, Danielle Madeley wrote:
> On Fri, 2010-02-19 at 22:54 -0600, Ted Gould wrote:
>
> > > It would be much cleaner to
> > > either expose the underlying dbus api or proxy something that is
> > > explicitly designed with this in mind: GtkActions.
> >
> > That's a great idea. What do you think would be a good API/name for a
> > function that did that? Do you think it should take an array of actions
> > or some sort of root action? Do you think that the function that takes
> > a GtkMenu * should be deprecated?
>
> It seems to me that it should probably take a GtkUIManager path.
>
> It can then serialise the menu description and association GtkActions
> over the bus to be recreated on the other side.
>
> Applications creating their menus directly and not using GtkUIManager
> should probably be ported anyway.
There's a number of things you cannot do with GtkUIManager and
GtkActions though, which is have access to the presentation of the
menus.
In gnome-bluetooth, I'd like to have bold menu items to represent
connected devices. I would also like to have some control over whether
device names will be ellipsised (or how). Both of which are currently
not possible with GtkActions.
> I would remove any API that takes a GtkMenu directly, since this is a
> GtkWidget and really cannot be reliably proxied over D-Bus (what would
> happen if I tried to poke in some of the widget properties of that
> GtkMenu?).
>
> --danni
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]