[haiku-development] Re: Ctrl+Alt window management functionality

  • From: pulkomandy@xxxxxxxxxxxxx
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 20 Jan 2013 10:04:29 +0100

> On Sun, 20 Jan 2013 00:39:39 -0500 John Scipione wrote:
> > I understand that you (Ingo and Humdinger) are partial to the current
> > behavior so here is my new idea. What if I were to make the window
> > borders perform a resize instead of a pan with no keys held?
> 
> I have no problems with that, not having moved or resized a window by
> border/corner for many months now. Also, new users will find that
> easier, because, as you say, their other OS probably does it the same
> way.

I prefer the borders to move the window. I tend to move windows in such 
ways that the title bar can't be reached anymore (either because it is out 
of screen, or below another window), but I can still grab the window by 
it's border which is almost always visible in at least one side.

> > Why would ESC cancel a drag? Just lift the mouse button. Maybe I'm
> > missing something...
> 
> You miss that when you have dragged/resized a window and release the
> mouse button, your window will have been moved/resized. Pressing ESC
> could snap the window to it's position/size before the drag was
> initiated. :)

if you do this AFTER the drag, it means the ESC key can't be used for 
anything else, right ? I'd say if you mistakenly press ESC some minutes 
after resizing the window, and it goes back to a very old size, that would 
be confusing.
I don't think I ever wanted to do this. It's easy enough to move/resize the 
window again. We could help that further by adding some sticking borders. 
We have these on the edges of the screen, but not between windows yet I 
think. (try it, look how you can easily put a window just in the corner of 
the screen because the system will help you align it, but still allow you 
to move it elsewhere if you really want).

Anyway, I'd rather fix the behaviour of the zoom button to do the same 
things in all applications. It should be :
 * First click: size the window so all the content can be seen (for 
example, ShowImage should scale to the image inside it, BePDF should scale 
as big as possible but keep the aspect ratio of the current page, etc.)
 * Second click: restore to size before first click.

With this working properly, you don't need to manually resize windows that 
often, which is why the resize knob isn't that easily reachable. 
Unfortunately, many applications use a behavior similar to the "maximize" 
button of other operaring systems. This make the window take the whole 
screen, needlessly hiding other windows and wasting space. Note that 
maximizing a window using the resize knob is easier than sizing it to the 
contents, which is another reason for the latter being automated.


I'd also like to point out the way the WindowLab window manager on unix 
does the resizing. You hold a key modifier and no mouse buttons, and you 
push the borders of the active window using the mouse pointer. This means 
you cna resize all sides at once, but only growing the window (if your 
cursor is inside) or shrinking it (if the cursor is outside). Maximizing a 
window is done by putting the cursor inside, pressing the modifier, and 
circling the mouse to push all borders to the edges of the screen. I think 
that's faster than our current solution, and avoids the problem of knowing 
which border you're closer to when resizing. However, it has the problem of 
being incompatible with focus-follows-mouse, because in this case the 
pointer can't be outside the window. Maybe this could be improved with 
requiring a mouse click. Something like :

 1 Hold Command+Option to enter resizing mode. Borders are highlighted
 2 Move mouse inside or outside the window
 3 Click and push the borders as you want
 4 Repeat steps 2/3 as many times as needed
 5 Release Command+Option

-- 
Adrien.

Other related posts: