@ppcamiga1

You often make the statement (even when not relevant to a given discussion) that someone has to provide some form of working MUI clone.

Why? What is it about MUI that is so overbearingly important?

MUI, Reaction and to be honest, every other BOOPSI evolution, while pretty impressive back at the start, are not what I would consider optimal solutions to GUI components in the 21st century.

Before anyone looks for their pitchfork, allow me to elaborate. The killer feature of BOOPSI is that it permits runtime definition of new "classes" by the extension and modification of existing ones. Make no mistake, this is quite a feat but the price you pay for it is pretty steep. It's an opaque macro-fest that hides a dispatch mechanism for method calls and property access that's rather indirect and inefficient.

It is my contention that the majority of software - certainly since NG - that uses MUI and Reaction make no use of this dynamic ability to define new classes at runtime and instead rely on loading classes that have been predefined and distributed but they continue to rely on the scaffolding that supports it.

If all you really need is to be able to load predefined classes that other developers have made, there are many better ways to go about it. By far the simplest is to define a C compatible structure that has all the expected member properties and appropriately initialised function pointers for all the method type behaviours. Each function pointer accepts the structure it's embedded in as parameter 0 (this in C++, or Self in OS4 interface parlance) and this can be hidden in a DoMethod type macro, or even just a custom compiler attribute like OS4 interfaces use (though not super compatible).

Each instance of this structure is an instance of the corresponding gadget. Your .class just needs to manage the life cycle of these and provide their default properties and behaviours. If you are solely dependent on loading existing classes only, you are good to go.

In the unlikely event you do need dynamic extension of existing classes, you aren't shit out of luck either.

My making sure the library functions of the class that [i]create[/] a new instance can be optionally given a size parameter, you can allow for extending the class with new properties (in essence you give it sizeof(struct MyExtendedClass) which is your new derivative). As the .class code is responsible for the memory allocation, it can keep track of that.

If you want to change the behaviour of one of these extended instances at runtime (and why wouldn't you?), you can still replace the behavioural function pointer with your own, that can add whatever fluff you want around the original call, or even replace it completely. All you need to do is to ensure that your extended structure retains a copy of the original method pointer you are overriding (if not replacing it completely).

Doing a method call by dereferencing a pointer in the structure is way less indirect than what a BOOPSI DoMethod call traditionally does and the whole mechanism is far easier to maintain and debug.

There's a thought for you.

_________________
Doing stupid things for fun...

@Karlos


Most MUI Applications have tons of internal classes.

That is the key feature to simplify the UI creation. For example the list class is usually subclassed to specify the contents, activate inline editing and context menus.

Usually every window is a subclass of window.mcc and so on.

In addition usually subclasses of area.mcc are used to render stuff. For example the playfield of a game. My game PixelCross renders using a playfield class, which is also used internally multiple times to handle the manual and tutorial.

The game wordy is using a class for the playfield, too. It is also used multiple times. E.g. in Preferences. Also each character box is its own class having tags to set and get colors, characters, modes, size and so on.

Grunch has about 30 internal classes. Ambient is using around 40 internal classes.

Fact is if an application is not using internal mui classes, it is very simple or the developer has no clue how to code MUI. With internal classes these components talk with each other using notifications and methods. No additional code required.

Last edited by geit on 01-Mar-2024 at 01:35 AM.

@geit

Quote:

Usually every window is a subclass of window.mcc and so on.

Every window?

Quote:

Also each character box is its own class having tags to set and get colors, characters, modes, size and so on.

Are you confusing classes with instances? I'm talking pure OO here not BOOPSI parlance.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @ppcamiga1 You often make the statement (even when not relevant to a given discussion) that someone has to provide some form of working MUI clone. Why? What is it about MUI that is so overbearingly important?

I'd see it's because of the existing software base. He's been referring that if someone makes an Amiga compatible operating system on new CPU architectures, it would need a native MUI clone (or port of an existing branch).

MUI has been a de-facto standard on Amiga for decades now, and most later days and modern software have been written using it. For example, vast majority of Internet related programs are MUI based.

So, if an Amiga compatible operating system is written or ported to x86, ARM, or whatever, it would need a MUI implementation to get existing programs ported and get things started at all in practise.

Writing or adapting a whole new GUI toolkit would be a huge job, and then to get some software written on it too... it doesn't look realistic with the resources Amiga has nowadays.

_________________
- The wiki based MorphOS Library - Your starting point for MorphOS
- Software made by jPV^RNO

@Karlos

While not every window or gadget may have a subclass you do want to subclass for a few major ones in a application (and the application object itself).

Stuff like setting up and maintaining the contents of a window/group setting up notifications for UI events etc.
You also may need to have area.mui based classes that do custom GFX and/or maintain the user data of your app.

All a bit cumbersome, but clearly OO.

Sure if you ware to develop a GUI toolkit today you wouldn't do it based on BOOPSI or you would atleast make a "modern" wrapper for the public facing API (like it has been done for ObjectiveC), but such a system has little chance of success without the limited number of developers seeing a clear reason why they should ditch the MUI they know.

None it would change existing apps that use MUI and won't get updates anytime soon.


@Geit

I'd say it is closer to 140 classes for Ambient

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

Stuff like setting up and maintaining the contents of a window/group setting up notifications for UI events etc

Why is that subclassing and not just parametrisation/composition?

_________________
Doing stupid things for fun...

@Karlos

Quote:

Before anyone looks for their pitchfork, allow me to elaborate. The killer feature of BOOPSI is that it permits runtime definition of new "classes" by the extension and modification of existing ones. Make no mistake, this is quite a feat but the price you pay for it is pretty steep. It's an opaque macro-fest that hides a dispatch mechanism for method calls and property access that's rather indirect and inefficient. It is my contention that the majority of software - certainly since NG - that uses MUI and Reaction make no use of this dynamic ability to define new classes at runtime and instead rely on loading classes that have been predefined and distributed but they continue to rely on the scaffolding that supports it.

This is strange aspect to "call out", as surely it's the killer feature of most object orientated GUI systems.

Every one of my reaction based application uses custom BOOPSI classes, even if most of the work is done with the existing public ones. The Gtk apps I've worked also use custom classes.

AS to the opaque Macrofest, I don't use the macro based GUI building process prefering explicit calls to NewObject() as in the end it's much easier to debug.

I would think the bigger distinction between "modern" and "retro" GUI systems is event handling, modern tend to use callbacks , retro tend to use loops.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Karlos

one and only thing from amiga os that still has some value
everything below amiga gui and graphics should be cut off and replaced by unix
as long as you don't have working mui clone tou have nothing
and there are no reasons to switch to x86/arm
no compatible amiga gui just use windows/android on x86/arm

@ppcamiga1

I happen to know that Qt was quite heavily inspired by MUI in its early days.

Last edited by kolla on 01-Mar-2024 at 05:04 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Didn't they have to "hack in" MUI to get Odyssey web browser working on OS4?


I have zero complaints in MorphOS with MUI. Very customizable from application, screens, and ambient. Have a pretty sweet looking and running system.

@broadblues

It's not that I don't appreciate BOOPSI and what it can do. Far far from it. I just think there are potentially much better implementation of the concept possible. The legacy implementation is really Rube Goldberg.

Anyway it appears I was wrong with my main contention that most software does not make use of the runtime class definition feature. This is an impression forged from years of using both systems. Though the examples given in MUI sound confused as if subclassing has been the hammer for every nail.

Last edited by Karlos on 01-Mar-2024 at 09:44 PM.

_________________
Doing stupid things for fun...

@Karlos
OOPs, C= messed up again. BOOPSI is barely usable on a 68000@7MHz with 512kiB which is a horrible fit for a computer designed to use the cheapest CPU and the least amount of memory possible. Did Amiga developers tell upper management that OO is anti-modular and anti-parallel in nature?

Carnegie-Mellon University stopped teaching OOP as part of their basic CS curriculum with the argument that it is anti-modular and anti-parallel in nature. Verification is also mentioned as important which may suggest OOP is more difficult to verify and debug? Performance reduction from indirect branches isn't even mentioned. There was academic arguments in the comments after the announcement at the following link.

https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/

They dropped OO Java as the initial language for CS students, despite "the fact that James Gosling, the developer of Java, is an alumnus of our computer science PhD program". Rather than choose a related non-OO JAVA like language that is also a descendant of ALGOL like C, they chose Python which also supports OOP but is not required? Is there a garbage collection requirement and performance is not an issue because the garbage collection can be done in parallel by another core?

BOOPSI is modular except for the base classes built into intuition.library. The add-on modules for Reaction and MUI are libraries in files which can be loaded or expunged as needed. I don't even see how parallelization is any worse. I believe there is more overhead than procedural programming including indirect branch overhead. There is also the inheritance aspect of objects which creates dependency chains reducing code sharing opportunities (perhaps confused with modularity in arguments above?). Debugging may also be more difficult. Does the advantage of OOP programming being easier for humans offset all these disadvantages? Maybe not but I don't see BOOPSI as being a particularly bad OOP implementation. BOOPSI is often criticized but how much bigger and slower would an OOP AmigaOS GUI using hyped C++ be?

@matthey

Quote:

matthey wrote: @Karlos OOPs, C= messed up again.

Exactly.
Quote:

BOOPSI is barely usable on a 68000@7MHz with 512kiB which is a horrible fit for a computer designed to use the cheapest CPU and the least amount of memory possible.

Well, nothing to wonder here: the OOP implementation chosen by Amiga engineers is one of the worst in terms of efficiency...
Quote:

Did Amiga developers tell upper management that OO is anti-modular and anti-parallel in nature? Carnegie-Mellon University stopped teaching OOP as part of their basic CS curriculum with the argument that it is anti-modular and anti-parallel in nature. Verification is also mentioned as important which may suggest OOP is more difficult to verify and debug? Performance reduction from indirect branches isn't even mentioned. There was academic arguments in the comments after the announcement at the following link. https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/

I'll read it when I've some time, thanks.
Quote:

They dropped OO Java as the initial language for CS students, despite "the fact that James Gosling, the developer of Java, is an alumnus of our computer science PhD program". Rather than choose a related non-OO JAVA like language that is also a descendant of ALGOL like C, they chose Python which also supports OOP but is not required? Is there a garbage collection requirement and performance is not an issue because the garbage collection can be done in parallel by another core?

Those aren't arguments against OOP: those are just single cases that cannot be generalized to the global cases. Unless you prove it, of course.
Quote:

BOOPSI is modular except for the base classes built into intuition.library. The add-on modules for Reaction and MUI are libraries in files which can be loaded or expunged as needed. I don't even see how parallelization is any worse. I believe there is more overhead than procedural programming including indirect branch overhead. There is also the inheritance aspect of objects which creates dependency chains reducing code sharing opportunities (perhaps confused with modularity in arguments above?). Debugging may also be more difficult. Does the advantage of OOP programming being easier for humans offset all these disadvantages?

Yes. Greatly. OOP offers a very simple and efficient (yes!) way when modeling a certain set of problems, which are quite common.

How do you want to model a GUI infrastructure WITHOUT using OOP concepts?

If you want replace one thing with another, I don't see any problem, but... you should show the advantages of the new solution compared to the new one.
Quote:

Maybe not but I don't see BOOPSI as being a particularly bad OOP implementation.

Really? It's obvious...
Quote:

BOOPSI is often criticized but how much bigger and slower would an OOP AmigaOS GUI using hyped C++ be?

On the contrary: it would have been much slimmer and faster using proper data structure definition / "extension" AND (especially) using VMT.

How much it costs to dynamically define a property / attribute of a class even if you already know upfront all its data member and types?

How much it costs to dynamicaly checking the method id against the known / supported ones and finally execute its once, compared to the single indirect jump of a VMT?

Not even talking here about the chance of making mistakes, since you're doing both operations... manually. Whereas the OOPs has all checks automatically performed at compile time.

Really, it's a no go. And a non-sense.

@matthey

- no 512k Amiga shipped with BOOPSI
- on 1MB Amigas you can use the prefs (using BOOPSI classes) and datatypes (BOOPSI again)
- code being "modular" or "parallel" is down to design decisions that have veery little to do with OO or not
- "xxx is evil" rants that can be found against any language or concept are really about the author not understanding when not to use a specific feature
- when BOOPSI was cooked up (late 88/89 I'd guess) C++ was still pretty rough in term of working compilers if these even existed and not just pre compilers like the one in SAS C 6.x which generated code bloated beyond believe
- OO is about making complex code easier to understand which goes against the argument that it would be harder to debug

So sure TODAY one would do a GUI TK in C++ (or similar) even when targeting a 1MB 68k but thats not what would have been smart 30+ years ago.

@Karlos
Most trivial MUI examples don't use subclasses but just Application_ReturnID which puts everything into a main event loop just like it would have been done with no BOOPSI vanilla IDCMP based program control.

Once you go non trivial that will turn spaghetti code

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Maybe there's some impedance mismatch in our terminology. For me, the only reasons to subclass an existing class are:

1. As part of implementing a concretisation of an abstraction.
2. To change and/or augment an existing class to add new behaviours in a manner that remains backwards type compatible with the original.

If I want a window class, I should just be able to use the default implementation and parameterise it on construction with the basic window configuration I need. I should only need to subclass it if creating a *new* type of window. Obviously a single window class can't encapsulate every conceivable specialisation so that's where extension comes in.

If I'm subclassing the default window because I want a window class with some specific gadget hierarchy something just seems really off. It sounds almost like cargo cult and a total lack of appreciation for what inheritance is and does.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: If I'm subclassing the default window because I want a window class with some specific gadget hierarchy something just seems really off.

If you want to just do that you don't need a subclass. But you will need some external function * (or class) to react to those gadgets and that function may need to change something about that window depending on those actions. You end up with convoluted code that will require several global variables.

If you want all the actions of those gadgets to be contained there you do need to subclass.
Thats what pretty much every modern UI TK does these days regardless of language used. Heck even SwiftUI with all it's state driven logic kinda boils down to that.

It's not the only solution, it's just the one that makes most sense (for non trivial dynamic UIs that is).


Edit:
* in trivial apps that function would be the event loop in main() as used by most of the MUI examples

Last edited by Kronos on 02-Mar-2024 at 07:47 PM.
Last edited by Kronos on 02-Mar-2024 at 07:46 PM.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

The obvious choice from the design pattern playbook would be to use observers/listeners, as your OO replacement for callbacks. That's a very standard approach to pairing up event source/sink without creating awkward coupling between them.

_________________
Doing stupid things for fun...

@Karlos

Just wanted to add that on morphos objective-c allows easier subclassing.
https://www.morphos-team.net/guide/objective-c

@matthey

Quote:

matthey wrote: Carnegie-Mellon University stopped teaching OOP as part of their basic CS curriculum with the argument that it is anti-modular and anti-parallel in nature. Verification is also mentioned as important which may suggest OOP is more difficult to verify and debug? Performance reduction from indirect branches isn't even mentioned. There was academic arguments in the comments after the announcement at the following link. https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/

Matt, why are you spreading completely false information? Just to discredit OOP, which you clearly don't like?

The only relevant thing from the above link is that they switched to a functional programming language. Which we know that are very good, when used in their pure nature (e.g.: immutability of data), to be scaled -> compute in parallel (so, make use of multiple cores).

This is the ONLY relevant statement here!

However this absolutely does NOT imply that an OOP language (and OOP, in generale, as you false reported) is anti-parallel. And even anti-modular. That's a logic fallacy!

BTW, since introducing a functional language isn't great at defining data structures, then they decided to also add a classic, imperative programming language.

Which, again, does NOT imply that an OOP language isn't good at that.

So, basically they removed an OOP language for teaching, but this means absolutely NOTHING about the assumed anti-modularity and anti-parallelability (!) of OOP. That's a completely wrong conclusion that you came up (I don't know if because you believe it, or on purpose).

The only other relevant thing is that their students now have to learn TWO programming languages AND they still lack the OOP which is a FUNDAMENTAL cornerstone in computer science (very widely spread and adopted). Welcome to the non-sense...

@Kronos

Quote:

Kronos wrote: @matthey - when BOOPSI was cooked up (late 88/89 I'd guess) C++ was still pretty rough in term of working compilers if these even existed and not just pre compilers like the one in SAS C 6.x which generated code bloated beyond believe

I've started OOP on 1989, with Turbo Pascal 5.5: it used single inheritance and VMT (of course!): it was very compact, required a small footprint in memory, and very quick.

I've developed a hell of things in OOP (even a complete CUI framework mimicking Borland's Turbo Vision. And then a GUI one as well) with such language (then with TP 6 and 7) which were running on my Amiga 2000 emulating a PC with IBeM.

That should be enough to understand that OOP is not monster per sé.
Quote:

- OO is about making complex code easier to understand which goes against the argument that it would be harder to debug

+2 & merge!
Quote:

So sure TODAY one would do a GUI TK in C++ (or similar) even when targeting a 1MB 68k but thats not what would have been smart 30+ years ago.

Exactly. Software is much more complex now, so it requires much more resources. That's pretty obvious.

But it was NOT the case at the end of '80s / beginning of '90s.


@Karlos

Quote:

Karlos wrote: @Kronos Maybe there's some impedance mismatch in our terminology. For me, the only reasons to subclass an existing class are: 1. As part of implementing a concretisation of an abstraction. 2. To change and/or augment an existing class to add new behaviours in a manner that remains backwards type compatible with the original. If I want a window class, I should just be able to use the default implementation and parameterise it on construction with the basic window configuration I need. I should only need to subclass it if creating a *new* type of window. Obviously a single window class can't encapsulate every conceivable specialisation so that's where extension comes in.

+2
Quote:

If I'm subclassing the default window because I want a window class with some specific gadget hierarchy something just seems really off. It sounds almost like cargo cult and a total lack of appreciation for what inheritance is and does.

It's not fully clear to me, but... shouldn't using containers + observers solve the problem?

I subclass only when I'm on one of the above two points that you mentioned above. Otherwise, I only use the regular OOP patterns (mostly composition and observers, for what you've reported here).