Hello, On this thread, I have tried to read all of them, but have not heard any mention of the multiple windows that get opened when using the built in file mgr. Is it configurable? I have looked, but have found no way to have a double click on a directory open in that windows, vs opening a new window. I saw someone mention that they hate treeviews (maybe Gustavo?), but personally, I'd rather have that than twenty windows open as I navigate through the directories. Is this something that could be added as a configurable option? Please let me know if I just haven't done the leg work to figure out how the current implementation could be configured to use one window vs many.
Thanks, Jess On Fri, 2008-11-28 at 19:13 -0200, Gustavo Sverzut Barbieri wrote: > On Fri, Nov 28, 2008 at 7:05 PM, Gustavo Sverzut Barbieri > <[EMAIL PROTECTED]> wrote: > > On Fri, Nov 28, 2008 at 4:49 PM, Dave Andreoli <[EMAIL PROTECTED]> wrote: > >> > >> ----- "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> ha scritto: > >> > >>> On Thu, Nov 27, 2008 at 8:46 PM, The Rasterman Carsten Haitzler > >>> <[EMAIL PROTECTED]> wrote: > >>> > On Thu, 27 Nov 2008 20:54:36 +0100 Chidambar 'ilLogict' Zinnoury > >>> > 2. all operations (copy, move, delete) have no progress on screen - > >>> if there is > >>> > a queue of work (like delete this dir then copy this to here, move > >>> this to here > >>> > etc.) you can't see it. the idea was to put such status inside the > >>> efm window > >>> > in-line with where the action was initiated or where it belongs (eg > >>> if u delete > >>> > a file in a dir then put the status in that dir). > >>> > >>> what to do when window is closed? and when that folder is viewed > >>> again? I'd like to have the progress even if I close the window... > >>> either do not close it or when you close "detach" the progress > >>> status. > >>> > >>> > >>> > 4. removable device handling (done via hal and dbus at least for the > >>> raw nuts > >>> > and bolts) mostly seems to work but is a bit hackey the way it > >>> writes .desktop > >>> > files to ~/.e/e/fileman/favorites then forcibly symlinks them to > >>> your Desktop - > >>> > this could be cleaned up and made more robust with more options (eg > >>> also put > >>> > them on other desktops eg Desktop-1 and -2 etc.). > >>> > >>> I hate these links. IMHO they should be transparent. > >>> > >>> Actually, the idea would be to follow kde's path to have directory > >>> views of EFM and selectively choose to "show devices". That way we > >>> can > >>> just have a EFM view with "show devices" to show our "~/Desktop" as a > >>> gadman. We can even have multiple views in the same desktops (ie: ~/ > >>> and ~/Desktop) or different views per desktops (~/Desktop-1, > >>> ~/Desktop-2...) > >>> > >>> With that I could choose to view ~/.empty-folder and "show devices" > >>> to > >>> list just the external devices. > >>> > >>> > >>> > 8. renaming files has a dialog - this is because it was hard to do > >>> before. now > >>> > we can rename in-place. edje's own entry can now do this. this needs > >>> changing. > >>> > >>> Even with edje support is remains difficult. You must ensure that the > >>> edited text is visible (ie: you're editing next to a border, you > >>> should pan/scroll to make sure it is visible). > >>> > >>> > 11. while i'm at it the open with.. dialog is not bad - but the > >>> 2-list thing > >>> > needs to go. 1 list. also ilist is again abused with a massive list > >>> of stuff > >>> > (poor ilist. i need to make it possible for ilist to defer list > >>> adding and size > >>> > calculation with an add queue). so likely that dialog could do with > >>> a toolbar > >>> > at the top to select between applications that say they do handle > >>> that > >>> > mime-type, and "all applications" as 2 separate lists and you switch > >>> between. > >>> > >>> about ilist, using Smart's "changed" could help a lot and remove need > >>> for freeze/thaw. Other than that we could port guarana's MVC list for > >>> such thing, it's very fast when you have rows with the same renderer > >>> (same edje group could be applied). > >>> > >>> My personal items would be: > >>> > >>> 12. keyboard shortcuts: ^c, ^v, ^x... > >>> > >>> 13. enable easy open of efm at some folder, specially from cmdline... > >>> efm ~/my-folder would be handy. > >> > >> +1 ... and we also need a .desktop file for efm. A fast way to implement > >> this is probably to setup a new e_remote option like > >> enlightenemnt_remote --showfm > >> than you can have an alias like efm and you can have your desktop file. > > > > Ok, I was trying to implement it when I got stuck with e_ipc stuff > > being all hardcoded... no dynamic extensions to > > enlightenment_remote... BUT I remembered that fileman registers its > > action and you can execute actions with remote: > > > > enlightenment_remote -exec-action "fileman" "$PATH" > > Just be careful no not have PATH set to a relative directory (E does > not know where you were when you called the action), I'm using the > following script: > > > #!/bin/sh > > dir=`dirname "$1"` > file=`basename "$1"` > > if [ "$dir" = "." ]; then > dir="$PWD" > elif [ "$dir" = ".." ]; then > dir="$PWD/.." > fi > > enlightenment_remote -exec-action "fileman" "$dir/$file" > > > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
