Re: Window controls for GNOME 3

[Andreas Wallberg <andreas wallberg gmail com>]

Hi Marcel & Co!

Is this discussion moving into tiling? I suggested a while back to
have a simple user-configurable per-workspace grid for windows tiling,
something along the guide lines (no pun intended) in programs like
Gimp and Inkscape. For this idea, the max button would indeed be very
important. This is a very basic mockup:

http://dl.dropbox.com/u/1879450/Idea_For_Tiling_In_Gnome_Shell.png

In this scenario, the grid would be controlled from the activities
overview. If the crosshair was put in a corner, pressing the maximize
button would indeed maximize the window over the whole workspace,
otherwise it would maximize the window to fill the space in which the
max button (or corner) of the window was located when pressed. The
idea is to make it easier to manage multi-window workspaces where, as
often is the case, one main window needs the most size but the others
still needs to be visible and we would like to resize all of them
together.

That idea originated back when the workspaces had a very different
layout compared with what it looks like today and I am not so sure it
would fit well with the current vision of the Gnome Shell. I still
think that the idea is neat though and would propose that instead of
controlling the grid from the overview, one would do this directly on
the workspace using a different workflow:

* When a window is maximized, it should still be possible to resize it
in any direction.
* When resized, the vacant space between the edge of the workspace and
the window should use a similar hint as when a window is dragged to
either edge, but this time indicating that there is a new area into
which windows can be maximized.
* Alternatively, snapping one window to another window would also
create a division among areas, or change the current division.
* If a window has been maximized in an area, it would be resized when
the size of the area changes.
* Resizing one of two maximized and snapped windows would also move
the guide line, resize the areas and any other maximized windows at
the same time.
* When a grid has been created, its guide lines should fade in/out
when a window is moved.
* Resetting the grid should be possible by right clicking a window
title bar and selecting the reset option or using some shortkey combo.

I realize that this idea is crude and would need a lot of refinement
to work. Among other things there needs to be a very visible
difference between an area-maximized window and floating windows. In
either case, the max button itself would be important and I strongly
suggest it is kept for future tweaks like this one.

Best regards,
Andreas

On Wed, Mar 2, 2011 at 2:45 PM, Marcel <lists nightsoul org> wrote:
> Am 02.03.2011 12:14, schrieb Vishnoo:
>>
>> Why does one actually want to maximize and restore windows or resize
>> them? (nautilus windows dont count, lets think about apps/task instead
>> of file-management ;p )
>>
>> IMO, the maximize/resize 'feature' is a workaround for a window
>> management that never got fully implemented.
>>
>> It would be very interesting to know why user is forced to resize the
>> windows manually and try to fix those problems.
>
> For example while trying to store knowledge in my brain, I often have pdfs
> with exercise opened and maximize the window to have it easily readable
> while working on plain ol' paper.
> When I do actual coding (and dont have the 2nd monitor available), I often
> have the exercise next to the IDE which requires the windows to be resized
> properly. 50/50 splitting wouldn't help since I'd want to set the
> distribution of screen real estate dynamically. Regardless of the fact that
> evince comes up with a completely unusable window dimension here, I often
> need to adjust the size of the content displayed.
>
> Marcel
> _______________________________________________
> gnome-shell-list mailing list
> gnome-shell-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>