[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Evas & Evoak future changes
On 9/6/06, Jorge Luis Zapata Muga <firstname.lastname@example.org> wrote:
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 .
I don't think rephorm was advocating that no work happen on evas, but
that as far as developer resources, people should be encouraged to
work on the window manager and other higher level work.
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 with you on this. Some people simply have no interest in
working on the window manager but have a lot of interest in graphics,
widgets, or some other related subsystem.
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.
I think the most reasonable approach going forward would be to
complete the color space conversion to premul, then branch of stable
and development tracks. The stable branch would maintain a relatively
stable API until release in order to allow development the window
manager and other higher level API's. The development branch can
incorporate the various ideas you and Jose have proposed without
disrupting other development. Depending on when the development branch
reaches a usable point, discussion can move to deciding if it's
suitable for merging to stable and converting existing software to use
the API changes or if it should be worked on further for an evas 2.0