Err, what? Reaction (or classact - that is its historical name) is a collection of boopsi classes that logically extends the already present Os interface.
and aros contains already reimplementation of a number of these classes. in most cases in order to use reaction based software you can simply download free to use classact package. this applies to aweb as well as number of other applications i have once tried. minous here is insisting that it is too outdated, taking his own software as example reference. personally i have an impression that he is on rampage against aros as a valid alternative wherever he can, using a technics of selective argumentation and alternative facts.
said that, i dont imply that aros is already a perfect reimplementation in every respect. as example the colorwheel gadget shows some flaws. bnut it is free and open. and it provides and contains much more that the basic 3.1 distribution. which is what people like minous are trying to suggest aros is inferior equivalent of.
Eh, what? We are moving on here. The pace is slow, but there is certainly movement. And no, it's not that "we screw 4.x". A lot of development from 4.x is merging into the 3.x line right now, but we need to make sure - and this is the real work - that it is compatible to the existing software basis, avoiding compatibility problems to the highest degree possible, and to make it run at acceptable speed even on low end machines.
im pretty grateful for your effort, but according to what you say working on implementing or reimplementing stuff from os4 (or aros or morphos for that matter), you need to ensure the compatibility which is the same we need to do on aros. of course since you work on a smaller scale it is possible to dedicate more work to details. unfortunately you have picked up your work only lately and already the code base you are working on has been subject of legal actions, which can make this work in vain. thats a part of the situation that aros is a solution for. an open source accessible for everyone.
The problem I see with AROS and the like is that - unfortunately - quite some software depends on undocumented internal featuers of the Os, and that the line between "official features" and "implementation details" is not very clearly drawn. Consider for example how "Monitor drivers" work (would that stuff work on AROS?) or how a user shell can be launched and written (would that work on AROS?). Whenever you deprecate such (non-)interfaces (probably to the best of the software development, understood) you also break programs depending on it. The willingness to make such steps is quite different, depending on the development goals, and I would assume that AROS has different goals than the 3.x team.
if you recall once upon a time quite long ago you privately advised me against reimplementing monitor files on aros because their obsolete and undocumented nature. aros has of course different goals than 3.1. but it tries to stay compatible where it makes sense. i was convinced by your argumentation that in case of moniotors it doesnt, and in such cases it is better to find modern, consequent and portable solutions.
Quite frankly, I do not quite understand what AROS is about,
i think its different to different people (involved or not). at the time it started there was apparently no other ng alternative and aros team has from apparently most of todays amiga-ng audience perspective the most sensible choice to port amiga api to the most popular architecture. at the time the distance to catch up with other operating systems have not been so dramatic.
now if you ask me today, aros is still a valid alternative in order to run the installed 68k software base providing it with a number of features and subsystems the genuine os doesnt offer. as example you can support hardware that didnt exist at the time of 3.x release at boot time. but also you have lan, usb, rtg and other stacks out of the box at disposal. and so on and so on.
there are other people involved with aros who have completely different goals, like multiprocessing, modern gl hardware support an and 64bit architecture. or big endian arm implementation inclusive transparent 68k compatibility. the house is big and considering how individualistic is the scene everybody might find his place and sobject of interest within this effort. one just needs to realize.
