Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 43121 - emelfm2-0.0.5.ebuild
Summary: emelfm2-0.0.5.ebuild
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Desktop Misc. Team
Keywords: EBUILD
: 38020 (view as bug list)
Depends on:
Reported: 2004-02-27 11:38 UTC by ares
Modified: 2004-09-02 06:57 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---

emelfm2-0.0.5.ebuild (New) (emelfm2-0.0.5.ebuild,1.02 KB, text/plain)
2004-02-27 11:38 UTC, ares
emelfm2-0.0.8.ebuild (emelfm2-0.0.8.ebuild,1.02 KB, text/plain)
2004-04-30 16:08 UTC, ares
melfm2-0.0.8.ebuild (emelfm2-0.0.8.ebuild,759 bytes, text/plain)
2004-06-15 22:58 UTC, Mr. Bones. (RETIRED)
locale-workaround.patch (locale-workaround.patch,4.42 KB, patch)
2004-06-22 06:26 UTC, Daniel Drake (RETIRED)
Details | Diff
emelfm2-0.0.8.ebuild (emelfm2-0.0.8.ebuild,842 bytes, text/plain)
2004-07-20 17:16 UTC, hollywoodb

Note You need to log in before you can comment on or make changes to this bug.
Description ares 2004-02-27 11:38:00 UTC
A file manager that implements the popular two-pane design based gtk+-2
Comment 1 ares 2004-02-27 11:38:48 UTC
Created attachment 26481 [details]
emelfm2-0.0.5.ebuild (New)
Comment 2 ares 2004-04-30 16:08:57 UTC
Created attachment 30413 [details]

New version emelfm2, support version gtk+2.4
Comment 3 hollywoodb 2004-06-15 13:41:01 UTC
would love to see this worked with & added to portage... getting this error when attempting to execute emelfm2: 

The error above usually means that you've set the environment variable
G_BROKEN_FILENAMES to something. Then GTK+2 is suppossed to work with file names
in your locale. Though, it is impossible to do this without a known locale.
To prevent crashes please either unset G_BROKEN_FILENAMES or adjust your locale.

(note there is no 'error above', just this)
Comment 4 Mr. Bones. (RETIRED) gentoo-dev 2004-06-15 22:58:02 UTC
Created attachment 33362 [details]

Here's my take on this ebuild.
Comment 5 hollywoodb 2004-06-16 07:29:11 UTC
comment #4's ebuild works fine for me... still getting error about G_BROKEN_FILENAMES...

more info on that here:

output of "locale":

from the emelfm2 author:
...this means your locale is set to C but you have exported
G_BROKEN_FILENAMES. gtk has to know from what locale it should convert
character to utf8. thus, as the message states, either set a different
locale or unset G_BROKEN_FILENAMES.

the 'no error above' note in comment #3 will be fixed, not yet known if by updating 0.0.8 sources or next release...

'export LANG=en_US.UTF-8' allows for running emelfm2 in my case, however I'd like to get this fixed on a better level
Comment 6 hollywoodb 2004-06-17 09:32:28 UTC
commenting out lines 172-185 of src/e2_main.c removes the "death" reaction to my setup and allows emelfm2 to run without panicking... however I'm not sure what side-effects this may have, other than causing emelfm2 to fall back on utf8... imo, users using another setting will have it set anyways... on commenting these lines from the author: 

if you do this, e2 is likely to crash sooner or later because there is
no error checking in case the utf8 conversion fails. gtk+2 uses only
utf8 internally. why do you export G_BROKEN_FILENAMES at all if your
file names aren't broken? if your users export G_BROKEN_FILENAMES
without having set up a locale, they will break all gtk+2 programs. if
there was a way to detect the stuff that G_BROKEN_FILENAMES is for, it
would have been done by gtk and G_BROKEN_FILENAMES wouldn't exist. but
there is no way, and thus gtk+2 has to let the user adjust it and if he
adjusts it wrong, it will break. (i mean if you export
G_BROKEN_FILENAMES you should be aware of what you're doing)
the only bad thing about e2 is, that it denies work in general instead
of handling each conversion error. other programs that don't rely on
file operations that heavily might handle it differently. for e2, this
was the easiest way to go right now, since it is a port of the gtk1

even so, I've never had any gtk2 apps 'break' because of this, and emelfm2 seems to be perfectly happy with this... perhaps a locale check that decides whether or not to patch e2_main.c followed by an einfo descript, or a better way?
Comment 7 hollywoodb 2004-06-17 21:55:09 UTC
I realized I can recieve the same result as previous post by simply commenting line 183 (the exit command)... doing this also lets emelfm2 show its mystical G_BROKEN_FILENAMES error and run properly (imo)... This is probably a better solution than commenting out that entire block because it makes the user aware of the problem, not that I feel it will make a big difference... I'm still open to ideas ;)

/me slowly learns to read this strange code
Comment 8 Daniel Drake (RETIRED) gentoo-dev 2004-06-18 01:33:22 UTC
Have you tried creating a file from the command line with non-ASCII characters (e.g. 
Comment 9 Daniel Drake (RETIRED) gentoo-dev 2004-06-18 01:33:22 UTC
Have you tried creating a file from the command line with non-ASCII characters (e.g. äää) in it and then seeing how this package can cope after your little hack?
Comment 10 hollywoodb 2004-06-18 08:54:28 UTC
a file containing "
Comment 11 hollywoodb 2004-06-18 08:54:28 UTC
a file containing "£££££" its fine with, no problem that I see... it determines the filetype exactly the same 'file' does...

attempting to save a file with the above string in the name results in this:
Could not build file name from 'file:///home/hollywoodb' and '£££££':
Invalid byte sequence in conversion input

attempting to rename a file alone on the command line with the same string results in '?????' in place of '£££££" so I'm doubting this is an emelfm2 problem.
Comment 12 Seemant Kulleen (RETIRED) gentoo-dev 2004-06-21 11:37:42 UTC
*** Bug 38020 has been marked as a duplicate of this bug. ***
Comment 13 Daniel Drake (RETIRED) gentoo-dev 2004-06-22 06:01:52 UTC
The words of the author seem to contradict how the code behaves.

If G_BROKEN_FILENAMES is _not_ set, then it is assumed that all filenames are read as UTF-8. However, the code is using logic such that:
 1. Read filenames
 2. Convert from locale to utf8
This is done in all situations, no matter if G_BROKEN_FILENAMES is set or not.

The way I have previously handled this is to just fall back to ISO-8859-1 ---> UTF-8 conversion if we can't detect the locale. This isn't technically correct, but it works for those people who do not have a locale set. It may be better if this was a configurable option.

Maybe we (as an OS) should be advising users to set a locale in the same way that we set a timezone.

Also, simply commenting out the exit call or check does not avoid the problem, as the app is unable to deal with any files with foreign characters in them. I'll see if I can patch up the basic conversion functions as described above.
Comment 14 Daniel Drake (RETIRED) gentoo-dev 2004-06-22 06:26:53 UTC
Created attachment 33824 [details, diff]
Comment 15 hollywoodb 2004-07-20 17:16:42 UTC
Created attachment 35843 [details]

fixed to include dsd's locale-workaround.patch
fixed KEYWORDS from x86 to ~x86

I've been using this quite extensively, and its pretty stable
Comment 16 Brad Laue (RETIRED) gentoo-dev 2004-09-01 23:17:55 UTC
Maybe we should investigate sending that patch upstream for review, this is a bit of a problem for the application itself, IMO.
Comment 17 Brad Laue (RETIRED) gentoo-dev 2004-09-02 06:33:42 UTC
Just tried the 
Comment 18 Brad Laue (RETIRED) gentoo-dev 2004-09-02 06:33:42 UTC
Just tried the £££££ thing myself. Named the file as such on a bash prompt and found that it doesn't display properly in bash, but emelfm2 picked it up. I have no variables set and launched it with the new -i flag. The -i flag is used on the advice of the application's author in cases where LANG is not set, and appears to work well.

I'm going to commit this so more eyes get a look at it, if anyone reading this wants to take maintainership let me know, otherwise I'll take care of it.
Comment 19 ares 2004-09-02 06:37:34 UTC
New version avaible emelfm2-0.0.9
Comment 20 Brad Laue (RETIRED) gentoo-dev 2004-09-02 06:57:30 UTC
That's the version I added. d8)