In order to get results as shown in the screen shots, make sure you start your work in a 24bit or 32bit format that can also be manipulated with an Atari ST GEM or TOS app. I chose 24bit TIFF format for my original XaAES work, 32bit TGA for my original widget work, and 32bit JPEG for the older style of MyAES skins. All of these formats support none or zero compression. This was the secret to getting extra clean skins in MyAES, even then it was sometimes differcult (just have a look at the associated info file for EcoGreen to see what sort of tricks were done), particularly when using areas of solid color.
 
  OK, so thats done, now what. For XaAES you need a compatible IMG/XIMG format. This is not as easy as it sounds, if you get a 24bit .IMG file saved from another Atari ST app rendering with XaAES, let me know how you did it (I recall seeing a IMG/XIMG image patcher, but I am unsure where or what for). BTW I did try 24bit IMG/XIMG as generated by Smurf, GEMview and GrafTool. What you will have to do is a two step process, First save the image or texture as GIF (256 color). This will often end up with a palette less than 256 colors, especially if you save it as a greyscale, you will sometimes get a 7bit or 127 color indexed palette. Now you can convert the 256 color GIF into 256 color IMG file. This is not a problem for most graphics applications, and the only real problem I had was using when GEMview as I could not find a straight image save, I always had to do a palette convert (from 24bit color). I ended up using GrafTool to load the GIF, then Sirchen als and choose IMG. After you have saved the file, on ARAnyM at least, you must quit, then load GrafTool again for the next image. Painful I know but it works.
 
  GEMview 3.18 is now Freeware. However the installers are still the 30 day trial shareware version, so if you want a key, you must email the creator, he should give you a key to work with both the lastest version and slightly earlier versions that are still widely available. I mention this because GEMview (and suppossedly GrafTool) can do batch conversion of images, and although I had no problems getting 24bit images down to 256 colors, the choice of palette caused major headaches for weeks, I ended up haveing to hand tweak every single image (after the first few accidentally got good palettes) for the desktop icons, no fun I can tell you. So if you are willing, give it a try. GrafTool can but I only once got it to save files, and I can't rememeber how I did it, but it too has a rather sucky 24bit to 256 color IMG convertion, but at least you can load a palette with it.
 
  If you are going to try GEMview, there is a user palette which can be set to top window, which almost works well, only a couple of colors are dithered. In order to use this properly, you need a palette image. If you are goinf to create you images on a non-Atari ST application like I did, you will also need the palette images, or if you use GiMP (which I hope to port soon) I have already made palette files from them, both 256 colors and 16 colors, one palette is the standard default one bult in to the Falcon (with exact 16 colors from ST), the other palette is the one used by NVDI, Jinnee, Jinne Alternat, and now Taskbar. If you are lucky enough to be able to load a .PAL file, I have included one from Taskbar in the theme kit also.
 
  OK, MyAES themes, as long as you save them as 100% (uncompressed .JPG) you will get near PNG and GIF quality form the image, just know that because they are JPEG's and the algorithm is a lossey one, there are still some instances where this is noticable when the texture is rendered. The only other thing you really need to know, is that there is (currently) no way to control the look of the bottom left corner of the border, and that the scrollbars and sizer are part of the borders also, so experiment with slider design before you commit to the borderstyle and sliders. Hopefully there will be a script or command line program that can be used to join scrollbars textures and border textures, to make it easy to change them, so always make sure you supply high quality border texture originals with your theme. This will probably be after the programmer, Olivier Landemarre, has menu popup textures, form widgets, and dialog and text backgrounds loading from images also. We will see.. Reference the two themes by Zorro, Milk and Dark to build your skin, then check and see how I managed to hack the images into position for EcoGreen.
 
  I will quickly mention the scrollbar texture hack for current versions of XaAES, but this will only be nescessary if you want your skin to work on older versions of XaAES, as I will supply extended texturing with AFROS-update, and that will mean the next version of AFROS will have both 1.16.3 and 1.17 with extended texturing. OK, you make you texture no larger than 720x720 and place your scroll textures along the top and left borbers, 20px wide. This can result in quirky starting corners, but with some enginuity the results can fool the viewer. The size is the absolute maxamum, anything larger and it wont load, but it helps with texture repititions. The loading sizes are still quite flexible, with custom left hand title images being 1600x21, again this should not be needed in the near future, but it does work right now and it looks good, besides, the textures can be cut down to fit max screen size.
 
  You need to remember that generally, the larger the textures, the more memory they require. Ecogreen could be even smaller, as indeed the title texture is 1x20, but I know from web development, that there is a boundary for too small a texture, where it takes too long to fill in the required area, which is why the sliders are 16x20. It really comes down to user preference, not just creator preference, but there is a respectable balance to be had.
 
  Texturing for 256 colors if a real mission, and made worse simply because fior some reason, it may be a bug, the textres are converted to the first 16 colors of the palette. In order to have the correct palette, your original 24/32 bit image needs to be tranformed into an index palette. In GiMP there is a quirk to doing this, first select all, copy then paste as new image, then image -> transform -> indexed, choose from one of the two AtariST 256 color palettes, choose your dithering technique. My experience with Photoshop was, Imageready had better algorithms. Nowadays it should be pretty good, just rememeber that any dither should use nearst match and reduced color bleeding, if none can not be chosen. In GiMP do not drop unused colors from the palette.
 
  The same is done to create 16 color images with a 16 color palette, as I have with the miMac theme, which also looks the same in >256 color modes. There is one unstated benefit to textures mapped to the first 16 colors of the palette, and that is if the user changes the default palette, the color scheme will be reflected in the rendered textures, which, as long as the gradients are kept in sync, will still look good. The technique described above will also give correct results when converting images to IMG format, still using GIF saves. Note some applications can not handel 7bit color IMG files.
 
  For XaAES widgets, generally, if you can get what you want visually when you save as 256 color Gif with one of palettes (shown above), then the resulting .IMG can be pasted or imported into a resource editor without modification. Obviously the above technique was not developed until I got started doing XaAES textures, so up until then, I had not end of problems with multi-colored icons, and ended up recreating most of the icon by hand. Use a current resource file, renamed, as the basis for you new widgets, and dont forget to change the text in the last object that fits your new widget set. I think the XaAES treats this a info text, which at the moment is unused. To test the extended widgets, most current versions of XaAES only load the file XA_XOBJ.RSC from the XAAES folder. The new extended texturing versions supplied with AFROS-update allow dor XWIDGETS in the config file, exactly like the WIDGETS entry, so you can place them anywhere really, with any name. You will need to text your scroll bar buttons with various border width, as there placement and apearance is slightly depending on wher they are and what border colors are drawn.
 
  At some point I will run a hex editor over GrafTool and make an english version available, in the meantime you can get both GEMview and GrafTool from most ftp sites, or download the latest GEMview v3.18 from the creators site. The version of GrafTool I have been using is somewhat buggy, but it does have some extras that GEMview does not, including MSX screenshot support. The gradients for the menu's in the EcoGreen theme were created in either Smurf or Vision, I can remember exactly which one, but I found Smurf to have unstable option dialogs, and would crash on load if certian setting wher saved into the config. Vision was not able to flood fill (roller brush), but was able to do most other things fine. The sources to both these apps are now available, so I will be looking at fixing up the situation for them both, and to add extended file format support. Vision does not support 24bit IMG/XIMG, and Smurfs format is incompatible with XaAES (as are most others). This will obviously be a while coming, but I have already found code in HighWire to support XBM and XPM formats, and I will add palette loading of both .PAL and GiMPS's .GPL formats.
 
  Resource editing was done with Resource Master 3.65 with v3.64 english .RSC file. As of 3.65 RSM is now freeware, you must just download the correct version. With XaAES, import image is the squigly mess of an image halfway down the side when select tool is chosen, it looks fine under MyAES, but I have not bean able to save when using MyAES. The last problem may be realted to why Taskbar will load, but not run, with MyAES. On ARAnyM with XaAES I did try Interface, but it only allowed me mono and 16 color icon editing. With RSM save the resource as a AES version 4 file. Make sure you do complete mono, 16 color and 256 color icons and selected icons. When doing large color icon sets for desktops I did a correct mono icon, but not selected, and only 256 color icons (and selected). The mono icon is compulsery for any icon resource, and at some point a mono set can be completed if there is a need. When creating icons for NewDesk.inf use, that is TOS rom v2.05 and greater, limit the resource file size to less than 65535 bytes in total. There are rom patchers that allow greater sizes, and 256 color icons on the desktop, so icon set resources like the one distributed with AFROS update are possible, currently >250Kb in size. The larger the resource file, the longer it will take to load, the more icons there are will increase memory usage and initial load times, but if you can afford that, the use of these large icon sets does not affect the desktop or rendering speeds.
 
  I need to clarify with current creators, the inclusion of these tool in AFROS-update, but since they are the only combinations I was able to get to work properly, they are essential for ARAnyM based development and design. In the near future you can also expect a command line .RSC creator, to help compile custom sets of icons for various programs, including Taskbar (v4.12 uses 16x16x256), TeraDesk, Jinnee, Thing, (32x32x256 and 48x32x256) and probably Gemini and NeoDesk if people are still using those. This allows for system wide theme changes that can affect all used apps, and can extend to langiage replacement also. Initially only those apps supplied with AFROS and AFROS update will be catered for, but as use spread, the required compile information for other apps and languages will become available. Some current apps where the source is avalible, will be fixed to include external resource files for interface icons, ie HighWire. Other systems of 32bit icons are being looked at and the basis for new AES and VDI inclusion, specifically the new Haiku (Open BeOS) vector icon format, which supports gradients and alpha channel. This should not affect current apps or resource files, but will be an extension, becoming part of AES v5 when that is finalized.
 
  If you complete a theme, skin, or icon set, please let me know, as I am compiling a AFROS-extras collection with all the extra fluff that people might use, but probably dont need installed on there systems. I currently am compiling the Blackiesgate Desktop Icon set which totals at least a 1000 icons, with many extra icons for specific applications and application functions. When I have compiled the current iconssuitable for Desktop and Taskbar, I will release the complete iconset sources, with Atari ST loadable formats already converted (GIF, TIFF, TGA). The next iconset will be 64x64 based with 32x32 for Taskbar. Whenb you release a MyAES theme, dont be afraid to place a default desktop background with it, as it is possible for TeraDesk to have a transparent background when using MyAES. At some point the use of background images witll be possible with XaAES, and currently, if you dont have a primary AVSERVER that includes a desktop, or you use the desktop as an app which can then be hidden, it is possible for XaAES to be the desktop background for other apps (any that do not have there own).