Welcome to awesome bug tracking system.

FS#384 - gkrellm showing up on taskbar if more than 1 gkrellm running

Attached to Project: awesome
Opened by Shaun Attfield (heurist) - Sunday, 23 November 2008, 00:28 GMT
Last edited by Julien Danjou (jd) - Thursday, 27 November 2008, 10:21 GMT
Task Type Bug Report
Category Statusbars
Status Closed
Assigned To No-one
Operating System Linux
Severity Low
Priority Normal
Reported Version git/master
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


With the gkrellm setting "Do not include on a taskbar" set, gkrellm does not appear on the statusbar, as expected.
However, if a second gkrellm is started (for remote monitoring) then 1 gkrellm instance will show up on the statusbar.
If more than 2 instances are running only 1 will show up, the one shown is apparently random and will change from time to time.

I have tested this with awesome-3.1_rc2 and awesome-3.1_rc3 gentoo stable and unstable and get the same results.
This task depends upon

Closed by  Julien Danjou (jd)
Thursday, 27 November 2008, 10:21 GMT
Reason for closing:  Fixed
Additional comments about closing:  commit 3cc7843f0588ba8a7a0f7927bb9daf65b8802aff
Author: Michael Hofmann <>
Date: Thu Nov 27 11:20:25 2008 +0100

awful.widget: fix iteration over removed elements

Signed-off-by: Julien Danjou <>

Comment by Julien Danjou (jd) - Monday, 24 November 2008, 09:40 GMT
Not reproducible and more likely a gkrellm bug.
Check with xprop your settings.
Comment by Shaun Attfield (heurist) - Wednesday, 26 November 2008, 02:10 GMT
Steps to reproduce:
start grellm, configure "set windows type to be dock or panel" to true, restart that gkrellm.
->there should be no gkrellm on the statusbar.
start a second gkrellm instance (e.g. grellm -c testconfig), configure "set windows type to be dock or panel" to true, restart that gkrellm.
->1 of the 2 instances is showing in the statusbar.
Shut down either 1, none will show, start it again 1 will show.

I have checked with xprop and attached the outputs. (e.g. xprop -display 0:0 -name gkrellm > server_local.txt)

I did this on 2 separate machines, the first running gentoo ~x86 (unstable) and gkrellm 2.3.2, these test were done with new gkrellm configs created using the "gkrellm -c test1" command and are named test1 - test3 for the 3 instances.
test#-dock.txt was with the "set windows type to be dock or panel" setting. (must restart gkrellm)
test#-skip.txt was with the "Do not included on the taskbar" and "Do not include in the pager" settings.
test1-skip-solo.txt was with only test1 running (skip setting) before loading the second and third instance.
xprops for test1-skip-solo and test1-skip are identical; though test1-skip had test1 showing in the statusbar.

The second machine is running gentoo x86 (stable) - with awesome 3.1_rc3 (and libs) pulled in via keyword hacks and gkrellm 2.3.1.
server_local.txt is the local gkrellm instance for monitoring the server.
server_gate.txt is the remote instance monitoring gkrellmd on the gateway.
server_cludge.txt is the remote instance monitoring gkrellmd on the system the "test#" tests were done on.

None of them show any significant differences in their xprops; both systems have 1 of the 3 instances appear in the statusbar (is this the same as a taskbar?) and that instance will also take focus with mod4+k while the hidden instance do not take focus.
I can not see any pattern in which of the 3 instance show up, this will change from time to time, but possibly only when instances are started and stopped.
With 4 instances running I had 2 on the taskbar, with 6 I had 3 and with 9 I had 4.

Let me know if you want to do any other tests or provide any other data.
Comment by Julien Danjou (jd) - Wednesday, 26 November 2008, 08:51 GMT
FWIW, I'm running gkrellm 2.3.2 from Debian.

I tried your steps to reproduce this, but I still cannot reproduce, which seems quite ok since it has really no logical sense to me.

Your first xprop shows that you set window type to dock, and so it's not shown in the statusbar.

There may be a bug, but again, I think it's rather a very hard to track or one on gkrellm side. In either way, we would need to have a « work-each-time » procedure to reproduce. Since you see the behaviour behing erratic it's impossible for now to me to get what's going on.

If you know a bit of Lua and feels like hacking, you can try to dig around the awful.widget lib to see for what reason precisely your client is not ignored.
Comment by Michael Hofmann (mh21) - Wednesday, 26 November 2008, 08:58 GMT
I'm sitting on a patch for a while now that seems to fix a bug in the do-not-show-in-taskbar window handling. Can you test whether it solves your problem?

Seems like you can't iterate over a table and at the same time remove some entries in it.
Comment by Shaun Attfield (heurist) - Wednesday, 26 November 2008, 09:12 GMT
Excellent work Michael, that patch fixed the taskbar display issue, all 3 instances are now hidden.
1 of the instances still takes focus with mod4+k, but that may be a similar issue in the skip focus code, I might look for that later if someone does not beat me too it (hint hint).
Comment by Shaun Attfield (heurist) - Wednesday, 26 November 2008, 09:39 GMT
I do not know about in LUA, but iterating over a list (table in this case) and removing items results in skipped items, which would account for this issue.
For instance: if you start at item[1] and test it and find it needs to be removed; when you remove it item[2] becomes item[1] but you continue your loop from item[2] thus skipping the test of the new item[1] (previously item[2]).
The solution is generally to iterate it in reverse, that way you start at item[100] (for example) and if you remove it and move on to item[99] it is still the same item[99] as you started with, only higher numbered item[s] will be moved down when the numbers below them are removed.
This is a problem with all formal queues.
I hope that makes senses as I am very tired ATM.

I am looking around client.lua line 110 for focus handing, but am thinking of leaving this till I have had some rest, this does not look like the correct place.