Hi Daniel and all, I tried to do "the right thing" i.e. postpone emergency disable xinput while a button is pressed until said button is released, to avoid disabling an input device that has an implicit pointer grab (due to button currently being pressed) and getting GDK confused about event routing when the device later gets re-enabled. (Disabling the xinput devices is needed when editing text or running a dialog box in order to avoid unresponsiveness of GTK text boxes and some other interface elements depending on environment, see bug #159). It caused more harm than good (it fixed this bug but made the text tool semi-unresponsive as the newly created text editing widget would be confused about focus etc.).
So instead, I'm doing the easy thing, i.e. the text tool and the image tool now activate upon releasing the mouse button, instead of upon pressing it. (Then we no longer have an implicit device grab and can safely disable xinput in order to allow the text box or dialog box to work properly). This should fix both the bug pointed out here, and a similar bug with the text tool: until now, if you select the text tool, click in the drawing area to start editing a text box, then press Esc to cancel the text edition while the pointer is in the drawing area, then click in the toolbar, that would start a new text box again (above the visible portion of the page) instead of doing whatever you expected to be doing in the toolbar. This should also be fixed now. On the other hand, this doesn't fix the more convoluted bug I pointed out last night: > In principle you can get a similar problem to happen if you are > drawing with the pen then, while drawing (pen or other drawing device > still pressed on the screen) use the keyboard shortcut say Ctrl+S to pop > up a save dialog window (assuming the document was unnamed so far). Then > release the pen (or input device); close the dialog box, making sure the > pointer is inside the drawing area when the dialog closes. Then at that > point xournal re-enables xinput; complains about a suspicious > MotionNotify event; and if now you move the pointer to the toolbar area > and click, it sends the click to the drawing area (and you are actually > drawing above the visible portion of the page) instead of sending it to > the toolbar. But I think we can live with this one, which is rather hard to run into by accident and unlikely to cause major headaches. The CVS and GIT repositories on sourceforge.net are now updated. Let me know if you confirm the bug with the "insert image" tool is fixed. Also let me know if you spot any regressions with the text tool or any other features (seems unlikely but one never knows). Denis -- Denis Auroux UC Berkeley, Department of Mathematics 817 Evans Hall, Berkeley CA 94720-3840, USA aur...@math.berkeley.edu ------------------------------------------------------------------------------ _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
