On startup, the cursor is kept hidden if there's any touchscreen available.
If the device that was last interacted is removed, we check on available
pointing devices though, so we don't possibly hide the pointer if there are
further mice/touchpads/etc.
Devices being added don't update cursor visibility, we wait for the user
interacting with those instead.
https://bugzilla.gnome.org/show_bug.cgi?id=712775
On X11, calling this function on meta_display_handle_events() will not catch
mouse events happening over clients, so poke directly in the backend for
XI_DeviceChanged events, which mutter will get on device switches.
The code has been slightly refactored so we deal with XIEvents at a single
handle_input_event() function.
https://bugzilla.gnome.org/show_bug.cgi?id=712775
This function can be used to trigger changes depending on the device type
that is currently emitting the events. So far, it is used to switch cursor
visibility on/off on touchscreen interaction.
A "last-device-updated" signal has also been added, in order allow hooking
other behavior changes (eg. OSK) when the last device changes.
https://bugzilla.gnome.org/show_bug.cgi?id=712775
Since commit 6e06648f7, we start out with the invisible frame parts
only, and then add the unconstrained rect's height (which consists of
the visible parts of both frame and client window) *unless* the window
is shaded. While we indeed don't want to add the client height in that
case, we need to explicitly include the visible frame parts now.
https://bugzilla.gnome.org/show_bug.cgi?id=746145
There is no good reason to do so, besides a nice way to check whether
a particular button is enabled. However there are legitimate reasons
for overdrawing like box-shadows or outlines, so remove the clip.
The initial pointer position is set by clutter. At the moment it
is the point 16x16 on the screen. But this point is not always
in the visible area on monitors (the monotors can be arranged in
many different ways).
https://bugzilla.gnome.org/show_bug.cgi?id=745752
Otherwise the pointer might be "lost" outside the visible area. Note
that the constraining code only ensures the pointer doesn't leave the
visible area but if the pointer is already outside because the rug was
pulled under it then it doesn't do anything.
https://bugzilla.gnome.org/show_bug.cgi?id=745121
Rename the install projects to clutter-install so that it would be easier
to use the project file set as a part of a grand solution file, such as
one that is used to build the entire Clutter stack.
"Install" the .pdb file for the Clutter DLL, that is already built
alongside with it with all builds. This commit will disable, for now,
the "installation" of the test/sample programs.
In order to make the .pdb filename match the filename of the target, the
.pdb filename must be specified for Visual Studio builds, if the target
filename does not match the project name. Update the Clutter main project
accordingly.
Use the multipropcessor compilation (/MP) option, which can help cut down
build times for release builds by quite a bit. A warning will be emitted
for debug builds, due to the use of /Gm, but the build will otherwise
proceed normally.
Also use the /d2Zi+ compiler flag for MSVC 2010 (and later) builds, so that
more useful info would be logged to the .pdb files that are generated
during the build.
Rename the install projects to cogl-install, so that it is easier to
differentiate the projects when using the project set in a grand solution
file, such as a grand solution file that is used to build the entire
Clutter stack.
"Install" the .pdb files with the built DLLs and examples, as the .pdb
files are already generated for all builds, which are useful for debugging
during Cogl development, or during development of Cogl-using items.
Also be more selective on the LIBs, DLLs and EXEs that are copied, so that
we only copy the items built during Cogl compilation when the project set
is used in a grand solution, such as when building the entire Clutter
stack, which will avoid items being incorrectly copied or extra and
unneeded items being copied.
Use the multiprocessor compilation (/MP) option so that release build times
can be cut down quite a bit. This will generate a brief warning for debug
builds as such builds use /Gm, but otherwise the build will proceed
normally albeit it would be slower.
Also use the /d2Zi+ flag for Visual Studio 2010 (and later) builds to log
more useful information in the .pdb files that are generated, to aid
debugging release builds when necessary.
To make the .pdb filename match the filename of the built target, one must
specify the .pdb file name if the target filename does not match the
project name for Visual Studio 2010 and later. Update the projects
accordingly.
The timer to blacklist the window from frame sync is set at the time of
issuing the sync request, but not removed until the client replies to
the most recent wait serial.
This means that if the client is slowly catching up, the timeout would
fire up regardless of the client slowly updating the alarm to older
values.
Fix this by ensuring the timeout is reset everytime the sync request
counter is updated, to acknowledge the client is not irresponsive,
just slow.
https://bugzilla.gnome.org/show_bug.cgi?id=740424
MetaWaylandFrameCallback has been added a surface field, which is then
checked when destroying the surfaces. This prevents unintended callbacks
to run after a surface has been destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=745163
