for security reaons, all the dbus methods that allow you to mess with
e are now in the msgbus module - load at your own risk. this is
irrelevant in x11, but in wayland this matters as wayland is actually
secure.
this also disables restart and shutdown dbus methods still in core.
they are there but non-functional due to possibly being able to be
abused in a wayland universe to "dos attack" the wm.
@fix
due to enabling manual rendering (and als animator frametiem to 10
secons) in e_comp_canvas.c when screensaver is active (blanking is
finished totallly - eg the fade to black) evas weill nto render the
last frame of the animation - skipping it and not rendering another
update until screensaver is disabled. this leaves a subtle ghost of
pixel data which is 1 step before black on the screen (until dpms
turns the monitor off).
this fixes that. this delays enabling manual render for 1 more second
after we have been told the screensaver is active. this is plenty of
time to update all the way to black.
@fix
in the case where a client is deleted, it's possible that the shell
surface may persist longer than the duration of the normal client delete
cycle, so it's necessary to ensure that the client will continue to exist
until the shell surface has been destroyed
Summary:
Found this with a quick valgrind session. For paths that are not directories, if we fail the `ecore_file_is_dir` condition memory will not be freed.
The change is to use the default e_path freeing function.
Test Plan:
Run enlightenment in valgrind. It should no longer show a mem leak like below.
```
==6912== 8 bytes in 1 blocks are definitely lost in loss record 186 of 5,940
==6912== at 0x4C28C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==6912== by 0x4D8574: e_path_dir_list_get (e_path.c:326)
==6912== by 0x4D1BA4: e_module_init.part.0 (e_module.c:183)
==6912== by 0x4D1DA8: e_module_init (e_module.c:153)
==6912== by 0x4371ED: main (e_main.c:868)
```
Reviewers: zmike
Subscribers: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D3356
This reverts commit bd0c590489.
the m->mirror object can never be deleted except in the case of a client
being removed from the owner desk. removing it at any point will break any
users of the deskmirror api and create other issues
ref T2846
Summary:
The imc import dialog at "Settings > Language > Input Method Settings >
Import .." had issue where the size was almost zero. When trying to
close the window it would SEGV.
The SEGV seems to be do the with dialog->cdata not being set.
The resize issue I am not so sure, but I upgraded to ELM and if fixed
the issue.
Test Plan:
Open "Settings > Language > Input Method Settings > Import ..."
- The size should not be really small
- When closing it should not cause E to SEGV
After applying the patch the above issues are fixed.
Reviewers: zmike
Subscribers: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D3353
there was previously a frame in which maximized x11 csd clients would
reposition themselves offscreen before rendering
this is now fixed by adjusting the client geometries either upon
unsetting the csd or re-setting it, allowing the client to retain its
expected positioning without jitters
a sticky window previously would always have the desk set for where
it was set as sticky, meaning that anything which tries to access it
will be reading wrong data here.
more useful information to provide is the last desk which the sticky
client was focused on, so update that upon focusing it
in the case that a mouse move event occurs, the compositor should validate
the event to ensure that the mouse cursor is actually over the window that
the event claims to be from
fix T2594
so e has a bit of a problem. we mostly deal with zones, BUt these
zones come from our old xinerama code (this likely should just die
some time) and THIS code gets fed info from e's randr code. we
re-fill/modify as randr finds new screens or things get reconfigured.
thus zones adapt. the problem is now all our zone code really has a
hard time reverse mapping the zone back to where it came from -eg the
randr screen data. you literally can't do a whole bunch of things like
know if that zone was an internal laptop lid or an external screen, or
if it was rotated or even what the dpi is... as you ave no deasy way
to map it back other than by guessing geometry matches.
this fixes that by storing the randr screen id (which should be
unique) fromt he original src randr screen in the xinerama screen and
then in the zone. with this you can do a quick lookup in the e randr
data should you ever need to find the info. this should pave the way
for some other fixes/improvements, but without this they cannot be done.
@fix
Summary:
@Fix
possible null dereference issue while referencing cs2->id. So added a condition
to check it
Signed-off-by: Vivek Ellur <vivek.ellur@samsung.com>
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3309
valgrind pointed out a referencing issue with the ibar client menu on
hover and if e is shut down while this is up. it ends up referencing
an already deleted ibar icon, so delete the menu objects that
reference the icon if icon is deleted.
@fix
previous behavior would result in the nocomp window becoming stuck at a fullscreen
layer when ending nocomp, even if the client was no longer fullscreen
fix T2827
Summary:
It seems this was missed when doing the manager/container id removal
back in march. The param validation was failing and causing the "Set"
button to not work in "Screen > Virtual Desktops > Click to Change
wallpaper".
Test Plan:
1. Open "Screen > Virtual Desktops > Click to Change wallpaper"
2. Click "Set"
- Expect that a wallpaper dialog be shown
- Before this patch nothing happens
Reviewers: zmike
Subscribers: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D3298
in order to continue rendering an iconic client without breaking icccm,
it's necessary to map the client's window again and unset iconic state
whenever rendering is needed, then re-set states when rendering
stops
ref T2788
Summary:
I noticed this because the description dialog in "Apps > Startup Application"
was never getting properly populated.
Test Plan:
When selecting items in the "Apps > Startup Applications" config the
description should update if a "Comment" field is available in the
.desktop file.
Reviewers: zmike
Subscribers: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D3297
Summary:
Currently the config dialog in Apps > Startup Applications does not properly
resized as one of the objects is not set to horizontal fill.
Test Plan: 1. Resize "Apps > Startup Applications", it should resize the list with the window
Reviewers: zmike
Subscribers: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D3296
Summary:
Currently the dialogs in Winows > Window List Menu and Window Display are
resizable the their content does not resize. This patch fixes that.
Test Plan: Open windows in window config dialog and ensure they can resize propertly
Reviewers: zmike
Subscribers: raster, cedric, seoz
Differential Revision: https://phab.enlightenment.org/D3275
efreet will send change events meaning out desktop file icons are
invalid now. we have refs but content is junk. update these to new
desktop ptr handles by using the exec key to look up new ones on the
change event. this fixes ibar gainign a bunch of blank unknown icons
when any desktop files are touched on the system or user dirs
@fix
i encontered a situation where the icon_hash contained a garbage entry
- had been freed already. the only way i can see this happening is if
the desktop file changed path during runtime thus the icon was never
removed from hash on free as string didnt match. store string used
when adding to hash so removal is guarannteed to work and also for
good measure protect against double-adding (and generate a new string
for storage using timestamp which should be unique).
so this fixes a crash i was just looping on.
@fix
wayland clients which have csd must be resized according to window geometry,
not client (surface) geometry. this is somewhat tricky to handle because x11
clients which have csd work the exact opposite way and must continue to be
managed using client geometry
this is not my ideal solution for this issue, but I can't think of a
better one at this time which fully fixes wayland client maximization
due to the (current) synchronous creation of wayland surfaces in efl,
creating these dialogs during startup will result in a crash. the only
way to prevent this and still display the dialogs is to wait a bit and
show the dialogs after init has completed
as promised almost a year ago, this module has been unmaintained to
the point where it cannot function in any way, and attempting to keep
it in the tree is a futile effort
this module can now be found at devs/discomfitor/e_module-access.git
ref 77717523f3
enlightenment is (I think) the first wayland compositor to run with
in-process pulseaudio integration for audio playback and not just mixer
support. hooray.
this results in a fun issue: if DISPLAY is set, as it must be for x11
clients to function, pulseaudio will unconditionally attempt to use a
blocking socket connection to create a connection to the running xserver.
the only exception here is if x11 support has been compiled out of pulseaudio,
but probably no distro will do that ever.
so, what happens when the compositor thread tries to create a socket connection
to the xserver that the compositor thread has not yet started? absolutely nothing.
forever.
the easiest solution which continues to provide the key press sounds that everyone
loves is to ensure that the pulseaudio connection is created before DISPLAY is ever
set, namely in the xwayland module init.
this will now occur automatically now in the case when the mixer module detects
pulseaudio support.
TL;DR: don't disable mixer module if you use xwayland
_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>
when applying new csd to a window which already has csd, the previous
csd must be removed in order to apply any new csd offsets in order to
avoid unwanted moving/resizing
man xset => If the `threshold' parameter is provided and 0, the
`acceleration' parameter will be used in the exponent of a more
natural and continuous formula, giving precise control for slow motion
but big reach for fast motion, and a progressive transition for motions
in between. Recommended `acceleration' value in this case is 3/2 to 3,
but not limited to that range.
due to how deferred rendering works, it's possible for a client to
send a second buffer before enlightenment has rendered the first one.
in this situation, it seems that the best solution is to queue successive
buffers (frames) and pop the queue after each render
ref T2784
since ICCCM requires that clients be unmapped while iconified, it's necessary
for the compositor to perform one last render prior to the unmap in order to
ensure that mirror objects will still appear as expected. this render must use
the pixmap buffer data in order to avoid timing issues due to async/deferred
rendering, and it is only necessary for the case of clients rendering with a
native surface
fix T2788
the env var DBUS_SESSION_BUS_ADDRESS may not be set for all platforms
where enlightenment+dbus are usable, so it's necessary to get the dbus
id to ensure that this value exists and is properly tracked
E_Client->comp_data is null after a client has been deleted, so
attempting to handle events which require the dereferencing of this
pointer after a client has been deleted will result in a crash
these events should be rejected after delete regardless, since at this
time the compositor has stopped handling events for the client
ref f42c6aa187
i got a crash here and the bt was broken and i couldnt check if
_e_comp_x_client_data_get() returned null, but it's the only thing
that would make sense, so protect against this to avoid a crash. as
this was a one-off, i can't find out more,
@fix
the current spec does not directly require any behavior from clients
when a systray host, leading to an issue where clients do not re-register
their items when a new host appears
when using an in-process systray watcher, as the current implementation does,
the best choice for maintaining consistency for systray items across restarts
is to cache them according to the current dbus session. the process of setting
up the item will validate it on subsequent restarts, and changes to the session
will clear the cache
fix T2786
Summary:
return value is small enough, so there is no risk in casting from unsigned int to signed int.
CID: 1267211
Reviewers: devilhorns, raster, cedric, zmike
Subscribers: seoz, sachin.dev
Differential Revision: https://phab.enlightenment.org/D3179
in the case where a shaped window with many rects exists, there is a high
probability of the damage rect count being huge, leading to massive blocking for
each frame as the compositor attempts to fetch all of these rects from the xserver.
instead, the compositor can shortcut this by forcing a full-window damage any time
the rect count is sufficiently high, trading a blocking socket operation for some
amount of (potential) overdraw.
testing in affected scenarios has shown huge improvements: where previously the entire
compositor would lock up, things work as expected now
see https://bugzilla.mozilla.org/show_bug.cgi?id=1214746 for a sample case
e_config->backlight.idle_dim is actually an unsigned char in the
structure, so use a 0 & 1 for min & max
Signed-off-by: Chris Michael <cp.michael@samsung.com>
it seems that damages for popup windows in some applications,
namely blink-based browsers, are reported incorrectly, resulting
in sometimes having a blank window
so a bit of a config wipe had my comp config reset (some dev
shenanigans) and i got to see what current e "out of box" config is -
and it was horrid for menus. visibilitiy effect was broken. vertial.
default was none - always. forever. like empty. so go back to that. in
fact why do this visibility effect? that was the point of having a
different shadow in the theme - each has its own look + effect. this
makes things far more complex...
Summary:
there is no need to set repeatedly input region even if it's already applied.
and this patch remove the code to clear tiler from client's unmapped case.
this fixes that tiler for input region is removed before applying it to comp object in case client is unmmaped yet.
Reviewers: devilhorns, zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3076
Sometimes, trying to go to the parent directory wouldn’t work and end up showing some garbage. Unfortunately, the code ended up not NULL-ending the path, which made searching for the path separator buggy.
according to the StatusNotifierItem specification, applications
register "service org.freedesktop.StatusNotifierItem-PID-ID" on the
session bus, and then "must register the unique instance name
to the StatusNotifierWatcher".
some applications, such as steam, instead register the path that they
will run on (/org/ayatana/NotificationItem/steam) and then expect the
watcher to register the method call's send id bus: this is totally bogus.
to catch this, when registering the new item the enlightenment watcher must
first determine if the item is spec-conforming. if yes, proceed as normal.
if no, pretend the application knows what it's doing and try to make things
work as expected anyway
for more details, read the full spec here
http://www.freedesktop.org/wiki/Specifications/StatusNotifierItem
fix T2763
in some cases, it's possible for a client which expects to render on
the next frame to actually render on the frame after. in these cases,
the compositor must not clear the pixmap image until after the render
has occurred in order to avoid inaccuracies. for this reason, the best
place to flag a client for post-render work is at the time of the client's
render
ref T2762
ref D3120
fixes case where plugging an external monitor would cause the screen
to expand onto that display without the display being effectively usable
until after a restart
the previous methodology was effectively:
attach -> ref(new buffer) x2 / unref(old buffer) x2
...
...
attach -> ref(new buffer) x2 / unref(old buffer) x2
this resulted in buffer management failures and crashing. now the
buffer gets 1x ref before render and 1x unref after render, ensuring
that the lifetime is accurate (assuming evas doesn't lie to us)
now we still have random crashing during resize, but not as much as
before
==24509== Invalid write of size 8
==24509== at 0x502D00: _e_elm_win_trap_del (e_win.c:39)
==24509== by 0x509BFC2: _elm_win_evas_object_smart_del (elm_win.c:1886)
==24509== by 0x91F4643: evas_obj_smart_del (in /usr/lib/libevas.so.1.15.99)
==24509== by 0x91F5B5C: evas_object_smart_del (evas_object_smart.c:1021)
==24509== by 0x91E9107: _evas_object_eo_base_destructor (evas_object_main.c:739)
==24509== by 0xE54A8A3: eo_destructor (in /usr/lib/libeo.so.1.15.99)
==24509== by 0x5086715: _elm_widget_eo_base_destructor (elm_widget.c:5744)
==24509== by 0xE54A8A3: eo_destructor (in /usr/lib/libeo.so.1.15.99)
==24509== by 0xE5443EC: _eo_del_internal (eo_private.h:221)
==24509== by 0xE5443EC: _eo_unref (eo_private.h:295)
==24509== by 0xE5443EC: _eo_do_end (eo.c:546)
==24509== by 0x4D5B1A: _e_obj_dialog_free (e_obj_dialog.c:125)
==24509== by 0x4D61FB: e_object_free (e_object.c:152)
==24509== by 0x4D61FB: e_object_unref (e_object.c:152)
==24509== by 0x4EDC54: _e_sys_logout_after (e_sys.c:750)
==24509== by 0x4ED7AC: _e_sys_action_do (e_sys.c:925)
==24509== by 0x4EE348: e_sys_action_raw_do (e_sys.c:311)
==24509== by 0x4EE43F: _e_sys_comp_done_cb (e_sys.c:66)
==24509== by 0x6097348: _edje_emit_cb (edje_program.c:1476)
==24509== by 0x6097348: _edje_emit_handle (edje_program.c:1405)
==24509== by 0x60924EE: _edje_message_queue_process (edje_message_queue.c:787)
==24509== by 0x60926A6: _edje_job (edje_message_queue.c:154)
==24509== by 0xCC5087A: _ecore_job_event_handler (ecore_job.c:121)
==24509== by 0xCC4B204: _ecore_call_handler_cb (ecore_private.h:390)
==24509== by 0xCC4B204: _ecore_event_call (ecore_events.c:565)
==24509== by 0xCC52AE7: _ecore_main_loop_iterate_internal (ecore_main.c:1927)
==24509== by 0xCC52CD6: ecore_main_loop_begin (ecore_main.c:983)
==24509== by 0x4383F4: main (e_main.c:1047)
==24509== Address 0x14fb1a28 is 1,176 bytes inside a block of size 1,352 free'd
==24509== at 0x4C2A65B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24509== by 0x4D61FB: e_object_free (e_object.c:152)
==24509== by 0x4D61FB: e_object_unref (e_object.c:152)
==24509== by 0x502CED: _e_elm_win_trap_del (e_win.c:37)
==24509== by 0x509BFC2: _elm_win_evas_object_smart_del (elm_win.c:1886)
==24509== by 0x91F4643: evas_obj_smart_del (in /usr/lib/libevas.so.1.15.99)
==24509== by 0x91F5B5C: evas_object_smart_del (evas_object_smart.c:1021)
==24509== by 0x91E9107: _evas_object_eo_base_destructor (evas_object_main.c:739)
==24509== by 0xE54A8A3: eo_destructor (in /usr/lib/libeo.so.1.15.99)
==24509== by 0x5086715: _elm_widget_eo_base_destructor (elm_widget.c:5744)
==24509== by 0xE54A8A3: eo_destructor (in /usr/lib/libeo.so.1.15.99)
==24509== by 0xE5443EC: _eo_del_internal (eo_private.h:221)
==24509== by 0xE5443EC: _eo_unref (eo_private.h:295)
==24509== by 0xE5443EC: _eo_do_end (eo.c:546)
==24509== by 0x4D5B1A: _e_obj_dialog_free (e_obj_dialog.c:125)
==24509== by 0x4D61FB: e_object_free (e_object.c:152)
==24509== by 0x4D61FB: e_object_unref (e_object.c:152)
==24509== by 0x4EDC54: _e_sys_logout_after (e_sys.c:750)
==24509== by 0x4ED7AC: _e_sys_action_do (e_sys.c:925)
==24509== by 0x4EE348: e_sys_action_raw_do (e_sys.c:311)
==24509== by 0x4EE43F: _e_sys_comp_done_cb (e_sys.c:66)
==24509== by 0x6097348: _edje_emit_cb (edje_program.c:1476)
==24509== by 0x6097348: _edje_emit_handle (edje_program.c:1405)
==24509== by 0x60924EE: _edje_message_queue_process (edje_message_queue.c:787)
==24509== by 0x60926A6: _edje_job (edje_message_queue.c:154)
==24509== by 0xCC5087A: _ecore_job_event_handler (ecore_job.c:121)
==24509== by 0xCC4B204: _ecore_call_handler_cb (ecore_private.h:390)
==24509== by 0xCC4B204: _ecore_event_call (ecore_events.c:565)
==24509== by 0xCC52AE7: _ecore_main_loop_iterate_internal (ecore_main.c:1927)
==24509== by 0xCC52CD6: ecore_main_loop_begin (ecore_main.c:983)
==24509== by 0x4383F4: main (e_main.c:1047)
==24509== Invalid write of size 8
==24509== at 0x2C5ED500: _notification_popup_del_cb (e_mod_popup.c:404)
==24509== by 0x91AAE93: _eo_evas_object_cb (evas_callbacks.c:92)
==24509== by 0xE54DDEA: _eo_base_event_callback_call (eo_base_class.c:715)
==24509== by 0xE54B67A: eo_event_callback_call (in /usr/lib/libeo.so.1.15.99)
==24509== by 0x91AB323: evas_object_event_callback_call (evas_callbacks.c:264)
==24509== by 0x91E8DE3: _evas_object_eo_base_destructor (evas_object_main.c:691)
==24509== by 0xE54A8A3: eo_destructor (in /usr/lib/libeo.so.1.15.99)
==24509== by 0x60A3019: _edje_object_eo_base_destructor (edje_smart.c:43)
==24509== by 0xE54A8A3: eo_destructor (in /usr/lib/libeo.so.1.15.99)
==24509== by 0xE5443EC: _eo_del_internal (eo_private.h:221)
==24509== by 0xE5443EC: _eo_unref (eo_private.h:295)
==24509== by 0xE5443EC: _eo_do_end (eo.c:546)
==24509== by 0x6091146: edje_match_callback_exec_check_finals (edje_match.c:556)
==24509== by 0x6091146: edje_match_callback_exec (edje_match.c:711)
==24509== by 0x60974AE: _edje_emit_cb (edje_program.c:1453)
==24509== by 0x60974AE: _edje_emit_handle (edje_program.c:1405)
==24509== by 0x60924EE: _edje_message_queue_process (edje_message_queue.c:787)
==24509== by 0x60926A6: _edje_job (edje_message_queue.c:154)
==24509== by 0xCC5087A: _ecore_job_event_handler (ecore_job.c:121)
==24509== by 0xCC4B204: _ecore_call_handler_cb (ecore_private.h:390)
==24509== by 0xCC4B204: _ecore_event_call (ecore_events.c:565)
==24509== by 0xCC52AE7: _ecore_main_loop_iterate_internal (ecore_main.c:1927)
==24509== by 0xCC52CD6: ecore_main_loop_begin (ecore_main.c:983)
==24509== by 0x4383F4: main (e_main.c:1047)
==24509== Address 0x23b3dcb0 is 16 bytes inside a block of size 80 free'd
==24509== at 0x4C2A65B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24509== by 0x2C5ED606: _notification_popdown (e_mod_popup.c:747)
==24509== by 0x2C5ED952: _notification_reshuffle_cb (e_mod_popup.c:700)
==24509== by 0x91AAE93: _eo_evas_object_cb (evas_callbacks.c:92)
==24509== by 0xE54DDEA: _eo_base_event_callback_call (eo_base_class.c:715)
==24509== by 0xE54B67A: eo_event_callback_call (in /usr/lib/libeo.so.1.15.99)
==24509== by 0x91AB323: evas_object_event_callback_call (evas_callbacks.c:264)
==24509== by 0x91E8DE3: _evas_object_eo_base_destructor (evas_object_main.c:691)
==24509== by 0xE54A8A3: eo_destructor (in /usr/lib/libeo.so.1.15.99)
==24509== by 0x60A3019: _edje_object_eo_base_destructor (edje_smart.c:43)
==24509== by 0xE54A8A3: eo_destructor (in /usr/lib/libeo.so.1.15.99)
==24509== by 0xE5443EC: _eo_del_internal (eo_private.h:221)
==24509== by 0xE5443EC: _eo_unref (eo_private.h:295)
==24509== by 0xE5443EC: _eo_do_end (eo.c:546)
==24509== by 0x504CEF: _e_zoomap_smart_del (e_zoomap.c:266)
==24509== by 0x91F5ABC: evas_object_smart_del (evas_object_smart.c:1019)
==24509== by 0x91E9107: _evas_object_eo_base_destructor (evas_object_main.c:739)
==24509== by 0xE54A8A3: eo_destructor (in /usr/lib/libeo.so.1.15.99)
==24509== by 0xE5443EC: _eo_del_internal (eo_private.h:221)
==24509== by 0xE5443EC: _eo_unref (eo_private.h:295)
==24509== by 0xE5443EC: _eo_do_end (eo.c:546)
==24509== by 0x458C7A: _e_comp_object_util_del (e_comp_object.c:2402)
==24509== by 0x91AAE93: _eo_evas_object_cb (evas_callbacks.c:92)
==24509== by 0xE54DDEA: _eo_base_event_callback_call (eo_base_class.c:715)
==24509== by 0xE54B67A: eo_event_callback_call (in /usr/lib/libeo.so.1.15.99)
==24509== by 0x91AB323: evas_object_event_callback_call (evas_callbacks.c:264)
==24509== by 0x91E8DE3: _evas_object_eo_base_destructor (evas_object_main.c:691)
==24509== by 0xE54A8A3: eo_destructor (in /usr/lib/libeo.so.1.15.99)
==24509== by 0x60A3019: _edje_object_eo_base_destructor (edje_smart.c:43)
==24509== by 0xE54A8A3: eo_destructor (in /usr/lib/libeo.so.1.15.99)
==24509== by 0xE5443EC: _eo_del_internal (eo_private.h:221)
==24509== by 0xE5443EC: _eo_unref (eo_private.h:295)
==24509== by 0xE5443EC: _eo_do_end (eo.c:546)
==24509== by 0x6091146: edje_match_callback_exec_check_finals (edje_match.c:556)
==24509== by 0x6091146: edje_match_callback_exec (edje_match.c:711)
==24509== by 0x60974AE: _edje_emit_cb (edje_program.c:1453)
==24509== by 0x60974AE: _edje_emit_handle (edje_program.c:1405)
==24509== by 0x60924EE: _edje_message_queue_process (edje_message_queue.c:787)
==24509== by 0x60926A6: _edje_job (edje_message_queue.c:154)
==24509== by 0xCC5087A: _ecore_job_event_handler (ecore_job.c:121)
==24509== by 0xCC4B204: _ecore_call_handler_cb (ecore_private.h:390)
==24509== by 0xCC4B204: _ecore_event_call (ecore_events.c:565)
==24509== by 0xCC52AE7: _ecore_main_loop_iterate_internal (ecore_main.c:1927)
==24509== by 0xCC52CD6: ecore_main_loop_begin (ecore_main.c:983)
==24509== by 0x4383F4: main (e_main.c:1047)
if this isn't explicitly blocked by config options then allowing resizes
on the unmaximized axes is necessary in order to avoid accidentally
queuing a full unmaximize
according to ICCCM 4.1.4:
Only the client can effect a transition into or out of the Withdrawn state
withdrawn windows cannot be shown under any circumstances. the best that can
be done is to try mapping the window and hope it decides to appear.
to prevent any inadvertent showing of the window before it leaves the
withdrawn state, we play games with the E_Client->ignored flag in order
to skip client evals until we get notified that maybe we want to stop
skipping those evals
ref T2745