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 _______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : [email protected] Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
