Well, It has been a few years yet again since I last posted on here. So I felt it might be time for an update.

Over the past year I've been having some fun working on porting FinalWriter to AROS (with massive help from Jason) - and it seems to be pretty much done with some minor issues still to resolve.

I've also been working on A number of other AROS projects including -:

# Updated my Doom3 port to the newest code, with some fixes that seem to finally resolve the known crash, as well as allowing the use of the expansion - Resurrection of Evil!
# A little more work on the RasPi port with Michals help, including starting work on supporting multiple cores within the scheduler.
# Rework the AROS build system to really use its own cross compilers with some related tidying
# fixes to the AROS headers so that we can use them with newer C++ standard compilers
# update the Gnu toolchains so that we can now build gcc 5.1. Also cleaned up some clang related issues.
# Adapt deadwoods hostgl library to run on ABI v1, and reworked the gl.library base implementation to be a proxy to the "desired" gl implementation (set using an ENV variable). This means there should be at least 2 library's on a system to support gl - the gl.library stub and the real implementation (hostgl.library and/or mesa3dgl.library).
# Change how AROS's gfx hidd subsystem handles the creation/destruction of some base "object" classes, so they use a unified (and driver overridable) way to implement them. This means drivers can also expose new object classes not exposed by the gfx subsystem itself, eg gallium contexts.
# Updated (privately) the Mesa GL implementation to v11, including minor changes to how the gallium interface is handled. mesa/gallium no longer use a hard coded list of possible classes to try, but instead ask the screens gfx driver to create a gallium object, and if this fails fallback to the software implementation.
# Update the softrast, and intelgma drivers to use the latest gallium driver code. This finally brings the software rasterizer to a level where it correctly displays the doom3 logo on its intro page.
# Adapt the AROS gfx hidd subsystem so that the gfx drivers are exposed as real hardware drivers - e.g. so that they can be enumerated in the sysinfo tool.
# Adapt the AROS gfx hidd subsystem so that the gfx "driver" objects which represent an individual hardware instance (e.g on die GPU, or discrete controller) expose one or more display objects each with its own mode array database etc.
# start adapting the way AROS exposes its software cursor so that it no longer uses the fake gfx subsystem, but instead the base display class exposes the behaviour.
# adapt the compositing code to use the changes, as well as make the intelgma driver use the base software compositor.

There is still a LONG way to go on the Mesa side (updating the remaining drivers) as well as fixing the remaining issues with the gfx subsystem changes, however the parts working/adapted so far seem to do what it says on the tin. the glsimplerendering test on my Atom's Intel GMA chip has gone from 700to800 FPS up to 900+.

I'm also starting to try and gear up to implement the next parts needed to get my "new" wanderer code base usable. This primarily means re-implementing the icon handling.

The first part I really need to tackle is the base/public "Iconlist" class from legacy wanderer. This is going to be replaced by a few Public classes that are meant to be very basic and usable outside of wanderer also. They don't explicitly represent a list of files, just any old icons which have a label. The most basic units are the IconClass, IconlableClass and IconimageClass. As it says on the tin, they represent the Image for an Icon, the Label for an Icon, and the Icon that exposes those (N.B: an Icon can have more than one "label" entry) The next class is the IconFamilyClass. It exposes a list of IconClass objects, and handles sorting them (the base class is only aware of the icon's label and co-ords). After this come the IconListClass itself. It exposes the input event handling for the IconFamily list of icons, and related codes.

Since these are meant to be very generic - the classes do not handle any IO or related things - they are exclusively interested in a list of "icons" and nothing more. This means they could (should) be used to implement e.g. Toolbar classes.

At some point wanderers own Toolbar panel will get the iconlist to handle most of its functionality, allowing for sorted/positioned icons and fine tuning the appearance. Once this is done it will be time to replace the "private" wanderer versions of these classes so that they tie up the configuration/appearance to suit wanderer, and so that they can populate the iconlists using the new "location" classes exposed by wanderer, matching the entries to icon objects. This will finally enable the new wanderer branch to display the desktop and local filesystem contexts again, but now using the new API's.

... lets see .... where to begin ...