this is a further fix for T5464 to actually make the intended option
work at all. what was there was broken. now it works. init order was
wrong - screensaver was relying on event id's from e_client socde that
were not initted yet AND the handlers didnt account for "dont blank
when fullscreen window is there" at all. @fix
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
This api give the possibility to add sink to an E_Client and control the volume
or the mute state of the sinks associated with this E_Client.
@features
Qt 5.7 has introduced an extra enviornment var for getting Qt/KDE
apps to follow gtk theming so we will export that alongside the
one that we already support.
Thanks to AJSlye for finding reporting and figuring this out.
this gives e by default sudo gui support with an askpass util that
sudo can use as well as setting the env var correctly so it will be
used by sudo.
@feature
this allows different display protocols to start their applications at
different times to ensure that any initialization has completed prior to
starting anything requiring a window
fix T3475
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.
so every time i restart e i have my windows all messed up. it's
INSANELY annoying and time consuming every single time having to move
a dozen or more windows back to where they should be just because i
restarted e. i've narrowed it down to 2 places. 1 which is trying to
handle "out of screen" windows and during startup it seems things are
not quite stable yet as the randr code figures things out until the
event storm settles down.
when this is then fixed - another bit of code just shuffles windows up
all the time by a titlebar whcih is also supremely annoying. this is
the code that adopes a new frame for a window.
so the nasty hack to avoid piles of pain right now is for the first 5
seconds of e's life - don't do this stuff. at least you can now use e
and not be annoyed to hell and back every restart.
yes a nicer fix may be better - but that's going to take a lot more
time and patience and until then - this will do.
these bindings activate before any other handler can process the
corresponding event and will block all propagation of the event upon
activation
as an example, the alt+wheel default binding for flipping desks currently
passes through a number of event handlers prior to activating the binding,
meaning that it's possible for the wheel action to have unwanted effects
when these handlers cause actions before the binding stops the propagation.
using a MANAGER context instead ensures that this is not possible
Summary:
@fix the display / customisation of KDE5 apps.
KDE5 applications don't understand anything other then gnome or kde
They expect everyone else to set QT_QPA_PLATFORMTHEME to tell them how
to theme there apps otherwise they use a fallback mode which results in
missing icons and a inability to change the appearance of applications
see https://bugzilla.suse.com/show_bug.cgi?id=920792 for more info.
There are two sensible defaults for this variable, "kde" which will
make apps appear the same as they do if they are run in kde. and gtk2
which will make kde applications follow the gtk/gnome theme, we have
decided on choosing gtk2 as it means that kde/qt apps will follow the
app and icon theme set in the enlightenment settings dialog. Some users
who wish to use Qt apps without any gnome or gtk usage may choose to
install qt5ct and overwrite this variable with qt5ct and use that to
configure there Qt5 applications.
Reviewers: raster, zmike
Subscribers: jeffhoogland, cedric
Differential Revision: https://phab.enlightenment.org/D3498
I have been running with this enabled for a while and it should not make
trouble but if it does simply reverting this one if totally fine while I'm
away.
this will allow all colorclasses present in the current theme to be edited
instead of only the hardcoded ones in the module. it will also require
completely new translations, for which translators will need to read the edc
files of the default theme (cleverly located in another repo) and provide
translations to the _translate() callback in the theme module
the editor currently lacks indicators for active/type on the colorclass
list, but this can be added in time. meanwhile, a large amount of code is
no longer duplicated or maintained in this repo
Wayland shm sets up a sigbus handler for catching invalid shm region
access. If we setup our sigbus handler here, then the wl-shm sigbus
handler will not function properly
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
We should be building Enlightenement with "--enable-wayland-only"
even if xcb, ecore-x... are not present. The Evas wayland-shm
engine will then be a prerequisite, though.
E_Alert being too much X11-oriented, let us disable it completely
before it is ported.
Also, do not require the X11 rendering engines at runtime.
Reviewers: stefan, devilhorns
Reviewed By: devilhorns
Subscribers: stefan_schmidt, stefan
Projects: #enlightenment-git
Differential Revision: https://phab.enlightenment.org/D1986
the previous patch(es) had a number of issues which made them unsuitable for general use:
* only checking "/usr" and "/usr/local" paths, despite this only being accurate if e was installed into /usr or /usr/local
* only checking if the paths were at the beginning of the string, when it's possible that they could be anywhere
* failure to also check XDG_CONFIG_DIRS
* improper formatting: this is a bit of a nitpick, but there are no correct instances of 'strcmp(a, b) == 0' in the e codebase.
Mike Blumenkrantz
Carsten Haitzler
Derek Foreman
Michaël Bouchaud (yoz)
Simon Lees (SUSE)
Marcel Hollerbach
Simon Lees
Stefan Schmidt
Chris Michael
Yomi
Manuel Bachmann