ALT+CTRL on border could resize a window

[humdinger]

This is around hrev32100...

As you may know, ALT+CTRL and a left-click'n'drag anywhere in a window, will move it, with a right-click it'll send it to the back. Nice!

How about having a ALT+CTRL and a left-click on a window's border resize the window from this border?
Having only the bottom-right corner as single point for resizing has been an annoyance back in BeOS times and it sure still is.

The above suggested way would be consistent, if a bit hidden. But every system as tricks that just have to be learnt somehow...

(When reworking the shortcut system we can think of unifying a few system-wide shortcuts. For example, I'd really love to invoke queries without having a Tracker window active. Maybe OPT+F (OPT=WIN key). And all the other system-related stuff like the moving/resizing/back-sending also with a simple OPT+click. But that's a discussion for another time.)

[leavengood]

I am working on this now.

[humdinger]

Before I start baking its first birthday cake... How are you doing with that, Ryan?

[leavengood]

Well I did start working on it way back when, and I got it partially working, but things got complicated when trying to resize from the top or left (which really ends up being a simultaneous move and resize.) The internal app server code wasn't set up for that then, and it may still require some changes. I did get some advice from Stephan about it, but I obviously never got back around to it.

I may not get much of a chance to work on it for a while, so if someone else really wants to they should feel free. I don't think what I worked on so far was all that complicated (mainly keyboard checks for the ctrl alt.) So I don't know if a patch is worth it, in terms of someone continuing my work. I will probably get back on this eventually though, when my current projects in other areas of life get finished up.

[humdinger]

OK. I would still very much like to see this feature (maybe even with a virtually enlarged "hot zone" so you wouldn't have to aim that precisely on the small border, see this old ​illustration).

You think it might be better to release ownership for this ticket for the time being? You can still grab it once more when you find the time and nobody else got it working.

[leavengood]

Removing my ownership as requested.

[bonefish]

Just to add my opinion: Ctrl+Alt quite consistently makes the whole window behave like the tab. I'd find it a bit weird, if the border, which normally already behaves like the tab, would work differently when Ctrl-Alt is pressed.

[leavengood]

Replying to bonefish:

Just to add my opinion: Ctrl+Alt quite consistently makes the whole window behave like the tab. I'd find it a bit weird, if the border, which normally already behaves like the tab, would work differently when Ctrl-Alt is pressed.

It might indeed be one of those annoying surprise moments for the user when they happen to click the border when trying to do a whole window move while pressing Ctrl+Alt and get a resize instead. I suppose we could consider another keyboard combo. I'll let Humdinger make his case because I'm ambivalent.

[humdinger]

Replying to bonefish:

Just to add my opinion: Ctrl+Alt quite consistently makes the whole window behave like the tab. I'd find it a bit weird, if the border, which normally already behaves like the tab, would work differently when Ctrl-Alt is pressed.

Ah... That is, dear Ingo, because you're working with a limiting definition. :)
See CTRL+ALT not as window-behaves-like-tab, but as general window managing shortcut. You have CTRL+ALT+Cursor to switch workspaces, add SHIFT to take the active window with you. You have CTRL+ALT+Z to alternative-size, CTRL+ALT+M to minimize, CTRL+ALT+H to hide all the app's windows etc.

CTRL+ALT plus border-click is just another window managing shortcut.

Replying to leavengood:

It might indeed be one of those annoying surprise moments for the user when they happen to click the border when trying to do a whole window move while pressing Ctrl+Alt and get a resize instead.

First off, how many times will the user be surprised? Then, why should a user invoke CTRL+ALT when clicking on a border to move/send-to-back a window when that can be accomplished without touching the keyboard with a simple click on the border. CTRL+ALT can be considered the switch that invokes an alternative behaviour of a window.

Also, I think changing the mouse-pointer could help the user to anticipate behaviour: When pressing CTRL+ALT the pointer could sport resizing arrows when above a border, or a move-symbol when anywhere else above a window.

[stippi]

Well, if *that* didn't convince y'all, then I don't know what.

[Meanwhile]

If it takes that horrific 'hot zone' concept off the table, then I'm convinced :)

[bonefish]

Replying to humdinger:

Replying to bonefish:

Just to add my opinion: Ctrl+Alt quite consistently makes the whole window behave like the tab. I'd find it a bit weird, if the border, which normally already behaves like the tab, would work differently when Ctrl-Alt is pressed.

Ah... That is, dear Ingo, because you're working with a limiting definition. :)
See CTRL+ALT not as window-behaves-like-tab, but as general window managing shortcut. You have CTRL+ALT+Cursor to switch workspaces, add SHIFT to take the active window with you. You have CTRL+ALT+Z to alternative-size, CTRL+ALT+M to minimize, CTRL+ALT+H to hide all the app's windows etc.

CTRL+ALT plus border-click is just another window managing shortcut.

I use none of the shortcuts, since I so far I can live pretty well with the pre-existing alternatives (e.g. why Ctrl-Alt-Cursor when I can use Cmd-Fx? Though, I guess in a mouseless work flow the other shortcuts probably are handy). The main problem the introduction of the Ctrl-Alt-mouse actions solved for me is the possible unavailability of the window tab in FFM mode. With Ctrl-Alt I can just throw the mouse cursor in the general direction of the window to perform the action -- no need to aim for the rather small border (if it is visible at all). My concern is that by making the borders behave differently that work flow could be hampered again by the possibility of accidentally hitting the border region (I assume that region would also be enlarged to make hitting it less fiddly, right?).

I suppose one would have to implement the feature and test whether this is a justified concern, but usually getting a feature removed is significantly harder than vetoing it being added. I also wonder, whether it wouldn't be better to have an explicit resizing mode (activated somehow) that would sectorize the complete window area into zones for resizing. I imagine this would be more convenient than aiming for the border regions, even if they are enlarged.

[humdinger]

Replying to bonefish:

I use none of the shortcuts, since I so far I can live pretty well with the pre-existing alternatives (e.g. why Ctrl-Alt-Cursor when I can use Cmd-Fx? Though, I guess in a mouseless work flow the other shortcuts probably are handy).

Moving through workspaces spatially has it's charms. I wouldn't want to miss it.

With Ctrl-Alt I can just throw the mouse cursor in the general direction of the window to perform the action -- no need to aim for the rather small border (if it is visible at all). My concern is that by making the borders behave differently that work flow could be hampered again by the possibility of accidentally hitting the border region

The question is how big are the chances to hit a border accidentally - I suspect low - and in case it isn't, would you be inconveniences unacceptably if you aim just a little bit when "throwing the mouse" around. :)
For me, and I suspect many others, being able to resize windows besides the bottom-right corner would make window management considerably more pleasant.

(I assume that region would also be enlarged to make hitting it less fiddly, right?).

I'd like that, but Meanwhile for instance, doesn't. That would also exaccerbate your concerns of hitting a border and resize instead of moving.

I also wonder, whether it wouldn't be better to have an explicit resizing mode (activated somehow) that would sectorize the complete window area into zones for resizing. I imagine this would be more convenient than aiming for the border regions, even if they are enlarged.

That's a nice thought as well. The one counter argument is that you'll have one more keycombo to memorize. Having one universal window managing combo of CTRL+ALT is very elegant IMO.

[bonefish]

Replying to humdinger:

Replying to bonefish:

With Ctrl-Alt I can just throw the mouse cursor in the general direction of the window to perform the action -- no need to aim for the rather small border (if it is visible at all). My concern is that by making the borders behave differently that work flow could be hampered again by the possibility of accidentally hitting the border region

The question is how big are the chances to hit a border accidentally - I suspect low - and in case it isn't, would you be inconveniences unacceptably if you aim just a little bit when "throwing the mouse" around. :)

I think the thing is that I rarely resize windows (my editor windows have a fixed size and Tracker windows remember theirs), but I move them very often. So, at least for me, it's a potential inconvenience for a frequent task vs. a small convenience for an infrequent one. And if the resize regions are to be just as big as the border regions, the additional convenience is very small IMO, at least for windows that have an actual resize corner.

For me, and I suspect many others, being able to resize windows besides the bottom-right corner would make window management considerably more pleasant.

I don't disagree. I'm just wondering whether there's a better method than one that doesn't offer that much of a benefit and potentially interferes with another action.

(I assume that region would also be enlarged to make hitting it less fiddly, right?).

I'd like that, but Meanwhile for instance, doesn't. That would also exaccerbate your concerns of hitting a border and resize instead of moving.

Yep, my point exactly.

I also wonder, whether it wouldn't be better to have an explicit resizing mode (activated somehow) that would sectorize the complete window area into zones for resizing. I imagine this would be more convenient than aiming for the border regions, even if they are enlarged.

That's a nice thought as well. The one counter argument is that you'll have one more keycombo to memorize. Having one universal window managing combo of CTRL+ALT is very elegant IMO.

Well, how about a different mouse button then? Unless I miss something the middle mouse button doesn't have any actions associate with it yet and for the right button only the click is used. Either button would allow enlarged resize regions without interfering with anything else. The only drawback would be that the mouse cursor shape couldn't indicate the action until one presses the respective button. OTOH I don't see why the app server couldn't draw helpful feedback directly on top of the window (or its border at least).

[humdinger]

Replying to bonefish:

Well, how about a different mouse button then? Unless I miss something the middle mouse button doesn't have any actions associate with it yet and for the right button only the click is used. Either button would allow enlarged resize regions without interfering with anything else.

Good thinking! I suggest using RMB instead of MMB as there's no MMB on many notebooks. So how about this:

• CTRL+ALT+LMButtonDown anywhere: change mousepointer, dragging moves window.
• CTRL+ALT+RMButtonDown anywhere: change mousepointer, dragging resizes window.
  • dragging right: resize right border
  • dragging left: resize left border
  • dragging up: resize top border
  • dragging down: resize bottom border
  • dragging diagonally: resize the respective corner
• CTRL+ALT+RMButtonUp: if mouse wasn't moved (much) since RMButtonDown, send window to back.

The RMB thing may take some getting used to, as the send-to-back will then kick in only when releasing the mouse button and upon the click-down. A very small price, I think.

The only drawback would be that the mouse cursor shape couldn't indicate the action until one presses the respective button. OTOH I don't see why the app server couldn't draw helpful feedback directly on top of the window (or its border at least).

The above mouse button action would not rely on a border at all anymore. Which is nice because a theme could make the border arbitrarily small. Some app_server eye-candy could be nice but isn't essential. Usage looks pretty straight forward. One day we may have some nice shortcut customizing in place, so people with many mouse buttons could even assign the above actions to avoid the CTRL+ALT combo.

[bonefish]

Replying to humdinger:

• CTRL+ALT+RMButtonDown anywhere: change mousepointer, dragging resizes window.
  • dragging right: resize right border
  • dragging left: resize left border
  • dragging up: resize top border
  • dragging down: resize bottom border
  • dragging diagonally: resize the respective corner

There's a mismatch between the number of resizing actions that should be possible -- 4 borders x 2 directions each (inwards/outwards) -- and the number of mouse movement directions -- 4 directions (ignoring diagonal movements). I don't think one can get around using the click position to specify what border(s) to move.

[humdinger]

Replying to bonefish:

There's a mismatch between the number of resizing actions that should be possible -- 4 borders x 2 directions each (inwards/outwards) -- and the number of mouse movement directions -- 4 directions (ignoring diagonal movements). I don't think one can get around using the click position to specify what border(s) to move.

One could determine what direction to resize with the mouse movement right after the right-click, i.e. first move is to the right -> right border is moved along with the mouse. To move another border you'll have to release the mouse button before right-clicking again.

[stippi]

Replying to humdinger:

One could determine what direction to resize with the mouse movement right after the right-click, i.e. first move is to the right -> right border is moved along with the mouse. To move another border you'll have to release the mouse button before right-clicking again.

This idea has big disadvantages:

1) After the initial click, it is very likely that the user moves the mouse unintentionally in a random direction (slightly). Especially when using a tablet input device.

2) You may want to move either border in two directions: For example when you click anywhere in the window and move the mouse downwards (assuming intentionally), it could mean you want to shrink the window by the top border, or it could mean you want to grow the window by the bottom border.

[humdinger]

No 1) might be a matter of a fine-tuned algorithm. You'd have to average over a long enough distance if the pointer doesn't leave a 360/8=45° corridor for to long. Doesn't sound impossible to me (pfft amateur :) ). Normally, I'd expect a tablet user to be esp. apt at drawing a rather straight line.

No 2): After the direction in 1) was determined, only the border/corner in that direction is moved. So, if that initial direction was down, you'll move only the bottom border when moving up and down (left and right are ignored), until you release the mouse button.

[stippi]

So solving 1) means there will be a delay before it is decided which border is moved.

I am not sure you fully understand the implications of 2). If I want to move the top border downwards, I have to first move the mouse up, so the algorithm choses the top border to be moved, then move the mouse down because I wanted to shrink the window from the top border.

It would appear that together with the solution for 1), it becomes quite a usability mess.

[humdinger]

Yes, there will be a slight delay until the direction of the mouse is recognized. But that will immediatly result in a moving of the particular border/corner. I don't see the usability mess: click, move toward the destination-border/corner and the destination will move. Sure, it'll first enlarge the window and you have to track back if you really want to shrink, but I can imagine one's muscle memory will adapt to that quickly. I could be totally wrong though... :)

​Here is a little graphic to see if this choosing the direction by tracking of initial mouse movement would work for you when using a touchpad, tablet, mouse. If you feel it's difficult to stay in one "octant" it's a bad solution. It also gives some indication how long a way the mouse would have to be tracked until the direction is clear, and therefore the resulting delay.

[bonefish]

Both discussed resizing methods are implemented in hrev39656 for "side by side" comparison. Humdinger's method on middle-click, the other one is on right-click.

[humdinger]

There's nothing better than a direct comparison. I'm now convinced my suggestion is not as nice as the other one. Moving to the corner/border that should be resized feels much more natural and is done fast enough. The occasional mis-navigation of the MMB version OTOH is a bit annoying. Maybe one gets better over time, but it doesn't seem to be worth it. So, I stand corrected and hope Ingo forgives me for causing him more work...

The blue border selection isn't that nice, of course. With the S&T's red and the normal yellow tabs, Haiku becomes a bit... colourful. :)
Maybe S&T and the Resizing Management should use the same colour scheme. I don't think that would lead to confusion. I've played around in WonderBrush a bit, and what I find quite pleasing - please don't hit me - is a discreet slow pulsing of borders/tab becoming slightly darker tinted. By having this kind of unobtrusive animation, the actual brightness-difference doesn't have to be as crass because the change draws the eye.

[bonefish]

Replying to humdinger:

There's nothing better than a direct comparison. I'm now convinced my suggestion is not as nice as the other one.

That was quick. :-)

Moving to the corner/border that should be resized feels much more natural and is done fast enough. The occasional mis-navigation of the MMB version OTOH is a bit annoying. Maybe one gets better over time, but it doesn't seem to be worth it.

The threshold the algorithm uses could be increased to reduce the chance of mis-navigation, at the cost of a later response. In case you want to play with it, that would be in ​this line. The numbers are the squares of the distances (i.e. 4 and 8 pixels) the mouse has to travel before the respective phase (an initial jitter phase and a phase for determining the direction) is completed.

Unless objections are raised I would consider the method scheduled for removal.

So, I stand corrected and hope Ingo forgives me for causing him more work...

No worries, it wasn't that much work and I was interested to see how it feels myself, too.

The blue border selection isn't that nice, of course. With the S&T's red and the normal yellow tabs, Haiku becomes a bit... colourful. :)
Maybe S&T and the Resizing Management should use the same colour scheme. I don't think that would lead to confusion. I've played around in WonderBrush a bit, and what I find quite pleasing - please don't hit me - is a discreet slow pulsing of borders/tab becoming slightly darker tinted. By having this kind of unobtrusive animation, the actual brightness-difference doesn't have to be as crass because the change draws the eye.

*cough* Yeah, I thought briefly about introducing animation, but decided that doing it properly would be a bit more work than I was willing to invest. I also thought about using the same color scheme as S&T, but TBH I find that a bit too aggressive. But please, by all means, feel free to change the scheme to something more consistent and pleasing. The colors are selected in the GetComponentColors() methods of the ​DefaultDecorator and the ​SATDecorator. They are mostly set/pre-computed in the constructor or statically, save for the resizing border highlighting, which is ​computed on the fly.

[Meanwhile]

I also think that the same colour for these two would be OK.

However, IMO the red colour for Stack and Tile doesn't work very well.

S&T and Resizing Management have in common that they need a 'keypress & drag' combination. That also means that the chances that they occur by accident are virtually zero. So, the user is expecting something as a result of what he consciously chose to do, and only needs a visual confirmation of it (by colour).

In such a case (with such a user's state of mind), a green colour would suit better than red, since red psychologically says 'Stop', 'Look out', 'Error', 'Warning' etc.

And Humdinger, you already saw it coming ("please don't hit me") so I'll be soft on you this time, "unobtrusive" pulsating animations belong to the discount section of the Annoying Bells & Whistles Store's Baroque department, IMHO...

If you really want to use Pulses, for a good user experience you should limit the use of them to ongoing processes that end by itself.

For instance, Mac OSX's system shutdown has a two minute delay that's announced by a window.

This window has a button that you can click if you want to shut down the PC by yourself (and don't want to wait before the two minutes are up). This button is animated as a pulse, with a very appropriate one second (or so it seems) interval.

As with the red colour from Stack and Tile, a pulse in Resizing Management expresses way too much urgency for the situation, since there is no time limit. The pulse would not only have no real function, it would suggest urgency that doesn't exist. This means a disturbance in the user's work flow, as a result of confusion. I know Zeta had it, and I remember what impression it left on me (not very positive).

[Meanwhile]

In fact, thinking about it some more, in Resizing Management there's no need at all to accentuate the window. Just like the resizing method using the window's lower right hand corner's 'Grippy' area doesn't use and need any colour accents.

With Stack and Tile it's different, because there you have to give visual feedback over the exact moment when the user is free to start the 'drop' phase in his drag 'n drop action...(and what better colour for a 'you're free to go' message than green?)

[humdinger]

Replying to Meanwhile:

And Humdinger, you already saw it coming ("please don't hit me") so I'll be soft on you this time,

"If you strike me down, I shall become more powerful than you could possibly imagine. " :)

Anyway, you could be right about the pulsating thing... :)

In fact, thinking about it some more, in Resizing Management there's no need at all to accentuate the window. Just like the resizing method using the window's lower right hand corner's 'Grippy' area doesn't use and need any colour accents.

While here you are of course totally wrong, you inadvertendly stumbled upon a nice idea. :) A visualization is indeed needed, because contrary to the familiar resize-corner, the keycombo-resizing depends on where your mouse pointer sits in the window.

Now... 'Grippy area'. There's an idea. How about making the moving borders 'grippy'? The metaphor doesn't fit 100%, because in this case you don't actually have to grab the border, as thanks for the keycombo, you can do a kind a 'telegrabbing'.
The implementation is of course much more difficult, I expect, than simple changing colours. (Which I haven't had the time yet to play with, Ingo...)

[Meanwhile]

Ah well, just start without things and only add them if you really see a practical need arising. Good luck!

[bonefish]

Replying to humdinger:

Now... 'Grippy area'. There's an idea. How about making the moving borders 'grippy'? The metaphor doesn't fit 100%, because in this case you don't actually have to grab the border, as thanks for the keycombo, you can do a kind a 'telegrabbing'.

I think this would be the wrong feedback, because unlike it would suggest you cannot grab the border with the left mouse button.

Moreover I think the visual change would be too subtle for the purpose. I want, without having to actually look at the borders (because it's the mouse cursor I'm tracking), see when the desired borders are activated. I'm already not so sure that the current visual change is perceptible enough.

The implementation is of course much more difficult, I expect, than simple changing colours. (Which I haven't had the time yet to play with, Ingo...)

Well, it all happens in DefaultDecorator, the code for drawing the borders in _DrawFrame(). Knock yourself out! :-)

[humdinger]

Alright. I have only managed to change the colour of the borders for resizing. Personally, I'd prefer to simply darken them by -120:

This gives a maximum difference without clashing too much with any background. But since the borders are quite small, it still doesn't draw much attention anyway...

I could imagine S&T could be the same colour scheme, i.e. the yellow tab becoming a dark grey gradient and the black title inverting to white. Until now I haven't even managed to change the default red... :) Changing values of rgb_color kHighlightFrameColors[6] doesn't seem to cut it.

[humdinger]

grey resize border

[Meanwhile]

Replying to humdinger:

I could imagine S&T could be the same colour scheme, i.e. the yellow tab becoming a dark grey gradient and the black title inverting to white. Until now I haven't even managed to change the default red... :) Changing values of rgb_color kHighlightFrameColors[6] doesn't seem to cut it.

Don't bother, there's a seperate ticket (#6928) for it now, suggesting things could be arranged through the Appearance preflet. This might also be an approach for your Resizing Management (as far as colours are concerned).

[bonefish]

Replying to humdinger:

Alright. I have only managed to change the colour of the borders for resizing. Personally, I'd prefer to simply darken them by -120:

Works for me.

I could imagine S&T could be the same colour scheme, i.e. the yellow tab becoming a dark grey gradient and the black title inverting to white. Until now I haven't even managed to change the default red... :) Changing values of rgb_color kHighlightFrameColors[6] doesn't seem to cut it.

Those are used for the window frame only (i.e. the borders) used for the "tile" confirmation effect. The tab colors are defined by the unsurprisingly named kHighlightTabColor* constants. :-)

If those shall be user-configurable, they must become members (well, actually that could be handled more cleverly, but for the time being it's OK, I suppose) and be fetched/computed in the constructor, as done in DefaultDecorator.

[bonefish]

Removed Humdinger's resizing method in hrev40060. Closing the ticket -- the requested feature is fully implemented. Aesthetical improvements are welcome, but no need to keep the ticket open.

[Meanwhile]

Just remarking that a change of colour (as happened in this case with the highlighted border colour going from grey to purple) should also be announced here instead of being silently implemented. Colour, even colour in itself, is an important enough element which can make or break the feel of functionality (where 'feel of functionality' = functionality).