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
the fact is that nobody developing this has tested with 1.15.x recently,
and almost none of the changes have been backported to that branch. better
to require a newer version than to present a failing user experience