The scroll motion values are subject of batching and scaling. Either
through scaling or by using a touchpad smooth scroll motion changes
below 0.5 are possible.
https://bugzilla.gnome.org/show_bug.cgi?id=769554
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com>
When a dialog is created, the mir event source is already executed on the
call stack. So without the recurse flag it will not be run in the main loop
used for the dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=768138
The event will be sent when the surface becomes visible on an output. With this change the GdkMirWindowImpl keeps track of the scale value and sends a configure event on change.
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com>
Windows save in hardware_keycode an information which is not so low
level and some application require the hardware scancode.
As Windows provides this information save it in GdkEventPrivate
and provide a function to get this information.
For no Windows system the function return the hardware_keycode instead.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=765259
Mouse over a parent menu[bar] didn't work while the menu was open.
The fix was to correct the behaviour of pointer crossing events so that
the pointer appears to be only inside one window at a time.
See: http://tronche.com/gui/x/xlib/events/window-entry-exit/normal.html
We need this because it fixes menu activation. The menu activation code
looks at the time between events to determine if mouse clicks happen too
quickly.
The Mir backend was checking for button mask changes to generate the appropriate
GDK event. When Mir generates a touch event it has no button mask. In this case
we'll just generate a primary button event.
