Version: 4.0 (using KDE 4.6.3) OS: Linux XPRA http://xpra.devloop.org.uk/ and further modified by http://winswitch.org/ is like VNC for only one application (simply put),its a xserver proxy using XVfb on the remote and therefore allows to transfer remotely running applications to the local display (with results similar to ssh x11 forwarding, but quite different in detail). The problem is now, that xpra only displays a remotely running application and presents (apparently a GTK window), which is only a giant image of the remote application, without any markers from which oxygen and oxygen-gtk could extract info about real empty window parts. So this results in the whole window being considered empty, with the resulting behavior: Dragging is started everywhere in the window, on buttons, on scrollbars, simply everywhere. xprop of an example application spawned using xpra over winswitch: _NET_WM_ICON_GEOMETRY(CARDINAL) = 1135, 1053, 265, 29 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE _KDE_NET_WM_FRAME_STRUT(CARDINAL) = 2, 2, 23, 4 _NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 23, 4 _NET_WM_DESKTOP(CARDINAL) = 0 WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_STATE(ATOM) = WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. window id # of group leader: 0x6400001 _KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 3052455 _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 104857657 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x6400038 WM_CLIENT_LEADER(WINDOW): window id # 0x6400001 _NET_WM_PID(CARDINAL) = 5850 WM_LOCALE_NAME(STRING) = "C" WM_CLIENT_MACHINE(STRING) = "PRIVATE" WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 0, 0 program specified minimum size: 0 by 0 window gravity: NorthWest WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_CLASS(STRING) = "xfe", "Xfe" WM_ICON_NAME(STRING) = "Xfe - /usr/home/PRIVATE (on Freebsd)" _NET_WM_ICON_NAME(UTF8_STRING) = "Xfe - /usr/home/PRIVATE (on Freebsd)" WM_NAME(STRING) = "Xfe - /usr/home/PRIVATE (on Freebsd)" _NET_WM_NAME(UTF8_STRING) = "Xfe - /usr/home/PRIVATE (on Freebsd)" It seems like xpra only exports the actual application name among with the machine name the application is running on, so no window class matching seems to be possible right now to apply workarounds for all windows matching a respective class. Reproducible: Always
Re-assigning to gtk style, if what's exposed is a gtk window. Will investigate. Thanks for reporting and sorry for the trouble.
@Armin So far I have been unable to run xpra/winswitch myself so could not reproduce. Now maybe you could provide more information (assuming the application is using gtk as a backend). Could you compile latest oxygen-gtk (from git trunk), with Debug mode enabled (basically: cmake -DOXYGEN_DEBUG=1 /path/to/sources) And post here the log of the output, when running the application and after triggering one mouse-drag ? That should help be debug/blacklist. Thanks, Hugo Sources from git are available via: git clone git://anongit.kde.org/oxygen-gtk
Since the applications have their attributes forwarded, I doubt that you will be able to blacklist them as it is. I think we may have to add a new window attribute via Xpra so that kde/oxygen can detect it and act accordingly (blacklist it or whatever). Is there an existing attribute we can re-use, or can you suggest an attribute name we should use for that purpose? _NET_WM_XPRA? "So far I have been unable to run xpra/winswitch myself so could not reproduce." Would mind sharing the details?
"So far I have been unable to run xpra/winswitch myself so could not reproduce." Missing python packages. What about: "Could you compile latest oxygen-gtk (from git trunk), with Debug mode enabled (basically: cmake -DOXYGEN_DEBUG=1 /path/to/sources)" Please ? Only then might I be able to try figure out a fix.
"basically: cmake -DOXYGEN_DEBUG=1 /path/to/sources" Sorry, *I* only have testing environments (via VirtualBox), so that's not an option for me. Does the _NET_WM_XPRA sound reasonable to you? It would catch all windows forwarded by xpra.
"basically: cmake -DOXYGEN_DEBUG=1 /path/to/sources" > Sorry, *I* only have testing environments (via VirtualBox), so that's not an > option for me. > > Does the _NET_WM_XPRA sound reasonable to you? > It would catch all windows forwarded by xpra. > Well I'd rather catch the native widget/window that runs locally and in which the app is embedded.
Yes, that is *exactly* what I am proposing: the native widget window *is* xpra, and the contents of the window are just forwarded bitmaps of the real remote window's contents. The applications that you launch via xpra have no idea that they are being remoted.
listen, if you think you can fix the bug your way, feel free to submit a patch. Otherwise, please let me try fix it my way. Thx.
Saying it differently, I do not plan to check on X flags unless there is no other way, which so far has not been proven.
let me see if I get this straight: * you've never used xpra * you don't understand what it does * you don't like my proposed solution * you are going to "fix it your way", which you won't be able to test since you don't use it Am I missing something? I don't mean to be argumentative here, I am trying to work *with* you to find a solution. I would submit a patch, but from the tone of your previous messages I get the strong impression that it would not be well received at all, so I will wait for now and simply tell users to "complain to KDE".
> "I will wait for now and simply tell users to "complain to KDE"". Please do, Maybe some of them would be able to provide the information I need.
Created attachment 60519 [details] Xpra log section from winswitch when doing a window drag
Hello Armin, Thanks for the log. To be sure I understand its content: is this the log of oxygen-gtk on the remote side, or on the local side (that runs xpra client ?) If I understand bug 274623, xpra-client crashes (on the local side) when using oxygen-gtk. Correct ? If yes ? How did you get the log above ? Thanks for the info and patience. (I'm trying to figure out if the issue is on the local or on the remote side).
Hi Hugo, Sorry for the rudeness above. I just happened to see this bug, and I might be able to help. IIUC, what's happening is that the gtk-oxygen style runs inside gtk+ programs and attempts to capture any clicks that occur outside of any widget, and for such clicks it triggers a drag? That would make sense of the observed behavior. The xpra client acts like an ordinary gtk+ application, except a very minimal one. You can see the complete code for the windows that xpra opens here: https://xpra.org/trac/browser/trunk/src/xpra/client.py#L181 Basically, it just makes a subclass of GtkWindow which captures input events and draws directly on the window surface -- this window contains no widgets whatsoever. This is admittedly an unusual way to use Gtk+, and I can see how it might confuse things... nonetheless, it should probably be supported. It's also possible that this is a bug in xpra, where it's letting the default button-press-event handler run when it should be overridden, or something of that nature -- my memory of gtk+ signal chaining rules is rusty. Antoine: If this analysis is correct, a possible hacky workaround would be to move the client window drawing code into a custom widget, and then place that widget inside the window. Also note that even if window matching were somehow appropriate for this bug, you are *not* allowed to just invent an attribute named _NET_WM_XPRA -- the _NET_WM prefix means "this is a standard attribute defined by the EWMH standard". HTH.
Hi Antoine, I would like to ask you. Is it possible to do, what Nathaniel is purposing? I would like to run xpra correctly in kde. Thanks for everything. Ciao Martin
Hi Martin, Although this "hacky workaround" sounds like it might do the trick, I am very reluctant to implement it as it would require some significant changes to the code, only to workaround an odd behaviour that is only present in kde/oxygen and nowhere else. On the other hand, adding a window property (not named _NET_WM_XPRA but _XPRA_MANAGED or whatever kde would be happy with) would require one line of code on our side and probably little more than one line of code on the kde side... Cheers Antoine
Hi Hugo, i am user who is complaining. I think i will be able to give you more info. Please just ask. Will it be possible to implement what Antoine is writing in previous comment? Thanks Martin
Hello Martin, others What Nathaniel propose would work. I'd get the widget name, check and blacklist. What Antoine propose would work, but requires that oxygen-gtk checks X Properties for every single window and every single application, just for this one application. X access being expensive, I will not implement that. A third solution which I am working on implementing is to pre-define a GtkWidget (actually a GObject) property that oxygen-gtk could check in order to turn off grabbing. Accessing GObject properties is 1/ much less expensive than accessing X windows 2/ as easy (or easier) to setup on the client side (the application) as an X property. 3/ the fact that the name of the property is defined (and hopefully will be documented) by the gtk-style makes it possible to be re-used by other applications with the same issue (or if you want, with which oxygen-gtk has the same issue). The name of the property would be "_kde_no_window_grab", for consistency with oxygen-qt which already has such a mechanism in place (for QObjects) Antoine ? Martin ? Does that sound acceptable ? Also, last but not least, the first thing oxygen-gtk does when checking if grab should be enabled on a gtk window is veryfying (before doing anything), if the GtkWindow has set the flags to receive Button Press and Button Release events, in which case grab is switched off, assuming that these events are indeed used by the window (and so unusable for oxygen-gtk's grab). Namely (pseudo code): if( (gtk_widget_get_events ( widget ) & (GDK_BUTTON_PRESS_MASK|GDK_BUTTON_RELEASE_MASK) ) ) { return false; } // means do nothing. Why this fails here is either 1/ because this mask is not set on the xpra GtkWindow 2/ the test above is done too early with respect to when it is set. 3/ there is a bug in my code (I'll try test this on my side with a simple dummy application) Any comments on this ? (mostly 1/ or 2/) Cheers, Hugo Reopening the bug report since there have been some activity lately.
I'm quite happy to use gobject properties for "_kde_no_window_grab", that would be trivial to add. It would probably be worth having in any case, even if the event mask stuff can be made to work. As for the event mask, we do this very early on in the gtk windows' constructor method: WINDOW_EVENT_MASK = gdk.STRUCTURE_MASK | gdk.KEY_PRESS_MASK | gdk.KEY_RELEASE_MASK | gdk.POINTER_MOTION_MASK | gdk.BUTTON_PRESS_MASK | gdk.BUTTON_RELEASE_MASK So I would have thought that the oxygen-gtk catch code should fire... I'll try to see if I can move it earlier in the constructor. Any idea when/how-early this catch is tested for? Cheers Antoine
Hi Antoine, From my test here, it should be sufficient to set the event mask _before_ calling gtk_widget_show( your_widget ); More explicitely: gtk_widget_add_events( widget, GDK_BUTTON_RELEASE_MASK | GDK_BUTTON_PRESS_MASK ); gtk_widget_show( widget ); Can you test and possibly confirm that it fixes the bug ? I'm still working on implementing the gobject property handling (for completion), but in your case it should not be necessary. Hugo
That is already the case: https://xpra.org/trac/browser/tags/v0.2.x/src/xpra/client.py#L1026 window = ClientWindow(self, wid, x, y, w, h, metadata, override_redirect) (...) window.show_all() We create the new ClientWindow (gtk.Window subclass) and we call show_all() after calling the constructor. The constructor is here: https://xpra.org/trac/browser/tags/v0.2.x/src/xpra/client.py#L204 and it contains: self.add_events(WINDOW_EVENT_MASK) (with the WINDOW_EVENT_MASK value shown in comment:19) There are no other calls to show() or realize() anywhere... So I don't understand why this does not fire!
ah ok. That's why it does not work. The current check only work on "native" GtkWindow not on derived classes (because of other issues in other apps) So this check will not work, sorry for the noise. I could "blacklist" the derived class name (in fact that was my original idea). The gobject property will work for sure also (when it is implemented in the oxygen-gtk code) I expect to have something by the end of the week.
Git commit 53312cd3dd5ae0338cc1c899f9461e82652cc9f8 by Hugo Pereira Da Costa. Committed on 26/04/2012 at 13:13. Pushed by hpereiradacosta into branch 'gtk3'. added the same property names as for the Qt version in separate file. check for _kde_no_window_grab property to blacklist widget. M +1 -0 src/CMakeLists.txt A +38 -0 src/oxygenpropertynames.cpp [License: BSD X11 (BSD like)] A +46 -0 src/oxygenpropertynames.h [License: BSD X11 (BSD like)] M +8 -0 src/oxygenwindowmanager.cpp http://commits.kde.org/oxygen-gtk/53312cd3dd5ae0338cc1c899f9461e82652cc9f8
Commits above would recognize setting the "_kde_no_window_grab" to disable window grab. Explicit code would be: add: g_object_set_data( G_OBJECT( your_widget ), "_kde_no_window_grab", (gpointer)1 ); before gtk_widget_show() So far it is only merged to oxygen-gtk's master branche. I'll merge with the release branche (1.2) in a couple of days after testing for regressions. Next "stable" releases of oxygen-gtk are for May 15 or so. In the meanwhile, would be awesome if someone could test using oxygen-gtk compiled from source.
Added _kde_no_window_grab=1 to all xpra windows: https://xpra.org/trac/changeset/773 I'm running Fedora 16, so I can test if someone tells me how to get this change into whatever oxygen version is shipped with Fedora ... Otherwise, testing xpra is relatively simple, build it from trunk: http://xpra.org/dev.html Then run a session: http://xpra.org/#get_started Thanks! Antoine
Hi All, i am using gentoo. so i can even test master(trunk) version. of xpra and oxygen-gtk. Ciao Martin
i builded oxygen-gtk from kde overlay, here is ebuild http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=x11-themes/oxygen-gtk/oxygen-gtk-9999.ebuild;h=1bc72f4dcd7960ff3318f92b070dfa3c8b1dac94;hb=HEAD and installed latest trunk of xpra mvala@vala ~/trunk/src $ PYTHONPATH=./build/lib*:$PYTHONPATH xpra attach ssh:alike@pcalike01:100 alike@pcalike01's password: cannot import x11 bell bindings (will use gtk fallback) : No module named bindings failed to use native get_modifier_mappings: No module named bindings failed to get keyboard repeat rate: No module named bindings Ciao Martin
Hi Martin, Sorry about the wrong instructions in the INSTALL file, this is now fixed in: https://xpra.org/trac/changeset/775 You need to use this tweaked python path when not installing globally (which I don't do very often): PYTHONPATH=`ls -d install/lib*/python`:$PYTHONPATH ./install/bin/xpra Cheers Antoine
Hi Antoine and Hugo, it is working nicely. I can press buttons and do any action with menu. Perfect. Thanks for fixing it. Ciao Martin
Awesome ! Nice collaborative work ! So I guess it will be available after next release of xpra and oxygen-gtk. Closing. Thanks for posting the bug, and for insisting ;)
Looks like this is broken in GTK3: set_data function got moved to gobject: https://developer.gnome.org/pygtk/stable/class-gdkwindow.html#method-gdkwindow--set-user-data And then removed completely: https://bugzilla.gnome.org/show_bug.cgi?id=641944 Any ideas on how to make this work again with Python3 / GI ? (skipping rant about how difficult it is to move to py3k even without the constant API breakage)
@Antoine This bug report is about oxygen-gtk2. If you found a problem with oxygen-gtk3, it's another bug. Now, oxygen-gtk3 has a shaky future, see https://bugzilla.gnome.org/show_bug.cgi?id=735211 . Dunno whether GTK team has removed GtkThemingEngine in GTK 3.16 yet or if not, whether they will do before GTK 4. Thus I'm not sure if fixing anything for GTK3 is worth it.