> This has been fixed in xournal's CVS code base. The patch adds an X > error trap around the functions to enable/disable Xinput devices. This > is in xo-callbacks.c, more precisely in on_canvas_enter_notify_event() > and on_canvas_leave_notify_event(). (see how these have changed > between stock 0.4.5 and the CVS). > > This is a small enough fix, and given how annoying the crashes are, I > suggest you include it too. > > Good luck with everything!
Thank you, I will use this code. ----------------------------------------------- Ok, thank you. I had problems with rotation in Xournal 0.4.5 on my tablet PC. Are I alone? If we don't get it working 100% width GTK may can write our own Abstraction layer. Catch and handle the X events needs not more than 100 lines of code. (I wrote this code for other purpose, but I didn't find it at the moment) The only disadvantage is that we have to do this 3 times, for Linux, Windows and Mac... But this has for me now low prio, there are to much other things which are not working... I thought I would try to recognize screen rotations, because (for me) I would switch the toolbars, my new tablet has a wide-screen display, so the toolbars are cut off. My tablet needs about 1 second to rotate, while this time the screen is flickering, one second is a long time for an application, so it is theoretically possible to restart the application without the user recognizes it. I save all states, so if you close and restart the application the same tool, the same color, even the same page is selected. Additional only the undo / redo stack has to be saved, then it is possible to restart the application. But not now, I also don't have enough time to do this now, but it is an idea;-) Andreas Am 04.01.2011 21:37, schrieb Denis Auroux: > On 01/04/2011 03:30 PM, Denis Auroux wrote: >> Correct. It's a GTK+ bug (GTK+ doesn't update its information when the >> screen gets rotated) that's really hard to overcome. >> >> Xournal should do very slightly better at it than GIMP and other >> programs, because it bypasses GTK+'s event coordinate conversion and >> does its own, assuming the aspect ratio of the digitizer matches that of >> the screen and the upper-left corner never moves (which of course are >> not quite correct, hence the frequent loss of calibration upon >> rotation). > > To be more precise: this is what #define ENABLE_XINPUT_BUGFIX is about. > (It used to be much more broken in older GTK+ versions, which made it > even more desirable). In main.c it sets the device axes to IGNORE mode > instead of being the X and Y axes, so that GTK+ does NOT attempt to > convert to x/y coordinates (which it is extremely confused about after > rotation), and instead converts to a range from 0 to 1. Subsequently, > the code in fix_xinput_coords() in xo-misc.c (called from the button > event handlers of xo-callbacks.c) converts these 0-1 ranges back into > canvas-relative coordinates, in a way that's slightly more robust than > GTK+'s. > > The main problem is that, since GTK+ never notices that everything > gets recalibrated by display rotation, and never tells xournal either, > I think the only way to really know what's going on might be to talk > directly to the X server, bypassing GTK+ completely for XInput event > handling. (Or maybe there is an event like ConfigureNotify that one > can try to listen for that might get triggered when the display gets > rotated? I am not sure). > > Anyway: this hack helps everyone for whom the tablet display starts at > (0,0) both in screen coordinates and in wacom device coordinates, > which is why some people will say "xournal works just fine with > rotation". > If those assumptions are not satisfied then most likely strokes will > be off by some amount. > > Denis > ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
