Re: [E-devel] Conf dialogs... modules?!

[Brian M. <bri...@gm...>]

On Sun, Jul 08, 2007 at 01:40:37AM +0300, Hisham Mardam Bey wrote:
> On 7/7/07, Luchezar Petkov <luc...@gm...> 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 -----