On Fri, 16 Sep 2005 16:18:50 +0900 Carsten writes:
> On Fri, 16 Sep 2005 01:44:42 -0400 Jose O Gonzalez
> <[EMAIL PROTECTED]> babbled:
>
> > Let me sharply critical here.
> >
> > Unfortunately for many other libs and apps, if evas is the
> > graphics engine they use, it's important to get it more than just
> > "good enough" -- as they will later find themselves stuck in the
> > situation where what was good enough earlier is not quite good
> > enough anymore.. What then?
>
> 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.
> > There are general patterns here, going beyond anything to
> > do with evas in particular, that lead to such things recurring
> > again and again... hampering the potential growth and development
> > of "e" in the larger sense.
>
> a lot of them can be changed internally at this stage and
> hidden/wrapped by
> ecore_evas (ie if we move event handling to an explicit process
> call). so only
> those doing their own display target bindings are affected (very
> few). for
> smart objects i think we cna do this all internally with no api-side
> effects so
> we can do this at any time in the future :) i actually wouldnt mind
> getting
> 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.
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?
Then, what is the event-model? And where does it come from?
Sure we can "fix" smart-objects in evas.. But, why? What is
it that you really want that smart-objects gave you initially?
> > 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!
> > 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...
> > 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
