On Mon, 9 Jan 2012 22:43:12 +0100 Davide Andreoli <d...@gurumeditation.it> said:
dave! :) > 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 !!! " well.. not SO fast. mmost features are now done - kbd layout left, multi-head randr dialog needs some love (merge with resolution settings too) and other than that lots of fixing of things... efm and many other things. polish and fix. :) > About fixing the Places module: to be honest... anything in e-modules-extra is "out of scope" for release. :) > 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. > 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... now that sounds sensible. as such efm already has "places" (.desktop files that can link to devices or specific parts of the filesystem). the real question is what other bits do u want? did you want something that displays dusk usage (75% full eg), something to display activity? (poll /sys/... stuff and match up to devices) etc. - then this could be aded to efm with fairly little effort. > 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 this behaviour though is more correct. the idea of mounting the moment you plug in is not very smart - and having to manually say "eject" or "unmount" is not very good. closing the last visible window for the device can implicitly unmount without the user needing to know or care. the real issue here is the linux/unix way of doing a filesystem. the fact that it can cache vast amounts of data in ram and not be on disk presents a big problem for removable media. reality is we should unmount as soon as we can to force changes to be written. for efm this is when you close the device window. (unmounting will fail if files are in use though - you CAN manually ask to unmount/eject too. its there in the right-click menu on the device icon. :) > module, as is it's main purpose is to provide the unmount/eject icon. rather superfluous as efm already provides that.. (though here someone managed to make desktop icons for devices stop working.. and for my phone at least the label in the fm device list menu is empty... :( need to investigate/fix). > 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? it will try and unmount and due to file being in use.. it will fail and it will stay mounted. you can manually unmount as above. > I really think e should behave as all the other OSs does, mount on > first use and unmount/eject on request. here i disagree, as THIS can lead much more easily to data loss and corruption. > 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. well it was working in efm. > * the EEZE backend needs libmount (hard to get) and seems also not > 100% functional. ok > * the UDEV backand is unselectable in the configure step, at least if > you have hal installed. hal code hasnt change in.. like.. forever, so this should still work. > 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 > doesn't work, e always force me to use the hal one. Also the options > seems wrong, we have: actually e should use hal if hal is there. eeze and udev are for when hal is deprecated - no longer there and functioning, so that's right. > --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? > > > 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? > 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?? this has nothing to do with eeze. this is fuse stuff. we have no support for fuse atm. no one has done any work on it. frankly we should have it for things like samba (cifs) and network file sharing. i have noi idea what iphone does, but most phones i know of do usb storage so its really seems like a thumbdrive. beats me what apple does. but frankly - that's a lot of work to start doing all the fuse stuff, network browsing, mounting etc... we used to have a perfectly working hal supoprt layer and then the rest of the linux world decided to kill it (though its still floating around and replacements are not "there yet") and leave us with having to try support 2 things. we have enough mess to fix here without worrying about fuse and friends. :) > 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. > > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
