<br><br><div class="gmail_quote">On Sat, Nov 17, 2012 at 4:41 AM, Scott Moreau <span dir="ltr"><<a href="mailto:oreaus@gmail.com" target="_blank">oreaus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div><div class="h5">On Fri, Nov 16, 2012 at 5:32 PM, Kristian Høgsberg <span dir="ltr"><<a href="mailto:hoegsberg@gmail.com" target="_blank">hoegsberg@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>On Thu, Nov 15, 2012 at 01:38:54PM -0700, Scott Moreau wrote:<br>
> On Thu, Nov 15, 2012 at 1:02 PM, Scott Moreau <<a href="mailto:oreaus@gmail.com" target="_blank">oreaus@gmail.com</a>> wrote:<br>
><br>
> ><br>
> ><br>
> > On Thu, Nov 15, 2012 at 12:57 PM, Bill Spitzak <<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>> wrote:<br>
> ><br>
> >> A scheme I have seen is to use 15 (ie all 4 edge flags or'd) for<br>
> >> center-resize. This makes it possible to add 6 (left | right) for "center<br>
> >> resize horizontally" and 3 (top | bottom) for "center resize vertically".<br>
> >><br>
> >> The only values from 1-15 that have no meaning are when 3 edges are<br>
> >> selected.<br>
> ><br>
> ><br>
> > Now that you mention it, I believe I have seen this used somewhere too and<br>
> > it makes sense. As a side note, the algorithm is always the same for<br>
> > resize-from-center regardless if it's horizontal, vertical or both.<br>
> ><br>
><br>
> I was tinkering with this idea and I remember trying it and why it wont fit<br>
> nicely here. We're using resize_from_center as a separate single bit flag<br>
> because it's actually resize state. Trying to make it have the meaning you<br>
> described while maintaining this real-time behavior would require much more<br>
> invasive changes. The edge flags would have to be stored separately because<br>
> we have to remember what edges were set before toggling resize-from-center.<br>
> It's simpler all around to have a single separate flag than try to mix<br>
> everything together and try to decipher how to handle it later.<br>
<br>
</div>Hm, I like the idea of making left|right mean resize horizontally from<br>
center, and trigger that on shift click side of window, and simiarly<br>
for vertical resize from center on shift click top or bottom edge.<br>
Shift click any corner is resize from center for all sides.<br>
<br>
We can just add 'left_right', 'top_bttom' and 'all' enums that are the<br>
bitwise or of left and right etc, and all being 15.  Why would that<br>
not work?  Seem like a pretty elegant approach.<br>
<br>
Kristian<br><br></blockquote></div></div><div><br>Hi Kristian,<br><br>This concept is an interesting one with more to it than meets the eye. I will try to explain my observations.<br><br><br>There's at least two behaviors that can be implemented here: 1) Set resize-from-center edge flags when the grab is initiated. 2) Set resize-from-center flags dynamically. With 1), you will have to end up creating a new binding, for mod+shift+button0 so you'll end up with two separate resize bindings. With 2), which is what this patch does, you can toggle resize-from-center while still holding a grab, with shift key.<br>

<br>Regarding the flags: With 1), having top_bottom=3, left_right=12 and all=15 would work. You'd still end up with two resize bindings.</div></div></blockquote><div><br>I did not thoroughly test this and I see it wont work. Here's why. The way resize-from-center works is:<br>
<br>1) shell.c: Compute an offset depending on which edge. It uses the existing code and stores the size difference in an offset.<br>2) shell.c: If resize-from-center mode is active, multiply the offset by two<br>3) window.c: If resize-from-center mode is active, the client always computes an x/y offset and divides these by two, respectively<br>
<br>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. I didn't catch this because I only tested on left edge, which happened to be the case that was used. On right edge, the action is reversed. In other words, a single edge means the edge that was clicked on, to determine the algorithm to use in client and compositor. If you set multiple conflicting edges, you can't know which edge the grab is on. So regardless if you do 1) or 2), to structure the bits so they seem to sit more comfortably means you'd need an additional edge variable in the shell plugin at least, and more code to do the edge tracking work.<br>
<br><br>Scott<br></div></div>