The way to fix 'openamiga'...

[iamaboringperson]

Karlos, i agree...

it would be especially nice with C++ interfaces for all of these

more choice of GUI for the programmer... the OS developer... and the end user...

plus it would be easier and more like other platforms(like borland c++ builder) to develop on

what i would really like is a dev. system like borland C++ builder
that would really help software development on the amiga
just do long as it is MUI/gadtools/reaction independant

[Kronos]

@Karlos

MUI and ReAction work in quite different ways, so creating an abstraction-layer that fits
both would mean loooooots of work, and result in more overhead and offcourse more bugs.

OS4 WILL suffer from that the problems you described anyways, as atleast one of
the contributions is allready bound to MUI.

ReAction has been the official way for years now, but is still only sparsley used, while
MUI is seen as the standard by a majority of the Amiga-coders.

Trying to change that by force will fail, maybe even make coders turn their back.

[iamaboringperson]

And no, ReAction is not based on BOOPSI, but on ClassAct.

ReAction is just another name for ClassAct

and im still pretty sure they are based on BOOPSI
having '.class' '.gadget' and '.image' extentions (am i right here? its been a while since ive used my miggy)

and being opend like libraries, just like boopsi classes can be

[Kronos]

@boring
http://ftp.uni-paderborn.de/aminet/aminet/dev/mui/MUIPlusPlus.readme

Maybe something like that ?

(haven't tried it myself, but looks interesting)

[iamaboringperson]

Kronos wrote:
@boring
http://ftp.uni-paderborn.de/aminet/aminet/dev/mui/MUIPlusPlus.readme

Maybe something like that ?

(haven't tried it myself, but looks interesting)

Remember that not everybody likes MUI, and saying that we should all just use it and shutup, is pure arrogance
people should have the choice

there are other GUI OOP abstraction kits on aminet

what needs to be done, is that all of these should be studied, and the common features/components of each could be included into one cross-gui version
so that it is similar to whats out there already

lets face it: all gui's have similar features, just a slightly different way of implementing and programming for them

so why not produce a standard set of libraries that will work for reaction/classact, mui, and plain intuition boopsi & gadtools

so that it is about choice, and not: "thou shalt use MUI..."

[Kronos]

Why not ?

Because MU does not work like ReAction !!

With ReAction (or plain BOOPSI) you have the gadgets running in the input.device-task.

Good responsivness, but also complete system-wide lockups when a gadget fails is
what you get from that.

MUI on the other hand works more like QT or GTK, where the gadgets run in the task of
the program using them.

The coder has to take care for the responsiness of his app himself, but ta locked GUI will
only lock that one task.

With ReAction you still have to supply your own main-loop and wait for inputevents, while MUI
will setup it's own mainloop on top of your code.

As I said, completly different, and incompatible.

Also, openamiga does not force anybody to use MUI, but only suggest to use parts that are
available for all plattforms. This includes most of the 3.1-API, including GadTools,BOOPSI, or
even simple Intuition-gadgets for the really hard&though.

[iamaboringperson]

Kronos

i understand that MUI and reaction work very differently
but a C++ set of includes would be a way around all of that
you(the application programmer) wouldnt be using the same functions, you would create an object, such as a button, asign some attributes to it, and get the input in some other OOP way...
the MUI/gadtools/reaction interfaces would be completly invisible to the programmer

[Kronos]

Problem is that if I would want to do a wrapper around MUI, I would make it
compatible with QT or GTK, so it would be of some real use ....

But thats lots off work and in the case of ReAction/MUI you should also remember
that there are lots of MUI-mcc that don't have a ReAction counterpart.

Someone who doesn't like MUI can still write an "openamiga"-SW using BOOSPI,
like GoldED or the IOSPIRIT programs do.

[Karlos]

Kronos wrote:
@Karlos
MUI and ReAction work in quite different ways, so creating an abstraction-layer that fits
both would mean loooooots of work, and result in more overhead and offcourse more bugs.

Okay I can appreciate that. I'm not saying one interface is better than another and I certianly don't have time to get into any kind of "MUI v Reaction" child of "MOS v OS4" crap :-D

I agree its a lot of work. But what is it that the OpenAmiga developer team will be doing all day?

Im sure there are people willing to work towards something like this.

OS4 WILL suffer from that the problems you described anyways, as atleast one of
the contributions is allready bound to MUI.

Well perhaps. But bear in mind that not everybody will use every contribution that comes along.

ReAction has been the official way for years now, but is still only sparsley used, while
MUI is seen as the standard by a majority of the Amiga-coders.

Trying to change that by force will fail, maybe even make coders turn their back.

Nobody is saying they would have to. Its clear many MUI coders wouldn't want to touch anything else. There are also reaction coders that feel the same.
Heck, even gadtools has its fans.

What this is about is giving those coders that want to a nice consistent API that doesn't depend ultimately on any particular underlying GUI.

Also, a well constructed OOP abstraction layer adds the possibilities that apps like games etc can provide their own GUIs and still use the same setup/event processing code in the internals.

One of the biggest problem is the use of mui custom classes for which there are no equivalents in other GUIs. However, not every application needs every esoteric gui element in its interface...

[iamaboringperson]

http://aminet.net/aminet.cgi?string=C%2B%2B+GUI
i like the look of this CIT.lha...

[DaveP]

I agree with iamaboringperson's original analysis on the locked thread. OpenAmiga could be a hell of a lot more than just a list of someones favorite APIs.

Standards are an opportunity not necessarily to select the most pervasive technology or a favoured technology but the best one - and generaly in a vendor neutral format.

I see no process for RFCs and therefore no means by which to get agreement. Its a fait accompli.

I would like standard by which I could use preprocessor conditionals to mark out an "Open Amiga" compliant version of my code which would lose all the bells and whistles from the AOS4 version. However with this, it ain't going to happen.

Finally there are two reasons to have a "standard", firsly to list the syntax that should be used to become compliant ( actually LIST them and not just say MUI vs x.y ) but also the semantics of the call.

For an example of how a real industry standard should work nip over to the OMG and take a peek at their process and standard of documentation.

[itix]

What this is about is giving those coders that want to a nice consistent API that doesn't depend ultimately on any particular underlying GUI.

I wonder who would use that. This would offer nothing for end user. And since many programmers see nothing bad in MUI they would continue using MUI anyway.

[Terminills]

@DaveP

The site has been up for about a month.  Many people are working in the background to help further it to be more of a working standard.  

Yes all would agree MUI isn't great and in time when there's a working port of something along the lines of GTK I'm sure it will be replaced.  

However for now what was chosen WAS the most vender nuetral API.   Like it or not a MUI based program CAN run on each OS.  Does that make MUI the best no but noone claimed otherwise.

As for syntax's etc.  Give it some time while that is being worked out.   I'm sure if anyone wants to help out instead of complaining noone is stopping them.

[DaveP]

I'm sure if anyone wants to help out instead of complaining noone is stopping them.

This prickly attitude to feedback isn't going to help.

Because you have no infrastructure to support or report the discussion leading towards a first draft the discussion is happening elsewhere.

Because you have no published process ( that I am aware of ) people are going to discuss it elsewhere, all over the shop and in a disconnected manner.

Myself and others will be communicating our expectations as we can - on forums that already are discussing the topic. If you intend to exceed or meet those expetations all well and good - but I still am none the clearer for your response.

Finally does one have to "contribute" to the back office process development in order to have a voice?

PS:  Where do I specifically criticise MUI in the post you refer to?

PPS: You say that you will go on to possibly replace MUI in the future - how will you handle deprecation then and backwards compatibility? Just drop it or extend it continually until you have #y components? You see this issue has to be handled so that people know how stable the spec is likely to be - if you are putting out the message now that component X is going to be replaced then is it worth my while writing using component X?

[Terminills]

For the record all that is being worked on.   As soon as a format is decided it will be available.  

 I don't know since it's such a young project maybe right now it would be more useful to suggest forums catagories instead of worrying about the rest.  So it can gain structure and eventually all input can be followed more easily.

As I see it personally I will agree the lack of structure is holding it back.   However it's being worked on.  Just need to give the poor thing some time to grow.  :-D

[DaveP]

Sure OK well maybe ask Wayne to create a forum on here called OpenAmiga, then when the site is fully up and running it can just embed the forum hosted on Amiga.org.

Then the rest of us can throw in ideas and debate the nitty gritty in one place and you can just weed out the stuff you don't need.