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.
So
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
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
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
or Tues,
On Wed, Sep 06, 2006 at 07:34:48AM +, [EMAIL PROTECTED] wrote:
snip
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,
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
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 from most of
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?
Right
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
with
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
always
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
...
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
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 that),
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
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 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
all object types,
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.
So, the
On 8/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Jorge writes:
snip
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 point
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 for
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
20 matches
Mail list logo
