Written by yzarc the 22 Mar 08 at 21:32.

Ubuntu Brainstorm was updated in January 2009. Since the idea #5443 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #5443 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by yzarc the 12 Oct 08 at 20:07.

Ubuntu Brainstorm was updated in January 2009. Since the idea #14338 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #14338 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by yzarc the 15 Nov 09 at 12:39.

give it more features:
1- show min/restore commands.
2- permit to the app to add gadgets like progress bar, tab-bar, multimedia commands.
3- make it fit with the gtk theme and touching the windows to give the illusion it's part of the window.
4- add launchers.
5- window "menu mode", the window is no maximized but stay attached to the panel, like the calendar.
6- group / ungroup windows.
7- tile windows command.
8- show desktop applet.
9- places applet.

give it more features: 1- show min/restore commands. 2- permit to the app to add gadgets like progress bar, tab-bar, multimedia commands. 3- make it fit with the gtk theme and touching the windows to give the illusion it's part of the window. 4- add launchers. 5- window "menu mode", the window is no maximized but stay attached to the panel, like the calendar. 6- group / ungroup windows. 7- tile windows command. 8- show desktop applet. 9- places applet.

Written by yzarc the 15 Nov 09 at 12:47.

make it more flexible permitting apps to use it as they need.
tab-bar for browsers, art and commands for media players,avatar, status, last msg of a IM windows, etc. no just title and min/max buttons.

look at this example from "clever windows" mockup, the title bar belong to the app, is useful and beautiful, holds interesting informations, is no more just an useless strip.

make it more flexible permitting apps to use it as they need. tab-bar for browsers, art and commands for media players,avatar, status, last msg of a IM windows, etc. no just title and min/max buttons. look at this example from "clever windows" mockup, the title bar belong to the app, is useful and beautiful, holds interesting informations, is no more just an useless strip. <img src="http://lh5.ggpht.com/_ugxjjESE8ro/SwEioSEWJLI/AAAAAAAAAFI/7j1JYEHM3WA/screenshot2.png" />

Written by Lachu the 15 Nov 09 at 15:45.

Already window managers have designed to not disappoint users. It will force designers to add caption bar, caption buttons, etc. We should fix window border size to 2/4 pixels to each edge. Also, we need to make whole space not contained in active window interactive - by clicking on other window, we don't bring it on first front, but menu with possible actions should appear.
Use cases:
1) Alex would to move window. He only click on destination position and select move there. Alex can also click on window border or white space at screen, go to mode submenu and select move.
2) We had window maximized. It takes whole screen plus borders. Alex can click on border and select window list > gedit(for example). She can also select desktop from window list or click minimize window.

It will brinks better way to integrate with user(more natural, flexible, faster). Additional features is we don't waste space and there always possibility to use mouse(today we must use keyboard in some cases or move window on whole screen).

We should display windows title, when cursor leaves active window or alt key is pressed.

Already window managers have designed to not disappoint users. It will force designers to add caption bar, caption buttons, etc. We should fix window border size to 2/4 pixels to each edge. Also, we need to make whole space not contained in active window interactive - by clicking on other window, we don't bring it on first front, but menu with possible actions should appear. Use cases: 1) Alex would to move window. He only click on destination position and select move there. Alex can also click on window border or white space at screen, go to mode submenu and select move. 2) We had window maximized. It takes whole screen plus borders. Alex can click on border and select window list > gedit(for example). She can also select desktop from window list or click minimize window. It will brinks better way to integrate with user(more natural, flexible, faster). Additional features is we don't waste space and there always possibility to use mouse(today we must use keyboard in some cases or move window on whole screen). We should display windows title, when cursor leaves active window or alt key is pressed.

Written by Lasall the 22 Nov 09 at 03:37.

So you can use unused space at the top bar.

So you can use unused space at the top bar. <img src="http://gnome2-globalmenu.googlecode.com/svn/wiki/GlobalMenuWindows.png" />

Written by speedkreature the 1 Dec 09 at 18:48.

Using solution #2, extend transparent (or not) borders around the windows when the user moves the pointer (whether mouse, tablet or finger) to the edge of the window because it may be that the menu texts take up the entire top of the window leaving no place to click and drag the window.
The transparent borders would allow the user to resize and move the window as desired.
Hovering some number of milliseconds (or holding the click and not moving) over the extended border would allow for resize, the default action being move.
If the window is fullscreen, it will need to be taken out of full screen mode first. If it still takes the full available monitor space, the desktop environment needs to be resolution aware and shrink the window enough to allow for the border to appear.

GUI's are moving toward multi-touch and I think we need to prepare our desktops for this switch.
This method is a little more intuitive as it only appears when the user is approaching the window boarders (as you do when you intend to move or resize a window).

Using solution #2, extend transparent (or not) borders around the windows when the user moves the pointer (whether mouse, tablet or finger) to the edge of the window because it may be that the menu texts take up the entire top of the window leaving no place to click and drag the window. The transparent borders would allow the user to resize and move the window as desired. Hovering some number of milliseconds (or holding the click and not moving) over the extended border would allow for resize, the default action being move. If the window is fullscreen, it will need to be taken out of full screen mode first. If it still takes the full available monitor space, the desktop environment needs to be resolution aware and shrink the window enough to allow for the border to appear. GUI's are moving toward multi-touch and I think we need to prepare our desktops for this switch. This method is a little more intuitive as it only appears when the user is approaching the window boarders (as you do when you intend to move or resize a window).

Written by c3h8 the 15 Dec 09 at 00:09.

The Menu Bar should be integrated in to the title bar. The menu bar should be to the left. The window name sdhould be in the middle, and the buttons are still on the right, left or center as dictated by the window decorator.

The Menu Bar should be integrated in to the title bar. The menu bar should be to the left. The window name sdhould be in the middle, and the buttons are still on the right, left or center as dictated by the window decorator.

Written by Lachu the 1 Jan 10 at 17:22.

Titlebar should presents, when mouse cursor is outside titlebar. It should be displayed above the window and be transparent. Also titlebar should been displayed, when mouse are above borders of window for some amount of time.

Once window is maximized, we can display close button on panel(GNOME3 would integrate panels and window managers).

Titlebar should presents, when mouse cursor is outside titlebar. It should be displayed above the window and be transparent. Also titlebar should been displayed, when mouse are above borders of window for some amount of time. Once window is maximized, we can display close button on panel(GNOME3 would integrate panels and window managers).

Written by yzarc the 26 Mar 10 at 16:47.

I wrote some draft about a my idea.

please, give a look and send me a feed back.

http://dl.dropbox.com/u/5348766/boarder.pdf

<img src="http://dl.dropbox.com/u/5348766/screenshot2.png" /> I wrote some draft about a my idea. please, give a look and send me a feed back. http://dl.dropbox.com/u/5348766/boarder.pdf

Written by Jryskamp the 14 Apr 10 at 16:28.

To attain more screen real estate, if the window borders were change, it could drastically improve this aspect. As most applications (such as word processing, picture editing, and others) need more space vertically, if the title bar was turned 90 degrees and placed on the side of the window while keeping the toolbars on top. Then, to maintain the width of the window, make the title bar auto-hide. Most everyone doesn't use the title bar when they are working on writing, or editing so this would be a great help to most everyone.

And most people know what application they are using at the time so the information produced by the title bar is useless. Having it hidden saves space; however, when it is needed, it can quickly be produced. The window switcher at the bottom will still display the names of the applications switching using them wouldn't be affected.

This will also help change up the impression that Ubuntu is trying to mirror OSX with the change from right to left of window controls.

It's just a thought from a common user who has no computer coding skill whatsoever but I thought it was kinda cool if it made life easier for some people... Let me know what people think or if there are any questions.

To attain more screen real estate, if the window borders were change, it could drastically improve this aspect. As most applications (such as word processing, picture editing, and others) need more space vertically, if the title bar was turned 90 degrees and placed on the side of the window while keeping the toolbars on top. Then, to maintain the width of the window, make the title bar auto-hide. Most everyone doesn't use the title bar when they are working on writing, or editing so this would be a great help to most everyone. And most people know what application they are using at the time so the information produced by the title bar is useless. Having it hidden saves space; however, when it is needed, it can quickly be produced. The window switcher at the bottom will still display the names of the applications switching using them wouldn't be affected. This will also help change up the impression that Ubuntu is trying to mirror OSX with the change from right to left of window controls. It's just a thought from a common user who has no computer coding skill whatsoever but I thought it was kinda cool if it made life easier for some people... Let me know what people think or if there are any questions.

Written by mikko.rantalainen the 19 Oct 10 at 11:46.

Something a bit similar to http://www.markshuttleworth.com/archives/359 adjusted to be usable with big screens:

(1) Render active window title in the top panel (over the panel's real contents such as "Applications", "Places", "System" etc) and fade out the window title (towards transparent) to make panel actions available again when mouse cursor come close. Keep window menu with the window (this is, of course, up to the application--suggest that "File" menu should be replaced with application name as seen in OS X, this would make even more sense if top of the window is usually the menu for the window).

(2) Remove title bar from window itself. Come up with better methods to move windows (and preferably, get the window manager to manage the windows automatically). I'd prefer Super + left mouse button for moving window, Super + right mouse button for resize. Dragging window towars the top of the screen should maximize it, dragging window towards the bottom of the screen should minimize it etc. A method that does not require keyboard could be invented, too. The real point here is that using ONLY the title bar for moving the window is missing a HUGE amount of pixels that could be used for moving a window. The same is even more true for resizing windows with current window managers. One possibility could be some kind of "Arrange windows" mode where clicking and dragging any windows does not send clicks or drags to the applications itself. Kind of "Show all desktops" view where clicking a window will interact with the window, not the application.

Something a bit similar to http://www.markshuttleworth.com/archives/359 adjusted to be usable with big screens: (1) Render active window title in the top panel (over the panel's real contents such as "Applications", "Places", "System" etc) and fade out the window title (towards transparent) to make panel actions available again when mouse cursor come close. Keep window menu with the window (this is, of course, up to the application--suggest that "File" menu should be replaced with application name as seen in OS X, this would make even more sense if top of the window is usually the menu for the window). (2) Remove title bar from window itself. Come up with better methods to move windows (and preferably, get the window manager to manage the windows automatically). I'd prefer Super + left mouse button for moving window, Super + right mouse button for resize. Dragging window towars the top of the screen should maximize it, dragging window towards the bottom of the screen should minimize it etc. A method that does not require keyboard could be invented, too. The real point here is that using ONLY the title bar for moving the window is missing a HUGE amount of pixels that could be used for moving a window. The same is even more true for resizing windows with current window managers. One possibility could be some kind of "Arrange windows" mode where clicking and dragging any windows does not send clicks or drags to the applications itself. Kind of "Show all desktops" view where clicking a window will interact with the window, not the application. (3) Possibly, reserve top right corner for application switcher, by default. If currently active application icon were always displayed at the top right corner and it's title were rendered next to it, clicking the top right corner would drop down a list of all application/windows. Done right, this could even make taskbar needless. As a result, the window manager would only render window border (a couple of pixels or possibly less) and window shadow and other extra stuff. There shouldn't be a reason why window top border should be any special from any other border the window has.

Written by nickr the 30 Jan 11 at 14:20.

All the Titlebar does is display close-minimize-maximize buttons and the window's title/name. Window-buttons (the rectangular windows that appear across the panel/taskbar when a file or program is opened) already display the window's name. If they were to gain a close-minimize-maximize button in the corner (similar to a web browser's TAB-button) they would negate any need for a Title bar. Perhaps the current length of the window-buttons could be made slightly longer to accommodate the extra buttons (not a problem on widescreen displays). All the Titlebar does presently is take up valuable vertical space. It will also improve Ubuntu usability because it is more intuitive to move to the open window-button on the panel/taskbar to close it or manipulate it than to move to the Titlebar.

To make everyone happy, developers could simply allow a settings change to add this functionality to the Ubuntu Appearance for users who want this functionality. Those who don't want it don't have to engage the setting.

All the Titlebar does is display close-minimize-maximize buttons and the window's title/name. Window-buttons (the rectangular windows that appear across the panel/taskbar when a file or program is opened) already display the window's name. If they were to gain a close-minimize-maximize button in the corner (similar to a web browser's TAB-button) they would negate any need for a Title bar. Perhaps the current length of the window-buttons could be made slightly longer to accommodate the extra buttons (not a problem on widescreen displays). All the Titlebar does presently is take up valuable vertical space. It will also improve Ubuntu usability because it is more intuitive to move to the open window-button on the panel/taskbar to close it or manipulate it than to move to the Titlebar. To make everyone happy, developers could simply allow a settings change to add this functionality to the Ubuntu Appearance for users who want this functionality. Those who don't want it don't have to engage the setting.

Written by rockachu2 the 2 Apr 11 at 19:22.

The user could click and drag to move, drag to the top of the screen to maximize, and double click to close
The user could drag to the window bar to minimize.
This would open up a lot of space.

When activating a window, a user would see the title in a separate 'bulge' , which would shrink after some time.

Applications should also be able to 'draw' over the top border and use the sides as they wish, since there is no need for restriction there anymore.

The user could click and drag to move, drag to the top of the screen to maximize, and double click to close The user could drag to the window bar to minimize. This would open up a lot of space. When activating a window, a user would see the title in a separate 'bulge' , which would shrink after some time. Applications should also be able to 'draw' over the top border and use the sides as they wish, since there is no need for restriction there anymore.

Written by yzarc the 10 Sep 08 at 19:04.

edited.

karmic koala won, please close this idea :)

edited. karmic koala won, please close this idea :)

Written by yzarc the 12 Aug 08 at 11:29.

ubuntu should have a webcam control panel app where would be possible to set configurations like brightness, colour, exposure, etc while we are using the webcam in any application.maybe some effects too.

ubuntu should have a webcam control panel app where would be possible to set configurations like brightness, colour, exposure, etc while we are using the webcam in any application.maybe some effects too.

Written by Holmen the 11 Oct 09 at 23:27.

Make use Cheese's settings manager to be the settings for the overall system.

Make use Cheese's settings manager to be the settings for the overall system.

Written by mikko.rantalainen the 7 Oct 10 at 10:50.

"guvcview -o" provides a control panel for web cameras and has ability to save and load settings. A suitable location for entry could also be System - Preferences.

Some work for it would still be required:
- ability to select device from the UI (if multiple cameras has been connected)
- ability to silently and automatically load predefined configuration for a camera during login/system startup.
- only works with UVC cameras, support for cameras with random data interfaces would be much harder to implement

"guvcview -o" provides a control panel for web cameras and has ability to save and load settings. A suitable location for entry could also be System - Preferences. Some work for it would still be required: - ability to select device from the UI (if multiple cameras has been connected) - ability to silently and automatically load predefined configuration for a camera during login/system startup. - only works with UVC cameras, support for cameras with random data interfaces would be much harder to implement

Written by yzarc the 28 Nov 08 at 17:59.

Ubuntu Brainstorm was updated in January 2009. Since the idea #16038 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #16038 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by yzarc the 14 Nov 08 at 12:14.

Ubuntu Brainstorm was updated in January 2009. Since the idea #15619 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #15619 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by yzarc the 7 Nov 08 at 16:35.

Ubuntu Brainstorm was updated in January 2009. Since the idea #15373 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #15373 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by yzarc the 20 Oct 08 at 12:03.

Ubuntu Brainstorm was updated in January 2009. Since the idea #14609 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #14609 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by yzarc the 12 Oct 08 at 19:49.

Ubuntu Brainstorm was updated in January 2009. Since the idea #14337 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #14337 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!