Applications  zView 
Supported AES  MyAeS  XaAES 
Iconsets  Icon Sets 
Tutorials  MyAeS 0.92 skins  MyAeS frames theming  MyAeS scroll sets  XaAES Widgets  XaAES extra Widgets  XaAES texturing  XaAES theming 


XaAES with extended textures for MiNT 1.16 (readme.txt)
68040 Pastel Color Pack, XaAES with extended textures for MiNT 1.16, in 6 flavours (readme.txt)
sources files XaAES ( with extended textures and gradient files for MiNT 1.16.3 (readme.txt)

 Update: The mentioned issues with current MiNT v1.17 are being looked into, and I have seen a bug fixed version of XaAES that has a slightly different pixel detection function, which does seem to provide a solution. I am as yet unconvinced that this is not hiding something deeper, however it should be noted the texture and gradient issues I have experience with ARAnyM usning 1.17 are not present on all systems or setups, so it may be enough, and we may never know the real cause of the issue. Expect a fixed version in a full release of AFROS-update, which should be 9.12 (this month in 09).

  Whats Available 
Apart from the packages uploaded to the afros-update project, you can also find here OS wide themes, AES frame widgets, AES frame skins, extra AES widgets, AES scroll sets, and complete AES themes. Also there are application specific skins, icons and themes. Where ever possible I have tried to complete all AES related work to be made available for MyAeS (v0.92) AND XaAES (v0.998 Alpha), both of which can be used with AFROS, ARAnyM, and MiNT. MyAeS skins, themes and scrollsets are tested on a ARAnyM Falcon setup (TOS 4.04), so they should work 100% on whatever other platforms that MyAeS successfully runs on. At some point I may start supplying Magic compatible themes, widgets and skins, same for N.AES, but only if there is demand, and only then on an "available time" basis. Let me know if you want them.
I have many projects on the go at any one time, and as you may find out, some of the downloads here (and on afros-update) are preview, "work in progress", or incomplete. These are continuosly being updated, improved and worked upon, but you may however request an update, fix, extension, or supply alternates and improvements. Some of these packages contain textures or icons that have taken days to get looking right on an Atari ST, and may be one of 3-6 alternative for that single image. Often there are enough individual pieces to mix and match up to about 6 different styles of one theme or skin. With this in mind, know that there are often included configuration and description files, to be used with something simply called Config.R8R.
At the moment, you need to do at least a small amount of reading in order to know what to do with, or where to put, these packages. Basically I suggest keeping everything in one "skins" directory somewhere, especially the MyAeS skins (ie keep only a folder called "default" in the "C:\GEMSYS\MYAES\SKINS" directory, you have been warned), as this will be used by config.r8r as a default stroage, from which all "options" will be installed from. The folder name will be user defined to help non-english users keep there filesystem organised properly. At the moment it is just a collection of bash (or shell) scripts, which will be released with "various intermediate front-ends" to start them, and hide them from view. A Thing groups file is one for, because this is the basis for Taskbar's menu system, and there are enough users still using Thing Desktop.
Eventually the config.r8r will come as a front end app. It will allow "dynamic resource creation", run-time program configuration changes, multiple boot-time configurations, GEM-script process config changers (for supported apps), a program patcher, and file/version backup, copier & packager, as well as multi-version MiNT configuration, and "single file" XaAES and MyAeS configurations, all from one frontend, but with fallback scripts for those who would "do it their own way". This too is obviously a lot of work, which may take 12 months or more to complete to a usable level, but it will be modular, so that it can be easily extended to be used to configure other CNF and INF files, as well as other programs. If you can imagine a kcontrol (KDE Kontrol Center) for MiNT/AFROS/ARAnyM/ATARI, then you might be close.


  Things You Need To Know 
What I am about to write here is not "an afternoon trying" or "an hour here or there", but comes from 8 to 20 hours sessions of trying to get the simplest thing for work, days or (in some cases) months of hunting for solutions, and many, many hours of repedative OS and app configuartion testing, mostly so you dont have to.. hopefully.
With ARAnyM at least, although I want to test a couple of other configurations, after 6 months, the following is still true:
wanted themes
256 color skins - MiNT/XaAES 1.16 or 1.17
more than 256 colors - MiNT/XaAES 1.16 (NOT 1.17)
gradient color skins - MiNT/XaAES 1.16 (NOT 1.17)
widgets - MiNT/XaAES 1.16 or 1.17
MyAeS will do only 256 colors on an ARAnyM Falcon setup (TOS 4.04), but with MiNT 1.16 or 1.17 it will give you 24bit color. XaAES under any MiNT version 1.17 on ARAnyM will NOT allow 24bit texture rendering (invalid pixel format). This does NOT affect applications in any way, just the theme related rendering. This may not be the case on Milan, Falcon, Hades, or CT6x (or Coldfire), but it is on ARAnyM, and has been for more than 12 months.
XaAES uses an NON-STANDARD 24bit IMG/X-IMG (GEM Paint) format. By "non-standard", I mean programs from the 80's & 90's like GemView, GrafTool, Smurf can not generate compatible 24bit IMG files. There may be a simple solution, I have yet to find a legitimate tool that can output a 24bit IMG that XaAES can read. That said, most tools can read the 24bit IMG files that are (currently?) supplied with XaAES.
The workaround is to create IMG format images with 256 or less colors. AGAIN, this is not practical with "legitimate" tool on the GEM/MiNT alone. The secret of my success? 24bit originals, usually TIF, saved out from GIMP as GIF format. That is to say, 24bit color to UN-DITHERED 256 or 128 color images, then GrafTool from GIF to IMG (having to quit after each image convertion, because the IMG option disappears from the "Save As" menu options). NOTE that GrafTool can do a straight image conversion, no palette remapping, or color dithering, to IMG format, as either 8bit (265 colors) or 7bit (128 colors), BOTH of which XaAES can read (suprisingly), unlike some other tools.
It is possible for GEM View to do 24bit to 256 color "nearest color", ALMOST-UN-DITHERED "img" image, but this takes an excessive amount of work, and does not give appropriate results when that IMG requires a specific palette. GrafTool also "sux" where a specific palette is required. At the moment I have resorted to using GIMP with custom palette files, and doing straight "265 color format conversions" from GIF images. IMG files of this type are required for XaAES's texture rendering in 256 color mode, which remaps image palettes to the palette currently being used, thankfully it does not try to dither the images as well, although some of the resulting textures may look that way, they are in fact not, so it is best to start out (on the Atari/GEM side) with an image that already contains the correct palette. NOTE: they are actually mapped to the FIRST 16 colors of the current pallete, so you better get those old pixel skills up again.
I have access to both Smurf and Vision source code. Both are a bit less than "stable" under MiNT on ARAnyM, but usable if you know what NOT to do (no fill tool in Vision, no multi select menus or option dialogs in Smurf). I also have some early versions of GIMP in source form. The idea is to get all 3 running stable, add the relative IMG/XIMG format extensions to all three, and offer the GEM/IMG/XIMG import export modules to the GIMP project for inclusion, along with 2 different 256 color palette files created tonight, one is the AtariST-default (AtariST-default-16) palette (which contains some color double-ups, and may or may not be the same as the default Falcon 256 color palette), while the other is the AtariST-common (AtariST-common-16) palette which is the one used by "taskbar.pal", "nvdi.pal", "jinnee.pal" and (believe it or not) Jinnee's "alternat.pal". I will double check these again using GIMP this time, but there is no noticeable difference in these "alternate" palettes, on the desktop anyway.
The only drawback of using GIMP at the moment, is that modern versions are probably "out of the question" on current TOS/GEM platforms, and that it really should be added to the AFROS LiveCD as a host OS dev tool, which means more work needs to be done on the X Server presentation, which is, currently under Slax, limited to running ARAnyM, then shutting down. However the bonus of using GIMP (source), is that various "must haves" can be added to Smurf and Vision, like more modern image formats and other modern "extras", and certain parts be crossed over from other apps, like Smurfs "modules", and Visions color chooser. I will add "paletteing" to both, based on GIMP's palette format, and include standard ".PAL" format support also. Never again will any person be required to spend a stupid amount of time in order to get a simple image to be usable on the GEM/AFROS platform, thank god... - © 2009 - paulwratt