it turns out that it is useful and needed (for future patches) to
request moves for nodes that are not focused currently. It is also
needed to request a move that might end up in a logical node.
so the MAIN loop is actually an efl.app object. which inherits from
efl.loop. the idea is that other loops in threads will not be efl.app
objects. thread on the creator side return an efl.thread object.
inside the thread, like the mainloop, there is now an efl.appthread
object that is for all non-main-loop threads.
every thread (main loop or child) when it spawns a thread is the
parent. there are i/o pipes from parnet to child and back. so parents
are generally expected to, if they want to talk to child thread, so
use the efl.io interfaces on efl.thread, and the main loop's elf.app
class allows you to talk to stdio back to the parent process like the
efl.appthread does the same using the efl.io interfaces to talk to its
parent app or appthread. it's symmetrical
no tests here - sure. i have been holding off on tests until things
settle. that's why i haven't done them yet. those will come back in a
subsequent commit
for really quick examples on using this see:
https://phab.enlightenment.org/F2983118https://phab.enlightenment.org/F2983142
they are just my test code for this.
Please see this design document:
https://phab.enlightenment.org/w/efl-loops-threads/
This reverts commit 135154303b.
Revert "efl: move signal events from efl.loop to efl.app"
This reverts commit 3dbca39f98.
Revert "efl: add test suite for efl_app"
This reverts commit 3e94be5d73.
Revert "efl: create Efl.App class, the parent of Efl.Loop"
This reverts commit 28fe00b94e.
Go back to before efl.app because I think this should be done with
superclassing here not a parent object. reasons?
1. multiple loops per single thread make no sense. so if multilpe loop
objects they wont be contained in a single app object and then deleted
like this.
2. the app object is not really sharable in this design so it cant be
accessed from other threads
3. it makes it harder to get the main loop or app object (well 2 func
calls one calling the other and more typing. it is longer to type and
more work where it is not necessary, and again it can't work from
other threads unless we go duplicating efl.app per thread and then
what is the point of splittyign out the signal events from efl.loop
then?)
etc.
This was proposed by Dave on the ML, I think it makes sense. Right now
the enum is just like the boolean, feature-wise, but it makes more sense
semantically (mode is not a bool) and allows for future extension (eg.
only apply orientation update for landscape vs. portrait modes).
There is absolutely zero testing for this in our existing codebase. Yay.
Summary:
focus_user and focus_object are similar classes. by merging them into
one mixin, we can maintain consistency.
Test Plan: make check
Reviewers: bu5hm4n
Subscribers: cedric, Jaehyun_Cho, woohyun, jpeg
Differential Revision: https://phab.enlightenment.org/D5734
This fixes cycles of init/shutdown/init where ecore event types would
become invalid, since they are now stored in a dynamic array rather than
a statically stored array.
The risk here is that if a module of EFL tends to init/shutdown in a
"normal" scenario then the event type array will grow in a leaking
manner. This could be fixed by resetting those event ID's only when the
loop actually exits (EFL_EVENT_DEL on the main loop). I'm not using
EFL_EVENT_DEL in this patch as this would add too many event callbacks
to the main loop object, which may result in slightly slower event calls
to it, affecting the overall performance.
earlier elm_object_focused_object_get returned gengrid genlist toolbar
objects if a item of them is focused. This should fix that.
thank you @davemds for the report!
we cant go iterating the mainloop before the current point. if someone
set up handlers but hasnt configured the things those handles use yet
as they dont expect them to be used until the mainloop is started...
thenthings break. we cant change this assumption without breaking
things.
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
ecore could not shut down properly in an elm_init()/elm_shutdown()
cycle, with 7 remaining references, all because of a typo.
This should help @cedric as well
This moves the API entry points from Widget to Layout parts. I don't
think the other widgets support translation, but that is easy to fix.
The actual code implementation remains in elm_widget.c.
Legacy-only widgets are covered by Part_Legacy, while all EO widgets
that have text inherit from Layout (except Win but I don't think the
window title was translatable in legacy).
This removes 2/3 remaining part APIs from Widget.
Ref T5363
It's not beta. It's about to die.
Also, move #define ELM_WIDGET_BETA to the common header file, as it is
consequently required by ALL widgets. :(
Ping @bu5hm4n :)
Ref T5363
I was told that the scrollable interface is being redesigned for EO.
This API definitely does not belong to the base Widget class, as it's
quite specific to item-based scrollable widgets, such as lists and
grids. Since Elm.Interface_Scrollable is itself being revamped, it is a
good place to move that EO API for now.
Ref T5363
1. Uniformize the API, which is now for internal use:
This uses the same enum as scroller "movement_block" instead
of 2 separate properties. Less APIs, more consistence.
2. Remove scroll_lock x/y from EO widget. I was told it is not going to
exist in the upcoming scrollable interface.
3. Remove scroll hold/freeze getters.
scroll hold/freeze push/pop are still there but it remains to be seen
how the EO scrollable interface will exploit them. Right now they are
full of bugs.
Ref T5363
This also includes the drag_child_lock APIs. This had nothing to do with
dragging beyond maybe the case where scrolling is done by thumbscroll
(ie. finger drag).
Note that the EAPI were called already scroll_lock, not drag_lock.
Ref T5363
... and others. this leads to crashes if x ops are busy in a thread or
engine evas thread shutdown happens to call engine calls that then do
x calls... should apply in general to wl too. fixes some segv's on
shutdown given the new gl thread patches.
@fix
This is, unlike what some of the documentation says, a public
API on elm_object. Let's place it along mirrored for consistency,
even if edje object will not implement it.
Ref T5363
fix CID 1360466
we don't actually chekc if efreet inits right with elm_need_efreet()
as we just assume it inits (And there pretty much is no case where it
will not), but make coverity happy and check.
@fix
This reverts commit 57d77c9041.
We are in freeze right now and this is a new feature. Considering the access
API is still in beta I might have let this slip by but its does not even build
../../../src/tests/elementary/elm_test_popup.c:27:1: error: conflicting types for ‘elm_object_part_access_object_get’
START_TEST (elm_object_part_access_object_get)
^
In file included from ../../../src/lib/elementary/Elementary.h:240:0,
from ../../../src/tests/elementary/elm_test_popup.c:6:
../../../src/lib/elementary/elm_object.h:521:54: note: previous declaration of ‘elm_object_part_access_object_get’ was here
EAPI Evas_Object *elm_object_part_access_object_get(const Evas_Object *obj, const char *part);
^
../../../src/tests/elementary/elm_test_popup.c: In function ‘elm_object_part_access_object_get’:
../../../src/tests/elementary/elm_test_popup.c:39:47: warning: passing argument 1 of ‘elm_object_part_access_object_get’ makes integer from pointer without a cast [-Wint-conversion]
access = elm_object_part_access_object_get(popup, "access.title");
^
../../../src/tests/elementary/elm_test_popup.c:27:1: note: expected ‘int’ but argument is of type ‘Evas_Object * {aka struct _Eo_Opaque *}’
START_TEST (elm_object_part_access_object_get)
^
../../../src/tests/elementary/elm_test_popup.c:39:13: error: too many arguments to function ‘elm_object_part_access_object_get’
access = elm_object_part_access_object_get(popup, "access.title");
^
../../../src/tests/elementary/elm_test_popup.c:27:1: note: declared here
START_TEST (elm_object_part_access_object_get)
^
../../../src/tests/elementary/elm_test_popup.c:39:11: error: void value not ignored as it ought to be
access = elm_object_part_access_object_get(popup, "access.title");
^
Makefile:43996: recipe for target 'tests/elementary/tests_elementary_elm_suite-elm_test_popup.o' failed
make[5]: *** [tests/elementary/tests_elementary_elm_suite-elm_test_popup.o] Error 1
If you still want this in make sure it actually can compile the tests you added.
Summary:
if trying to apply incorrect theme, widget apply default theme and return TRUE.
so there is no way to check it really apply correct theme.
To resolve this problem, _elm_theme_set return three type enum
* related history : 4ca3ef4514
* elm_object_style_set is public api, so I didn't change it.
* typedef name [ Theme_Apply ] is temporarily, please suggest better one.
@fix
Reviewers: singh.amitesh, herb, Hermet, cedric, jpeg, raster
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4073
Summary:
evas_common_language_from_locale_* functions kept static pointers
inside of its functions. Once these function was called, it was never reset.
It made big problems for harfbuzz and hyphenation. Also, Elementary
provides elm_language_set() API. Then we need to support it fully.
@fix
Test Plan: Test case for hyphenation is included in Evas test suite.
Reviewers: raster, tasn, herdsman, woohyun, z-wony, Blackmole, minudf
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3864
this now allows vpath files to be looked uop using app directory
resources like @app.data/file.jpg ... if the object uses vpath to do
its hunting.
@feature
Mike Blumenkrantz
junsu choi
Marcel Hollerbach
Xavi Artigas
Cedric BAIL
Carsten Haitzler
Jean-Philippe Andre
Yeongjong Lee
Amitesh Singh
Marcel Hollerbach
Vincent Torri
Daniel Zaoui
Andy Williams
Tom Hacohen
Stefan Schmidt
Chris Michael
Shinwoo Kim
Jinyong Park
Ji-Youn Park
Youngbok Shin