Written by bbordwell the 15 Nov 09 at 21:58.

One of the options that comes up when you click on "places" should be "places preferences". It would be a simple GUI that allows you to add/remove things from the list, as well as change recent documents settings (i.e. disable, the number of documents it remembers).

One of the options that comes up when you click on "places" should be "places preferences". It would be a simple GUI that allows you to add/remove things from the list, as well as change recent documents settings (i.e. disable, the number of documents it remembers).

Written by biffen the 15 Nov 09 at 22:45.

Alacarte is used to edit Applications and System menus, it should be extended to edit the Places menu as well.

Adding a "Places preferences" item to the Places menu (as proposed in solution #1) would crowd the menu itself. Editing the menu is a rare task and should be accessible by right click, rather than via a menu item, as with most other parts of Gnome and many other environments.

On a side note, the ability to choose whether the bookmarks go into a sub menu should be part of the customisation.

Alacarte is used to edit Applications and System menus, it should be extended to edit the Places menu as well. Adding a "Places preferences" item to the Places menu (as proposed in solution #1) would crowd the menu itself. Editing the menu is a rare task and should be accessible by right click, rather than via a menu item, as with most other parts of Gnome and many other environments. On a side note, the ability to choose whether the bookmarks go into a sub menu should be part of the customisation.

Written by Warbo the 20 Nov 09 at 09:59.

If a folder or bookmark is dragged on to the Places menu it should drop down to allow the user to drop it somewhere in the list. There could also be an item such as "New Folder" which appears in the list when in the process of dragging, allowing a hierarchy, which would prompt the user to rename it once they've dropped their item.

Dragging a Nautilus window should do the same, with the window's current location being added to the menu. Browser windows and hyperlinks should also have the same behaviour (there should be no distinction between local and online). Basically treat Places as a bookmarks system (which preferably would give the same lists in every application)

If a folder or bookmark is dragged on to the Places menu it should drop down to allow the user to drop it somewhere in the list. There could also be an item such as "New Folder" which appears in the list when in the process of dragging, allowing a hierarchy, which would prompt the user to rename it once they've dropped their item. Dragging a Nautilus window should do the same, with the window's current location being added to the menu. Browser windows and hyperlinks should also have the same behaviour (there should be no distinction between local and online). Basically treat Places as a bookmarks system (which preferably would give the same lists in every application)

Written by antaveiv the 26 Nov 09 at 14:19.

Allow navigating the Places by dynamically expanding the menus. Open the selected document/directory when clicked, perhaps allow moving/copying it with drag'n'drop.
I believe this could speed up simple tasks, e.g. plug in USB stick (appears in Places), then browse and open a document, all without having to open Nautilus.

Allow navigating the Places by dynamically expanding the menus. Open the selected document/directory when clicked, perhaps allow moving/copying it with drag'n'drop. I believe this could speed up simple tasks, e.g. plug in USB stick (appears in Places), then browse and open a document, all without having to open Nautilus.

Written by xubaj the 19 Dec 09 at 10:30.

you can only add the whole menu (main, places, system) or just the Main Menu to the panel. it should be possible to add only the Places Menu.

see also: http://ubuntuforums.org/showthread.php?t=1308623

you can only add the whole menu (main, places, system) or just the Main Menu to the panel. it should be possible to add only the Places Menu. see also: http://ubuntuforums.org/showthread.php?t=1308623

Written by DPic the 4 Aug 08 at 01:54.

Ubuntu Brainstorm was updated in January 2009. Since the idea #11805 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 #11805 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 Tomppeli the 2 Jun 10 at 12:43.

In Nautilus, in F-Spot and even in Microsoft Windows XP you can see preview of every file at the same time. That should be implemented in file dialogs as well. There could be option to select way how they are displayed and show it that way.

Most of people don't need dates and other stuff what's showed now but they could have use for showing more files at the same time and bigger icons. That old way and new way could be selectable for user.

In Nautilus, in F-Spot and even in Microsoft Windows XP you can see preview of every file at the same time. That should be implemented in file dialogs as well. There could be option to select way how they are displayed and show it that way. Most of people don't need dates and other stuff what's showed now but they could have use for showing more files at the same time and bigger icons. That old way and new way could be selectable for user.

Written by vektor the 4 Jun 10 at 09:32.

Inspired by Windows, where file dialogs work like a little Explorer:

Add file management options like rename, move, etc. to Gnome/GTK file dialogs.

This solution strongly supports Solution #1.

Inspired by Windows, where file dialogs work like a little Explorer: Add file management options like rename, move, etc. to Gnome/GTK file dialogs. This solution strongly supports Solution #1.

Written by komputes the 19 Apr 10 at 23:06.

Brightness setting 0 should turn off backlight

Brightness setting 0 should turn off backlight

Written by Dread Knight the 29 Apr 10 at 09:05.

There should be an easy command that will turn off the LCD, maybe with a 3 second visual counter or something.

So you can make a launcher with that command and add it in the menus and panels if needed.
Maybe even have such an icon in the administration menu.

There should be an easy command that will turn off the LCD, maybe with a 3 second visual counter or something. So you can make a launcher with that command and add it in the menus and panels if needed. Maybe even have such an icon in the administration menu.

Written by woody123 the 4 May 10 at 18:42.

as the current ubuntu settings
but with an extra option to turn of the backlight

as the current ubuntu settings but with an extra option to turn of the backlight

Written by arturhoo@gmail.com the 5 May 10 at 03:11.

These two commands turn off the LCD:

killall gnome-power-manager
xset -display :0.0 dpms force off


What I did was replace the lock screen action to a script, that both locks the screen and turns off the LCD:

#!/bin/bash
gnome-screensaver-command -l
sleep 2
killall gnome-power-manager
xset -display :0.0 dpms force off

These two commands turn off the LCD: killall gnome-power-manager xset -display :0.0 dpms force off What I did was replace the lock screen action to a script, that both locks the screen and turns off the LCD: #!/bin/bash gnome-screensaver-command -l sleep 2 killall gnome-power-manager xset -display :0.0 dpms force off

Written by gazilla the 11 May 10 at 11:35.

This is another use case for my idea from two years ago. A GUI (Gtk/QT/?) front-end to create and maintain user-level Upstart scripts.

In this case the event being watched would be 'screen-brightness', the action taken (if zero) would be 'backlight-off'.

For this problem Solution #1 is the correct answer, however if idea #9103 existed then the user could control this themselves until Solution #1 was implemented.

Please read and perhaps vote on... http://brainstorm.ubuntu.com/idea/9103/

This is another use case for my idea from two years ago. A GUI (Gtk/QT/?) front-end to create and maintain user-level Upstart scripts. In this case the event being watched would be 'screen-brightness', the action taken (if zero) would be 'backlight-off'. For this problem Solution #1 is the correct answer, however if idea #9103 existed then the user could control this themselves until Solution #1 was implemented. Please read and perhaps vote on... http://brainstorm.ubuntu.com/idea/9103/

Written by mydoghasworms the 29 Mar 10 at 19:27.

An "about" entry on every context menu is too much and gives you the impression that the desktop is just an incoherent collection of programs, not a single unit working together, and then get rid of all the "about" entries in each and every context menu.

An "about" entry on every context menu is too much and gives you the impression that the desktop is just an incoherent collection of programs, not a single unit working together, and then get rid of all the "about" entries in each and every context menu.

Written by yman the 7 Apr 10 at 04:43.

As the title says.

As the title says.

Written by DawnLight the 27 Mar 09 at 20:04.

Make the default terminal, gnome-terminal, support RTL and do this by default.

Make the default terminal, gnome-terminal, support RTL and do this by default.

Written by DawnLight the 3 Apr 09 at 07:17.

Make the terminal of RTL users display English.

It is better to have English, which most RTL users who can use a terminal know, than to use their native language in reverse.

Make the terminal of RTL users display English. It is better to have English, which most RTL users who can use a terminal know, than to use their native language in reverse.

Written by DawnLight the 3 Apr 09 at 07:33.

So that RTL users could use it.

The terminal mlterm perhaps.

So that RTL users could use it. The terminal mlterm perhaps.

Written by DawnLight the 3 Apr 09 at 07:39.

Develop RTL support for the default terminal and make it turned off by default.

Develop RTL support for the default terminal and make it turned off by default.

Written by DawnLight the 3 Apr 09 at 08:02.

Develop a mechanism in the default terminal which detects RTL characters.

When RTL characters are detected, switch to RTL enabled mode. When RTL characters are gone, disable the RTL support.

Provide an option to disable this auto-detection.

When RTL characters are detected for the very first time, display a dialog box that explains this mechanism to the user and tells him that he can disable it if there are problems with the display in the terminal.

Develop a mechanism in the default terminal which detects RTL characters. When RTL characters are detected, switch to RTL enabled mode. When RTL characters are gone, disable the RTL support. Provide an option to disable this auto-detection. When RTL characters are detected for the very first time, display a dialog box that explains this mechanism to the user and tells him that he can disable it if there are problems with the display in the terminal.

Written by rouge568 the 1 Sep 08 at 21:01.

Pretty Self-Explanatory.

Pretty Self-Explanatory.

Written by Darwin Survivor the 13 Jul 09 at 00:29.

There has been lots of work put into the HIG, but few people are pushing it or even mentioning it for that matter.

Canonical should help push developers and teams to standardize on the HIG principles and make applications more intuitive and familiar to people who have used other gnome applications.

There has been lots of work put into the HIG, but few people are pushing it or even mentioning it for that matter. Canonical should help push developers and teams to standardize on the <a href="http://library.gnome.org/devel/hig-book/stable/">HIG</a> principles and make applications more intuitive and familiar to people who have used other gnome applications.

Written by Darwin Survivor the 13 Jul 09 at 00:31.

HIG may not be the best thing to use for gnome. It may be a better idea to start from scratch and write a new "Recommended UI standards for Gnome applications" definition and push that instead.

HIG may not be the best thing to use for gnome. It may be a better idea to start from scratch and write a new "Recommended UI standards for Gnome applications" definition and push that instead.

Written by xfuser4 the 16 Jul 09 at 09:11.

Make a price that is given every year to projects which have high usability and which are concentrating on user interface guidelines.

Make a price that is given every year to projects which have high usability and which are concentrating on user interface guidelines.

Written by sathishmanohar the 28 Jul 09 at 21:26.

Make a Gnu public license Icon package with awesome quality, which covers almost all usage. Even a high paid job, wouldn't hurt.

So, that everybody can use those in their projects. and there will be a great consistency among the application using those Icons.

Users will feel home even if they try new applications.

Make a Gnu public license Icon package with awesome quality, which covers almost all usage. Even a high paid job, wouldn't hurt. So, that everybody can use those in their projects. and there will be a great consistency among the application using those Icons. Users will feel home even if they try new applications.

Written by sheol the 5 Aug 09 at 23:01.

HIG's is fine, but it requires developers of open source software to reimplement the HIG's user interface, and also to test for the environment and implement a different interface for KDE.

An easy solution, and one that would solve this problem, but simultaneously encourage development is to create a standard UI API. Then programmers could simply attach actions to common elements (like save), or to custom button in common categories (like edit), and the UI would render itself; and simultaneously conform to the UI guidelines of the environment it is working in.

HIG's is fine, but it requires developers of open source software to reimplement the HIG's user interface, and also to test for the environment and implement a different interface for KDE. An easy solution, and one that would solve this problem, but simultaneously encourage development is to create a standard UI API. Then programmers could simply attach actions to common elements (like save), or to custom button in common categories (like edit), and the UI would render itself; and simultaneously conform to the UI guidelines of the environment it is working in.

Written by stoffel the 16 Nov 09 at 11:58.

Communicate a roadmap like the following to the whole community:

[hypothetical example]

* Ubuntu 10.10:
** =main= All Gnome software in the main repository needs to adhere to sections x, y and z of the Gnome HIG. All KDE software in the main repository needs to adhere to sections x, y and z of the KDE HIG. Click here for a list of software that currently is not compliant (click on the software names for details regarding the issues). In May 2010 all software will tested for compliance. Incompliant software will be moved to the universe repository.

* Ubuntu 11.04:
** =main= All Gnome software in the main repository needs to adhere to sections a, b, c, x, y and z of the Gnome HIG. All KDE software in the main repository needs to adhere to sections a, b, c, x, y and z of the KDE HIG. Click here for a list of software that currently is not compliant (click on the software names for details regarding the issues). In November 2010 all software will tested for compliance. Incompliant software will be moved to the universe repository.

* Ubuntu 11.10:
** =main= All Gnome software in the main repository needs to adhere to sections 1, 2, 3, a, b, c, x, y and z of the Gnome HIG. All KDE software in the main repository needs to adhere to sections 1, 2, 3, a, b, c, x, y and z of the KDE HIG. Click here for a list of software that currently is not compliant (click on the software names for details regarding the issues). In May 2011 all software will tested for compliance. Incompliant software will be moved to the universe repository.

Communicate a roadmap like the following to the whole community: [hypothetical example] * Ubuntu 10.10: ** =main= All Gnome software in the main repository needs to adhere to sections x, y and z of the Gnome HIG. All KDE software in the main repository needs to adhere to sections x, y and z of the KDE HIG. Click here for a list of software that currently is not compliant (click on the software names for details regarding the issues). In May 2010 all software will tested for compliance. Incompliant software will be moved to the universe repository. * Ubuntu 11.04: ** =main= All Gnome software in the main repository needs to adhere to sections a, b, c, x, y and z of the Gnome HIG. All KDE software in the main repository needs to adhere to sections a, b, c, x, y and z of the KDE HIG. Click here for a list of software that currently is not compliant (click on the software names for details regarding the issues). In November 2010 all software will tested for compliance. Incompliant software will be moved to the universe repository. * Ubuntu 11.10: ** =main= All Gnome software in the main repository needs to adhere to sections 1, 2, 3, a, b, c, x, y and z of the Gnome HIG. All KDE software in the main repository needs to adhere to sections 1, 2, 3, a, b, c, x, y and z of the KDE HIG. Click here for a list of software that currently is not compliant (click on the software names for details regarding the issues). In May 2011 all software will tested for compliance. Incompliant software will be moved to the universe repository. ** =universe= All Gnome software in the universe repository needs to adhere to sections x, y and z of the Gnome HIG. All KDE software in the universe repository needs to adhere to sections x, y and z of the KDE HIG. Click here for a list of software that currently is not compliant (click on the software names for details regarding the issues). In May 2011 all software will tested for compliance. Incompliant software will be removed from the universe repository. * Ubuntu 12.04: ** =main= All Gnome software in the main repository needs to adhere to sections X, Y, Z, 1, 2, 3, a, b, c, x, y and z of the Gnome HIG. All KDE software in the main repository needs to adhere to sections X, Y, Z, 1, 2, 3, a, b, c, x, y and z of the KDE HIG. Click here for a list of software that currently is not compliant (click on the software names for details regarding the issues). In November 2011 all software will tested for compliance. Incompliant software will be moved to the universe repository. ** =universe= All Gnome software in the universe repository needs to adhere to sections a, b, x, x, y and z of the Gnome HIG. All KDE software in the universe repository needs to adhere to sections a, b, c, x, y and z of the KDE HIG. Click here for a list of software that currently is not compliant (click on the software names for details regarding the issues). In November 2011 all software will tested for compliance. Incompliant software will be removed from the universe repository. [/hypothetical example]

Written by slsolaris the 30 Jan 09 at 04:56.

Use smaller icons in the ubuntu main menu, to prevent it to get long and out of control.
Here is a screen shot of what I mean.
This is not a mock up, this is done by editing gtk+ file
https://dl.getdropbox.com/u/384589/small%20menu.png

Use smaller icons in the ubuntu main menu, to prevent it to get long and out of control. Here is a screen shot of what I mean. This is not a mock up, this is done by editing gtk+ file https://dl.getdropbox.com/u/384589/small%20menu.png

Written by Magnes the 30 Jan 09 at 09:32.

Use normal icons, they are OK, but give the user an option to use smaller ones. And if the resolution is small (for example on netbook screen) automatically activate smaller icons in menu.

Use normal icons, they are OK, but give the user an option to use smaller ones. And if the resolution is small (for example on netbook screen) automatically activate smaller icons in menu.

Written by eugene2k the 4 Feb 09 at 11:45.

The problem is not the icons, it's the whole places menu - it's simply too long. If it were shorter it would be more usable and less confusing.

The problem is not the icons, it's the whole places menu - it's simply too long. If it were shorter it would be more usable and less confusing.

Written by dflemstr the 4 Feb 09 at 20:01.

The most intuitive way to shorten the menus (At least the "Applications" and "System" menus) would be to simply add more sub-menus.
For instance, instead having multimedia apps directly on the "Multimedia"-menu, there could be sub-menus like "Multimedia>Media Players" and "Multimedia>Audio Production".

Alot of other distros use this system (For instance Debian and UbuntuStudio (At least for the "Multimedia"-menu) ) and Ubuntu could aswell.

It wouldn't only shorten menus, but also making it possible to find your applications/settings faster.

The most intuitive way to shorten the menus (At least the "Applications" and "System" menus) would be to simply add more sub-menus. For instance, instead having multimedia apps directly on the "Multimedia"-menu, there could be sub-menus like "Multimedia>Media Players" and "Multimedia>Audio Production". Alot of other distros use this system (For instance Debian and UbuntuStudio (At least for the "Multimedia"-menu) ) and Ubuntu could aswell. It wouldn't only shorten menus, but also making it possible to find your applications/settings faster.

Written by admin.luis the 4 Feb 09 at 22:29.

A configuration option to have a smaller icons and more than one column per submenu.
The option should include a parameter to indicate the number of icons to be grouped as columns. Columns of 12/14 items by default should be ok.
(I hate the up/down arrow on gnome menus)

A configuration option to have a smaller icons and more than one column per submenu. The option should include a parameter to indicate the number of icons to be grouped as columns. Columns of 12/14 items by default should be ok. (I hate the up/down arrow on gnome menus)

Written by C.H.E.W.S. the 5 Feb 09 at 15:28.

In firefox when you open tabs they are one size but as you use the space they start to shrink till a certain point in witch it does not go smaller and puts them in a drop down list. This same idea could be used for Ubuntu menus.

In firefox when you open tabs they are one size but as you use the space they start to shrink till a certain point in witch it does not go smaller and puts them in a drop down list. This same idea could be used for Ubuntu menus.

Written by zerothis the 6 Feb 09 at 20:50.

Each menu items should be tagable. The right click menu could have "add a tag" and "remove a tag" submenus listing tags and an "advanced tags manager". A text box at the top of the menu could accept simple filters to dynamically list the menu. "games" would produce a menu with only items tagged "games". Including a negative tag would exclude items from the dynamic menu. For instance "games -turnbased". When no text was entered, all the menu items would be visible in sub menus named after tags. Sub menus would list all the items with that tag but also include sub sub menus based on the other tags the items included. Items with multiple tags would be reachable in multiple ways. For instance,
games>Internet>wine>pogo2go
Internet>games>wine>pogo2go
wine>Internet>games>pogo2go
wine>games>pogo2go
wine>pogo2go
games>pogo2go
and so on. The top level sub menus based on tags would be a very big list. Navigating the sub sub menus to deeper levels reduces the size of the list because the items listed must be tagged with the name of each menu navigated.
games>Internet>wine> would only show game including all three of these tags. This sub menu would show the equivalent of typing "games Internet wine" in the text box above.

Each menu items should be tagable. The right click menu could have "add a tag" and "remove a tag" submenus listing tags and an "advanced tags manager". A text box at the top of the menu could accept simple filters to dynamically list the menu. "games" would produce a menu with only items tagged "games". Including a negative tag would exclude items from the dynamic menu. For instance "games -turnbased". When no text was entered, all the menu items would be visible in sub menus named after tags. Sub menus would list all the items with that tag but also include sub sub menus based on the other tags the items included. Items with multiple tags would be reachable in multiple ways. For instance, games>Internet>wine>pogo2go Internet>games>wine>pogo2go wine>Internet>games>pogo2go wine>games>pogo2go wine>pogo2go games>pogo2go and so on. The top level sub menus based on tags would be a very big list. Navigating the sub sub menus to deeper levels reduces the size of the list because the items listed must be tagged with the name of each menu navigated. games>Internet>wine> would only show game including all three of these tags. This sub menu would show the equivalent of typing "games Internet wine" in the text box above.

Written by jeypeyy the 21 Sep 08 at 17:39.

In the "Colors"-tab in System>preferences>Appearance>Customize, there aren't many things to choose between (only Windows, Input boxes, Selected items, and Tooltips). It would be great if there were an "advanced"-button there that linked to gnome-color-chooser.

In the "Colors"-tab in System>preferences>Appearance>Customize, there aren't many things to choose between (only Windows, Input boxes, Selected items, and Tooltips). It would be great if there were an "advanced"-button there that linked to gnome-color-chooser.