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 personally do advocate the idea though. The more important thing is to continue on doing this. 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. 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. There might be other things that other developers can think of in regard to this issue, but the main point here is, we should not be afraid of cleaning up our mess and creating quality libraries and applications that we all reuse instead of going about things in this way, specially when it comes to our star product, E. The closer E has come to a release, the messier it has gotten. For example, Efreet was written, it worked well, it wasnt 100% complete, but it got used by E because it made sense. We added a dependency, we reused good code, and we did a good job. If that is the case, why do we not do the same with every other component we have? Why should E be 6 million lines of code all in one application when it can be cleaned up and divided into several reusable modules? What if you want to run e_desktop with metacity or fluxbox? Why cant that be possible? Or use some other desktop with EFM? That should all be possible. Packaging everything into one big solution is not the proper way to do this. Perhaps, yes, we will lose some more time, but does that really matter to us now? We've been working on this since around 1999/2000 and we dont have a release yet, so an extra 6 months on our release date is not going to affect anyone. I know that a lot of developers are starting to feel frustrated because of what is going on, and I totally understand where they are coming from. We cant simply keep writing code, each on his own. We need to share, and work as a community to get quality code and a quality application that people can rely on and use, and one that developers feel good about and can learn from and extend if need be. This entire subject of redoing everything all the time, not adding dependencies, and closing ourselves off from the world and other projects is not going to make anything any better nor is it going to give us the exposure and user base that other similar projects have. Lets get into gear and get this show on the road, properly. Regards, hisham. -- Hisham Mardam Bey http://hisham.cc/ +9613609386 Codito Ergo Sum (I Code Therefore I Am) ------------------------------------------------------------------------- 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
