Written by cyrex the 30 Sep 12 at 16:23.

For example leaving SUPER+Z pressed, the user can go to the background Window, without the focus changing windows (All Windows will maintain their current positions) and dragging or CTRL+Select/ Shift+Select items from the background window and dragging them to the front focus window.

For example leaving SUPER+Z pressed, the user can go to the background Window, without the focus changing windows (All Windows will maintain their current positions) and dragging or CTRL+Select/ Shift+Select items from the background window and dragging them to the front focus window.

Written by tenplus1 the 1 Oct 12 at 08:20.

Why not implement a mouse focus system like the one they use in Enlightenent (e17) "Click", "Pointer", "Sloppy" which you can set to your own personal preference... Also you can set wether you want the window to pop to the front during that focus method or you really have to click on it to do so...

Why not implement a mouse focus system like the one they use in Enlightenent (e17) "Click", "Pointer", "Sloppy" which you can set to your own personal preference... Also you can set wether you want the window to pop to the front during that focus method or you really have to click on it to do so...

Written by jonasPlatte the 3 Oct 12 at 08:05.

One simple improvement would be allowing the user to use Alt+Tab while dragging an item from one window.

One simple improvement would be allowing the user to use Alt+Tab while dragging an item from one window.

Written by jonasPlatte the 3 Oct 12 at 08:12.

It would be nice if a program would move to the foreground when you rest the mouse e.g. 2 seconds on the Icon in the Unity launcher. This could be either an addition or a replacement for the current option to open a file with a program by dragging the file to the programs icon (I don't know anyone who uses that feature)

It would be nice if a program would move to the foreground when you rest the mouse e.g. 2 seconds on the Icon in the Unity launcher. This could be either an addition or a replacement for the current option to open a file with a program by dragging the file to the programs icon (I don't know anyone who uses that feature)

Written by Aielyn the 14 Oct 12 at 18:13.

As the title of the solution suggests, set the focus system up so that focus only changes when the mouse button is released, not when it is pressed (unless the user clicks on the title bar for a non-maximised window). This allows the user to click-and-drag from a window that doesn't officially have focus to the one that does, without needing any more complicated change. It avoids the need for any sort of keystroke or additional command, and should make no difference to any other context.

As the title of the solution suggests, set the focus system up so that focus only changes when the mouse button is released, not when it is pressed (unless the user clicks on the title bar for a non-maximised window). This allows the user to click-and-drag from a window that doesn't officially have focus to the one that does, without needing any more complicated change. It avoids the need for any sort of keystroke or additional command, and should make no difference to any other context.

Written by GUI_Junkie the 9 Sep 12 at 17:25.

I'm guessing the code to populate the list is running before the focus is put on the textbox in a synchronous fashion. By detaching it, the focus can be put on the textbox immediately.

I'm guessing the code to populate the list is running before the focus is put on the textbox in a synchronous fashion. By detaching it, the focus can be put on the textbox immediately.

Written by jonasPlatte the 3 Oct 12 at 08:52.

Currently, the normal letter keys can only be used in the search box. There is no other part of the USC where you can type anything. Why not just start searching when you type (whenever the search bar is visible, not when viewing one application)?

Currently, the normal letter keys can only be used in the search box. There is no other part of the USC where you can type anything. Why not just start searching when you type (whenever the search bar is visible, not when viewing one application)?

Written by Eldmannen the 28 Oct 11 at 14:56.

I would like an option to dim the file extension in Nautilus.
Many web browsers have now began dimming less relevant parts of the URL, such as the protocol, subdomain, path, and query string.
I propose we have an option/setting/feature that does the same Nautilus. Dim the the file extension.

I would like an option to dim the file extension in Nautilus. Many web browsers have now began dimming less relevant parts of the URL, such as the protocol, subdomain, path, and query string. I propose we have an option/setting/feature that does the same Nautilus. Dim the the file extension. <img src="http://img683.imageshack.us/img683/7264/nautiluswithdimmedexten.png">

Written by Eldmannen the 28 Oct 11 at 15:02.

I would like an option to dim the file extension in Gtk file chooser dialogs.

I would like an option to dim the file extension in Gtk file chooser dialogs. <img src="http://img401.imageshack.us/img401/6733/gtkfilechoser.png">

Written by thehosh the 29 Oct 11 at 23:36.

I propose that the file extensions are hidden by default, if a user needs/wants them, they can enable it in the settings. Maybe even add a dim feature (File extensions: Hidden/Show/Dimmed).
Of course, this would be system wide.

I propose that the file extensions are hidden by default, if a user needs/wants them, they can enable it in the settings. Maybe even add a dim feature (File extensions: Hidden/Show/Dimmed). Of course, this would be system wide.

Written by jonasPlatte the 31 Oct 11 at 14:24.

I propose to make it an option to show the file extension normally or completely hide it, and set "dimmed" as default.

I propose to make it an option to show the file extension normally or completely hide it, and set "dimmed" as default.

Written by ckujau the 31 Oct 11 at 18:35.

If this is wanted at all, I propose to show the file extension by default and provide an option to hide/dim it. The individual user should judge what she considers as "less relevant parts of the URL".

If this is wanted at all, I propose to show the file extension by default and provide an option to hide/dim it. The individual user should judge what she considers as "less relevant parts of the URL".

Written by NictraSavios the 6 Nov 11 at 02:36.

Linux has no concept of a "file extension" like legacy operating systems. You may name files any way you like. The contents/purpose of a file is determined by other means.

This means that a file extension should have no bearing on linux users, a text file is not denoted by .txt, and MPEG layer 3 doesn't have to have .mp3. If a program requires an extension, then the developer should be notified immediately about proper Linux concepts.

This is something that has been a sticking point for Linux users since before Ubuntu was even around, if you are going to give any mention to file extensions, it should be that they mean nothing.

They shouldn't be hidden, they shouldn't be dimmed, they are part of the file name in Linux and should be treated as such, they tell the USER what the file is and the system doesn't care. Its just a name. So if you have problems with them, your in luck.... just ditch them. You do not need them. They are simply there for the user to be able to tell that "this is an image, this is a music file", the system doesn't care. Neither should you.

If this is for compatibility with Windows, then an option to hide them would be sufficient, but please, please, please do not make it default.

Linux has no concept of a "file extension" like legacy operating systems. You may name files any way you like. The contents/purpose of a file is determined by other means. This means that a file extension should have no bearing on linux users, a text file is not denoted by .txt, and MPEG layer 3 doesn't have to have .mp3. If a program requires an extension, then the developer should be notified immediately about proper Linux concepts. This is something that has been a sticking point for Linux users since before Ubuntu was even around, if you are going to give any mention to file extensions, it should be that they mean nothing. They shouldn't be hidden, they shouldn't be dimmed, they are part of the file name in Linux and should be treated as such, they tell the USER what the file is and the system doesn't care. Its just a name. So if you have problems with them, your in luck.... just ditch them. You do not need them. They are simply there for the user to be able to tell that "this is an image, this is a music file", the system doesn't care. Neither should you. If this is for compatibility with Windows, then an option to hide them would be sufficient, but please, please, please do not make it default.

Written by Gregory the 13 Nov 11 at 23:07.

Nautilus has three views right now: Icons, List, and Compact. Considering the optional extra pane and sidebar, and the combinations possible, you might say we have 36 views. If you're looking for files based on something like access time or permissions, the icon view isn't very helpful, but if you're looking at a small set of well known files related to a project, the list might have too much irrelevant information and the compact view might not have enough. If you're moving lots of files around, you might want an extra pane or tree view sidebar instead of two separate windows.

The filesystem hierarchy can be categorized in many ways. One set of categories might be "a user's files" and "everything else". The user's files category would typically include all non-hidden directories and files in the user's home folder. These are fewer in number and more familiar to the user than everything else. In any directory they are usually more type-heterogeneous than files in standard system directories like "/usr/bin".

The icon view is better suited for a small set of familiar files of different types, while the list view is better suited for large sets of unfamiliar files of the same type. The default view for non-hidden directories in the user's home folder should be the icon view, and the default view for everything else should be the list view.

This simple division (user's files, everything else) and use of just two views (icons, list) is only meant to be an example. This is only for the default view when a user first visits a directory and is not meant to disallow changing the view or having the change remembered by file manager.

Nautilus has three views right now: Icons, List, and Compact. Considering the optional extra pane and sidebar, and the combinations possible, you might say we have 36 views. If you're looking for files based on something like access time or permissions, the icon view isn't very helpful, but if you're looking at a small set of well known files related to a project, the list might have too much irrelevant information and the compact view might not have enough. If you're moving lots of files around, you might want an extra pane or tree view sidebar instead of two separate windows. The filesystem hierarchy can be categorized in many ways. One set of categories might be "a user's files" and "everything else". The user's files category would typically include all non-hidden directories and files in the user's home folder. These are fewer in number and more familiar to the user than everything else. In any directory they are usually more type-heterogeneous than files in standard system directories like "/usr/bin". The icon view is better suited for a small set of familiar files of different types, while the list view is better suited for large sets of unfamiliar files of the same type. The default view for non-hidden directories in the user's home folder should be the icon view, and the default view for everything else should be the list view. This simple division (user's files, everything else) and use of just two views (icons, list) is only meant to be an example. This is only for the default view when a user first visits a directory and is not meant to disallow changing the view or having the change remembered by file manager.

Written by puxkggn the 27 Feb 12 at 18:15.

Dimming (but only slightly) the file extension is clearer to read.


When selecting a filename and choosing to change the filename from the gui. By default the selected text should be the name selected from he beginning to the first dot. A user can still select the whole name or pieces of it as he or she sees fit. This way it's the most efficient because most of the time most users don't want to change the extension, just the name.

This will help inexperienced or careless users a lot!!!
While still allowing power users to change the whole thing.
While allowing people to easily discard the extensions if they are searching for a specific file name.

Dimming (but only slightly) the file extension is clearer to read. When selecting a filename and choosing to change the filename from the gui. By default the selected text should be the name selected from he beginning to the first dot. A user can still select the whole name or pieces of it as he or she sees fit. This way it's the most efficient because most of the time most users don't want to change the extension, just the name. This will help inexperienced or careless users a lot!!! While still allowing power users to change the whole thing. While allowing people to easily discard the extensions if they are searching for a specific file name.

Written by Aielyn the 7 Mar 12 at 14:10.

Rather than dimming or hiding extensions, how about making extensions actually useful? As noted in Solution #6, extensions in Linux should mean nothing more than "this is how we've decided to end the name of the file".

But there's definite use for extensions. Octave/Matlab use ".m" files, which are really nothing more than text files... but the ".m" tells you that it's matlab code that is in the file. It also helps Matlab/Octave to know that your file is intended to be read by them, in an efficient manner.

But perhaps it would be useful if extensions were also used to essentially "tag" a file. This would provide a useful way to "group" files within a directory without requiring more directories. Then, nautilus could sort files by their extensions (optionally either grouping those with multiple extensions by their set of extensions, or displaying them repeatedly in each of their groups).

This is an extension, if you'll pardon the pun, of the original purpose of extensions, which is to make it easier (for both user and computer) to see what sort of file it is. While someone could certainly choose to name all of their work files "WorkXyz" (which would then sort "nicely" in Nautilus), it would be nicer if they could be named "Xyz.work". Then, if someone makes an m-file for work, it could be named "Xyz.work.m"... and they could have Nautilus automatically group all the ".work" files together.

As such, extensions suddenly no longer need to be hidden or dimmed, but instead become a useful part of the filename.

Rather than dimming or hiding extensions, how about making extensions actually useful? As noted in Solution #6, extensions in Linux should mean nothing more than "this is how we've decided to end the name of the file". But there's definite use for extensions. Octave/Matlab use ".m" files, which are really nothing more than text files... but the ".m" tells you that it's matlab code that is in the file. It also helps Matlab/Octave to know that your file is intended to be read by them, in an efficient manner. But perhaps it would be useful if extensions were also used to essentially "tag" a file. This would provide a useful way to "group" files within a directory without requiring more directories. Then, nautilus could sort files by their extensions (optionally either grouping those with multiple extensions by their set of extensions, or displaying them repeatedly in each of their groups). This is an extension, if you'll pardon the pun, of the original purpose of extensions, which is to make it easier (for both user and computer) to see what sort of file it is. While someone could certainly choose to name all of their work files "WorkXyz" (which would then sort "nicely" in Nautilus), it would be nicer if they could be named "Xyz.work". Then, if someone makes an m-file for work, it could be named "Xyz.work.m"... and they could have Nautilus automatically group all the ".work" files together. As such, extensions suddenly no longer need to be hidden or dimmed, but instead become a useful part of the filename.

Written by Laslow the 17 Jan 12 at 05:16.

Either as part of the installer when detecting the system type, or as a configurable option, or both, allow the "NumLock is Enabled" warning to be changed to "NumLock is Disabled" to remind desktop users when this is the case.

Either as part of the installer when detecting the system type, or as a configurable option, or both, allow the "NumLock is Enabled" warning to be changed to "NumLock is Disabled" to remind desktop users when this is the case.

Written by jonasPlatte the 17 Jan 12 at 16:02.

I think it's better to have a selection between warning for only capsLock, only numLock, both or none. And perhaps it would be good to have the choice to "invert" the warning for numLock, like Solution #1.

I think it's better to have a selection between warning for only capsLock, only numLock, both or none. And perhaps it would be good to have the choice to "invert" the warning for numLock, like Solution #1.

Written by PaddyLandau the 17 Jan 12 at 19:15.

It used to be that the computer would remember your preference. Turn on Num Lock? It would still be on when you were ready to log in next time. Turn off Num Lock? It would still be off when you were ready to log in the next time.

That makes so much more sense.

It used to be that the computer would remember your preference. Turn on Num Lock? It would still be on when you were ready to log in next time. Turn off Num Lock? It would still be off when you were ready to log in the next time. That makes so much more sense.