xpra icon
Bug tracker and wiki

Changes between Version 2 and Version 3 of Ticket #438, comment 8


Ignore:
Timestamp:
12/12/13 02:01:52 (6 years ago)
Author:
Antoine Martin
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #438, comment 8

    v2 v3  
    44
    55FYI: the {{{gtk.gdk.X_CURSOR}}} ("`X`") is used as a fallback when we fail to locate a cursor by name and fail to instantiate one with the pixels sent by the server. Both of which should never happen, but did in the past, and we now take extra precautions. Before r4906, we would also (wrongly) use it when we should have used the default cursor. ([http://www.pygtk.org/docs/pygtk/class-gdkwindow.html#method-gdkwindow--set-cursor gtk.gdk.Window.set_cursor]: `Passing None means that the window will use the cursor of its parent window`)
    6 
    7 ----
    8 
    9 > It looks like window focus, as far as the cursor is concerned, is being confused when one xpra session window overlaps another xpra session window [...] then the mouse focus returns to the chrome window [...]
    10 [[BR]]
    11 
    12 * Is this a regression? (does this belong in this ticket)
    13 * Does this work any differently on other platforms?
    14 * Where is the log from that exact moment this happens?
    15 
    16 It may be a case of focus-follows-mouse, which may or may not be a bug, but certainly looks like it doesn't belong in this ticket. (unless it is a regression caused by changes in this ticket - which is doubtful)
    17 OTOH: the top-level window should always have keyboard focus and receive key events (even when the mouse is somewhere else - local platform event delivery allowing), but mouse-wheel and key modifier changes can be delivered to non-top-level windows without raising them to the top.