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