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 geoff.m the 2 Nov 10 at 18:55.

When a folder doesn't have anything to expand it should not have a dropdown button, i.e. folders without subfolders in the folders panel on the left, and completely empty folders in the file panel on the right.

 

<p>When a folder doesn't have anything to expand it should not have a dropdown button, i.e. folders without subfolders in the folders panel on the left, and completely empty folders in the file panel on the right.</p><p>&nbsp;</p><p><img src="http://agora.ulaval.ca/~gemen16/nautilus_solution.jpg"></p>

Written by ak123 the 3 Nov 10 at 17:01.

If the folder is empty, Nautilus should attach an emblem to the icon to show the folder is empty. This can also be used when browsing in icon view and can also be applied to differentiate between folders with files and no subfolders and those that are completely empty.

If the folder is empty, Nautilus should attach an emblem to the icon to show the folder is empty. This can also be used when browsing in icon view and can also be applied to differentiate between folders with files and no subfolders and those that are completely empty.

Written by Benagain the 7 Nov 10 at 07:41.

To make the 'Network' window display other network devices, with the ability to at least look at their shared files.
Network hard drives are one thing I really want to be able to connect to, easily.

To make the 'Network' window display other network devices, with the ability to at least look at their shared files. Network hard drives are one thing I really want to be able to connect to, easily.

Written by linuxlalala the 13 Nov 10 at 13:13.

Nautilus can display a list of network devices like the "network" folder in windows. After doing that work, the ubuntu dev team can create a nautilus script that detects avaliable networks, lists them on the screen and easily conect to a network clicking on a network and pressing the "connect" buton.

Nautilus can display a list of network devices like the "network" folder in windows. After doing that work, the ubuntu dev team can create a nautilus script that detects avaliable networks, lists them on the screen and easily conect to a network clicking on a network and pressing the "connect" buton.

Written by zalluth the 14 Nov 10 at 09:23.

In the screenshot, there are connect, message, and file share buttons. So, it maybe useful to add remote button to give the user the ease to remote other computer even via gui or terminal.

In the screenshot, there are connect, message, and file share buttons. So, it maybe useful to add remote button to give the user the ease to remote other computer even via gui or terminal.

Written by zalluth the 14 Nov 10 at 09:29.

Honestly, it is already easy to create a bluetooth networking using blueman, maybe it will be easier if there is an option to create new bluetooth networking using this Ubuntu Network Center...

Honestly, it is already easy to create a bluetooth networking using blueman, maybe it will be easier if there is an option to create new bluetooth networking using this Ubuntu Network Center...

Written by zalluth the 14 Nov 10 at 09:39.

It maybe easier too, if there is menu to install related networking tools, such as: DHCP Server, etc...

It maybe easier too, if there is menu to install related networking tools, such as: DHCP Server, etc...

Written by graylion the 2 Dec 10 at 00:24.

We are not using X to anything like its potential but are instead stuck in a "one computer" paradigm rather than "the network is the computer". It should be easy to create menu items that run apps on a different box as long as you have the permissions.

We are not using X to anything like its potential but are instead stuck in a "one computer" paradigm rather than "the network is the computer". It should be easy to create menu items that run apps on a different box as long as you have the permissions.