Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
34 user(s) are online (24 user(s) are browsing Forums)

Members: 1
Guests: 33

NinjaCyborg, more...

Support us!

Headlines

 
  Register To Post  

« 1 (2) 3 »
Re: ReAction, what is missing to make it a good GUI?
Just popping in
Just popping in


See User information
@madmonkey

Quote:

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... ;->

Go to top
Re: ReAction, what is missing to make it a good GUI?
Just popping in
Just popping in


See User information
@samwel

Quote:

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.

Go to top
Re: ReAction, what is missing to make it a good GUI?
Supreme Council
Supreme Council


See User information
@madmonkey

"
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 *)mommyLM_REMOVECHILDinst->Winubrow->buttons[j], TAG_DONE);
    }
    else 
// Use fallback function. Note, this function may deadlock
    
{
     
IIntuition->RefreshSetGadgetAttrs(mommyNULLNULLLAYOUT_RemoveChildubrow->buttons[j], TAG_DONE);
    }

Vacca foeda. Sum, ergo edo

Mr Bobo Cornwater
Go to top
Re: ReAction, what is missing to make it a good GUI?
Just popping in
Just popping in


See User information
@ShInKurO
Quote:

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...



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.

Go to top
Re: ReAction, what is missing to make it a good GUI?
Supreme Council
Supreme Council


See User information
@madmonkey

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.

Vacca foeda. Sum, ergo edo

Mr Bobo Cornwater
Go to top
Re: ReAction, what is missing to make it a good GUI?
Quite a regular
Quite a regular


See User information
@ShInKurO

Quote:

ShInKurO wrote:
Quote:

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).

Back to a quiet home... At last
Go to top
Re: ReAction, what is missing to make it a good GUI?
Just popping in
Just popping in


See User information
@madmonkey

Quote:

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.

Go to top
Re: ReAction, what is missing to make it a good GUI?
Just popping in
Just popping in


See User information
@orgin

Quote:

Code example for anyone interested:


Good to know, thanks

Go to top
Re: ReAction, what is missing to make it a good GUI?
Supreme Council
Supreme Council


See User information
@ShInKurO

"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 :)

Vacca foeda. Sum, ergo edo

Mr Bobo Cornwater
Go to top
Re: ReAction, what is missing to make it a good GUI?
Quite a regular
Quite a regular


See User information
@ShInKurO

Quote:
Quote:

So you felt the need to start one


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.


Yes I agree see my answer above.

Back to a quiet home... At last
Go to top
Re: ReAction, what is missing to make it a good GUI?
Just popping in
Just popping in


See User information
@ShInKurO

Quote:


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.

Go to top
Re: ReAction, what is missing to make it a good GUI?
Amigans Defender
Amigans Defender


See User information
@ShInKurO

Quote:

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.

Go to top
Re: ReAction, what is missing to make it a good GUI?
Not too shy to talk
Not too shy to talk


See User information
@ShInKurO

pftp uses a form of drag and drop for items between list windows.

Go to top
Re: ReAction, what is missing to make it a good GUI?
Just can't stay away
Just can't stay away


See User information
@madmonkey

Quote:

It is always good to fix methods that are broken.


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.

Go to top
Re: ReAction, what is missing to make it a good GUI?
Just popping in
Just popping in


See User information
@salass00

Quote:

salass00 wrote:
@madmonkey

Quote:

It is always good to fix methods that are broken.


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.

Go to top
Re: ReAction, what is missing to make it a good GUI?
Just popping in
Just popping in


See User information
@trixie

Quote:

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?

Best Regards,

Harry

[SOLD] ?A1-C, 512MB, Antec Aria
Go to top
Re: ReAction, what is missing to make it a good GUI?
Amigans Defender
Amigans Defender


See User information
@samwel

Quote:

MUI vs ReAction war


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

Go to top
Re: ReAction, what is missing to make it a good GUI?
Amigans Defender
Amigans Defender


See User information
@madmonkey

Quote:

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.

Go to top
Re: ReAction, what is missing to make it a good GUI?
Amigans Defender
Amigans Defender


See User information
@Chris

Quote:

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.

Go to top
Re: ReAction, what is missing to make it a good GUI?
Amigans Defender
Amigans Defender


See User information
@trixie

if you want real oop you should have:

mommy.RemoveChild(j)

this should be the right step...

i'm really tired...
Go to top

  Register To Post
« 1 (2) 3 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project