[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Evas & Evoak future changes

On 9/6/06, brian.mattern@gmail.com <brian.mattern@gmail.com> wrote:
On Wed, Sep 06, 2006 at 03:22:39PM +0000, jose_ogp@juno.com wrote:
>    Brian writes:
> > >   To me the main issue is not really a 'technical' one pre se,
> > > it's do people really want, and want to help with, such changes?
> > >
> >
> > Right now, I think the response you're going to get from most of
> > us is: "Wait until e17 is out the door." Evas may have issues, but,
> > our main focus at this time is getting a long awaited product
> > released and in the wild.
> >
> > However, this does mean that Evas will also be "in the wild",
> > making drastic API changes more painful on end users of the
> > library. So, maybe we should prioritize the changes (premul
> > seems a higher up candidate).
> >
>       The only api 'change' that I know of anyone having in mind
> is the change to premul semantics. But as far as large or radical
> api changes, evas has already had some.. eg. the textblock.
>       Part of the benefit of having loadable object types is to
> minimize the need for such things happening. But mostly it's to
> provide a better base on which to build - to build apps, not to
> fiddle with the lib for the hell of it. If people don't understand
> this then I don't know what to tell you.

I realize this. I never said anything about "lib fiddling" :)
I totally agree that evas needs some work. I would love true loadable
objects with a well defined interface so we can more easily extend
things. All I'm saying is that we have very little dev power to divy up
between everything that needs doing.

> > I just don't think that we should take what little dev time we
> > have and suck it into overhauling evas (which, unfortunately,
> > is 'good enough' for our current purposes).
>       Then it's likely not going to happen and will thus stay
> 'good enough' until deemed otherwise. A concensus needs to be
> reached on what needs work and what doesn't.. it can't be carried
> or be decided on by one person alone, wether it be me or Carsten
> or whomever.. Some things can be done here and there, but major
> work needs more than that.

I think we need to get e17 out, and THEN bump this up to top priority.
(With the exception of pre-mul, which, due to the API shift, should
probably be done before any evas release). However, that said, we're a
pretty unguided mass of transient coders, with different goals and
desires. Maybe its just my lack of familiarity with evas internals that
forms my opinion. :)

well i dont totally agree, i mean, i started this discussion with some
ideas i would like to have implemented on evas, i guess jose thinks
the same. so this thread is to actually THINK and WRITE what are the
future goals of evas (that's why the topic is called like that). and
looks like im not the only one with some evas' ideas .

if e17 is a priority i agree but im not actually coding it, instead i
would like to settle down the base of what will be the next evas. what
other opinions can we receive but yours? (developers and evas users).
so if this ends to be actually a branch ill be glad to code it, e17
will still use current evas branch and everyone happy :) we can code
in parallel. might be double effort to then merge both branches, but
that's why branches are for :)

i agree when you say that evas is "good enough" for the libs/apps we
have. but if would like to actually be able to code more fancy/good
stuff evas has to evolve, and must evolve from an evas developer point
of view (possibility to extend evas functionality)

basically i think evas api wont change too much, the premul color
thing will end up with another layer between the colors used on edje
and the current colors used (current color space -> premul), what we
are looking for is an evas internal refactoring.


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
enlightenment-devel mailing list