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. > I think also if the user then lets the shift key go, they expect to now be > in resize-lower-left mode, though all the programs I tried just go into > resize-from-center mode but you cannot get out of it without letting the > mouse go. > This the behavior that this patch implements. If you look at the short, shift is being pressed and released while left-click-grab is held continuously. > > It sounds to me like the "receiver" of the resize is expected to interpret > shift-up in your scheme. Since the very first thing it has to do is check > this key (as the user may have pressed or released it between when the > event was sent and it started working on it), there is now no reason to > communicate "center" at all. > I assume by "receiver" you mean server? Technically, we don't need checks at all in shell_surface_resize() or reszize_binding() since shift state is checked on each resize iteration and toggles the state accordingly. That is, the way this patch works is, only resize-from-center when shift is held. <mod>+shift+drag doesn't work to initiate resize at all, since bindings must be matched explicitly. i.e. <mod>+button0 != <mod>+shift+button0. Shift+border-edge-click+release-shift will still be in normal resize mode. While grabbed, pressing shift will activate resize-from-center, releasing shift will return to normal resize mode. Scott
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
