GNOME Bugzilla – Bug 445284
Custom (pixbuf etc.) cursor reverts to default cursor on left/right mouse click
Last modified: 2018-02-10 04:36:48 UTC
Please describe the problem: On Win32, a custom cursor assigned with gdk_window_set_cursor and either built-in or created from gdk_cursor_new_from_pixbuf will vanish (reverting to the stock Windows cursor) when the user depresses left or right-click. The custom pixbuf cursor reappears when the mouse button is released. The same code on Linux or OSX/X11, however, demonstrates proper behavior: the custom pixbuf cursor remains on the screen regardless of the mouse button being pressed or not. A workaround exists for win32 which involves setting the cursor with gdk_window_set_cursor during each "button_press_event" for every widget that can be clicked. This requires that every widget sets a callback for the "button_press_event", and then the callback needs to call gdk_window_set_cursor with the current cursor that should be displayed. This workaround code also operates correctly on the X11 platforms--but why is it necessary? This appears to be a weakness in GTK on Win32. We have prepared two C examples, one which shows correct cursor behavior (custom cursor does not disappear) on X11 but shows the cursor reverting on Win32, and one with the workaround. Code tested with GTK 2.10.11 on Win32. Steps to reproduce: 1. Obtain the attached code package including the custom pixbuf PNG for the cursor. 2. Compile scribble-old on Win32 and run it (or run our included scribble-old exe). gcc -Wall -g scribble-old.c -o scribble-old `pkg-config --cflags gtk+-2.0``pkg-config --libs gtk+-2.0` 3. Notice that the custom cursor appears in the window. 4. Press left mouse button to draw in the scribble window. 5. Notice that while LMB is depressed, our custom cursor vanishes and is replaced by the Windows cursor. Notice that when the LMB is released, our custom cursor returns. 6. Compile scribble-old on an X platform (we used MacOSX/PPC w/X11.app, we suspect Linux will also serve.) 7. Notice that while LMB is depressed on an X platform, the custom pixbuf cursor _correctly remains on the screen._ 8. Compile scribble-new on Win32 and run it. (or run our included scribble-new .exe) This version of the scribble code uses the workaround. 9. Notice that the custom cursor now correctly remains on the screen even while drawing with LMB. Actual results: On scribble-old, you see the pixbuf cursor disappear on Win32 during mouse clicks. You see the pixbuf remain on X platforms during mouse clicks. With scribble-new, the pixbuf cursor correctly always remains on the screen. Expected results: We would expect that the same (correct) pixbuf cursor behavior exhibited with scribble-old on X would be replicated on Win32 so that the special workaround is not necessary for Win32. Does this happen every time? Yes, this happens consistently, every time. Other information:
Created attachment 89570 [details] Two scribble.c variants demonstrating the vanishing custom cursor, one with workaround
Additional information: Our Win32 trials were run on Win2K and WinXP.
Created attachment 89576 [details] [review] Suggested patch Thanks for the test programs. It would have been enough to just attach the source files, each as such as a separate attachment. I did not run the provided executables anyway, but recompiled them. This simple patch (which just removes a few lines of apparently unnecessary and even broken code) to gdkevents-win32.c seems to fix this problem. I hope it doesn't cause any unintended side-effects. I'll ask for volunteers to test the patch and see if they can come up with some case where the patch causes a regression.
Thank you for the prompt attention (and I'll post individual unarchived source files in the future if and when it comes up, as you suggest.) I don't suppose there's "nightly build" DLL(s) available incorporating this change? We would be happy to test it against our master application (the one we need the persistent custom cursors for), but I don't know as much about getting someone here who can build GTK Win32 from source... Also, although we looked around a bit, I couldn't find a ready explanation for the question of why GIMP Win32 is able to keep its custom cursors around even during a left-click (the paintbrush remains a paintbrush while you draw with it, etc.) Has GIMP on Win32 been doing some sort of other workaround to deal with this issue for years, or is something else going on? The fact that GIMP appears to handle it had us wondering if _we_ were initially doing something wrong.
Hi Jason, I've posted some instructions for how I cross-compile Win32 GTK binaries from Linux[1], and Tor has documented how he builds Evolution and its dependencies (of which GTK is one) using MSYS/mingw on Windows[2]. Feel free to email me if you have any help with this. [1]. http://live.gnome.org/Cross_compiling_GTK+_for_Win32 [2]. http://www.go-evolution.org/Building_Evolution_on_Windows
Cody sent over a compile of libgdk-win32-2.0-0.dll with this patch applied, and it appears to have solved the problem (custom cursors now remain on-screen during LMB/RMB) without introducing any obvious side effects. Thank you both.
I went ahead and applied this to trunk and gtk-2-10 branch in svn.
Unfortunately that small patch causes an unfortunate and irritating side-effect and should probably be reverted until a more proper fix is available: Try right-clicking in a GIMP image window. With this patch, the cursor used for the menu that pops up is still the one for the current GIMP tool. This is ugly and an unacceptable regression in my opinion. Too bad this wasn't noticed before the patch was committed. We need to emulate X11 cursor behaviour in combination with grabs more closely. A more complex fix for this bug is required.
Patch reverted.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.