So... annoying and confusing. This issue seems to be caused by the emergency disable of xinput that we perform before opening the dialog box (then re-enable afterwards). (Call to emergency_enable_xinput(GDK_MODE_DISABLED) in wrapper_gtk_dialog_run()).
Supposedly such an emergency-disable is needed in order to circumvent bug #159 (see https://sourceforge.net/p/xournal/bugs/159/) whereby users of some desktop environments ended up with unresponsive dialog boxes (apparently they got created with xinput attributes on but didn't know how to handle xinput events properly). For some reason, after we have disabled xinput (during the dialog box to choose the image file to insert) then re-enabled it (when we return to xournal), the xinput events get sent to the main drawing area window even when the pointer is in the menu or toolbar -- thus, clicks in the menu or toolbar get interpreted as happening in the drawing area and hence another attempt to insert an image. I'm very puzzled by why disabling and re-enabling xinput (by disabling/enabling listening for device events on the various devices, rather than toggling the xinput-awareness of the xournal windows, so this really shouldn't cause any changes to which windows receive given events (?)) causes xinput events to get sent to the wrong sub-window. Sounds like a potential GTK bug (though one that's triggered by my attempts to work around other GTK bugs -- after all in an ideal world we wouldn't need to play games with disabling/enabling input devices when a popup window shows up). One thing that confused me for a while is how to reproduce it with other dialog boxes for which in principle we handle the xinput disable/enable in exactly the same manner but I couldn't get it to work. I finally got it; it's not very interesting but, for the record, here's how to make it happen. 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. So: one contributing factor seems to be that the "insert image" action causes the xinput device to be disabled *while the button is pressed* (as we activate insert image on a button press, not on a button release). This is probably what causes event routing to get mangled once we re-enable the device -- it thinks it's still grabbed by the drawing area (as normally occurs while a button remains pressed: if the pointer leaves the window while button is pressed, the motion events still go to that window where it was when button press occurred, until button release happens). Questionable behavior whether a device that gets disabled while in a grabbed state then re-enabled much later should still remain grabbed. So, anyway, we seem to have various possible options to fix this: 1. make "insert image" act upon button release instead of button press. Perhaps easiest. 2. make the emergency disable xinput still happen when we leave the drawing area for a toolbar while not actively drawing (cur_item_type = ITEM_NONE). Then even if the xinput device is in a confused grabbed state, by the time we try to click in the toolbar we've re-disabled xinput again and things will work fine. As far as I can tell this is not a bad idea in general (under the assumption that non-drawing-area interface elements are likely to be more confused than helped by xinput events. Though I can't remember why, we used to emergency disable xinput a lot more and I explicitly removed some of those disables that this scenario would bring back -- I expect this would cause another bug to re-appear. So: not keen on this option. 3. try to manually intercept if we get a buttonpress that's outside of the drawing area and then try to convert it into a non-xinput event sent to the correct widget instead. Seems tricky. I'll think about it more and likely end up doing #1 if it does fix the problem. Denis On 04/04/2016 02:48 PM, D M German wrote: > > Please see: > > https://github.com/dmgerman/xournal/issues/26 > > > "After clicking on the insert image icon, all clicks, including those to > menus are interpreted as attempts to insert an image." > > I just tested the version in master in git (sourceforge) and it has this > bug. > > After inserting the image, any new click (even on menu options or menu > buttons) is interpreted as an attempt to insert an image, which brings > the dialog window to indicate the input file. > > > > --dmg > > -- > Daniel M. German "I don't know if HAL is homicidal, suicidal, > Dr. Floyd, in 2010 -> neurotic, psychotic, or just plain > broken." > http://turingmachine.org/ > http://silvernegative.com/ > dmg (at) uvic (dot) ca > replace (at) with @ and (dot) with . > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Xournal-devel mailing list > Xournal-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xournal-devel > -- 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
