#173 Window move/resize enhancement
I was alway wondering about the small inconsistency in the window move/resize behavior. First of all opaque resizing is not possible, secondly resizing does not grab display, so the outline frame could make a lot of mess on the screen.
So, I've started to reworking the window engine in order to solve those issues. In the attached file, there is a proposition (mainly the idea, because the code needs some polishing) how this could be achieved.
It would be great if someone will review this patch.
There is one thing I'm not sure about. If passing absolute pointer coordinates into the resize method is a good idea. It simplifies a lot, because right now the pointer tracking logic is the same for move and resize actions. But resize is connected with the intrinsic window properties: width and length..., so I've got mixed fillings about this.
Beyond the opaque resize, I've also "fixed" the CENTER-corner resizing type. However, I'm not sure if I've actually fixed the logic, but definitely I've made it deterministic (please try the current one with window which has hints for minimal width and height - it's total mess). With my change the CENTER resize preserves aspect ratio and does not move window's center. I wonder if anyone is using CENTER resize, because it is not usable right now (imho). So, maybe this should be dropped after all, not fixed.
I've also made one small optimization. I've added isMaximizedAny method which tests against any type of maximization. This might be separate patch, not related to move/resize refactorization.
I've got two not resolved issues with this patch. There seems to be some problem with layers. Sometimes window get stuck in the top layer after maximization/fullscreen - seems like regression. And there is another issue (currently present in the master code) with maximization. When maximization respects hints (!maxIgnoreIncrement) and window can be moved (!maxDisableResize), the hints are withdrawn after move action (reproducible with gvim). There is also one more thing which could be fixed - stop resize action when maximization state is toggled.
opaque resizing: it was never implemented because of the load it puts on the xserver. also, as you figured out, one has to grab the whole xserver .. which then denies processing requests of other clients than fluxbox. a windows, which gets resized, won't be able to update it's contents anyway due to the grab.
outline-messup: yep, can happen. an xrefresh solves that issue, we should call it maybe after the resize is done.
second issue with the hints etc: is that a bug introduced by this patch? or is it existant already in master?
@@ -2923,11 +2935,11 @@ void FluxboxWindow::doSnapping(int &orig_left, int &orig_top) {
Workspace::Windows::iterator it = wins.begin();
Workspace::Windows::iterator it_end = wins.end();
unsigned int bw;
for (; it != it_end; ++it) {
if ((*it) == this)
continue; // skip myself
unsigned int bw;
bw = (it)->decorationMask() & (WindowState::DECORM_BORDER|WindowState::DECORM_HANDLE) ?
(it)->frame().window().borderWidth() : 0;
why?
I think the "has to grab the whole xserver" part is a misinterpretation, he did that for the outline version to prevent artifacts.
About the server load, I'll push a patch to github and make a pull request (no refactoring, only opaque resize - the strategy is to limit the resizes/second with a timer which works nicely even for very slow clients that would create a huge backlog on continuous resizes)