Nathan writes:
> On 9/6/06, Jorge 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.
>
I raised some concerns related to this, but it was not
to imply that people should divert from e17 (or anything else)
and should begin working on evas instead.
> > 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.
That's certainly a natural thing, and allows for growth in
various areas that are needed.
If "e", in the large sense, is to really advance, then that
is of utmost importance.. a wm alone will not do it. In fact, I would
say that good gui-toolkit(s) and filemanager(s) are more important in
the long run.
> > 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 candidate.
>
There's really no issue here of api breakage. Some semantic
changes will be needed for premul, and we've discussed and agreed
on those already.
There are two separate but related aspects here that are
what Jorge, Cedric, and I referred to.
1) Evas 'internal' changes:
Many reasons for this that are purely internal issues.
2) Evas 'external' additions:
New capabilities, possibilities, etc.. The above 'internal'
changes make this far more doable. For me, it's actually pretty
much essential. In turn, this part can greatly affect the nature
of the above internal changes.
This part could mean more api functions, more libs, ...
But it's unlikely to mean "break some current set of api functions",
or at least I personally don't see that as needed.
Now, unfortunately, this discussion came up at a time when
people are busy with e17... in particular, the 'owner' of evas is
especially so.
So basically, either people proceed without him (with a
'branch' or whatever), or they can wait around, or they can let
things go..... Or they can discuss ideas, get feedback, etc.
I think this last was what Jorge was attempting to get
started.. good timing or not.. and I guess he hoped that at least
raster would have joined in (even if he did say that he was too
busy to do so).
I'd suggest maybe keep ideas in mind, let them develop,
see what one might need, etc.. until things quiet down a bit on
the release front.
jose.
-------------------------------------------------------------------------
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
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
