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!!!!

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

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

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

[lsmart]

It is a well known fact that MUI is far superior to any toolkits from every possible pov.

Well, great then. Discussion over.

Oh wait .. I have to buy a Mac now because: "It is a well known fact that Mac OS X is far superior to any operating system from every possible pov."

[lsmart]

Programs with complex Reaction GUIs don't exist :-)

From the users point of view, a simple GUI is always better than a complex one.

I can see how MUI is superior when it comes to the number of classes and the number of systems it runs on. That was well spoken for. But nobody aparently has used both long enough to speak about the merits of Reaction from a developers point of view. Experience in other feilds show a high probability that there are.

I can only talk about GadTools & BOOPSI from experience. They have extremely low overhead and are completely modular. Your program is small in size and you dont have to make sure that there are certain files in certain places at the users machine (i.e. no worry about BetterListview.mcc, trallala). 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. Windows GUI is overly complex and this will be hard to recreate with GadTools.

[lsmart]

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

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.

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?

I never copy/paste code in bigger chunks. I tend write software modules for re-use.

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

[lsmart]

Maybe OpenStep should be ported to Amiga using Gnustep source code...

This may have been a good idea in 1999, but as it turns out open source hasn`t really caught on in the Mac world and today you would have to ask yourself if there is more than one person that would use it. GNUSTEP itself is a project that is moving slowly and isn't really used much. Porting it to AmigaOS would not make Amiga developers switch API and no new developers will gain interest.
While Objective-C is a great language, the Cocoa Toolkit is evolving and rivals the Java class libraries in complexity and feature creep. It is beyond the might of a single coder to maintain a compatible implementation. Furthermore a lot of the stuff that was added, when Apple bought NeXT is more demanding in terms of performance. Take UAE on MacOS: it has a significant lower frame rate than it's windows counterpart on the same machine. NeXT computers were quite snappy for business use but they were speced with a high-end 68030 at the least. And a NeXT Station did not even do double buffering in games or screensavers to avoid slow movement. Mind we are talking about 4 grey tones in 1024x1024pixels - not truecolor! I guess MUI is significantly faster than GNUSTEP on the same hardware.

If you want to build a great toolkit that will run on an Amiga 1200 you'd better code it in 68k assembly language and limit configurability to fonts and colors only. Then you can do really amazing dynamic interfaces without allocating half of your memory for stack.

 If what you need is just what you see in something like Cygnus ED, you can safely stick to the regular Boobsie Gadtools and forget about the gradients and fancy list/table-gadgets of MUI. At least I won`t miss it.

Heck, in my day  a list/table was a sequence of characters. Why do people now want a whole spreadsheet application in a window that will just list the tracks of an audio-CD?