On Mon, Nov 19, 2012 at 12:10:09PM -0700, Scott Moreau wrote: > On Mon, Nov 19, 2012 at 11:36 AM, Bill Spitzak <[email protected]> wrote: > > > Scott Moreau wrote: > > > > Because resize-from-center depends on knowing what edge was actually > >> clicked on, setting both left and right bits simultaneously means that both > >> left and right cases will be hit, and whichever sets the offset last, wins. > >> > > > > You should be able to tell "which" edge by what side of the original > > center the mouse is on. So if the user grabs the top-right corner and then > > moves the mouse so that it is to the lower-left of the center, they are now > > dragging the bottom-left corner. The few things I have that do > > resize-from-center (drawing programs are all I can find) work exactly this > > way. > > > My point is that we're not confined to a single byte of data to store edge > flags. We have plenty of room to store additional flags. I agree that it > would be a nice way to structure the data, I don't think it warrants the > additional code required to support it. By dedicating a single bit to > 'resize opposing edges', you're avoiding all the code that would have to be > in place to detect the grabbed edge, regardless if you store it in a > different edge mask or compute the pointer position against the original > center, later.
Ah, right I see the problem now. How about we leave it entirely to the compositor to implement resize from center behavior when shift is clicked? No changes to the protocol, just make the compositor do resize from center when shift is held down. Metacity has a similar move/resize behavior where it restricts the position/sizes to only those that align with other edges when shift is held down. This works regardless whether the resize was started from clicking the frame, alt-left/middleclick or a _NET_WM_MOVERESIZE message. Kristian _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
