Reaction vs MUI (as what concerns the API)

[Crumb]

When doing low-level microcontroller work, I want C++

Assembly is usually better suited for that.

[Karlos]

Assembly is usually better suited for that.

Some embedded devices are well supported. Amtel AVR springs to mind. Also remember that what is referred to as "C++" on embedded systems is usually a carefully-selected subset of the full language specification.

[bloodline]

Assembly is usually better suited for that.

For PIC work, yes, but my Atmel and ARM microcontrollers are well supported with C/C++ compilers.

With the atmel AVRMega328 (my favourite 8bit), I use a mixture of C and assembler (it has a really elegant ISA)... But withe my ARM M3 chips it is almost 90% C++

On my iPhone Dev work I use obj-c

[bloodline]

I have two of them and they are a joy to read, I just feel "uncomfortable" writing ObjC.  To me it similar to blonde hair and white skin on a woman, does nothing for me.

Ain't choice great?

My tastes in women depend on the woman in question... I've been with my current girl friend for nary 3 years and she's Chinese!

I really understand where you are coming from with Obj-C! I totally hated it, I just couldn't get used to the syntax and the odd terms for things. But I realise now that my biggest problem came from thinking too low level, I didn't like being forced into MVC and Delegate patterns, I didn't realised Obj-C has runtime features I'm not used to in Asm and C++, frankly I just couldn't understand how my classes fitted into the anatomy of a program... It was only after forcing myself to plough on with it (I had to make an iPhone app, failure was not an option) that I got it... I'm by a long way a much better coder for learning the rules that Obj-C demands

[kolla]

So, it seems ClassAct is not much use at all.

Well, there's Grapevine IRC client and AmiFTP - the only native Amiga ftp client that grasps VMS servers.

[nicholas]

My tastes in women depend on the woman in question... I've been with my current girl friend for nary 3 years and she's Chinese!

My wife of four years is a very "exotic" mix: Jewish/English/Argentinean Native/Italian/Spanish/Black Brazillian/Portugese and she grew up in Iran during the war with Iraq.

It's always amusing when she has to fill out a form and it asks her what ethnicity, "too many" is a common answer. lol
 

I really understand where you are coming from with Obj-C! I totally hated it, I just couldn't get used to the syntax and the odd terms for things. But I realise now that my biggest problem came from thinking too low level, I didn't like being forced into MVC and Delegate patterns, I didn't realised Obj-C has runtime features I'm not used to in Asm and C++, frankly I just couldn't understand how my classes fitted into the anatomy of a program... It was only after forcing myself to plough on with it (I had to make an iPhone app, failure was not an option) that I got it... I'm by a long way a much better coder for learning the rules that Obj-C demands

You want to try coding big apps in the stuff I've used professionally since '97. Nothing like ANYTHING you've ever seen before and seriously head mashing.  I hated it for a long time and then one day I fell in love!

[Jose]

I like brunettes don't know why...

Regarding Reaction the biggest stumble I've found so far is that there isn't much documentation! The original ClassAct release on Aminet has some stuff, also the NDK3.9 has descriptions on each class and there are some examples on the DevCD. Should be enouph. There's also a PDF tutorial somone did wich seems more oriented towards OS4 but should be usefull.
MUI docs on the contrary seem to be very good.
I've only read part of the intro on the ClassAct release and it seems every class on Reaction/ClassAct is a boopsi object, wich makes it usable from any other Boopsi object. Someone above mentioned that to use Boopsi classes on MUI you have to encapsulate them in a MUI class so maybe the result is the same, does it work the other way around too, i.e. can you call a MUI class method from a standard Boopsi object ?

Pah, I guess the best way is try both. I might even do some benchmark program thing.
Granted I expect each one to have it's advantages/disadvantages depending on each context.

BTW, regarding complex GUIs with Reaction, I've recently read the Boopsi chapter on the RKRMs and it seems to me that a lot of people jumped into MUI/Reaction without knowing Boopsi, I think if you know how interconnection Boopsi classes work you can do very complex GUIS pretty straightforward, maybe it takes a bit more code to set up your connection objects but it didn't seem that much. And it's very flexible.

Anyway, when I get the time I'm gonna try both that's for sure...

[itix]

Someone above mentioned that to use Boopsi classes on MUI you have to encapsulate them in a MUI class so maybe the result is the same, does it work the other way around too, i.e. can you call a MUI class method from a standard Boopsi object ?

See this for BOOPSI objects in MUI.

It can not be done other way around (embedding MUI objects into Reaction GUI), mostly due to the notification system which does not exist in Reaction.

[itix]

Getting back to the topic (sorry we got carried far away to sideline) I think notification system is one of strong points in MUI API. You can add callback hooks and methods to events so you dont have to mess with this in your event loop. It also allows simple automation of events i.e. when user presses a button MUI could automatically window title for example.

Another difference in MUI is that you can define window or context menus as objects. You dont necessarily have to define static menu structure (but you can if you want to). They can be used to store attributes and they are part of notification system so menu selections can be automated just like everything else. You can expand and shrink menus simply by adding or removing objects from them.

[bloodline]

Getting back to the topic (sorry we got carried far away to sideline) I think notification system is one of strong points in MUI API. You can add callback hooks and methods to events so you dont have to mess with this in your event loop. It also allows simple automation of events i.e. when user presses a button MUI could automatically window title for example.

If Reaction lacks notification then I would consider it obsolete! I think this answers the OP question, MUI is the more modern design.

Another difference in MUI is that you can define window or context menus as objects. You dont necessarily have to define static menu structure (but you can if you want to). They can be used to store attributes and they are part of notification system so menu selections can be automated just like everything else. You can expand and shrink menus simply by adding or removing objects from them.

MUI wins, topic closed

[Karlos]

If Reaction lacks notification then I would consider it obsolete! I think this answers the OP question, MUI is the more modern design.

Actually, if you know how to use design patterns, this is never a limitation. You can wrap an observer mechanism around absolutely anything that needs event handling to be decoupled from the event source, no matter how old and retarded it is.

[nicholas]

Actually, if you know how to use design patterns, this is never a limitation. You can wrap an observer mechanism around absolutely anything that needs event handling to be decoupled from the event source, no matter how old and retarded it is.

Kitab al-Karlos

[Kronos]

@jose

Back in the day (1999-2001) I wrote some BOOPSI-classes for was then (not) known as AmiDraw. Very clumsly lots of code and all I got was a simple toolbar and a special palette gadget.

Those 2 classes are actually also costum classes in the MUI-version even less known as SteamDraw, and while offering more features than the old BOOPSI-variants they only took a fraction of the code to implement.

BOOPSI is primitive, powerfull but still primitive. MUI adds ease of use and to some degree even elegance to that while improving on the "powerfull" part.

[Karlos]

Kitab al-Karlos

Seriously, I cannot recommend that book enough. It's examples are all based on C++ and Smalltalk but no matter which language you use (provided it supports or can achieve basic object orientation), the principles in there can be utilised to great effect. After a while, you see the patterns described therein all over the place, often in interesting combinations. The chances are, you've independently "reinvented" more than one of them without even knowing it. However, once you have seen them formally catalogued (and the book is by no means exhaustive but instead considers the the most fundamental structural/creational/behavioural patterns to which all others can be reduced) and dissected it's very easy to see how to go about solving whatever awkward development job lands on your plate.

[bloodline]

@Karlos

A quick read through, suggests that a fair few of these design patterns are easier to implement with Obj-C... Or at least to me seem more natural in Obj-C than in C++... This isn't a criticism of C++, simply an observation. I submit that this could be due to Obj-C's dependence on the cocoa framework which seems to have been built with only this book as reference! But I feel Obj-C's runtime nature is key here

[kamelito]

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

Kamel