headers
Sergey Semernin | 1 Apr 2009 12:22
Picon

[E-devel] Efm development

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.semernin <at> gmail.com
Cellular: +7-909-206-5992

------------------------------------------------------------------------------
Permalink | Reply | 19 comments |
headers
Luca De Marini | 1 Apr 2009 12:32
Picon

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.semernin <at> 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.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vincent Torri | 1 Apr 2009 12:39
Picon

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?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vincent Torri | 1 Apr 2009 13:01
Picon

[E-devel] consistentness of the API


Hey,

I think that, before the release, we should verify that the api is consistent.

I think that, at least, we must verify that:

1) if a function has a _add sufix, the invert function must have the _del sufix

2) if a function has a _new sufix, the invert function must have the _free 
sufix.

I have seen that, in all the graphic systems of ecore, we create a window with 
_new, but we destroy it with _del, which is not consistent with the other parts 
of evas / ecore.

Do you think that we should (must ?) rename these _del functions to _free ?

Vincent

------------------------------------------------------------------------------
Permalink | Reply | 6 comments |
headers
Massimiliano Calamelli | 1 Apr 2009 13:11
Picon
Gravatar

Re: [E-devel] consistentness of the API


On Wed, 1 Apr 2009 13:01:08 +0200 (CEST)
Vincent Torri <vtorri <at> univ-evry.fr> wrote:

> 
> Hey,
> 
> I think that, before the release, we should verify that the api is consistent.
> 
> I think that, at least, we must verify that:
> 
> 1) if a function has a _add sufix, the invert function must have the _del sufix
> 
> 2) if a function has a _new sufix, the invert function must have the _free 
> sufix.
> 
> I have seen that, in all the graphic systems of ecore, we create a window with 
> _new, but we destroy it with _del, which is not consistent with the other parts 
> of evas / ecore.
> 
> Do you think that we should (must ?) rename these _del functions to _free ?
> 
> Vincent

I totally agree.

Massimiliano
--

-- 
Massimiliano Calamelli
http://www.mcalamelli.net
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Wehrfritz | 1 Apr 2009 13:57
Picon
Gravatar

Re: [E-devel] consistentness of the API

Vincent Torri schrieb:
> Hey,
>
> I think that, before the release, we should verify that the api is consistent.
>
> I think that, at least, we must verify that:
>
> 1) if a function has a _add sufix, the invert function must have the _del sufix
>
> 2) if a function has a _new sufix, the invert function must have the _free 
> sufix.
>
> I have seen that, in all the graphic systems of ecore, we create a window with 
> _new, but we destroy it with _del, which is not consistent with the other parts 
> of evas / ecore.
>
> Do you think that we should (must ?) rename these _del functions to _free ?
>
> Vincent
>   

In ewl we are using _destroy() as the opposite of _new(). I think the 
_free() name can be misleading, because it's sounds like it's only going 
to free the memory, where as _destroy() describes what it really does, 
it calls the destructor. That can be more then freeing memory. Like 
destroying child objects, freeing or closing other resources, etc.

Peter

------------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gustavo Sverzut Barbieri | 1 Apr 2009 14:00

Re: [E-devel] Efm development

On Wed, Apr 1, 2009 at 7:22 AM, Sergey Semernin
<sergey.semernin <at> 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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gustavo Sverzut Barbieri | 1 Apr 2009 14:07

Re: [E-devel] consistentness of the API

On Wed, Apr 1, 2009 at 8:01 AM, Vincent Torri <vtorri <at> univ-evry.fr> wrote:
>
> Hey,
>
> I think that, before the release, we should verify that the api is consistent.
>
> I think that, at least, we must verify that:
>
> 1) if a function has a _add sufix, the invert function must have the _del sufix
>
> 2) if a function has a _new sufix, the invert function must have the _free
> sufix.
>
> I have seen that, in all the graphic systems of ecore, we create a window with
> _new, but we destroy it with _del, which is not consistent with the other parts
> of evas / ecore.

ok, evas_free is there, all ecore is del, maybe rename free->del in
evas and have all destructors/deleters to be _del? I will not say the
same for _add/_new since they are different things/concepts, although
I'd not bother if rename _add->_new happens.

> Do you think that we should (must ?) rename these _del functions to _free ?

I'd not change it at this point, but if you feel like doing so, not against.

--

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
(Continue reading)

Permalink | Reply | 3 comments |
headers
Viktor Kojouharov | 1 Apr 2009 14:48
Picon

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?
(Continue reading)

Permalink | Reply | 13 comments |
headers
Luca De Marini | 1 Apr 2009 16:30
Picon

Re: [E-devel] Efm development

2009/4/1 Viktor Kojouharov <vkojouharov <at> 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 :)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane