Reaction vs MUI (as what concerns the API)

[itix]

Not at the user level so please no flamming wars I decided I'll take some time to slowly learn one of the APIs and would like advice on advantages/disadvantages of both regarding:
- User ability to make your own Boopsi objects and mix them with Reaction/MUI's own ones.

You can do that but you rarely find any reason to use BOOPSI objects in MUI. BOOPSI objects simply are very archaic compared to MUI classes.

- Ability to modify Reaction/MUI's own objects to add features / behavious, just like you can do with subclassing a Boopsi object

MUI subclasses are powerful way to extend your existing MUI classes.

[itix]

Wow, the MUI-lovers are out in force today :-(

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

Sorry but I dont remember any Reaction classes on my Workbench 3.1 install disks.

If AROS and MOS don't support then that is a lack in those OSes. If those OSes didn't support eg. menus, would there be suggestions along the lines of "don't use menus"?

You can download ClassAct/Reaction from Aminet for free.

ReAction software can run under MOS, it's just a matter of the relevant classes being omitted from the MOS CD for some reason.

There are no Reaction classes to omit. They never got written for MorphOS and I dont think we are going to see Reaction for MorphOS in the future. It just does not make sense when MUI is chosen as the official toolkit.

MUI is a third-party hack and rather slow and ugly IMHO, requiring many extra files and not giving any benefit over ReAction. Another case of reinventing the wheel for no real purpose and forcing users to go download and install extra packages instead of using what is already present in the OS.

I know bunch of broken 3rd party MUI classes, just like I know tons of Amiga software which only reboots your Amiga without a warning. However, how many 3rd party Reaction classes you have seen in last 10 years? Is it less than zero?

But anyway, real reason to consider Reaction obsolete is that creating UI with Reaction is laborous. You have to invent wheel again and again if you want standard features into your software and it still hasnt got out from this ID based eventloop hell.

[itix]

- user interface is non standard (e.g. PSI instead of standard screen mode requestor)

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?

[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.

[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.

[itix]

Like QT is for some random desktops like KDE?

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

You had other choices like IBrowse and Voyager.

Reason why ClassAct/Reaction never really took off is they never understood what made MUI so popular.

[itix]

Well, you can turn it off and just create your own UI with MUI or whatever. Can one do that with OWB?

Turn it off, exactly how? And when I turn it off how its display compares to, lets say, Links?

[itix]

MUI is nice, but it's also ridden with annoyances. just to name a few:
* Too bloody many options, why do I have to configure each and type of "box" or "list" or whatever individually for each and every class? Why is there no cascading of styles? "Apply this to all string input gadgets"

Ideally there should be only one string input class and all 3rd party string input classes inherit style from String.mui. They dont however.

But good point.

* No overview of which MUI apps that have individual settings, have to check this manually in env:mui/envarc:mui, and also (iirc), no way to set MUI settings for a certain app back to default settings (other than deleting the corresponding file in envarc:mui/env:mui

Unless you start that application and from its MUI settings you select "Restore defaults". But yes, good point, again.

* No quality control of third party classes whatsoever, no official "approved" list, no warnings from the system when well known broken classes are called upon.

In practise it would rule out all MUI classes not maintained by the MorphOS team.

* Legal situation that only favours MorphOS.

"Nopeat syö hitaat". (Old Finnish saying.)

[itix]

Programming GadTools/BOOPSI is not easy. You have to do a bit of reading upfront, but after your second program you have learned all the shortcuts and you don´t have to think about the GUI much and can concentrate on the real code. I don´t recommend copying GUIs from Windows in GadTools though.

Let me guess: your GadTools applications have one big eventloop where you control all possible events using switch/case construct?

And let me guess more: you copy/paste your GUI engine from your previous projects because you can not get arsed to write all that code again and again? It probably implements your own CloseWindowSafely(), CreateGadgetXYZ(), MyAddGadget(), MyRemGadget() and half of Intuition re-implemented because low level Intuition calls are, well, low level?

And probably because you never heard about screennotify.library your window blocks Workbench from closing when user tries to change resolution? You probably dont support snapshotting or iconifying your windows, either. And of course you dont offer localization option because localized strings probably would exceed allocated space and you can't be arsed to TextLength() every UI string when calculating your UI layout. You do calculate your UI layout runtime, don't you?

I really appreciate your enthusiasm. I have written fully scalable GUI engine using GadTools and only in 68k asm. It was really good as it supported most of MUI features and was blazingly fast. But when localized strings didnt fit to their allocated space anymore I realized I was only reinventing wheel. Only just worse as my GUI engine still didnt allow tweaking GUI layout easily, so why bother... instead I started writing MUI applications in 68k asm

[itix]

No, speed is not the big issue - memory consumption is.

It is true. When I had Internet on my unexpanded Amiga 1200 I had to use AWeb only. After launching Miami there was not enough RAM left to run IBrowse or Voyager anymore. With 800kB RAM free I could run AWeb and visit some web sites using 4 colours. Without images though since despite of amazing memory efficieness of ClassAct it didnt help with memory consumpting JPEG images at all.

But pretty much after fast RAM expansion it becomes non-issue. It does not mean much when you have 4 MB fast. You always run out of chip ram first.

[itix]

Yes, isn't that what you want?

Users still have to run their existing software so no, it isn't. However the goal is that users don't have to depend on 3d party classes but everything you need is in the OS.

In this context, that saying makes no sense - MUI and MorphOS too are very much in the slow lane.

It is still better than Reaction which hasnt got any progress since Hack & Patch OS 3.5.

[itix]

... when browsing the web, perhaps.

You make it sound as if web browsing is the only task you'd use the computer for, but then... why on earth bother with an amiga system in the first place?

Hmm... actually you are right there, (apart from coding for fun) I dont see any other use for computers than web browsing. And of course gaming.

And you do know that you can run Miami without _any_ GUI engine?

Not Miami 1.x I had in 1995 or so. Miami 3.x or Miami Deluxe offered chance to run without GUI but I don't think I ever used that version. But why bother when you had 16 MB fast ram which was more than you ever would need on Amiga? :-) In 90s you could run MacOS on Shapeshifter at the same time while browsing the web.

And why really bother when 90% of quality software for Amiga used MUI. Not just good old IBrowse 1.22 I was using but AmIRC, AmFTP and AmTelnet to mention few classics from the 90s.

But maybe you should point out what you can do with Amigas. I even have got an Amiga you can use for demonstration. My Amiga 500 has got only Kickstart 1.3 on it but I can upgrade Kickstart to version 3.1. CPU or memory upgrade is not obviously needed because ClassAct is so efficient (there is 512kB memory expansion already). I guess I should download ClassAct 2.2 from Aminet first. I don't have a hard disk but I know how to split OS into several disks so it is not really issue here. Now, where is that cool application I can run on my Amiga?

[itix]

No, the event loop just gathers enough information to continue. The rest is done elsewhere. But you are obviously thinking that I have written Amiga software after 1995. But I did most of my Amiga development before that. And much of it wasn´t in C.

Then it changes quite lot.

I do adapt to language and font-size. Iconify wasn´t useful in my software and frankly I don´t know what snappshotting means in an Amiga application context. But I do know that there are a million great Amiga programms that don´t use MUI or Reaction.

Sure there are and I dont want to mockup that old software. Programmers did their best with tools they had available. But this was almost 20 years ago!

[itix]

http://aminet.net/package/dev/misc/AWNP_2-54 and you're all set.

Great, so I can install multifunction pipe on my Amiga 500. What now?