Summary:
We move the creation of the popup to a timer to let double left click
event occur. This timer is set to the current double click time value.
@fix T354
Reviewers: zmike, devilhorns
Reviewed By: zmike
Subscribers: cedric
Tags: #enlightenment-git
Maniphest Tasks: T354
Differential Revision: https://phab.enlightenment.org/D7568
now right click on any gagdte in bryce and they ALL have a menu that
allows removal of the gagdte bar or the gadget as well as access to
gadget settings AND the ability for gadgets to extendthis menu like
lunhcer does per icon. now it's standard behavior everywhere which is
much easier to use and discover. it also removes code from every
gadget to do their own "button 3" handling as its handled centrally
making the code in gadgets simpler.
this is part of my effort to improve usability (mostly discoverability
and accessibility of settings/features).
also long press left mouse gets u gadget right click menu
this has to move many modules/gadgets actions to mouse up instead of
mouse down so the bryce has a chance to trap the events first and set
hold flags. but now long press for 0.5 sec and bryce menu come sup
(with left mouse .. so touch friendly).
in addition move context menu hanbdling to e_gadget instead of in
bryce and in e_gadget. a context callback is called so different
systems can still do different things. this should probably change to
always pop up a mnenu and simple call populate callbacks for site
owner specific content.
all in all it makes the new gagdtes more consistent, easier to use
(without a right mouse button), doesn't need special action bindings
etc. etc.
Summary:
Drop deprecated Encoding key from desktop files
The Encoding key is no longer required, all desktop files are assumed to
be UTF-8 encoded. See details at:
https://standards.freedesktop.org/desktop-entry-spec/1.1/apc.html
Fix various typos and misspellings
lintian, Debian's package checker, uses strings to check for common typos
in compiled binaries. This change fixes the ones it identified in 0.22.1.
Reviewers: zmike!
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5585
a reason for doing that is that you can just pack together targets into
a array and pass them to our helper, and the helper will just handle
them, so even module with eldbus codegen etc is now supported.
This also means that we are just passing the src object directly into
the shared_module call, which means the user of our helper can just pack
everything he needs into the src var and the helper does not need to
know about it.
now mdoule build files that fllow one pattern (the most common by far)
all JUSt list their souce files and nothing else. this really cuts
down on build size/complexity.
there are other patterns too (no icons at all) that i'll do next, then
we're down into "weird" land where i'll have to think of some more
interesting ways to deal with this.
so we';re missing installing desktop files. edj icon files, wizard
data files in the wrong place, and much more. this also cleans up the
module meson build of pretty much all modules and make their build
files cimple and consistent so it's far easier to re-use things from
one module to the next. we should aim for simplicity, consistency
between as much as possible so we can refactor and turn into maybe
functions later. imho that starts with consistency though. until i can
see all the common patterns clearly, i don't want to write functions
yet. it's easier to see if all the files are consistently using the
same vars and formatting etc. etc. etc.
but either way the installation needs fixing so it installs all files
in the right places with the right permissions etc. etc. etc.
this doesn't fix all module build files bt all the ones i found that
were broken installs and they use what i think is a cleaner/simpler
template, BUT there is far too much copy & pastage here... far too
much.i need to find a cleaner way to automate this.
All three of these gadgets are ports of the existing modules of the same name and are contained within those directories. Once the move from shelves -> bryce and gadcon->gadgets is complete, backlight and mixer will likely need to go into the sysinfo gadget.
==10821== Invalid write of size 8
==10821== at 0x28168A4B: _list_del (e_mod_config.c:455)
==10821== by 0x78F6C78: _eo_evas_object_cb (evas_callbacks.c:192)
==10821== by 0xE597F3A: _event_callback_call (eo_base_class.c:1422)
==10821== by 0xE598161: _efl_object_event_callback_legacy_call (eo_base_class.c:1491)
==10821== by 0xE59BC8F: efl_event_callback_legacy_call (efl_object.eo.c:146)
==10821== by 0x7932A4D: _efl_canvas_object_efl_object_event_callback_legacy_call (evas_object_main.c:1012)
==10821== by 0xE59BC8F: efl_event_callback_legacy_call (efl_object.eo.c:146)
==10821== by 0x78F7537: evas_object_event_callback_call (evas_callbacks.c:364)
==10821== by 0x7932C9B: _efl_canvas_object_efl_object_destructor (evas_object_main.c:1042)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x5033E3F: _elm_interface_atspi_accessible_efl_object_destructor (elm_interface_atspi_accessible.c:609)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x511E8DB: _elm_widget_efl_object_destructor (elm_widget.c:5866)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0xE58D31E: _efl_del_internal (eo_private.h:248)
==10821== by 0xE58D6E5: _efl_unref_internal (eo_private.h:323)
==10821== by 0xE58F9CA: _efl_object_call_end (eo.c:620)
==10821== by 0xE599203: efl_del (efl_object.eo.c:18)
==10821== by 0x7932565: evas_object_del (evas_object_main.c:902)
==10821== by 0x510EC99: _elm_widget_efl_canvas_group_group_del (elm_widget.c:461)
==10821== by 0x7948FE8: efl_canvas_group_del (efl_canvas_group.eo.c:36)
==10821== by 0x505ACC0: _elm_layout_efl_canvas_group_group_del (elm_layout.c:813)
==10821== by 0x7948FE8: efl_canvas_group_del (efl_canvas_group.eo.c:36)
==10821== by 0x7946ED7: evas_object_smart_del (evas_object_smart.c:1076)
==10821== by 0x7933114: _efl_canvas_object_efl_object_destructor (evas_object_main.c:1095)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x5033E3F: _elm_interface_atspi_accessible_efl_object_destructor (elm_interface_atspi_accessible.c:609)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x511E8DB: _elm_widget_efl_object_destructor (elm_widget.c:5866)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0xE58D31E: _efl_del_internal (eo_private.h:248)
==10821== by 0xE58D6E5: _efl_unref_internal (eo_private.h:323)
==10821== by 0xE58F9CA: _efl_object_call_end (eo.c:620)
==10821== by 0xE599203: efl_del (efl_object.eo.c:18)
==10821== by 0x7932565: evas_object_del (evas_object_main.c:902)
==10821== by 0x510EC99: _elm_widget_efl_canvas_group_group_del (elm_widget.c:461)
==10821== by 0x7948FE8: efl_canvas_group_del (efl_canvas_group.eo.c:36)
==10821== by 0x4F4D549: _elm_box_efl_canvas_group_group_del (elm_box.c:412)
==10821== by 0x7948FE8: efl_canvas_group_del (efl_canvas_group.eo.c:36)
==10821== by 0x7946ED7: evas_object_smart_del (evas_object_smart.c:1076)
==10821== by 0x7933114: _efl_canvas_object_efl_object_destructor (evas_object_main.c:1095)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x5033E3F: _elm_interface_atspi_accessible_efl_object_destructor (elm_interface_atspi_accessible.c:609)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x511E8DB: _elm_widget_efl_object_destructor (elm_widget.c:5866)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0xE58D31E: _efl_del_internal (eo_private.h:248)
==10821== by 0xE58D6E5: _efl_unref_internal (eo_private.h:323)
==10821== by 0xE58F9CA: _efl_object_call_end (eo.c:620)
==10821== by 0xE599203: efl_del (efl_object.eo.c:18)
==10821== Address 0x2c731708 is 184 bytes inside a block of size 456 free'd
==10821== at 0x4C2ED4A: free (vg_replace_malloc.c:530)
==10821== by 0x28165F69: _free_data (e_mod_config.c:249)
==10821== by 0x49D92E: _e_config_dialog_free (e_config_dialog.c:156)
==10821== by 0x546D2F: e_object_free (e_object.c:119)
==10821== by 0x546F4B: e_object_unref (e_object.c:152)
==10821== by 0x546B5E: e_object_del (e_object.c:60)
==10821== by 0x49E233: _e_config_dialog_cb_dialog_del (e_config_dialog.c:333)
==10821== by 0x546B34: e_object_del (e_object.c:58)
==10821== by 0x4AA23C: _e_dialog_cb_key_down (e_dialog.c:357)
==10821== by 0x78F6CB4: _eo_evas_object_cb (evas_callbacks.c:199)
==10821== by 0xE597F3A: _event_callback_call (eo_base_class.c:1422)
==10821== by 0xE598161: _efl_object_event_callback_legacy_call (eo_base_class.c:1491)
==10821== by 0xE59BC8F: efl_event_callback_legacy_call (efl_object.eo.c:146)
==10821== by 0x7932A4D: _efl_canvas_object_efl_object_event_callback_legacy_call (evas_object_main.c:1012)
==10821== by 0xE59BC8F: efl_event_callback_legacy_call (efl_object.eo.c:146)
==10821== by 0x78F7537: evas_object_event_callback_call (evas_callbacks.c:364)
==10821== by 0x7906AD8: _canvas_event_feed_key_down_internal (evas_events.c:3112)
==10821== by 0x7909281: _evas_canvas_event_key_cb (evas_events.c:3960)
==10821== by 0xE597E57: _event_callback_call (eo_base_class.c:1399)
==10821== by 0xE598161: _efl_object_event_callback_legacy_call (eo_base_class.c:1491)
==10821== by 0xE59BC8F: efl_event_callback_legacy_call (efl_object.eo.c:146)
==10821== by 0x65FDE63: _direct_key_updown_cb (ecore_evas.c:4664)
==10821== by 0x65FDFC9: _ecore_evas_input_direct_cb (ecore_evas.c:4692)
==10821== by 0x6813D6E: _ecore_event_evas_key (ecore_input_evas.c:429)
==10821== by 0x6814A8D: ecore_event_evas_key_down (ecore_input_evas.c:707)
==10821== by 0xDBD7AF6: _ecore_call_handler_cb (ecore_private.h:317)
==10821== by 0xDBD8A85: _ecore_event_call (ecore_events.c:518)
==10821== by 0xDBE1AEF: _ecore_main_loop_iterate_internal (ecore_main.c:2380)
==10821== by 0xDBDF89D: ecore_main_loop_begin (ecore_main.c:1290)
==10821== by 0x441BB4: main (e_main.c:1093)
==10821== Block was alloc'd at
==10821== at 0x4C2FA50: calloc (vg_replace_malloc.c:711)
==10821== by 0x28165773: _create_data (e_mod_config.c:182)
==10821== by 0x49DBBC: _e_config_dialog_go (e_config_dialog.c:204)
==10821== by 0x49D4E9: e_config_dialog_new (e_config_dialog.c:80)
==10821== by 0x28165625: _xkb_cfg_dialog (e_mod_config.c:141)
==10821== by 0x49EACF: e_configure_registry_call (e_configure.c:72)
==10821== by 0x314400C3: _e_mod_run_cb (e_mod_main.c:165)
==10821== by 0x53DA23: _e_menu_active_call (e_menu.c:2045)
==10821== by 0x53F7CC: _e_menu_cb_mouse_up (e_menu.c:2778)
==10821== by 0xDBD7AF6: _ecore_call_handler_cb (ecore_private.h:317)
==10821== by 0xDBD8A85: _ecore_event_call (ecore_events.c:518)
==10821== by 0xDBE1AEF: _ecore_main_loop_iterate_internal (ecore_main.c:2380)
==10821== by 0xDBDF89D: ecore_main_loop_begin (ecore_main.c:1290)
==10821== by 0x441BB4: main (e_main.c:1093)
So yeah, I've literally used sed to replace every occurrence of
ecore_time_add() with ecore_timer_loop_add() because I'm reasonably
confident that no part of E has a legitimate need for timer based on the
exact current time.
It would be really nice if I'm not wrong. :)
The reason for this is the incredible spew of clock_gettime() calls I'm
seeing on an ARM system (that should have a vdso for gettime, but...)
This can amount to thousands of system calls per second.
#YOLO
When in the config dialog a new set of layouts is created, this set has
to be told to the displayserver. Like at the startup of e, so calling
e_xkb_reconfig().
fix T3072
Summary:
There is an edge case that results in SIGFAULT in Enlightenment when
"Keyboard Settings" dialog is closed prior to "Add New Configuration"
dialog and "OK" button is pressed in the latter one.
This makes sure that closing the dialogs follows the parent/child logic.
@fix
Test Plan:
1. Go to Settings -> All -> Input -> Keyboard and press "Add"
2. Observe that "Add New Configuration" dialog is opened
3. Select/highlight any new layout
4. Go back to "Keyboard Settings" dialog and close it
5. Press "OK" in "Keyboard Settings" dialog
6. Observe that Enlightenment sigfaults
Reviewers: zmike, raster
Subscribers: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D3901
for the case e_xkb gets initialized, we need to init it before ecore_drm
is called, otherwise ecore_drm will create his own context and keymap,
which will be overriden a few moment later when e_xkb is initializied.
So by calling e_comp_wl_input_keymap_set before ecore_drm_init the
correct context and keymap is set and no useless elements are created.
The mainproblem is that the comp_type is set when the compositor is
already running, so we have to pass the type at the init to the e_xkb
to tell for which kind of compositor we are running.
we free the instance layout even though tthis is never duplicated but
jhust set to point to the current_layout. don't free it as this causes
a double-free. this fixes a crash here.
@fix
the previous behavior would just set up the new layouts, resulting in
the first layout in the list being applied. now it should be the case
that if the current layout has not been deleted, it will continue to
remain in effect; alternatively if the current layout has been modified,
it's now more likely to be picked up and used