Slightly harder, but doable.
Examples for 2):
ivi_layout_transition_move_layer would update the size and position of
the target surface.
ivi_layout_transition_visibility_on/off would immediately set the
surface to the requested visibility.
What do you think?
--
John-John Tedro
Examples for 2):
ivi_layout_transition_move_layer would update the size and position of
the target surface.
ivi_layout_transition_visibility_on/off would immediately set the
surface to the requested visibility.
What do you think?
--
John-John Tedro
signature.asc
Description: Digital
On Mon, Sep 21, 2015 at 09:33:29AM -0700, Bill Spitzak wrote:
>=20
> Maybe this should be using xzalloc, that seems to be the standard method =
in
> Weston
Yikes.
It looks like create_move_resize_view_transition (and others?) returns
NULL on allocation failures, which is fed unchecked into
layout
create_layout_transition does not initialize is_transition_func.
This patch initializes it to NULL.
Signed-off-by: John-John Tedro
---
ivi-shell/ivi-layout-transition.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ivi-shell/ivi-layout-transition.c
b/ivi-shell/ivi-layout-transition.c
As a hobby game dev, what follows is a description of my dream input system.
Apart from the existing input protocol...
I would expect Wayland to support a protocol that can enumerate input
devices and discover capabilities regardless of type. What follows that
wayland has a sensible set of i/o pr
