[PATCH wayland 1/2 v2] protocol: Add resize from center flag.

[Scott Moreau]

On Sat, Nov 17, 2012 at 4:41 AM, Scott Moreau <oreaus at gmail.com> wrote:

>
>
> On Fri, Nov 16, 2012 at 5:32 PM, Kristian Høgsberg <hoegsberg at gmail.com>wrote:
>
>> On Thu, Nov 15, 2012 at 01:38:54PM -0700, Scott Moreau wrote:
>> > On Thu, Nov 15, 2012 at 1:02 PM, Scott Moreau <oreaus at gmail.com> wrote:
>> >
>> > >
>> > >
>> > > On Thu, Nov 15, 2012 at 12:57 PM, Bill Spitzak <spitzak at gmail.com>
>> wrote:
>> > >
>> > >> A scheme I have seen is to use 15 (ie all 4 edge flags or'd) for
>> > >> center-resize. This makes it possible to add 6 (left | right) for
>> "center
>> > >> resize horizontally" and 3 (top | bottom) for "center resize
>> vertically".
>> > >>
>> > >> The only values from 1-15 that have no meaning are when 3 edges are
>> > >> selected.
>> > >
>> > >
>> > > Now that you mention it, I believe I have seen this used somewhere
>> too and
>> > > it makes sense. As a side note, the algorithm is always the same for
>> > > resize-from-center regardless if it's horizontal, vertical or both.
>> > >
>> >
>> > I was tinkering with this idea and I remember trying it and why it wont
>> fit
>> > nicely here. We're using resize_from_center as a separate single bit
>> flag
>> > because it's actually resize state. Trying to make it have the meaning
>> you
>> > described while maintaining this real-time behavior would require much
>> more
>> > invasive changes. The edge flags would have to be stored separately
>> because
>> > we have to remember what edges were set before toggling
>> resize-from-center.
>> > It's simpler all around to have a single separate flag than try to mix
>> > everything together and try to decipher how to handle it later.
>>
>> Hm, I like the idea of making left|right mean resize horizontally from
>> center, and trigger that on shift click side of window, and simiarly
>> for vertical resize from center on shift click top or bottom edge.
>> Shift click any corner is resize from center for all sides.
>>
>> We can just add 'left_right', 'top_bttom' and 'all' enums that are the
>> bitwise or of left and right etc, and all being 15.  Why would that
>> not work?  Seem like a pretty elegant approach.
>>
>> Kristian
>>
>>
> Hi Kristian,
>
> This concept is an interesting one with more to it than meets the eye. I
> will try to explain my observations.
>
>
> 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.
>
> 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.
>

I did not thoroughly test this and I see it wont work. Here's why. The way
resize-from-center works is:

1) shell.c: Compute an offset depending on which edge. It uses the existing
code and stores the size difference in an offset.
2) shell.c: If resize-from-center mode is active, multiply the offset by two
3) window.c: If resize-from-center mode is active, the client always
computes an x/y offset and divides these by two, respectively

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.


Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20121117/ee792add/attachment.html>