Re: Various issues for emelfm2 0.1.7

On Sun, 2006-04-30 at 14:16 -0400, tpgww@xxxxxxxxxxx wrote:
> > * 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.
he talked about a bug showing multiple or nonsense toolbars.. i don't
really see the relation here.. and what do you mean by english only
config?


> What do people think ?
> 
> > * 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.
> 
> 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 ?
I have never noticed that, but this adds a much needed feature for me.
maybe you can add a small drop-down box next to the command line, when
dropped down, it shows the actual running pid's with the command
entered, and when clicked on it, it will enter <pid>: into the command
box. so new users who try out can easily explore this feature and it is
handy for not searching the pid in the command window.
you could also use this to jump to the process and continue to follow
it's output, it you manually scrolled away from it. this would be really
cool und should not be that hard to implement?

greetings





-- 
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: