Re: [E-devel] EFM: thoughts, current work et al.
> > no. "windows" reversed the convention. before windows existed in the mac > and > amiga etc. worlds shift was multi-select, control was range select. i am > following the original convention by default. efm can switch to do it the > "windows way". but nothng is exposed in the gui to do that - the code is > there > though. > Ok ! I didn't know that. Anyway that's not an habit that couldn't be lost - particularly if it comes from windows ;) > you could do this with multiple fm views... but this is going too far. efm > is > intended as a basic SIMPLE fm that you get "for free" because the majority > of > the infra for a fm is already lurking inside e - and this just exposes it. > we > need to get e17 released and so i want efm to remain simple - we can worry > about more features after release - unless those features are really core > to > the thing working properly at all. as such the old fm that brought up a new > window per dir worked wonders on macos and amigaos and a dozen others for > many > years. its very simple and flexible. thats all i wanted for e17 - fore e18 > etc. > we can look at doing more. > For sure that's not needed for a release ! - 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
Re: [E-devel] EFM: thoughts, current work et al.
On Mon, 1 Dec 2008 00:25:47 +0100 "Vincent Pomageot" <[EMAIL PROTECTED]> babbled: > Hi, > > As a user I'm very happy to see all this keen interest with efm. I really > like it since I use the thumbscroll feature (sometimes I even try to scroll > the firefox pages like this !) and I think it's good for basic operation / > navigation. > > Nevertheless I'm used to select multiple files in a list view from one to > another by holding Shift and to separtely select files by holding Control... > In efm it's the opposite, is it an error ? no. "windows" reversed the convention. before windows existed in the mac and amiga etc. worlds shift was multi-select, control was range select. i am following the original convention by default. efm can switch to do it the "windows way". but nothng is exposed in the gui to do that - the code is there though. > Like many of you I would like to have shortcuts to copy/paste and I'll add : > Alt+directions to navigate through folders like in others filemanager. > > + a module like efm_nav and path but which will show us the path with > buttons for a speedy navigation > > + an implementation of the "delete in trash" like in the trash module > > + a column view like in the macos finder, but raster said : > > the fm widget views 1 directory at a time - that's how its built. you could do this with multiple fm views... but this is going too far. efm is intended as a basic SIMPLE fm that you get "for free" because the majority of the infra for a fm is already lurking inside e - and this just exposes it. we need to get e17 released and so i want efm to remain simple - we can worry about more features after release - unless those features are really core to the thing working properly at all. as such the old fm that brought up a new window per dir worked wonders on macos and amigaos and a dozen others for many years. its very simple and flexible. thats all i wanted for e17 - fore e18 etc. we can look at doing more. > > changing that is major surgery. > > > So I don't know if it's feasible, but could be really great with some nice > translations when the columns have to slide, and could permits the last > column to show some more informations on the file selected... I'm dreaming > :) > > ... or if it's something not doable, why not adding some fancy effect when > opening a folder (when the "open dirs in place" is checked) ? > > Hope it could make e even better ! > Thank you e dev ! > - > 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 > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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
Re: [E-devel] EFM: thoughts, current work et al.
Hi, As a user I'm very happy to see all this keen interest with efm. I really like it since I use the thumbscroll feature (sometimes I even try to scroll the firefox pages like this !) and I think it's good for basic operation / navigation. Nevertheless I'm used to select multiple files in a list view from one to another by holding Shift and to separtely select files by holding Control... In efm it's the opposite, is it an error ? Like many of you I would like to have shortcuts to copy/paste and I'll add : Alt+directions to navigate through folders like in others filemanager. + a module like efm_nav and path but which will show us the path with buttons for a speedy navigation + an implementation of the "delete in trash" like in the trash module + a column view like in the macos finder, but raster said : the fm widget views 1 directory at a time - that's how its built. > changing that is major surgery. So I don't know if it's feasible, but could be really great with some nice translations when the columns have to slide, and could permits the last column to show some more informations on the file selected... I'm dreaming :) ... or if it's something not doable, why not adding some fancy effect when opening a folder (when the "open dirs in place" is checked) ? Hope it could make e even better ! Thank you e dev ! - 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
Re: [E-devel] EFM: thoughts, current work et al.
Holy Crap!!! ;-) Thanks Guys! I hadn't touched it in quite a while, thanks for the direction! I can now dump thunar! ;-) On Sat, 2008-11-29 at 09:50 +1100, Carsten Haitzler wrote: > On Fri, 28 Nov 2008 17:27:20 -0500 jess <[EMAIL PROTECTED]> babbled: > > > 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. > > yes it is. you haven't spent much time looking at the config - have you? :) > you > will also want to try the efm_nav module. > > > 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...
Re: [E-devel] EFM: thoughts, current work et al.
- "Nick Hughart" <[EMAIL PROTECTED]> ha scritto: > On Sat, 29 Nov 2008 00:03:14 +0100 (CET) > Dave Andreoli <[EMAIL PROTECTED]> wrote: > > > > > - "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> ha > scritto: > > > > > On Fri, Nov 28, 2008 at 5:11 PM, Dave Andreoli > > > <[EMAIL PROTECTED]> wrote: > > > >> 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. > > > > > > Why don't you add "places" module in E's SVN? I dislike having to > > > search for modules over the net... and I really forgot about > places > > > (actually could be named volumes, dunno?). > > > > 'couse I don't know witch filemanager to launch on click, for now > > places use thunar ... I have made some try to find an E-way to > share > > mime default but without success for now ;) > > So, i'm waiting for a efm desktop to run :) > > You should be able to launch an efm window from a module without a > problem. I don't see what your issue is there. My issue is WITCH is the right filemanager to run, not how to run it. And I want to resolv this issue BOTH for modules and for apps. (in edje_editor I need to launch you preferred text editor and your pref image editor. > > > and a centralized way to store info (default fm, default term > etc..) > > to read from. I have also done a module to set your default > > applications, but don't know how to share this information :( > > > > Hey! this spot out a new todo item: > > * efm should read and write preferred applications in a 'standard > > way', note that standard don't stand for fredesktop, they don't > have > > a spec for defapp atm. > > It already has a 'standard' way then. You can read the config just > as > easy as efm can afaik. It should be global and accessible by any > module. but only by modules > I don't see this as a standard though due to the fact that > no > one else is or will use it since it is very specific to E. So I'd > rather someone get involved in the FDO spec that is being tossed > around > and help get it pushed through and improved. Might be a good chance > for us to get our foot in the door with FDO. The FDO standard for this is a work in progress, and is not exacly what I need for the moment. I think we need an 'abstraction layer' for the standard. I mean to have 2 functions somewhere (like get_default_mime and set_default_mime). In this way when the standard will be ready we just need to modify that 2 functions. If this is not going to happend I will invent my own method and I will make Places and Trash to use the $X-FILEMANAGER, $X-WWW-BROWSER variables...and also my module to setup the defaults will work in this way. hmmm...maybe this last solution is not so bad :) Dave > > > > > Dave > > > > p.s. the same problem is also blocking the trash module to go in > svn > > > > > > > > -- > > > 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
Re: [E-devel] EFM: thoughts, current work et al.
2008/11/29 Viktor Kojouharov <[EMAIL PROTECTED]>: > On Sat, 2008-11-29 at 00:13 +0100, Massimiliano Calamelli wrote: >> 2008/11/28 Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>: >> > On Fri, Nov 28, 2008 at 5:11 PM, Dave Andreoli <[EMAIL PROTECTED]> wrote: >> >>> 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. >> > >> > Why don't you add "places" module in E's SVN? I dislike having to >> > search for modules over the net... and I really forgot about places >> > (actually could be named volumes, dunno?). >> > >> >> We have exchange.e.org for that, people can add their modules into the >> showcase, and add info about where to get it. > > I still haven't figured out how to add themes to the showcase, let alone > modules. The typical user can not add a theme to the Showcase section. Only the site admins can do that. If you do think a theme is worthy of the Showcase, message the e-users list so people can debate it. Same goes for removing themes from the showcase. Toma >> >> Massimiliano >> >> - >> 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 > - 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
Re: [E-devel] EFM: thoughts, current work et al.
On Sat, 29 Nov 2008 00:19:16 -0200 "Gustavo Sverzut Barbieri"
<[EMAIL PROTECTED]> babbled:
> On Fri, Nov 28, 2008 at 9:03 PM, Dave Andreoli <[EMAIL PROTECTED]> wrote:
> >
> > - "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> ha scritto:
> >
> >> On Fri, Nov 28, 2008 at 5:11 PM, Dave Andreoli
> >> <[EMAIL PROTECTED]> wrote:
> >> >> 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.
> >>
> >> Why don't you add "places" module in E's SVN? I dislike having to
> >> search for modules over the net... and I really forgot about places
> >> (actually could be named volumes, dunno?).
> >
> > 'couse I don't know witch filemanager to launch on click, for now places
> > use thunar ... I have made some try to find an E-way to share mime default
> > but without success for now ;)
> > So, i'm waiting for a efm desktop to run :)
>
> Well, I said how you could launch EFM from command line, BUT for
> places you can use e_fwin directly since it is in the same binary OR
> you could inject the "fileman" action directly. Calling e_fwin
> directly have the problem that is one module knowing about the other
> module, we can write a simple registry to easy such things.
>
> With Guarana we have the module manager that unlike E, is based on an
> external association of key=(file, symbol). We write key and
> association in an EET file and we request for symbols matching that
> key, files are automatically loaded if not already. These keys can
> represent "interfaces" or "implementations" of some functionality.
> Anyway, since E has already this module init functions that
> register stuff, we could register a filemanager symbol there. e's
> fileman would just call e_fwin_new(), but one can write one that exec
> some external application like thunar.
you can call the action like this from any code:
E_Action *a = e_action_find("fileman");
if ((a) && (a->func.go)) a->func.go(NULL, NULL);
anything that advertises an action can do this. its in principle not much
different to a more complex eet file set with symbols and basically runtime
dlsym() on abstracted objects. :) there is also e_msg.c - it's a generic
messaging interface that sends named (string) messages with a few basic
parameters able to be sent with it. anyone can set up a handler for one. so all
the nuts and bolts are there.
> > and a centralized way to store info (default fm, default term etc..) to
> > read from. I have also done a module to set your default applications, but
> > don't know how to share this information :(
>
> as mekius said, it's a global in e_config I guess.
yup. just the only one accessing it is e. you'd need to patch any fm to share
the same stuff as there is no universal location for this currently that
everyone already uses.
> > Hey! this spot out a new todo item:
> > * efm should read and write preferred applications in a 'standard way',
> > note that standard don't stand for fredesktop, they don't have a spec for
> > defapp atm.
> >
> > Dave
> >
> > p.s. the same problem is also blocking the trash module to go in svn
>
> Hacking them inside E SVN, I'm not even talking about E package, it
> could be in extra modules, would let more people look at it... or at
> least know it is being development
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: [EMAIL PROTECTED]
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
-
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
Re: [E-devel] EFM: thoughts, current work et al.
On Fri, Nov 28, 2008 at 9:03 PM, Dave Andreoli <[EMAIL PROTECTED]> wrote: > > - "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> ha scritto: > >> On Fri, Nov 28, 2008 at 5:11 PM, Dave Andreoli >> <[EMAIL PROTECTED]> wrote: >> >> 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. >> >> Why don't you add "places" module in E's SVN? I dislike having to >> search for modules over the net... and I really forgot about places >> (actually could be named volumes, dunno?). > > 'couse I don't know witch filemanager to launch on click, for now places > use thunar ... I have made some try to find an E-way to share mime default > but without success for now ;) > So, i'm waiting for a efm desktop to run :) Well, I said how you could launch EFM from command line, BUT for places you can use e_fwin directly since it is in the same binary OR you could inject the "fileman" action directly. Calling e_fwin directly have the problem that is one module knowing about the other module, we can write a simple registry to easy such things. With Guarana we have the module manager that unlike E, is based on an external association of key=(file, symbol). We write key and association in an EET file and we request for symbols matching that key, files are automatically loaded if not already. These keys can represent "interfaces" or "implementations" of some functionality. Anyway, since E has already this module init functions that register stuff, we could register a filemanager symbol there. e's fileman would just call e_fwin_new(), but one can write one that exec some external application like thunar. > and a centralized way to store info (default fm, default term etc..) to read > from. > I have also done a module to set your default applications, but don't > know how to share this information :( as mekius said, it's a global in e_config I guess. > Hey! this spot out a new todo item: > * efm should read and write preferred applications in a 'standard way', note > that standard don't stand for fredesktop, they don't have a spec for defapp > atm. > > Dave > > p.s. the same problem is also blocking the trash module to go in svn Hacking them inside E SVN, I'm not even talking about E package, it could be in extra modules, would let more people look at it... or at least know it is being development -- 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
Re: [E-devel] EFM: thoughts, current work et al.
On Sat, 2008-11-29 at 00:13 +0100, Massimiliano Calamelli wrote: > 2008/11/28 Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>: > > On Fri, Nov 28, 2008 at 5:11 PM, Dave Andreoli <[EMAIL PROTECTED]> wrote: > >>> 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. > > > > Why don't you add "places" module in E's SVN? I dislike having to > > search for modules over the net... and I really forgot about places > > (actually could be named volumes, dunno?). > > > > We have exchange.e.org for that, people can add their modules into the > showcase, and add info about where to get it. I still haven't figured out how to add themes to the showcase, let alone modules. > > Massimiliano > > - > 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
Re: [E-devel] EFM: thoughts, current work et al.
On Sat, 29 Nov 2008 00:03:14 +0100 (CET) Dave Andreoli <[EMAIL PROTECTED]> wrote: > > - "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> ha scritto: > > > On Fri, Nov 28, 2008 at 5:11 PM, Dave Andreoli > > <[EMAIL PROTECTED]> wrote: > > >> 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. > > > > Why don't you add "places" module in E's SVN? I dislike having to > > search for modules over the net... and I really forgot about places > > (actually could be named volumes, dunno?). > > 'couse I don't know witch filemanager to launch on click, for now > places use thunar ... I have made some try to find an E-way to share > mime default but without success for now ;) > So, i'm waiting for a efm desktop to run :) You should be able to launch an efm window from a module without a problem. I don't see what your issue is there. > and a centralized way to store info (default fm, default term etc..) > to read from. I have also done a module to set your default > applications, but don't know how to share this information :( > > Hey! this spot out a new todo item: > * efm should read and write preferred applications in a 'standard > way', note that standard don't stand for fredesktop, they don't have > a spec for defapp atm. It already has a 'standard' way then. You can read the config just as easy as efm can afaik. It should be global and accessible by any module. I don't see this as a standard though due to the fact that no one else is or will use it since it is very specific to E. So I'd rather someone get involved in the FDO spec that is being tossed around and help get it pushed through and improved. Might be a good chance for us to get our foot in the door with FDO. > > Dave > > p.s. the same problem is also blocking the trash module to go in svn > > > > > -- > > 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
Re: [E-devel] EFM: thoughts, current work et al.
2008/11/28 Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>: > On Fri, Nov 28, 2008 at 5:11 PM, Dave Andreoli <[EMAIL PROTECTED]> wrote: >>> 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. > > Why don't you add "places" module in E's SVN? I dislike having to > search for modules over the net... and I really forgot about places > (actually could be named volumes, dunno?). > We have exchange.e.org for that, people can add their modules into the showcase, and add info about where to get it. Massimiliano - 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
Re: [E-devel] EFM: thoughts, current work et al.
On Fri, 28 Nov 2008 18:10:00 -0200 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> wrote: > On Fri, Nov 28, 2008 at 5:11 PM, Dave Andreoli > <[EMAIL PROTECTED]> wrote: > >> 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. > > Why don't you add "places" module in E's SVN? I dislike having to > search for modules over the net... and I really forgot about places > (actually could be named volumes, dunno?). > Well once E is released you'll probably have to search around for modules anyway as we will probably not be able to host every module out there. Besides, some people will rather have their code somewhere they can control instead of in our SVN. - 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
Re: [E-devel] EFM: thoughts, current work et al.
- "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> ha scritto: > On Fri, Nov 28, 2008 at 5:11 PM, Dave Andreoli > <[EMAIL PROTECTED]> wrote: > >> 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. > > Why don't you add "places" module in E's SVN? I dislike having to > search for modules over the net... and I really forgot about places > (actually could be named volumes, dunno?). 'couse I don't know witch filemanager to launch on click, for now places use thunar ... I have made some try to find an E-way to share mime default but without success for now ;) So, i'm waiting for a efm desktop to run :) and a centralized way to store info (default fm, default term etc..) to read from. I have also done a module to set your default applications, but don't know how to share this information :( Hey! this spot out a new todo item: * efm should read and write preferred applications in a 'standard way', note that standard don't stand for fredesktop, they don't have a spec for defapp atm. Dave p.s. the same problem is also blocking the trash module to go in svn > > -- > 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
Re: [E-devel] EFM: thoughts, current work et al.
On Fri, 28 Nov 2008 17:27:20 -0500 jess <[EMAIL PROTECTED]> babbled: > 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. yes it is. you haven't spent much time looking at the config - have you? :) you will also want to try the efm_nav module. > 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. > > >
Re: [E-devel] EFM: thoughts, current work et al.
On Fri, 28 Nov 2008 12:54:58 -0200 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled: > > 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. > > I guess this is something harder because it needs to be solved at Evas > and Edje, see other discussion about textblock and "...". Since there > are no markups involved we could hack it using single line text > objects and simulate that ourselves, but it's not that simple. > > > > 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 > > I really dislike tree views... :-/ agreed. simply not going to happen because of the work required to make it happen. the fm widget views 1 directory at a time - that's how its built. changing that is major surgery. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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
Re: [E-devel] EFM: thoughts, current work et al.
- "jess" <[EMAIL PROTECTED]> ha scritto: > 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. :| Isn't it the first checkbox on the efm configuration dialog? "open directory in the same window" ?? Dave > > > 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
Re: [E-devel] EFM: thoughts, current work et al.
2008/11/28 jess <[EMAIL PROTECTED]>: > 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 > E menu -> Setting -> Setting Panel -> File e Directory (in italian) -> File Manager Check "Open Dirs In Place" Massimiliano - 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
Re: [E-devel] EFM: thoughts, current work et al.
2008/11/29 jess <[EMAIL PROTECTED]>: > 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 > It is entirely configurable. But before you go ahead with the option, its advised to build and install efm_nav and/or efm_path from the E-MODULES-EXTRA dir to make use of the single window option. Its under Settings > Files > File manager > Open Dirs in Place. Toma. > > 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
Re: [E-devel] EFM: thoughts, current work et al.
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 w
Re: [E-devel] EFM: thoughts, current work et al.
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" -- 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/lis
Re: [E-devel] EFM: thoughts, current work et al.
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" -- 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
Re: [E-devel] EFM: thoughts, current work et al.
On Fri, Nov 28, 2008 at 5:11 PM, Dave Andreoli <[EMAIL PROTECTED]> wrote: >> 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. Why don't you add "places" module in E's SVN? I dislike having to search for modules over the net... and I really forgot about places (actually could be named volumes, dunno?). -- 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
Re: [E-devel] EFM: thoughts, current work et al.
- "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 t
Re: [E-devel] EFM: thoughts, current work et al.
- "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. Dave > > 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. > 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. > > 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". > > -- > 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
Re: [E-devel] EFM: thoughts, current work et al.
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
Re: [E-devel] EFM: thoughts, current work et al.
On Fri, Nov 28, 2008 at 11:13 AM, Luchezar Petkov <[EMAIL PROTECTED]> wrote: > > 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
Re: [E-devel] EFM: thoughts, current work et al.
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 >
Re: [E-devel] EFM: thoughts, current work et al.
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 al
Re: [E-devel] EFM: thoughts, current work et al.
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 (provi
Re: [E-devel] EFM: thoughts, current work et al.
On Fri, Nov 28, 2008 at 12:41 AM, Alberto Castro <[EMAIL PROTECTED]> wrote: > This is more related to the "Confirm" (file(s)) delete dialog. I wish it > was STACKED above all windows all the time, its troubling having to go > search for it whenever another window gains focus. > > The current efm icon_efm/dnd copy/move/ask behavior where you move a > file, and you lose sight of the original file's location and its name is > also troubling. Across most desktop environments, the file in question, > upon initial move, always stays in place (might go from opaque to semi > transparent) but always stays in place, while in transition, the new > copy is visible (and so is the file in question). Upon mouse release, > the file (if the physics allow) will change location. Currently when you > move a file from one area of the desktop to the other, the icon moves, > you get a small overlay (icon) representing (copy, ask, move), but the > file is no longer visible where it was initially picked up. And if you > want to find out what what file you are dragging you have to look for > your mouse pointer. With the current lack of compositing effects this > behavior is a bit ugly. I guess that adding these stuff IN (as in an edje overlay) to EFM windows is the best approach. Dialogs should be tied to windows to avoid confusion if they apply to that or another window. -- 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
Re: [E-devel] EFM: thoughts, current work et al.
This is more related to the "Confirm" (file(s)) delete dialog. I wish it was STACKED above all windows all the time, its troubling having to go search for it whenever another window gains focus. The current efm icon_efm/dnd copy/move/ask behavior where you move a file, and you lose sight of the original file's location and its name is also troubling. Across most desktop environments, the file in question, upon initial move, always stays in place (might go from opaque to semi transparent) but always stays in place, while in transition, the new copy is visible (and so is the file in question). Upon mouse release, the file (if the physics allow) will change location. Currently when you move a file from one area of the desktop to the other, the icon moves, you get a small overlay (icon) representing (copy, ask, move), but the file is no longer visible where it was initially picked up. And if you want to find out what what file you are dragging you have to look for your mouse pointer. With the current lack of compositing effects this behavior is a bit ugly. Salut! Chidambar 'ilLogict' Zinnoury wrote: > 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. :) > > Cheers! > > Chidambar > > > > > - > 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
Re: [E-devel] EFM: thoughts, current work et al.
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. 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. 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. 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". -- 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
Re: [E-devel] EFM: thoughts, current work et al.
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. 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). 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.) 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.). 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. 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. 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. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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
Re: [E-devel] EFM: thoughts, current work et al.
Progress bars: But not in a seperate window. Keep it on the EFM overlay edje part. Thats all Ive got atm... Toma 2008/11/28 Chidambar 'ilLogict' Zinnoury <[EMAIL PROTECTED]>: > 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. :) > > Cheers! > > Chidambar > > - > 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
[E-devel] EFM: thoughts, current work et al.
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. :) Cheers! Chidambar signature.asc Description: PGP signature - 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
