#1975 closed enhancement (fixed)
ROX Filer
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | normal | Milestone: | x-future |
| Component: | BOOK | Version: | SVN |
| Severity: | normal | Keywords: | |
| Cc: |
Description (last modified by )
The ROX-Filer (part of the ROX Desktop http://rox.sourceforge.net/desktop/static.html ) is a nice, lightweight, fast file manager. It is not a straight CMMI to install. I think it would be nice to have it in BLFS
Change History (9)
comment:1 by , 18 years ago
| Description: | modified (diff) |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
comment:2 by , 18 years ago
comment:3 by , 18 years ago
Is that sufficient reason to not have it in BLFS? It works well in ascII and UTF-8 locales which covers a large proportion of BLFS users. As I understand it UTF-8 is the wave of the future. If so then as time passes these issues with non UTF-8 locales will become less important.
comment:4 by , 18 years ago
This is not a reason to exclude ROX Filer from BLFS (but a warning is needed). This was a reason to exclude it from earlier releases of BLFS, because there was officially no LFS with UTF-8 support.
comment:7 by , 14 years ago
Andy sent in a patch to include Rox Filer in the book. See:
http://linuxfromscratch.org/pipermail/blfs-dev/2010-March/020436.html
comment:8 by , 12 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Added to BLFS SVN. Marking as fixed.
It is also buggy enough to be useful only in UTF-8 locales (i.e.: doesn't respect G_FILENAME_ENCODING). In non-UTF-8 locales, the following happens:
1) You create a directory with non-ASCII name using ROX Filer. 2) You open a terminal and say "ls" to see what you just created 3) The displayed name is garbage, because ROX always uses UTF-8 for file names, and that contraditcs expectations of other programs, and POSIX (see the description of "tar" program there and assume an implicit requirement of interoperability).
This real bug is treated WONTFIX/NOTABUG upstream, because upstream interprets POSIX differently (just doesn't know that it has to look on "tar" page to see the specification for filename encoding).