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
0001-Added-option-handling-for-filled-outline-resize-mo.patch
Description: application/mbox
0002-Do-not-make-constrainNewWindowSize-depend-on-the-act.patch
Description: application/mbox
0003-Added-outline-and-filled-outline-modes.patch
Description: application/mbox
_______________________________________________ compiz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/compiz
