[compiz] [PATCH] Resize improvements (Multiple resize modes, better aspect ratio constraining)

[Danny Baumann]

Hi,

> > > 0001-Added-options-for-additional-resize-modes.patch - I think I'll just
> > > leave this patch out and add these options once we converted the resize
> > > plugin to use the new metadata system.
> > 
> > Yes, that's ok as it has the same effect ;-)
> 
> I've done this. The description for this option mentions that it's the
> default resize mode because I think it makes a lot of sense to add match
> options that defines what resize mode to use for a specific window. This
> allow the user to more dynamically choose which resize mode should be
> used. It might also make sense to add specific actions for each resize
> mode so the user can set up shortcuts that will always initiate a
> specific resize mode.

Yes, I fully agree there; but let's add the basis for that first ;-)

> Let's add one resize mode at a time, starting with the outline mode and
> what's necessary to make that work properly. We'll look at the stretch
> mode once that's done. Can you provide a patch against head that only
> adds the outline mode?

Please find it attached. I've splitted it up into 3 smaller ones:

0001-Added-option-handling-for-filled-outline-resize-mo.patch
This one adds the option handling including updating the XML.

0002-Do-not-make-constrainNewWindowSize-depend-on-the-act.patch
This one updates constrainNewWindowSize so that it returns TRUE if the
new calculated size does not match the old, passed size rather than the
window's server size.

0003-Added-outline-and-filled-outline-modes.patch
This one adds the actual logic.

> > The main point the current constraining code is lacking are the
> > following:
> > 
> > 1) ability to apply only a subset of all the constraints (e.g. only
> > applying minimum/maximum size constraints) - no big deal with passing a
> > bit mask to constrainNewWindowSize
> 
> ok, let's fix that. btw, why do we need to only apply a subset of the
> constraints?

My reason for that was that I only wanted to warp the pointer for a
subset of the constraints (not for the resize increment one). After
leaving out that part, the main point is obviously lost ;-)
I still think it might be a good idea to have this for the sake of
flexibility, but perhaps it would be a good idea if the mask would
disable some constraint checks rather than enabling them so in most
cases just '0' would be passed for it?

> > 2) abilitity to resize windows with aspect ratio hint set to other
> > directions than the lower right 
> > The code in the patch (which was taken from Metacity) takes the resize
> > direction into account in order to compute the best possible window size
> > depending on the resize direction. The problem that I see here is: how
> > to pass the direction of resizing to constrainNewWindowSize properly?
> > Perhaps we could pass it using an enum and assume some default behaviour
> > when there is no clear direction (e.g. when called from
> > addWindowSizeChanges).
> 
> Sounds good to me.

Ok, I'll ask the Metacity guys if we get MIT permission for the code
parts I took from Metacity. I'll include this code as soon as we got
permission.

> > > 0007-Avoid-resizing-windows-to-negative-sizes.patch - The constrain size
> > > code should be fixed to take care of this if it doesn't already.
> > 
> > It does, but there is some weird effect when only one coordinate is
> > negative. In my testing, the size (-1|700) became something like (20|
> > 20). I will have a look into this if there is a more appropriate
> > solution than that patch.
> 
> ok, good.

It seems that this problem was a problem of the constraining code I
added as it doesn't happen with the current constrainNewWindowSize code.
I will take care of that when we update constrainNewWindowSize.

> Yes, the resize should finish once server and client processing is done
> and the window can be rendered at the new size. Not doing this for
> stretched resize mode will look awful but there's also no reason for not
> doing this for other resize modes. So all I'm saying is that we
> shouldn't make the stretched mode a special case.

Ok, understood. It's not in the current patches (as it's not currently
needed), but you definitely are right that this doesn't hurt for other
modes as well. What do you think is the correct place for resetting
rd->w - the ConfigureNotify event if rd->w is set and rs->grabIndex is
not?

Regards,

Danny
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Added-option-handling-for-filled-outline-resize-mo.patch
Type: application/mbox
Size: 4353 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/compiz/attachments/20070426/16c27527/0001-Added-option-handling-for-filled-outline-resize-mo-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Do-not-make-constrainNewWindowSize-depend-on-the-act.patch
Type: application/mbox
Size: 1080 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/compiz/attachments/20070426/16c27527/0002-Do-not-make-constrainNewWindowSize-depend-on-the-act-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Added-outline-and-filled-outline-modes.patch
Type: application/mbox
Size: 14011 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/compiz/attachments/20070426/16c27527/0003-Added-outline-and-filled-outline-modes-0001.bin