ok, better late than never, this will clear up some things and complicate some others.. it is 2008/9 when I do that original texture work, and 2010/11 when I (re)write patch.
texturesI have not been able to set the unselect background UXTERIOR.IMG neither.
There may be patch missing, u can check code near bottom, all the U image objects are fall-thru to the topped imaged. When the original extended textures patch was finally submitted (3 yrs later), I did not have a working setup, I had to write it from scratch off the top of my head (for the 3rd time). Within a week I noticed something was missing, I believe it is related to the fall-thru filling of objects (like UXTERIOR.IMG).
Did you verify the image sizes, there is piece, either on wiki, or on afros-update, about the size of the images, and there multiplacants. It may be vertical images require 8 pixel boundry size (8,16,etc) (it is 2009 when I do that work).
gradientsThere is doc somewhere that explains gradient code that I wrote, I think I see it in XaAES repo. note that all the gradient types/methods are held in one .c file
Yes, BOX-GRADIENT2 is for large areas, like the userdef(?) in TeraDesk used by MyAES to change background. There is calculation in code somewhere that tell when to use it.
Dont change the gradient types, or the way they function (in code), and dont use
utop_grey_gradient.
You need to go to the .c file that defines the gradient methods.
utop_grey_gradient was a quick hack (Ozk) used to get gradients working and tests them, particularly with (alert) dialogs (with
(u/o)top_red_gradient). If u check code, u will find if it is not defined, it is not used, one of the other ones is, it is reverse fall-thru, if its defined it over-rides (some) others.
most of XaAES gradient types are optical illusions, but here is better descriptions of what can be done:
1-color liniar: horizontal & vertical (true flat, ala win10 & google)
2-color liniar: horizontal & vertical (ala OpenBox Artwiz-boxed)
2-color intermediate (ramp): horizontal & vertical & both (ala XaAES Gold & OpenBox)
4-color bubble (2-color ramp + 2-color ramp): horizontal & vertical & both (original XaAES grey menu bg, where 2x defined 2-colors, 1x in reverse)
multi-color multi-ramp (incl bands): horizontal & vertical & both (this uses more step triplets)
I notice in all ur description of RGB 0-1000 triplet examples u not show the 3 one only the 2 one. It is possible to do varing step where the ramp is hard on one side, and multiple ramps to fake a unbalanced ramp. It is also possible to do multi-color rainbow or "5-color" gradient square (ala Pi boot test colors), or rainbow style "color-bands", that is the true power of the gradients Ozk placed into XaAES, and may have been directly inspired by the simple gradient configs used by OpenBox (and others), as Artwiz-boxed is simply a black version of the longtime gold XaAES gradient frame.
From memory, it is possible to get textures and gradients to work together, but there must be a default gradient defined as a fall-thru texture, in the same way the Untopped texture gets pre-filled by the (o)Topped texture. I made them use less memory if they were nor there, instead of coping the objects, specifically for users who liked lite-n-fast (n-low-mem). That needs to be verified in the current code.
I have a MiNT 1.16 setup on a HD image with the original Extended Texture and half dozen color Gradient variants builds of XaAES. Unfortunately I have to recover that drive to get access to it.
widgetsThe curerent standard for .rsc widgets does not include 24-bit color, however the format does not limit its use, more so apps never thought it would be possible. I believe someone suggested using the 2bit masks space on 24-bit systems, but that is debatable (still). With the work being done on MyAES and EmuTOS it is a good time to look at 24-bit XIMG and .RSC formats.
Helmet mentions widget display time as linked to CPU and visibility issues, there can also be wrongly defined widget, check with RSM.
24-bit texturesThe second issue with widgets, is also a problem with many apps, and may explain why Smurf works sometimes and not others. The IMG format, and defines for XIMG use, "allows" for any bit size, 32,24,16,8,4,2. but it also "allows" for little endian OR big endian
The reading of a 24-bit X-IMG format image need to be done with a "blind" algorythm, as the code in XaAES does, which most apps DONT do, they expect, or pre-fill some values based on others. Note: the original 24-bit XIMG textures in XaAES will not load is some 24-bit apps, but Ozk created them with some app, so which one was it (Apex Media?).
Handling of 24-bit XIMG in Smurf is not an issue, as there is source for it, as long as the currently available source is the patched one for CF and some other minor crash, it will not be an issue for 24-bit intergration.
If I remember rightly, there are some grafix programs that can handle grafix import and export plugins, this can also be done for GiMP, which was my intention originally.
265 colors for resourse widgets is not impossible, but yes it can take time to hand tweek them. I suggest that someone needs to expand RSM a bit more to make it easier (like load palette, or transpose 2nd palette)
I had shareware program that could save and load various formats (GifView maybe?), I could get 24-ximg in, but not out (it can still be registered, and I may have posted its name on MiNT mailing list circa 2009-10). I used that and graftool (after I hacked the resource file) to visually verify the palette and dither algorythms, which where usually different for differing pictures (24-bit GIF imageready, PNG/TIFF or TGA from GiMP - it was arduous) and sometimes zView (screen.ldg & tga.ldg - different versions give different results).
XaAESSome parts of the window-frame are hard coded, need to be change-able or furned off from config. Also those who say "this line" or "that line" is missing, not so, it is drawn, just next layer is 1px out, so it looks like its missing.
The problem with using helmuts .grd files is they are only as good as ur understanding of the code, same thing goes with apps to make them. Also because they are binary blobs, they are not suitable for CVS. I originally suggested loading raw .c files and plugging those into C objects, simply because Ozk had layed them out really well, it would not have been hard with the .ini engine.
ATM if (somehow) you could save the C objects that are the gradient and texture trees directly out of XaAES, u would get exactly what Helmuts XGT make files do. A very ST way of doing things.
That is why it is important NOT to change any part of the gradient system until it is fully documented, GUI apps exist to write both .c source and binary blobs (as make & AHCC does), and people have had a chance to push it to its limit.
It was designed to be expandable, with more functions/methods, and should not be modified to fit our view of the world, especially when it is not fully understood.
A lot of the things asked for in XaAES GUI render can easily be done by writing a MyAES windfram, but most of that comes from being modular at its core. At some point in the past there was talk of seperating out the GUI stuff from XaAES, which would make it modular, also
FYII took about 9 months of upto 24 hrs per day to fully understand the situation with 24-bit textures in XaAES, and the work-a-rounds required to get good 256-color results, unfortunately only the initial developments are still available (on web.archive.net), and some of the online documentation has been pruned.
(Jan 2017) I am almost at a point again, where I can have a permanent Atari ST setup again, and I will endeavour to help out with some of the above problems, but I warn u all now, I am not going to wait 3yrs for code to appear that others can use.
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
all these statements are still true

Cheers
Paul