Reaction is a v difficult system to work with. It's fine for a simple GUI but trying to do anything complex with it is a nightmare.
Strange, I don't see any flame war after this line, perhaps amigans have finally seen how lack Reaction is? :)
Quote:
1) Dynamic GUI changes cause lock ups. Yes I know there have been some fixes in 4.1 but these lockups can still occur
All modern UIs are based on these dynamic changes, so this is a BIG lack, as I said in past...
Quote:
2) Drag n drop built into objects. Drag and drop is possible but each object requires subclassing atm.
Nope, it's not possible at all. What you define with d&d is Workbench AppWindow support, but in Reaction you can't drag a Reaction object and drop it into another one or into Workbench. This is the reason Filer has no d&d, and it will never have until listbrowser.gadget (and so Reaction) will support a proper D&D API...
Quote:
3) It is impossible to subclass some objects due to the lack of exposed properties so effectively you have to write your own gadgets from scratch, increasing development time considerably.
This another very BIG Reacton flaw, without subclassing a Reaction class you can't build a proper big project without to become crazy to develop and MANTAIN it. All modern UI toolkits permit subclassing their classes.
Quote:
Certain OS developers have the opinion that you should not be subclassing system gadgets. Why? No idea seems pretty insane to me
Because they live into '80 ages, it's enouch clear to me
Quote:
4) Some objects do not support the standard gadget tags but instead implement their own tag that does the same thing. Trial and error makes development time v slow.
Sad thing which is joined with subclassing problem...
Quote:
5) Documentation is poor. I would like to see self documentating objects i.e. standard properties that return list of all supported tags, descriptions etc.
nope. MUI documentation is very poor, Reaction documentation is not existant... ;->
Quote:
Oh I could go on forever about how bad Reaction is when compared to other GUI systems.
I could go on forever about the fact without MUI I wouldn't have programming on The Amiga at all because MUI is more similar to modern programming styles than Reaction... ;->
What is missing from ReAction? What's wrong with the ReAction implmentation? Is it possible to fix without a total rewrite?
One of thing nobody has mentioned is Reaction notification system, this is few intuitive and very poor than MUI's one. If we said true, MUI notification system is what makes MUI intuitive, and gives to it a particular "Amiga" way to implement notification system into an UI toolkit. In fact even if other UI toolkits are more advanced than Reaction/MUI in many aspects, MUI notification system appears always more intuitive than other ones and enough powerful to use it into modern applications implementations. MUI notification mechanism is an "Amiga way" to do something and it would be nice if Reaction or whatever new UI will come on OS4 would implement it.
Quote:
In another thread I read about the limiting menu system of Amiga OS, which I gathered Intuition handles. Is this fixable with a new ReAction menu class?
sure, if someone would implement it/them
Quote:
Also what is generally missing or wrong in AmigaOS4 GUI that we (the users aswell as developers) want changed?
A new, modern (and if we can do, innovative) file manager/Desktop.
" 1) Dynamic GUI changes cause lock ups. Yes I know there have been some fixes in 4.1 but these lockups can still occur"
IIRC the old api calls were not fixed. There's a new set of functions that you should use for adding/removing components. So while it's true that apps that use the old methods may lock up, if may not be true that apps using the new methods do.
Code example for anyone interested:
if(LayoutBase->lib_Version>=53)
{
IIntuition->IDoMethod((Object *)mommy, LM_REMOVECHILD, inst->Win, ubrow->buttons[j], TAG_DONE);
}
else // Use fallback function. Note, this function may deadlock
{
IIntuition->RefreshSetGadgetAttrs(mommy, NULL, NULL, LAYOUT_RemoveChild, ubrow->buttons[j], TAG_DONE);
}
2) Drag n drop built into objects. Drag and drop is possible but each object requires subclassing atm.
Nope, it's not possible at all. What you define with d&d is Workbench AppWindow support, but in Reaction you can't drag a Reaction object and drop it into another one or into Workbench. This is the reason Filer has no d&d, and it will never have until listbrowser.gadget (and so Reaction) will support a proper D&D API...
It is possible but you have to subclass the objects and add the support yourself. Which leads back to the problem that some objects cannot be subclassed due to the lack of exposed properties.
@orgin
Quote:
IIRC the old api calls were not fixed. There's a new set of functions that you should use for adding/removing components. So while it's true that apps that use the old methods may lock up, if may not be true that apps using the new methods do.
This is what is so silly and messy with Reaction the old methods should have been fixed not introduce new methods.
NB From my understanding, there is no guarantee that the new methods will succeed so the child may or may not be removed / added. i.e. the problem is not fixed. It's just the deadlock is avoided.
I may be wrong, but I seem to recall that the old way of doing it was never supposed to be used on a live GUI. Someone explained a few months back that those methods could not be fixed for some reason. Hence the new methods.
Reaction is a v difficult system to work with. It's fine for a simple GUI but trying to do anything complex with it is a nightmare.
Strange, I don't see any flame war after this line,[...]
So you felt the need to start one
@Madmonkey Quote:
5) Documentation is poor. I would like to see self documentating objects i.e. standard properties that return list of all supported tags, descriptions etc.
Please no, I don't think users want to carry on their HD huge development materials for which they don't have a slight need of. The problem never were the form of the documentation but the people (and the time) to write it. IMHO autodocs are fine (the principle, see it has been adopted by almost every documentation system : javadoc, doc++, etc.) they just need a serious refreshment (that already started in latest SDK thanks to Steven Solie IIRC) and they should be kept up to date when the code is modified that's all. We also need more general documentation in order to understand the general concepts under such or such part (BOOPSI is probably the one needing the most explanation, but (good) device writing is another one for example).
It is possible but you have to subclass the objects and add the support yourself. Which leads back to the problem that some objects cannot be subclassed due to the lack of exposed properties.
Uhm, I haven't here my A1, I'm curiuos about this aspect of d&d, can you show me how Reaction API should work with d&d? Yes, definitely without subclassing life is very hard for Reaction programmers
Quote:
This is what is so silly and messy with Reaction the old methods should have been fixed not introduce new methods.
This is not always good, because it could be broke working applications, so with a fix they broke something else. This is the usual problem of an old broken API well know by programmers: they write their programs workaround problems, so their software become dependents by that bug. If a mantainer of that module fix the problem, all applications which workaround it will not work anymore. Old methods are mantained for compatibility, it's a good thing, BUT documentation MUST BE CLEAR, "OBSOLETE, DO NOT USE IT", or something similar So the real problem is lack of documentation at this point...
@ abalaban Quote:
So you felt the need to start one
I don't start any flame, only minded discussions ;-P
Quote:
Please no, I don't think users want to carry on their HD huge development materials for which they don't have a slight need of.
Ehm, you should speak for you ("in your opinon"): I would want huge development materials on my HD, without an huge (and ordered) documentation even a wonderful API become bad You give me a good book about Reaction from beginning to all new APIs of OS4 and I will program you in Reaction (sure, I want first a good menu class and subclassing support for all classes and d&d for all classes of course)
Quote:
IMHO autodocs are fine (the principle, see it has been adopted by almost every documentation system : javadoc, doc++, etc.) they just need a serious refreshment (that already started in latest SDK thanks to Steven Solie IIRC) and they should be kept up to date when the code is modified that's all. We also need more general documentation in order to understand the general concepts under such or such part (BOOPSI is probably the one needing the most explanation, but (good) device writing is another one for example).
Autodocs are fine for who knows where he must use his hands... and these people are few... for beginners (and in this Amiga situation we are all beginners, and even a good programmer from another platform would be a beginner if he would go into Amiga dev world) the only good thing would be an huge upgrade of RKRM Libraries, Devices and Style guide volumes.
"Autodocs are fine for who knows where he must use his hands... and these people are few... for beginners (and in this Amiga situation we are all beginners, and even a good programmer from another platform would be a beginner if he would go into Amiga dev world) the only good thing would be an huge upgrade of RKRM Libraries, Devices and Style guide volumes."
Yeah, I've been a developer since the 80's and I still find 'reaction' a bit hard to get into by just using the autodocs. The autodocs mostly focuses on individual api calls but it does not explain the overall concept and how you use it all together. There's plenty of examples where you're supposed to know certain things before reading the autodoc entry but those things aren't explained anywhere.
A book on intuition, BOOPSi objects, event handlers, GUI classes and whatnot would have been really nice. And no some ancient stuff on a dev cd from the previous century isn't always enough :)
I don't start any flame, only minded discussions ;-P
Nice one
Quote:
Quote:
Please no, I don't think users want to carry on their HD huge development materials for which they don't have a slight need of.
Ehm, you should speak for you ("in your opinon"): I would want huge development materials on my HD, without an huge (and ordered) documentation even a wonderful API become bad
No you misunderstood me : I too want huge development material *but* I don't think having binaries carrying this huge materials is a good thing especially for average (non developer) user : why would he want to waste so much place on its HD when he could have used this place to store more digital pictures of his little son and his family. Please we don't need to adopt the non sense of carrying developer documentation in the release binary... And my point still holds : there was not so much people to update the documentation in the autodoc (i.e. in the code source, just above the function) until recently why would there be more people to write (i.e. from scratch) it in your new system ?
Quote:
You give me a good book about Reaction from beginning to all new APIs of OS4 and I will program you in Reaction (sure, I want first a good menu class and subclassing support for all classes and d&d for all classes of course)
We agree we are in dire need of up to date documentation, but not just API documentation, we also need more general concept explaining documentation.
Quote:
Autodocs are fine for who knows where he must use his hands... and these people are few... for beginners (and in this Amiga situation we are all beginners, and even a good programmer from another platform would be a beginner if he would go into Amiga dev world) the only good thing would be an huge upgrade of RKRM Libraries, Devices and Style guide volumes.
This is not always good, because it could be broke working applications, so with a fix they broke something else.
It is always good to fix methods that are broken. Causing a system wide lockup I'd say is pretty broken.
It is silly to create new methods that do exactly the same thing and expect programmers to add additional code to use them every time a bug is fixed in the OS.
@All
Autodocs are fine as a format but sadly so much is missing.
Strange, I don't see any flame war after this line, perhaps amigans have finally seen how lack Reaction is? :)
No one said ReAction was perfect. Anyone who actually _has_ programmed software using RA will know of its shortcomings. And this is what this thread is for: identifying RA's weakest spots so that they could possibly be remedied in future updates. We're discussing things from the technical and user point of view. No need for flame wars.
Not if that method is broken by design (like dos.library/AbortPkt f.e.). In that case the only thing to do is to deprecate it and if possible add a new and better method.
Not if that method is broken by design (like dos.library/AbortPkt f.e.). In that case the only thing to do is to deprecate it and if possible add a new and better method.
Agreed APIs change and some methods become obsolete and are therefore deprecated.
It is however entirely idiotic to introduce a new function AbortPkt2 that accepts the same parameters and performs the same functionality as AbortPkt but works correctly.
No one said ReAction was perfect. Anyone who actually _has_ programmed software using RA will know of its shortcomings. And this is what this thread is for: identifying RA's weakest spots so that they could possibly be remedied in future updates. We're discussing things from the technical and user point of view. No need for flame wars.
Couldn't have said it better myself
This is the reason I started this thread in the first place. Not as a MUI vs ReAction war. But if MUI has good points then it's wise to adopt them into ReAction if possible.
I have read several times that Rigo has done extensive updates to ReAction during the past year (or more?).. Maybe Rigo could mention some of the fixes/additions that have been made, if they're not secrets until 4.1.1 is released?
I could never understand that war. I heartily believe MUI is the better of the two. No doubt about that. However, I program using ReAction, I enjoy it, and despite certain undisputable shortcomings, RA never let me down to the point that it became a showstopper.
Quote:
Maybe Rigo could mention some of the fixes/additions that have been made, if they're not secrets until 4.1.1 is released?
Rigo, and I think Steven Solie as well. Please please, give us a hint
Agreed APIs change and some methods become obsolete and are therefore deprecated.
It is however entirely idiotic to introduce a new function AbortPkt2 that accepts the same parameters and performs the same functionality as AbortPkt but works correctly.
That's not the case here. If you look at Orgin's code you will see that a gadget attribute to remove a gadget has been replaced with a method. I'm not sure using gadget attributes for this sort of functionality was intended by the designers of BOOPSI, and I suspect a gadget doing a self-call of a method to remove itself from some code which sets gadget attributes is asking for trouble.
If, as has been said, this was never documented in the first place, then just ditching it and doing it properly another way is the right choice.
If you look at Orgin's code you will see that a gadget attribute to remove a gadget has been replaced with a method. I'm not sure using gadget attributes for this sort of functionality was intended by the designers of BOOPSI
Tags should describe object properties, not invoke function calls - that's what methods are for. So the introduction of the child removing method was the right step, in line with OOP principles.
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
I don't start any flame, only minded discussions ;-P
