When I first implemented the Efl.Container interface I made a mistake of
mixing "single slot" content API's with "multiple children" content
API's. This should fix that, by separating API's that are for a single
part and those that deal with a list of children.
Efl.Content: Single slot. This will be used a lot by efl_part()
objects, and for the default content of widgets (eg. the window
content).
Efl.Container: Multiple children. Used by lists, boxes, layouts
(edje/elm), etc...
I didn't see any class that implemented both interfaces (note: Layout
implements Container and Button implements Content, so technically
Button implements both through inheritance).
For now the eo_prefix is not changed in Efl.Container. I wonder if it
should be reset (to efl_container) or not. This would only affect the C
API.
Ref T5328
Note: this is C only, not legacy only.
The problem is that bindings will hold a strong reference to the window,
which will then die "under the rug" if autodel is enabled. This then
leads to at least ERR if not crashes.
Note:
elm_policy needs to support autodel and quit on last del only for C
applications. Bindings will require some other mechanism that doesn't
break all assumptions wrt. references.
The fix is not complete. We need to make efl_part() work nicely in C++:
- Get the refs work properly (maybe without auto-del)
- Generate the parts from the EO file as methods on the object
Final form should be close to:
slider.indicator().format_string_set("%1.2f");
Where everything autocompletes nicely :)
Summary:
9d2dcd92 requires elocation to build.
cxx examples still broken due to elm cleanup
Test Plan: make examples
Reviewers: jpeg, felipealmeida
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5426
make examples now builds all c++ examples but some of them are in fact
empty skeletons. Those either need some c++ love or the final eo api to
be ready (eg. menu, popup, ...).
I removed some examples that don't have an exact equivalent in EO since
the widget is legacy only.
This is more of an experiment than anything else.
@felipealmeida I would like to know what you think.
Notes:
- events still need a better API (event_add isn't part of the object
definition...).
- references are an issue, when you want to actually delete an object.
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.
Summary:
Currently user ask for the root_node from the evas_vg object and then attach its tree by setting the root node as parent.
With this change this process will be explicit. user has to set the root node to the evas_vg object and the object will take the ownership
of the tree. User can query the current vg_tree by root_node_get api.
Test Plan:
Fixed the test app to reflects this change.
Reviewers: jpeg, cedric
Reviewed By: jpeg, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5347
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
eina_strbuf_append_strftime()
eina_strbuf_insert_strftime()
eina_strbuf_prepend_strftime() - macro
We need these functions for implementing generic format function
interface especially for calander.
Ref T6204
Summary: We should define the windows version before including evil.
Test Plan: Run make examples on windows newer than XP.
Reviewers: vtorri
Subscribers: jenkins, cedric, jpeg
Tags: #efl, #windows
Differential Revision: https://phab.enlightenment.org/D5261
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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 13da5e980e
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);
Lauro Moura
Jaehyun Cho
Jean-Philippe Andre
Daniel Kolesa
Amitesh Singh
Prince Kumar Dubey
subhransu mohanty
Cedric Bail
Subodh Kumar
Stefan Schmidt
Bryce Harrington
Felipe Magno de Almeida