> > > In the meantime, evas grads could also be enhanced in
> > > various ways. Here are some that I would like to add sometime
> > > soon:
> > > 1. Loading grads from a file - ie. support for whatever
> > > file formats may exist, or may be defined, for describing
> > > types and/or spectrums for gradients.
> > > .....
> > > .....
> > >
> > > If anyone has any suggestions/comments/ideas, or whatnot,
> > > related to 'gradients'... :)
> >
> > I think inkscape, gimp, and a few others have been working on
> > standards to allow dragging and dropping things like gradients
> > between their applications, so have a look at the work they are
> > doing.
>
> like ".grd" files that can describe a gradient? :)
>
Yes, both 'drag&drop' and 'thumb-nailing' functionality
would be something that could be done with gradient file formats.
It should be possible in eg. a file-manager view, for one
to d&d some grad file and be asked wether to move/copy/... *or*
set that as the bg.. etc. :)
There are many things that one could include in a file
format that could "specify" a 'gradient' -- eg. does one want to
include wether it's a 'radial' gradient.. or other such info.
At its core though, a gradient needs a 1-dimen spectrum
(multi-gradients need a 2-dimen spectrum), which we may think of
as a mapping s: [0,1] --> SomeColorSpace, and let's just restrict
the color space to ARGB32 say.
Clearly there are multitudes such, but common ones are
simple:
1. Given some ARGB32 data[len], with len > 1, we can
define a spectrum s by:
For 0.0 <= f <= 1.0, s(f) = data[f*(len - 1)];
There are 'smoother' ways of doing this, but it gives the basic
idea.
2. Given a sequence of pairs (col[i], r[i]), 0 <= i <= n,
where the col[i] are ARBG32 colors, and the r[i] are in [0,1] and
satisfy
a) r[0] = 0.0, r[n] = 1.0
b) i < j implies r[i] < r[j]
We can then define a spectrum s by:
For s(0.0) = col[0], s(1.0) = col[n], and for 0.0 < f < 1.0,
let j be the max i with r[i] <= f, and set s(f) to be the linear
interpolation from col[j] to col[j+1], at f,
ie. s(f) = ((r[j+1] - f)*col[j] + (f - r[j])*col[j+1]) /
(r[j+1] - r[j])
Most definitions that require one to generate the spectrum,
eg. evas' 'color_add' api, gimp's .grd format, svg grad 'stops',...
essentially reduce to 2 above (modulo wether the interpolation is
to be linear or some other).
Even 1 above is a particular case of 2, with n = len - 1,
col[i] = data[i], and r[i] = 1.0/i, and we use for 'interpolation'
a sampling method...
Now, one doesn't necessarily compute things this way, but
the point is that at its core we can import most anybody's spectrum
descriptions.
We can easily support gimp's '.grd' gradient files (modulo
funky interpolation methods they like to have for each 'segment'),
and also svg-doc gradient fragments as well.
So the question for evas is really one of "how much of a
given format's specifics should we also import..?" (it would be good
to know exactly what are the known grad related file formats)
I believe that evas should only import the spectrum
(possibly also basic aspects like the color space), all other
'higher level' attributes should be left free for the grad api
to modify (ie. things like the 'type', the 'spread', the 'fill',
the 'jump and wriggle this or that way...', etc).
We also want to have eet based descriptions - both stand-
alone and as part of an edje file..
Thus, secondary questions are - what would be a good format
to use in eet files for spectra defns, and what would be a good
format for edje gradients that could refer to the former...?
Suggestions are welcome :)
> > > like ".grd" files that can describe a gradient? :)
> > >
> > I'm not sure of the details, this is recent work and someone
> > gave a talk about it at my local users group a few weeks ago.
> >
> aaah - but i assume there is some "file format" involved.
> i do hope its not some xml mojo again...
Man, it's ALL mojo!
Syntax is syntax.. :) What less mojo is there in bash/
smash/perl/shell scripts, or in the autotools/auto-confusing
macro-wonderland, or this or that format/language/api/whatever...
To me, the greatest mojo of all is having dozens of them,
each with their own wonderful [EMAIL PROTECTED]<<uT;&if34+=???.???..?????
Programmers are the masters of mojo it seems.. You ought
to embrace and extend them all with equal love and affection :) :)
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid7521&bid$8729&dat1642
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
