Additional to the categories it would be great to (de)activate all modules in a category with "one" click. So the category should get the same checkboxes like the modules have right now. Maybe a advanced dialog could be useful to separate user-modules (tclock, cpu, ...) from system-modules (borders, stacking, ...)
2007/7/9, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>: > > On Sun, 8 Jul 2007 10:39:28 +0200 Brian 'morlenxus' Miculcy < > [EMAIL PROTECTED]> > babbled: > > > 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). > > agreed. though adding this now doesn't buy us much in terms of > functionality. > people wont be fiddling with their modules on a daily basis... :) > > > 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 > > > [email protected] > > > 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 > > [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 > ------------------------------------------------------------------------- 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
