XaAES skinning

[Faucon2001]

Hi,

I have been dwelling into skinning XaAES and .... it's a pain in the ass

Firstly, 32 bits img files are a real nightmare : the only application that writes "more or less" this format, and it is not consistent, is SMURF.
I have not managed to get a positive result with Pixart.
So edition under Pixart, conversion with SMURF works some time.
Secondly, the way GEM use different surfaces for the skin is quite limiting, especially for the background "EXTERIOR.IMG": as a result vertical gradients on widgets don't look good. I have not been able to set the unselect background UXTERIOR.IMG neither.

The wiki is very light on skinning and I have read almost everything still available from Paul Wratt. Where can I find more info ?
So far I have reached this first result as a skin for Linear Blue icon set ; I am satisfied but there is still a lot of things to do and I am reaching a dead end.
How to make the vertical background different ? Is there a way to change windows font to white without the shade effect ?
What soft do you recommend ?

Thanks,

[helmut]

It's been a while since I've dealt with the gradient-things (and never really understood it all I think).

I remember that some sort (might be vertical) needs a lot (too much) memory, I started to optimize it a little, but lost interest.

You can create your own gradients if you have a C-Compiler. Maybe a setup I once made can help:

http://home.arcor.de/zabruder/atari/xgt.zip

I think the documentation is german though, maybe it contains AHCC, don't know.
I suppose you made gradients already, so you compiled gradient-source? Or are that img-files (that would be textures not gradients)?

-Helmut

[Faucon2001]

It is textures and not gradient. That's why I have issues with vertical and especially windows background texture.
I am going to have a look a your archive but I believe I already tried to use it.
As I don't understand German (even with google translate it does not help) and I am not skilled in C, I have not been able to make it compile.
If you could help me, I will appreciate.

[helmut]

Ok, here's my english version naturally translated and expanded:

Creating gradient-files

You need: ahcc (in C:\DEVTOOLS, otherwise change AHCCROOT in the
Makefile), toswin2, bash or another shell, unzip and an editor (e.g.
qed).

In toswin you:

1. unzip xgt anywhere, say /usr/src.

2. Copy one of the c-files (e.g. n_blue.c) to your new c-file:

cp n_blue.c n_new.c (Return)

3. Load n_new.c in your editor: qed -> Open -> n_new.c

4. In toswin:
In case you dont have a login-shell: Start TOS programm ->/usr/src/xgt/src/bash.tos (Return)

5. If AHCC is not C:\DEVTOOLS; Load /usr/src/xgt/src/Makefile in qed and
change AHCCROOT.

6. Load n_new.c in your editor,

6a. change some parameters and save (not quit).

7. In toswin (/usr/src/xgt/src):

./mkgrd n_new (Return)

or ./mkgrdcf n_new (for Coldfire ?)

in bash you can type Ctrl-P for history, and Ctrl-F, Ctrl-B for cursor.

The newly created gradient-file should be used by XaAES immediately.

8. back to 6a. or done.

PS: If you already have a login-shell or make you don't need the ones
from the archive.

It would also work with gcc or pure-c, but in this case the Makefile
(CC) would need to be changed.

All files should have unix-line-endings.

I think he main-issue would be to get the compiler installed, but that should be easy.
If you are on ext2: Be sure that mkgrd, bash and make are executable: chmod +x ... (I guess they are not in my zip-file, seems to come from a FAT-drive).

Beware: Only Paul Wratt knows what the numbers mean, but I can say they are RGB-values (0..1000).
So it's 100% trial and 98% error

One more: I don't know what happens if you have gradients and textures for the same objects, so I would disable textures for those that you want to have gradients for (rename the files?). And set gradients=1 in xaaes.cnf.

-Helmut

[Faucon2001]

Thanks Helmut for the traduction and explanation.
I'll give a try.

[Faucon2001]

Thanks Helmut, it works great

Values for (0...1000) are RGB values : confirmed.

For the others variables, looking at gradients.h it seems that :
1 and 2 : orientation of the gradient : -1,0 vertical, 0,-1 horizontal
3 and 4 : width and height of the gradient (16 pixels for title and sliders)
5,6 and 7 : method (seems to be different based on the type of object), n_steps, steps (not sure of what it is, may be different steps of color in the gradient, up to 8 steps for non linear gradients?)
8 : RGB values from 0 to 1000 for the beginning color and end color of gradient for each step.

Changing the RGB values works correctly ; I will play with other variables this week end.
Regarding gradients or texture, it's one or the other, you can't use both.

[helmut]

Great that someone tries it. I guess we could need some more fancy gradients for XaAES. If you find something comparable to your screenshot it would be even better.

If you think the c-source needs more explanation, maybe you can carefully add comments (inside /* */)?

From viewing at the source I guess n_steps says how many values steps has, if n_steps is -1, the gradient is disabled. steps is only used in methods 3 (horizontal?) and 4 (vertical?). With that you can define the strengths (or "speed") of the n_steps sub-gradients (smaller step is faster, the final RGB for this sub-gradient is reached earlier). step<0 gives -step*(width or height)/100, else the plain value. You need n_steps+2 RGB-triples (first, n_steps middle, last). Otherwise XaAES may crash, if I remember correctly.

-Helmut

[Faucon2001]

Finally, I did my first gradient for Linear blue icon set



As far as I have understood the values :
Most of the object name are pretty logical to guess but I have not yet found what BOX-GRADIENT2 is for .
1 and 2 : mask of the gradient : -1,0 vertical, 0,-1 horizontal, -1,-1 both
3 and 4 : width and height of the gradient in pixel
5 method : 0 vertical, 1 horizontal, 2 diagonal, 3 and 4 step related (not fully tested yet)
6 n_steps : number of steps of the gradient (no tested yet). In this case -1 would mean no gradient or plain color, 0 2 colors gradient, >1 multi colors gradients
7 Speed of the gradient (not tested yet)
8 : RGB values from 0 to 1000 for the beginning color and end color of gradient for each step. {{400,400,400},{600,600,600}} will give a flat gradient, {{600,600,600},{400,400,400}} will give a kind of 3D rounded gradient.

I am going to continue to play with steps now. I believe we can achieve nice effects with it.

[jfl]

Hi Philippe. I haven't tried your gradient yet but it's great that you're playing with this. But I wanted to ask: on that screenshot, how do you make the Taskbar menu display there?

[Faucon2001]

I use Tera desktop.
In "Set Application", install taskbar, choose "Special Use" "right button extension".
With that, right click will launch taskbar menu.
That's a very cool feature indeed.

[jfl]

I use Tera desktop.
In "Set Application", install taskbar, choose "Special Use" "right button extension".
With that, right click will launch taskbar menu.
That's a very cool feature indeed.

Thanks.I had forgotten about that feature.I will try it.

[Faucon2001]

Ok, I have played with steps and reached to that conclusion :

1 and 2 : mask of the gradient : -1,0 vertical, 0,-1 horizontal, -1,-1 both
3 and 4 : width and height of the gradient in pixel
5 method : 0 vertical, 1 horizontal, 2 diagonal, 3 vertical with step, 4 horizontal with step
6 n_steps : number of steps of the gradient. -1, no gradient or plain color (only the first of the two RGB triplet is taken), 0, 2 colors gradient, 1, three colors gradient (you need 3 RGB triplets : Beginning, Step, End), >1 doesn't seem to work?
7 : position of the step in pixel if the value is positive or in % of the size if negative.ex : {8,0} at 8 pixels from the beginning, {-50,0} step at 50% of the height
8 : RGB values from 0 to 1000 for the beginning color and end color of gradient for each step. {{400,400,400},{600,600,600}} will give a flat appearance, {{600,600,600},{400,400,400}} will give a kind of 3D rounded gradient.

[helmut]

I guess I like that gradient, didn't know what's possible. I would appreciate it if you could do more of this. Later the sources could be committed to the freemint-CVS if you don't mind?

But what do you mean by "flat appearance"? When I have a change from {400,400,400} to {600,600,600} then that's not flat?

BOX_GRADIENT2 is for big boxes (esp. screen-background) to decide it from the smaller boxes used in dialogs etc.

I'll look at the n_steps>1-issue.

-Helmut

[Faucon2001]

I have done an other one, this time full blue with the assorted widgets and the source



Flat may be not the best description, it's an optical perception of the gradient which in one case seems rounded and in the other not.
I guess it's coming from the color of the frame (gray at the bottom and right, white on top and left) which gives this "rounded" effect if the lighter color of the gradient is located on the top and on the left side of each object. Look at the picture bellow you will see what I mean. It's not an issue, just an observation.


Yes you can distribute them in freemint-CVS, it's an honor for me to contribute

I have noticed a strange behavior of the windows widget : up and left arrows do not switch to selected state when clicked on whereas the others yes, even though they are defined in the rsc. Is it a bug?
Do you know if it's possible to change the color of the windows title / info and top menu font? I would like to do a black gradient and therefore I need the top menu font and info bar to be in white.

Next to come, a full gray gradient to match Linear Gray icon set.

[wongck]

Looking good.
I prefer the flat versions... i am using flat version n_* since gradients were available.

[helmut]

Flat may be not the best description, it's an optical perception of the gradient which in one case seems rounded and in the other not.
I guess it's coming from the color of the frame (gray at the bottom and right, white on top and left) which gives this "rounded" effect if the lighter color of the gradient is located on the top and on the left side of each object. Look at the picture bellow you will see what I mean. It's not an issue, just an observation.

So it's more like an optical illusion?

I have noticed a strange behavior of the windows widget : up and left arrows do not switch to selected state when clicked on whereas the others yes, even though they are defined in the rsc. Is it a bug?

Are you sure? When there's nothing to scroll they go back to unselected immediately. Just made a quick check on my TT (but without gradients). On aranym it's so fast you hardly see the state-change. But you can set widget_auto_highlight = 1 in xaaes.cnf, and the state will change when moving the mouse over the widget.

Do you know if it's possible to change the color of the windows title / info and top menu font? I would like to do a black gradient and therefore I need the top menu font and info bar to be in white.

Don't know right now. Maybe it's possible to use a color which guarantees a contrast to the background, will have to look.



You were right with n_steps:

There is only 1 step between first and last possible.

So currently the implementation looks like this:

all methods: n_steps=-1: gradient disabeld.
methods 0,1,2: all values other than -1 of n_steps and all values of steps ignored (n_steps should be 0 or -1).
methods 3,4: n_steps must be 1, and there must be 1 RGB-value in step.

I think in a future version of XaAES it should be implemented as I first thought it is.


-Helmut

[Faucon2001]

2 new flat versions of Blue_b and Blue_g, to satisfy Wongck tastes

http://www.philippeworld.net/ftp/Apps/blue_bf.grd
http://www.philippeworld.net/ftp/Apps/Blue_bF.c


http://www.philippeworld.net/ftp/Apps/blue_gf.grd
http://www.philippeworld.net/ftp/Apps/Blue_gF.c


Regarding the widget behavior, I confirm, when autohilight is on, it works fine all widgets are animated. When it's off only the closer, hide, iconify, increase, resizer, bottom and right arrow widgets are animated, the other arrows are not when you click on it. It's not a matter of speed because if you maintain the clic it should maintain the state of the icon.

[helmut]

As soon as the action is done the widget always returns to unselected, no matter if you still hold the mouse-button or not.

I agree though, that the response is not always as expected (on aranym), I guess the selected state is too short to be displayed at all (<5ms or so).

What annoys me since long is the dependency of the scroll-speed and CPU-speed, but that's another story.

Do you make the widgets with rsm? If they shall they go into the freemint-cvs, we'd need the *.rsm-files I guess.

-Helmut

[Faucon2001]

The strange thing is that all the other widgets remain selected when you hold the mouse button, but not the up and left arrow ; the behavior is not homogeneous then?

Yes the resources are done with RSM.

[Faucon2001]

2 more gradients for tonight, this time in Grey, which work with the blue_b.rsc




http://www.philippeworld.net/ftp/Apps/GREY_F.GRD
http://www.philippeworld.net/ftp/Apps/Grey_F.c

I have not changed the menus nor alert background, which remain in light grey, in order to maintain a good reading contrast with the black fonts.
To do so, we will need to be able to change the color of the system font ... may be one day.

If you have any wish of colors, please don't hesitate to ask.

[helmut]

Looks good. The blue one impressed me in the browser, but in real use I found it a little to bright, but of course that depends.

It would be better if the files would have the same spelling: e.g. grey_f.c->grey_f.grd, easier to maintain.

One day you could pack it all together: grad_f-src.zip, grad_f.zip. widg_f.zip, or whatever. Or put a specific character in front instead of at the end, so all your gradients appear in a row in the fileselector.

-Helmut

[jfl]

2 more gradients for tonight, this time in Grey, which work with the blue_b.rsc

Looks great. The blue one is a bit bright for me but I've downloaded the grey one and will try it out on my FireBee.

[Faucon2001]

Thanks.
I realized that I had forgotten to modify some objects, especially in the scroll list windows ; I will have to update all the gradients therefore and will do the name changes suggested at that time. I will do a darker blue version too.

[Faucon2001]

After using the previous gradients I realized that not only they were too bright but depending on the background picture they were not very usable. So I have started again from scratch.
I have used various darker shades of blue trying to be more pleasant and also more flexible with the background picture.
I also decided not to do uniform skin of one gradient as I finally did not find it very aesthetic and quite heavy in the end.
For now there is 3 shades of blue (Saturated, Royal and Jean ) and 2 of black, together with one asorted widget.
If you want more shades of grey you'll have to read the book

I have called this set of gradients Askin' as it is my first skin set and also as you can suggest more colors : just give me R,G,B values for the gradients of the different objects, I will build it for you, as tastes are very personal in the end.
http://www.philippeworld.net/ftp/Apps/askin.zip (If you want to change gradients quickly : ctrl+alt+n and choose your skin.)

I have updated also XGT package with an "how to", and Helmut installation instructions : http://www.philippeworld.net/ftp/Apps/howto.txt
http://www.philippeworld.net/ftp/Apps/xgt2.zip

[jfl]

Hi Philippe. I do like your gradients, but there is one thing that doesn't work too well I think. The gradients in the infoline are OK if you use the large font, like in your pictures. With the small font, it doesn’t look that great (see below). It makes the text less readable.

snap_000.png

Also, a note probably more to Helmut: couldn't the gradient choice be stored in XAAES.INF rather than in XAAES.CNF? That way users wouldn’t have to edit XAAES.CNF to be able to use the new gradient after a reboot. Just a thought.