Destroying an actor is supposed to destroy all of its children, so
it makes sense to reason that destroying the stage should destroy all
of its children, too.
Unfortunately, it seems that the stage removed all of its children
without destroying them before chaining up to what would destroy all
of its children, for whatever reason. Change this to a destroy so
resources get cleaned up.
The TextureNode premultiplies the blend color passed to the node
constructor, so we need to document the fact properly to avoid
causing premultiplication twice.
We can also allow passing NULL for a color, and use a fully opaque
white, to make the code slightly more friendly.
ClutterTextureNode will do that for us when converting the ClutterColor
to a CoglColor, so we can simply pass a white color with the correct
alpha channel.
The calculation (n - 1) * spacing to compute the total spacing is
only correct for n >= 1 - if there are no visible rows/cols, the
required spacing is 0 rather than negative.
https://bugzilla.gnome.org/show_bug.cgi?id=709434
For some XI2 we do not have a Stage associated to the event window.
Original patch by: Giovanni Campagna <scampa.giovanni@gmail.com>
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=708439
On high DPI density displays we create surfaces with a size scaled up by
a certain factor. Even if the contents stay at the same relative size
and position, we need to compensate the scaling both when changing the
surface size, and when dealing with input.
https://bugzilla.gnome.org/show_bug.cgi?id=705915
In order to transparently support high DPI density displays, we must
maintain all coordinates and sizes exactly as they are now — but draw
them on a surface that is scaled up by a certain factor. In order to
do that we have to change the viewport and initial transformation
matrix so that they are scaled up by the same factor.
https://bugzilla.gnome.org/show_bug.cgi?id=705915
The added support is very very basic (single touch, motion only,
no acceleration, no pressure recognition), but anything more
complex requires a state machine that will be hopefully provided
by libinputcommon in the future.
And at least, with this patch the pointer moves, which will be
useful for people testing wayland in 3.10 without a physical mouse.
https://bugzilla.gnome.org/show_bug.cgi?id=706494
In situations when the default backend would fail (for example
when compiled with X11 support but run without DISPLAY), or
when the application is using backend specific code, it makes
sense to let the application choose the backend explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=707869
It was a bad idea to add it, because clutter events are batched,
so by the time the application processes one, the keyboard state
internally tracked by clutter could be already different.
Instead, apps should use clutter_event_get_state_full()
https://bugzilla.gnome.org/show_bug.cgi?id=706494
We can't dispatch a motion event for EV_REL (because we don't
have yet the other half of the event), but we can't also queue
them at the end of processing (because we may lose some history
or have button/keys intermixed).
Instead, we use EV_SYN, which means "one logical event was
completed", and let the winsys-independent code do the actual
motion compression.
https://bugzilla.gnome.org/show_bug.cgi?id=706494
When we release a device, we lose all the events after that point,
so our state can become stale. Similarly, we need to sync the
state with the effectively pressed keys when we reclaim.
This ensures that modifier keys don't get stuck when switching
VTs using a keybinding.
https://bugzilla.gnome.org/show_bug.cgi?id=706494
When talking to other applications or serializing the modifier
state (and in particular when implementing a wayland compositor),
the effective modifier state alone is not sufficient, one needs
to know the base, latched and locked modifiers.
Previously one could do with backend specific functionality
such as clutter_device_manager_evdev_get_xkb_state(), but the
problem is that the internal data structures are updated as
soon as the events are fetched from the upstream source, but
the events are reported to the application some time later,
and thus the two can get out of sync.
This way, on the other hand, the information is cached in the
event, and provided to the application with the value that
was current when the event was generated.
https://bugzilla.gnome.org/show_bug.cgi?id=706494
These two devices are logically tied togheter, and their state
should always be the same. Also, we need to update them after
the event is queued, as the current modifier state (as opposed to the
modifier mask in the event) should include also the effect of the last
key press/release.
https://bugzilla.gnome.org/show_bug.cgi?id=706494
Add a new callback that is called prior to emitting pointer
motion events and that can modify the new pointer position.
The main purpose is allowing multiscreen apps to prevent the
pointer for entering the dead area that exists when the screens
are not the same size, but it could also used to implement
pointer barriers.
A callback is needed to make sure that the hook is called early
enough and the Clutter state is always consistent.
https://bugzilla.gnome.org/show_bug.cgi?id=706652
If we don't get passed a CoglFramebuffer when creating the root paint
node then we ask Cogl to give us the current draw buffer.
This allows the text-cache conformance test to pass, but it'll require
further investigation.
Currently the default values according to their param spec don't
match the actually used defaults, so update the former to reflect
the actual behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=703809
Whether a child should receive extra space should be determined
by the expand property, not [xy]_fill (which just determine how
additional space should be used). The behavior is already correct
when using the ClutterActor:[xy]_expand properties, but needs
fixing for the corresponding ClutterBoxLayoutChild property.
https://bugzilla.gnome.org/show_bug.cgi?id=703809
Just as BoxLayout, BinLayout uses an odd interpretation of the box
passed into allocate(): to define a child area of (w x h) starting at
(x, y), callers need to pass a box of (x, 2 * x + w, y, 2 * y + h).
This behavior is just confusing, change it to use the full box for
child allocations.
https://bugzilla.gnome.org/show_bug.cgi?id=703809
Currently, BoxLayout interprets the box passed into allocate() in
a fairly peculiar way:
- in the direction of the box, all space between [xy]1 and [xy]2
is distributed among children (e.g. children occupy the entire
width/height of the box, offset by [xy]1)
- in the opposite direction, expanded children receive space
between [xy]1 and the height/width of the box (e.g. children
occupy the width/height of the box minus [xy]1, offset by [xy]1)
The second behavior doesn't make much sense, so adjust it to interpret
the box parameter in the same way as the first one.
https://bugzilla.gnome.org/show_bug.cgi?id=703809
