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
