On Sat, 7 Jul 2007 19:57:51 -0500 Brian Mattern <[EMAIL PROTECTED]> babbled:
> On Sun, Jul 08, 2007 at 01:40:37AM +0300, Hisham Mardam Bey wrote: > > On 7/7/07, Luchezar Petkov <[EMAIL PROTECTED]> wrote: > > > Raster, why the heck are you doing this? I don't like the idea (and its > > > not only me, of course)... At least explain us :-) > > > > > > > This is actually not a very bad idea, its actually a good move towards > > refactoring a lot of E's code and making it cleaner (if this continues > > with all the non-WM stuff in E that is). > > > > The only annoyance I can see here is having to load those modules > > yourself - which might be a bit of a problem to the clueless new user. > > I think they're on by default. Its just that there is no code to turn > them on for old configs (nor should there be). They indeed are. > > > > I personally do advocate the idea though. The more important thing is > > to continue on doing this. > > I agree. Pushing functionality into modules has a side effect of forcing > the interfaces to be abstracted and (hopefully) cleaner. Yup. also allows replacement by alternative versions for specific situations/purposes. > > E has become a BIG beast with a lot of > > features that are not required by a WM. What WM has so much > > configuration dialogs? X configs? Includes its own panels, > > mini-modules? File manager? > > > > After thinking about the state of E (the WM / desktop shell first, and > > the entire EFL second), I believe that this is exactly what we need. > > We need to do this for everything that does not belong to the core WM. > > Things need to be moved out of the main code base and refactored. > > > > I even believe that we need to do this sort of thing for the "desktop" > > itself. E draws its own desktop, completely ignoring X's root window. > > Ignoring the root window itself is not a problem, but I firmly believe > > that we need to move the entire "canvas desktop" idea outside E. Call > > it e_desktop or whatever. E, as a WM, should not have to draw this > > desktop, handle the clock, battery, ibar, etc. and the rest of the > > modules that load and draw on the desktop. By putting this into E, not > > only have we made it bigger and slower, we have also made it more > > error and crash prone. > > > > The e_desktop application could, if need be, open up the space for > > modules like the ones we currently have. There is no reason for them > > to be a part of E itself. Now one would argue that some of those > > modules do in fact need access to some of the info that E has (ibox, > > drop shadow, pager?) but I am sure that we can find a sane way to do > > this stuff as well (I have not given those modules any thought as of > > now). > > > > Another part of E that really needs to move outside its code base is > > EFM. EFM is growing and becoming a terrifying beast. Anyone that has > > tried to fix something or add something to it knows that (ask me, I > > spent two hours understanding its code trying to add a feature the > > other day). Not only does EFM have its own process now, it keeps on > > growing and growing, and it still has a good way to go. We need to > > move EFM outside E and turn it into a standalone proper file manager. > > At that point, E can *use* EFM for its file dialog needs, and having > > a file manager inside E as an excuse to needing a file selector / > > dialog for some internal things (background choosing, theme choosing > > etc) will no longer be a valid excuse to code a full fledged file > > manager inside E. > > Much of how the three components (wm, fm, desktop) interact would need > to be re-thought. The IPC interfaces would need a LOT of work. That > said, the filemanager already does the majority of its work in a helper > application. Anyway, I would like to hear from raster about the reasons > behind mashing all of this functionality into one monolithic process > before giving any more though to how it could be split up. :) E needs a file selector - one way or another. it is possible to put this into another process, but you pay a price in latency for starting it up just to select a file (and starting a process is not cheap). in the end everywhere you look selectors are built into widget sets. with e the core of the selector also happens to be an FM - notice selectors elsewhere (gtk, kde, windows etc.) become more and more like mini-filemanagers. for us they are actually already filemanagers. the functionality is used in many places (browsing wallpapers, themes etc.) the async loading of dir contents was a must for these as your list of items goes up in your wallpaper collection for example. again - fm wins. so adding the core of an fm into e is just so useful in so many places it may as well live in the core. we get a "desktop filemanager" for free in the end. anyway - as for config dialogs - it made sense as e needs to configure itself. doing this via ipc and 3rd party tools imho wasn't panning out very well. as for them not being modules - no mechanism at the time to make that happen. i'm not rewriting config dialogs - i am just moving where they live now. it's not a big deal. as for the desktop - simply put - desktop menus filemanager and dropshadows drives it to be inside the wm. if its a separate process it will NOT share the same image cache as the wm - this means if you use the same image/icon multiple times across multiple "apps" it is loaded multiple times. we have no shared cache mechanism between processes. putting dropshadows in a separate process would lead to greater latency in updating them (and thus worse visual artifacts on redraw), would mean the separate process needs to also do round-trips to x to query the shape rect list etc. etc. etc. etc. performance and ease of adding into e (changing wallpaper on desktop flip etc. etc.) made this living inside e (to me) the better option. also i didn't envisage "modules" being complex apps- simple things like battery meters etc. which are hard to make crash as they are so simple are all we need in e - other complex things should go outside as apps. they could use an e module as a way of doing "systray" like functionality if they wanted - but only a very small minimal component lives inside the wm as a module. in many ways the module interface is being abused and not used with care and the way i had intended. > > Another component that should also be removed from E itself (maybe > > even completely deleted and replaced with an already existing library, > > or appended to that library) is e_thumb. e_thumb has no place inside E > > itself. We have Epsilon, a perfectly working library that can work > > both in "library mode" and in IPC mode as a service. If Epsilon has > > given some of us some trouble then we should fix it and use it instead > > of implementing a thumbnailer in E itself. > > > > I never did understand why epsilon was ignored. I know this was brought > up at least on IRC years ago. The 'no deps' requirement here just > resulted in much of the code in epsilon being rewritten inside e. > > I'll leave the rest of this email for later (gotta run). mainly because 1. it was simple to add to e17 for a very low cost in code. 2. epsilon required imlib2. i didn't want to bring imlib2 in - it's mostly on maintenance these days. 3. limit deps. epsilon can be put in - there is a nice abstraction for this so it can be slid underneath, but epsilon would need some work. > rephorm. > > > ----- End forwarded message ----- > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
