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
the default profiel is configureed to use dpi to scale. if dpi goes up
so does wizard scaling. setitng to 1.2 forcibly is just wrong. imagine
a uhd screen thats 13" or imagine an 8k display... at least if dpi can
be read correctly things work out find. think the base dpi of 90 is
too high - then adjust that in profile... but not in wizard code.
this has been here a while and i always thought this scaling bumping
was a dpi effect. it wasnt. it was hardcoded. bad bad.
@fix.
we should use here the translation for plural or singular, everything
else makes it hard to translate
This commit also adds the file to POTFILES so it gets recognized by the
pot file
this does not trigger any efreet cache rebuilds and will result in the user
being forced to sit through the full duration of the wait timer: currently 7.0s
this gets triggered multiple times throughout the wizard.
embarrassing.jpg
this is a default feature of enlightenment which is not obvious to all new
users and, with the default modifier being Alt, may interfere with some
application behavior. this informs users of the feature's existence and
allows for easily changing the modifier(s)
Summary: If we get here when curpage is NULL, we'll crash later, so we should test for it.
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2793
Summary: If we get here when curpage is NULL, we'll crash later, so we should test for it.
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2789
str(n)dupa are GNU extensions that duplicate a string, using an alloca'd
buffer. This patch removes their definitions from e.h (which should only
contain E's own API, without fallback definitions for libc functions)
which were wrong anyway (they failed in cases where str(n)dupa was an
actual function, not a macro).
Instead, we replace them depending on context with alloca+memcpy+strlen
or a static buffer (used in contexts where we are sure that the buffer
will contain the string entirely)
@fix
Summary:
@fix The list of icon themes in the search list is quite out of date
it doesn't include the icon themes used by gnome3 or kde4/5 this means
for a lot of users at first boot e has alot of missing icons.
The Icon sets that have been added are as follows
"Oxygen", /* KDE 4 */
"Adwaita", /* Gnome 3 */
"Breeze", /* KDE 5 */
"HighContrast"
This change will cause T1732 and T1923 to not occur for almost all users
but it does not fix them properly the code should be modified to fall back
to pick up icons from fallback locations such as the hicolor theme if no
icon theme is set.
It would be nice if someone could backport this to e19 I don't know how to
Reviewers: bu5hm4n, zmike, raster
Reviewed By: raster
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2377
there is only one E_Comp which can now be accessed by the e_comp global.
if you're editing a file with some uses of these deprecated functions, replace their usages with appropriate references to this variable
pass -Wno-deprecated-declarations to ignore these warnings during build
Summary:
Commit rE5b992bdc4a76 added the free for the list, the list is filed
with static pointers from the .c file, soo free will crash.
This pointer does not need to be freed, just freeing the list.
Test Plan: Just run the wizard
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1679
There was a bug there, that caused the one after the standard to be
selected, instead of the standard one.
This was caused because directories and the default profile were not
properly ignored.
this option provides the functionality which was intended by the old and broken "raise on focus" option. it raises windows ONLY when reverting focus in cases not directly triggered by the user or any application
huge fustercluck commit because there wasn't really a way to separate out the changes. better to just rip it all out at once.
* compositor and window management completely rewritten. this was the goal for E19, but it pretty much required everything existing to be scrapped since it wasn't optimized, streamlined, or sensible. now instead of having the compositor strapped to the window manager like an outboard motor, it's housed more like an automobile engine.
** various comp structs have been merged into other places (eg. E_Comp_Zone is now just part of E_Zone where applicable), leading to a large deduplication of attributes
** awful E_Comp_Win is totally dead, having been replaced with e_comp_object smart objects which work just like normal canvas objects
** protocol-specific window management and compositor functionality is now kept exclusively in backend files
** e_pixmap api provides generic client finding and rendering api
** screen/xinerama screens are now provided directly by compositor on startup and re-set on change
** e_comp_render_update finally replaced with eina_tiler
** wayland compositor no longer creates X windows
** compositor e_layout removed entirely
* e_container is gone. this was made unnecessary in E18, but I kept it to avoid having too much code churn in one release. its sole purpose was to catch some events and handle window stacking, both of which are now just done by the compositor infra
* e_manager is just for screensaver and keybind stuff now, possibly remove later?
* e_border is gone along with a lot of its api. e_client has replaced it, and e_client has been rewritten completely; some parts may be similar, but the design now relies upon having a functional compositor
** window configuration/focus functions are all removed. all windows are now managed solely with evas_object_X functions on the "frame" member of a client, just as any other canvas object can be managed.
*** do NOT set interceptors on a client's comp_object. seriously.
* startup order rewritten: compositor now starts much earlier, other things just use attrs and members of the compositor
* ecore_x_pointer_xy_get usage replaced with ecore_evas_pointer_xy_get
* e_popup is totally gone, existing usage replaced by e_comp_object_util_add where applicable, otherwise just placed normally on the canvas
* deskmirror is (more) broken for now
* illume is totally fucked
* Ecore_X_Window replaced with Ecore_Window in most cases
* edge binding XWindows replaced with regular canvas objects
* some E_Win functionality has changed such that delete callbacks are now correctly called in ALL cases. various dialogs have been updated to not crash as a result
comp files and descriptions:
e_comp.c - overall compositor functions, rendering/update loop, shape cutting
e_comp_x.c - X window management and compositor functionality
e_comp_wl.c - Wayland surface management and compositor functionality
e_comp_canvas.c - general compositor canvas functions and utilities
e_comp_object.c - E_Client->frame member for managing clients as Evas_Objects, utility functions for adding objects to the compositor rendering systems
additional authors: ivan.briano@intel.com
feature: new compositor
removal: e_border, e_container, e_popup
this adds moldova (moldavian?) flag for layouts of keyboards and
refreshes some of the generic images for unknown, latin america, brail
and arabic "flag" images, and forces flag icons to be 2:1 aspect
ration with icon centered within that area to address T647
Derek Foreman
Carsten Haitzler
Marcel Hollerbach
Mike Blumenkrantz
Kai Huuhko
Simon Lees
Daniel Kolesa
Chris Michael
kabeer khan
maxerba
Mike Blumenkrantz
Sebastian Dransfeld
Cedric BAIL
Thanatermesis
Tom Hacohen