app-indicator trayicon menu slow to respond

[Eric Ding]

I'm running Zim 0.54 on Ubuntu 12.04 with the Unity shell.

DEBUG: Python version is sys.version_info(major=2, minor=7, micro=3, releaselevel='final', serial=0)
DEBUG: Gtk version is (2, 24, 10)
DEBUG: Pygtk version is (2, 24, 0)

If I use the trayicon plugin with default settings (so that it uses AppIndicatorTrayIcon), then clicking on a menu item from the tray icon often is unresponsive. After an unpredictable amount of time, the specific notebook will finally come up, or action (i.e., Quit) will be performed. Until that moment, there is no debug output in the terminal from which I've started Zim.

If I use the trayicon with "classic icon" settings (so that it uses DaemonTrayIcon), then clicking on menu items from the tray icon behaves as expected.

[Jaap Karssenberg (jaap.karssenberg)]

On Mon, May 7, 2012 at 2:06 PM, Eric Ding <email address hidden> wrote:
> Public bug reported:
>
> I'm running Zim 0.54 on Ubuntu 12.04 with the Unity shell.
>
> DEBUG: Python version is sys.version_info(major=2, minor=7, micro=3, releaselevel='final', serial=0)
> DEBUG: Gtk version is (2, 24, 10)
> DEBUG: Pygtk version is (2, 24, 0)
>
> If I use the trayicon plugin with default settings (so that it uses
> AppIndicatorTrayIcon), then clicking on a menu item from the tray icon
> often is unresponsive. After an unpredictable amount of time, the
> specific notebook will finally come up, or action (i.e., Quit) will be
> performed. Until that moment, there is no debug output in the terminal
> from which I've started Zim.
>
> If I use the trayicon with "classic icon" settings (so that it uses
> DaemonTrayIcon), then clicking on menu items from the tray icon behaves
> as expected.

Are you sure this is a bug in zim ? Could also be an issue with the
appindicator framework. As far as I can see it works fine on my
system. Coding wise there is not much difference between the two
trayicons, zim executes the same as soon as it get's the signal.

REgards,

Jaap

[Eric Ding (ericding-alum)]

On 05/07/2012 10:03 PM, Jaap Karssenberg wrote:

>> If I use the trayicon plugin with default settings (so that it uses
>> AppIndicatorTrayIcon), then clicking on a menu item from the tray icon
>> often is unresponsive. After an unpredictable amount of time, the
>> specific notebook will finally come up, or action (i.e., Quit) will be
>> performed. Until that moment, there is no debug output in the terminal
>> from which I've started Zim.
>>
>> If I use the trayicon with "classic icon" settings (so that it uses
>> DaemonTrayIcon), then clicking on menu items from the tray icon behaves
>> as expected.
>
> Are you sure this is a bug in zim ? Could also be an issue with the
> appindicator framework. As far as I can see it works fine on my
> system. Coding wise there is not much difference between the two
> trayicons, zim executes the same as soon as it get's the signal.

No, I can't be sure this is a bug in zim. :-) I can tell you, though,
that no other appindicator menus are as slow to respond as the zim menu.
 While it could be a bug in the appindicator framework, I do wonder
whether there's some difference between how zim implements its trayicon
menu and how other trayicons are working. Thoughts?

I found at least one other anecdote online of someone else who ran into
the same problem and worked around it by using the 'classic icon'
instead. I'm doing the same for now, but it'd be nice for the sake of
UI consistency to be able to use the appindicator icon instead...

Thanks, regardless, for your quick response!

Eric

[Eric Ding (ericding-alum)]

By the way, there are times when the menu simply doesn't seem to respond at all. For example, I might press "Quit", and nothing happens. However, when I then run a zim command from the CLI, e.g., "zim --plugin quicknote" then the action is finally processed. As another example: if I click on "Quick Note", then on one of my notebooks listed in the menu, then typically, nothing happens -- until I run "zim --plugin trayicon" (for example), at which point both a Quick Note window and my notebook pop up suddenly onscreen.

Could there be some odd behavior going on between zim's daemon architecture and the appindicator implementation? Is there some way that the daemon is falling asleep when it should be listening to signals from somewhere? I'm just shooting in the dark, so if there's anything more specific I can do to help chase down this bug, please let me know.

[tschoie (tschoie)]

I'm experiencing a similar slowness/unreliable response pattern with the zim appindicator running Zim 0.54 on Ubuntu 12.04 and can therefore confirm this issue. I'd be happy to help out if any additional information is needed to track down this bug.

[pvanb (p-vanbreugel)]

I am experiencing the same problems (slow, unresponsive) as mentioned above since Ubuntu 12.04 and Zim 0.56. I sometimes even have to go in system monitor - processes to kill the Zim process before I can start using it again.

Also like the earlier reports, I am only experiencing this problem with ZIM.

[Renaud Levesque (releve1403)]

Since 12.04, I got the same kind of problem (slow response and, sometimes, no response at all).
Python : 2.7.3
Zim : 0.56

Tried changing from Unity to Unity2D, but the problem is still there.

Sometimes, as you will see in attachment, Zim processes are running, but there is no trayicon. At other times, the Zim icon is present, but when I click on it , no notebooks are present in dropdown. Usually, my dropdown menu of Zim icon looks like in this attachment "zim-dropdown menu.png".

Also, when the icon and the dropdown menu are all right, there is no response when I click on a notebook until I do a right click on the Zim trayicon. Strange.

[Jaap Karssenberg (jaap.karssenberg)]

I can confirm on my own system under 12.04. Did some testing, and afraid the problem is on the side of the app indicator framework. Zim simply does not get any signal when you click something in the menu. Can't change much on the zim side. The class wrapping the appindicator is literally about 10 lines of code, all functionality is common with the status tray icon.

Since functionality for tray icon works on both unix and windows, and app indicator wrapper used to work on ubuntu < 12.04, I get the feeling the problem is in ubuntu itself.

[Jaap Karssenberg (jaap.karssenberg)]

Verified (again) implementation versus example code on ubuntu.com and should work exactly as documented.

However where zim is behaving flacky, the example code as a test script, works perfectly. So now I'm completely confused where the issue comes from.

....

[Jaap Karssenberg (jaap.karssenberg)]

@eric: deamon is up and running, otherwise commandline arguments like "zim --plugin quicknote" would also hang. However the trayicon itself is also running in a separate background process.

[Renaud Levesque (releve1403)]

I think this bug has little to do with Zim, in fact. I have experienced the same kind of problem (lack of content in drop-down menu with the bookmarks in nautilus).

In fact, since about a week, I just tried to make the switch to another desktop (XFCE) and Zim 0.56 is working fine. So, this misbehavior seems related to Unity.

[Jaap Karssenberg (jaap.karssenberg)]

Added Ubuntu and Unity, as fixing this issue likely requires help from platform developers.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mike Mintz (mikemintz)]

This affects me, but I don't use Unity. I use zim 0.56 and i3-wm 4.2 with gnome-panel.

[Jaap Karssenberg (jaap.karssenberg)]

On Sat, Jun 2, 2012 at 3:32 AM, Mike Mintz <email address hidden> wrote:
> This affects me, but I don't use Unity. I use zim 0.56 and i3-wm 4.2
> with gnome-panel.

I think that should be a different bug report, since this bug report
is specific for the app-indicator icon, which is specific for Unity.
Or does gnome-panel also include app-indicator menus now ?

Regards,

Jaap

[Omer Akram (om26er)]

are there any steps I could take to reproduce this issue? I just installed and ran zim but don't know how to recreate the issue.

[Jaap Karssenberg (jaap.karssenberg)]

On Sun, Jun 10, 2012 at 3:42 PM, Omer Akram <email address hidden> wrote:
> are there any steps  I could take to reproduce this issue? I just
> installed and ran zim but don't know how to recreate the issue.

In zim enable the "Tray icon" plugin ("Edit" -> "Preferences", Tab
with "Plugins"). This will use the app-indicator framework if python
bindings are found.

Now take e.g. the "quit" option in the menu, which should close all
zim instances, in Ubuntu 11.10 this worked instantaneous, but in 12.04
there is a certain lag.

It does not always reproduce the same way, but most common thing is
that nothing happens, until you "touch" zim by doing some other
operation (like clicking the icon in the dash) and then all the sudden
the "pending" action happens and zim closes.

Similar behavior is observed for all menu entries.

From zim debug log (kill all zim processes, and start zim with "zim
-D") I can see when zim gets a signal back from the menu, so I know
the lag is not in zim itself.

Please not that zim runs multiple processes. There is a "daemon"
process that manages multiple instances by anonymous pipes (server
like design). An open notebook runs in one process, the plugin with
the app-indicator menu in another. Not sure if this architecture
contributes to the issue. But given that it works fine in Ubuntu 11.10
I suspect that some change in Unity triggers the behavior.

Regards,

Jaap

[Omer Akram (om26er)]

here is what I see.. after enabling the indicator icon, if i quit zim from its File menu the indicator still persists and won't go away unless I quit it from the indicator itself. is that the bug?

[Jaap Karssenberg (jaap.karssenberg)]

On Thu, Jun 14, 2012 at 2:24 PM, Omer Akram <email address hidden> wrote:
> here is what I see.. after enabling the indicator icon, if i quit zim
> from its File menu the indicator still persists and won't go away unless
> I quit it from the indicator itself. is that the bug?

No this is intended behavior. The indicator should be persistent.

The bug is going the other way around. When you activate "quit" in the
indicator menu, all zim instances should quit. However here there is a
seemingly random lag or complete failure of the signal from the menu
to reach the zim process.

Regards,

Jaap

[Omer Akram (om26er)]

that seems not to be an issue for me. I will try it on a different machine when i get my hands on it.

[Jaap Karssenberg (jaap.karssenberg)]

Still unclear what the cause is, but rework of the ipc code in rev 590 seems to have fixed it.

[RomanIvanov (ivanov-jr)]

Jaap, did you uploaded new version to ppa ? such slow behavior is a pain, but I do not want to return back other notes applications. Zim rocks !

[Jaap Karssenberg (jaap.karssenberg)]

On Tue, Oct 9, 2012 at 7:30 PM, RomanIvanov <email address hidden> wrote:
> Jaap, did you uploaded new version to ppa ? such slow behavior is a
> pain, but I do not want to return back other notes applications. Zim
> rocks !

If you use the daily snapshot PPA you should already have it.
Otherwise if you use the zim-releases PPA check again in a few hours,
should be done building by then.

Regards,

Jaap

[Jaap Karssenberg (jaap.karssenberg)]

Fixed in zim 0.57