[haiku-development] Re: Ctrl+Alt window management functionality
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 26 Jan 2013 09:35:45 +1300
John Scipione <jscipione@xxxxxxxxx> wrote:
>On Fri, Jan 25, 2013 at 4:26 AM, Ingo Weinhold <ingo_weinhold@xxxxxx>
>wrote:
>> I introduced the border highlighting because it is needed. Humdinger
>and I
>> were hoping you would replace/improve the indication, not remove it
>> altogether. That seriously cripples the feature IMO.
>
>Oh dear. Worse come to worse we can bring the border highlighting
>back. Try the current functionality out first and see if you think it
>is acceptable.
I can't try it ATM, but I don't see how it would be different from before I
implemented the border highlighting.
>I removed it because I am trying to show what action will take place
>via the mouse cursor only. Since this is a RMB action there isn't a
>good way to indicate the action until you click. This is one of the
>reasons I oppose RMB drags in the first place, they have poor
>discoverability. The only reason to bring the border highlighting back
>is to improve discoverability but it doesn't tell you too much since
>it still won't indicate the RMB action, you just have to know it.
Maybe you're using the word discoverability with a different meaning. To
clarify: The main purpose of the border highlighting was not to let new users
discover the feature (it doesn't do a particularly for job in this respect,
besides due to having to press CTRL-CMD first the functionality is hidden
anyway). I added it mainly to make the feature reasonably efficient.
Especially when the window isn't that large the sectors get relatively small
and the highlighting helps with aiming. Without it you have to make sure you
move the mouse very clearly into the desired sector (i.e. very close to the
border or the corner) to avoid risking initiating the wrong action. That slows
the whole thing down considerably.
An improved indication could e.g. draw a little mouse in the center of the
window with the right button highlighted and around it the resize sectors, with
the active one highlighted. That would improve both discoverability and
aesthetics and maybe even efficiency (due to the indicators being larger and
easier to see).
While compositing support might make that easier to implement, it shouldn't be
to hard now either. The app server supports the "draw on top of child views"
functionality already and drawing the indication wouldn't be too different from
that. The people more familiar with the app server implementation may want to
comment on that.
>What we really need is a key combo that displays the resize arrows
>before you click.
I disagree with the "really need" part. Regular mice have at least two buttons
and I don't see why we shouldn't make use of the secondary. As I wrote before,
I wouldn't mind a modifier+LMB to emulate the RMB, but I would use the RMB in
the first place.
CU, Ingo
Other related posts:
