----- "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> ha scritto:
> 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. > This is exacly what the places module do..plus some more :) Please have a look at it (http://code.google.com/p/e17mods/wiki/Places) In my opinion we can remove some hal code from efm and use more the places module (maybe use it by default). This mainly for reducing efm complexity. Dave > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: [EMAIL PROTECTED] > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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
