Summary:
It should return width and height with positive values or zero.
@fix
Test Plan: make check
Reviewers: raster, jpeg, cedric
Reviewed By: raster
Subscribers: jiin.moon
Differential Revision: https://phab.enlightenment.org/D5422
Apparently this isn't well supported by dash, which will print an
error and return a 2, where zsh and bash will return 255.
Explicitly returning 255 seems least surprising.
see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772322
#IHaveNoIdeaWhatThisScriptDoes
This disallows deeply nested pointers, you can only explicitly
ptr() on types that are strictly value types.
For a few cases where it was necessary to override this behavior,
you can use legacy(ptr(x)) as a temporary measure.
As we do not know when a window won't be able to tick, and we do
not know which window a legacy animator is attached to, we require
all windows to tick as often as they can and only generate one tick
per loop run.
This might need more adjustement especially with multi output.
It is not because a round of rendering happen for a child, that it result in
actually drawing anything in the parent. The parent will always be aware of
the rendering request of the sub surface and we should only track what the
parent think.
T6049
Tested-by: Derek Foreman <derekf@osg.samsung.com>
Summary:
This uses constructor/destructor instead of group_add/group_del.
Note: finalize can't be used for theme loading as any action done
inside
efl_add(...) would be lost (eg. part text set).
Test Plan: 1) run elementary_test -to radio
Reviewers: jpeg, woohyun, cedric
Subscribers: akanad
Differential Revision: https://phab.enlightenment.org/D5404
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
If we pass in screen geometry here when trying to set an output mode,
we can encounter "out of memory" errors from libdrm with outputs
that have a high resolution. As it turns out, we should be passing 0, 0 for
the x/y values when trying to set an output mode.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This prevents legacy EO classes from being exposed through .eo.h headers
or .eo in share/eolian/includes. Also removes a slew of useless xxx_eo.h
intermediate headers.
Notes:
- elm_systray has no proper API: it's not clear if the EO API should be
released (in which case it needs to be renamed to efl_something) and
there is no legacy API to create a systray object.
- Some files have been placed in a "FIXME" section, as I believe they
are necessary within EO land, but at the same time still don't
conform to the interfaces (eg. name starts with elm_).
- elm_interface_scrollable is required by photocam. This means photocam
needs to be adapted to fit the EO scroller API (still to be
completed, I believe).
Bugs:
- This breaks most C++ examples. I KNOW. And I'm working on it.
Ref T5301
This is a "pass by reference to const" equivalent. There is no explicit pointer
and currently it's the same as ptr(const(x)) on the type. However, it is also
usable on properties.
Summary:
**@feature** T6241
This feature enables genlist to pin an item to viewport which will
be available always for user to view/select.
**Use Case**:
In a big list of music, most times when user finds a song which they
like, before playing that they may want to go through the entire list
to check whether there is some other good songs, but
after seeing the entire list user have to again scroll back to the
position of item which they liked to play it then.
In this case item pinning can be used, so that the item
which they want to keep for future selection can be pinned
and then it will remain in viewport, finally when user want to do
operation on item, it will be readily available in viewport.
Signed-off-by: Godly T.Alias <godlytalias@yahoo.co.in>
Test Plan: Elementary Test -> Genlist -> Double click on items to enable/disable pinning
Reviewers: raster, cedric, prince.dubey, SanghyeonLee
Subscribers: rajeshps, jpeg, shilpasingh
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D5340
Summary:
There are wrong annotation about version and wrong enum name
so fix that.
Reviewers: jpeg, cedric, akanad
Differential Revision: https://phab.enlightenment.org/D5403
This isn't meant to be installed. The canvas API in EO is based around
the interfaces Efl.Canvas and the widget Efl.Ui.Win. Anything else is
not EO (eg: ecore_evas, evas, ...)
Note: evas_canvas3d is the last remaining thing that is installed along
EO files, but those are all beta APIs.