Reaction vs MUI (as what concerns the API)

[kolla]

AWeb user interface is just plain horrible.

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

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

[kolla]

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

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"
* 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
* 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.
* Legal situation that only favours MorphOS.

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

[kolla]

The only remotely relevant argument that was given so far is about speed, but there's no benchmark to prove it, which means it may just be wishful thinking or propaganda fruits.

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

I've been one of those who prefer ClassAct apps over MUI alternatives, simply becuase with CA options left my system with much more RAM free. Also, the development of CA at the time was much more open than that of MUI, the devs were all easily reachable online. Stuntzi was always away on some bicycle trip or whatever.

[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

[jacadcaps]

puke

Where are your Cocoa apps then? I'd assume you did not write any - easy to bash something you don't know. No Amigaoid toolkit comes close to the Cocoa classes in terms of features, completeness, documentation, etc.

[Karlos]

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

Ick.

Observer and Mediator patterns, ftw

[jahc]

If you want to have a real discussion, try to find areas where reaction is superior (preferably not of the "official" or "someone told me..." kind), and then we can talk.

The only remotely relevant argument that was given so far is about speed, but there's no benchmark to prove it, which means it may just be wishful thinking or propaganda fruits.

Yeah, speed isnt an issue if you're running non-classic hardware. MUI and Reaction feel exactly the same on the next-gen setups I've been using.. everything happens instantly.

Anyway, the focus should be on what sort of functionality they can provide, and whether it can speed up development (through ease or features).

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

[kolla]

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

Yes, isn't that what you want?

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

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

[kolla]

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.

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

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

[jacadcaps]

Yes, isn't that what you want?

Not quite. If we did, we wouldn't be handling MCC key ID requests coming from developers.

[nicholas]

Where are your Cocoa apps then? I'd assume you did not write any - easy to bash something you don't know. No Amigaoid toolkit comes close to the Cocoa classes in terms of features, completeness, documentation, etc.

I prefer C++ to Obj-C.  Cocoa provides a very nice set of classes but Obj-C is from the devil.

I type this from my 17" Macbook Pro 4,1 (and looking over my shoulder at the 3 Cocoa and 2 Obj-C books on my shelves.)

It's easy to bash someone you know nothing about.

[jacadcaps]

I prefer C++ to Obj-C.  Cocoa provides a very nice set of classes but Obj-C is from the devil.

You puked at Cocoa, not Obj-C.

Then again, Obj-C's method invocation is actually pretty close to BOOPSI - just replace [] with DoMethod and use : to separate arguments rather than , That makes it easy to switch to Obj-C/Cocoa when you're a MUI programmer. At least it took me far less time to learn Obj-C & Cocoa than to learn C++ with its imho obscure GUI toolkits like Qt or MFC.

I type this from my 17" Macbook Pro 4,1 (and looking over my shoulder at the 3 Cocoa and 2 Obj-C books on my shelves.)
It's easy to bash someone you know nothing about.

Wrong:
http://dreamolers.binaryriot.org/fuhquake/
http://iconsole.pl