»

[Karlos]

I was thinking about something earlier today.

Imagine, if you will, a library compiled for OS4, MOS and AROS.

This library abstracts the common MUI and Reaction (ie those of comparable functionality) classes behind a common interface. In addition it abstracts the event handling and other mechanims involved behind a simple, consistent API.

A user of the libray can use its functions to open their windows, add gadgets, modify them, query them etc.

I realise this isn't going to appeal to hardcore fans on either side of the GUI divide, but think of the advantage to the common middle ground programmer who wants to write applications quickly, without having to choose one over the other (MUI in particular is not everybodies cup of tea).

So, what do you guys reckon? It's a worthwhile job for the open amiga team if you ask me :-)

[Lo]

Nice Avatar!
But it conflicts with your question? MOS?
Yes, It would be nice! :-)
-edit-

doesn't look like that blue butterfly is giving up soon!
:-P

[Karlos]

Lo wrote:
Nice Avatar!
But it conflicts with your question? MOS?
Yes, It would be nice! :-)
-edit-

doesn't look like that blue butterfly is giving up soon!
:-P

Well, it's only a wee joke and supposed to represent the 'conflict' between the two camps, which is why neither side is winning or losing. Anybody who's known me for long can verify I'm not anti MorphOS or its userbase.

Back on topic, I think the above idea has merit. I am aware of technical differences between MUI and Reaction in terms of threads etc (MUI does its gadget work in the context of the applications thread, whereas Reaction does so on the input.device thread), but a good abstraction layer should be able to cope with this.

[bloodline]

Well, it's only a wee joke and supposed to represent the 'conflict' between the two camps, which is why neither side is winning or losing. Anybody who's known me for long can verify I'm not anti MorphOS or its userbase.

Yes your Avitar *here* is an amusing joke...

This is less so...

[Karlos]

Are you serious?

The avatar I made here wouldn't fit. It's still just a joke dude, check the tag line there. Big deal the dude with the chaincannon won the animation allowing me to squeeze it into 5k. So am I an anti-MOS troll now then?

[bloodline]

Karlos wrote:
Are you serious?

The avatar I made here wouldn't fit. It's still just a joke dude, check the tag line there. Big deal the dude with the chaincannon won the animation allowing me to squeeze it into 5k. So am I an anti-MOS troll now then?

Fair point, carry on.

[iamaboringperson]

That's what I've been talking/thinking about for a long time.

I think it's a great idea, and I honestly believe it can be done.


It would be nice to have a kind of C++ touch to it, if you know what I mean! ;-)

[Karlos]

iamaboringperson wrote:
That's what I've been talking/thinking about for a long time.

I think it's a great idea, and I honestly believe it can be done.


It would be nice to have a kind of C++ touch to it, if you know what I mean! ;-)

I getcha :-) As it goes, however, the existing amigaOS shared library thing is not an ideal candidate for a C++ system.

My take is to go for a normal shared library approach (OS4 version could use an Interface instead) and provide two headers.

Specifically there could be a opengui.h for C abd opengui.hpp for C++.

The latter could use some class wrappers and factory methods and such for people who prefer the paragdim.

More than likely, a small stub link library might be required - ideally what we need to do is to prevent the opengui header (that is the user header) from having to include any mui or reaction stuff. Only the library source should do that.

In other words, the abstraction would be total.

Abstraction techniques are kind of my thing but unfortunately MUI and Reaction are not.

[iamaboringperson]

I'm okay with BOOPSI and Intuition(and GadTools I suppose), but I'm not so great with MUI.

I would absolutly love to see an abstraction library. It might be a set of files with one that includes them all(one ring to bind them all). :-)

I think if we were to look at the similarities between the different systems we could map out which functions can be used in common between them.

Data structures might need to be unique to this new gui thing.

I imagine compareing two string gadget(as an example) classes, and looking for similar methods etc. and then writing new functions that will in turn call either of the MUI or ReAction functions.
It might be a bit inefficient to begin with, but with faster machines in the futre it shouldn't matter too much.

[Karlos]

iamaboringperson wrote:
...
I think if we were to look at the similarities between the different systems we could map out which functions can be used in common between them.

That's the basic idea, yes. However, by designing an API 'from scratch', we can get away with matching up slightly less compatible classes from each system since we define what access level the end user has. Additionally, in each specific implementation, we can fill in the gaps to make the overall behaviour consistent.

Realistically we need to get the common buttons, menus, lists, scrollers, choosers and other gui elements under our umbrella. Support for more exotic classes (and for MUI this is quite a lot, I guess) is of lesser importance to the target audience.

Data structures might need to be unique to this new gui thing.

Well that's an implentation detail and is probably inevitable as most abstraction layers need to track data not belonging to the layer beneath.

Such things should, wherever possible, be hidden from the end user. What most people want are simple methods for opening windows, creating gadgets, binding them and suchlike. Our handles to said gadgets can be abstract (a pointer or whatever) that is given as an argument to our functions.
A C++ version would simply use a wrapper class for this instead.

Eg C interface

OGWindow* guiWindow;

guiWindow = OGWindow_Create( ... );

if (guiWindow!=NULL && OGWindow_Open(guiWindow) == TRUE)
{
/* stuff here */
}

A C++ version could look a little different, depending on how OOP you want it to be...

OGWindow* guiWindow;

guiWindow = OGWindow::Create(..); // factory method

if (guiWindow!=0 && guiWindow->Open() == TRUE)
{
// ...
}

Both versions would offer the same abilites, just differ in how they are presented to the programmer.

I imagine compareing two string gadget(as an example) classes, and looking for similar methods etc. and then writing new functions that will in turn call either of the MUI or ReAction functions.
It might be a bit inefficient to begin with, but with faster machines in the futre it shouldn't matter too much.

Well, the overhead is far smaller than you might think and it's usually not time critical either. How many people would notice a delay of an additional hundred clock cycles after clicking something for a forwarding function that does a little interim work?

[bloodline]

One idea bouncing around the AROS Team right now is to build a reaction wrapper for Zune (MUI)...

Thus, one would be able to run Reaction apps in Zune (MUI) :-)

[Kronos]

Realistically we need to get the common buttons, menus, lists, scrollers, choosers and other gui elements under our umbrella. Support for more exotic classes (and for MUI this is quite a lot, I guess) is of lesser importance to the target audience.

Sorry, but I have to disagree here ;-)
The 3rd-party-classes are one of the biggest arguments for MUI (and sometimes the
biggest against it :-o ).

Coding a "real" MUI-app without useing those, is next to impossible, unless
you create your own classes inside your project, which would most
likely break the compabilty with your ReAction-layer.

MUI and ReAction are just to far apart for your idea to turn into reality(without
adding lots of bloat).

Better solutions:
a) use MUI/Zune which is (will be) available for all 3 plattforms.

b) write some headers that make porting between MUI and ReAction easier (but
would still result in different exes).

c) create a new GUI-lib useing only the 3.1 API (like that NewGUI,Triton, StormWizard,
BGUI .....), and make it open-source.

[Matt_H]

I think this would be spectacular in building a bridge between the two camps.

Now if I only knew how to program...

[iamaboringperson]

Matt_H wrote:
I think this would be spectacular in building a bridge between the two camps.

Now if I only knew how to program...

Three camps!

And would you like me to recommend a good programming book? ;-)

[Matt_H]

Doh! Yes, three.

*Kicks self*