On Fri, 16 Sep 2005 05:28:38 -0400 Jose O Gonzalez <[EMAIL PROTECTED]> babbled:
> > true. but given that i only have a few hrs a week to do this stuff. > > what do i > > work on? e is a priority. likely above evas in priority right now. > > > I know.. But it's not just evas I'm trying to point to here. i know there's more too. that just exascerbates the same issue :) > > right of the smart class creator that accepts like 10 args forall > > the methods, > > but instead use the one that accepts the smart as a struct - we can > > then expand > > that strucxt until the cows come home. it's alreayd there, just not > > used. > > > Ok. Let's talk about canvas/gfx specific issues a bit. > > Two key elements: rendering and event-handling. But how do > we deal with them and integrate them - what's the model? And what > can we 'use' to do this? > > We need an immediate-mode rendering engine.. let's get it > out of the canvas so it can be accessed itself. do we NEED it exposed at this stage? NEED is the wordd. yes it'd be NICE, but do we NEED to expose it. can ADD this as a feature later and EXPOSE it later on. ? i think we can :) > This needs a variety of other things.. including things like > dealing with image loading, font loading, and others. It needs > file-handling routines, string-handling routines, caching mechanisms, > etc.. Where do they come from? > > We need a retained-mode canvas model.. What is it? There are > many 'canvases' one can have, as I pointed out to you in some emails.. > Which objects with what apis does one settle on? Why? the canvas as such already is retained-mode as all object retain their state. if you literally mean rendering to sub-canvases ecore_evas offers a buffer canvas that returns an evas object that it renders to and accepts events on like a child object. > Then, what is the event-model? And where does it come from? same event module if its a sub-canvas as above (buffer engine) :) > Sure we can "fix" smart-objects in evas.. But, why? What is > it that you really want that smart-objects gave you initially? because they are a bit ugly internally. it will simplify the code a lot and make it easier to build on in the future. :) > > > If "e" aims to be a "gui platform" of some sort, say eg. > > > a "desktop shell", then it needs to take a serious look at its > > > foundations.. its subsystems... > > > > indeed - if i had the time i'd be devoting it there. :) > > > That is where you are needed most man! i'm needed everywhere :) > > > It needs to build these, and build from these, in a > > > systematic and coherent manner... and it needs to support > > > and facilitate all the 'standards' that people expect to have > > > these days. > > > > > > Unless this is done, e will never scale much besides > > > constituting a handful of very nice special-purpose programs > > > like a window manager, a graphical terminal, a login manager, > > > ... programs that, sooner rather than later, 'others' will be > > > able to duplicate in "coolness", and do so within the context > > > of a much more comprehensive framework. > > > > agreed, but the programs si what peolpe seem to be wanting and > > pining for. > > personalyl me too. peoelp are waiting for them. wanting them. its a > > 2 way > > street. u cant go make a set of libs and never have anything USE > > them. i agree > > we need to do things. i woudl be doing them mystelf - but i don't > > have time. > > i'm hoping others can get a firm grip on what to do int he meantime > > until i > > come back to it. > > > They won't unless the 'core' e-developers come together > and discuss design decisions, aims, etc. And you need to lead > them there... i actually think we have a lot of this workign very well already. whan we need is more good peolpe with TIME to devote to it sitting down actually doing code - making things happen. talking about things can be done endlessly in circles - if no one gets up and DOES something as a result of talking, then it's rather moot to talk. we DO talk - like here, now :) but i'm basically saying "it's not going on MY todo list for now. it's got a lot of stuff ahead of it in the priority queue" the important stuff is rto make sute the api can be expanded without breaking it in the future. some things need to be put off (at last off my own todo list) until others have been done. i have placed e17 (itself) at the top notch of my priority queue. i only do things directly related to it getting done (sanely) outside of it. of course if everyone else things we should abandon e17 and just go back to working on libs for a few years... ? who's voting for that? (looking for hands going up). > > > E will lead the way, in various gui related ideas, thanks > > > mostly to the tremendous creative talents and skill of a certain > > > nameless individual.. but it will never keep that lead for long, > > > or be able to capitalize on it. > > > > > > Jose. > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
