ewancoder / wmii

Automatically exported from code.google.com/p/wmii
MIT License
0 stars 0 forks source link

witray can be moved from the floating layer and closed with mod+shift+c when it is the last item on a tag #189

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. open witray and some tray apps in the background
2. open some xterms
3. close them all with mod+shift+c, hit mod+shift+c one more time, witray
closes

What is the expected result? What do you see instead?
I would not expect to have focus dropped to witray when everything else is
closed, mainly because this allows you to close it by accident, and
sometimes (I cant reproduce this 100% of the time), when you try to open a
new xterm when witray is focused, it opens floating instead of the default. 

What version of the product are you using (wmii -v)? On what operating
system (uname -a)?
wmii-hg2683
Linux 2.6.32-trunk-686 #1 SMP Sun Jan 10 06:32:16 UTC 2010 i686 GNU/Linux

Please provide any additional information below.

Original issue reported on code.google.com by adkilgore on 4 Jun 2010 at 7:14

GoogleCodeExporter commented 8 years ago
Also, once moved to the floating layer, you can't move it back to the bar.

Original comment by google@nemesis13.de on 4 Jun 2010 at 7:21

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
The odd part about this one is that I can't seem to make it behave the same way 
every
time, I have been trying to figure out in what cases it does this, but have not 
come
up with anything consistent

Original comment by adkilgore on 4 Jun 2010 at 9:14

GoogleCodeExporter commented 8 years ago
Trying the latest tip, I can't seem to reproduce this anymore, can anyone else?

Original comment by adkilgore on 5 Jun 2010 at 6:39

GoogleCodeExporter commented 8 years ago
Ah, never mind, still can, but only when the last window closed was floating, 
so far

Original comment by adkilgore on 5 Jun 2010 at 6:40

GoogleCodeExporter commented 8 years ago
I don't consider this a bug. wmii tends not to prevent its users from doing 
things if
they really want to. They may well have a good reason I haven't thought of. The 
only
real problem I have with the current behavior is that there's really no way to 
select
a dock/splash window is if it's the last window in the floating layer, but so 
far I
prefer that to the alternatives.

Original comment by maglion...@gmail.com on 5 Jun 2010 at 8:20

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
I think my initial problem with this one was that with the previous behavior, 
when
you closed all of your managed windows, focus would drop automatically to the
floating layer (it would select the dock), this would cause the next opened 
window to
be floating. That shifting to the floating layer does not appear to happen 
anymore,
so it does not seem to be as big of a deal at this point.

The original issue was that I accidentally ended up doing something that I did 
not
want to do. This could still happen when wmii drops focus to the tray 
automatically
when you close all other windows and have the floating layer selected.

 In my opinion, the way to handle this would be to allow people to select the tray
using the keyboard, but maybe not focus the tray automatically, and maybe show 
some
indication that the tray is selected when it actually is.

Just a few thoughts, and thanks for your time.

(edits for clarity)

Original comment by adkilgore on 5 Jun 2010 at 9:11

GoogleCodeExporter commented 8 years ago

Original comment by sunaku on 22 Feb 2011 at 9:23

GoogleCodeExporter commented 8 years ago
Alternatively, we could just ignore witray in the wmiirc's mod+shift+c handler.

Original comment by sunaku on 20 Sep 2011 at 6:15

GoogleCodeExporter commented 8 years ago
I did this (excluding witray from mod+shift+c) in my wmiirc:

https://github.com/sunaku/wmiirc/commit/da483bc0c4623c49d172bc611ed965c94f12ec4f

Original comment by sunaku on 20 Sep 2011 at 6:26

GoogleCodeExporter commented 8 years ago
Marking as Accepted because I was able to reproduce the issue.

Original comment by sunaku on 23 Sep 2011 at 6:35