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.
@feature
Details
Details
- Reviewers
devilhorns raster - Commits
- rE835221e29a58: actions: Add 'Grow in Direction...' action
Diff Detail
Diff Detail
- Repository
- rE core/enlightenment
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
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.
| src/bin/e_actions.c | ||
|---|---|---|
| 1128 | 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. | |
| 1131 | style-wise strcmps in efl/e do if (!strcmp(...)) :) | |
| 1199 | 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 | |