We use a temporary file for espeak (the accessibility text-to-speech
engine we use), and then we remove and close the file. But the fd was
not reset to -1 which meant that later on the previous fd was closed
again (this is kinda weird), but that fd was now invalid. Or rather it
was reused by ecore animator, closing the read-end of the pipe
(timer_fd_read). This caused SIGPIPE in the animator code.
Thanks strace and gdb for helping me figure out this. :)
@fix
This fixes a case where an object is hidden before the first render.
When called from elementary. the visible intercept code would be called
before evas object's visible_set, bypassing the line setting visible_set
to true.
As a consequence the object would be visible even when explicitly
requested as hidden.
Thanks @JackDanielZ for the report!
This is also another protected and beta API. Meant to be overridden by
subclasses, but belongs to a still unstable API.
The difference between the internal legacy and the EO API is really bad.
Same as with activate (previous commit).
Ref T5363
Renamed to on_disabled_update.
Also passed in the new state of disabled. It's more convenient this way,
than having the subclasses call disabled_get.
Also simplify some code...
Ref T5363
Renamed to on_orientation_update
This internal / virtual function is in fact not overridden anywhere. Not
sure it is necessary to expose it in EO API?
Ref T5363
a nested compositor will have a mismatch between canvas seat id and
compositor seat id, so this attempts to perform matching based on the
order that they are listed, which should be identical
@fix
gl_generic_context_find() returns the gl shared context struct but
this is not just a read-only operation. It in turn calls window_use
which may call make_current. This can invalidate the work of evas gl
when the API tried to switch to a specific context.
This fixes evas gl with multiple outputs.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
For now, do not use Evas_Canvas3D in multi output context, it won't work.
The update code for Evas_Canvas3D_Node might trigger rendering logic, which
is opposite to what the scene graph logic should do. It require to much
reshuffle around to handle that case at the moment. So I am just adding a
warning.