Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: iamaboringperson on June 28, 2003, 11:37:01 PM
-
:-)
Hi, everybody!
@Karlos:
I agree with this. MUI is not being developed outside of AROS and MOS. Hyperion are providing it as a "crippled shareware" version only so that people can run their older stuff; they would rather ppl use Reaction on new programs. The AROS/MOS crowd have spent way too much time and energy to give up on their effort, so I believe that the only way for the largest number of people to be able to use any given program is if that program has been written to use some sort of GUI abstraction layer. The user would decide what GUI toolkit to use, not the coder. If this abstraction layer happens to be one of the Linux APIs like Qt, wxWindows or GTK, so much the better; it will make porting many Linux programs a lot easier, and also help attract Linux coders because they won't need to learn yet another GUI API.
This is something that is definitely needed, but it's too big for a weekend coder. We need a determined team who has the respect and credibility of all three sides (AROS, MOS and Hyperion), because they will need to work closely with all three. In my opinion this project is a lot more important than getting an office suite, because we need anything and everything that will prevent people from thinking that writing programs for the Amiga is too much of a hassle. What good is an office suite if that's the only program you have?
@The OpenAmiga crew: if you're looking for a good cause to back, consider backing this one!
i quite agree!
a good standard called BOOPSI came out with 2.x
this is very a very good start for a gui toolkit, i believe reaction is based on this
a good use of the opensource model would be to produce a range of (opensource) gadgets/images that are compatable with all the common BOOPSI gadgets(which might include reaction ones)
just simple boopsi classes at first, then various authors can write new ones that are 100% source compatable, but have all the customization features in the world
and a standardized OOP C++ set of libraries could be added(and that
a problem with chosing MUI, and (AFAIK) AHI, and some of those others, especialy cybergraphics, is that if this is ment to be for opensource/non propritety OS's as well,
since not every OS out there can get cybergraphics for it, and AmigaOS 4.0 is ment to come with Piccaso anyway
there need to be other abstraction models
and a way to write software that will work on more than just cybergraphics.library
IMHO listing a whole bunch of apps aint going to help!
and more people/groups need to be involved
-
8bit bitplane modes are DEAD !! No one sensible codes SW anymore that needs them, and
since Openamiga is more targeted at "modern" Amiga I would even say noone really uses them anymore.
i wouldnt say that
for backwards compatability with OS3.1 graphics.library, 8 bit support is needed, and doesnt cause much harm
all gui's support 8-bit for some very good reasons
even if the 8-bit functions were used as an indirect way to call the hi/true color functions
or perhaps even if implemented as macros in the includes
i know its nice to have all modern tech. and no legacy stuff, but 8-bit color is still usefull
-
OT: I had sex with my wife to be last night you boring twat. you have a nice wank loser?
i never ment the intro. to sound so negative, nor to get people upset
but if this is your attitude, ill leave it with you and/or you psychologist to deal with
no use me flaming back, with more irrelevant nonsense
i would rather talk about the technical side of things i.e. programming
-
If the flamefest continues, I'll lock the thread. Try to be just a little more mature guys. These forums are not a vent for raging testosterone.
so what made you lock the thread??
all i saw was one flame, and it was pretty harmles IMO
:-)
-
Seems you still don't understand ....
1) Cypergraphics:
MorphOS has it (DUH)
OS4 has it (CGX-emu found in P96).
AROS has a dummy lib which redirects/implements those function on their gfx.lib.
2)MUI:
MorphOS hast (DUH again)
OS4 has it (the unreg version is fully useable, you just can't change the look).
AROS has it in the form of Zune (which could also be used on OS4/MOS).
3)Boopsi/ReAction:
Would mean lot of reinventing the whell for something that is still inferior to MUI.
Want a opensource GUI-kit ? Use Zune !
3)8Bit:
Openamiga is aimed at NEW SW, and full compabilty with the old gfx.lib would only be
needed when someone would insist on usig planar modes, or is poking directly into
structures. Both are big NONOs for modern Amiga-SW, and that why there is more
harm than good in putting those into the openamiga-definition.
-
@ iamaboringperson
so what made you lock the thread??
all i saw was one flame, and it was pretty harmles IMO
After I made my first comment, someone replied again in a way that could only help to continue the flamefest. I deleted their post and then locked the thread. I would appreciate it if you didn't do things that might continue the flamefest on another thread (ie. quoting flame comments from previous thread).
-
iamaboringperson wrote:
OT: I had sex with my wife to be last night you boring twat. you have a nice wank loser?
i never ment the intro. to sound so negative, nor to get people upset
but if this is your attitude, ill leave it with you and/or you psychologist to deal with
no use me flaming back, with more irrelevant nonsense
i would rather talk about the technical side of things i.e. programming
I'd rather do the actual programming as opposed to talking about it. Do you want to help?
-
I dont care about GUIs, whether one is present or absent
makes no difference to me, what matters is what the
actual prog does.
I have 3 very useful progs:
1. gcc
No GUI, probably *the* most useful prog in the universe,
I dont like it but its very useful, without it there would
be no OS4 for instance.
because it has no GUI it is very very portable,
in fact it is the most portable prog in the universe,
so portable it can even port itself!
Name me one other prog that can do that?
You can port unix, Linux, OS4 with it, not bad for a GUI free prog.
2. make,
this is a unix prog, vital for ports, no GUI, good!
without it its a p.i.t.a to port things though some people
have managed without it.
3. Memacs:
very good text editor, the unix version of this is even better
gnu-emacs: even has a built in language emacs-lisp, so you can
write customised clever functions.
The Amiga version has a menu, but I find keyboard short cuts
much faster:
search and replace? ESC-q
search ? control-s
insert file ? control-x control-i
and so on. By the time you have located the menu command I could have done
5 keyboard commands.
The only GUI thing I miss on Memacs is an input-file-requester, I've heard
there is an Amiga port of gnu-emacs that has this and that it was done
with asl.library.
What I really cant stand are progs that have wonderful GUI's and
do sod all.
nice GUI shame about the features!
I would rather have nice features but shame about the GUI.
If I were to use GUIs myself I think I would write my own one,
that way I would ensure portability. If you use an external one
then the problem is that 5 years down the line everyone will
have abandoned that path, and you will be stuck with complicated
+ interesting + unusable source code.
People complain about progs that use their own GUI,
I say smart move! Your prog will port everywhere.
People keep sobbing for standardisation of interface,
I have no sympathy for you!:
the "standardised approach" of today is in a rubbish dump tomorrow.
I remember once writing some shareware prog, and someone
criticised my docs saying they should be more standardised,
they should be in amigaguide. Well amigaguide wonderful though it is
never took off.
OS2.0 with its gray wb was someones bright idea of standardisation,
standardisation is so mind numbingly boring. Please dont ask for this,
who is going to standardise, what qualifies them to do it,
please dont even think about it. Standardise the OS by all means
but not the interface.
One cross platform portable GUI mechanism that exists is HTML,
eg this website, perhaps people who want a portable GUI should
use that? not sure how you would incorporate it into a prog,
maybe create a browser-compiler: input html output binary code??
:do this by customising an existing browser.
Regarding 8 bit planes, bit planes in general were a bad concept
they are slow to read, slow to write and probably slow from a
h/w POV: the video hardware has to read from eg 8 different
locations (1 for each bitplane) so its inefficient eg from a
memory caching POV. So all round bitplanes were stupid.
However if you have an AGA only machine like mine then thats the
only option.
Its a good idea though to try to create your own
abstraction layer and work through that.
Byte per pixel, or byte per component is a much better approach
in every way. Byte per pixel eg for grayscale has the advantage
of tripling the data rate eg frame rate. Its also 3 times as fast
to render + read, problem is its in gray.
:I think using any OS directly is a dangerous move.
One day even Windows will be in a glass case in a museum:
Bill Gates must one day retire, without him MS will disintegrate!
Windows==Bill Gates, its like Virgin==Richard Branson.
When these bosses retire their companies will disintegrate.
Alongside Windows in the museum will be Linux in another case,
the caption will read "early man OS's".
Windows is also based on deliberate impermanence, they deliberately
keep moving the goalposts to force everyone to keep buying.
Its best to put a private abstraction layer between your prog and the
external OS:
prog ---- OS-abstraction ----- actual OS
That way to port your progs reduces to porting the abstraction layer.
So regarding GUI's you just need your own private GUI abstraction.
You dont actually need to abstract the GUI, but just abstract the
function of the GUI.
eg the abstraction of an input-string-gadget in C might even be
char *input_string(void) ;
or something.
Remember the GUI should be 1% of your prog, 99% of a prog should be
actually doing things: non visible, lots of data movement + processing.
For many progs a GUI is purely there to input data:
this data may be boolean (click on gadget),
string (eg file name), or number (eg no. of iterations),
its not a big deal.
Obviously GUIs are more central for graphics progs where the prog has to
track the mouse, but there are so many progs other than art progs.
BTW what exactly is the prog you want the GUI for?
then we can have some "context" for discussing the GUI problem.
whoosh777
-
mdma
I'd rather do the actual programming as opposed to talking about it. Do you want to help?
id like to help(without being abused), however if its about listing programs, id say there is not much more that needs to be done,
if its about creating specifications for libraries and ABI's etc... i would certainly like to help
but what should be posted on the site, for now are the types of executable/ABI's that each OS(AOS/MOS/AROS)uses, that would be very helpful
and as somebody else suggested, an OOP GUI abstraction library, to help with better portability between GUI systems, so that each OS or user may chose their own GUI and programs will still be easily portable
that idea to get QT stuff from other platforms ported sounds good... if its possible
-
whoosh777
GCC i dont care so much for, but its a matter of personal choice IMO
i would probably prefer a comercial compiler, and including GCC as standard would only discourage other third party compiler producers - OK for AROS, probably not for AOS/MOS but thats just my opinion
MEMACS definintly should be made standard :-P
-
and as somebody else suggested, an OOP GUI abstraction library, to help with better portability between GUI systems, so that each OS or user may chose their own GUI and programs will still be easily portable
that idea to get QT stuff from other platforms ported sounds good... if its possible
The problem with this is that you would then be reinventing the wheel when such an OOP GUI library already exists for all of the platforms: MUI.
Some folk will go "MUI is commercial, can't use that" and forget about Zune, which could be ported to AOS4 simply, to replace the shareware MUI with a fully compatable replacement. (MOS comes with the full MUI already, so that is not an issue)
And no, ReAction is not based on BOOPSI, but on ClassAct.
But the idea behind OpenAmiga was to create specifications. What is there now is a preliminary list only. Want to define more, or work out more, then join in!
-
I hate GCC too. It's bloated, takes aaaaages to compile, and doesn't produce the best code. Not to mention that it's a total pain in the ass to install. I'd rather use SAS/C any day.
That said, GCC is unique in that it's the most compatible compiler. It'll work for all systems and produce any kind of file you want, ELF, EHF, whatever. It also makes porting *ix apps quick and easy. It's the perfect choice of a standard.
-
Remember the GUI should be 1% of your prog, 99% of a prog should be
actually doing things: non visible, lots of data movement + processing.
Sorry, but that is BS :-o :-o SW is for doing things easier than doing them by hand.
This means that every SW needs an usable and understandable UI, and for most things
that make use of todays CPUs a graphical UI is the best solution.
Thise GUI has to offer the user all functions of the SW and have some safenet for false input.
It also needs to be easy to use, which can't be reached when every apps uses
different methods to reach the same goal. Thats why there should be a limited number
of GUI-kits for any OS, and that why there should be some basic style-guide in place.
-
downix wrote:
The problem with this is that you would then be reinventing the wheel when such an OOP GUI library already exists for all of the platforms: MUI.
I agree that MUI is fine as it stands but I feel you are missing our point here.
An abstraction layer has many benefits. For MUI and reaction both, such a layer would be very thin.
Enforcing MUI as an interface is not a good idea - plenty of people don't like it, it may not be ideal under one or other versions of the OS (ie OS4).
Having to use MUI or Zune on a system which already has GUI results in an underutilisation of that systems existing abilites and increases the memory overhead of the program (having to load MUI resources etc). Reinventing the wheel as you yourself describe it :-)
By contrast the abstraction layer would be relatively small since it relies on the underlying native GUI to do all the work.
One overwhelming advantage, as codesmith pointed out would be to use an API which is source compatible with one of the Linux APIs which would reduce the work required to port software.
I feel this idea has a lot of potential, but that's my humble opinion :-)
-
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
-
@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.
-
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
-
@boring
http://ftp.uni-paderborn.de/aminet/aminet/dev/mui/MUIPlusPlus.readme (http://ftp.uni-paderborn.de/aminet/aminet/dev/mui/MUIPlusPlus.readme)
Maybe something like that ?
(haven't tried it myself, but looks interesting)
-
Kronos wrote:
@boring
http://ftp.uni-paderborn.de/aminet/aminet/dev/mui/MUIPlusPlus.readme (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..."
-
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.
-
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
-
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.
-
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...
-
http://aminet.net/aminet.cgi?string=C%2B%2B+GUI (http://aminet.net/aminet.cgi?string=C%2B%2B+GUI)
i like the look of this CIT.lha...
-
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.
-
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.
-
@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.
-
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?
-
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
-
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.
-
@DaveP
I've been in hospital Dave, give us a chance! :-) I also lost my job, and had to find another, somethings take priority over free-time projects when you have a young family to look after.
The forums will be going up soon, so people can discuss in one central place. Hopefully, Wayne will embed the forum here, and Targhan will do the same on MorphZone. :-)
-
@mdma
Hey I meant no offense - sorry to hear that you have been through a rough spot.
Will keep any further feedback back until you open the fora :-)
-
DaveP wrote:
@mdma
Hey I meant no offense - sorry to hear that you have been through a rough spot.
Will keep any further feedback back until you open the fora :-)
None taken mate.
-
I see no process for RFCs and therefore no means by which to get agreement. Its a fait accompli.
well, thats right - i would like to see a #### load of disscusion before any so called standards are posted on the web site
a list of programs just wont do it
-
OpenAmiga certainly is an interesting idea, given the community looks to be splitting between PegososPPC and AmigaOne - any chance it could apply to both, and/or provide help and technical details to aspiring programmers - say how to port skills from one platform to another.
-
iamaboringperson wrote:
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
Mind you:
Why does a programmer prefer MUI or ClassAct? It is:
A) Because it has classes which he likes or needs.
B) Because he likes the API.
Thus you encounter two problems. The first one is a purely practical one, which may be resolved with lots and lots of hard work:
Lack of appealing classes!
You will need to replace loads of MUI and even ClassAct classes. Toolbar.mcc, Trafficlight.mcc, Inputfield.mcc, Textedit.mcc...
B is, however, the real problem. The programmer will favour one toolkit, and replacing both will one will run the risk of putting of both camps.
In the end, I think that MUI will slaughter all others, both because it is the only real cross-platform toolkit, and because it has been the more popular one since the late nineties. Really, how many ClassAct programs can you find outside of the AmigaOS CD? AWeb is probably the only major ClassAct app, and it's abandonware now.
Most of the antipathy towards MUI is historical, too. MUI is neither particularly slow nor buggy on a moderately fast classic Amiga, and in the next-generation context of OpenAmiga, there really is no slowness problem.
-
Whoosh wrote:
If I were to use GUIs myself I think I would write my own one, that way I would ensure portability. If you use an external one then the problem is that 5 years down the line everyone will have abandoned that path, and you will be stuck with complicated + interesting + unusable source code.
Whereas you are stuck with further developing your own one. That works if you're Stefan Stuntz, whose only concern is that of developing a toolkit for others to use, but as you said yourself, only 5 percent of a program should be the interface, and how do you manage that with a fairly complex interface, if you have to incorporate your entire private GUI toolkit into your program.
You will even have to think about portability of your own toolkit. You advocate dropping the bitplane system. Well, let's say that your private toolkit made use of that. Now you will have to update your toolkit to run on chunky screens, whereas if you had used GadTools, ClassAct or MUI, it would run just as fine without knowing.
The last few weeks, I've been running Betascan, and the programmer uses his own private OO toolkit. Well, good for him. Bad for me. It tries to fit in, but there's only so much you can do to ensure that your toolkit will be really system friendly. Basically, it mimics a plain grey OS 3.0 interface, using the standard grey colour, Topaz 8 as its screen font, and so on. Well, I'm sorry, but I stopped using Topaz 8 as my system font in 1994, and I don't feel like making its acquaintance anew, especially not on a screen with square pixels. It also looks like it uses the ASL requester, only it doesn't. It just mimics Intuition, but since it isn't Intuition, it doesn't fit in with any system which has had its prefs changed, or its system upgraded. Betascan's reimplementation of the ASL requester doesn't adhere to the standard shortcut keys, doesn't have the same menu features, and will in no way behave the way you expect after having used ASLPrefs.
If you adhere to standards, you will not alienate users. And if you use external toolkits, your program will often be upgraded along with the toolkits. For example, a program released in 1992 will inherit all the new features of the latest ASL library, whereas your own implementation will forever be frozen in the 1992 stage.
People complain about progs that use their own GUI, I say smart move! Your prog will port everywhere.
Port everywhere, fit in nowhere. What a useless concept.
People keep sobbing for standardisation of interface, I have no sympathy for you!: the "standardised approach" of today is in a rubbish dump tomorrow.
Like everything else, you mean?
Mind you, some standards do persist. Standard keyboard shortcuts have been the same ever since Apple and Commodore first defined them. Why, the QWERTY keyboard is an even older standard (which, however, deserves to end up in the dump ;-). However, are you saying that your own standard ensures longevity surpassing that of the OS/toolkit developers? Even though GadTools is deprecated, it still works, on every Amiga system in existence.
I remember once writing some shareware prog, and someone criticised my docs saying they should be more standardised, they should be in amigaguide. Well amigaguide wonderful though it is never took off.
What world or year are you from? AmigaGuide is very much the standard documentation format, and used by most software packages with more than one K of documentation.
OS2.0 with its gray wb was someones bright idea of standardisation, standardisation is so mind numbingly boring. Please dont ask for this, who is going to standardise, what qualifies them to do it, please dont even think about it. Standardise the OS by all means but not the interface.
OS2 with its gray WB, and the UI guidelines, made Amiga apps more usable, since programmers could concentrate on programming, instead of reinventing the GUI wheel and confusing the user. It was a win-win deal for all sides.
You say OSes should be standardised, but not the GUI. Well, AmigaOS is a GUI OS, and has always been one. You standardise the OS, you standardise the GUI. And GUIs are, despite what you might think, not the only parts of an OS which are upgraded or left behind. Only, when you use the standard GUI, you leave the updating to someone else, and hopefully in a way which won't break your program.