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
