Hi again,
After a quick test, the proposed fix works well for me. I made a commit
in the git repository. I don't think this warrants a re-release of the
win32 port since it's a fairly specialized bug.
(also added: now the touch detection only works if xinput is enabled --
otherwise, if touch = Core Pointer and Use XInput is actually disabled
(e.g. when you start xournal with the wacom driver disabled), everything
maps to the hand tool and it's rather confusing).
Let me know if the new git head works for you.
Denis
On 07/01/2014 05:01 PM, Denis Auroux wrote:
> Hi Daniel,
>
> I was finally able to reproduce the problem by plugging in my external
> monitor, which causes the tablet to become mis-calibrated, so that in
> Xournal the wacom pen draws some distance away from the location of the
> cursor.
>
> * ANALYSIS:
>
> This is caused partly by my hack to the gdk-win32 library to avoid the
> problem of the interface becoming unresponsive after a stylus stroke
> until one clicks outside of the canvas (because core events get filtered
> out). With my hack to gdk-win32, when you click with the stylus, we
> receive first a ButtonPress event from the stylus device, then a Motion
> event from the core pointer (why??? it's strange), then a ButtonPress
> event from the core pointer. The first button-press event starts a text
> edition. However the second button-press event then arrives and gets
> processed to see what to do with it.
>
> The standard logic in this situation, with the default settings of
> various relevant options (eg. ui.discard_core_pointer == FALSE), is that
> we want to look into this Core Pointer button-press event carefully,
> since it might be the start of some other action by the user. One of the
> first things we do after sanitizing the event data and checking that we
> do care about this event is:
>
> if (ui.cur_item_type == ITEM_TEXT) {
> if (!is_event_within_textview(event)) end_text();
> else return FALSE;
> }
>
> i.e. if we're currently editing text, we check whether the click is
> inside the text box -- if so, we abort processing the event and let it
> be sent to the text box instead; if not, we abort the text edition and
> start whatever action the user is initiating by clicking outside the
> text box.
>
> (Text is different from other drawing tools in that, normally, the user
> action -- drawing a stroke, using the eraser, moving a selection, etc.
> -- is terminated when we receive a ButtonRelease event. Not so with text
> edition obviously: you don't want to have to hold the pen pressed
> against the screen during the whole text edition).
>
> On my machine, when the external monitor is unplugged, the two button
> press events are within a fraction of pixel from each other, and in
> about 90% of the cases, the core event does fall within the text edition
> widget area, so the Core Pointer button press event gets ignored and all
> is well. In other cases or when the external monitor is plugged, the
> core event falls outside of the text widget area, so we first abort the
> text edition and then process the new button event. With more "normal"
> settings, the new button event would just start text edition again and
> you wouldn't notice much. With touch_as_hand and "Core Pointer" as touch
> device, the "Core Pointer" button press event instead starts the hand
> tool as requested... and we lost the opportunity to edit a text box.
>
> * SOME BAD SOLUTIONS:
>
> The first dirty hack that came to my mind was to add a flag to test for
> Core Pointer events that "echo" a just-received Button Press event from
> the stylus and discard them; this fails because somehow a MotionNotify
> event arrives in between the two ButtonPress events and I'd rather not
> start second-guessing what the whole sequence of events means.
>
> The second dirty hack that came to mind is to modify the code of
> is_event_within_textview() in xo-misc.c to add a margin of say 5 or 10
> pixels around the GtkTextView widget in which nothing happens when we
> click -- this would filter out the second ButtonPress event even when
> the positions don't quite match. It's quite dirty and arbitrary though.
>
> * A BETTER SOLUTION:
>
> While writing this message and back in Linux (so I can't test right
> now), a better idea came to me: in xo-callbacks.c, in
> on_canvas_button_press_event(), first move the two lines
>
> is_touch = (strstr(event->device->name, ui.device_for_touch) != NULL);
> if (is_touch && ui.pen_disables_touch && ui.in_proximity) return FALSE;
>
> further up (e.g. just above the code mentioned above testing what to do
> with the event if we're currently in ITEM_TEXT) so that when the
> pen_disables_touch option is enabled and would discard the event, it
> does so BEFORE aborting the text box. (Then turning on
> pen_disables_touch should fix your problem since proximity detection
> should work fine).
>
> A false good idea: perhaps better for you, but probably undesirable in
> general: in addition to this, also modify the test on ITEM_TEXT from
>
> if (ui.cur_item_type == ITEM_TEXT) {
>
> to
>
> if (ui.cur_item_type == ITEM_TEXT && !(is_touch &&
> ui.touch_as_handtool)) {
>
> so that touch-as-handtool events don't interrupt text edition. I don't
> think this latter change is a great idea however -- I imagine that
> "most" users expect the touchscreen to continue working while they are
> editing text, i.e. a touchscreen action should end the text edition and
> start scrolling, without having to first manually end the text edition
> by pressing the Esc key.
>
> Thinking of all these ideas -- the one I view as safe for everyone is
> moving the test on ui.pen_disables_touch up by a few lines as explained
> in "1." above, and you'd just need to enable "Pen disables touch" in
> addition to "Touch as hand". Can you confirm that this fixes the issue
> for you? One could then even add a second test to handle this specific
> bug:
>
> if (is_touch && is_core && ui.touch_as_handtool && ui.cur_item_type ==
> ITEM_TEXT && ui.in_proximity) return FALSE;
>
> (i.e., when we're in the process of editing text, and the touch device
> is the core pointer, then "Touch as handtool" also implies the same
> filtering as "Pen disables touch").
>
> The other possibilities (disabling touchscreen altogether while text is
> being edited, or adding 5- or 10-pixel margin, or undoing the bugfix in
> the gdk-win32 dll) I think of as less desirable.
>
> I'll try it out tomorrow if you haven't had the chance to do so yet --
> right now it's getting close to the end of my work day and I have to go
> pick up my child at daycare...
>
> Denis
>
>
> On 07/01/2014 07:06 AM, D M German wrote:
>> Denis Auroux twisted the bytes to say:
>>
>>
>> Denis> On 06/29/2014 10:21 PM, D M German wrote:
>> >>
>> >> I think I understand. But... what about simply being able to start
>> >> editing the text? Once in the box I don't need the stylus (i can use
>> >> arrows and shift) but the problem is that one cannot get into the
>> >> text-edit mode
>> >>
>> >> --dmg
>>
>> Denis> Hi Daniel,
>>
>> Denis> Actually I can't reproduce your problem on my Yoga. In the
>> Windows
>> Denis> version, with touch device set to "Core Pointer" and both
>> Denis> pen-disables-touch and touch-as-hand enabled, I'm able to use
>> the pen
>> Denis> just fine to create text boxes and edit them...
>>
>> Denis> (My messages yesterday about understanding how such a bug
>> might happen
>> Denis> were hypothetical as I was too lazy to actually reboot into
>> Windows to
>> Denis> try it out. Looking at the code, I also don't see why the bug
>> should
>> Denis> happen.)
>>
>> I ran some tests in my windows tablet (both my old hack and your code).
>>
>> Overall, the handling of the core pointer/touch is better now than
>> before. The only annoyance is that in text mode (and only in text mode)
>> the stylus reacts as a core-pointer:
>>
>> - Select core-pointer as the touch device
>> - Select touch as hand tool
>>
>> now:
>>
>> - Select text mode
>> - Clicking with the stylus anywhere changes the tool to hand tool mode
>> momentarily.
>>
>> but this does not happen with any of the other drawing tools: when
>> clicking with the stylus, the action is what is expected. Only when
>> using touch (core-pointer) the hand tool is activated momentarily.
>>
>> I'll look at the code and find the reason. It is a minor annoyance
>> though, since I never used text (but now that text works I was hoping to
>> use it :)
>>
>> --dmg
>>
>>
>> Denis> Denis
>>
>> Denis> --
>> Denis> Denis Auroux
>> aur...@math.berkeley.edu
>> Denis> University of California, Berkeley Tel: 510-642-4367
>> Denis> Department of Mathematics Fax: 510-642-8204
>> Denis> 817 Evans Hall # 3840
>> Denis> Berkeley, CA 94720-3840
>>
>>
>> --
>> Daniel M. German "In other studies you go as far as
>> others have gone before you,
>> -> and"
>> http://turingmachine.org/
>> http://silvernegative.com/
>> dmg (at) uvic (dot) ca
>> replace (at) with @ and (dot) with .
>>
>>
>>
>
--
Denis Auroux aur...@math.berkeley.edu
University of California, Berkeley Tel: 510-642-4367
Department of Mathematics Fax: 510-642-8204
817 Evans Hall # 3840
Berkeley, CA 94720-3840
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Xournal-devel mailing list
Xournal-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xournal-devel
