Re: [Xournal-devel] xournal touchscreen updates / windows to-do

[D M G. <dm...@uv...>]

Hi Denis, everybody,

> Dear all,
>
> I finally have a laptop with dual pen+touch input (a Thinkpad Yoga), so 
> some updates have been happening to how xournal handles input events.
>
> 1. Touch device options and tweaks:
>
> You'll see from the last few commits (in the git and cvs repositories at 
> sourceforge.net) that there's now a bunch of new options and menu 
> entries related to touch devices -- one is the "touchscreen as hand 
> tool" option to map a touch device to the hand tool, another is a "pen 
> disables touchscreen" option to disable the touch device in xournal when 
> the pen is near the screen, and there are other tweaks to the event 
> processing code. Note in particular, if you find that the interface 
> becomes non-responsive and the pen won't stop drawing, the option 

I never had this issue.

> ignore_btn_reported_up in the config file -- no menu entry for that one; 
> the new default is true, the old default behavior was false. The old 
> behavior is safer in terms of restoring sanity if xournal somehow fails 
> to receive a button-release event, but it doesn't work at all with the 
> Thinkpad Yoga's touchscreen.
>
> This is almost exclusively for Linux since in Windows the touch device 
> is not recognized as a separate xinput device. (one could still use "pen 
> disables touchscreen" to disable the Core Pointer when the pen is in 
> range in windows as well, except the Core Pointer seems to already 
> disable itself too much in Windows -- see below).

That is the behaviour of the Wacom digitizer.

> 2. Windows:
>
> After installing MinGW more or less successfully, I'm again able to 
> build xournal for windows. I got immediately hit with the issue of 
> xournal crashing when done editing a text box, which has been reported 
> here. Unfortunately, as soon as I tried to install gdb and add debug 
> output to the code, the problem disappeared. I'll try to reproduce it 
> again another day... however, if you have a working MinGW development 
> environment, basic expertise in debugging, and do encounter this bug and 
> can figure out where exactly things get stuck at the end of a text box 
> editing action, that would be extremely useful. (Most likely, you want 
> to attach gdb to a running instance of xournal and interrupt the 
> execution when it gets stuck to get a backtrace.) Also, if some of you 
> experience this bug intermittently, ideas about what causes it to happen 
> or disappear would be helpful.

do you have binaries we can try?

> Another bug I'd like to figure out is the drawing area being 
> unresponsive to touch/mouse/... after drawing with the pen with xinput 
> enabled (and the wacom driver), until one clicks somewhere outside of 
> the drawing area. (There seem to be other variants of this issue). 
> Debugging the event code suggests that GTK+ never passes the button 
> press and pointer motion events to us -- presumably using the wacom pen 
> puts GTK+ in a mode where Core Pointer events don't get passed along 
> anymore.  If this is a GTK+ bug, a custom GTK+ DLL might need to be 
> packaged with the 'semi-official' Xournal win32 build. This one should 
> be within my abilities -- I understand the GTK+ xinput code reasonably 
> well, though I've never looked at the win32 side of it.
>
> Yet another issue is the general trouble with fonts and text and export 
> / printing. I am not sure I am competent to do anything here, but I'll 
> take a look. Ditto for the bug that causes copy-paste to go "numb" 
> sometimes (the clipboard starts giving xournal the wrong data at some 
> point, and when this happens xournal just rejects the copy-paste 
> attempts instead of crashing).
>
> Any other bugs of a similar severity level (things that crash, don't 
> work at all, or are generally major annoyances to using xournal in 
> windows) ?
>

no, no mayor annoyance.  It is more about some lack of features I'd like
to have :)

thanks Denis,

--dmg