"git gui": click only after moving window

[pmarek]

When I start "git gui", I get the initial window asking which GIT checkout I want to use.

I cannot click on the path already shown there; if I move the window, I can click.

Reproduceable by ahuillet.

[Antoine Martin]

Probably window focus related, moving the window ensures it is focused, unfocusing it (from the local window manager's point of view) before clicking in that area probably does the same thing.

Focus is a pain, you have X11 focus, xpra focus, client-side focus... getting them all to agree in an asynchronous world is difficult at best.

Please try various client-side window managers, and at least tell me the one you have which did not work. I'm pretty sure some do work ok (there were similar problems before - see #51 r357 r356 r231).

git gui is written in Tcl/Tk, it may be worth trying other Tcl/Tk applications to see if they exhibit the same problem. Focus is generally handled by the toolkit, not by the app directly.

[pmarek]

This is with debian testing/unstable, KDE 4.7.4.

[ahuillet]

Fluxbox exhibits the problem but not where the OP described it - clicking the path works, but the window that appears *then* is unresponsive until I move it.

[Antoine Martin]

starting "git gui" in a path which does not have a repository

[Antoine Martin]

starting "git gui" in a path which has an existing repository

[Antoine Martin]

As per the screenshots above, I cannot see the "path already shown there" that you refer to.

Please provide more detailed steps on how to reproduce this issue.

[ahuillet]

The window in your "existingpath" screenshot is the one that is unresponsive in my case.
The window in your "newpath" screenshot - is the one that is unresponsive for the OP, *but* in the case where there is a path displayed there.

[Antoine Martin]

OK, and any idea how would I get a path to display there?

FWIW: both work just fine for me. LXDE on Fedora 16.

[ahuillet]

Open git-gui in a directory where there is no repository. You will get your "newpath" image. Click open, select a path. You'll get the "existing path" image.
Quit git-gui. Start it again in the same directory where there is no repository. This time you should see the path appear (as a "last used" path).

[Antoine Martin]

starting "git gui" in a path which does not have a repository (with fluxbox desktop)

[Antoine Martin]

once started, I can select an existing project immediately (fluxbox desktop)

[Antoine Martin]

starting "git gui" in a path which has an existing repository (fluxbox desktop)

[Antoine Martin]

"git gui" project window is responsive as soon as it is started (fluxbox desktop)

[Antoine Martin]

Finally managed to reproduce the KDE one (was doing it wrong in the KDE screenshots - edit: now removed them). Looks like a KDE bug to me, maybe related to that recent click vs drag thing with KDE windows.
I have kde 4.8.3, will try to find out more about what is going on here, but I am not certain this can be solved in xpra.

I simply cannot reproduce the fluxbox one however, no matter how hard I try.
It goes to the project shown as soon as the mouse is clicked (button-down, it does not even wait for the corresponding button-up)
Fluxbox 1.3.2

I tested this by starting a new fluxbox/KDE "desktop session" with VNC via winswitch (you can also do it by hand if you feel so inclined). Since the focus never leaves the VNC window, I doubt a "real" DISPLAY=:0 session will make much difference, but I will try anyway.

[Antoine Martin]

Simply by adding this:

Index: src/xpra/client.py
===================================================================
--- src/xpra/client.py	(revision 884)
+++ src/xpra/client.py	(working copy)
@@ -416,6 +416,7 @@
                                           pointer, modifiers])
 
     def _button_action(self, button, event, depressed):
+        log.info("button_action(%s,%s,%s)" % (button, event, depressed))
         if self._client.readonly:
             return
         (pointer, modifiers) = self._pointer_modifiers(event)

I can see that the clicks are being passed from the KDE client to the xpra server. Why the window/toolkit decide to ignore them... is another matter.

[Antoine Martin]

Also reproducible with the win32 client.

[Antoine Martin]

OK, here is a log of everything related to focus calls:

• on the server:

  _process_focus(['focus', 5, []])
  _focus(5,[]) has_focus=0
  _focus(5,[]).give_focus()
  Giving focus to client
  ... using XSetInputFocus
  

• on the client:

  _focus_change(()) _been_mapped=True
  _focus_change((<ClientWindow object at 0x23a3370 (xpra+client+ClientWindow at 0x22e5350)>,
                 <GParamBoolean 'has-toplevel-focus'>)) _been_mapped=True
  send_focus(5)
  

The client window's _focus_change fires and we tell the server which then uses XSetInputFocus to give it focus (to mimic what the client has already done).

In the case where it does not work, the calls are identical.. race?

First note: we fire first from do_map_event via idle_add then via the notify::has-toplevel-focus signal (sometimes the other way around too?).
Removing the first call does not change anything unfortunately, and I seem to remember that this was necessary for some window managers which fail to fire the "has-toplevel-focus" signal despite actually giving focus.. (unity irrc - might be worth checking if this is fixed to remove the double call)

Not sure this is relevant, but this sequence of events does happen when we click on the "git gui" window widget to do both focus and click in one go:

_process_focus(['focus', 6, []])
_focus(6,[]) has_focus=0
_process_button_action(['button-action', 6, 1, 1, [197, 166], []])
_focus(6,[]).give_focus()
Giving focus to client
... using XSetInputFocus
_process_button_action(['button-action', 6, 1, 0, [197, 166], []])

The focus happens between the mouse-down and mouse-up.

We had to add gobject.idle_add to fix focus problems on win32... And now we get another one?! See r231 and the docstring it adds:

#no idea why we can't call this straight away!
#but with win32 clients, it would often fail!???

[Antoine Martin]

I don't understand why this makes any difference, something asynchronous in X11 is making the "move-window" re-do what we already do in configure_window and that makes everything happy... but why? (this will be the next step)

In the meantime, here's a workaround, please let me know if that fixes the issue in *ALL* cases for you:

Index: src/xpra/client.py
===================================================================
--- src/xpra/client.py	(revision 884)
+++ src/xpra/client.py	(working copy)
@@ -359,7 +359,9 @@
                 ox, oy = self._pos
                 dx, dy = x-ox, y-oy
                 self._pos = (x, y)
-                self._client.send(["move-window", self._id, x, y])
+            self._client.send(["move-window", self._id, x, y])
+            if (x, y) != self._pos:
+                log.info("window moved to %sx%s", x, y)
                 for window in self._override_redirect_windows:
                     x, y = window.get_position()
                     window.move(x+dx, y+dy)

[Antoine Martin]

fixed in r905, feel free to re-open if you find an app or toolkit that still misbehaves...

Tested with KDE and win32. Will apply to 0.3.x branch after further testing.

[Antoine Martin]

applied to 0.3.x branch in r951

[Antoine Martin]

I suspect that the more correct fix for this might well be r2003 (backported as r2004) - someone with spare time could confirm.

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/138