@saimon69
Debug current Zune codebase and,where possible, improve existing MUI 3.x
compatibility adding missing functions and fixing current broken features,

@Ball000
1. Port Fab1's OWB. Seems it mainly means "Implement in Zune MUI4 functions needed to compile Fab1's OWB" (of course the port itself would need some other work (improve CAIRO?), so this bounty can't be only Zune-related);

@Fab
That would indeed be the most practical way. I don't think i'd like to have tons of "duplicated" code in OWB just because previous MUI versions didn't support methods for construction/display and co, for instance.

@Ball000
2. Implement MUI4 functions needed to compile Ambient (but yet again, the port of Ambient will need other works to be done, especially system functions, as Ambient relies on some specific improvements of MorphOS);

@bernd_afa
Sebastian Bauer have zune port to run on OS4.there are some os4 ifdefs in.

@ShInKurO
This Zune enhancement would be very good even for an eventual port of Ambient on AROS/OS3/OS4 and to make Ambient in this way what DirectoryOpus Magellan was for AmigaOS some years ago.

@Ball000
3. Implement remaining functions of MUI4 in Zune.

Tags should describe object properties, not invoke function calls - that's what methods are for. So the introduction of the child removing method was the right step, in line with OOP principles.

if(LayoutBase->lib_Version>=53)
{
IIntuition->IDoMethod((Object *)mommy, LM_REMOVECHILD, inst->Win, ubrow->buttons[j], TAG_DONE);
}
else // Use fallback function. Note, this function may deadlock
{
IIntuition->RefreshSetGadgetAttrs(mommy, NULL, NULL, LAYOUT_RemoveChild, ubrow->buttons[j], TAG_DONE);
}

DoMethod(group, MUIM_Group_InitChange);
DoMethod(group, OM_REMMEMBER, button);
DoMethod(group, MUIM_Group_ExitChange);

Code example for anyone interested:

It is possible but you have to subclass the objects and add the support yourself. Which leads back to the problem that some objects cannot be subclassed due to the lack of exposed properties.

This is what is so silly and messy with Reaction the old methods should have been fixed not introduce new methods.

So you felt the need to start one

Please no, I don't think users want to carry on their HD huge development materials for which they don't have a slight need of.

IMHO autodocs are fine (the principle, see it has been adopted by almost every documentation system : javadoc, doc++, etc.) they just need a serious refreshment (that already started in latest SDK thanks to Steven Solie IIRC) and they should be kept up to date when the code is modified that's all. We also need more general documentation in order to understand the general concepts under such or such part (BOOPSI is probably the one needing the most explanation, but (good) device writing is another one for example).

What is missing from ReAction?
What's wrong with the ReAction implmentation?
Is it possible to fix without a total rewrite?

In another thread I read about the limiting menu system
of Amiga OS, which I gathered Intuition handles.
Is this fixable with a new ReAction menu class?

Also what is generally missing or wrong in AmigaOS4 GUI
that we (the users aswell as developers) want changed?

Reaction is a v difficult system to work with. It's fine for a simple GUI but trying to do anything complex with it is a nightmare.

1) Dynamic GUI changes cause lock ups. Yes I know there have been some fixes in 4.1 but these lockups can still occur

2) Drag n drop built into objects. Drag and drop is possible but each object requires subclassing atm.

3) It is impossible to subclass some objects due to the lack of exposed properties so effectively you have to write your own gadgets from scratch, increasing development time considerably.

Certain OS developers have the opinion that you should not be subclassing system gadgets. Why? No idea seems pretty insane to me

4) Some objects do not support the standard gadget tags but instead implement their own tag that does the same thing. Trial and error makes development time v slow.

5) Documentation is poor. I would like to see self documentating objects i.e. standard properties that return list of all supported tags, descriptions etc.

Oh I could go on forever about how bad Reaction is when compared to other GUI systems.

The Widget part isn't complete yet. There are a few things to do still (for example, popup windows that move with their parent). Networking had its share of problems too, like I pointed out (gethostbyname not being reentrant), we still have a while to go.

The presence of close buttons on the tab depends on the theme used. This theme doesn't have any. We hope to make a more Amiga-specific theme at one point (if we ever figure out how that works ;))

We already loose Detlef W?rkner (tetiSoft) in early 2008 who was working on the locale part of the OS

In the middle of this depressing situation we have a technology divergence going on. Let us consider the three or four main players:

1.Amiga OS4.x
2.AROS
3.Amiga OS3.x
4.MorphOS

If you develop for Amiga OS3.x you have a reasonably good chance of being able to port it to AROS without much modification, and AmigaOS4.x with some modification. Obviously, depending on what you do. It is a laughable thought that you could develop for Amiga OS3.x plus RTG and then rely on the emulation layer of Amiga OS4.x to execute it, presumably the same applies to MorphOS.

The ideal situation would be some convergence going on, perhaps a standards group overseeing not just a set of guidelines for developers of device drivers, portability layers and application software to help them avoid making expensive (in terms of time spent) implementation decisions.

Ideally you could write for one, and recompile for all others with some idea that it was going to work. For the developer this would be a boon, for the users, well it would allow them real freedom of choice when selecting their Amiga-like distribution. For the OS developers, it would mean some real competition. Having a standards group would not mean an end to innovation. Like anywhere, an idea could be tried out first on MorphOS, giving that the advantage temporarily, and if it was successful the demands of users on the other platforms would help it race through the standards group and get implemented on the other distributions.

Of course, there are going to be many out there that will refuse to port using applications as advocacy for a given distribution. Well, so what? Given enough time and developers and most importantly end users for developers to sell (or get kudos from) to competitive applications would appear.

I urge technical co-operation between the development groups. Put personal vendettas aside, and work together on a new AmigaOS API standard that all can share in common.

While I salute your idea of a common API for the Amiga-alike platforms, that is going to be restrictively prohibitive. The biggest problem is going to be in the user interface. One uses MUI, one uses a MUI clone and the other, Reaction. To build a common API (wrapper) for those would mean leaving out a lot of functionlity from each GUI system. I have personally implemented a few modern features within Reaction that is not available in MUI, and I know that works the other way around too. I doubt the AROS MUI clone has all the features of MUI 4 either.

This would lead to a common API which misses a lot of the latest features, and would only allow access to any common functions between the systems.

That's impossible since the MorphOS port of OWB is not open source. But even if the sources would be available they would be just as useless as the AROS ones, about 90% of the code for a download manager is GUI related and the MorphOS one uses MUI4.

Are you saying that I can change all the menu options in an MUI application, the order of menus, and even what menu items are called in a MUI application from the prefs panel?