Unresponsive GUI when XInput enabled
Brought to you by:
andreasb123,
auroux
Menu
▾
▴
#170 Unresponsive GUI when XInput enabled
OS: Debian Unstable, Xfce4
Xournal: 0.4.8
Steps to reproduce:
1.Launch Xournal
2.Enable 'Use XInput'
3.Click File --> Export to PDF
Now "Export to PDF" window is unrepsonsive to mouse. You can't click or select or scroll or do anything else with mouse (except buttons of its title bar). Although you can still use keyboard to select and click element of interface.
Steps to reproduce:
1.Launch Xournal
2.Enable 'Use XInput'
3.Click 'Text' icon and type something in. Don't do anything else, because otherwise 'Export to PDF' can become unrensponsive.
4.Click File --> Export to PDF (this time the window is mouse-responsive)
- Now close "Export to PDF" window either by pressing Escape or by saving file, it doesn't matter.
6.Now all menus(except "Layer" ) and all icons don't response to mouse.
P.S.
Feel free to ask me any questions about my system! I will do my best to answer them!
Last edit: roboq6 2016-06-26
This seems very closely related to bug #159 and other random similar
problems (details dependent on window-manager and perhaps GTK version;
likely caused by a GTK issue since no windows should be unresponsive
ever). I've already added workarounds for some of these issues in the
GIT repositories, can you please recompile xournal from the latest CVS
or GIT version and check whether the problem remains present ?
See eg https://sourceforge.net/p/xournal/code/ci/master/tree/ for the
GIT repository (you can click "download snapshot" in the black titlebar
if you don't want to bother with git). I hope this fixes the issue,
but let me know if not (or if a modified version of the problem remains).
Denis
I don't know if my results are helpful, because I can't properly satisfy dependencies for compilation. Your program needs versions of libgnomecanvas and poppler-glib that are too new even for Debian Sid. I even tried to find newer version of said packages in "experimental" branch, but without sucess.
I nevertheless tried to compile the code with the latest versions of development packages for libgnomecanvas (2.30.3-2) and poppler-glib (0.44.0-3) that are available on Unstable (I followed the instruction for installation in $HOME because systemwide installation of anything without package manager is dangerous). I was able to successfully compile and install it in $HOME . (except for "make home-desktop-install", something gone wrong here. And by the way, you should add gtk-update-icon-cache to dependencies, because "make home-desktop-install" needs it and this package wasn't installed on my system). Then I located the executable with "find $HOME -name '*ournal'' " and started it. I wasn't able to reproduce the reported bugs, so it seems like your changes are successful.
I have two questions for you:
1.Who is guilty for this bug? Is it bug of Xournal? Or maybe it's bug of XInput/Xorg and you just added workaround/hack in order to circumvent it?
2.What Linux distro are you using that you are able to use such bleeding edge versions of development packages for libgnomecanvas and poppler-glib?
Last edit: roboq6 2016-06-27
Thanks a lot for testing!
You did more than satisfy the dependencies for compilation -- the
oldest allowed versions are from around 2006 or so. Regarding
libgnomecanvas 2.4.0 is much older than 2.30.3, and regarding
poppler-glib, 0.5.4 is much older than 0.44.0... (by 39 versions, 44
minus 5). (This is so xournal will keep running on CentOS, even though
it is hopelessly out of date; several features only become enabled with
slightly more recent versions though.)
(For your info, I'm running Fedora 22, which has poppler-glib 0.30.0 and
gnomecanvas 2.30.3.)
Who's responsible for the bug: at this point it is pretty hard to
figure out whose fault it is, though I'd blame the GTK libraries first.
There have been historically a number of bugs surrounding XInput event
processing, not all of them fixed so far, and Xournal tries to work
around many of them in various ways. In this case one of my workarounds
did some good and some harm alike; the patches since 0.4.8 try to make
it better.
The general issue causing all this trouble is that, for XInput-enabled
windows, the ordinary ("core") input events are filtered out by GTK to
only send the enhanced XInput event to the application, but some of
GTK's own widgets don't seem to handle XInput extension events properly.
Eg, one issue still present in not-so-old distributions is that the
text edition widget can easily become unresponsive when XInput is
enabled in its container window, so we have to disable XInput when we
start typing text. Under some situations (likely dependent on the window
manager or X server, I've never had the problem with Gnome 3 on Fedora),
GTK pop-up windows also get very confused and unresponsive when XInput
is enabled (the problem is ultimately with GTK, which should be aware of
its own limitations and not filter out core events to leave only XInput
extended events in a way that will confuse its own widgets; not sure why
the problem is window manager dependent).
Anyway, it's complicated, but the story is that there were some
scenarios where Xournal's code to disable XInput temporarily while a
pop-up window is open or a text edition box is active or one leaves the
window didn't quite work in the expected way (basically when two of
those scenarios happened near-simultaneously). Hopefully the new code is
more robust. I'm glad the issue seems to be fixed.
with Debian and related distributions... will need to look into proper
installation process sometime.
Best,
Denis
On 06/26/2016 10:02 PM, roboq6 wrote:
--
Denis Auroux
UC Berkeley, Department of Mathematics
817 Evans Hall, Berkeley CA 94720-3840, USA
auroux@math.berkeley.edu
Related
Bugs:
#170What the ... yeah, now I see it. I thought that 2.4 is short name for 2.40, not for 2.4.0
And I thought that 0.5.4 is short name for 0.50.4, not litrally 0.5.4. (because I thought that it would be 0.05.4)
Then why don't you switch to less buggy widget toolkit?
And even more, why Xournal needs "Use XInput" option in the first place?
On 06/26/2016 11:28 PM, roboq6 wrote:
The goal is to access high-resolution data and pressure sensitivity from
Wacom pens (and other similar devices) -- a Wacom pen has extremely high
resolution (typically less than 0.1 pixel) and can detect very subtle
variations of pressure. But the only way for a linux application to get
that data is through the XInput (or now XInput2) extension to the X
protocol. Otherwise all you get is "click" at some integer number of pixels.
Because Gimp is the main Linux application using Wacom tablet's
features, its toolkit (= GTK) has had the best XInput feature set. And
it's hard to change. But at some point Xournal will move to GTK3... But
ultimately the issue is that Xournal and Gimp are essentially the only
two applications making such heavy use of XInput features under Linux,
and so those features are basically not tested thoroughly except via
those two applications. Hence the bugs.
Denis
Release 0.4.8.2016 is up to date with cvs/git repositories, and should include a fix for this bug. Please reopen if problems persist with 0.4.8.2016 or with the current cvs/git code.