Re: Various issues for emelfm2 0.1.7

On Thu, 27 Apr 2006 23:31:33 +0200
Marcus von Appen <mva@xxxxxxxxxxxx> wrote:

> although the 0.1.7 release seems to have many nice changes, it contains
> some newly introduced bugs and some which seem to exist for quite some
> time.
> 
> In order not to spam the list with various bug reports I file them all
> here (well, the most obvious bugs, I encoutered so far):
Feel free to mail the bug reports directly to me, if you don't want to 
overcrowd this mail-list.

> * ToolBar->Disk Usage button broken:
>   Clicking the disk usage button causes the gtk rendering backend to
>   crash with a SIGABRT:
>     [DEBUG ] _e2_action_run_from (rt:file.du,from:)
>     (emelfm2:11891): Gtk-CRITICAL **: gtk_text_layout_real_invalidate:
>     assertion `layout->wrap_loop_count == 0' failed
>     [DEBUG ] inserted additional newline because the message requested it
>     Assertion failed: (unscaled->lock > 0), function
>     _cairo_ft_unscaled_font_unlock_face, file cairo-ft-font.c, line 572.
>     Assertion failed: (unscaled->lock > 0), function
>     _cairo_ft_unscaled_font_unlock_face, file cairo-ft-font.c, line 572.
> 
>   This may be a cairo related issue as it is not completely stable for
>   now, but as earlier releases work fine so far, I do not think it is
>   caused by cairo.
It's because printing to the output pane was not thread-safe. Now fixed.

> * Localization issue german:
>   Ronny, the disk usage button has the wrong action: It states
>   "Datei.du" although this should be "Datei.Speicherplatz". The de.po
>   file looks okay, so maybe this is a emelfm2 related issue. Could you
>   verify that on your de_* environment?
Default commandbar data now updated, as per Ronny's suggestion (see separate 
message on this).
 
> * Localization issues in multilanguage environments:
>   Given the case a user wants to use emelfm2 in various languages, he
>   will have many troubles with emelfm2's toolbars:
>        http://sysfault.org/emelfm017_i18n.png
>   
>   How to repeat this error:
>   * Start emelfm2 in you default locale.
>   * Quit it and set your locale to a different one (I simply exported
>     LANG as C, but it also works fine with setting de_DE.UTF-8 to
>     ja_JP.UTF-8 and other combinations).
>   * Start emelfm2 again and look at its reordered layout :-).
The question is: what is the best way to deal with this ? I don't much like 
reverting to english-only config data. To manage different locales ... some 
things in a config file are easy to "un-translate", others are hard, some are 
effectively impossible. So on-the-fly re-translation is not an option either. 
Perhaps it's best to simply flag a config file for a locale (name it 
config.$LANG or .$LC_MESSAGES or ?) and always try to use the one for the 
currently-active [variable], and if none found, revert to default settings.

What do people think ?

> * child PID table does not update correctly upon the various kill*
>   commands (exists in earlier versions, too):
> 
>   Although using kill (and especially killall) causes the "List child
>   processes" button to show the correct results, an internal PID table
>   does not seem to be updated correctly and states on closing emelfm2,
>   that there are still some open processes left.
>   How to repeat:
>   Simply use some script, that runs an endless loop and explicitly kill
>   it using the rocketlauncher killall or something like that or, if
>   you've got ImageMagick installed, execute the 'display' command from
>   the commandbar. You also will notice, that it will behave slightly
>   different than running it from a normal console.
Same list, wrong test. Now fixed.
 
> * stdin/stderr/stdout pipes do not work (exists in earlier versions,
>   too):
> 
>   Given the case I have an program, that needs either interaction or
>   writes code to stdout/stderr, it will not do that correctly in any
>   case. This seems to be a non-trivial error. The input issue can be
>   recognized, if you have to an executed command want to have user input
>   (e.g. unzip with the request to overwrite something).
Standard terminal-emulators typically allow a running application that wants 
some input from the user to effectively block, until that input is provided (or 
the user cancels). The assumption is that the app. in question is the only show 
in town.

In e2, that does not happen. Entered text is by default a new command, and any 
number of them can be run. That has some downsides too. One is that the user 
must specifically direct a string to a running application that wants input. 
It's clumsy, but entering NNNN:response will send "response" (not the quotes) 
to the child process with id NNNN, or 0:reponse (or in 0.1.7, 
response<Shift>Enter) will send "response" to the 
most-recently-started-and-still-running child. Ever wondered why the pid is 
printed after each command string ?

BTW, there is disabled code for a function e2_fs_write_stdout(), which has 
never been tested or used. I've never been interested enough to delve into the 
basics of inter-process communications.

Commands with any sort of redirection (| < > >>) need to be run in a separate 
shell, which is achieved by prepending ">" to the command string. You usually 
don't have to remember to do that, as an alias handles it for you. Or it's 
supposed to (I see that the regular-expression is a bit wrong, in recent 
releases). Maybe it would more robust to move it from the alias handler 
directly into the command interpreter.

>   The output issue is another case, which I only encountered in cases,
>   where a shared object loaded by the program wants to write something
>   to stdout.
Can you recall what the problem was, and where ? Probably due to the bad regex 
just mentioned.

Regards
Tom


-- 
Users can unsubscribe from the list by sending email to 
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by 
logging into the web interface.

Other related posts: