Written by mahdif62 the 6 Mar 09 at 17:26.

Think about a Programs directory, when each package is installed with all its dependencies, installation is a matter of copying or extracting an archive, and removing the folder will uninstall the program. Please take a look at Gobo Linux to see how they have implemented the idea. Shared libraries can be installed in a common directory, and a mechanism should be defined to avoid duplicate libraries.

Think about a Programs directory, when each package is installed with all its dependencies, installation is a matter of copying or extracting an archive, and removing the folder will uninstall the program. Please take a look at Gobo Linux to see how they have implemented the idea. Shared libraries can be installed in a common directory, and a mechanism should be defined to avoid duplicate libraries.

Written by mahdif62 the 17 Mar 09 at 09:49.

Programs can be packaged with static shard libraries, so that the user can just extract and run the program.

Programs can be packaged with static shard libraries, so that the user can just extract and run the program.

Written by sf_007 the 15 Jun 09 at 01:53.

RUNZ allows portable apps on Ubuntu:
http://hacktolive.org/runz

RUNZ allows portable apps on Ubuntu: http://hacktolive.org/runz

Written by nerdopolis the 29 Jan 10 at 04:00.

util-linux-ng 2.17 brings in a new utility. I think Ubuntu Karmic uses util-linux-ng 2.16, and Lucid will use the new 2.17

The new utility is called unshare and it basically brings a feature that has existed in the Linux kernel for some time, down to the commandline/scripting world.

It allows you to "separate" the view of file system for the shell (such as bash) you run it in. Once you separate it, you can mount a FS on /media within that shell, and that shell, and other programs run from it will see it mounted under /media, but other processes won't see anything mounted under /media. A util-linux-ng developer describes it here http://karelzak.blogspot.com/2009/12/unshare1.html
-----------------------------------------------------------

Basically the idea is that apps can be made portable by being compiled with an agreed upon --prefix, as well as their depends, the path will have to be fixed (so it cant be in the users home directory), and they will need permission to access it.

The compiled app and depends could be packaged in a cramfs package, and a script can be provided with it to deal with the unshare, PATH and LD_LIBRARY_PATH environment setting (and the environment path varibles should set priorty for the directory the app is set to be compiled in, over the system paths), and mounting it with fuse-ext2, and then launching of the app. This could allow apps to be stored in only two files. (but they will both be dependent on each other). I have a script thought out that could make the creation of this almost completly automatic, so that all devs need to do is edit the makefile to configure it to the prefix, and tell the script the name of their executable so the launcher knows the name. ...in theory.

util-linux-ng 2.17 brings in a new utility. I think Ubuntu Karmic uses util-linux-ng 2.16, and Lucid will use the new 2.17 The new utility is called unshare and it basically brings a feature that has existed in the Linux kernel for some time, down to the commandline/scripting world. It allows you to "separate" the view of file system for the shell (such as bash) you run it in. Once you separate it, you can mount a FS on /media within that shell, and that shell, and other programs run from it will see it mounted under /media, but other processes won't see anything mounted under /media. A util-linux-ng developer describes it here http://karelzak.blogspot.com/2009/12/unshare1.html ----------------------------------------------------------- Basically the idea is that apps can be made portable by being compiled with an agreed upon --prefix, as well as their depends, the path will have to be fixed (so it cant be in the users home directory), and they will need permission to access it. The compiled app and depends could be packaged in a cramfs package, and a script can be provided with it to deal with the unshare, PATH and LD_LIBRARY_PATH environment setting (and the environment path varibles should set priorty for the directory the app is set to be compiled in, over the system paths), and mounting it with fuse-ext2, and then launching of the app. This could allow apps to be stored in only two files. (but they will both be dependent on each other). I have a script thought out that could make the creation of this almost completly automatic, so that all devs need to do is edit the makefile to configure it to the prefix, and tell the script the name of their executable so the launcher knows the name. ...in theory. Where unshare fits in is that the --prefix directory can be separate for all the apps. If two portable apps use incompatible versions of a library, they wont interfere, in theory. Then again, i'm not sure how Linux manages libraries. It might use the one of the same name in ram if its loaded...? The user settings would still be created in the users directory, and will not go with the image. I cant think of a good way to securely and practically solve that for multi-user on multi-systems. The major MAJOR problem is how many depends to include, to make it work on all systems, or without making the package too huge. a gtk app and its package will work on a default Ubuntu system without providing the gtk libraries, but it won't work on a kubuntu system without them, and a Hardy user might have older GTK libs that are incompatible. And then when it gets into multiple distros, which would be possible, one could be using less depends then ubuntu... The packages that would be need to be installed are util-linux-ng 2.17, and fuse-ext2. these are not installed in Ubuntu by default. BTW: This would generate in place runnable apps. They wont be installable. What do you think?

Written by mahdif62 the 10 Aug 10 at 09:55.

The Portable Linux Apps project brings the ideal of "1 app, 1 file" to Linux. Applications are able to run on all major distributions irrespective of their packaging systems - everything the application needs to run is packaged up inside of it. There are no folders to extract, dependencies to install or commands to enter: "Just download, make executable, and run!"

See here: http://www.omgubuntu.co.uk/2010/07/portable-linux-apps-run-your-favourite.html and here: http://sourceforge.net/projects/portable for details.

The Portable Linux Apps project brings the ideal of "1 app, 1 file" to Linux. Applications are able to run on all major distributions irrespective of their packaging systems - everything the application needs to run is packaged up inside of it. There are no folders to extract, dependencies to install or commands to enter: "Just download, make executable, and run!" See here: http://www.omgubuntu.co.uk/2010/07/portable-linux-apps-run-your-favourite.html and here: http://sourceforge.net/projects/portable for details.

Written by mahdif62 the 10 Aug 10 at 10:19.

By being self-contained one-click solutions that can run on multiple distributions without requiring the installation of anything else they provide an easy solution to the headache of packaging applications in so many various formats. 1 app = 1 file = any os.

Better yet AppImages don’t require administrative privileges in order to run. This makes AppImages a safe and secure way to not only try out the latest version of software without damaging any locally installed versions but also afford users a greater level of security as they are unable to affect the file system as a whole.

As AppImage’s can be run from anywhere users are able to store them wherever they like: a dedicated folder in their home drive, a USB drive, even a network share! Better yet you won’t find excess libraries or cruft left behind when you move or delete them - just delete and it’s gone.

More info here: http://www.omgubuntu.co.uk/2010/07/distro-agnostic-packaging-making.html and here:http://www.elementary-project.com/wiki/index.php?title=AppImages for more details.

By being self-contained one-click solutions that can run on multiple distributions without requiring the installation of anything else they provide an easy solution to the headache of packaging applications in so many various formats. 1 app = 1 file = any os. Better yet AppImages don’t require administrative privileges in order to run. This makes AppImages a safe and secure way to not only try out the latest version of software without damaging any locally installed versions but also afford users a greater level of security as they are unable to affect the file system as a whole. As AppImage’s can be run from anywhere users are able to store them wherever they like: a dedicated folder in their home drive, a USB drive, even a network share! Better yet you won’t find excess libraries or cruft left behind when you move or delete them - just delete and it’s gone. More info here: http://www.omgubuntu.co.uk/2010/07/distro-agnostic-packaging-making.html and here:http://www.elementary-project.com/wiki/index.php?title=AppImages for more details.

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 twocool the 1 Apr 10 at 14:57.

Ubuntu default themes (Ambiance and Radiance) should be ported to wine (msstyles) so those applications look better integated with ubuntu.

Ubuntu default themes (Ambiance and Radiance) should be ported to wine (msstyles) so those applications look better integated with ubuntu.

Written by PKduck the 2 Apr 10 at 09:19.

You don't need to port themes anymore and those applications look better integrated with ubuntu even you hate ubuntu default themes.

You don't need to port themes anymore and those applications look better integrated with ubuntu even you hate ubuntu default themes.

Written by GamePad64 the 29 May 10 at 18:02.

Make a program that converts GTK theme to msstyles automatically and applies it.

Make a program that converts GTK theme to msstyles automatically and applies it.

Written by Martin1980 the 20 Feb 09 at 15:33.

I read the news that Intel leaved Ubuntu for Fedora in their development of Moblin 2. The biggest reason to do that was the packagemanager RPM that Intel thought was better.

Maybe even Ubuntu has a reason to change from *.deb to *.rpm?

I read the news that Intel leaved Ubuntu for Fedora in their development of Moblin 2. The biggest reason to do that was the packagemanager RPM that Intel thought was better. Maybe even Ubuntu has a reason to change from *.deb to *.rpm?

Written by twocool the 21 Feb 09 at 13:12.

Create better tools to install .rpm's in ubuntu. For example a GUI tool that automatically converts rpm's to deb and installs the deb file.

Create better tools to install .rpm's in ubuntu. For example a GUI tool that automatically converts rpm's to deb and installs the deb file.

Written by Robutux the 21 Feb 09 at 13:46.

Improve .deb package system so the next time around, Intel will have the reason to choose .deb over RPM because it'll be better ;)

Find out the weaknesses of .deb and address them. What is it that makes RPM better packaging system?

Improve .deb package system so the next time around, Intel will have the reason to choose .deb over RPM because it'll be better ;) Find out the weaknesses of .deb and address them. What is it that makes RPM better packaging system?

Written by fcsonline the 22 Feb 09 at 17:04.

It would be interesting to work with Red Hat, other distributions and FreeDesktop to find a standard way to install packages and in the future join funcionality of RPM, deb, emerge ...

It would be interesting to work with Red Hat, other distributions and FreeDesktop to find a standard way to install packages and in the future join funcionality of RPM, deb, emerge ...

Written by Primož Papič the 22 Feb 09 at 18:17.

I tried to install Arora Qt web browser in .rpm I used Alien to convert it to .deb, but when I tried to install it nothing happened.
So I propose that Alien is somehow incorporatet in GDebi (the installer of .deb packages) so that it converts and installs any (not only .rpm) packages on the fly.
So that even if you have only a source-code in tar.gz2 it would still be installed with GDebi with one simple click.
there's no need to change package managers and packages just because .rpm is supposedly more popular one.

Yes this solution is just a more specific version of #2.

I tried to install Arora Qt web browser in .rpm I used Alien to convert it to .deb, but when I tried to install it nothing happened. So I propose that Alien is somehow incorporatet in GDebi (the installer of .deb packages) so that it converts and installs any (not only .rpm) packages on the fly. So that even if you have only a source-code in tar.gz2 it would still be installed with GDebi with one simple click. there's no need to change package managers and packages just because .rpm is supposedly more popular one. Yes this solution is just a more specific version of #2.

Written by viraptor the 24 Feb 09 at 15:16.

Allow installing of pure-data packages (probably also architecture independent), into places specified by the user.

For example:
If someone wanted to create a quake package, allow developer to make the quake-data directory-independent and create a symlink from /usr/share/quake (or other directory) to the target one.
dpkg should keep track of both the symlink and real site in the database.

Allow installing of pure-data packages (probably also architecture independent), into places specified by the user. For example: If someone wanted to create a quake package, allow developer to make the quake-data directory-independent and create a symlink from /usr/share/quake (or other directory) to the target one. dpkg should keep track of both the symlink and real site in the database.

Written by askander the 4 Mar 09 at 15:27.

Ubuntu should have an application (could be "on demand" or a "stand by" one) that can detect when a rpm package is being used and create a virtual platform so the package can be installed like is in a red hat based distribution, and when finished, do the proper arrangments to fit the debian (ubuntu) based structure, without user intervention. Somehow like WINE with *.exe files, when you double-click an exe file on nautilus, wine starts automatically and start the proper emulation.

Ubuntu should have an application (could be "on demand" or a "stand by" one) that can detect when a rpm package is being used and create a virtual platform so the package can be installed like is in a red hat based distribution, and when finished, do the proper arrangments to fit the debian (ubuntu) based structure, without user intervention. Somehow like WINE with *.exe files, when you double-click an exe file on nautilus, wine starts automatically and start the proper emulation.

Written by Craig73 the 20 Mar 09 at 19:31.

Focus on the tools first. Developers should be able to easily create one package, and the build service then auto builds an RPM or DEB targeted at the more popular distributions. [Something along the lines of OpenSUSE's build service]

[Such a platform could also theoretically offer a secure build service for non-FOSS vendors to leverage. With a little automation perhaps allow users to request unofficial auto-built packages for non-supported distributions and partially exposed build scripts to allow tweaks]

Then, with packages built for all, it should allow easier enhancement or merging of packaging standards... which with packagekit the end user would be none the wiser.

[I recognize there are inconsistencies in packaging naming, a centralized lookup table to map package names to a common name would be necessary.]

Focus on the tools first. Developers should be able to easily create one package, and the build service then auto builds an RPM or DEB targeted at the more popular distributions. [Something along the lines of OpenSUSE's build service] [Such a platform could also theoretically offer a secure build service for non-FOSS vendors to leverage. With a little automation perhaps allow users to request unofficial auto-built packages for non-supported distributions and partially exposed build scripts to allow tweaks] Then, with packages built for all, it should allow easier enhancement or merging of packaging standards... which with packagekit the end user would be none the wiser. [I recognize there are inconsistencies in packaging naming, a centralized lookup table to map package names to a common name would be necessary.]

Written by yman the 4 Apr 10 at 12:26.

Get as many distributions and companies together as possible to create a standard package naming scheme. Create a directory of package names for existing packages. There will also be more things that would need to be standardizes, like where the files go on the system.

Each project will be offered to have vanilla packages of it's software hosted in it's own repository on the package directory's server. This will provide users with a one-stop-shop for all their software needs, regardless of distribution, and free distributions to deal only with customized packages. Non-customized packages can simply be pulled from the directory, or their repository can be included by the distribution or or something.

The directory will have to support paid applications, screenshots, and user reviews. It will also be good if it provided some easy way to automatically build packages in multiple formats for multiple hardware architectures.

Get as many distributions and companies together as possible to create a standard package naming scheme. Create a directory of package names for existing packages. There will also be more things that would need to be standardizes, like where the files go on the system. Each project will be offered to have vanilla packages of it's software hosted in it's own repository on the package directory's server. This will provide users with a one-stop-shop for all their software needs, regardless of distribution, and free distributions to deal only with customized packages. Non-customized packages can simply be pulled from the directory, or their repository can be included by the distribution or or something. The directory will have to support paid applications, screenshots, and user reviews. It will also be good if it provided some easy way to automatically build packages in multiple formats for multiple hardware architectures.

Written by Endolith the 29 Apr 08 at 14:22.

Files with a "hidden" attribute in their native filesystem (or a special filename) should be hidden in Nautilus, too.

They should be treated exactly the same way as UNIX dotfiles by the file manager, since they serve the same purpose.

Ubuntu should respect the "hiddenness" of the file, no matter what the filesystem.

Files with a "hidden" attribute in their native filesystem (or a special filename) should be hidden in Nautilus, too. They should be treated exactly the same way as UNIX dotfiles by the file manager, since they serve the same purpose. Ubuntu should respect the "hiddenness" of the file, no matter what the filesystem.

Written by pubsbin the 22 May 09 at 03:29.

First, I will make some considerations:

1 - Kids & Grannyies Rule: A user interface must be designed intending it to be used by simple people without any knowledge of Computers.
2 - The average user that mounts a windows filesystem (which may be just an USB disk or a photo camera) wants to see his music/photos/videos/documents and nothing else.
3- Windows programs don't mark a file as "hidden" without reason. It's because that file contain no information useful oto the user, only to the program.
4 - Therefore, the GUI must, by default, hide anything that stands in the way of the user to their data, including the Windows-hidden files.

5 - For the Pro user who wants to SEE everything in the disk, Nautilus must allow him to configure it in order to show the hidden files.


The solution I propose would include:

1 - Create a nautilous configuration option for "see hidden files in native filesystems" or so on.
2 - By Out of Box Default, this option should be unmarked (windows hidden files are hidden).
3 - When the user mounts an NTFS or FAT32, Nautilus shows

First, I will make some considerations: 1 - Kids & Grannyies Rule: A user interface must be designed intending it to be used by simple people without any knowledge of Computers. 2 - The average user that mounts a windows filesystem (which may be just an USB disk or a photo camera) wants to see his music/photos/videos/documents and nothing else. 3- Windows programs don't mark a file as "hidden" without reason. It's because that file contain no information useful oto the user, only to the program. 4 - Therefore, the GUI must, by default, hide anything that stands in the way of the user to their data, including the Windows-hidden files. 5 - For the Pro user who wants to SEE everything in the disk, Nautilus must allow him to configure it in order to show the hidden files. The solution I propose would include: 1 - Create a nautilous configuration option for "see hidden files in native filesystems" or so on. 2 - By Out of Box Default, this option should be unmarked (windows hidden files are hidden). 3 - When the user mounts an NTFS or FAT32, Nautilus shows a small message saying "there are windows-hidden files in this folder. If you want to see them, then activate the "XXX checkbox in the menu YYY".

Written by Penguin Guy the 3 Sep 09 at 13:28.

GUI:
In nautilus there should be a right-click option and a properties option to hide files.

Backend:
Make the dot a symbolic character meaning 'hidden' when put at the start of files - this would allow support for hidden files on FAT, without the need to modify programs. This should work on all supported filesystems. It should be possible to use the escape sequence \. to print an actual dot.

GUI: In nautilus there should be a right-click option and a properties option to hide files. Backend: Make the dot a symbolic character meaning 'hidden' when put at the start of files - this would allow support for hidden files on FAT, without the need to modify programs. This should work on all supported filesystems. It should be possible to use the escape sequence \. to print an actual dot.

Written by Penguin Guy the 15 Oct 09 at 17:26.

On Windows filesystems Nautilus should have either a right-click option or a properties option to hide/unhide files.

On Windows filesystems Nautilus should have either a right-click option or a properties option to hide/unhide files.

Written by Endolith the 19 Nov 08 at 02:40.

A better way to shorten filenames is to cut out the middle and leave the ends:


This is a file.txt
This is a long f...is number 001.jpg
This is a long f...is number 002.jpg
This is a long f...is number 003.jpg
This is a long f...that it ends in.htm
This is a short filename.jpg


This should be the standard way to do it in Nautilus as well as other apps. It applies to any list of strings that go past the edge of the viewing area, really.

Of course, the *best* way to do it would be to keep track of subsequent file names and display just the parts that are different, no matter where they appear, but this would be significantly more complex and usually isn't necessary.

A better way to shorten filenames is to cut out the middle and leave the ends: This is a file.txt This is a long f...is number 001.jpg This is a long f...is number 002.jpg This is a long f...is number 003.jpg This is a long f...that it ends in.htm This is a short filename.jpg This should be the standard way to do it in Nautilus as well as other apps. It applies to any list of strings that go past the edge of the viewing area, really. Of course, the *best* way to do it would be to keep track of subsequent file names and display just the parts that are different, no matter where they appear, but this would be significantly more complex and usually isn't necessary.

Written by openmoho the 23 Jan 09 at 17:54.

provide an oprion in nautilus' preferences to let the filename scroll horizontally back and forth, when moving mouse over...

provide an oprion in nautilus' preferences to let the filename scroll horizontally back and forth, when moving mouse over...

Written by lujana the 10 Feb 09 at 06:36.

Implement a a popup hint that shows full filename after a short delay.

Implement a a popup hint that shows full filename after a short delay.

Written by seeminglee the 23 Mar 09 at 11:30.

Same as solution #1 but with add a mouse-hover state which shows the full name as a label. Would be awesome (maybe configurable as option?) to hover and show fullname for files in the entire column (for the list and compact views)

Fullname labels expansion ideally displays as layer in place but on top of the UI (as opposed to liquid expansion of the of column which can be jarring)

Same as solution #1 but with add a mouse-hover state which shows the full name as a label. Would be awesome (maybe configurable as option?) to hover and show fullname for files in the entire column (for the list and compact views) Fullname labels expansion ideally displays as layer in place but on top of the UI (as opposed to liquid expansion of the of column which can be jarring)

Written by Cé the 1 Mar 09 at 09:08.

I think firefox should be run as a very limited user, so it can only destroys its own files.

I think that limited user should only be able to write to
/user/cedric/Desktop/
/user/cedric/normal locations for caching and so on

This way the normal user can read and use the files from firefox, but firefox can't destroy the files of the normal user.

Best regards,
Cedric

I think firefox should be run as a very limited user, so it can only destroys its own files. I think that limited user should only be able to write to /user/cedric/Desktop/ /user/cedric/normal locations for caching and so on This way the normal user can read and use the files from firefox, but firefox can't destroy the files of the normal user. Best regards, Cedric

Written by aysiu the 3 Mar 09 at 00:02.

AppArmor allows you to restrict what directories an application can access and it's installed in Ubuntu by default, but, as you can see from the community documentation, it's not so easy to configure:
https://help.ubuntu.com/community/AppArmor

There should be a nice little AppArmor config by which you can select with your mouse an application from a list of applications (Firefox being one of the available apps), select again with your mouse a directory you want to limit it to.

This wouldn't be restricted by default, but it should be just a couple of clicks away for those who need it.

AppArmor allows you to restrict what directories an application can access and it's installed in Ubuntu by default, but, as you can see from the community documentation, it's not so easy to configure: https://help.ubuntu.com/community/AppArmor There should be a nice little AppArmor config by which you can select with your mouse an application from a list of applications (Firefox being one of the available apps), select again with your mouse a directory you want to limit it to. This wouldn't be restricted by default, but it should be just a couple of clicks away for those who need it.

Written by aysiu the 3 Mar 09 at 00:07.

It's great to prevent applications from damaging your personal files, but that stuff should be backed up on some external media anyway.

It's great to prevent applications from damaging your personal files, but that stuff should be backed up on some external media anyway.

Written by Thelasko the 24 Mar 09 at 14:54.

From the Novel website:
"Novell AppArmor is an access control system that lets you specify per program which files the program may read, write, and execute."
With the default installation AppArmor only protects CUPS. There is a movement to make it protect Firefox by default. More information can be found here.

From the Novel website:<br> "Novell AppArmor is an access control system that lets you specify per program which files the program may read, write, and execute."<br> With the default installation AppArmor only protects CUPS. There is a movement to make it protect Firefox by default. More information can be found <a href="http://ubuntuforums.org/showthread.php?t=1008906">here.</a>

Written by Thelasko the 6 Apr 09 at 19:59.

When AppArmor loggs a violation, users should be notified via the new Ubuntu notification system. They can then have the option to allow or deny such connections. This is similar to the way the popular Windows firewall ZoneAlarm works.

When AppArmor loggs a violation, users should be notified via the new <a href="http://www.markshuttleworth.com/archives/253">Ubuntu notification system.</a> They can then have the option to allow or deny such connections. This is similar to the way the popular Windows firewall ZoneAlarm works.

Written by jackmcslay the 7 Mar 09 at 17:29.

I haven't searched deep, but it doesn't seem gnome's "File Chooser" widget currently supports file filtering by mimetypes natively. If it actually doesn't, the function should be added, and the old "by extension" method be marked as deprecated and scheduled for removal.

I haven't searched deep, but it doesn't seem gnome's "File Chooser" widget currently supports file filtering by mimetypes natively. If it actually doesn't, the function should be added, and the old "by extension" method be marked as deprecated and scheduled for removal.

Written by koenfloris the 8 Feb 09 at 11:15.

we can let Ubuntu check the text for certain patterns( phone numbers, dates etc... )

and when the mouse hovers over the text, it should highlight a bit to make the user aware that he/she can click on it.

when clicked, Ubuntu should launch the corresponding progrem ( for example: skype for phone numbers ).

programs should be able to make use of this "ubuntu-text-detect". so that developers can decide when they are going to use this. skype already does this with an browser-extension. and i think all programs should be able to do this with all text without an additional program.

EDIT1:

if you vote -1, please tell why.

i believe apple has also this feature, but i don't know the details

we can let Ubuntu check the text for certain patterns( phone numbers, dates etc... ) and when the mouse hovers over the text, it should highlight a bit to make the user aware that he/she can click on it. when clicked, Ubuntu should launch the corresponding progrem ( for example: skype for phone numbers ). programs should be able to make use of this "ubuntu-text-detect". so that developers can decide when they are going to use this. skype already does this with an browser-extension. and i think all programs should be able to do this with all text without an additional program. EDIT1: if you vote -1, please tell why. i believe apple has also this feature, but i don't know the details

Written by twocool the 8 Feb 09 at 14:45.

We should have this feature implemented like googlizer instead of changing the way individual applications work.

We should have this feature implemented like googlizer instead of changing the way individual applications work.

Written by koenfloris the 8 Feb 09 at 16:49.

we should have let ubuntu seek in whatever kind of text ( e-mail, documents, webrowsing... ) for relevant strings. but at low-priority so that it won't slow down anything.

no high-lighting, to keep the content pure. and the extra functionality will be in the context-menu for the right click.

implanting this way will prevent unpure content(duo the highlighting), while keeping the extra feature.

it is very important to implant it on OS-level, so the functionality will get applied on all text. not just the web-browser( like skype ).

we should have let ubuntu seek in whatever kind of text ( e-mail, documents, webrowsing... ) for relevant strings. but at low-priority so that it won't slow down anything. no high-lighting, to keep the content pure. and the extra functionality will be in the context-menu for the right click. implanting this way will prevent unpure content(duo the highlighting), while keeping the extra feature. it is very important to implant it on OS-level, so the functionality will get applied on all text. not just the web-browser( like skype ).

Written by superfoor the 23 Oct 08 at 16:14.

Ubuntu Brainstorm was updated in January 2009. Since the idea #14741 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 #14741 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!