XaAES skinning

[wongck]

Your gradients look great. I prefer the Saturated version.

Now OT...
sorry for not following the Xaaes dev too much....
I always see that during XaAES startup (Mint 1.19) it is reporting that it cannot find XAAES.INF, which is true because I do not have it.
I dismissed this error msg as everything seems working as expected ( except for the e2fs corruption).
I only have XAAES.CNF... and change gradient using reboot


What is this XAAES.INF ???

[frank.lukas]

Look Great ...

Ask helmut to the xaaes.inf (from helmut at the atari-home.de) -> XaAES stores its own window and Settings (Ctrl-Alt-S)

[jfl]

I only have XAAES.CNF... and change gradient using reboot

You can change gradients on the fly with Ctrl+Alt+N. No need to reboot.

[Faucon2001]

Thanks for your comments.

JFI -> I will look at the info bar gradient to make it more flat ; I had never tried with as mall info font. I will do other minor adjustments in the coming days too.
Your suggestion to have the gradient definition saved into XaAES.INF is interesting. Helmut is the right person to ask ; I am not into XaAES development.

Wongck -> To create XaAES.inf use ctrl+alt+s
To change on the run gradient without rebooting : ctrl+alt+n open the file selector to select the gradient you want and apply it immediately.
If you want to change it permanently, you have to modify XaAES.CNF.

[Faucon2001]

I only have XAAES.CNF... and change gradient using reboot

You can change gradients on the fly with Ctrl+Alt+N. No need to reboot.

You have been faster

[helmut]

Some interesting ideas here. I'm collecting them all

First I guess I should make the enhanced XaAES compatible with the trunk-kernel, because I don't think anyone uses the enhanced kernel (which is actually de-hanced in some places).

I think I updated xgt on my disk meanwhile, but there's no time to manage it all atm (some notes in the readme and some minor changes in the scripts, nothing crucial). So I thought I'd send it to Phillipe, the new maintainer

The howto is really a helpful plus!

Then later it all could go into the freemint-CVS.

HC,

Helmut

[Faucon2001]

Hi,

Here is a new version for Christmas, with a softer grey gradient for the Info bar and Sliders for all, and a softer Title gradient for ablue_1.
I have also modified the widgets in order to have more contrast, and added a new pastel one.
Thanks to Zerosquare for the suggestion.
This should resolve your issue JFI.

http://www.philippeworld.net/ftp/Apps/askin1_2.zip

I wish you a Merry Christmas from Mexico.

[jfl]

Here is a new version for Christmas, with a softer grey gradient for the Info bar and Sliders for all, and a softer Title gradient for ablue_1.
I wish you a Merry Christmas from Mexico.

Nice improvements. I prefer ablue_3 personally. This has become my default gradient. Thanks for your efforts and merry Christmas to you!

[Faucon2001]

Merci Jean Francois
By the way I really enjoy GEMDICT, a great tool.

Thanks to Lodovico comments (author of the Linear Grey and Blue icon set), I have updated slightly the gradients for a for better contrast :
- Lighter and flatter grey for untopped info bar.
- Lighter color for selected widgets of the title bar.

http://www.philippeworld.net/ftp/Apps/askin1_3.zip


XGT archive has been updated too with the correct gradients source.
http://www.philippeworld.net/ftp/Apps/xgt2.zip

[Faucon2001]

Some interesting ideas here. I'm collecting them all

First I guess I should make the enhanced XaAES compatible with the trunk-kernel, because I don't think anyone uses the enhanced kernel (which is actually de-hanced in some places).
I think I updated xgt on my disk meanwhile, but there's no time to manage it all atm (some notes in the readme and some minor changes in the scripts, nothing crucial). So I thought I'd send it to Phillipe, the new maintainer
The howto is really a helpful plus!
Then later it all could go into the freemint-CVS.
Helmut

Hi Helmut,

It's my pleasure if I can help

I have noticed some possible improvements in XaAES appearance :
- otop_title_gradient define the gradients of the window tittle bar and of the widgets Closer, Iconify, Fuller, which is logical.
- utop_title_gradient define only the tittle bar gradient and not the widgets. For untopped windows the gradient of all widgets is defined by utop_grey_gradient
This is not consistent and oblige to use only one gradient for all untopped widgets.
Also it would be nicer if untopped windows had the widgets greyed like the text.
Correct the selected widgets (up and left arrow) which don't change of state when auto highlight is off.

Some objects are misaligned as you can see on the picture attached. The tittle has a dark grey frame instead of a black frame like the widgets.


Now, I would put in Santa bucket list :
-Be able to define within the gradient file the color of the text for tittle bar, info bar, Menu bar, lists ... It will allow more flexibility in gradients construction.
-Use png files instead of rsc for widgets /icons, in order to allow more flexible colors (256c are really a limitation)
-Use png instead of img for the skins.
-Get rid of the "old" 3D looking and allow different skins for topped/untopped, selected/unselected.
Real grafix instead of calculated gradients is I believe the way to go.

Sorry if I am asking too much, especially detail aesthetic stuff, but that's the season of the good wishes, so it costs me nothing to try

[jfl]

I would add to Philippe's list of feature requests a personal annoyance of mine: the lack of left border for window menus and toolbars. It really looks horrible (see screenshot below, above a white background to make it stick out). Also, the excessive blank space at the left of the 1st menu item (but this is a different kind of problem).

snap_002.png

[helmut]

I phoned her the other day and that was the reply:

"What the F*ck do you want with a f*cking atari nowadays? I'm f*cking never waste any of my precious time for this peace of sh*t! Go back where you came from from you bloody bastard!"

Maybe I made a typo and reached at Satan instead of Santa?

Seriously: I'm aware of most of the things reported and surely want to fix them all. Time will show

I remember I tried to get the toolbar-border-thing right long ago, turned out to be not as easy as it seems.

Adding new gradient-objects might be problematic due to possible version-conflicts, but there is probably need for a versioning of gradients anyway.

Using a different image-format like png is far far away ...

As I understand you Phillipe, you want to throw away the current gradient-code and use png-textures for everything? I'm not sure if that's the way to go. I don't know much about png, and would not profit much myself except that it could probably also work for lower video-depths like 8 bit which I use a lot. Also the XaAES-code could unnecessarily increase when it contains the png-stuff.

-Helmut

[Faucon2001]

I phoned her the other day and that was the reply:
"What the F*ck do you want with a f*cking atari nowadays? I'm f*cking never waste any of my precious time for this peace of sh*t! Go back where you came from from you bloody bastard!"
Maybe I made a typo and reached at Satan instead of Santa?

Strange, I called Santa last year to have a new Atari and brought me a brand new firebee
It sounds more like my wife answer
How come do you have my wife phone number?

Seriously: I'm aware of most of the things reported and surely want to fix them all. Time will show

Great to know. I perfectly understand we are all struggling with time, and there is so many other important things to do. No pressure.

I remember I tried to get the toolbar-border-thing right long ago, turned out to be not as easy as it seems.

Adding new gradient-objects might be problematic due to possible version-conflicts, but there is probably need for a versioning of gradients anyway.

Using a different image-format like png is far far away ...

As I understand you Phillipe, you want to throw away the current gradient-code and use png-textures for everything? I'm not sure if that's the way to go. I don't know much about png, and would not profit much myself except that it could probably also work for lower video-depths like 8 bit which I use a lot. Also the XaAES-code could unnecessarily increase when it contains the png-stuff.

The first idea is not to add new gradients, but to have the same objects structure for topped and untopped, which is not the case today. The actual gradient structure allows it without the need to create new ones.
The second idea, I understand that is much more complicated, should be to complete the actual skinning with images, with an opened and universal image format (32 bits img is a nightmare), and extended to the 4 object states topped/untopped, selected/unselected, and in this case remove the forced pseudo 3D animation. That is what is done with MyAES. In this case, gradients will be useless and could be thrown away.
I don't know if it will make the code heavier, as img skinning is already partially implemented.

[paul92706]

Your gradients look great. I prefer the Saturated version.

Now OT...
sorry for not following the Xaaes dev too much....
I always see that during XaAES startup (Mint 1.19) it is reporting that it cannot find XAAES.INF, which is true because I do not have it.
I dismissed this error msg as everything seems working as expected ( except for the e2fs corruption).
I only have XAAES.CNF... and change gradient using reboot


What is this XAAES.INF ???

Oops!

[paul92706]

Your gradients look great. I prefer the Saturated version.

Now OT...
sorry for not following the Xaaes dev too much....
I always see that during XaAES startup (Mint 1.19) it is reporting that it cannot find XAAES.INF, which is true because I do not have it.
I dismissed this error msg as everything seems working as expected ( except for the e2fs corruption).
I only have XAAES.CNF... and change gradient using reboot


What is this XAAES.INF ???

First off i apologize if this is off topic, anyhow Hi wongck, i to am having issues with Mint/XaAes searching for XaAes.inf, also i am having issues with somthing related to my NFS sharing file system, the system scrolls to fast at start up and i can't make out the error, the problem is right after the FSTAB setup, i think its as you say the e2fs corruption, also when i access my NFS folder there is a bunch of text on screen i dunno what it is. how could i fix this? thanks wongck

[wongck]

To get rid of the cannot find XAAES.INF, just create it using CTRL-ALT-S.

e2fs corruption ought to be independent of NFS, just do not load nfs.xfs and see if you can see those e2fs errors.

I think there was a version of NFS drivers that display lots of status, but I think Vincent toned it down subsequently.
Or try to configure the debug level when the MINT splash occurs at very beginning of startup (press your SHIFT keys).
While you are there, you can configure writtng outputs to file also.
( or edit your MINT.INI file .... with some care)

Sorry can't remember if either a latter version of nfs by Vincent or lowering of debug level to remove the huge amount of status reports.

[paul92706]

To get rid of the cannot find XAAES.INF, just create it using CTRL-ALT-S.

e2fs corruption ought to be independent of NFS, just do not load nfs.xfs and see if you can see those e2fs errors.

I think there was a version of NFS drivers that display lots of status, but I think Vincent toned it down subsequently.
Or try to configure the debug level when the MINT splash occurs at very beginning of startup (press your SHIFT keys).
While you are there, you can configure writtng outputs to file also.
( or edit your MINT.INI file .... with some care)

Sorry can't remember if either a latter version of nfs by Vincent or lowering of debug level to remove the huge amount of status reports.

Thanks wongck i will look further into this, and do as you say about the XAAES.INF and nfs.xfs driver.

[paul92706]

To get rid of the cannot find XAAES.INF, just create it using CTRL-ALT-S.

e2fs corruption ought to be independent of NFS, just do not load nfs.xfs and see if you can see those e2fs errors.

I think there was a version of NFS drivers that display lots of status, but I think Vincent toned it down subsequently.
Or try to configure the debug level when the MINT splash occurs at very beginning of startup (press your SHIFT keys).
While you are there, you can configure writtng outputs to file also.
( or edit your MINT.INI file .... with some care)

Sorry can't remember if either a latter version of nfs by Vincent or lowering of debug level to remove the huge amount of status reports.

Thanks wongck i will look further into this, and do as you say about the XAAES.INF and nfs.xfs driver.

[paulwratt]

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.


textures

I 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).


gradients
There 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.

widgets
The 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 textures
The 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).


XaAES
Some 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


FYI
I 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

[Faucon2001]

Hi Paul,

Good to read from you and see you're back on track.

Thanks for this in-depth explanation which would have helped me a lot 2 years ago when I was working on new gradients, having to guess by myself, trials and errors. Anyway, it's better later than never
I made this documentation https://sites.google.com/site/emaappsar ... /documents explaining how I did it and at least what I had guessed, in my simple language as I am not a C developer, and finally have reached the look and feel I was looking for. Feel free to amend it, correct it or complete it ; it would be nice if you could republishe your archives as they disappeared since then with your website.

Now, two years later (I can hardly imagine that 2 years have gone since!), I can only say that nobody followed the path, no new gradients have been developed, and as far as I know nobody has tried to modify XaAES GUI render (And surely not me as it is far above my poor knowledge in C) ; it seems that I was the only one interested in XaAES look and feel to make it appears a "little bit" more modern.
Thinking about improvements, MyAES windframe is definitely a nicer and easier way to go.

I wish that you will have your Atari setup soon ; in the mean time you can use BeeKey
https://sites.google.com/site/emaappsar ... eavailable

Welcome back.

[mikro]

Philippe, would you please sign up for FreeMiNT ML? (http://mail.atariforge.org/mailman/list ... emint-list)

You're obviously pretty productive and knowledgeable, on that list people will be able to a) include your work into the official distribution b) other people will respond there so also all the other ;) people will see what's going on.

Helmut, Paul, all of them are on the ML but not all ML members read this forum. And since this is very FreeMiNT-specific thing, I'm sure everyone will appreciate it even more. :) Just summarise your work, feel free to include links, archives and screenshots.

[wongck]

Is the ML pretty quiet nowadays ?

[joska]

Is the ML pretty quiet nowadays ?

http://mail.atariforge.org/pipermail/freemint-list/Week-of-Mon-20170102/000385.html

[wongck]

http://mail.atariforge.org/pipermail/freemint-list/Week-of-Mon-20170102/000385.html

hmmmm. Thanks.

[jfl]

Is the ML pretty quiet nowadays ?

I had to unsubscribe and re-subscribe; I didn't get any mails for months.