<br><br><div class="gmail_quote">On Mon, Nov 19, 2012 at 11:36 AM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>Scott Moreau wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>



</blockquote>
<br></div>
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.</blockquote>


<div><br>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.<br>


 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.<br>


</blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<br>
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.<br>


</blockquote><div><br>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.<br>

<br><br>Scott<br>
</div></div>