On Mon, 9 Jan 2012 22:43:12 +0100
Davide Andreoli <d...@gurumeditation.it> wrote:

> First of all Hi to everyone!!
> 
> I have been lot of time far from the e world, mainly because I have
> changed 2 different jobs (and the house were I live) in the last year.
> But I'm more 'stable' now, so it's time to make some sane E related
> works :)
> In the last week I spent my nights reading the past messages from the
> devel list and the first feel I got was: "wow, we are going to release
> e17"...after a few seconds the second thought: "arghh. We need to fix
> all that broken stuff around !!! "
e17 release is still a VERY long way out. elementary appears to be the
current focus, and there's decades of development required for it to be usable
which must be compressed into a couple months. given the comparatively tiny
number of people who commit regularly to e17, it's unlikely that there will be
even an alpha until late Q2-Q3. if that.
> 
> 
> About fixing the Places module:
> places is broken, arghh! don't ask me why, I don't know, it was
> working well the last time I installed it (like 1 year ago). I must
> fix it! and a good'old rewrite seems necessary.
most likely a result of my rough attempt to add udisks support to it a long
time ago. whoops. iirc though, I implemented it properly and just never tested
it. you'll likely find that there are only a few small things breaking which
prevent it from working.
> I'm going to rewrite it as part of the fm module, so I can share all
> the code about the volumes management with e, seems to me the more
> natural way to go.
> but now comes the problems...
> 
> 
> About the way efm mount:
> The way e17 handle the unmount of device is quite odd to me (you know,
> e unmount the volume as soon as you close the last efm-win that use
> that volume) and this behavior is quite in conflict with the places
> module, as is it's main purpose is to provide the unmount/eject icon.
> Are we sure we want e17 behave in this way? I don't think so, an exaple:
>  * I want to watch a film on my usb stick: I put the key in, double
> click on the icon that appear on the desktop, double click on the film
> I like to start mplayer. Then I close the fm win to watch my
> video.....what happen? does e unmount the key while I'm watching? if
> no, when the key will be unmounted?
> I really think e should behave as all the other OSs does, mount on
> first use and unmount/eject on request.
I have no comment on this as I have never, and will never, allow a window
manager to manage my devices.
> 
> 
> About e17 device backends:
> We now have 3 different engine to manage volumes in e and none seems
> 100% functional:
> * the HAL backand seems broken as the places module.
this one works, but nobody has HAL anymore
> * the EEZE backend needs libmount (hard to get) and seems also not
> 100% functional.
I stopped working on this because it's impossible to get good testers. once
libmount-based mount implementations get more widespread (and it's a redhat
technology, so this is a guarantee), I will improve it to work better.
currently, however, it does work for me.
> * the UDEV backand is unselectable in the configure step, at least if
> you have hal installed.
UDEV is is only an option when 1) you have eeze, 2) you do not build HAL. The
reason for #2 is simple: udev is synchronous and HAL is not. that said, I have
been using this backend since I wrote it without issues in either configure or
runtime. also udev is not a mount backend, nor does it have any mounting
capabilities.
> really the configure switch seems broken to me, I have hal, udev and
> eeze installed, I should be able to choose witch one to use...it
eeze is udev.
> doesn't work, e always force me to use the hal one. Also the options
> seems wrong, we have:
> --enable-device-hal and --enable-device-udev   but not the one for eeze :/
> then we have:
> --enable-mount-hal --enable-mount-udisks --enable-mount-eeze   I
> understand the eeze one but the others? disable mount in hal? in
> udisk? ...why?
udisks is something entirely different; it aims to provide the same
functionality as HAL did for drives (dbus management and detection). I provided
configure switches so it would be easy to disable unwanted backends.
> 
> 
> About eeze:
> I like it (at least the api seems good, never used directly) but I
> have some issue in mind: in the api I saw some functions and datatypes
> that has the 'udev' word in...shouldn't eeze abstract the user from
> the underground?
no, the eeze_udev namespace is linux-only. this is made obvious by the _udev
namespace, and the intent is to provide faster alternatives for the
infantile linux-specific (at the time of writing eeze 1.0) technologies udisks
and upower. if support for other operating systems is added (READ: NOT BY ME),
this can easily be abstracted to an eeze_device namespace as I have already
planned.
> And what about volumes mounted in other different ways? I WANT my
> iphone to show up in E as it is in nautilus, I think it is mounted
> using fuse(or gvfs?)...what about that??
gvfs is broken by design in that it mounts devices specially in ~/.gvfs instead
of the FDO specified /media. nevertheless, eeze mount functionality will detect
such brokenness and allow you to transparently use such a mount; this is the
reason why libmount is used.
> 
> 
> 
> I don't want this email to become too huge so I leave for a future
> mail other details and the discussion about the efm itself...that need
> loooots of discussion and code for a proper e17 release.
most of the device code in efm is poorly implemented at a design level from
what I've been able to tell. it's clunky, easily broken, and based around
technology which has not been current for years (HAL). imo rewriting the entire
thing in time for e17 release is not an option - the amount of work required
would be tremendous. at the very least, I have absolutely zero interest in
working on it. if someone else wants to, however, I am always willing to
consult on device management.
> 
> bye
> 
> DaveMDS

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to