On Sun, 8 Jul 2007 01:40:37 +0300 "Hisham Mardam Bey" <[EMAIL PROTECTED]> babbled:
> 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. well yes and no. i don't intend to split out the desktop as a separate process - the fact that people use modules just to write apps is very silly - also the fact that modules may be of incredibly poor quality is a problem we should solve by simply disabling the build of modules deemed "problematic". the desktop itself it used by e for dropshadows, wallpaper, changing it when flipping desktops - and more. in fact when becoming a composite manager one day it will be useful to keep it. BUT... you are right - we should split things up a bit and modularise. The config dialogs are really useful - BUT they aren't needed 100% for core functionality. The only thing you NEED is the module config dialog. Secondly- you are seeing the pain of config dialogs going away because you already have a config. If you were a new user now you would have these new config dialog modules enabled by default - I added them to the default config. For you there is a transition where they are being added and need enabling. I don't really worry about that as you know what to do. :) In the end there is a release to worry about and will things be OK for a fresh install at release (and at release we likely will enforce a fresh install even on existing users - or at least prompt to have it wiped and re-done). But why am I doing this? Well... the Dialogs have a habit of growing. They even grow to the point where they don't fit on small screens anymore. Try E on 320x240? 640x480? (it works in 640x480 but only with the default small font - now put that on a 2.6" LCD and make it 480x640 - or 800x480 on a 3" LCD etc.) This will make it POSSIBLE to replace config dialogs with new versions that work better at low res or simplify config as not all of it is needed for a specific target etc. (eg mouse-bindings is pretty useless on a touchscreen with no keyboard - as is keybindings for starters). I put e on my n800 recently - it runs out of the box - quite fine. but it is a desktop wm stuck on a tiny screen with limited inputs. a few re-shufflings like this and it is POSSIBLE to do much more in a clean and ordered way. We can't put everything in modules - or separate processes (well not without paying a price of some sort). e_fm is big mostly because of the fm widget. not surprising. that will stay in e itself, BUT the e_fwin (filemanager window) could move outside into a module - as the code that puts e_fwin on the desktop too - into a module, allowing different fielmanagers to be built - they can hook to different back-ends or widgets, or just impose different fm window policies and designs. but the main point is to make it POSSIBLE. allowing a module to extend the config dialog was a todo item for a long time. now its possible - and i'm running with the ball having e have its own modules extend the config dialog the way any other module can now! it's also nice and simple to do. ;) there is basically NO down-side for users (beyond an adjustment phase now for existing users having to go add these modules). There is only upside. -- ------------- 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
