On Fri, 28 Nov 2008 09:46:03 +1100 Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote:
> On Thu, 27 Nov 2008 20:54:36 +0100 Chidambar 'ilLogict' Zinnoury > <[EMAIL PROTECTED]> babbled: > > > Hello! > > > > I'm currently working on EFM, by trying to make operations atomic > > (for mount...). > > Work on EFM is always a big part of E's todo. But as I don't really > > use file managers, I don't really know: > > - what doesn't work like expected, > > - what features are missing, > > - what kind of killer-features only available to EFM you would want > > to see, > > - and so on... > > > > So, if you have anything to share, please send your thoughts. :) > > 0. there is a todo list: http://trac.enlightenment.org/e/wiki/Release > 1. check all operations - moves, copies, deletes etc. and make sure > they work and work reliably in all situations. error conditions are > handled and where appropriate operations are aborted, or skipped and > the user is informed or given a choice. This is mostly done, it's just done with dialogs at this point. The idea would be to essentially overlay the dialog in the EFM window itself. This helps keep it clean and also helps one associate the request with whatever window it's coming from. > 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). Same as above, probably use some generic code to make it easier to make the overlays. In the case that the window is closed, opening the same dir again will recreate the overlay. One could write a module that could keep track of all operations and perform operations on them as the operations will be globally available. I had started some work on this, but never finished it. I'm not sure how much use any of my work was since a few things have changed since I started it. > 3. need to check and ensure all DND > works between all efm windows (into the window, in top of directories > etc.), and between other apps (other fm's like nautilius or thunar or > konqueror, apps like gimp, inkscape, openoffice, abiword, firefox > etc. etc.) Working with other file managers may be harder then it looks on the surface since they may not all use an identical spec for transferring file information. I seem to recall that they all had their own quirks, but I believe we are already compatible with most GTK file managers. > 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.). Yes, this does mostly work. The biggest problem now is that the cleanup of the .desktop files is not very good. If you plug in a thumbdrive, kill E, pull out the drive, and then restart E it will not have deleted the .desktop and will cause the issue that many users have seen where their efm windows refresh rapidly. > 5. there are obvious bugs like > the favorites window not remembering position (don't know why > currently - just saw that it doesnt). > 6. missing small things like > remembering scroll position as well as pos/size for windows. > 7. part of another todo but related to fm is making all fm window > (opened by fwin in the fileman module) should be re-opened on > login/start if they were open on shutdown (exit). (this means > restarting e doesnt lose internal e windows like fm windows) > 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. > 9. efm actually supports a custom bg (and/or > overlay) .edj .. per directory. so different dirs can have a > different look and feel - even the theme can be changed so selected > file icons and scrollbar can all be customised. there is no gui to do > this - just magic dot-files right now. Well not sure how much of a GUI you want for this, but I would just document it and those who want to use it can. I figure this will be more used by distributions who want to customize certain folders. If there is a GUI, then just the basics like background image and icons might be the most you want to do. > 10. there is a right-menu > option for efm when it sees image files (jpg's etc./) to "set as > wallpaper". this basically doesn't work. sure a dialog comes up - but > it's not usefully pre-seeded with the file you selected. admittedly > the whoel wallpaper config dialogs need a re-do. I believe this used to work so probably just needs a simple fix somewhere. > 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. > Well the applications that belong to the mimetype is a pretty small list usually and therefore I don't see how your change would really help. One of the lists would still be very large. One thing that could help with this would be the collapsible headers and do on-demand loading only when a section is opened. ------------------------------------------------------------------------- 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
