Re: [E-devel] Efm development
I'm still playing catch up after being off the 'net for four months, but this caught my attention... On Wed, 1 Apr 2009 09:00:24 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Apr 1, 2009 at 7:22 AM, Sergey Semernin sergey.semer...@gmail.com wrote: ... I can help you. What tasks are remaining exactly? In my view there are several major improvements: removable devices mount with correct fstab processing (so devices can be mounting properly when fstab corresponding fstab records exists); grid representation in fileman window with name, type, size, access rights, etc.; toolbar in file manager window with most using operations. we should use hal (or device kit, or similar) and not bother about /etc/fstab, so the thing today is how to populate one folder with real and virtual items. Maybe this is getting fixed, or is discussed in the hundreds of E17 emails I am still reading through. When I tried it, I got complaints that HAL wont mount my devices cos they are listed in fstab. WTF? I don't know about this HAL stuff, but what's wrong with having the device in fstab? It's in there so that it goes to a fixed place that I decided, with the options I want, and then I can just mount /foo when not using a GUI. Seems pointless to not live happily with a very long lived standard way of dealing with this sort of thing. It all just seems silly. signature.asc Description: PGP signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm development
On Thu, 2009-04-02 at 06:33 +0200, Vincent Torri wrote: On Thu, 2 Apr 2009, Dave Andreoli wrote: hmmm... pause... I have to much stuff to write... What about if I make a page on the wiki that we can use as TODO ? so we can keep all the progress up to date. I can start the page with all the question on this thread. maybe better to use the release plan page. NO ! the release page is NOT here for adding features, it's a page with entries to fix for the release. If we always add something to do, it will be a neverending story Agreed. The release page must stay as-is. Vincent -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm development
Hello, Dave. In message from 2 апреля 2009 Dave Andreoli wrote: * efm atm read .gtk-bookmarks (they are displayed in the new file submenu in the E main menu). This is cool, as many other apps use it, but at the end create some confusion with the E favorite [skipped] There are two ways - first, import .gtk-bookmarks into .favorites and then keep it timed. Second way - add fuction to read and populate gtk-bookmarks as icons in favorites folder and vice versa. I think first approach more unify with exists code. Actually, when adding some new into favorites we don't change gtk-favorites, but if .gtk-favorites changed we rescan it and adding/removing entries from our favorites. hmmm... pause... I have to much stuff to write... What about if I make a page on the wiki that we can use as TODO ? so we can keep all the progress up to date. I can start the page with all the question on this thread. It will be very good. Each of us will known exactly what need to do and who what doing now. Sincerely yours, Sergey. -- Jabber/XMPP: sergey.semer...@gmail.com Cellular: +7-909-206-5992 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm development
Please people, help Sergey, he's the stipended coder I was talking about some time ago. Thank you very much for your efforts Sergey, I'm happy you are here, really. So, anyone who reads this mail, please comment Sergey's patch, verify what he did, help him, show him what he can do to help! He's here exactly to help :) And then I'm also happy to see that Sergey is also interested in Enlightenment for his own purposes and interests. Doing things with passion is way better than anything else :) Greetings everyone, Luca D.M. 2009/4/1 Sergey Semernin sergey.semer...@gmail.com Hello, Dave! I see you importing 'places' into efm2. I'm starting work on efm2 too, because i have plans for E17 use and interesting first a robust, usable file manager. I can help you. What tasks are remaining exactly? In my view there are several major improvements: removable devices mount with correct fstab processing (so devices can be mounting properly when fstab corresponding fstab records exists); grid representation in fileman window with name, type, size, access rights, etc.; toolbar in file manager window with most using operations. What about background/color set GUI, rename in place, progress indication? P.S. Earlier, I send to e-devel small patch to read window geometry in e_fwin_new function. What's wrong, or you plan reject this function from code? Sincerely yours, Sergey. -- Jabber/XMPP: sergey.semer...@gmail.com Cellular: +7-909-206-5992 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm development
Hey, I see you importing 'places' into efm2. I'm starting work on efm2 too, because i have plans for E17 use and interesting first a robust, usable file manager. I can help you. What tasks are remaining exactly? for the e17 release, see: http://trac.enlightenment.org/e/wiki/Release there are lots of improvements to be done. Btw, for all those who work on efm (Gustavo, Viktor, etc...), if you have fixed an entry in that list, please strike it. about your questions below, i let the devs on efm answer you regards Vincent In my view there are several major improvements: removable devices mount with correct fstab processing (so devices can be mounting properly when fstab corresponding fstab records exists); grid representation in fileman window with name, type, size, access rights, etc.; toolbar in file manager window with most using operations. What about background/color set GUI, rename in place, progress indication? P.S. Earlier, I send to e-devel small patch to read window geometry in e_fwin_new function. What's wrong, or you plan reject this function from code? Sincerely yours, Sergey. -- Jabber/XMPP: sergey.semer...@gmail.com Cellular: +7-909-206-5992 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Ce message a été vérifié par MailScanner pour des virus ou des polluriels et rien de suspect n'a été trouvé. Message délivré par le serveur de messagerie de l'Université d'Evry. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm development
On Wed, Apr 1, 2009 at 7:22 AM, Sergey Semernin
sergey.semer...@gmail.com wrote:
...
I can help you. What tasks are remaining exactly?
In my view there are several major improvements: removable devices mount with
correct fstab processing (so devices can be mounting properly when fstab
corresponding fstab records exists); grid representation in fileman window
with name, type, size, access rights, etc.; toolbar in file manager window
with most using operations.
we should use hal (or device kit, or similar) and not bother about
/etc/fstab, so the thing today is how to populate one folder with real
and virtual items. For example, the desktop uses links in order to
have the code that reads entries to do it on one way. Also, everything
is handled as if it was a real file, with stat information and so
on. At first I'd say we should lie about the virtual device being a
file and add it to the list by other means, just need to be careful
with add/remove signals that come from inotify. Then I'd try to
refactor part of the code based on the findings of the first part,
abstracting the common bits.
just one thing, the only folder that seems to require dynamic devices
to show on automatically is ~/Desktop, where we can have the places
gadgets and get ride of that code. So I'd not expend much time on this
issue, at least now. I'd say we should get ride of that nasty
devices-links code and ship e17 with places by default.
grid: it's not hard in edje, but there is absolutely no code there to
support generic model-view mapping. That is, you need to walk every
switch()/if() and the list mode to find it out. For this one I'd
refactor that from start, setting a single layout function and let
it do the things, no switch()/if() at all. And move the enumeration to
a list of pointers to struct describing view mode, be them list, grid,
custom grid... Config dialog would use it to let you choose (like it
do today), and extensions could register a new fancy view mode. But
again, in order to be really useful this is not a small task and need
lots of work and surely it is NOT mandatory for e17, so low priority.
toolbar: very easy, actually it is there, just need some love.
What about background/color set GUI, rename in place, progress indication?
background set gui I know of a guy doing some work in set as
wallpaper... that could be easily changed to set as wallpaper
{Directory, Desktop} (sub menu with 2 entries). Other parts like
selecting custom themes for other bits is bit more complicated and
would need a nice dialog we have not think about, maybe raster can
provide some insights.
P.S. Earlier, I send to e-devel small patch to read window geometry in
e_fwin_new function. What's wrong, or you plan reject this function from
code?
nothing wrong, just busy! I'm traveling atm and raster is busy with
his stuff, I don't know about Viktor, but other than us not many
people working on efm these days.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm development
On Wed, 2009-04-01 at 14:22 +0400, Sergey Semernin wrote: Hello, Dave! I see you importing 'places' into efm2. I'm starting work on efm2 too, because i have plans for E17 use and interesting first a robust, usable file manager. I can help you. What tasks are remaining exactly? In my view there are several major improvements: removable devices mount with correct fstab processing (so devices can be mounting properly when fstab corresponding fstab records exists); grid representation in fileman window with name, type, size, access rights, etc.; toolbar in file manager window with most using operations. What about background/color set GUI, rename in place, progress indication? We should take the in-place to a whole new level, and remove as many dialogs as we can. The only dialog that should stay is the properties one, since it is quite big. Every other dialog should go as an overlay to the e_fm window that spawned it. Some type of status overlay that displays useful info on the selected item (or is hidden if nothing is selected) would also be nice. the rest just need love and bug cleaning :) btw, what do you guys think if these ideas: Having a gadcon on the left/right side to display some info, like a directory tree or a list of favourites? Using the .gtk-bookmarks instead of the current favourites (if the first supports things other than directories) Using a toolbar to open different locations within the same e_fm window? P.S. Earlier, I send to e-devel small patch to read window geometry in e_fwin_new function. What's wrong, or you plan reject this function from code? Sincerely yours, Sergey. -- Jabber/XMPP: sergey.semer...@gmail.com Cellular: +7-909-206-5992 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm development
2009/4/1 Viktor Kojouharov vkojouha...@gmail.com On Wed, 2009-04-01 at 14:22 +0400, Sergey Semernin wrote: Hello, Dave! I see you importing 'places' into efm2. I'm starting work on efm2 too, because i have plans for E17 use and interesting first a robust, usable file manager. I can help you. What tasks are remaining exactly? In my view there are several major improvements: removable devices mount with correct fstab processing (so devices can be mounting properly when fstab corresponding fstab records exists); grid representation in fileman window with name, type, size, access rights, etc.; toolbar in file manager window with most using operations. What about background/color set GUI, rename in place, progress indication? We should take the in-place to a whole new level, and remove as many dialogs as we can. The only dialog that should stay is the properties one, since it is quite big. Every other dialog should go as an overlay to the e_fm window that spawned it. Some type of status overlay that displays useful info on the selected item (or is hidden if nothing is selected) would also be nice. the rest just need love and bug cleaning :) btw, what do you guys think if these ideas: Having a gadcon on the left/right side to display some info, like a directory tree or a list of favourites? Using the .gtk-bookmarks instead of the current favourites (if the first supports things other than directories) Using a toolbar to open different locations within the same e_fm window? I think all of the 3 things listed here are necessary for a serious File Manager. At least, I wouldn't use anything without a gadcon on the left side displaying a directory tree. Same at least for the toolbar. Greets, Luca D.M. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm development
Hello, Gustavo.
In message from 1 april 2009 Gustavo Sverzut Barbieri wrote:
we should use hal (or device kit, or similar) and not bother about
/etc/fstab, so the thing today is how to populate one folder with real
and virtual items. For example, the desktop uses links in order to
have the code that reads entries to do it on one way. Also, everything
is handled as if it was a real file, with stat information and so
on. At first I'd say we should lie about the virtual device being a
file and add it to the list by other means, just need to be careful
with add/remove signals that come from inotify. Then I'd try to
refactor part of the code based on the findings of the first part,
abstracting the common bits.
IMHO, there's no bad in use special files to describe and point to removable
and virtual devices. In my practise I using in-memory filesystem for similar
things. It's quite another matter, that I need additional code to attach tree
of this filesystem to real fs or my window.
Other approaching - list of structured containers that holds information about
virtual items. So, that lists can be attached to different folders within
program code.
I think that will be GUI to define some parameters to mount, such as codepage,
sync mode.
just one thing, the only folder that seems to require dynamic devices
to show on automatically is ~/Desktop, where we can have the places
gadgets and get ride of that code. So I'd not expend much time on this
issue, at least now. I'd say we should get ride of that nasty
devices-links code and ship e17 with places by default.
Yes, ~/Desktop and ~/.e/e/fileman/favorites.
Btw, I tried to compile 'places' module today and got a undefined
symbol 'e_util_menu_item_icon_theme_set'. I searched this symbol in entire
trunc and not find it.
And last - I'm using several old programs, which work with cd-roms and etc.
and it require /dev/cdrom record in fstab. It's difficult to modify - I
have'nt sources of it, attempts to contact with authors bring nothing.
That's why I saying about fstab.
grid: it's not hard in edje, but there is absolutely no code there to
[skipped]
again, in order to be really useful this is not a small task and need
lots of work and surely it is NOT mandatory for e17, so low priority.
At total - now API for treelist and gridlist processing not exists?
Maybe realize approach when tree or grid represented as dynamical structure
with callbacks for elements and/or groups of elements (drawing, describing,
properties, etc.)?
toolbar: very easy, actually it is there, just need some love.
I found tho widgets for efm2 toolbar - set of back-forward-etc. buttons and
address line, but it have difficulties when positioning and dynamical resizi
ng in the toolbar. Is it known issue or problems depending on my build only?
background set gui I know of a guy doing some work in set as
wallpaper... that could be easily changed to set as wallpaper
{Directory, Desktop} (sub menu with 2 entries). Other parts like
selecting custom themes for other bits is bit more complicated and
would need a nice dialog we have not think about, maybe raster can
provide some insights.
Ok. I understood.
There is some problems with 'set as wallpaper' - im using utf-8 in filesystem
and russian names of dirs of course, so dialog can't read file with picture -
invalid path. I'll try to solve this problem.
Sincerely yours, Sergey.
--
Jabber/XMPP: sergey.semer...@gmail.com
Cellular: +7-909-206-5992
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm development
Hello, Victor. In message from 1 april 2009 Viktor Kojouharov wrote: We should take the in-place to a whole new level, and remove as many dialogs as we can. The only dialog that should stay is the properties one, since it is quite big. Every other dialog should go as an overlay to the e_fm window that spawned it. Some type of status overlay that displays useful info on the selected item (or is hidden if nothing is selected) would also be nice. I'll try to make in-place rename first. the rest just need love and bug cleaning :) So, I'll searching and fixing it. :) Having a gadcon on the left/right side to display some info, like a directory tree or a list of favourites? Absolutely yes, I think. Using a toolbar to open different locations within the same e_fm window? You mean 'address string'? That's need too. Sincerely yours, Sergey. -- Jabber/XMPP: sergey.semer...@gmail.com Cellular: +7-909-206-5992 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm development
On Wed, Apr 1, 2009 at 9:48 AM, Viktor Kojouharov vkojouha...@gmail.com wrote: On Wed, 2009-04-01 at 14:22 +0400, Sergey Semernin wrote: Hello, Dave! I see you importing 'places' into efm2. I'm starting work on efm2 too, because i have plans for E17 use and interesting first a robust, usable file manager. I can help you. What tasks are remaining exactly? In my view there are several major improvements: removable devices mount with correct fstab processing (so devices can be mounting properly when fstab corresponding fstab records exists); grid representation in fileman window with name, type, size, access rights, etc.; toolbar in file manager window with most using operations. What about background/color set GUI, rename in place, progress indication? We should take the in-place to a whole new level, and remove as many dialogs as we can. The only dialog that should stay is the properties one, since it is quite big. Every other dialog should go as an overlay to the e_fm window that spawned it. problem: window can be too small. problem specifically to rename in place: text can grow outside the viewport and it will be unusable. elementary suffers from that a lot, needs to be solved somehow generically. Some type of status overlay that displays useful info on the selected item (or is hidden if nothing is selected) would also be nice. yes, I'd say like a statusbar, but nicely overlayed. the rest just need love and bug cleaning :) btw, what do you guys think if these ideas: Having a gadcon on the left/right side to display some info, like a directory tree or a list of favourites? isn't it your drawer stuff?! Using the .gtk-bookmarks instead of the current favourites (if the first supports things other than directories) I'm pro it, at least firefox and other apps would use it. However kde apps do not share the same thing, so maybe have an option to try/use both, as some users will just not use gtk apps. Using a toolbar to open different locations within the same e_fm window? that's efm_nav, no? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm development
On Wed, 2009-04-01 at 12:59 -0300, Gustavo Sverzut Barbieri wrote: On Wed, Apr 1, 2009 at 9:48 AM, Viktor Kojouharov vkojouha...@gmail.com wrote: On Wed, 2009-04-01 at 14:22 +0400, Sergey Semernin wrote: Hello, Dave! I see you importing 'places' into efm2. I'm starting work on efm2 too, because i have plans for E17 use and interesting first a robust, usable file manager. I can help you. What tasks are remaining exactly? In my view there are several major improvements: removable devices mount with correct fstab processing (so devices can be mounting properly when fstab corresponding fstab records exists); grid representation in fileman window with name, type, size, access rights, etc.; toolbar in file manager window with most using operations. What about background/color set GUI, rename in place, progress indication? We should take the in-place to a whole new level, and remove as many dialogs as we can. The only dialog that should stay is the properties one, since it is quite big. Every other dialog should go as an overlay to the e_fm window that spawned it. problem: window can be too small. problem specifically to rename in place: text can grow outside the viewport and it will be unusable. elementary suffers from that a lot, needs to be solved somehow generically. From my very, very limited exposure with OSX, I've noticed that some dialogs grow when they are smaller than required. I have to say that I really liked that, and it could be a solution for this problem. Some type of status overlay that displays useful info on the selected item (or is hidden if nothing is selected) would also be nice. yes, I'd say like a statusbar, but nicely overlayed. the rest just need love and bug cleaning :) btw, what do you guys think if these ideas: Having a gadcon on the left/right side to display some info, like a directory tree or a list of favourites? isn't it your drawer stuff?! Not really. More like Places though. Actually, if the sidebar is a gadcon, the Places module will be perfect, as long as it understands that it is in an e_fm window already, so clicking on icons will open the destination in place. This also calls for some generic way of identifying some type of context per gadman (I currently assume in a few modules, including drawer and forecasts that if the orientation is FLOAT, then the gadget is on the desktop or on the desktop overlay, but that might prove very limiting in the future). Using the .gtk-bookmarks instead of the current favourites (if the first supports things other than directories) I'm pro it, at least firefox and other apps would use it. However kde apps do not share the same thing, so maybe have an option to try/use both, as some users will just not use gtk apps. That's true. But we need some KDE experts on this one though :) Using a toolbar to open different locations within the same e_fm window? that's efm_nav, no? Not really. I'm thinking more along the lines of 'tab'-like interface, like in recent versions of nautilus. And it should be pretty easy to implement too. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm development
On Wed, 1 Apr 2009 12:59:54 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Apr 1, 2009 at 9:48 AM, Viktor Kojouharov vkojouha...@gmail.com wrote: On Wed, 2009-04-01 at 14:22 +0400, Sergey Semernin wrote: Hello, Dave! I see you importing 'places' into efm2. I'm starting work on efm2 too, because i have plans for E17 use and interesting first a robust, usable file manager. I can help you. What tasks are remaining exactly? In my view there are several major improvements: removable devices mount with correct fstab processing (so devices can be mounting properly when fstab corresponding fstab records exists); grid representation in fileman window with name, type, size, access rights, etc.; toolbar in file manager window with most using operations. What about background/color set GUI, rename in place, progress indication? We should take the in-place to a whole new level, and remove as many dialogs as we can. The only dialog that should stay is the properties one, since it is quite big. Every other dialog should go as an overlay to the e_fm window that spawned it. problem: window can be too small. problem specifically to rename in place: text can grow outside the viewport and it will be unusable. elementary suffers from that a lot, needs to be solved somehow generically. Make the entry that shows up be scrollable. Doesn't need a scrollbar, just scroll it with the cursor. Granted this adds some complexity, but with edje_entry it might not be too hard. Some type of status overlay that displays useful info on the selected item (or is hidden if nothing is selected) would also be nice. yes, I'd say like a statusbar, but nicely overlayed. Anyone use evidence before? If not take a look at old screenshots. That had the sexiest info popup I've ever seen :) the rest just need love and bug cleaning :) btw, what do you guys think if these ideas: Having a gadcon on the left/right side to display some info, like a directory tree or a list of favourites? isn't it your drawer stuff?! Also allow a way to disable this hideous convention. I'd much rather just have a pull down on the toolbar that I can pick from instead of something soaking up screen real estate. Think of the poor individuals on 320x320 touchscreens :) Using the .gtk-bookmarks instead of the current favourites (if the first supports things other than directories) I'm pro it, at least firefox and other apps would use it. However kde apps do not share the same thing, so maybe have an option to try/use both, as some users will just not use gtk apps. Or we could potentially work with the KDE team, as they've expressed their distaste for some of the current specs as well, to generate a proper standard and f*** Gnome? Once Gnome no longer inter-operates with anything, maybe they'll get the point that they can't control the Linux desktop :) Using a toolbar to open different locations within the same e_fm window? that's efm_nav, no? I'm thinking he meant more of a paned typed thing where you can have multiple views all in a single window. Don't think this will be making it into E17 if that's the case. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm development
On Wed, 2009-04-01 at 11:52 -0500, Nick Hughart wrote: On Wed, 1 Apr 2009 12:59:54 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Apr 1, 2009 at 9:48 AM, Viktor Kojouharov vkojouha...@gmail.com wrote: On Wed, 2009-04-01 at 14:22 +0400, Sergey Semernin wrote: Hello, Dave! I see you importing 'places' into efm2. I'm starting work on efm2 too, because i have plans for E17 use and interesting first a robust, usable file manager. I can help you. What tasks are remaining exactly? In my view there are several major improvements: removable devices mount with correct fstab processing (so devices can be mounting properly when fstab corresponding fstab records exists); grid representation in fileman window with name, type, size, access rights, etc.; toolbar in file manager window with most using operations. What about background/color set GUI, rename in place, progress indication? We should take the in-place to a whole new level, and remove as many dialogs as we can. The only dialog that should stay is the properties one, since it is quite big. Every other dialog should go as an overlay to the e_fm window that spawned it. problem: window can be too small. problem specifically to rename in place: text can grow outside the viewport and it will be unusable. elementary suffers from that a lot, needs to be solved somehow generically. Make the entry that shows up be scrollable. Doesn't need a scrollbar, just scroll it with the cursor. Granted this adds some complexity, but with edje_entry it might not be too hard. Some type of status overlay that displays useful info on the selected item (or is hidden if nothing is selected) would also be nice. yes, I'd say like a statusbar, but nicely overlayed. Anyone use evidence before? If not take a look at old screenshots. That had the sexiest info popup I've ever seen :) They don't look too bad from the screenshots. But they do tend to take a lot of realestate. See your other post on this topic :) the rest just need love and bug cleaning :) btw, what do you guys think if these ideas: Having a gadcon on the left/right side to display some info, like a directory tree or a list of favourites? isn't it your drawer stuff?! Also allow a way to disable this hideous convention. I'd much rather just have a pull down on the toolbar that I can pick from instead of something soaking up screen real estate. Think of the poor individuals on 320x320 touchscreens :) Well, unlike some other file managers, people with small screens can always opt to not turn on the side gadmans (or it should be off by default). For the rest of us that prefer something visible and in-your-face, the sidebar is a nice convention. We are not GNOME, we can live with a few options :) Using the .gtk-bookmarks instead of the current favourites (if the first supports things other than directories) I'm pro it, at least firefox and other apps would use it. However kde apps do not share the same thing, so maybe have an option to try/use both, as some users will just not use gtk apps. Or we could potentially work with the KDE team, as they've expressed their distaste for some of the current specs as well, to generate a proper standard and f*** Gnome? Once Gnome no longer inter-operates with anything, maybe they'll get the point that they can't control the Linux desktop :) Whatever fits best. Using a toolbar to open different locations within the same e_fm window? that's efm_nav, no? I'm thinking he meant more of a paned typed thing where you can have multiple views all in a single window. Don't think this will be making it into E17 if that's the case. Why not? -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm development
On Wed, 2009-04-01 at 11:52 -0500, Nick Hughart wrote: On Wed, 1 Apr 2009 12:59:54 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Apr 1, 2009 at 9:48 AM, Viktor Kojouharov vkojouha...@gmail.com wrote: On Wed, 2009-04-01 at 14:22 +0400, Sergey Semernin wrote: Hello, Dave! I see you importing 'places' into efm2. I'm starting work on efm2 too, because i have plans for E17 use and interesting first a robust, usable file manager. I can help you. What tasks are remaining exactly? In my view there are several major improvements: removable devices mount with correct fstab processing (so devices can be mounting properly when fstab corresponding fstab records exists); grid representation in fileman window with name, type, size, access rights, etc.; toolbar in file manager window with most using operations. What about background/color set GUI, rename in place, progress indication? We should take the in-place to a whole new level, and remove as many dialogs as we can. The only dialog that should stay is the properties one, since it is quite big. Every other dialog should go as an overlay to the e_fm window that spawned it. problem: window can be too small. problem specifically to rename in place: text can grow outside the viewport and it will be unusable. elementary suffers from that a lot, needs to be solved somehow generically. Make the entry that shows up be scrollable. Doesn't need a scrollbar, just scroll it with the cursor. Granted this adds some complexity, but with edje_entry it might not be too hard. Some type of status overlay that displays useful info on the selected item (or is hidden if nothing is selected) would also be nice. yes, I'd say like a statusbar, but nicely overlayed. Anyone use evidence before? If not take a look at old screenshots. That had the sexiest info popup I've ever seen :) p.s. I knew I forgot something. Speaking of evidence, people seem to be begging for nautilus to have a browser view (like evidence, finder, everything else under the sun). Just getting the idea out of the door. Could be the first new feature after E17 goes live. the rest just need love and bug cleaning :) btw, what do you guys think if these ideas: Having a gadcon on the left/right side to display some info, like a directory tree or a list of favourites? isn't it your drawer stuff?! Also allow a way to disable this hideous convention. I'd much rather just have a pull down on the toolbar that I can pick from instead of something soaking up screen real estate. Think of the poor individuals on 320x320 touchscreens :) Using the .gtk-bookmarks instead of the current favourites (if the first supports things other than directories) I'm pro it, at least firefox and other apps would use it. However kde apps do not share the same thing, so maybe have an option to try/use both, as some users will just not use gtk apps. Or we could potentially work with the KDE team, as they've expressed their distaste for some of the current specs as well, to generate a proper standard and f*** Gnome? Once Gnome no longer inter-operates with anything, maybe they'll get the point that they can't control the Linux desktop :) Using a toolbar to open different locations within the same e_fm window? that's efm_nav, no? I'm thinking he meant more of a paned typed thing where you can have multiple views all in a single window. Don't think this will be making it into E17 if that's the case. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm development
Ok, I'm a little late on this post, I'm really busy lately, sorry :( Hey Sergey welcome :) Some random stuff in replay to the whole thread: * efm atm read .gtk-bookmarks (they are displayed in the new file submenu in the E main menu). This is cool, as many other apps use it, but at the end create some confusion with the E favorite folder. We need a single place to show favorites to the user. Note that the .favorite approach of E is much powerfull than the .gtk-bookmark, you can have what you want in the favorites (link to file, link to apps, link to device, etc) while in .gtk-bookmarks you can only have directory path. In conclusion I think the best solution is to keep the efm favorites as is (also with .desktop link to devices) and, optionally, populate it with entry (link or .desktop) from the .gtk-bookmarks file. * IMO the toolbar is a crucial point of the efm. We really need to fix it. It must handle every gadget we have, also with d'n'd, as we have many intresting gadgets for it (places, trash, efm_path, etc). As many of you said: the toolbar need to be placed also on the right or on the left, AND we should be able to have more than one toolbar. one on top and one on the left, just to make a random example ;) * I agree that we need to make gadget aware of the container type (shelf, gadcon, or toolbar). I remember that you can check for something like gadget-gadcon-name, but I'm not sure. This could be improved if a module have the ability to choose the accepted container, something like e_gadget_dont_show_in(toolbar) hmmm... pause... I have to much stuff to write... What about if I make a page on the wiki that we can use as TODO ? so we can keep all the progress up to date. I can start the page with all the question on this thread. Dave 2009/4/1 Viktor Kojouharov vkojouha...@gmail.com On Wed, 2009-04-01 at 11:52 -0500, Nick Hughart wrote: On Wed, 1 Apr 2009 12:59:54 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Apr 1, 2009 at 9:48 AM, Viktor Kojouharov vkojouha...@gmail.com wrote: On Wed, 2009-04-01 at 14:22 +0400, Sergey Semernin wrote: Hello, Dave! I see you importing 'places' into efm2. I'm starting work on efm2 too, because i have plans for E17 use and interesting first a robust, usable file manager. I can help you. What tasks are remaining exactly? In my view there are several major improvements: removable devices mount with correct fstab processing (so devices can be mounting properly when fstab corresponding fstab records exists); grid representation in fileman window with name, type, size, access rights, etc.; toolbar in file manager window with most using operations. What about background/color set GUI, rename in place, progress indication? We should take the in-place to a whole new level, and remove as many dialogs as we can. The only dialog that should stay is the properties one, since it is quite big. Every other dialog should go as an overlay to the e_fm window that spawned it. problem: window can be too small. problem specifically to rename in place: text can grow outside the viewport and it will be unusable. elementary suffers from that a lot, needs to be solved somehow generically. Make the entry that shows up be scrollable. Doesn't need a scrollbar, just scroll it with the cursor. Granted this adds some complexity, but with edje_entry it might not be too hard. Some type of status overlay that displays useful info on the selected item (or is hidden if nothing is selected) would also be nice. yes, I'd say like a statusbar, but nicely overlayed. Anyone use evidence before? If not take a look at old screenshots. That had the sexiest info popup I've ever seen :) p.s. I knew I forgot something. Speaking of evidence, people seem to be begging for nautilus to have a browser view (like evidence, finder, everything else under the sun). Just getting the idea out of the door. Could be the first new feature after E17 goes live. the rest just need love and bug cleaning :) btw, what do you guys think if these ideas: Having a gadcon on the left/right side to display some info, like a directory tree or a list of favourites? isn't it your drawer stuff?! Also allow a way to disable this hideous convention. I'd much rather just have a pull down on the toolbar that I can pick from instead of something soaking up screen real estate. Think of the poor individuals on 320x320 touchscreens :) Using the .gtk-bookmarks instead of the current favourites (if the first supports things other than directories) I'm pro it, at least firefox and other apps would use it. However kde apps do not share the same thing, so maybe have an option to try/use both, as some users will just not use gtk apps. Or we could potentially work
Re: [E-devel] Efm development
I may pop in with UX suggestions (mockups, etc). -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm development
2009/4/2 Dave Andreoli d...@gurumeditation.it Ok, I'm a little late on this post, I'm really busy lately, sorry :( Hey Sergey welcome :) Some random stuff in replay to the whole thread: * efm atm read .gtk-bookmarks (they are displayed in the new file submenu in the E main menu). This is cool, as many other apps use it, but at the end create some confusion with the E favorite folder. We need a single place to show favorites to the user. Note that the .favorite approach of E is much powerfull than the .gtk-bookmark, you can have what you want in the favorites (link to file, link to apps, link to device, etc) while in .gtk-bookmarks you can only have directory path. In conclusion I think the best solution is to keep the efm favorites as is (also with .desktop link to devices) and, optionally, populate it with entry (link or .desktop) from the .gtk-bookmarks file. * IMO the toolbar is a crucial point of the efm. We really need to fix it. It must handle every gadget we have, also with d'n'd, as we have many intresting gadgets for it (places, trash, efm_path, etc). As many of you said: the toolbar need to be placed also on the right or on the left, AND we should be able to have more than one toolbar. one on top and one on the left, just to make a random example ;) * I agree that we need to make gadget aware of the container type (shelf, gadcon, or toolbar). I remember that you can check for something like gadget-gadcon-name, but I'm not sure. This could be improved if a module have the ability to choose the accepted container, something like e_gadget_dont_show_in(toolbar) hmmm... pause... I have to much stuff to write... What about if I make a page on the wiki that we can use as TODO ? so we can keep all the progress up to date. I can start the page with all the question on this thread. maybe better to use the release plan page. Dave 2009/4/1 Viktor Kojouharov vkojouha...@gmail.com On Wed, 2009-04-01 at 11:52 -0500, Nick Hughart wrote: On Wed, 1 Apr 2009 12:59:54 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Apr 1, 2009 at 9:48 AM, Viktor Kojouharov vkojouha...@gmail.com wrote: On Wed, 2009-04-01 at 14:22 +0400, Sergey Semernin wrote: Hello, Dave! I see you importing 'places' into efm2. I'm starting work on efm2 too, because i have plans for E17 use and interesting first a robust, usable file manager. I can help you. What tasks are remaining exactly? In my view there are several major improvements: removable devices mount with correct fstab processing (so devices can be mounting properly when fstab corresponding fstab records exists); grid representation in fileman window with name, type, size, access rights, etc.; toolbar in file manager window with most using operations. What about background/color set GUI, rename in place, progress indication? We should take the in-place to a whole new level, and remove as many dialogs as we can. The only dialog that should stay is the properties one, since it is quite big. Every other dialog should go as an overlay to the e_fm window that spawned it. problem: window can be too small. problem specifically to rename in place: text can grow outside the viewport and it will be unusable. elementary suffers from that a lot, needs to be solved somehow generically. Make the entry that shows up be scrollable. Doesn't need a scrollbar, just scroll it with the cursor. Granted this adds some complexity, but with edje_entry it might not be too hard. Some type of status overlay that displays useful info on the selected item (or is hidden if nothing is selected) would also be nice. yes, I'd say like a statusbar, but nicely overlayed. Anyone use evidence before? If not take a look at old screenshots. That had the sexiest info popup I've ever seen :) p.s. I knew I forgot something. Speaking of evidence, people seem to be begging for nautilus to have a browser view (like evidence, finder, everything else under the sun). Just getting the idea out of the door. Could be the first new feature after E17 goes live. the rest just need love and bug cleaning :) btw, what do you guys think if these ideas: Having a gadcon on the left/right side to display some info, like a directory tree or a list of favourites? isn't it your drawer stuff?! Also allow a way to disable this hideous convention. I'd much rather just have a pull down on the toolbar that I can pick from instead of something soaking up screen real estate. Think of the poor individuals on 320x320 touchscreens :) Using the .gtk-bookmarks instead of the current favourites (if the first supports things other than directories) I'm pro it, at least firefox and other apps would use it. However kde apps do not share the
