Attached is a contribution, if someone wants to submit it: it enables
resizing of windows via their edges (border grips) Stef border grips.cs (4K) Download Attachment |
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 - PastedGraphic-3.png (24K) Download Attachment |
> 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 border grips.1.cs (5K) Download Attachment |
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: > >> 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 > |
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 |
In reply to this post by Stéphane Rollandin
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 |
Free forum by Nabble | Edit this page |