[haiku-development] Re: Ctrl+Alt window management functionality
- From: Matt Madia <mattmadia@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 21 Jan 2013 19:01:17 -0500
On 1/21/13, pulkomandy@xxxxxxxxxxxxx <pulkomandy@xxxxxxxxxxxxx> wrote:
>> How about LMB on the border performs a move, and option key+LMB
>> performs to a resize, good compromise?
>
> RMB already performs a resize. You think this is not easy to reach, and want
>
> to replace it with a key + LMB ? I think this is only change for the purpose
>
> of change now. RMB drag is easier than LMB drag + a key.
>
> So, we already have a good compromise.
Exactly. This is why I vehemently oppose you changing the LMB or RMB
functionality with regards to moving the window or resizing it.
(Altering the visual appearances during CTRL+ALT is something I agree
with and even have some suggestions further below.)
Changing the behavior of LMB and RMB would be breaking consistency in
order to "fix" a problem by implementing an improper solution.
To put it bluntly, arguing to change behavior of LMB, RMB, CTRL+ALT on
"poor discoverability" (or even ergonomics) is a moot point.
By needing to control two devices (a pointer and a keyboard), CTRL+ALT
is advanced, we cannot demand users to use it as the only or primary
means.
CTRL+ALT is alternative because there are other means to achieve the
same effect.
To be clear, those other means only require either 1. just a LMB on
the title bar or resize corner. 2. LMB or RMB on window border
The 1st is quite discoverable and easy to accomplish.
The second is slightly less discoverable and slightly less easy to
accomplish (after all, a second mouse button is needed).
Using CTRL+ALT is even less discoverable and even more difficult to perform.
However, there is a strong consistency between all three. That should
be maintained.
Okay, on to addressing the highlighting of CTRL+ALT...
(Aside from Stack and Tile) there are no instances where the window
border becomes highlighted for window management.
(For SAT, I cannot think of a more intuitive method to convey "these
two parts will stick together".)
So, let's remove the border highlighting for CTRL+ALT and replace it
with something more descriptive.
Next, let us recall that upon CTRL+ALT, the entire application window
can receive and properly trigger a LMB, RMB. This includes the frame,
title bar, resizer corner, window border, ...,
So, upon the CTRL+ALT keypress, a grey (or some other system/user
defined color) transparent mask could be drawn over the entire
application window.
This will hopefully convey the entire application window is a uniform
canvas wrt CTRL+ALT+LMB,RMB.
That should also convey the notion of "CTRL+ALT will act differently
than the standard window behavior".
For differentiating beteween CTRL+ALT+LMB and CTRL+ALT+RMB, ...
First, during that key press, there is no need to convey presice
pointer location.
After all, the entire application window will respond to a LMB, RMB.
So this affords us the opportunity to repurpose the mouse cursor into
a more informative role.
I'm curious if it is feasible to draw two mouse cursors side by side
at the same time.
One (e.g., a 4 directional arrow) to convey moving the window.
Another to convey "In this current pointer location, the window can be
resized on the east border only".
Obviously, that second cursor would change, depending on the location
of the pointer.
The positioning of these dual cursors (i.e. which one is drawn on the
left and the right) would be dependant on the user's current mouse
configuration (i.e., left handed vs right handed configuration).
In the case of single button devices, only the LMB cursor would be shown.
I think this would make CTRL+ALT+LMB,RMB more intuitive to users,
without destroying the current consistency of LMB and RMB behavior.
--mmadia
Other related posts:
