Re: [E-devel] edje and event objects

[Jose O G. <jos...@ju...>]

On Sat, 17 Sep 2005 13:10:27 +0900 Carsten writes:
> On Fri, 16 Sep 2005 05:28:38 -0400 Jose O Gonzalez 
> <jos...@ju...> babbled:
> 
> > 	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 :)
> 

	It would be very useful, for many reasons.. But no, it's not
really needed at this time :)


> > 	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.
> 

	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.

	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.


> > 	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?

	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!


> > > > 	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.
> > > > 
>