Reaction vs MUI (as what concerns the API)

[lsmart]

MUI/Zune:
[...]
- slow
- memory hog
- many different versions and classes make installation a pain
- user interface is non standard (e.g. PSI instead of standard screen mode requestor)

That was my impression too. But this is the user-level view. The original poster asked for the developers perspective. MUI fans keep claiming that it´d be so easy and flexible. I´d love to give my perspective on this, but I only coded GadTools and BOOPSI back in the day. I wrote a small Reaction GUI recently, but not enough to tell if it really has a serious advantage to the classic way of writing Amiga GUI, which actually was very straightforward and had all the gadgets my programs ever needed!!!!

[matthey]

In MorphOS PSI uses the standard screen mode widget, the very same widget what screen requester is using ;-)

Do you happen to have a screenshot from Reaction screenmode widget?

PSI doesn't use the standard asl.library screen mode requester under AmigaOS 3.x. Reaction leaves it up to the programmer but most use the standard screen mode requester which follows the Amiga User Interface Style Guide. Maybe MOS does something different but then it isn't AmigaOS and has redefined the user interface also. I prefer the AmigaOS and Reaction way as it's straight forward and less cumbersome to open a screen.

@Tcheko
PSI takes about 5 seconds to open it's window with my 68060@75MHz. That's just sad. Enough said.

[kolla]

Both suck immensely.

[Tcheko]

PSI doesn't use the standard asl.library screen mode requester under AmigaOS 3.x. Reaction leaves it up to the programmer but most use the standard screen mode requester which follows the Amiga User Interface Style Guide. Maybe MOS does something different but then it isn't AmigaOS and has redefined the user interface also. I prefer the AmigaOS and Reaction way as it's straight forward and less cumbersome to open a screen.

@Tcheko
PSI takes about 5 seconds to open it's window with my 68060@75MHz. That's just sad. Enough said.

Is it more 4s or 6s?

Perceived time worth nothing.

[itix]

Reaction leaves it up to the programmer but most use the standard screen mode requester which follows the Amiga User Interface Style Guide.

Problem is standard requester is not always what you want. You may wish to embed requester into your window or have custom options there.

Take a file browser as an example. With MUI's filepanel class you can attach standard file requester features into your software without using ASL requesters. It is useful for image viewers for example. If you use GadTools you have to build your own file panel using its crappy listview gadget.

Neither you can have your own GadTools widgets. Your only option is going BOOPSI which again leads you into Reaction or MUI.

[itix]

PSI takes about 5 seconds to open it's window with my 68060@75MHz. That's just sad. Enough said.

Btw I saw your comment on another thread. I think you didnt understand purpose of PSI.

PSI is used to manage public screens for MUI software. Instead of re-implementing screen settings into every MUI application you use PSI to define what screen is used for each program.

When I implemented my BBS offline reader using GadTools aeons ago I had to implement screen mode selector (button which opens ASL screen requester), public screen selector and manager to manage my public screens. And this all have to be re-implemented into every software. And of course every software impements it always differently so behaviour is not consistent. Only advatage is that you get your standard ASL requester but screen management is different and re-implemented for each program.

Another advantage with MUI is that you get many other features as a standard: commodity support, Rexx port, iconify support (configurable as an icon or tools menu), standard fonts and many more. In GadTools application you can only read GfxBase to get your system font (how many implement it properly without potential race condition btw?) or use what is provided by default in your Window rastport. But you still dont get small/large font option and if you want configurable fonts you have to code it all yourself.

That is after all biggest gripe with GadTools. To support basic features properly you have to write thousands lines of code. When I converted good old SnoopDos to Snoopium (SnoopDos with MUI GUI) I could get rid of lot of old support code. MUI GUI version was not only much smaller than the original GadTools version but it was also much faster. Faster because due to reduced code size I could easily redesign its event management.

[matthey]

@Tcheko
I apologize. I tried again and PSI came up nearly instantly this time. It must have been that CPU intensive task I had in the background slowing things down :O. MUI does seem to be slower although a fast processor makes it less of an issue.

Problem is standard requester is not always what you want. You may wish to embed requester into your window or have custom options there.

True. The MUI way is powerful but it is also different from the standard AmigaOS user interface, slower and less obvious. A good example is in this thread...

http://www.amiga.org/forums/showthread.php?t=56505

Take a file browser as an example. With MUI's filepanel class you can attach standard file requester features into your software without using ASL requesters.

I don't see anything wrong with asl.library requesters. They are somewhat limiting in order to have a standard user interface.

If you use GadTools you have to build your own file panel using its crappy listview gadget.

Gadtools in primitive and was only meant to suffice until boopsi/Reaction became more powerful. Boopsi/Reaction/Datatypes is good but never got finished.

[lsmart]

Is it more 4s or 6s?
Perceived time worth nothing.

Even 2,5 seconds is too slow for opening a simple window with hardly any data in it. Furthermore percieved time is actually quite relevant, when you are talking about GUI systems, maybe even more that the actual time measured.

[takemehomegrandma]

ReAction is the official AmigaOS GUI, this applies to both 3.x and 4.x.

The vast support from third party developers made MUI the de facto standard Amiga GUI a long time before Haage&Partner and Hyperion gave things a try. This massive support from developers came from MUI being so easy yet so powerful from a developers point of view (which answers the original post in this thread). Go back and look what people have said about it over the years. Why did Stefan Burström choose MUI for IBrowse for example? It has simply been what most developers prefer!

The reason Haage&Partner (and later Hyperion) used something else, was for intellectual property and money reasons. Technology had probably nothing to do with it at all. This is also yet another example of Hyperion's "OS4" product having to settle with the left-over Amiga standards, after MorphOS already secured the best ones.

From a user's POV, MUI is available for all *miga OS's, and offer great flexibility and level of customization. From a developers POV, MUI is the easiest and most powerful GUI to work with. And don't take my word for it, listen to the testimonies from all the developers who used it during almost two decades.

The choice should be fairly easy!

[Piru]

ReAction is the official AmigaOS GUI, this applies to both 3.x and 4.x.

Not quite. AmigaOS 3.0 and 3.1 official GUI is gadtools. ClassAct was some obscure GUI toolkit needed bu some random applications such as AWeb. It was inferior compared to MUI back then already and making it official GUI toolkit for later AmigaOS versions didn't change that fact.

[Karlos]

Strange you should say that as just this very evening I booted up a NOS Escom A1200 with Workbench 3.1, which had "MUI-AT" drawer with a readme that said "MUI 3.2 Amiga Technologies Edition".

No Reaction in sight........

Karlos was here with me and can confirm this as it was he who noticed it first.

Yep. I guess it was to support the included network software?

[Tcheko]

Not quite. AmigaOS 3.0 and 3.1 official GUI is gadtools. ClassAct was some obscure GUI toolkit needed bu some random applications such as AWeb. It was inferior compared to MUI back then already and making it official GUI toolkit for later AmigaOS versions didn't change that fact.

Simple benchmark with Aminet to confirm Piru's quote.

How many search hits with words : MUI, ClassAct, GadTools, Reaction

MUI scores 793
ClassAct scores 34
GadTools scores 46
Reaction scores 32

Damn. MUI is #1. It can't be that bad then...

Btw, latest OWB using MUI for OS4 looks really promising. And DigiBooster 3 beta 18 too. ^^

[itix]

I tried again and PSI came up nearly instantly this time. It must have been that CPU intensive task I had in the background slowing things down :O. MUI does seem to be slower although a fast processor makes it less of an issue.

MUI is always slower than simple GadTools based applications. I have seen MUI application running on Amiga 500 @ 7MHz 68000. It is not fast. But then MUI includes an automatic layout engine which takes screen aspect ratio, font sizes and window/screen space into account. There is much more computation involved in MUI window layout.

True. The MUI way is powerful but it is also different from the standard AmigaOS user interface, slower and less obvious. A good example is in this thread...

http://www.amiga.org/forums/showthread.php?t=56505

I am not so sure. Because MUI preferences dialog is the same for all MUI applications. Once you learn to use it you dont have to re-learn it for every application. It is always in the same place, it always works in the same way.

I don't see anything wrong with asl.library requesters. They are somewhat limiting in order to have a standard user interface.

In PSI it would mean that you have PSI dialog and then in this PSI dialog you have to open screen mode dialog to select screen mode. It is not necessarily practical because I'd like to see what screen modes are available without really going to select one.

Gadtools in primitive and was only meant to suffice until boopsi/Reaction became more powerful. Boopsi/Reaction/Datatypes is good but never got finished.

There never was Reaction in C= AmigaOS. They only had couple of BOOPSI classes. But it is not problem for MUI. You can have BOOPSI classes embedded in MUI application. Classic example here is colorwheel.gadget used in MUI settings. And not only that -- also String.mui class in MUI 3.x is the original BOOPSI string class and it is actually reason why built-in String class in MUI feels non-standard (it lacks some standard MUI gestures) and various 3rd party replacements were written.

[lsmart]

[...] some random applications such as AWeb.

Like QT is for some random desktops like KDE?

AWeb was something you had to install in 1995. AWeb was the modern internet.

[Fab]

Like QT is for some random desktops like KDE?

AWeb was something you had to install in 1995. AWeb was the modern internet.

And can you name any other significant application using classact/reaction for 3.x? I can't.

[lsmart]

And can you name any other significant application using classact/reaction for 3.x? I can't.

I just think that we are reading pointless bashing instead of a well balanced analysis here.