[awesome bugs] #384 - gkrellm showing up on taskbar if more than 1 gkrellm running
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#384 - gkrellm showing up on taskbar if more than 1 gkrellm running User who did this - Julien Danjou (jd) Reason for closing: Fixed Additional comments about closing: commit 3cc7843f0588ba8a7a0f7927bb9daf65b8802aff Author: Michael Hofmann [EMAIL PROTECTED] Date: Thu Nov 27 11:20:25 2008 +0100 awful.widget: fix iteration over removed elements Signed-off-by: Julien Danjou [EMAIL PROTECTED] More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=384 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to [EMAIL PROTECTED]
[awesome bugs] #384 - gkrellm showing up on taskbar if more than 1 gkrellm running
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#384 - gkrellm showing up on taskbar if more than 1 gkrellm running User who did this - Julien Danjou (jd) -- 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. -- More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=384#comment919 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to [EMAIL PROTECTED]
[awesome bugs] #384 - gkrellm showing up on taskbar if more than 1 gkrellm running (Attachment added)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#384 - gkrellm showing up on taskbar if more than 1 gkrellm running User who did this - Michael Hofmann (mh21) -- 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. -- One or more files have been attached. More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=384#comment921 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to [EMAIL PROTECTED]
[awesome bugs] #384 - gkrellm showing up on taskbar if more than 1 gkrellm running
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#384 - gkrellm showing up on taskbar if more than 1 gkrellm running User who did this - Shaun Attfield (heurist) -- 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. -- More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=384#comment924 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to [EMAIL PROTECTED]
[awesome bugs] #384 - gkrellm showing up on taskbar if more than 1 gkrellm running (Attachment added)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#384 - gkrellm showing up on taskbar if more than 1 gkrellm running User who did this - Shaun Attfield (heurist) -- 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. -- One or more files have been attached. More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=384#comment918 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to [EMAIL PROTECTED]
