Written by Nanotron the 28 Feb 08 at 20:17.

I feel there should be a Tool in Nautilus and Dolphin which allows mounting Images by double Click or something similar. (This feature exists int MacOS). Or with a right click on the I think that would be a very useful Tool for every one.
A good example for this is CDemu.

I know there are some other good programs, but I think that would be the easiest way

I feel there should be a Tool in Nautilus and Dolphin which allows mounting Images by double Click or something similar. (This feature exists int MacOS). Or with a right click on the I think that would be a very useful Tool for every one. A good example for this is CDemu. I know there are some other good programs, but I think that would be the easiest way

Written by Bender2k14 the 26 Jan 09 at 04:42.

I should be able to right-click a disk image and select "Mount Image" in the context-sensitive section (just as right-clicking on a disk image provides the "Write to Disk..." option).

I should be able to right-click a disk image and select "Mount Image" in the context-sensitive section (just as right-clicking on a disk image provides the "Write to Disk..." option).

Written by cbx33 the 20 Mar 09 at 12:22.

Gisomount was created to make this an easy process. It needs a little love and attention, but offered things like md5sum browsing etc. Would make a good GSoC project.

Gisomount was created to make this an easy process. It needs a little love and attention, but offered things like md5sum browsing etc. Would make a good GSoC project.

Written by markoresko the 13 May 09 at 08:35.

I use Gmount-iso to do just that.
sudo apt-get install gmountiso

But I also think that it could be more obvious to do that etc.
Maybe Gmount-iso should be available by default, under right-click on images, like proposed.

I use Gmount-iso to do just that. sudo apt-get install gmountiso But I also think that it could be more obvious to do that etc. Maybe Gmount-iso should be available by default, under right-click on images, like proposed.

Written by mikaelstaldal the 20 Oct 09 at 12:14.

Also make it possible to mount ISO images from command line without root (sudo) access.

Also make it possible to mount ISO images from command line without root (sudo) access.

Written by dexter_greycells the 24 Oct 09 at 07:41.

When the user selects the ISO file (through the keyboard arrow keys, Tab key or a single click) in nautilus a pop-up should come up asking the user to 'Double-click' the ISO file to mount it.

When the user selects the ISO file (through the keyboard arrow keys, Tab key or a single click) in nautilus a pop-up should come up asking the user to 'Double-click' the ISO file to mount it.

Written by r0g the 28 Oct 09 at 05:09.

In the form of a python script for nautilus actions.

http://www.technicalbloke.com/iso_mount.py

I don't have time to do the unmount command too but it should be easy to adapt if you know a little python, consider that homework & pls post me a copy :)

I think it would be nice if Ubuntu came with some more useful nautilus action scripts and a nicer way of adding/removing them. At the moment getting them in and out is more of a pain than it needs to be. It ought to be as easy as Firefox (if not easier!) to install plugins, maybe then people would make more.

Roger.

In the form of a python script for nautilus actions. http://www.technicalbloke.com/iso_mount.py I don't have time to do the unmount command too but it should be easy to adapt if you know a little python, consider that homework & pls post me a copy :) I think it would be nice if Ubuntu came with some more useful nautilus action scripts and a nicer way of adding/removing them. At the moment getting them in and out is more of a pain than it needs to be. It ought to be as easy as Firefox (if not easier!) to install plugins, maybe then people would make more. Roger.

Written by Lachu the 28 Oct 09 at 11:56.

Automatically mount *.iso files dragged onto computer window/desktop/places menu.

Automatically mount *.iso files dragged onto computer window/desktop/places menu.

Written by choad the 10 Mar 09 at 15:12.

By default have the file browser view open in "My Files"



but have "home" right there in the path bar, so it's just one click away.

By default have the file browser view open in "My Files" <a href="http://img510.imageshack.us/img510/6537/28jkw4.png"><img src="http://img510.imageshack.us/img510/6537/28jkw4.th.png" /></a> but have "home" right there in the path bar, so it's just one click away.

Written by Psycho_zs the 10 Mar 09 at 18:59.

and leave ~/ for configs stuff

and leave ~/ for configs stuff

Written by aysiu the 10 Mar 09 at 19:57.

I don't see a problem here. My home directory doesn't look like that.

I don't see a problem here. My home directory doesn't look like that.

Written by Cé the 11 Mar 09 at 11:00.

The directory ~/Documents already exist in Ubuntu, so the only change needed is the link in the "Places" menubar, and the default place when the filebrowser start.

The directory ~/Documents already exist in Ubuntu, so the only change needed is the link in the "Places" menubar, and the default place when the filebrowser start.

Written by fmorel90 the 11 Mar 09 at 14:56.

Convince developers to put their application settings under ~./config so that the Home folder looks neater even when hidden files are shown.

Convince developers to put their application settings under ~./config so that the Home folder looks neater even when hidden files are shown.

Written by zeroangelmk1 the 28 Mar 09 at 18:20.

~/.hidden is a text file which is supposed to allow the file manager to prevent certain files and folders in the home from being viewed in normal mode (unless 'view hidden files' is enabled). Mentioning this in a tip dialogue or creating a link to a program which edits this file for the user would be useful.

~/.hidden is a text file which is supposed to allow the file manager to prevent certain files and folders in the home from being viewed in normal mode (unless 'view hidden files' is enabled). Mentioning this in a tip dialogue or creating a link to a program which edits this file for the user would be useful.

Written by cheesehead the 25 Mar 09 at 00:39.

Use Gconf for many config settings. That's what it's for, it's already included in the default install, and it offers many benefits to the apps that use it. Including KDE apps (Gconf does not require Gnome).
Many upstream projects could use volunteer love to help convert from .conf files to Gconf settings.

Use Gconf for many config settings. That's what it's for, it's already included in the default install, and it offers many benefits to the apps that use it. Including KDE apps (Gconf does not require Gnome). Many upstream projects could use volunteer love to help convert from .conf files to Gconf settings.

Written by benpicco the 26 Mar 09 at 03:12.

EDIT: So just use $XDG_CONFIG_HOME
http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html

By using an environment variable, everyone can decide where the config goes - one could even set $XDG_CONFIG_HOME=/tmp/ to try something out without overwriting the existing configuration - or having multiple configs for the same application with no effort. It's a flexible solution which would be even more easy to implement. (considering applications use getenv("HOME") to determine the home folder, the only change would be to replace getenv("HOME") with getenv("XDG_CONFIG_HOME").)

EDIT: So just use $XDG_CONFIG_HOME http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html By using an environment variable, everyone can decide where the config goes - one could even set $XDG_CONFIG_HOME=/tmp/ to try something out without overwriting the existing configuration - or having multiple configs for the same application with no effort. It's a flexible solution which would be even more easy to implement. (considering applications use getenv("HOME") to determine the home folder, the only change would be to replace getenv("HOME") with getenv("XDG_CONFIG_HOME").)

Written by codexx the 1 Apr 09 at 06:08.

Either make the user folders or the autogenerated folders, have different icons.

This can be done in addition to other suggestions and i imagine be relatively simple

Either make the user folders or the autogenerated folders, have different icons. This can be done in addition to other suggestions and i imagine be relatively simple

Written by jamesisin the 7 Apr 09 at 06:26.

It certainly would help these matters if there was a simple button which would allow us to toggle hidden files on and off.

It certainly would help these matters if there was a simple button which would allow us to toggle hidden files on and off.

Written by tchalvakspam the 9 Apr 09 at 02:42.

Often app or config files and folders -can't- be moved, or renamed with a dot, or perhaps they will just be frequently auto-created even if they were moved. So we need to be able to just hide files or folders that we don't want to see ourselves, but still get used in that location by applications. Make that simple to do from the right click menu.

Often app or config files and folders -can't- be moved, or renamed with a dot, or perhaps they will just be frequently auto-created even if they were moved. So we need to be able to just hide files or folders that we don't want to see ourselves, but still get used in that location by applications. Make that simple to do from the right click menu.

Written by mykeus the 10 Oct 09 at 07:05.

I tend to edit configurations alot and one thing i did like about OSX was making use of Library Folder under each user home directory.

$HOME/.config are conforming to old standard and is it nasty.

$HOME/library not only can we eliminate the .dotfile orgy in each directory and better organize the home structure, but it would assist in user accessible files. ex. ruby gems, perl modules, skins, icons.

I tend to edit configurations alot and one thing i did like about OSX was making use of Library Folder under each user home directory. $HOME/.config are conforming to old standard and is it nasty. $HOME/library not only can we eliminate the .dotfile orgy in each directory and better organize the home structure, but it would assist in user accessible files. ex. ruby gems, perl modules, skins, icons.

Written by xeniac the 3 Oct 09 at 23:31.

Every graphical Application in Ubuntu should be conform to the Basedir Spec from the Free Desktop Project (See:
http://standards.freedesktop.org/basedir-spec/latest/index.html)

* User specific config files should be stored in gconf, or in $HOME/.config

* named pipes, cache-files, and any other application data should be saved under $HOME/.local/share/$APP_NAME

Every GUI application that does not conform to this spec, should be cousiderd faulty and a bug should be reported to fix it in upstream.

Pure CLI Packages should'nt be affected by this, to preserve UNIX compatibility.

Every graphical Application in Ubuntu should be conform to the Basedir Spec from the Free Desktop Project (See: http://standards.freedesktop.org/basedir-spec/latest/index.html) * User specific config files should be stored in gconf, or in $HOME/.config * named pipes, cache-files, and any other application data should be saved under $HOME/.local/share/$APP_NAME Every GUI application that does not conform to this spec, should be cousiderd faulty and a bug should be reported to fix it in upstream. Pure CLI Packages should'nt be affected by this, to preserve UNIX compatibility.

Written by Lachu the 29 Oct 09 at 18:30.

Prevent user from removing this files/directories. Each hidden file in user home directory should been protected from being removed by user. Nautilus, Dolphin, etc. should show warning messages in this situation.

Prevent user from removing this files/directories. Each hidden file in user home directory should been protected from being removed by user. Nautilus, Dolphin, etc. should show warning messages in this situation.

Written by mahan_h the 6 Mar 09 at 05:10.

Dedicating a nice panel for adding more criteria and metadata to search in, like "Context", "Size", "Date", "Hidden", "Recursive" and etc. along adding advanced metadata search capabilities for some specific files like mp3s like searching for a specific artist, album and etc. plus mixing these abilities together.

Dedicating a nice panel for adding more criteria and metadata to search in, like "Context", "Size", "Date", "Hidden", "Recursive" and etc. along adding advanced metadata search capabilities for some specific files like mp3s like searching for a specific artist, album and etc. plus mixing these abilities together.

Written by Endolith the 4 Feb 09 at 02:51.

100,000 meters is equal to 100 km, and 100,000 bytes is equal to 100 kB.

This is how the vast majority of end-users expect their computers to operate, since it's what they use in everyday life.

This is the way it's already done by apt/Synaptic, fdisk, parted, the Linux kernel, and defined in the Linux Programmer's Manual (type 'man 7 units' in a terminal). It should be done the same way everywhere, especially Nautilus.

Using standard 1000-based math would make calculations intuitive, without confusing users with math like "512 + 512 = 1000".

1024-based measurements are fine for things that are based on powers of two (like memory sizes or partition sizes), but file sizes are NOT based on powers of two; they can be any arbitrary number. When combining the sizes of multiple files to figure out if they will fit on a disk, it makes much more sense to work in decimal.

If you buy a new harddrive that holds 500,107,862,016 bytes, which is the most logical way to abbreviate the size: "500.1 GB" or "465.8 GB"? Microsoft reports this as "465.8 GB" in one place and "476,940 MB" in another. Yes, they have a long tradition of doing it this way, but... why? How does this benefit the user? It's useless.

100,000 meters is equal to 100 km, and 100,000 bytes is equal to 100 kB. This is how the vast majority of end-users expect their computers to operate, since it's what they use in everyday life. This is the way it's already done by apt/Synaptic, fdisk, parted, the Linux kernel, and defined in the Linux Programmer's Manual (type 'man 7 units' in a terminal). It should be done the same way everywhere, especially Nautilus. Using standard 1000-based math would make calculations intuitive, without confusing users with math like "512 + 512 = 1000". 1024-based measurements are fine for things that are based on powers of two (like memory sizes or partition sizes), but file sizes are NOT based on powers of two; they can be any arbitrary number. When combining the sizes of multiple files to figure out if they will fit on a disk, it makes much more sense to work in decimal. If you buy a new harddrive that holds 500,107,862,016 bytes, which is the most logical way to abbreviate the size: "500.1 GB" or "465.8 GB"? Microsoft reports this as "465.8 GB" in one place and "476,940 MB" in another. Yes, they have a long tradition of doing it this way, but... why? How does this benefit the user? It's useless. • A 500,107,862,016 byte hard drive should be abbreviated as "500.1 GB". • A 4,700,372,992 byte DVD should be abbreviated as "4.7 GB" • A 123,888,499 byte file should be abbreviated as "123.9 MB" Why should a user be presented with a number that looks like decimal, but actually isn't?

Written by Endolith the 4 Feb 09 at 13:22.

This would continue the Microsoft tradition of 1024-based measurements, but using the standard units. This is also in the Linux Programmer's Manual.

• A 500,107,862,016 byte hard drive would be abbreviated as "465.8 GiB".
• A 4,700,372,992 byte DVD would be abbreviated as "4.4 GiB"
• A 123,888,499 byte file would be abbreviated as "118.1 MiB"

If you vote for this option, please explain in the comments why you think 1024-based math is more useful.

This would continue the Microsoft tradition of 1024-based measurements, but using the standard units. This is also in the Linux Programmer's Manual. • A 500,107,862,016 byte hard drive would be abbreviated as "465.8 GiB". • A 4,700,372,992 byte DVD would be abbreviated as "4.4 GiB" • A 123,888,499 byte file would be abbreviated as "118.1 MiB" If you vote for this option, please explain in the comments why you think 1024-based math is more useful.

Written by twocool the 8 Feb 09 at 15:09.

Implement both and let the user choose.

Implement both and let the user choose.

Written by Endolith the 30 Mar 09 at 16:26.

1024 makes more sense when working with memory, since memory is always a power of 2, but 1000 makes more sense when working with file sizes, disk sizes, and most other things, since they can be any arbitrary number.

• For memory, use KiB = 1024, according to the IEC standard.
• For file sizes, disk sizes, and most other things, use kB = 1000, according to the SI standard.

These two standards are explained in the "units" man page in the Linux Programmer's Manual, and on the NIST website.

k = 1000 is already used for thing like networking, hard drives, and DVDs. It's already used for file sizes in things like the Linux kernel, apt, Synaptic, fdisk, and Qtparted. We should use it for file sizes everywhere.

1024 makes more sense when working with memory, since memory is always a power of 2, but 1000 makes more sense when working with file sizes, disk sizes, and most other things, since they can be any arbitrary number. • For memory, use KiB = 1024, according to the IEC standard. • For file sizes, disk sizes, and most other things, use kB = 1000, according to the SI standard. These two standards are explained in the <a href="http://www.kernel.org/doc/man-pages/online/pages/man7/units.7.html">"units" man page in the Linux Programmer's Manual</a>, and on the <a href="http://physics.nist.gov/cuu/Units/binary.html">NIST website</a>. k = 1000 is already used for thing like networking, hard drives, and DVDs. It's already used for file sizes in things like the Linux kernel, apt, Synaptic, fdisk, and Qtparted. We should use it for file sizes everywhere.

Written by Richieland the 11 Mar 09 at 15:40.

There is a brain damaged standard that says that 1kB is 1000 bytes. This is based on the physical SI units. But "byte" is no SI unit because it is no physical unit.
This standard is basically a marketing effect used by mass storage sellers but technically it is completly nonsense: Would you buy a new computer with 4294,967296MB RAM (=4*1024*1024*1024 bytes)?
Nearly everything in the computer world is based on powers of two. Therefore it just causes confusion if we start using something else.
As a short note: What about MBit? They would also have to be changed, e.g. the download speed of your DSL connection would habe to be specified as 6,291456 MBit/s instead of 6 MBit/s. Heaven't seen that yet.
And the Kib, Mib abd Gib units are no replacement because no average user knows them and they sound rather silly (they are not suitable for an ad).

There is a brain damaged standard that says that 1kB is 1000 bytes. This is based on the physical SI units. But "byte" is no SI unit because it is no physical unit. This standard is basically a marketing effect used by mass storage sellers but technically it is completly nonsense: Would you buy a new computer with 4294,967296MB RAM (=4*1024*1024*1024 bytes)? Nearly everything in the computer world is based on powers of two. Therefore it just causes confusion if we start using something else. As a short note: What about MBit? They would also have to be changed, e.g. the download speed of your DSL connection would habe to be specified as 6,291456 MBit/s instead of 6 MBit/s. Heaven't seen that yet. And the Kib, Mib abd Gib units are no replacement because no average user knows them and they sound rather silly (they are not suitable for an ad).

Written by krs the 11 Mar 09 at 09:39.

1 kilo binary byte = 1024 bytes
Using kB as unit conflicts with the SI definition of the prefix "kilo" ("kilo" mean 1000, not 1024)

The IEC unit standard unit for a kilo binary byte is KiB

1KiB = 1024B
1MiB = 1024KiB
1GiB = 1024MiB
...

http://en.wikipedia.org/wiki/Kibibyte

1 kilo binary byte = 1024 bytes Using kB as unit conflicts with the SI definition of the prefix "kilo" ("kilo" mean 1000, not 1024) The IEC unit standard unit for a kilo binary byte is KiB 1KiB = 1024B 1MiB = 1024KiB 1GiB = 1024MiB ... http://en.wikipedia.org/wiki/Kibibyte

Written by davourak the 10 Mar 09 at 21:17.

The size of anything in Ubuntu, whether in Nautilus or elsewhere, should display the kB symbol correctly for kilobytes and not use the incorrect KB symbol.

The size of anything in Ubuntu, whether in Nautilus or elsewhere, should display the kB symbol correctly for kilobytes and not use the incorrect KB symbol.

Written by codeslicer the 2 Mar 09 at 15:10.

Right now right clicking anywhere in the list of files shows "Add to Bookmark" and "Show Hidden Files".

I think that right clicking on the file should provide options such as rename, delete, or open with viewer.

Right now right clicking anywhere in the list of files shows "Add to Bookmark" and "Show Hidden Files". I think that right clicking on the file should provide options such as rename, delete, or open with viewer.

Written by codeslicer the 2 Mar 09 at 15:14.

Sometimes you want to know if the file you're selecting is the right one.

There should be a small button near the file selection list, which would toggle previews on and off. This could be remembered for future selections or configured from Nautilus settings.

When preview is on, single clicking on a file would show a preview of the file. For example, sometimes in some applications a preview of an image is shown. However, it'd be great if text previews or excerpts for text files, documents, presentations, programming files, and other files were added.

In addition, previews could have an option to zoom in or show more information in a popup.

Sometimes you want to know if the file you're selecting is the right one. There should be a small button near the file selection list, which would toggle previews on and off. This could be remembered for future selections or configured from Nautilus settings. When preview is on, single clicking on a file would show a preview of the file. For example, sometimes in some applications a preview of an image is shown. However, it'd be great if text previews or excerpts for text files, documents, presentations, programming files, and other files were added. In addition, previews could have an option to zoom in or show more information in a popup.

Written by codeslicer the 2 Mar 09 at 15:27.

One of the key features cherished by Linux users is that it can work Great on old hardware (or at least better than Windows can).

However, when on an 866Mhz machine, selecting File->Open... from some application results in a combination of slow and ugly "effects".

This is what happens after opening the file selector:
1.)A small dialog with white boxes shows.
2.)The dialog gets resized to be about twice as big.
3.)Everything is drawn.
4.)After clicking on an image file, the dialog again resizes to accomodate the preview.

This looks really jagged and unstable, despite an 866Mhz computer not being the slowest of all Linux users.

Instead, the dialog box should already start up with its proper size, or perhaps at least remain hidden until its contents are fully loaded (just have the mouse cursor change to waiting status while the dialog is secretively constructed).

Or, the dialog should be preloaded in Nautilus memory, and instead of having a plain white box while the dialog is loading, have a "Loading..." text box. In addition load the buttons & icons before the file selection list, so that it just looks a bit more speedy. Maybe even use multiple threads so that the ui doesn't freeze...

One of the key features cherished by Linux users is that it can work Great on old hardware (or at least better than Windows can). However, when on an 866Mhz machine, selecting File->Open... from some application results in a combination of slow and ugly "effects". This is what happens after opening the file selector: 1.)A small dialog with white boxes shows. 2.)The dialog gets resized to be about twice as big. 3.)Everything is drawn. 4.)After clicking on an image file, the dialog again resizes to accomodate the preview. This looks really jagged and unstable, despite an 866Mhz computer not being the slowest of all Linux users. Instead, the dialog box should already start up with its proper size, or perhaps at least remain hidden until its contents are fully loaded (just have the mouse cursor change to waiting status while the dialog is secretively constructed). Or, the dialog should be preloaded in Nautilus memory, and instead of having a plain white box while the dialog is loading, have a "Loading..." text box. In addition load the buttons & icons before the file selection list, so that it just looks a bit more speedy. Maybe even use multiple threads so that the ui doesn't freeze...