On Sat, 17 Sep 2005 04:24:29 -0400 Jose O Gonzalez <[EMAIL PROTECTED]> babbled:
> Ecore-evas' "buffer" based sub-canvas is 'flawed' in several > respects: > 1. It forces one to use the software engine, like it or not, > and with modular based engines that means loading that engine. > 2. It's an inefficient use of buffering as a means to achieve > 'sub-canvas' like capabilities. This can be done far more efficiently > internally by fitting the sub-canvas 'buffer' to the parent engine > type. > 3. It could potentially introduce disimilar rendering results, > or even 'features' that one engine might not support (but the software > engine does, say) -- one would prefer that the parent canvas rendering > and the sub-canvas rendering would match. but its good because u have a canvas whose pixels u can directly access, save to disk or do something with (read-only). its nto intended as a end-all solution to sub-canvases. but it is currently A solution. > There are a few other reasons why this is less than optimal > or desirable.. > > But no, that's not what I meant here. > > There are many canvas 'models' in the object types they > support and the event model they (may) use: > > The most common seems to be a canvas of various graphical > "primitives" (lines, rects, etc), and often the evnt-model is > relegated to whatever event model the underlying target surface > may support. > > There is what we might call the w3's "svg" canvas model. > This has one object type, the svg-document (or document fragment), > and the event-model contains (among others) things like tracking > changes in the document's structure.. > > There is "edje" - this is easily seen as a canvas with, > again, only one object type, and 'edje' (which, like the svg- > doc, is also an object loaded from from some structured file- > based format). The event-model here is somewhat different from > evas' own, and has things like named messages.. > > There others... and indeed we may even think of "ewl" > as a canvas. indeed - it isnt "the same everywhere" its a problem - but its also due to each system being specific for a particular task. > > > 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. :) > > > > You don't have to tell me that part of it :) > > But, again, that's not what the question is intended to > address. > > Why do you have to have smart-objects? because makign evas istelf govern the policy of "if u move 1 object how do u move a group of them) and resize is stupid. that level of complex high-level policy shoudl be exportable to "smart objects" they have been overloaded a lot of late though :) > What is it that you want them to give you? An "edje" lib? > There are better ways of getting that.. > > > > > > > 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 :) > > > > You got me there :) I will most definitely not argue with > that one :) :) > > > > > > > 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). > > > > Shame on you for taking such a cheap way out that one :) > Truly shameful :) > > But hey, everyone knows that real men don't use *any* libs > to write their code - think of how much easier and quicker you'd > have had e17 done if you hadn't had to waste so much time writing > all those pesky libs! seriously though - there is a bigger picture at stake and it RELIES on use getting e17 out the door - with perfect libs or not. > > > > > 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. > > > > > > > > > > > ------------------------------------------------------- > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
