Two Bugs abd a Mis-Feature

[Charles Lindsey]

Compiz 0.9.11.2 cum 14.04 (Trusty), though I think this applies as well to 0.9.12.2

First the Mis-Feature.
-----------------------------

Suppose Window A has the focus, and you wish to move the focus to Window B. If you have configured focus-on-click, you click over B; otherwise you have focus-on-enter, so you just hover over B (I actually prefer focus-on-enter because you find yourself typing in the wrong window less often that way).

BUT the same effect happens whatever modifier keys you happen to have pressed at the same time, whereas nobody in his right mind would deliberately change focus with such a modifier down. This precludes interesting enhancements where you would wish to do something different on Window B whilst retaining the focus in Window A. The case I have in mind is where you want to set a secondary selection in Window B. Yes, secondary selections have gone out of fashion these days, but they were there for a purpose (namely to grab stuff from other windows to import it into the focus window), and I am currently working on an enhancement to GTK to that effect, which is how I encountered the problem. It would make life much simpler if focus changes only happened when you hovered, or clicked, over Window B with no modifier keys down (naturally, I exclude Caps-Lock and Num-Lock from this restriction).

Now for the Bugs
------------------------

BUG#1 Suppose you are working in Window A, and you want to move Window B out of the way, so you can see both together. So you press Alt and then click over B to drag it out of the way. And Behold! B now has the focus, which you did not want because you were trying to do useful work in A. This is a nuisance and an inconvenience, but I admit it does little harm. The next Bug is more troublesome.

BUG#2 Suppose you are in focus-on-enter mode, that you are using Unity (I quite like Unity), and Window A is low down on the screen, with window B higher up. As is usual with Unity, the various menus (File, View,..., Help) for the application running in A are not visible until you move the cursor into the top margin of the Screen. BUT to do that, you have to move the cursor over Window B, which thereby acquires the focus, so that what you see is the menu items for B's application. That is a serious Bug. Easily fixed, however, because there is already a delay when moving over a window before it is moved to the Front, so you just need to arrange for that same delay to elapse (0.5 secs is enough) before the focus change takes effect.

I have attached a patch (for 0.9.11.2, though I believe the code for 0.9.12.2 would accept the same patch, or something very similar). This causes focus changes to happen only when no modifier keys are down, and also delays the focus change as described. Unless someone comes up with a good reason why changing focus with some modifier key down is actually useful in current situations, then I request this patch be adopted. And yes, I recognize that most other window managers need a similar fix, but we have to start somewhere.