| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
and move elm_slider_step_set/get() as legacy APIs.
|
| |
|
|
| |
fix return val if cache is null (something bad happening)
|
| |
|
|
|
|
|
|
| |
ok. i can't find the root cause because all i have is a backtrace from
ApBBB and he says he can't reproduce it and i know im->cache is
null... if i could reproduce ... i'd be hunting the root cause. but
the best i can do is check for null im->cvache ptrs and be safe.
crashes are bad. especially for end users.
|
| |
|
|
|
|
| |
Reviewers: cedric, raster
Differential Revision: https://phab.enlightenment.org/D5831
|
| |
|
|
|
|
|
|
| |
Seems Linux would munmap a lump of coal without failing. Make
sure the pointers match. Again bogus unmap not detected by
valgrind and not failing.
@fix T5949
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
so there is something broken in the complect efl promise/loop promise
that the clear of promises on loop destroy is clearing
promises/futures that have already triggered (loop timer ones). i've
spent enough time figuring out that it is happening.
_efl_loop_timeout_del() simple doenst ensure the future in
pending_futures for that promise is removed from the list. getting the
future from the promise handle is an exercise in pain... so i'm not
continuing with that path and will just ignore it.
but for now filling the promise data with null at least means if the
menory is re-used after free it wont see garbage freed ptrs and get
nulls so its easier to track.
|
| |
|
|
|
|
|
|
|
| |
1 test was wrong. it didn't wait for the thread to exit before checking
msg count recieved. fixed. race condition here.
also reduce the sheer message counts sent - it makes the suite take a
lot longer than is sane and als consume massive amounts of log space
in /tmp as a result.
|
| |
|
|
|
|
|
|
|
|
| |
rthe ecore file download test was downloading from sf.net ... and i
noticed sf.net refusing thus the ecore tests suite failing... i
changes it to grab a file (rss.php which is disabled for us but there)
so at least enlightenment.org has it.
better would be to spawn a webserver and test against that locally.
but thats a whole other level of work.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
so it was listening for cb adds and dels... and or del of any cb
except the cb add/del catcher was done.. it would fail...
but ... the test actually added other cbs than this ... like:
efl_event_callback_array_priority_add(obj, _eo_signals_callbacks(),
-100, (void *) 1);
a while array of cb's:
{ EV_A_CHANGED, _eo_signals_a_changed_cb },
{ EV_A_CHANGED, _eo_signals_a_changed_cb2 },
{ EV_A_CHANGED, _eo_signals_a_changed_never },
{ EFL_EVENT_DEL, _eo_signals_efl_del_cb });
none of which were _eo_signals_cb_added_deled. i am amazed it passed
before...
now switch its checks to check for itself and then check for anything
BUT itself...
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/F2983118
https://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 135154303bea691c6f7f9472a5dec32d9103c38d.
Revert "efl: move signal events from efl.loop to efl.app"
This reverts commit 3dbca39f98288580c62a43c179ac11621433ec88.
Revert "efl: add test suite for efl_app"
This reverts commit 3e94be5d73256a7f5c02d3a9474173226be7beff.
Revert "efl: create Efl.App class, the parent of Efl.Loop"
This reverts commit 28fe00b94e55575c15684959b89a614d5a579309.
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.
|
| |
|
|
| |
Closes D5829.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
with adjusted tests
|
| |
|
|
| |
Also updated tests, generator and gendoc accordly
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d764e0b2790b322778e6db80932c168ae0d43b96.
The whole idea of renaming the default theme is an "api break" even if
config is changed. and symlinks don't work on windows as a solution.
(well on ntfs only as only as administrator, so they don't exist).
modifying config for switch from default to dark also will break the
case where someone put ~/.elementary/themes/default.edj there and it just
is different to the system one and how their theme changes on them as
it switches to dark.
basically we can't rename a theme like this mid-flight in efl. default is
default and has to stay that name. it can change the look, but not the
name.
i think the apparent reasoning behind this is not a good one. the work on
flat is temporary. i don't think we will ever maintain multiple "default
themes" as its just far too much work.
we can maintain color SCHEMES which are just a list of colorclasses and
colors for them - that's separate to a theme and would override. right now
these things don't exist. we are not going to create a dark.edj and a
light.edj just to store differing default colorclass values. we should be
doing the above with colorclass "color palette/scheme/whatever" files
that override those named colorclasses globally on init.
so reverting because this is an api break and we shouldn't break api
unless there is really absolutely no other choice.
here the choice is to just temporarily work in a branch and modify
default and then merge the branch when done.
|
| |
|
|
|
|
|
| |
On linux we can do this test without firing a SIGILL and trapping it,
if getauxval() is present.
ref T6711
|
| | |
|
| |
|
|
| |
put some small effort into preventing the user from destroying their config
|
| |
|
|
|
|
| |
this inhibits maintenance and development of multiple stock themes
a symlink is created to 'default.edj' to preserve compatibility
|
| |
|
|
|
| |
loading the system profile only works if the current profile has the
same name as a system profile
|
| |
|
|
|
| |
if done properly, this should never occur, but at least find some
layout to use if one is available
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
after this commit, efl base themes should now specify:
data.item: "efl_theme_base" "theme_name";
and overlays/extensions which match a given theme should use:
data.item: "efl_theme_match" "theme_name";
this will cause overlays and extensions with the data.item to only
be loaded when the corresponding theme is in use. note that this
should not be specified for theme-independent overlays/extensions
as it will completely block loading of themes
|
| |
|
|
|
| |
the "default" style fallback code here was identical, so just call again
with "default" instead of copy and pasting the same code
|
| |
|
|
|
|
|
|
| |
instead of maintaining separate lists for the file and the edje file,
maintain a single list of structs containing both of these
also dynamically manage a string list of files to preserve compat with
existing (bad) functions which return this directly
|
| |
|
|
|
|
|
| |
for whatever reason this is only generated in elm_theme_get(), so call
that whenever doing theme string parsing
@fix
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this uses the just-added "id" property to allow referencing images
by name from that theme. example:
=FILE1=
id: "myfile";
images.image: "someimage.png" COMP;
=FILE2=
requires: "myfile";
images.image: "someimage.png" EXTERNAL "myfile";
FILE2 will now load someimage.png from FILE1 at runtime if FILE1 is
currently opened in edje, and FILE1 will be kept open until FILE2 is
closed
@feature
|
| |
|
|
| |
this can be used by edje files to identify themselves
|
| |
|
|
|
| |
a lot of this was unreadable due to mixed tabs/spaces or just random
formatting
|
| |
|
|
| |
no functional changes, just a confusing define rename
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit fb01a697dd099f17a6a30c74781b6cfeb72bc512.
The problem this commit was anticipating never happened.
Now the next version of wayland will allow us to make protocol symbols
private, so it makes more sense to have this stuff back where it was
in the first place.
|
| |
|
|
| |
Also fixed a declaration error from previous commit
|
| | |
|
