unity-design team mailing list archive

[Marcelo Hashimoto <marcelo.hashimoto@xxxxxxxxx>]

I accidentally sent the reply below only to Ted.

I also forgot to mention one thing: once everything
is clear to me, I'd love trying to set up an
"indicators for dummies" wiki to help people who
are lost like me.


Le jeudi 11 mars 2010 à 08:53 +0100, Marcelo Hashimoto a écrit :
> 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.
> 
> But let me see if I understood everything correctly:
> 
> 1) The purpose of LIBDBUSMENU is synchronizing two menus,
> possibly coming from different toolkits.
> 
> 2) LIBAPPINDICATOR uses LIBDBUSMENU for synchronizing a
> menu from an application and a menu included in either
> indicator-applications or the KDE systray.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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 don't expect this to be completely correct, but
> hopefully I didn't miss anything big this time.
> 
> Don't let out that sign of relief yet, this mail
> is not over. ;) I just want to comment on two
> things you said.
> 
> > > 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.
> 
> - 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.
> 
> > 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.
> 
> Best regards and thank you very much again,
> Marcelo