Page MenuHomePhabricator

actions: Add 'Grow in Direction...' action

Authored by romildo on May 2 2021, 1:11 PM.



Add an action to grow a window until it touches the nearest edge in
the direction specified. Edges are the outer edges of other windows,
or the desktop boundaries.

Diff Detail

rE core/enlightenment
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
romildo created this revision.May 2 2021, 1:11 PM
romildo requested review of this revision.May 2 2021, 1:11 PM
raster added a comment.May 3 2021, 7:05 AM

nicely done. some pointers to where to look and .. presto. it wasn't hard...

but you have a bug. growing down (in y direction) makes the window super tall. (so if vdir > 0).

also there is another issue. size stepping. grep for icccm.step_w and icccm.step_h in the source. ALSO you don't consider window ma×imum size too (grep for icccm.min_w and icccm.min_h). luckily for you there is a function that applies limits: e_client_resize_limit() and modifies a requested size to respect window sizing limits. so you want to first figure out size you want (x2 - x1) and (y2 - y1) then adjust this new size with e_client_resize_limit(ec, &new_w, &new_h). this will mean the size may change and you need to then appropriately adjust x1 and y1 if hdir or vidir is -1 so the right edge of the window stays where it is but the growing edge is what is limited. :) try grow with terminals... they limit sizing to steps. you will find you end up in stuck situations like you cant grow more horizontally or vertically because size limiting keeps s few pixels before the edge of some other window and thus doesn't become flush and can't grow beyond. you need a strategy to handle this but also still respect max size too, but get the size stepping limit "over the line".

also as a style and bug minimization see my inline comments.


might be best to set vdir and vdir to 0 here and avoid setting them below to 0. this way they are always set to SOMETHING. not needed here strictly but style-wise nicer to avoid bugs.


style-wise strcmps in efl/e do if (!strcmp(...)) :)


it's good practice to do:

((cur->x + cur->w) < ec->x)

getting order of operation always right is not so easy and this is a wonderful source of invisible bugs that are so easy to gloss over like:

a * b + c != a * (b + c)

which did you intend. the left or the right? if you use ()'s it's explicit. is if you intended the left side then

(a * b) + c

is better

raster added a comment.May 3 2021, 8:20 AM

FYI - your patch "fixed" would be something like: P340

and fixed sizing beyond the scree in P341

This revision was not accepted when it landed; it landed in state Needs Review.May 3 2021, 1:01 PM
This revision was automatically updated to reflect the committed changes.