[haiku-development] Re: Ctrl+Alt window management functionality
- From: pulkomandy@xxxxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 22 Jan 2013 21:44:39 +0100
> > 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.
>
> I don't see how it is a moot point because the action requires you to
> use the mouse and keyboard simultaneously and it's not true that there
> are real alternatives, you can only resize a window by the bottom
> right corner and only move a window by the tab, and only if it is in
> focus.
You can RMB drag a border or use the knob, that's two other ways.
You can also use the zoom button that should do the "right thing", and in
that case you don't need to manually resize the window at all.
>
> If you discount ergonomics and discoverability then yes the current
> solution is consistent and works except for the details but I just
> don't see how you are able to do that. To use your language, I
> vehemently oppose any solution that requires the user to perform a RMB
> drag no matter how consistent it is.
We still have no proof that an RMB drag is a problem. Moreover, the primary
way to resize a window is the resize knob, which you can use with LMB drag
perfectly fine. Note this is also available in some GTK applications,
because they tend to have 1px border that are not easy to grab. Same for
OSX, I belive. So, resizing by grabbing the border is something you might
need on windows, and that's it. Moreover, you'll usually grab te window from
a corner so you can resize vertically and horizontally at the same time. And
at this corner, you'll find the resize knob.
> You recognize that despite being consistent the functionality is quite
> hidden, but you don't consider that to be as big an issue as me. What
> is the merit of having "advanced" functionality that will not be
> discovered by the vast majority of users when you could have similar
> functionality that will be discovered by most users?
Using modifier + LMB isn't more discoverable than RMB. I even think it is
less discoverable.
But, what matters is consistency, because it helps remembering stuff. Using
RMB to perform a mouse action is consistent. Using a keyboard modifier is
not. Using the same mouse button in CTRL+ALT and in 'click the border' mode
is consistent.
Using a modifier that's otherwise useful to the app for window management
tasks is not consistent.
>
> > 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.
>
> Okay I am following you here... the borders are confusing.
>
> > 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.
>
> Yes, that sounds like a pretty good solution although I don't see why
> it should be user defined, maybe use a nice light grey partially
> transparent box over the window, (can we do transparency effects?)
> although updating the mouse cursor might be enough.
Greying the whole window sounds quite distracting. The idea behind
highlighting the decorator is that you are working with the window, not the
application contents.
Also, not showing the contents of the window while resizing it makes it hard
to see what you do. And refreshing the window contents while applying an
overlay to it is unlikely to work flicker-free until we get compositing in
the app_server.
> > 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.
>
> Perhaps we could display the LMB action big in the center with the RMB
> action little in the bottom right corner of the cursor. With the
> previously mentioned solution of using ctrl+LMB=RMB this might be an
> ideal solution.
I prefer having both side by side. In this case, they are equally important
actions, not a primary and a secondary one, so they deserve the same screen
space.
>
> > 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.
>
> You are right that I have been referring to the buttons as LMB for
> primary and RMB as secondary assuming a right handed user, that is my
> mistake, of course I meant primary and secondary not left and right,
> please excuse my omission.
Beware: our mouse preflet allows the primary button to be the middle one as
well. This may be a problem for showing cursors side by side, however it's
an unlikely case.
>
> > I think this would make CTRL+ALT+LMB,RMB more intuitive to users,
> > without destroying the current consistency of LMB and RMB behavior.
>
> I do not wish to destroy the current consistency but I would wish
> there would be a different way to accomplish this without using the
> secondary mouse button. You have minimized my reasons but I stand by
> them, dragging with the secondary mouse button is poor UI and should
> be avoided. Let's come up with a solution that is equally consistent
> but uses the primary mouse button instead.
What's wrong with the resize knob ? It's what youshould be using and doesn't
need the RMB.
--
Adrien.
Other related posts:
