This page is for users to add comments. You can use the @'DATE@ and @'MAILTO@ macros, but keep in mind that they don't get expanded in the preview.
PLEASE DO NOT USE THIS PAGE FOR BUG REPORTS. EMAIL THEM! We often need to follow up with the sender.
emelfm2 dies on my machine when i do "config", change any option and press OK. Remove of ~/.emelfm2 doesnt help. No error message appears even if started from rxvt.
Slackware 10.1, xorg 6.8.2.
I found a bug in the command line support. The command: tar czvf somedir-date +%Y%m%d.tar.gz somedir fails to work. It's entirely valid, and worked in emelfm.
As you haven't told me any error message, I assume you just don't know that e2 has a different command handling. First, it doesn't start a new shell for a command but it runs it directly. Second, the % stuff could go wrong because of the macro expansion. So your solution is to start the command in a new shell and surpress macro expansion. You can do that by using %! at the beginning of the command, e.g.:
I found a strange bug, I just have to report it. Somehow emelfm2 became a unkillable process on my machine (Ubuntu)! And I think it also reacted strangely to directories, which weren't there anymore. Since it remembers the last directories you used, and when you start it again and one of the directories doesn't exist, I thought it handled it stragely. Please look into it. SWAT
Also take a look at the e2help command which explains this in more detail! Furthermore, there are aliases to make your life easier. The backticks could be added to "the special shell alias".
Hm... there are backticks in that command. Is there a way to make it accept literal text rather than using those as formatting marks?
Sorry, but I don't get what you mean here. As i've said to the other people writing bug reports on the comments page: PLEASE DO NOT USE THIS PAGE FOR BUG REPORTS. EMAIL THEM'''
It would be great to have a mailing list and CVS access -- to keep track on the development of EmelFM2
Awesome work tooar! :-) I lost track of this project for a while, sorry. You have added lots of nice
improvements over emelfm - I am changing over to it now at version .6. The only things I need to do are to make
one-liners to undo tarballs etc. (or I'm just mis-configured maybe) and recreate my command bar under the new prefs.
I'm going to poke around the site and see what other plans you have in mind.
I would like to be able to re-order the columns that I choose to show; haven't seen how to do that yet. Also, the col width
isn't saved on mine -- maybe those are details for later. Thanks for your work!
pevans At catholic.org, Fri Feb 27 15:31:10 2004
well, such features will probably be added after/around version 0.1.0 when the file panes are replaced. though, it might take a while until then.
I've just had a 1st quick play with 0.5. A suggestion: really nail the right-click menu.
"File" actions is misnamed (also applies to folders, in general). "copy as" is missing (maybe it can be added by reconfiguration, haven't chnecked yet).
Best to tailor the menu and/or sub-menu content (or at least, the enabled content) to suit whatever is selected, which may be: 1 file, >1 file, 1 folder, >1 folder, file(s) + folder(s).
yes, sorry, your're right. this will be fixed when the file types are replaced :)
Hello, I was wondering if there will be an mount-functionality like in the 'old' emelfm. (or is it allready, but did I srew up my /etc/fstab too much?)
well, this should already be possible. currently, i recommend to add a mount file action to directories. in the latest pre-release you could also use a toolbar button with a <custom command> and use something like ";mount %f;cd %f" as argument.
Been having a problem with the rename box not expanding to size of the text.basically all I'm able to see is the window border from the window manager.I can type something in and it will rename the file though.Same exact results with the "makedir" button.when creating a new dir the closed box pops up and I can type in a name for that dir,hit enter and it works.One more thing,I really miss the old back button with the right click to go home feature.Think you could add it back as an option or at least something with the above mentioned feature that closely ressembles it?Btw,I'm using version 0.0.7 with gtk2-2.4 along with gcc-3.3.3 on Gentoo-2004.0 if that helps.Think it could be a problem with gcc?
Keep up the great work
This problem seems to derrive from gtk2.4. Please try the latest pre-release from the DownLoads page if that fixes your problems. Furthermore, please report other bugs directly to me via email. Thanks! ;-)
Ops, sorry, i somehow missed the 2nd part of your comment. What do you mean with closely? So far, you at least have two possibilities: 1) add another button to the panebars that changes the dir to home or 2) use the new bookmarks system. I'd recommend number 2. By default, there should be a "home" bookmark at the very top of the main toolbar. (The bookmarks also have an option to open it in the inactive file pane if you press the middle mouse button.)
this program looks awesome! The new version 0.10 has nice new features. Speed is great in your application. I've some request, which I'm going to add in the feature wiki. thanks
Hmm, perhaps it's the wrong way, but I don't like subscribing to a mailing-list for just one question.
I tried to run 0.1.1 (on gentoo), but it segfaults. I don't know if earlier versions work but here is the backtrace:
(gdb) bt #0 0x0807a5aa in e2_window_create () #1 0x00000000 in ?? () #2 0x00000000 in ?? () #3 0xb7b3313c in timezone () from /lib/tls/libc.so.6 #4 0x080a08a9 in e2_utils_update_gtk_settings () #5 0x00000001 in ?? () #6 0x00000000 in ?? () #7 0xbfffee8c in ?? () #8 0xb7b3313c in timezone () from /lib/tls/libc.so.6 #9 0x08069672 in main ()
I was searching for ages for a good file-manager and gentoo (the file-manager) doesn't support GTK2: so please help me :).
bye, Adam. (2005-08-07T20:41:34Z)
Adam, if you see this, please provide some way of contacting you for more detail about the problem. e2_utils_update_gtk_settings() does not make reference to e2_window_create()
I must admit that emelfm2 is just what i was looking for, but there is one thing that is missing. Some status window during coping or moving files. Some times I would like to cancel or stop coping for moment.
Everything else is just great!!
Try the copy and move plugins. They provide progress reports and allow cancellation (but not suspend and resume).
The links on the DownLoads page should point to the new .net location instead of the old .org :-).
Hello, thank you very much for your work, emelFM2 is very very good.
Where can i get the icons on tooar's screenshots? And which gtk2 theme is it? I can't find a decent dark one.
edit: i meant Florian's screenshots, sorry :)
Theme is aero
And I think those icons where included.
Thank you, and nice to see the "fail silently when viewing/editing a file without relevant permission" bug was fixed, and it's faster now.
Fri Nov 24 19:39:08 EST 2006
Sorry about posting this here, but I dunno who 'freelists' is and don't like putting my email address out any more than absolutely necessary. An IRC channel would be great, or a Trac interface with tickets or, at least, a sourceforge page like everybody else. ;)
Anyway: when told to start up in '~' emelfm2 0.3.1 (compiled today on Slackware-current) reports 'Cannot access ~, going to /home/j/ instead'. Just putting in /home/j works, of course. The odd thing is that '~' works as a 'bookmarks' path. Another thing is that emelfm puts in something like '~/.share/Trash/files' or some such as the default path for Trash in the bookmarks. It would be nice if it would getenv() to find $XDG_DATA_HOME and fill in the path from there. On mine, that would give /home/j/.xdg/data/Trash/files. Either way, it would be nice if it would also accept and correctly interpret user-supplied variables like $HOME and $XDG_DATA_HOME and whatnot.
Turns out that "~" was interpreted anytime other than at the start of a session.
The FD.O trash spec wants trashed files to be in $XDG_DATA_HOME/Trash/files. Instead of direct interpretation of $XDG_DATA_HOME (which often doesn't exist), emelFM2 uses g_get_user_data_dir(). From the glib documentation and FD.O dirs spec, it looks like that should give the same result. Perhaps some slackware user might explore and feed back on what's going on, there ?
More generally, an equivalent glib function call is preferred to direct interpretation of environment variables, for determining directories to be used. However variables are interpreted directly when used in commands and actions.
Sorry, the actual path emelfm2 puts by default is '~/.local/share/Trash/files', which is the default XDG_DATA_HOME. I may have miscommunicated what I meant, though. emelfm2 correctly trashes a trashed file to my XDG_DATA_HOME/Trash/files - I just meant that emelfm2's default configuration for the bookmarks defaults to what's more or less hardcoded in line 566 of e2_bookmark.c. So the user gets 'The directory '/home/j/.local/share/Trash/files/' does not exist!' when they click on the bookmark. Of course, you're going to have to reconfigure the bookmarks for the most part anyway, but it's just kind of unexpected. New user creates a testfile, trashes it, clicks on the bookmark, gets an error message and can't see his trashed file. Realizes the bookmarks aren't set up right for his configuration. (Granted, it's only weirdos like me who set their XDG* vars, but still. :) Same with the '~' interpretation. I just had to twiddle with emelfm2 a bit much before I could even get started with serious twiddling.) I kind of wonder about the extent of the defaults anyway. Things like spreadsheets being separate from other office docs and opening with specific components like oocalc that I don't even have. My openoffice calc is scalc and I just set all office filetypes to one category all opened with 'soffice'. On the one hand, a bunch of defaults like that are very useful examples and serve to get users started but, on the other hand, there's a lot of stuff to undo, as well. -- Anyway, the tilde thing seemed kinda buggy, but I realize now I should have put the bookmarks thing on the 'FeatureRequests' page. Sorry about that.
Incidentally, there are typos all over the Makefile (and, I assume, elsewhere) where it's given as 'XGD' instead of 'XDG'.
Anyway - may have some other quibbles, but this is looking nice. I've used emelfm once upon a time. Nice work.
Sat Nov 25 18:31:47 EST 2006
Me again. I just installed xarchiver and it could well be xarchiver's fault, but I suspect it's emelfm's, because it works fine with rox and by itself: when I associate tarballs with xarchiver, xarchiver opens and displays the message 'Please wait while the content of the archive is being read...' while the progress indicator goes back and forth perpetually. As I say, it works find under any other condition. It's like it's waiting on an exit code emelfm is eating or some kind of communication breakdown, anyway.
We've had a report on this before. Investigation of emelFM2 and xarchiver code indicated that both apps are individually doing reasonable things to run an application, using virtually identical gtk functionality. However, when such usage is nested, the 2 completion reports get "tangled". Presumably the same would apply to any other app that runs things the same way. Maybe we can come up with some work-around.
Well, after posting this, it actually did occur with rox once and behaved properly with emelfm2 once so, true, it definitely isn't just emelfm2. After that, it occurred to me to try putting it in a wrapper script, where emelfm2 calls 'wxarchiver' and the wxarchiver script calls xarchiver, and it seems to work. Now that I read this, I guess the shell script is enough separation to avoid tangling. :) I'm not sure what's different with rox, though - it must be doing something different to have an inverted success ratio. Still, it turned out it was easy enough to work around (as far as chewing gum and baling wire workarounds an end user can slap on go).