the drm screenshot action forcefully iterates the main loop, causing
the current loop (which triggered the action) to return after the screenshot
action has ended. during this time, it's possible for other actions to also
trigger, including triggering subsequent screenshot actions, so it's necessary
to defer the execution of the action until after the initial loop which triggered
the action has returned
#Recursion
in this case, mouse events which are not originating from the internal
window are for the screen, and these coords can be used for determining
"mouse out". if the mouse event comes from the window, it is inside the window.
ref 7c661b54a9
these types of surfaces should grab focus as early as possible, and
setting the flag at this time ensures that it will be handled during
the next client eval
if windows are created during startup, they will attempt to show themselves
before xdg surface operations are available, leading to a scenario where they
will never successfully map themselves. if the elm win object is visible, this
indicates a mapped internal window, so directly call the map function at this
time to make the window visible
Summary:
printf %m stringifies and prints errno. This is actually hugely confusing
if used in error messages after failures that don't set errno.
You may get "Success", or you may get an errno that was harmless ages
ago.
Some of the functions followed by %m have only some error paths that
set errno, or make multiple system calls that can set errno
independently - knowing the errno at failure time is unlikely to be
useful in these cases.
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3571
this removes the per desktop profile config and replaces it with a
per-screen one that is tied to a specific display so it is far more
logical than per desktop. this allows e to set up different scaling
per screen for apps that use elementary for example via this derived
profile.
this of course is slightly problematic for e itself since it now uses
elm - as this will cause e to go kind-of-crazy with differing profiles
as it fights with itself and elm if 2 screens have different profiles.
this requires elm to be fixed to allow custom profiles per window.
this also currently won't switch profile of a window when you
reconfigure screens.
@feature
xx
Summary:
Set xkb context and keymap to Ecore_Drm.
In enlightenment (used in wayland with drm backend), keymap is used only one.
So for avoid unnecessary open keymap files, set cached context and keymap.
But for this, enlightenment must compile keymap before init ecore_drm.
So I changed booting sequence also.
Test Plan: Distinguish time between before and after during add a keyboard device.
Reviewers: raster, devilhorns, zmike
Subscribers: cedric, input.hacker, ohduna
Differential Revision: https://phab.enlightenment.org/D3504
I can't find anything in the specs that would imply those shouldn't be
tiled. This may cause placement bugs, but I don't think that'd be the
case, as we ignore application placement when tiling anyway.
@fix
This function is being used inside e_mod_main, but the function
prototype was never exposed which lead to implicit declaration
warnings when building winlist module
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
Summary:
The original next window selection of winlist is weak. It searches the next window with the following conditions:
1. Next non-overlaped window in the direction of user's selection (up,down,right,left).
2. The next window has to be the closest window from the currently selected window (calculated from shortest distance from each window's border, in the direction of selection)
3. the second distant requirement is this:
delta2_next = abs(ec_orig->x - ec_orig->w / 2 - ec->x + ec->w/2);
* Which I believe is a mistake, should be:
delta2_next = abs(ec_orig->x + ec_orig->w / 2 - ec->x + ec->w/2);
These two conditions are weak, and they sometimes can result in unexpected selection to the user.
The enclosed patch enhances the next window selection: 1) A next window selection can be the window that's overlapping with the in-focused window. 2) calculates the next window from the center of the currently focused window to the next window, and it also takes into account directionality (a window that's farther in the direction of selection has a better chance of being selected then a window that's closer in the direction of selection, but offset-ed in the lateral direction.)
Test Plan:
1. Create 4 key binds for "next window to left, right, up, down".
2. Open up 4 different windows and position them in odd/random positions.
3. Try to navigate to each window (with the winlist shortcut keys) before this patch.
4. Try with this patch, and evaluate if the window selection is more **PREDICTABLE**.
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2661
I fixed the weridness and it behaves much more reliably now with
"tall" or "wide" windows. also fixed some formatting etc. etc. - this
now works better and now if u alt+tab AND then use arrow keys while
holding alt... it'll navigate around geometrically rather nicely.
so big fixes and good for pointing out the simpleness of the original
code. :)
- raster
@feat
If we are calling emix_config_save_state_get while in init, we are
freeing the list emix_config_save_state_restore is iterating over.
This leads to crashes.
@fix T2942
@fix T2906
In the xdg_surface_configure_send function, the size params
(width/height) come in as int32_t. This patch makes the E_Shell_Data
fields for width & height match those (else we end up with compiler
warnings when comparing int32_t to uint32_t).
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
desktop gadgets don't have minimum size set from parent objects, so
it's necessary to use the current object geometry in order to correctly
size these gadgets since the top-most widget is from elm
fix T2907
Summary:
Fix missmatched paths between desklock and conf_applications module to
enable adding/removing screen lock applications with a dialog.
Test Plan:
Settings=>Apps=>Screen lock/unlock application
Veryfy if apps are correctly added to config.
Reviewers: zmike, cedric
Subscribers: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D3436
Mike Blumenkrantz
Marcel Hollerbach
Derek Foreman
Carsten Haitzler
Chris Michael
JengHyun Kang
Tom Hacohen
Toan Pham
Lukasz Stanislawski
Chris Michael
Stefan Schmidt
