Gcc complains here due to _wl_default_seat_id_get not accepting a
'const' Evas_Object, so to avoid the warning just case it to a normal
Evas_Object when passing in.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
otherwise we get a complaint for everty time some audio needs/wants to
play and that's just noisy and ugly, so only do it once - the first
time sndfile/pulse are being loaded and it fails.
Send visible/hidden signal when text/content are realized.
This feature is already implemented in genlist widget,
for reacting dynamically in item layout depending on their
text/content realizations.
we can't sensibly use things like massif to track memory if we bypass
itr with mmaping -1 fd anonymous memory... so if built with valgrind
support and running under valgrind, use malloc/calloc and free so
these tools actually do something useful for these bits of memory.
osmesa needs llvm. llvm apparently just by dlopening or linking to the
lib (libLLVM...) gets you 3.5mb of dirty pages just in this lib. that's
a whole lib entirely dirty pages. odd and horrible. in fact once i
stoppd dlopening OSMesa all the time on engine init (and only when gl
is needed)... the amount of dirty pages went from 17208 to 8860.
that's a whopping drop of 8mb! 8mb saved! in fact just dlopening
osmesa and doing the other gl init stuff led to more anonymuse
mappings with dirty pages. 2 of them (2072k and 2076k) which baffled
me as that didn't seem like heap or efl's own data. these disappeared
along with libLLVM-5.0.so (3520k + 60k dirty pages). we stopped
linking/loading libedit (12k dirty), libglapi (20k dirty),
libLLVM-5.0 (3580k dirty), libncursesw (72k dirty),
libOSMesa.so (260k dirty), libtinfo (20k dirty). ... or at least
stopped until absolutely needed. total 17208k of dirty pages went down
to 8860.
my test case was just launching terminology (and doing nothing with it).
@fix memory bloating
evas_canvas_default_device_get used here leads to an 'implicit
declaration of function warning'. Use evas_default_device_get instead
to remove warning.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
remove thread code since osx is not happy with threads trapping
signals (or at least a thread setting up the handler and trapping
there with signal blocks...). this should now work universally.
Summary:
we can consider that the node is freed during focus_manager routine.
for example, efl_ui_focus_manager_redirect_set call edje event callbacks,
and a application can delete a object in the edje callback. if the object is
the focusable object of a node, focus_manager make the node freed.
the focus_manager is able to use freed node. (a good example is test_popup.c)
this prevent reusing freed pointers.
Test Plan:
1. elementary_test -to popup
2. popup-center-text + 1 button
3. Click the Close button
4. check that there is no erroe message
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric, woohyun, jpeg, Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5729
we used to do signals on main loop. keep doing. the pipes should work
in cleanly serializing the signals irrespective of when/where they are
caught (because we do into kernel and back out again). hoping this
makes osx work again. can't test as i have no osx box or vm. works on
linux and freebsd though.
Summary:
Short/middle term: use UTF-16 on Windows.
So I plan to remove most of external API (like dirent in Evil) and use only EFL to have less work later
Test Plan: compile and run elm_test
Reviewers: jpeg
Subscribers: raster, cedric
Differential Revision: https://phab.enlightenment.org/D5731
The platform check was added for systems (like ARM) that don't generally
have PCI graphics devices. However, now we pick a fallback device that
doesn't have a PCI constraint, so the platform check should no longer be
necessary.
Summary: This is a tweak to c264ef264f for D5712 . chosen_dev in the loop was only being set for DRM devices attached to PCI devices. While this is useful for determining if the device is the preferred boot_vga device, There is no apparent requirement (comparing to Weston) for all DRM devices to be attached to a PCI device. (This is considering USB DisplayLink devices. I am not sure how the parent device tree is with these...)
Reviewers: devilhorns, ManMower
Reviewed By: devilhorns, ManMower
Subscribers: cedric, jpeg, #efl
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D5727
Triggered after (almost) complete destruction of the object.
Not called "deleted" because the other event is already "del".
I don't like "destruct" much but this follows the terminology of
"constructor" / "destructor".
@feature
If we are Not using Atomic/Hardware support for output rotations, we
should return all available rotations as these will still work in
software mode.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Commit 9d583b3fdb broke
ecore_drm2_output_enabled_set function due changing order of setting
output->enabled value. This patch fixes both issues by checking the
'enabled' variable being passed in.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
The default backend overrides this operation depending on the fill color
but the cairo backend dosen't hence cairo will always use bled mode while drwaing the vector.
Reviewers: jpeg
Subscribers: vtorri, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5724
this willonly apply to the main loop, but to be able to see these
signals as callbacks, we have to expose them. term/quit/int are
already handled internally where the loop will terminate (efl will
enforce this) AND ... there is a terminate event already on the loop
to deal with this cleanup. other signals really arent applicable IMHO
except usr1/2 and hup.
so xine module plus 2 eina dbug threads didnt set up signal
blocking/masks correctly. xine use ssigprocmask not pthread_sigmask
and the other 2 didnt even bother at all. fix this so these threads
all block most of these commnly caught signals so these threads never
get them
In a multi-seat configuration it's quite likely that only one
seat will have a boot_vga device.
While we should use the boot_vga device if possible, we shouldn't
fail just because a seat's gpu isn't the boot_vga device. Fallback
to the last viable drm device we saw.
Reported-by: n3rdopolis
ref D5712
ref T6455
Added a new test "Focus 6", it's an not very
complex elm layout: a swallowed genlist and three
buttons in an edje box.
You should be able to navigate the layout with
just the keyboard, that is currently impossible.
With the help of the mouse click you can randomly
make the key navigation work again... this is
mostly random.
...should help to make progress on T6453
add efl_main_loop_steal() and efl_main_loop_release() for new efl
namespace versiosn of ecore_thread_main_loop_begin() and
ecore_thread_main_loop_end().
Summary:
clicked event will be called when alert popup's button is clicked.
But usually, clicked event means when object is clicked, not sub object is clicked.
So it is so ambiguous, event name change.
Test Plan:
1. elementary_test -to efl.ui.popup.alert
2. click button.
Reviewers: Jaehyun_Cho, herb, jpeg, cedric
Reviewed By: Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5722
see c8dcc4327b803e9b8ad2a0985e756c924946c442 - basicall evas depends
on ecore these days... thus requires ecore be initted THEN evas. ...
which in theory is an abi break for those using evas and ONLY evas
long ago from when efl was separate... but it''s how we're building
these days.
@fix
because as of... i don't know when, evas relies on ecore with
ecore_pipe_add to create the async fd... and if you init evas then
ecore this doesnt work. obviously. well now it isn't working. probably
due to new efl loop work. but the efl loop code is correct.
ecore_pipe_add should never work until you init ecore... it just
happesn to have managed to be gotten away with for a while.
@fix
Gcc issues a warning here that 'main' is usually a function, so just
rename the variable to avoid the warning.
NB: No funtional changes
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
efl_ui_popup has needs_size_calc flag
to skip size calculation when it is not needed.
But efl_ui_popup_alert_text/scroll do size calc although that flag is FALSE
Test Plan:
1. elementary_test -to efl.ui.popup.alert.text
or elementary_test -to efl.ui.popup.alert.scroll
2. resize window
3. watch _sizing_eval call
Reviewers: Jaehyun_Cho, herb, jpeg, cedric
Reviewed By: Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5720
This reverts commit f910ba248e.
The scheduler is meant to be used only in C, not by bindings so there isn't really
a use for it in the loop class. Now this patch was triggered due to complexity in
using future/promise, so will do a follow up patch to improve that.
This is (in my mind) meant to replace the current elua generator.
Currently the generated output is pratically identical to the elua
one, just some little difference here and there, some for thecnical
reasons and some just for my preference.
I consider this work just a starting point, extending the
templates we can now easily improve our docs. Whithout the need
to touch a single line of code.
Really I think this is a great improvements, and this are some
numbers to prove it:
Current elua implementation:
4185 lines of code in 7 lua files
generation time: ~ 7 seconds
New generator:
115 lines of python + 513 lines of templates
generation time: ~ 8 seconds (can be optimizd ALOT)
To generate the full Efl.* docs just run "./gendoc.py -v" in this folder.
...will wait for reviews (in particular from @andy and @q66)
elsewhere in efl we moved to pthread_sigmask but eina debug didn't, so
mirror the changes here too. at this point in time when we are
initting eina debug this shouldnt really matter much as we're single
threaded until this pthread_Create is called. after that tough...
we're not. signals + threads is a nightmare though... horrible
horrible...
../src/benchmarks/eina/eina_bench_sort.c: In function ‘eina_bench_sort_eina’:
../src/benchmarks/eina/eina_bench_sort.c:52:10: warning: implicit declaration of function ‘time’ [-Wimplicit-function-declaration]
srand(time(NULL));
Found due to the nice quite build output in our meson feature branch.
This is a really powerfull tool that can be used to generate anything eolian
releted just providing a template file. You can then render the template
with the wanted scope (class, namespace, enum, etc)
For example give a try at this (from the src/srcipts/pyolian folder):
./generator.py test_gen_class.template --cls Efl.Loop.Timer
or ./generator.py -h for the full help
Next step: maybe generate the new efl API doc using this tool?
@andy I think this will make your life much easier :)
This are manually written ctype bindings for eolian, that means they
run on the standard python library (nothing to install) and can run
without any build step (in fact ctypes just open the so/dll file at runtime)
Next step will be (soon) a template based generator for eolian that will
be a lot of fun :)
also eina_procmis was not threadsafe so cannto use loops in different
threads at all until this was made safe. needed to disable the old
ecore_event using code in for ecore futures and create a new efl loop
message future and handler instead ... but now a quick experiment with
multiple loops in 10 threads plus mainloop have timers at least work.
i need to test more like fd handlers etc etc. but it's a step.
stop using the legacy ecore_loop_time_get() func when it should be
coming from the loop object's loop time. also ecore_time_get should
never fall back on ecore_loop_time_get for similar reasons.
part of making the ecore/efl loop a non-global instance (allow loops
in threads)
so loop object destruction was clearing out fd handlers but those may
be later deleted by destructors of child objects. so leave legacy
fdh's and just remove them from the list
This makes sure that duplicate method/part/etc checks are done on
every database update, removing the need for clunky toplevel
checks and improving reliability. It also sacrifices some
performance but it shouldn't be too bad (if a class is already
validated, some checks are avoided to speed things up).
This has been bugging me for some time but now we are triggering new errors internally
this is appearing to end users for problems they did not cause.
Additionally I was able to improve a couple of the errors by copying the
explanation from code comments into the error message.
Shorter error logs now too :)