Reasons:
- This API has been confused with the min size of the widget, resulting
in badly laid out applications.
- The EO API was not very nice (Range is about numbers, the Gfx size
hint in a part is really ugly).
While I understand the value of this API and how it can be used in
scalable applications, it is in fact not absolutely necessary.
Alternatively to that span size, the widget min size can already be
defined from the application side, or the widget can simply be expanded
to fill in its parent.
This can obviously be reinstated later if the need arises for EO. For
now, keep this feature as legacy-only.
I think this closes the orientation vs. direction problem.
RTL vs. AnyRTL is not fully handled yet but this becomes a
widget-per-widget issue (eg. should a box in a RTL locale be mirrored if
set to horizontal?).
Fixes T5870
Summary:
without it, it was failing with following error
/usr/bin/ld: /tmp/ccnjRcVr.o: undefined reference to symbol 'evas_object_move'
//usr/lib64/libevas.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Test Plan: just try to compile it with and without.
Reviewers: jpeg
Reviewed By: jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5182
Summary:
Fill in the intro section and the first test mode. (Docs for second
mode will be forthcoming.)
Also drop some of the generic comments that are already explained better
in some of the basic examples.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5201
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
For this patch I decided to add a pseudo legacy wrapper as the function
is called in a very large number of places. Fixing all those calls to
use the size2d form is a lot of work and a greater risk of b0rking
something.
It's a complex struct but defined in EO as a simple struct. ABI-wise
it's equivalent to Eina_Rectangle. Some macros that use Eina_Rectangle
also work on Eina_Rect out of the box, most of the code dealing with
x,y,w,h will require no modifications either.
But Eina_Rect provides direct access to a size or position 2d component,
as well as the usual x,y,w,h. The field "rect" is provided as a
convenience for code dealing with both Eina_Rectangle and Eina_Rect. We
may or may not require it.
Note: Size2D could use unsigned values but I have spotted a few places
in the code that actually use -1 to indicate invalid size (as opposed to
0x0).
@feature
Introduced with commit 13da5e980eb43288b9b9f502cb6a7a000e1f26ea
A compile before pushing would have been great, again.
Having the same name for two variables is something no compiler likes.
evas-map-utils-eo.c:74:8: error: conflicting types for ‘r’
int r, g, b, a, f;
^
evas-map-utils-eo.c:73:19: note: previous declaration of ‘r’ was here
Eina_Rectangle r;
^
evas-map-utils-eo.c:93:31: error: ‘h’ undeclared (first use in this function)
efl_gfx_size_get(o, NULL, &h);
^
evas-map-utils-eo.c:93:31: note: each undeclared identifier is reported only once for each function it appears in
evas-map-utils-eo.c:108:25: error: ‘w’ undeclared (first use in this function)
efl_gfx_size_get(o, &w, &h);
Some names have not been changed, hopefully making a distinction
between legacy APIs and internal code (elm_layout_blah) and valid EO
usages.
This means many internal functions are still elm_layout_ as their
sole purpose is to support the legacy API.
Ref T5315
Summary:
The evas-transparent.c example is quite short, and so will allow for
more detailed explanation of setting up Ecore-Evas. Then
evas-object-manipulation.c can focus more on the explanation of objects
in Ecore-Evas.
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5011
Summary:
This is one of the basic examples that introduces Ecore-Evas, so needs
to be more detailed in commentary than other examples. It also points
out the use of the legacy API and directs the reader to the Eo example
where appropriate.
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5008
Summary: ecore_main_fd_handler_add is not working on Windows
Reviewers: vtorri, raster
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4470
1. The word "class" is a pain point with many languages where
it's a keyword. Type is a little better. Also, the property
was already named "device_type" and not "device_class".
2. Remove Efl.Input.Device.Sub_Class
It's not used inside EFL upstream codebase, and unlikely to
be used anywhere else (even in Tizen).
Hopefully no one used the Efl_ enum types. So far only the Evas_
types should be in used.
Ref T5540
Those are now merged with Efl.Object parent, name and comment.
The reasoning is that only seats can be parent devices; And name
and description are not only name clashes but also not extremely
useful anyway.
Tested with VNC.
Fixes T5540
Summary:
This serves as an early example for new Evas programmers to introduce
the buffer engine as well as very basic canvas usage, so we're going
into a lot more detail for both of those than we'll do in subsequent
examples.
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4950
Cedric BAIL
Jean-Philippe Andre
Stefan Schmidt
Bryce Harrington
Felipe Magno de Almeida
Daniel Zaoui
Guilherme Iscaro
smohanty
Vincent Torri
Lauro Moura
Jeeyong Um
Andrii Kroitor