So, where are all these serious Reaction/Classact applications?
Anyway, you seem to be quite ignorant about MUI and what it can bring. It may have been slower on 68020 (quite obvious given the extra functionality), but hey, these times are waaaaaaaaaaaaay behind, we're using ppc now.
But you're free to write top-notch applications using plain gadtools (in ASM of course, else it's too slow). :)
And sorry to prove you wrong, but i remember the good old Amiga days who no serious app was built with MUI [only freeware or shareware apps] and it was big discuse as IB use MUI as GUI, it slowing down the GUI ws the main outcome. Nowdays no seriouse app is still use MUI, because it ISS no serious app on OS4/MOS more ....[sad but true] So only shareare/freeware apps use MUI nowdays. As MUI was createt it was to simplyfi the GUI writing process for freeware progger.Any proffesional software use his own native GUI. Not [or most times] the easy way is the best ...
In "the good old Amiga days" so 1992-93, MUI was born, so it was very young and it wasn't what it becomes in the version 3 (I don't know the year, but I believe 1996). ClassAct was born in 1995. So all big application which were born before 1995-1996 didn't use MUI or Reaction. It's something of logic: if you have just built your application GUI with your blood without MUI/ClassAct you can't insert your work into trashcan, but update your work, because it's simpler for you. Tell in this topic all Amiga big applications of "the good old Amiga days" don't use MUI/Reaction is totally unsense because if authors of these software at that time could choose between to write from scratch their GUIs and to use MUI/Reaction they would be choose second way, it's obvious.
If all MUI 3rd part devs would follow OOP paradigm using subclasses instead to build guis with structured programming these kind of problems would disapperar.
Yes, but it doesn't change the reality. The problem is there, and therefore it makes MUI difficult to use at best.
Quote:
Chaos with external classes could happen even with Reaction, the only reason because this isn't happens yet is because Reaction/ClassAct was always less widespread than MUI.
Yes, but again, it doesn't change reality. There is no such chaos on Reaction, yes it is mostly because these external classes don't exist, but that is a good thing in this case. About 50% of all MUI stuff I tried wants specific versions, sometimes they don't even work with newer versions of the same external class they're using. MUI isn't to be blamed for that, sure, but it still makes me shy away from anything MUI related, and makes me not even consider it for my own stuff.
Quote:
The real problem is into BOOPSI/Amiga itself, it should be written to load in a own part of memory an external version class by a program, if another program would want another (crap) version it could load it without to remove from memory thats other version class. In this way a program would include their own set of version classes and user is not bored by classes installation.
No, the BOOPSI stuff is not the problem. It's a simple object oriented class framework. The problem are incompatible changes in classes, a thing that should normally not occur.
Quote:
If I should describe a sensation when I use a MUI GUI and a Reaction GUI I could say:"when use a Reaction GUI all seems hard and cumbersome, like wood, while while I use a MUI GUI seems I use plasticine, I can shape it as I want". This is an empiric concept, but on these concepts are founded and fixed modern UI...
I find arguments like this dubious at best. It's like saying "I like MUI better because I like MUI better". It's wrong as well, because if someone decided to use Highlight color on a background that doesn't give enough contrast you're pooped anyway.
The fundamental issue with MUI on one extreme and Reaction on the other extreme is customization. MUI has too much, Reaction has too little. A user should never be able to control every single aspect of a GUI. An artist should, and this should be handled in the form of themes. If that was the case, then GUI design would be much more painless.
As it is now, neither Reaction nor MUI provides that.
There are more problems with Amiga GUI's that will need to be addressed in further updates. Basically, I think a complete redesign is needed.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Like shinkuro said, notification is an essential concept in MUI which reaction lacks (or if it exists, it's never used :)).
Shows how much you know about BOOPSI.
Quote:
Then, builtin classes coming with MUI are more than enough to make any descent application. That myth a modern MUI app would require all the latest MCC is just plain wrong.
It's a reality, and ignoring the reality will not help. If you look around, EVERY major MUI app will require external classes. Whether it is possible to write them without them is irrelevant. Take YAM, take IBrowse, they require these classes.
Quote:
Anyway, i think the statistics speak for themselves. The most evolved/complex apps almost all use MUI, and there's a reason for this...
The typical non-argument is to quote statistics. The most evolved/complex apps all use Windows.
Quote:
But it's no valid reason to bash MUI. Better try to achieve what MUI does by extending Reaction (and good luck :)).
Another non-argument. "XYZ is so powerful Mwahahaha". So lame.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
So, where are all these serious Reaction/Classact applications?
OWB and CodeBench come to mind immediately.
Quote:
But you're free to write top-notch applications using plain gadtools (in ASM of course, else it's too slow). :)
Snoddy sarcastic replies are not going to win an argument. They will only help to cement your appearance as a cult follower. People raise valid points and the only thing you do is try to ridicule. You close your eyes to any valid criticism.
You will notice that I pointed out a number of flaws in Reaction as well. Denying them is useless. MUI has its own flaws, but the cult followers like yourself will always ignore these flaws and nitpick on the flaws of "the other side".
A useless discussion.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Yes, but it doesn't change the reality. The problem is there, and therefore it makes MUI difficult to use at best.
It's the usual story of cat which bites its tail :) If you give more freedom users can use bad this freedom, instead if you insert rules that user can feel limited by them...
Quote:
There is no such chaos on Reaction, yes it is mostly because these external classes don't exist, but that is a good thing in this case.
Uhm but problem isn't into Reaction nor MUI...this problem could give problems even to Reaction...MUI shows us like this is really a problem. "How could you manage BOOPSI external classes?How better deal problem of different versions of same external class" This is the real problem...
Quote:
About 50% of all MUI stuff I tried wants specific versions, sometimes they don't even work with newer versions of the same external class they're using.
Ehm, this is a problem of some specific (old?) application... I can't understand why an application should check something as:
if (version== 1)
instead of:
if (version >= 1)
this is senseless :)
Quote:
MUI isn't to be blamed for that, sure, but it still makes me shy away from anything MUI related, and makes me not even consider it for my own stuff.
If MUI has not fault for this, it's even true that MUI can't take responsibility for bad written applications...I could understand user POV, but from dev POV I must admitt MUI is not fault for bad programming style... So really problem is missing of a proper documentation and lack of a better external classes management (again not MUI, but BOOPSI itself).
Quote:
No, the BOOPSI stuff is not the problem. It's a simple object oriented class framework. The problem are incompatible changes in classes, a thing that should normally not occur.
Again, MUI has not fault for bad written external classes, and again, this is a problem which could happen even to Reaction. It's useless hide ourselves into sand... So if BOOPSI external classes are libraries, on OS4 it could be possible to mantain different versions of same external class using interface method... but this is not my field programming, in fact I've asked you (I've implied;D) what do you think about this :) I'm interested to your opinion about how improve Amiga GUI system/framework (too work which couldn't be useful? is it better to abandon BOOPSI? write from scratch a new system with API compatibility?)
Quote:
The fundamental issue with MUI on one extreme and Reaction on the other extreme is customization. MUI has too much, Reaction has too little.
IMO is not true, because on OS4 I can configure Reaction much more then MUI3.9 OEM (so without a key), but in any case I feel MUI better than Reaction, and I'm not the only one... (I'm speaking like user from now).
Quote:
I find arguments like this dubious at best. It's like saying "I like MUI better because I like MUI better". It's wrong as well, because if someone decided to use Highlight color on a background that doesn't give enough contrast you're pooped anyway.
But this doen't deny that empirical sentence it's an example of what modern designers begin to focus what it's worng in a certain GUI than onother one. Why user feels that feeling with Reaction? Why with MUI he feels another thing? Reaction and MUI are BOOPSI, so what MUI has/not has than Reaction? You tell me that main reason is how user can customize his GUI, I'm not agree with you :) MUI seems "softer" than Reaction even you don't customize it, so it must be something else :)
Quote:
There are more problems with Amiga GUI's that will need to be addressed in further updates. Basically, I think a complete redesign is needed.
I'm very curious about your ideas about this field
most [if not all] was already said by Rogue and is 100% conform with my experience in MUI.[compatibility problems with prg/classes..]
@Fab
so we now at the Winblows train ? If the GUI slow get a more powerfull CPU/RAM/watever .. Nice to see you are a true Amigan [i hope you get the sarcastic ..] And i [and Rogue too] say that we KNOW that reaction is not the ultimate sulotion ! But it is faster as MUI and have less bugs/incompatibility - so yes, i going for Reaction ATM. If come a better GUI system then this is another thing,but MUI is out of scope.
And i see you have no arguments more, you come to the childish senseles argument "doing it better then you can talk here ..", with this logic i think you cant talk in the most threads.
@ShInKurO
yes you are partly right that the most good old day apps come to a time MUI was young.But would any seriouse company a proffesional app relase with a GUI system that is shareware and have bugs and incompatibility and would bind his app on this -> NO! This is only Valid for small hobby apps.
BOOPSI notifications are rather raw to use. Maybe you should consider using MUI for real to know how powerful it can be when implemented properly.
Quote:
t's a reality, and ignoring the reality will not help. If you look around, EVERY major MUI app will require external classes. Whether it is possible to write them without them is irrelevant. Take YAM, take IBrowse, they require these classes.
Taking YAM as an example is a cheap shot. Its author seems to have fun bumping any mcc (for nothing) and requiring the very latest version each time. That said, i find it funny you're so upset by using external classes when you yourself opened the door to the shared object hell in OS4, which is a way worse concept in every aspect (no proper version concept, no compatibility, ...).
Quote:
The typical non-argument is to quote statistics. The most evolved/complex apps all use Windows.
statistics aren't an argument, but that should at least show you which toolkit developers prefer. Now you can of course assume most of them are ignorant who didn't see the holy light in Reaction or ClassAct.
Quote:
Another non-argument. "XYZ is so powerful Mwahahaha". So lame.
You can choose to ignore MUI abilities. It's your problem.
Quote:
Quote:
So, where are all these serious Reaction/Classact applications? OWB and CodeBench come to mind immediately.
I can't tell about CodeBench, but OWB is certainly not a complex application GUI-wise (and i repeat, i'm only talking about the gui side, not owb itself). If you need to take an example, better take Aweb than OWB.
Quote:
Snoddy sarcastic replies are not going to win an argument. They will only help to cement your appearance as a cult follower. People raise valid points and the only thing you do is try to ridicule. You close your eyes to any valid criticism.
Sarcasm seemed quite appropriate to the blind answers from R-Team. I mean, how "MUI is only good for simple apps" or "MUI is slow" is a valid point? Please enlighten us.
Quote:
You will notice that I pointed out a number of flaws in Reaction as well. Denying them is useless. MUI has its own flaws, but the cult followers like yourself will always ignore these flaws and nitpick on the flaws of "the other side".
You can see external class concept as a flaw when abused (which i agree on, of course). But then you should also consider removing libraries concept from amigaos, maybe. Else someone could start abusing it and requiring external libs for his apps (shock, horror!).
Quote:
A useless discussion.
It's an useless discussion because you decided to cover your ears and close your eyes.
I don't think i ever denied abusing external classes sucked (but how can it possibly the toolkit fault?). I just argued on the other points (mui too complex, too slow, only good for simple things). But maybe you imply argueing is useless on this forum.
Yep, especially since it was started from a thread about OWB, a program which doesn't even use the ReAction class (window.class) for it's GUI. OWB uses plain intuition windows with a few BOOSI gadgets and gadtools menus. The only parts where OWB uses classes from ReAction are the 3 requester.class JavaScript requesters, but for at least 2 of them I could have used IDOS->TimedDosRequester() instead to get exactely the same result, and the arexx.class for it's ARexx port.
Quote:
People complaining about MUI making it harder to design complex GUI or being unresponsive when some processing happens just prove they don't have a clue about MUI.
Most obviously don't or there wouldn't be that much crap MUI programs with unresponsive GUIs, but I know exactely what's required to work around the design flaws of MUI, and it's a pain in the ass no matter which of the solutions you are using. Fortunately I don't have to use it any more, none of my AmigaOS programs which used MUI are maintained since years any more.
Quote:
Like shinkuro said, notification is an essential concept in MUI which reaction lacks (or if it exists, it's never used :)).
Since AmigaOS 3.5 there is no such thing as ReAction, the methods it added like GM_DOMAIN are standard AmigaOS BOOPSI methods now, and not only the classes which where added to AmigaOS from ReAction support it but old ones like gadgetclass as well. OM_NOTIFY was always supported by BOOPSI, since AmigaOS 2.0.
Quote:
Then, builtin classes coming with MUI are more than enough to make any descent application.
Maybe in the MorphOS MUI 4.x, but definitely not in the AmigaOS MUI 3.9. Even something extremely simple as the OWB 3.5+ GUI with tabs is impossible with MUI, unless you use 3rd party classes or implement your own replacement for Register.mui with support for dynamically adding/removing tabs and their page groups.
Quote:
And for the record, MUI inherits and extends BOOPSI
It's gadget, image, etc. classes are not based on the BOOPSI gadget, image, etc., classes, the only ones it's using are rootclass and icclass. It doesn't use standard BOOPSI methods like GM_DOMAIN either but it's own replacements. Some things MUI does were required on AmigaOS 2.x, but it was never updated to newer versions of AmigaOS, and never will be, and that's not just limited to core methods like GM_DOMAIN and attributes like WINDOW_CharSet/LAYOUT_CharSet, etc., it's the same for all other parts of MUI as well. For example the MUI Public Screen Database is still limited to DRI_VERSION 1 or 2 (AmigaOS 2.x or 3.x), it doesn't even include the settings required for DRI_VERSION 3 (AmigaOS 4.x), let alone other settings like different GUI prefs for each screen, and is therefore useless on AmigaOS 4.x.
Quote:
Also, when you need to process something in a GUI, you do it asynchronously or in an external thread. Otherwise, be it MUI, Reaction or any other toolkit, it will just block.
If you need to handle input from the GUI while processing something else, yes. But if not that's only the case for MUI, not with the AmigaOS BOOPSI classes which do the basic things (visual feedback for input like button presses, refresh handling in simple refresh windows, relayouting and rerendering on window resizes, etc.) in the intuition task instead.
If there would be a better GUI toolkit for AmigaOS, for example if the AmigaOS 4.x port of Feelin would have worked, I would use it, but currently the BOOPSI classes included in AmigaOS is the best one. If that wouldn't be the case, before I'd use MUI again, especially since it's outdated since years and will never be updated again, for example it's gadget classes don't even support a charset attribute which is mandatory since AmigaOS 4.x for GUIs, since other charsets than ISO-8859-1 are supported by AmigaOS, I'd rather use the most hated AmigaOS GUI toolkit instead: Triton ???? (For example MakeCD uses it.) Of course it would have to be updated for AmigaOS 4.x as well before it could be used, but unlike with MUI that's possible for Triton.
Maybe in the MorphOS MUI 4.x, but definitely not in the AmigaOS MUI 3.9. Even something extremely simple as the OWB 3.5+ GUI with tabs is impossible with MUI, unless you use 3rd party classes or implement your own replacement for Register.mui with support for dynamically adding/removing tabs and their page groups.
MUI4.x supports it natively. But anyway, adding dynamic tab add/remove is at most 100 lines of code with proper subclassing.
Quote:
Some things MUI does were required on AmigaOS 2.x, but it was never updated to newer versions of AmigaOS, and never will be, and that's not just limited to core methods like GM_DOMAIN and attributes like WINDOW_CharSet/LAYOUT_CharSet, etc., it's the same for all other parts of MUI as well.
It's indeed bad if you can't make MUI evolve, but that's not a MUI issue, that's your issue. About these *_CharSet attributes, i'd say it's really not a well thought API. What about using a unique tag that all subclasses would inherit at will instead?
Quote:
If you need to handle input from the GUI while processing something else, yes. But if not that's only the case for MUI, not with the AmigaOS BOOPSI classes which do the basic things (visual feedback for input like button presses, refresh handling in simple refresh windows, relayouting and rerendering on window resizes, etc.) in the intuition task instead.
So you're telling that if such a BOOPSI class crashes (which can easily happens when developping), then intuition is also dead, since they run in intuition context? Not great if you ask me. At least, with MUI, you're free to crash as many times as you want. :)
Quote:
If there would be a better GUI toolkit for AmigaOS, for example if the AmigaOS 4.x port of Feelin would have worked, I would use it, but currently the BOOPSI classes included in AmigaOS is the best one. If that wouldn't be the case, before I'd use MUI again, especially since it's outdated since years and will never be updated again, for example it's gadget classes don't even support a charset attribute which is mandatory since AmigaOS 4.x for GUIs, since other charsets than ISO-8859-1 are supported by AmigaOS...
Feelin may have some cool ideas (much inspired from MUI, btw), but it's *totally* unproven on real use. The only app using it is its prefs GUI, apparently. I wouldn't like to develop serious stuff with such an unproven toolkit.
And once again, it's too bad you don't control MUI development. I guess that's the real reason for OS4 using "Reaction" instead of MUI (along with 3.5/3.9 legacy), actually, not all these weird statements about unresponsiveness, slowness and all... :)
OWB, a program which doesn't even use the ReAction class (window.class) for it's GUI. OWB uses plain intuition windows with a few BOOSI gadgets and gadtools menus.
Reaction is a plain (more or less) collection of BOOPSI classes, so if you use clicktab.gadget, arexx.class (it was into classact archive in fact) you're using Reaction. The fact you're using part of GadTools API into OWB instead of use BOOPSI window.class is an your choise (if it's better or worse it will be show by yourself and users in future)...
Quote:
Most obviously don't or there wouldn't be that much crap MUI programs with unresponsive GUIs
If you fill main loop of checks instead to use OOP subclassing method it's always an your choise....I've just written problem of MUI (and Amiga) is lack of documentation...
Quote:
Since AmigaOS 3.5 there is no such thing as ReAction, the methods it added like GM_DOMAIN are standard AmigaOS BOOPSI methods now, and not only the classes which where added to AmigaOS from ReAction support it but old ones like gadgetclass as well. Quote:
GM_DOMAIN -- Obtain gadget sizing requirements.
What is it concerns GM_DOMAIN with notification? In any case this method does same things MUI gives you from its first version... I don't see any new and better way to have notification with BOOPSI/Reaction , you have to use always OM_NOTIFY/ICA_TARGET/ICA_MAP tools, they are all except modern and easy to use if they are compared with MUIM_Notify of MUI...and problems increase when there are many notification chains to mantain...
Quote:
Some things MUI does were required on AmigaOS 2.x, but it was never updated to newer versions of AmigaOS, and never will be,
this is false, MUI from version 3 provided a MUIC_BOOPSI class which can encapsulate all new BOOPSI classes from AmigaOS3.x so they can use into MUI program if a 3rd part dev wants... In other words it's similar to Java's wrapper classes for primitive types... And not only this MUIC_BOOPSI was added...
Quote:
Of course it would have to be updated for AmigaOS 4.x as well before it could be used, but unlike with MUI that's possible for Triton.
Feelin may have some cool ideas (much inspired from MUI, btw), but it's *totally* unproven on real use. The only app using it is its prefs GUI, apparently. I wouldn't like to develop serious stuff with such an unproven toolkit.
I totally agree with you, in particular way in a situation like Amiga universe (where there are 30- active devs at all? :D) I find imprudent don't use MUI for big projects, it's much tested, reliable and with behaviours known than other alternatives...Same problem if it would be implemented a new GUI framework...
Quote:
And once again, it's too bad you don't control MUI development. I guess that's the real reason for OS4 using "Reaction" instead of MUI (along with 3.5/3.9 legacy), actually, not all these weird statements about unresponsiveness, slowness and all... :)
There is always Zune, I've just told I'm sure a couple of OS4 devs could fix and enhance it instead to try to improve Reaction (of which in this thread was told about many lacks of design...). They could better integrate it to OS4 than MUI3.9 is now...
There is always Zune, I've just told I'm sure a couple of OS4 devs could fix and enhance it instead to try to improve Reaction (of which in this thread was told about many lacks of design...). They could better integrate it to OS4 than MUI3.9 is now...
I don't know how the licencing would work with Zune, I assume it's open source (everything else AROS is), so including it in a commercial distribution may be problematic.
Apart from that, the ongoing improvements to the AmigaOS4 BOOPSI classes is built upon an existing frameswork which has been tried and tested. Those improvements are far easier to test than a complete gui toolkit. I am currently working on parts of the BOOPSI system as we speak, and development in this area is constantly evolving.
The other thing with extending the BOOPSI classes is that it doesn't involve recompiling everything that uses them, unlike the adoption of a new gui toolkit (Zune or otherwise).
I would definitely rather see the OS4 devs work on what we have, rather than what we don't have. Their time is extremely limited as it is, let alone taking on more projects like a Zune port.
I don't know how the licencing would work with Zune, I assume it's open source (everything else AROS is), so including it in a commercial distribution may be problematic.
Nope, AROS public licence provides commercial product can use code under this licence, in fact MorphOS uses dos.library taken from AROS and other parts... The only thing is to release enhancements and fix under the same licence. The code used doesn't pollute with its licence the commercial product, close parts codes, etc... it's very similar to BSD licence from which all Amiga TCP/IP stacks were born... So there isn't any real problem for AmigaOS4.x to include/integrate/enhance Zune instead of MUI.
Quote:
Apart from that, the ongoing improvements to the AmigaOS4 BOOPSI classes is built upon an existing frameswork which has been tried and tested.
Good to know this However...
Quote:
Those improvements are far easier to test than a complete gui toolkit.
I want noticed you Zune was just ported on AmigaOS3.x (an old version, so now it's enhanced), and many OS3.x users just test it with MUI programs. If you port Zune on OS4.x will be MUI programs theirself to be a good test for Zune:
I am currently working on parts of the BOOPSI system as we speak, and development in this area is constantly evolving.
Sure, thanks for your work, but lack into BOOPSI design are not fixable...you can enhance it for sure, add much personalization for users, new methods and attributes to classes...but to have a better system notification than MUI you should upset BOOPSI itself, and not only for notification (think about MDI paradigm of some posts ago...).
Zune is here, ready to be ported by someone who knows Intuition/BOOPSI programming, it is just usable instead of MUI3.8 on OS3.x, so I really see few steps for OS4 then a complete enhancement of BOOPSI/Reaction...and to abandon MUI where you haven't no decisional power (like Fab has suggested...)
And once again, it's too bad you don't control MUI development. I guess that's the real reason for OS4 using "Reaction" instead of MUI (along with 3.5/3.9 legacy),
If AmigaOS 4.x would have used MUI as default GUI there would be at least one AmigaOS 4.x developer less, I wouldn't even use it at all.
Quote:
actually, not all these weird statements about unresponsiveness, slowness and all... :)
Definitely not, MUI was utter crap on AmigaOS 3.x already and I only used it if I had to (link in PINT, which I didn't write but just maintained for some years). There are next to no improvements in MUI 3.9 compared to the AmigaOS 3.x version, but just updating MUI wouldn't help anyway, it's broken by design. If would want to have something as broken as MUI I could port the AROS Zune to AmigaOS 4.x and add the required AmigaOS 4.x changes, but since Zune can be used instead of MUI with MUI programs on AmigaOS 3.x they obviusly copied all design flaws of MUI and, except for the required AmigaOS 4.x changes MUI doesn't have, it would be just as bad.
Sure, thanks for your work, but lack into BOOPSI design are not fixable...you can enhance it for sure, add much personalization for users, new methods and attributes to classes...but to have a better system notification than MUI you should upset BOOPSI itself, and not only for notification (think about MDI paradigm of some posts ago...).
I haven't used MUI much in the past, and not for years, but I wasn't smitten with the way the application interacts with MUI, the whole idea just seemed very clunky. Using the AmigaOS4 BOOPSI classes can be very flexible. It can be used the way that is shown in the example sources, or you can set up notification on just about everything by using IDCMP_IDCMPUPDATE and a hook. Personally I like the way Reaction works, as opposed to my memories of MUI.
Quote:
Zune is here, ready to be ported by someone who knows Intuition/BOOPSI programming, it is just usable instead of MUI3.8 on OS3.x, so I really see few steps for OS4 then a complete enhancement of BOOPSI/Reaction...and to abandon MUI where you haven't no decisional power (like Fab has suggested...)
I have nothing against someone porting Zune, but IMO it will only ever be a third-party thing, as opposed to an OS component. There is no need to include it, as we already have MUI (and all its apparent shortcomings), and the system will probably not be rewritten to use it, otherwise that would have already happened with MUI.
I think you (and everyone else that favours MUI) is going to have to resign themselves to the fact that AmigaOS4.x will not be supporting MUI, or a deriviative, as the default GUI toolkit. If a move away from the BOOPSI classes occurs, I'm sure it will be in favour of something that offers something more suitable.
Nope, AROS public licence provides commercial product can use code under this licence, in fact MorphOS uses dos.library taken from AROS and other parts...
dos.library, most of the C: commands, intuition.library, gadtools.library, asl.library, commodities.library, diskfont.library, icon.library, locale.library and iffparse.library were based on the AROS ones, probably much more. Half of MorphOS is, or at least was in early versions, just AROS/PPC
Quote:
The only thing is to release enhancements and fix under the same licence. The code used doesn't pollute with its licence the commercial product, close parts codes, etc...
Correct.
Quote:
it's very similar to BSD licence from which all Amiga TCP/IP stacks were born...
Wrong, it's very different to BSD licences. The APL is nearly the same as the MPL (Mozilla Public Licence). They are like a GPL withouth the virus part, all changes in the same source file have to be released, but it doesn't contaminate other sources linked with them.
but just updating MUI wouldn't help anyway, it's broken by design.
it's an your opinion, in my opinion it's Reaction to be broken by design compared with most modern GUI frameworks...
Quote:
If would want to have something as broken as MUI I could port the AROS Zune to AmigaOS 4.x and add the required AmigaOS 4.x changes, but since Zune can be used instead of MUI with MUI programs on AmigaOS 3.x they obviusly copied all design flaws of MUI and, except for the required AmigaOS 4.x changes MUI doesn't have, it would be just as bad
It's for you is not too difficult to port and add OS4.x features of MUI3.9 into Zune, a similar thing for final user and for you (OS4 team) wouldn't be bad because:
1) all users could have a complete Zune package (full personalization) without any key (MUI3.9OEM has only OS4.x default style...);
2) I believe that for OEM version of MUI the author taken a % on OS4, I don't know about what contract you have signed...using Zune nobody would take nothing to OS4 team...;
3) You can modify Zune to be more integrated with Intuition OS4 (for example, a trivial one, OS4 GUI prefs could configure even Zune and Zune prefs could disappear...);
I haven't used MUI much in the past, and not for years, but I wasn't smitten with the way the application interacts with MUI, the whole idea just seemed very clunky. Using the AmigaOS4 BOOPSI classes can be very flexible. It can be used the way that is shown in the example sources, or you can set up notification on just about everything by using IDCMP_IDCMPUPDATE and a hook. Personally I like the way Reaction works, as opposed to my memories of MUI.
Different point of view :)
I believe that if I should connect click of a button with a string for me it's simpler to write:
I have nothing against someone porting Zune, but IMO it will only ever be a third-party thing, as opposed to an OS component. There is no need to include it, as we already have MUI (and all its apparent shortcomings), and the system will probably not be rewritten to use it, otherwise that would have already happened with MUI.
In the actual state MUI is a third part thing (OEM), a Zune port would be much integrated to OS4 from fact it would be full and not OEM, and because you can have full power on Zune sources...
Quote:
I think you (and everyone else that favours MUI) is going to have to resign themselves to the fact that AmigaOS4.x will not be supporting MUI, or a deriviative, as the default GUI toolkit. If a move away from the BOOPSI classes occurs, I'm sure it will be in favour of something that offers something more suitable.
But this move away from BOOPSI will not happen tomorrow or from a year, I'm sure you know how much time taken to design a complete new GUI system with actual resources of Amiga universe, and time for testing a complete new solution. If Zune/MUI appears now better than BOOPSI/Reaction in many situation, most of modern ones, I don't understand why don't use this opportunity during waiting of a new modern GUI framework (and I believe this waiting will be long because there are many others very important thing to write before this GUI system). To use a full Zune version instead of a OEM MUI version could give to OS4 only benefits:
1) benefits for users = complete package without any key; 2) benefits for 3rd part devs = an alternative and under development GUI framework to use instead of BOOPSI/Reaction (under development because you could be free to add features without violating any kind of contract, like if I've understand, it happens now with MUI OEM on OS4); 3) benefits for OS4 team = you don't have to ask permission to modify Zune as you like, and you have full power over its sources...;
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
However...