_e_shell_surface_destroy() is already the implementation's destructor, so
it'll be called when the surface is destroyed anyway. What we have to do
here is just call wl_resource_destroy(resource) - which will call that
function for us.
It'll also do us the favor of actually destroying the resource and
removing it from the client's resource list so we won't get a SECOND call
to _e_shell_surface_destroy() on client exit.
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
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>
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
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
as part of another fix for having e just pop up the screen config
dialog when a new screen is detected that isn't configured, allow
config dialog for randr to get screen output name via input params
@fix
Summary:
libwayland-server.so will post an error if the requested version
is higher than the supported one anyway, so there's no point in
doing this.
Using MIN() to pick versions is a client side idiom.
#kansas
Reviewers: zmike, devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3385
We have to use void in a function declaration if we want no function
parameters. Using just empty parenthesis means the function takes an
unspecified number of parameters.
We had it correct for most declarations and this series fixes it for
the rest.
Thanks for the sparse semantic parser for pointing this out.
Mike Blumenkrantz
Derek Foreman
Chris Michael
Chris Michael
Carsten Haitzler
Tom Hacohen
Toan Pham
Marcel Hollerbach
Lukasz Stanislawski
Stefan Schmidt
