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
