Re: [MiNT] XaAES Gradients

[Paul Wratt <paul.wratt@gmail.com>]

On Tue, Aug 10, 2010 at 5:13 AM, Jo Even Skarstein <joska@online.no> wrote:
> On 08/09/2010 01:58 PM, Paul Wratt wrote:
>
>>> This sounds like a real hack. Why go to all this trouble? it will only
>>> make it impossible for atleast 95% of all users to modify the gradients
>>> themselves.
>>>
>>> I have not studied how the gradients works in XaAES, but how complex can
>>> it be? A gradient consists of a starting colour, a finishing colour and
>>> a direction. That's it. It can easily be defined in xaaes.cnf if necessary.
>>>
>>> Jo Even
>>>
>> this is the point of why the gradients should added
>
> No, this is why they shouldn't at this stage. Configuration by
> copy/paste in source files is... well.. a hack.
>
So your saying that people should not be allows access to related
information because no one has implemented in code or a config loader?

If you are compiling yourself, then ANY changes you make are going to be a hack.

Besides I have already stated that I have an integrated patch, one
that does not require any C+P

>  If the gradients can be
> defined in xaaes.cnf (or perhaps a separate configuration file), you
> won't have to add any gradients at all.
>
whos gonna do this? (config reader)

does anyone who currently works on XaAES know how to eval() structs at
runtime from c source files (which is the fastest config parser in
this case)

> Something like this:
>
> default_gradient = {500,100,100,1000,500,500}
> v_slider_gradient = {1000,1000,1000,500,500,500}
> h_slider_gradient = {500,500,500,1000,1000,1000}
> button_gradient = {500,500,1000,500,500,500}
> form_background_gradient = button_gradient
>
> etc...
>
exactly 37 struct's are defined. each struct has 1 identical value on
creation, and 8 seperate values which change, and 2 values which are
arrays which change in size according to the render function used

this does not include a few struct that are still missing, or the
addition of other render algorithms/functions

this is NOT something I would put in the xaaes config, mostly because
it would become unusable for other people. Even you must admit that.

after looking at the mint config parser it became apparent that this
was not a viable option to use the .cnf format

> Quite crude, but this is just an example. The user defines the gradients
> in a configuration file, and XaAES generates the actual gradients.
>
> Jo Even
>
Why cant those user defined configs be exactly like the provided c files?

Unless you want to take default gradients out of XaAES, the c files
will always be useful

It also makes it easier to create a config tool (ie point and click
gui with interface preview)

so it just makes sense to add them, even if in the future they are not
used in exactly there current form

I dont know what the problems are with people on the list in relation
to textures and gradients, you've had like 7 years + to look into
this, soon as some else does all hell breaks loose, what gives?

Paul