Bear in mind MUI is a contribution, present purely to allow third party applications to run without the need to download the MUI package first. None of the OS uses it (AHI prefs uses it, yes, but that too is a contribution, not a component)

So, I see the bottom line as: The effort expended in this thread talking about MUI/Zune could already have been better spent, and the end result is still the same - highly unlikely that Zune will be adopted, even as a contribution, let alone the OS actually using it.

I haven't used MUI much in the past, and not for years, but I wasn't smitten with the way the application interacts with MUI, the whole idea just seemed very clunky. Using the AmigaOS4 BOOPSI classes can be very flexible. It can be used the way that is shown in the example sources, or you can set up notification on just about everything by using IDCMP_IDCMPUPDATE and a hook. Personally I like the way Reaction works, as opposed to my memories of MUI.

I have nothing against someone porting Zune, but IMO it will only ever be a third-party thing, as opposed to an OS component. There is no need to include it, as we already have MUI (and all its apparent shortcomings), and the system will probably not be rewritten to use it, otherwise that would have already happened with MUI.

I think you (and everyone else that favours MUI) is going to have to resign themselves to the fact that AmigaOS4.x will not be supporting MUI, or a deriviative, as the default GUI toolkit. If a move away from the BOOPSI classes occurs, I'm sure it will be in favour of something that offers something more suitable.

but just updating MUI wouldn't help anyway, it's broken by design.

If would want to have something as broken as MUI I could port the AROS Zune to AmigaOS 4.x and add the required AmigaOS 4.x changes, but since Zune can be used instead of MUI with MUI programs on AmigaOS 3.x they obviusly copied all design flaws of MUI and, except for the required AmigaOS 4.x changes MUI doesn't have, it would be just as bad

I don't know how the licencing would work with Zune, I assume it's open source (everything else AROS is), so including it in a commercial distribution may be problematic.

Apart from that, the ongoing improvements to the AmigaOS4 BOOPSI classes is built upon an existing frameswork which has been tried and tested.

Those improvements are far easier to test than a complete gui toolkit.

I am currently working on parts of the BOOPSI system as we speak, and development in this area is constantly evolving.

Feelin may have some cool ideas (much inspired from MUI, btw), but it's *totally* unproven on real use. The only app using it is its prefs GUI, apparently. I wouldn't like to develop serious stuff with such an unproven toolkit.

And once again, it's too bad you don't control MUI development. I guess that's the real reason for OS4 using "Reaction" instead of MUI (along with 3.5/3.9 legacy), actually, not all these weird statements about unresponsiveness, slowness and all... :)

OWB, a program which doesn't even use the ReAction class (window.class) for it's GUI. OWB uses plain intuition windows with a few BOOSI gadgets and gadtools menus.

Most obviously don't or there wouldn't be that much crap MUI programs with unresponsive GUIs

Since AmigaOS 3.5 there is no such thing as ReAction, the methods it added like GM_DOMAIN are standard AmigaOS BOOPSI methods now, and not only the classes which where added to AmigaOS from ReAction support it but old ones like gadgetclass as well.
Quote:

GM_DOMAIN -- Obtain gadget sizing requirements.

Some things MUI does were required on AmigaOS 2.x, but it was never updated to newer versions of AmigaOS, and never will be,

Of course it would have to be updated for AmigaOS 4.x as well before it could be used, but unlike with MUI that's possible for Triton.

Yes, but it doesn't change the reality. The problem is there, and therefore it makes MUI difficult to use at best.

There is no such chaos on Reaction, yes it is mostly because these external classes don't exist, but that is a good thing in this case.

About 50% of all MUI stuff I tried wants specific versions, sometimes they don't even work with newer versions of the same external class they're using.

MUI isn't to be blamed for that, sure, but it still makes me shy away from anything MUI related, and makes me not even consider it for my own stuff.

No, the BOOPSI stuff is not the problem. It's a simple object oriented class framework. The problem are incompatible changes in classes, a thing that should normally not occur.

The fundamental issue with MUI on one extreme and Reaction on the other extreme is customization. MUI has too much, Reaction has too little.

I find arguments like this dubious at best. It's like saying "I like MUI better because I like MUI better". It's wrong as well, because if someone decided to use Highlight color on a background that doesn't give enough contrast you're pooped anyway.

There are more problems with Amiga GUI's that will need to be addressed in further updates. Basically, I think a complete redesign is needed.

And sorry to prove you wrong, but i remember the good old
Amiga days who no serious app was built with MUI [only freeware
or shareware apps] and it was big discuse as IB use MUI as GUI,
it slowing down the GUI ws the main outcome.
Nowdays no seriouse app is still use MUI, because it ISS no serious
app on OS4/MOS more ....[sad but true]
So only shareare/freeware apps use MUI nowdays.
As MUI was createt it was to simplyfi the GUI writing process
for freeware progger.Any proffesional software use his own native GUI.
Not [or most times] the easy way is the best ...

Have you tried Wildfire on 68060/66 with CV64 ?
It is slow like hell in comparing with a native
8bit gui like in Imagine.Both use realtime preview.
Both have many bottons/menues - but wildfire suck in all
MUI aspects - realy Bloatware!

MUI is nice for small/simple GUIs !
Not more.
This is the Reason nearly all "new" prg use it - it is eays
to make a nice simple GUI with it.

This i have said the past 10years - you are welcome to proof me wrong.

One thing I always disliked about MUI and which is the reason why I won't use it is that it is totally unpredictable how things look on another machine. Its over-configurability is a severe handicap. I once wrote a program with it, gave it to someone else and he complained that the GUI looked crap. And yes, it did. You can change all sorts of aspects, whether they make sense or not. People might think that this is "good" and "powerful", I think it's a severe flaw and that it makes writing programs way too complex because you have to be able to cope with anybody's weird configuration.

I am not a fan of Reaction either, and I have discovered its shortcomings as well (especially when it comes to dynamic GUI creation), but for most purposes it is way better suited than MUI. The only reason I thin that people like MUI is that it looks fancy if you configured it, but the version chaos with external classes makes it overly complicated.

if you want to do it correctly for complex GUIs using MUI is much more work than any other AmigaOS GUI system.

MorphOS includes a full version of MUI, and the AROS Zune clone of MUI isn't a limited demo version either, but AmigaOS 4.x only includes a demo version of MUI (or maybe it's an OEM version, but with nearly the same limits as the AmigaOS 3.x demo versions of MUI).

MUI itself, without using any 3rd party classes, is much worse and has much less features than the AmigaOS BOOPSI classes.
MUI just has much more 3rd party classes, and there is next to no MUI software which works without any of them.

If I would have had too use the MUI crap instead of ReAction there wouldn't have been any AmigaOS 4.x port of OWB with GUI at all, at least not from me.

You have to do it for all fonts you installed.

- Implemented text shadow.