Written by Klau3 the 17 Oct 10 at 13:56.

If two windows use all vertical space and they touch each other it should be possible to resize both windows, dragging the mouse cursor between them to the left or the right.

If two windows use all vertical space and they touch each other it should be possible to resize both windows, dragging the mouse cursor between them to the left or the right.

Written by Ssdg the 18 Oct 10 at 08:19.

In order not to mess with people's habits, the "multiple-resizing" feature should be associated with another button. Because left is linked with "legacy resizing" and because right shows the menu (I use it a lot, it helps see a window bigger than the screen) so let's use the middle mouse button.

In order not to mess with people's habits, the "multiple-resizing" feature should be associated with another button. Because left is linked with "legacy resizing" and because right shows the menu (I use it a lot, it helps see a window bigger than the screen) so let's use the middle mouse button.

Written by Lachu the 18 Oct 10 at 13:55.

Allow to use now floating mode in Metacity, but restrict settings to certain window. Each window will remember positioning type. By switching window, we switching also positioning mode.

You can imagine that like using fullscreen app. By switching to this window, it takes whole screen. When switching it off, it are minimized. We can extend this to remember different settings of sets of window, but each will be related to one main window. Now, by select another main window fullscreen application will be showed as normal window in ex. right-bottom edge.

Allow to use now floating mode in Metacity, but restrict settings to certain window. Each window will remember positioning type. By switching window, we switching also positioning mode. You can imagine that like using fullscreen app. By switching to this window, it takes whole screen. When switching it off, it are minimized. We can extend this to remember different settings of sets of window, but each will be related to one main window. Now, by select another main window fullscreen application will be showed as normal window in ex. right-bottom edge.

Written by Aielyn the 19 Oct 10 at 07:04.

Give the system the ability to attach windows to each other as far as layout issues are concerned - basically, you could anchor one window to another one, with various settings to allow you to anchor them in the way that suits you.

This would not only enable the functionality desired by this idea (moving two, or more than two, connected window boundaries simultaneously), but would also grant a few other features, including the ability to always keep the windows together in the display stack (so, in the image above, if you minimise the writer, it minimises firefox, and vice versa, and if you give one focus, the other is displayed directly "beneath" it in terms of display depth, above all other windows).

Options for the anchoring process would include:

- "Common Frame", which would make the windows operate as though they were a single window for the purposes of resizing, etc (drag Writer's right border to the left, and Firefox shrinks in proportion, while keeping the borders aligned - halve Writer's width, and Firefox's width is also halved).
- "Common Border", which would do as suggested in the idea, and move both borders without moving any other borders.
- "Glued Border", which would cause the borders to be held together, but otherwise leave all details of the windows separate; move the Writer right border to the left, and the Firefox window moves to the left so the borders still remain aligned, but the Firefox window keeps its size and shape.
- "Free Borders", which would decouple the window borders, but still attach the windows to each other.

Give the system the ability to attach windows to each other as far as layout issues are concerned - basically, you could anchor one window to another one, with various settings to allow you to anchor them in the way that suits you. This would not only enable the functionality desired by this idea (moving two, or more than two, connected window boundaries simultaneously), but would also grant a few other features, including the ability to always keep the windows together in the display stack (so, in the image above, if you minimise the writer, it minimises firefox, and vice versa, and if you give one focus, the other is displayed directly "beneath" it in terms of display depth, above all other windows). Options for the anchoring process would include: - "Common Frame", which would make the windows operate as though they were a single window for the purposes of resizing, etc (drag Writer's right border to the left, and Firefox shrinks in proportion, while keeping the borders aligned - halve Writer's width, and Firefox's width is also halved). - "Common Border", which would do as suggested in the idea, and move both borders without moving any other borders. - "Glued Border", which would cause the borders to be held together, but otherwise leave all details of the windows separate; move the Writer right border to the left, and the Firefox window moves to the left so the borders still remain aligned, but the Firefox window keeps its size and shape. - "Free Borders", which would decouple the window borders, but still attach the windows to each other. In all cases above, moving one window would also move the other window. Further gluing would be possible in order to attach more windows to each other, even sharing a single border. In the "Free Borders" option, only movement of windows would make a difference, resizing of windows would not matter.

Written by Mrinal Saurabh the 19 Oct 10 at 18:51.

Every new window opened should be a tab in title bar. Then a multiple display feature could be used to see more than one windows together.

Every new window opened should be a tab in title bar. Then a multiple display feature could be used to see more than one windows together.

Written by dsterry the 20 Oct 10 at 22:08.

If you want two windows to split the screen, you should be able to grab each one and move them toward their respective sides of the screen to put them in this auto-resized mode. Then if you want to move the boundary between them, you should be able to grab the boundary on either side of that split and move it back and forth horizontally.

This is similar to what another OS does but the addition of being able to drag the adjoining barrier can make this more useful for me. For example, I may want my web browser to be bigger than my gedit with as few clicks and drags as possible.

This may collide with compiz's ability to drag windows between desktops but it's a valid tradeoff.

Furthermore, this should be default behavior for Ubuntu.

If you want two windows to split the screen, you should be able to grab each one and move them toward their respective sides of the screen to put them in this auto-resized mode. Then if you want to move the boundary between them, you should be able to grab the boundary on either side of that split and move it back and forth horizontally. This is similar to what another OS does but the addition of being able to drag the adjoining barrier can make this more useful for me. For example, I may want my web browser to be bigger than my gedit with as few clicks and drags as possible. This may collide with compiz's ability to drag windows between desktops but it's a valid tradeoff. Furthermore, this should be default behavior for Ubuntu.

Written by 3esmit the 21 Oct 10 at 19:17.

Built as a Compiz 'plugin'.
While pressing super button, select windows to resize, and if the resizing selected window reaches other selected window, it will move it and if there is no space to move, resize it.

Built as a Compiz 'plugin'. While pressing super button, select windows to resize, and if the resizing selected window reaches other selected window, it will move it and if there is no space to move, resize it.

Written by david4dev the 24 Oct 10 at 23:19.

Introduce a window manager mode where windows do not overlap and act more like frames. By default the screen space should be shared equally but the borders between frames should be adjustable (a bit like terminator). Opening a new application window or selecting a frame from the window list (or alternatives) should add this window to the list of frames on the screen. The existing frames should automatically resize to accommodate the new frame. Clicking on the window list button for a particular frame that is showing (so the minimise action) should remove it from the screen and the existing windows should automatically resize to fill the space. This should not be a default but should be easy to enable or disable.

Introduce a window manager mode where windows do not overlap and act more like frames. By default the screen space should be shared equally but the borders between frames should be adjustable (a bit like terminator). Opening a new application window or selecting a frame from the window list (or alternatives) should add this window to the list of frames on the screen. The existing frames should automatically resize to accommodate the new frame. Clicking on the window list button for a particular frame that is showing (so the minimise action) should remove it from the screen and the existing windows should automatically resize to fill the space. This should not be a default but should be easy to enable or disable.

Written by argh0 the 25 Oct 10 at 08:11.

Introduce new options when right-clicking on the windows list (gnome-panel applet) :
- rearange the open windows vertically
- rearange the open windows horizontally
-> and when doing that, associate the connecting windows borders in order to move them together

Introduce new options when right-clicking on the windows list (gnome-panel applet) : - rearange the open windows vertically - rearange the open windows horizontally -> and when doing that, associate the connecting windows borders in order to move them together

Written by ganassa the 26 Oct 10 at 17:18.

In a tiling Wm like Ion, Xmonad, i3 etc., this problem is solved at the source: windows can't overlap each other, with some exception using floating windows and tabbed frames. It would really nice if metacity, or whetever WM adopted, could manage this behaviour.

In a tiling Wm like Ion, Xmonad, i3 etc., this problem is solved at the source: windows can't overlap each other, with some exception using floating windows and tabbed frames. It would really nice if metacity, or whetever WM adopted, could manage this behaviour.

Written by lemuelinchrist the 3 Nov 10 at 03:09.

Most users, when using a big screen (say 22'') almost never use the maximize button anymore. So why not give the user freedom to customize the maximize button such that it would only fill half or maybe 2/3 or 1/3 of the screen depending on his choice?

Or if we want to preserve the function of the maximize button, why not add a fourth button for this in addition to the min, max, and close button.

Sometimes manually resizing windows can be burdensome. pressing the maximize window is a lot quicker to fill up screens

Most users, when using a big screen (say 22'') almost never use the maximize button anymore. So why not give the user freedom to customize the maximize button such that it would only fill half or maybe 2/3 or 1/3 of the screen depending on his choice? Or if we want to preserve the function of the maximize button, why not add a fourth button for this in addition to the min, max, and close button. Sometimes manually resizing windows can be burdensome. pressing the maximize window is a lot quicker to fill up screens

Written by ejh the 4 Nov 10 at 17:32.

This is one area that I think windows 7 beats ubuntu. Windows 7's "aerosnap" function works as shown in this video: youtu.be/bopeB6QbOjI.

Ubuntu could implement the windows 7 functionality, then make it better by allowing you to move the vertical boundary between two programs which are sharing your screen left and right, by holding ctrl or shift or using a different mouse button.

This is one area that I think windows 7 beats ubuntu. Windows 7's "aerosnap" function works as shown in this video: youtu.be/bopeB6QbOjI. Ubuntu could implement the windows 7 functionality, then make it better by allowing you to move the vertical boundary between two programs which are sharing your screen left and right, by holding ctrl or shift or using a different mouse button.

Written by cyprys the 10 Nov 10 at 01:15.

Windows attached in the following manner should maximise and share one virtual space: there's a windows list on the bottom gnome-panel in Ubuntu - drag one window from this list and drop it on another window while holding "Super" key, repeat as needed.

When manually changing the width of one window neighbouring window should auto-resize (shrink or grow).

When certain width of the neighbouring window is approached during shrinking auto-resize of the next neighbouring window should start or the process should stop (when there are no more neighbouring windows).

Minimizing one of the attached windows should hide whole virtual space and all windows sharing it.

Unmaximising one of the attached windows should unattach only this one window and release previously occupied space so it could be redistributed between other attached windows.

Multiple virtual spaces on one workspace should be created by attaching two windows to each other (one virtual space) and then attaching two different windows to each other (second virtual space), etc.

When switching between windows (e.g. alt+tab), virtual space should be treated as one window regardless of number of actual windows sharing it.

Windows attached in the following manner should maximise and share one virtual space: there's a windows list on the bottom gnome-panel in Ubuntu - drag one window from this list and drop it on another window while holding "Super" key, repeat as needed. When manually changing the width of one window neighbouring window should auto-resize (shrink or grow). When certain width of the neighbouring window is approached during shrinking auto-resize of the next neighbouring window should start or the process should stop (when there are no more neighbouring windows). Minimizing one of the attached windows should hide whole virtual space and all windows sharing it. Unmaximising one of the attached windows should unattach only this one window and release previously occupied space so it could be redistributed between other attached windows. Multiple virtual spaces on one workspace should be created by attaching two windows to each other (one virtual space) and then attaching two different windows to each other (second virtual space), etc. When switching between windows (e.g. alt+tab), virtual space should be treated as one window regardless of number of actual windows sharing it.

Written by jeffster the 10 Nov 10 at 05:07.

If there is one window that is already set up, taking half the screen, double clicking another window's corner will fill the remaining space.

If there is one window that is already set up, taking half the screen, double clicking another window's corner will fill the remaining space.

Written by koenfloris the 14 Nov 10 at 09:33.

kubuntu already does this, just implent it in compiz and metacity

kubuntu already does this, just implent it in compiz and metacity

Written by Gonz-IT the 11 Nov 10 at 12:16.

Windows 7 implements a very neat way for window resizing and positioning. If you select a window and type WindowsKey (Super) + Right Arrow, the window will take exactly half of the space available in the right side of the screen, and so on with the WindowsKey + Left combo.

I think this is a very nice usability feature that should be implemented with Ubuntu.

Windows 7 implements a very neat way for window resizing and positioning. If you select a window and type WindowsKey (Super) + Right Arrow, the window will take exactly half of the space available in the right side of the screen, and so on with the WindowsKey + Left combo. I think this is a very nice usability feature that should be implemented with Ubuntu.

Written by thamawij pirajnaraporn the 28 Dec 10 at 08:53.

- User may increase/decrease slot numbers for a single workspace.
- Treat each slot as a cell in a spreadsheet, a user may merge them with the adjacent cells.

Currently, I'm not so clear about how it should works or the way that possibly implemented, I will add some details later.

- User may increase/decrease slot numbers for a single workspace. - Treat each slot as a cell in a spreadsheet, a user may merge them with the adjacent cells. Currently, I'm not so clear about how it should works or the way that possibly implemented, I will add some details later.

Written by thamawij pirajnaraporn the 28 Dec 10 at 09:11.

It would be nice if we can make one of our workspace split; for example, a 1280x960 may split into 4, 640x480, screens or 2, 640x960, screens as virtual attached monitors. Maximize make a window fit a monitor.

(In my head, it looks like compiz's Expo view with adjustable numbers of adjacent workspaces to show at the time)

I'm not so sure if this idea is implementable. Just share the idea so the superior in system and programming may see the way to go.

It would be nice if we can make one of our workspace split; for example, a 1280x960 may split into 4, 640x480, screens or 2, 640x960, screens as virtual attached monitors. Maximize make a window fit a monitor. (In my head, it looks like compiz's Expo view with adjustable numbers of adjacent workspaces to show at the time) I'm not so sure if this idea is implementable. Just share the idea so the superior in system and programming may see the way to go.