Comments on: Application Indicators In Python

By: Quentin Neill

Quentin Neill — Wed, 02 Nov 2011 02:17:00 +0000

Your code has some syntax problems. The lines “menu_items =” through “menu_items.show()” should be indented.

Click through to the original article to see the code

https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Python_version

By: jm

jm — Tue, 13 Sep 2011 03:04:00 +0000

great work! o/ congratulations!

By: YADev

YADev — Wed, 01 Sep 2010 07:16:50 +0000

It seems like a bad idea to replace panel applets with the buggy and poorly documented libindicator at this point.

It appears that when the developed application is run, the menu that is set is not directly used. It is packaged up and sent over dbus to the indicator-applet. This process is the source of countless weird bugs where menus don't behave like normal due to problems in the translation. It seems like most of the function calls in the base classes have not been implemented in the translator.

I wouldn't mind all the bugs if things were at least documented so that time wasn't wasted trying to figure out why some function doesn't work.

Make application indicators stable before you start talking about making it the only option.

By: MeanEYE

MeanEYE — Fri, 25 Jun 2010 21:52:11 +0000

That example is a bit buggy. But it doesn't really matter.

One thing with python-appindicator I find troubling. Once you call ind.set_menu you can no longer add items to that menu. You can do all sorts of stuff to menu items (hide, show, change label), but you can't add :/ new items. My guess is that when set_menu is called AppIndicator iterates through menu and picks all the items.

This awkward behavior makes AppIndicator in my case unusable. I need the ability to update items on the run.

By: Julia

Julia — Sat, 20 Feb 2010 12:29:29 +0000

is this all about adding menus and attaching it to a custom function?

Many paths lead to Rome (qt, kde scripting, ..)

What so special about this one? or I did not understand the source code. then sorry

By: Dylan McCall

Dylan McCall — Fri, 18 Dec 2009 16:58:44 +0000

That’s a tad silly to say, since even Windows 7 uses its legacy system tray style notification area quite extensively

The roadmap, if memory serves me right, does include the old system tray being completely removed on a fairly aggressive schedule (Lucid+1, I think). The system allows different types of indicators to be categorized, so the system and hardware ones are each separated from the others, for example. It is very, very different from the existing design.

For the rest, I think there needs to be a safe landing place for applications that no longer fit on the panel with this spec. (Notification area abusers, eg: Basket Notes).

One possibility that springs to mind is to improve the launchers and the window list. Maybe the window list could just show important and minimized windows to reduce clutter, for example.

By: Nathaniel McCallum

Nathaniel McCallum — Thu, 17 Dec 2009 21:49:25 +0000

My understanding was that it was a project for Ubuntu. I was just concerned that perhaps XDG be involved, GTK/QT devs, perhaps usability lists from other distros, etc. Perhaps I misunderstand Ayatana though… Not being an Ubuntu dev anymore, I’m probably just hiding under a rock.

By: jono

jono — Thu, 17 Dec 2009 17:40:09 +0000

“ghettoize”? I hardly think that discussing the usability direction of an upstream project on it’s mailing list is ghettoizing it.

By: Nathaniel McCallum

Nathaniel McCallum — Thu, 17 Dec 2009 17:12:16 +0000

Also, I think it would be a mistake to ghettoize this discussion to the ayatana mailing list. Something this broad deserves much broader exposure. There are lots of programs that use StatusIcon that should be using this. They should all have an avenue for input into the design (though not design-by-committee of course).

By: Nathaniel McCallum

Nathaniel McCallum — Thu, 17 Dec 2009 17:01:10 +0000

What about cross-platform compatibility? As much as StatusIcon sucks, I can use it on Linux/Mac/Windows and it pretty much works.

Also, in Zapplet we embed a TreeView into the pop-up window so that we can handle (sometimes) 10s of thousands of rows. Menu will never work for us (unless you have some really cool menu improvements; perhaps you do).

And look at the latest NetworkManager-applet menu. I would argue that, even with its massive recent improvements, its still just too cumbersome.

I think it is precisely this rich format which needs some standardizing, otherwise we’ll end up with yet another wild-west scenario or worse, lots of applications cramming stuff into menus that should never be there. In conclusion, I promise this is not stop-energy. I really want to see something workable.

Say hi to Mark for me. I meant to stop by the office when I was in London a few weeks back, but never found time.