unity-design team mailing list archive

[Ted Gould <ted@xxxxxxxxxxxxx>]

On Thu, 2010-03-11 at 08:53 +0100, Marcelo Hashimoto wrote:
> Hello Ted! First of all, thanks for all your patience in
> answering all my questions.
> 
> In gratitude, I... have more questions. :) But hopefully,
> nothing that will take much of your time.

No problem, that's what I get for not writing enough documentation ;)

> 1) The purpose of LIBDBUSMENU is synchronizing two menus,
> possibly coming from different toolkits.

Yes.  Or even, in theory, no toolkit at all.  I believe that one of the
developers of Goggles Music Manager[1] was looking at using it without
GTK or QT for use in libappindicator.

> 2) LIBAPPINDICATOR uses LIBDBUSMENU for synchronizing a
> menu from an application and a menu included in either
> indicator-applications or the KDE systray.

Yes.

> 3) LIBAPPINDICATOR and indicator-applications are Gtk
> ports of things that *already exist* in Qt. If I write
> a Qt application with the regular systray Qt libraries,
> it will magically appear in indicator-applications.
> If I write a Gtk application with libappindicator, it
> will magically appear in the KDE systray.

Yes.  And both will fallback to using the Notification Area if neither
of those two exist.

> 4) LIBINDICATE implements a n:1 relation between
> applications and an indicator. It works by using
> LIBDBUSMENU to synchronize an indicator and a
> "daemon" menu that is not particularly associated to
> any application.

No.  Libindicate is n:n really.  It is just about counting messages and
only provides a slight nod to dbusmenu in that applications that are
using libindicate can also (not required) provide menu items for extra
actions.  They're different in that the different messaging sources for
instance can't be in a hierarchy and are more closely associated to
times and counts (messaging focused).

> 5) In other words, the main difference between
> LIBAPPINDICATOR and LIBINDICATE is that with the
> former each application *gives* its own menu, while
> with the latter each application *modifies* a menu
> that exists outside of it.

I think the better way to distinguish would be that libindicate is used
to put entries inside the messaging menu, while libappindicator is for
the application having its own menu outside of the messaging menu.

> 6) The Gtk/Qt bindings for LIBINDICATE are for more
> complex operations of such menu modification, for
> example adding submenus. Those are not expected to
> be common use cases, but nevertheless the libraries
> make them possible.

I think that you mean DBUSMENU instead of LIBINDICATE here, and if so,
you're correct :)  For the most part the toolkit specific wrappers for
libindicate are more about doing higher level actions like dealing with
icons.  Or in the QT case, making it work with C++ nicely.

> > > 4) Why does the specification of which INDICATORS go
> > > inside each INDICATOR-APPLET, and their order, are
> > > hardcoded in the INDICATOR-APPLET code? Currently, the
> > > only "configuration" available to the end user is
> > > uninstalling the indicators they don't want and the
> > > only way for developers to experiment with, for example,
> > > the order of INDICATORS is constant recompilation.
> > 
> > Didn't see a reason to make it more complex.
> 
> IMHO, the current hardcoded way creates two problems:
> 
> - For users: if someone does not like the Messaging Menu
> and wants to get rid of it, for example, the only way to
> do it is to uninstall indicator-messages. This is a little
> bit non-intuitive, specially considering that Gnome users
> are used to right-click on the panel and control what
> should be there and what should not. Maybe a blacklist
> system, like the Messaging Menu uses, could fit.

Sure, I'm not defending the hardcoding or saying it's perfect.  It just
hasn't been a requirement yet :)  Obviously with
indicator-applet-complete it is a bigger issue, but that isn't really
anywhere by default, I don't think most people know about it yet.

> - For developers: each different setup of indicators
> (ex: indicator-applet-complete) requires coding,
> compiling and packaging. This sounds suboptimal,
> specially considering that the different indicator-applets
> share a lot of boilerplate code.

I've been trying to put a bunch of this common code into libindicator
precisely for this reason.  In general, I don't consider libindicator
API stable as it's more for making the indicator development easy and
fast so it changes as we need it to.  I know everyone who's using it
today and I tell them :)

> > Cool.  Can you give us a sneak peak? :)
> 
> Unfortunately no, for the unsolvable reason that there's
> nothing to peek at yet. =P But we'll be sure to announce
> it when we finish the specification.

Great, well drop me or the list an e-mail when you get something
together I'd hate to do something like remove a feature that I thought
nobody was using and you were depending on because I didn't know :)

		--Ted

[1] http://code.google.com/p/gogglesmm/

Attachment: signature.asc
Description: This is a digitally signed message part