so dropping a bit of overhead/latency for e menus here - this isn't to
the extent of a cache for menu objects/items... but it's just nuking
useless calls to do things not used or that can be done in fewer calls
as well as ordering things to we don't emit events and handle them
multiple times or calc min size multiple times etc. etc. -
adds a test case we can enable for perf testing too.
found a valgrind issue and an input issue all in one... this fixes
that with no more valgrind complaints and input works if e menu is up
whilst desklock kicks in.
@fix
hold mode is where if u hold mosue down menu stays only as long as
mouse is held down... then dismissed on up. doesnt work well when youa
re trying to overload a single click with longpresses and so on -
optionally turn it off. used in gadgets.
Summary:
evas functions
This fixes an issue when quickly mousing through menus can cause a
segfault in Enlightenment due to menu->comp_object being NULL
ref T7030
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric
Tags: #efl, #enlightenment22
Maniphest Tasks: T7030
Differential Revision: https://phab.enlightenment.org/D6641
Summary:
these are all harmless but will trigger error messages from efl
ref T7030
Depends on D6315
Reviewers: ManMower, devilhorns
Reviewed By: devilhorns
Subscribers: cedric
Tags: #enlightenment-git
Maniphest Tasks: T7030
Differential Revision: https://phab.enlightenment.org/D6316
there were recent changes to evas object deletion mechanics which caused
this to begin crashing due to recent changes to evas object deletion mechanics
these are all cases where bindings should fail to activate in order to
avoid interfering with current operations
also fixes an issue where attempting to add or modify an existing
mouse/key/wheel binding would fail as a result of that binding activating
while the grab dialog was active
remove menu object from autoclose (if set) and ensure that only the
intended menu is deactivated in the autoclose callback
this fixes some cases where the wrong menu could be closed (or not closed)
due to race conditions with ecore and evas events
_e_menu_realize was trying to swallow the menu->container_object into
the menu->bg_object, but the menu->bg_object was being created on the
compositor canvas, and the container object was being created on the
e_comp->elm_win.
With recent EFL changes, this causes an abort inside Evas.
To fix this, set the menu->evas to be the Evas from the e_comp->elm_win.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
this has been in e for ages - someone not noticed, but this fixes
visual artifacts of left over menus on the top-left. this extra ref
really makes no sense. it's not like this ref is then accomoanied by a
matching unref somewhere else (after much debugging).
@fix
Summary:
Remove an unnecessary comparison.
It fixes coverity CID 1291841 Same on both sides.
@fix
Reviewers: raster, devilhorns, zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2523
sometimes while quickly moving the cursor through menu items with submenus
the visibility flag would toggle more quickly than the menu object's visibility.
this is no longer the case
Summary: add the condition check code if the pressed key is not in range of menu items
Test Plan:
(1) Left-click on the desktop to bring up the menu.
(2) Press down the number key to activate the menu item.
(3) When you press down the number key that is not in range, you will see the segmentation error.
below is the crash log which I encoutered.
-------------------------------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
_e_menu_item_activate_nth (n=n@entry=5) at src/bin/e_menu.c:2318
2318 _e_menu_item_ensure_onscreen(mi);
Reviewers: zmike, gwanglim, raster
Reviewed By: raster
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1845
so e is using eo... and something in eo changes... and e fails to
compile entirely.... there are hacks to use eo... and this is not good.
eo is still in a beta state. that means any usage of it can (and
will) break. this is a problem for e. if e uses eo, then eo breaks in
an efl upgrade, e breaks. we can't really have that. we already hit
this problem in terminology with the app server code in elm. so let's
just not use eo in e until it's stable.
this removes eo usage in all places, with the e_menu code having a
small isedje() func due to some of its code paths doing special things
based on if the obj is an edje one or not as opposed to just a simple
"only emit if its an edje obj".
this was a neat experiment, but apparently it's not going to be usable for a long time in anything outside efl/elm
This reverts commits f87b9900fa, a49cede790, 81038f8d02, 47cfb31752.