From: Essien I. E. <es...@wa...> - 2006-08-09 12:02:51
|
I've begun looking at laying the initial groundwork for the Entrance GUI config/control center. To do this, I can either choose etk or ewl or (ewww!!! build yet another e toolkit (YAET!), I'm too lazy to do that anyways). This is probably going to generate a lot of comment anyways, so I may as well just go straight to the point! :) The point is that there is yet a third option apart from etk and ewl... that is the micro-toolkit used inside of E itself. Apparently, this toolkit is geared exactly for this kind of work, whipping up configuration dialogs, etc... its small its simple, its easy, almost everyone who's written a module/gadget has used it already. I too would love to use it for Entrance, as it will keep all configuration info for E looking unified as opposed to frankenstein'd. What I've been mulling over since about 4.30am (during REM sleep - if you believe that ;) ), is the possibility of pulling out the internal e widgets and their neccessary support infrastructure out of E itself, into... yup... you saw it coming... tada!!! ecore_config_tk or something similar. E already depends on Ecore, so no new dependency will be dragged in, and Entrance will just grab this and use. That will mean that once you have the big 5 (eet, evas, ecore, edje, embryo), you can still install Entrance. Moreover, I think it will allow the micro toolkit to properly shake itself free and clean. right now, its kinda difficult to see it clearly, since its part of e, but when its an ecore subsystem, it will be easier to see thru it (ok... that's just a secondary benefit.. really a sales pitch). The main point though is this... I'm still going to be borrowing code from E internal widgets anyways... should we (Peter Parkanyi is working with me on the config thingy), go ahead to start making them E-widgets an ecore subsystem? We're setting up ourselves with just a couple of weeks ahead of us to get things up to *snuff* so we'll need to move ASAP. Cheers, Essien |