I also suggest to have module categories, as we already use the module.desktop files for the icons, we should use it for the categories. This way we wouldn't have a long list, we instead have the modules more organised in category lists. It would be also cool to have the description directly in the module.desktop, this way the module doesn't need to get loaded for simply checking what the module does (with the about button).
Greets, Brian 'morlenxus' Miculcy On Sat, Jul 07, 2007 at 07:57:51PM -0500, Brian Mattern wrote: > 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). > > > > > 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. > > > 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. :) > > > > > 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). > > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
