Gadtools

• GadTools is simply not good enough for a modern OS (which I think AROS should be ;-)).

• Hardcoded position and sizes

• gadtools.library being implemented using BOOPSI is that it would be quite easy to, say, have a prefs editor that let you set the classname that gets constructed when you create boopsi gadgets of a specific kind.

  This way you could do some theme-ability without having to let the programs know. It also means you don't need to reimplement most of the complex stuff, just the GM_RENDER code (such as the layout parts).

  I don't think you can do very much theme-ability without breaking compatability, since GadTools is based on absolute position and size of gadgets. Many programs assume that GadTools gadgets have 'x' amount of border etc (AFAIK it's not possible to 'find out' such things, since it's hardcoded anyway).

  ...And this is bad practice from the very beginning. There should have been a clientWidth, or innerWidth to go along with a borderWidth (or something like that).

MUI

• Problem MUI is closed source, commercial software.
• Convince Stefan Stuntz to release the source.
• Convince Stefan Stuntz to release a binary for AROS.
• Reimplement MUI starting with Zune (GPLed MUI clone for X11). Author is Flavio Stanchina, http://spazioweb.inwind.it/fstanchina/, flavio.stanchina@tin.it.

ReAction

• ReAction is the GUI system of AmigaOS V3.5+
• AROS should only have one GUI standard
• A lot of work to implement it (no special ReAction code base to start)
• Not many programs use ReAction, much more use MUI but ReAction is new.
• ReAction isn't very configurable but it seems possible to make it very configurable and good looking without breaking API compatability.

I think we should use ReAction. My reasoning goes something like this:

1. The official goal of AROS is to be compatible with AmigaOS 3.1, but this is only because it was written down before 3.5 and above existed. I assume that we want AROS to be compatible with AmigaOS 3.5 and above, and probably higher version numbers (as long as it's the basic, same classic style OS (i.e. not AmigaDE)).
2. Since we want to be compatible with AmigaOS 3.5 and above, we want to have ReAction compatability, since this is the official GUI standard (and most core applications in AmigaOS 3.5+ are written in it).
3. If we have ReAction compatability, we most likely want to have it in the core distribution (since it's in the core distribution of AmigaOS).
4. Since we do not want to have multiple GUI standards in the core OS (since, as you say, we want to fit it on a single disk perhaps), there is only one option: use ReAction for all core applications, because of the point above.

So, we should go for ReAction. There are a couple of issues with this you'll probably bring up:

1. It's a lot of work to implement ReAction, since there is no existing codebase to work from (i.e. we must begin from scratch).

   This is true, but since we want ReAction anyway (see point 2 above), we'd have to invest this time anyway.

2. ReAction isn't very configurable, and people (e.g. me ;-)) think it's ugly.

   I haven't looked very closely at the API of ReAction, but I think it's possible to make it very configurable and good looking without breaking API compatability. You can already specify some options, like background texture and basic look of buttons ('gadtools', 'thin', 'xen'), which seems totally transparent to the application using ReAction, so extending it with more configuration options should be possible.

3. Not many programs use ReAction, much more use MUI.

   Granted, but see point 2 and 3 above. We want to have ReAction compatability anyway, so we might just as well use it. Also, the number of ReAction applications is AFAIK rising, since it's the GUI standard of AmigaOS 3.5+. Also, it's probably just as much work to implement an Open Source version of MUI (i.e. Zune) as implementing ReAction.