On Fri, 8 Sep 2006 08:15:38 -0500 [EMAIL PROTECTED] babbled:
> On Fri, Sep 08, 2006 at 09:40:08AM +, [EMAIL PROTECTED] wrote:
> > Now, unfortunately, this discussion came up at a time when
> > people are busy with e17... in particular, the 'owner' of evas is
> > especially so.
> >
> >
On Fri, Sep 08, 2006 at 09:40:08AM +, [EMAIL PROTECTED] wrote:
> 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
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
On Thursday, 07 September 2006, at 04:57:31 (+),
[EMAIL PROTECTED] wrote:
> just make it clear that when I 'criticize' evas' this or that, and
> whatnot.. it's not to criticize Carsten's work on evas - not by any
> means.
Criticism doesn't have to be negative; "constructive criticism" is
alwa
This is slightly 'off-topic' for this thread, but let me
just make it clear that when I 'criticize' evas' this or that, and
whatnot.. it's not to criticize Carsten's work on evas - not by any
means.
It's remarkable what he was able to do with this.. to design
it, and put it togethe
On 9/6/06, Jorge Luis Zapata Muga <[EMAIL PROTECTED]> 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
On 9/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>Jorge writes:
>
> > > I tell you what, let me look things over a bit during the
> > > weekend, and if you like you and maybe Jorge can do the same...
> > > maybe discuss it with others on the list who have some experience
> > > wi
On 9/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 06, 2006 at 03:22:39PM +, [EMAIL PROTECTED] 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?
>
On Wed, Sep 06, 2006 at 03:22:39PM +, [EMAIL PROTECTED] 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
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, bu
On Wed, Sep 06, 2006 at 07:34:48AM +, [EMAIL PROTECTED] wrote:
>
> It's going to be just about impossible to do this any other
> way than with a separate CVS version to work with.
>
A branch should work, right?
> To me the main issue is not really a 'technical' one pre se,
> it
Jorge writes:
> > I tell you what, let me look things over a bit during the
> > weekend, and if you like you and maybe Jorge can do the same...
> > maybe discuss it with others on the list who have some experience
> > with evas/objects/engines and we can take it up again on Mon
> > o
> indeed, a cvs dir to experiment with evas would be nice, maybe i can
> put it on proto?
or in another branch
Vincent
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with
>...
>
> I thought about getting back to this some time in the future,
> but if you and maybe Jorge ar willing to give this a try, then it may
> be better to go ahead and try and finish it off now -- it would be
> very useful in many other ways as well, especially since much of the
> image
>...
>
> This would be true on PC, but on embedded device you will really like the idea
> of using as much as possible the hardware. Preserving evas ability in this
> area is really something important in my opinion.
indeed, but there's a problem. evas manages internally always ARGB
data, so to ac
Cedric writes:
> > Many engines have some sort of native notion of a 'buffer'
> > that one can get/put data to, which they can composite to a
> > target surface.. eg. xrender has 'pictures', gl has at least
> > 'textures', etc.. and usually this compositing can be done with
> > some
On Friday 01 September 2006 08:02, [EMAIL PROTECTED] wrote:
> Jorge writes:
> >
> >
> ...
> Many engines have some sort of native notion of a 'buffer'
> that one can get/put data to, which they can composite to a target
> surface.. eg. xrender has 'pictures', gl has at least
Jorge writes:
>
>
>
> ok! now i understand what you mean on the first place, i totally
> agree with you.
>
> in the current evas in order to make a new engine you have to
> define all the current engine functions or at least inherit the
> software engine (almost all engines do
On 8/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>Jorge writes:
>
> > >So, the gfx parts of the engines (and some that are not
> > > directly gfx aspects) are really mostly a bunch of functions that
> > > apply to each object type, and some core functions that apply to
> > > a
Jorge writes:
> >So, the gfx parts of the engines (and some that are not
> > directly gfx aspects) are really mostly a bunch of functions that
> > apply to each object type, and some core functions that apply to
> > all object types, and some that apply to display-target aspects.
> > S
On 8/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>Jorge writes:
>
> But to export evas' internal structures, especially the engine
> funcs and such.. is really dangerous at this point in time, unless
> you're willing to freeze evas' capabilities, or just use this as a
> starting poin
Jorge writes:
> 1. reorder the headers:
> every subsystem has its own header, no more one huge header
> (Evas.h, evas_private.h, evas_common.h). as the main idea of this
> is to allow objects, loaders/savers, engines to be able to build
> outside evas, we need a way to export internal API. So
hi ppl,
this are my ideas i actually have implemented in a local version of
evas, i wont do a direct commit for everything i have, instead ill do
small commits to actually allow raster to read the commits and for
better understanding of what im doing. also evas has changed several
things in the pas
23 matches
Mail list logo
