On 28/11/2008, at 12.15, Gustavo Sverzut Barbieri wrote: > On Fri, Nov 28, 2008 at 3:29 AM, The Rasterman Carsten Haitzler > <[EMAIL PROTECTED]> wrote: >> On Fri, 28 Nov 2008 00:23:08 -0200 "Gustavo Sverzut Barbieri" >> <[EMAIL PROTECTED]> babbled: >> >>> 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. >> >> should have some central "operations manager" window which can list >> all the >> tasks being worked on. doesnt have to be fancy as it hopefully wont >> be needed >> often :) >> >>>> 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. >> >> you mean - not be files on disk? yes - it's ugly - but doing it the >> way i did >> was easiest as it re-used an existing code path :) >> >>> 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...) >> >> yeah - the problem is efm REQUIRES a file to back every icon in the >> view - no >> file. no icon. so you need to create one. you'd have to change this >> code which >> isnt trivial. >> >>> With that I could choose to view ~/.empty-folder and "show >>> devices" to >>> list just the external devices. >> >> yup. as above. not so easy :) >> >>>> 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). >> >> correct. of course this comes with its list of gotchas - like >> everything :) >> >>>> 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). >> >> almsot all ilists use freze/thaw - but this isnt the problem. the >> problem is >> that we literally for a 500 entry ilist create 1000's of objects - >> and >> calculate every edje's min size as each one CAN be different >> (thanks to >> headers and text being different lengths on each line). really the >> best way to >> really do this is: >> >> 1. actually creat each object calculate its size then destroy - >> only keep an >> active set of objects near the visible viewport >> 2. move adding items to a job queue and spool it off over time like >> with efm so >> calculating all the items is done over an extended period thus >> making it appear >> more quickly and be usable, but fill in over a timespan. >> >>> My personal items would be: >>> >>> 12. keyboard shortcuts: ^c, ^v, ^x... >> >> of course - i listed "delete key" as well (should delete). >> >>> 13. enable easy open of efm at some folder, specially from >>> cmdline... >>> efm ~/my-folder would be handy. >> >> yes. this would be nice - though i didnt really think it was a must >> - but i >> think we can add this to the list - the wiki page should have all >> of this >> listed. >> >>> 13. popup with preview options. plugin-able would rock, but at least >>> way to see more information about most used types (images, videos, >>> music, oo.org) would help, things like title, preview, date and >>> like. >> >> yes. i'd go - for now, for simply allowing hooks that modules can >> plug into >> here and do a rudamentary module that plugs in and for example >> simply shows a >> larger version of an image file - if its an image. simething >> simple. of course >> since it is able to do this (provide some popup over /near the file >> icon on >> click or mouse over or in right-mouse menu) and it knows what the >> file is - >> this popup could contain much more info and details when the plugin >> module is >> more extensive. >> >>> I guess I could make it easier if I add individual file >>> extraction >>> for LightMediaScanner. Today it's based on folders and every file is >>> stored on SQLite DB, maybe I can change that to make it more useful >>> for one-file users, including EFM. >> >> the plugin could use such a db for extracting info.. though as it'd >> be one file >> at a time it'd probably just make sense to look at the file itself >> and extract >> in-place - as above. a simple example would be a bigger view of an >> image (and >> maybe with width x height info in the preview). etc. this of course >> then is >> just a matter of more and more plugins doing more and more info. >> >>> And sure, we could use more EFL apps to handle files... things like >>> Eyelight (presentation viewer), Eyesight (document viewer, pdf...), >>> Enjoy (music player)... Most required, at least to me, are a >>> document >>> (pdf, ps, ooo) viewer and photo viewer. Eyesight really need work to >>> be useful, Ephoto and Exhibit are not what I'd like to see my >>> picture >>> directory, I'd like a quick viewer with easy and fancy slideshow, >>> easy >>> to use zoom and possible exif and rotation support, until that I >>> keep >>> using cmdline imagemagick's "display". >> >> yup. of course - though these apps i'd consider separate to e17's >> release as >> such e just will happily launch whatever app you like on a file. be >> it efl or >> otherwise :) > > 14. Another request remembered by an user at #e: auto-mount and a way > to force mount and unmount of devices. It is annoying to keep an efm > window open just to be able to use the device with other apps. Using > the advice name instead of a code/number as mount dir would be good as > well, just see pmount-hal.
15. Better handle the long filenames in iconview. Like if the name consists of 2 or 3 words and it's too long for one line - move one of the words to a second line. Same if it consists of one very long word (maybe more than 10 characters?), but use a dash or just put "..." after the 5th letter. This will help to keep the icons better snapped to the grid. 16. Better list view like in Finder [1] or Nautilus so you can use it without opening a new window to see what's inside the folder you want to open. [1] http://lucho.sagehall.com/files/finder-listview.png > > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems ------------------------------------------------------------------------- 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
