Border grips for windows

Attached is a contribution, if someone wants to submit it: it enables
resizing of windows via their edges (border grips)

Stef

On 19.04.2010, at 22:54, Stéphane Rollandin wrote:
>
> Attached is a contribution, if someone wants to submit it: it enables resizing of windows via their edges (border grips)
>
> Stef
> <border grips.cs>

That would be awesome!

I tried it in a fully updated trunk image, and it works rather unreliably. All 4 corners work fine but not the edges, most of the time. I opened a new window, does this need any other initialization?

- Bert -

I did not see any bug in the latest 4.1 release.

The border grips are rather small, so it is easy to miss them; they are
also invisible. No extra initialization should be required, but it only
works for new windows.

Stef

> The border grips are rather small, so it is easy to miss them

I forgot to mention that the grips do not extend all over the edges,
only around their middle part, which is different from the behavior of
the splitter grips. Is it what you dislike ?

Stef

On 19.04.2010, at 23:54, Stéphane Rollandin wrote:
>
>> The border grips are rather small, so it is easy to miss them
>
> I forgot to mention that the grips do not extend all over the edges, only around their middle part, which is different from the behavior of the splitter grips. Is it what you dislike ?
>
> Stef

Ah, I see. Yes, I expected them to stretch along the whole edge. If they were only active in the middle, they should have some mark like on the splitters (though I'd personally prefer if they extended all the way).

Also, their extent is off - I wondered why the cursor sometimes changed shape already when not even touching the window yet:




- Bert -

> Ah, I see. Yes, I expected them to stretch along the whole edge. If they were only active in the middle, they should have some mark like on the splitters (though I'd personally prefer if they extended all the way).

I disagree on both points :)

Rationale:

- the middle of an edge is easy to find, no need to mark it (it's ugly
for my taste).

- grips should no stretch along the full edge, because it would make it
too easy to mistakenly resize the window while attempting to bring it up
to front from under another window by grabbing one of its edges (am I
clear here ?).

Of course, both points should be set by preferences, so everybody is happy !


> Also, their extent is off

fixed in the attached changeset

Stef

I filed it in an I like them as well. But with large windows it is not
so easy to find the middle. So I think the active area should be
around 12.5% in length.

I tried to find the place where it is set but did not see it.

It is very natural and I have the impression it has already been
there.............

Hannes

On 4/20/10, Stéphane Rollandin <[hidden email]> wrote:

Le 20/04/2010 18:17, Hannes Hirzel a écrit :
> I filed it in an I like them as well. But with large windows it is not
> so easy to find the middle. So I think the active area should be
> around 12.5% in length.
>
> I tried to find the place where it is set but did not see it.

That's in #defaultWidth and #defaultHeight, but those values are
absolute, not relative to the window size.

> It is very natural and I have the impression it has already been
> there.............

It has... it was in 3.8, and disappeared with the new look in 3.9

Stef

Stéphane,

2010/4/20 Stéphane Rollandin <[hidden email]>:
>
>> Ah, I see. Yes, I expected them to stretch along the whole edge. If they
>> were only active in the middle, they should have some mark like on the
>> splitters (though I'd personally prefer if they extended all the way).
>
> I disagree on both points :)

Wow.

> Rationale:
>
> - the middle of an edge is easy to find, no need to mark it (it's ugly for
> my taste).

The key word here is, "find".  In the first place, the computer has
already let down the user by making him do a resize in the first place
(e.g., the computer should size windows accrording to contents of the
data, but that's another story).

So, now that the software has distracted the user from their domain
just because they must dork-around with the widgetry to be able to
view their domain, we're going to make them "find" the center and aim
the mouse right on it?  I suppose the center could be covered by
another window, so I would involve topping another window

I'm sorry, but this doesn't make a lot of sense to me!

> - grips should no stretch along the full edge, because it would make it too
> easy to mistakenly resize the window while attempting to bring it up to
> front from under another window by grabbing one of its edges (am I clear
> here ?).

Well, would it really be that easy?  Let's see..

  1)  you have to click within the 1 (2 or 3, I hope!) pixel line for
the resize.
  2)  you would have to *drag* it for a resize to occur, right?  But
wait, you said this is the case of the user just trying to top the
window, which is just a click, not a drag.
  3)  the "accidental" drag would have to cover a distance
*perpendicular* to the window edge that is being "accidently dragged",
because dragging parallel would not affect the size of the window.
  4)  EVEN IF, 1, 2 and 3 all occurred, what is the penalty to the
user?  That his window is 1 or 2 pixels different in size because he
accidently held the button down a millisecond too long when attempting
to do a "click".
  5)  If that penalty is so bad, then I suppose, by your logic, we
should watch out because the user could still accidently click in the
center of the resize bar resulting in an accidental resize?  Perhaps
an "Are you sure you want to resize" prompt for the user accompanied
by a Beep??
  5)  Center-resizing is inconsistent with every other windowing
system I've ever seen.  Talk about unfriendly to new users!

The alternative is, for every single resize, I have to 1) find the
center (which may be buried by another window), and 2) aim for it,
carefully (a fine-motor gesture!), 3) click and drag it.

Again, I apologize, but I think your reasoning about requiring a
center click has been obliterated!  :)

> Of course, both points should be set by preferences, so everybody is happy !

Umm, yeah, I guess I'm just not so much into masochism. ;-)   We would
need an option to have it stretch the full extent of the window and
that should be the default for new users coming to Squeak...

Regards,
  Chris

Fine, I actually don't really mind.

I guess my main (implicit) point was that I'm not going to dig any
further since it satisfy me at this point: that's the code that will be
shipped with muO for 4.1, until Squeak catches up... so feel free to
improve my implementation and submit it.

By the way Pharo has full-length grips on windows size, so maye there is
something to get from there.

Stef