Silly question

15 posts / 0 new
Last post
dbstastny
dbstastny's picture
Offline
Last seen: 3 years 2 weeks ago
Joined: 2017-02-04 00:01
Silly question

So I have been exploring building my own gadgets. I am bit stumped as to what defines a BOOPSI gadget to be a Reaction gadget. I clearly see distinction with MUI as it has its own messaging and base classes, but for Reaction I don't see any characteristics that clearly define any functional requirements for a Reaction gadget. I do see a lot of selective implementation of base GadgetClass attributes. For example GA_Hidden, does it work or not who knows until you try. Is there a clear helloworld gadget example that shows a skeleton of a gadgetclass derived gadget? Is the answer really only go read autodocs and headers? Half of TextEditor gadget don't work. I have found some decent information and reference materials on Thomas Rapp's site but I find I spend more time writing test programs and reverse engineering how controls work than writing working code and moving my project forward.

Sorry if this sounds whiny I do get the AmigaOS is limited with its user base I am just bit frustrated as this is slogging.

Anyone got any suggested references I might be missing?

Regards
Doug

thomas
thomas's picture
Offline
Last seen: 1 week 19 hours ago
Joined: 2011-05-16 14:23
Re: Silly question

Actually you cannot make true ReAction gadgets because ReAction has some internal features which are not documented. For example it calls undocumented methods and sets undocumented attributes.

But you can make BOOPSI gadgets which are compatible with ReAction. All you need to do is to implement the GM_DOMAIN and GM_LAYOUT methods beside the other mandatory methods.

And for proper rendering you need to store the backfill hook set by REACTION_BackFill as well as GA_BackFill and set it to the rastport before you start rendering (unless your gadget hasn't transparent parts and you always fill the whole area without calling EraseRect).

The texteditor gadget is the worst example of a BOOPSI class you can find. It seems to be some kind of back-port of a MUI class with all the MUI workings left in it but non-working in a ReAction environment.

mritter0
mritter0's picture
Offline
Last seen: 2 years 6 months ago
Joined: 2014-04-21 21:15
Re: Silly question

I posted on Hyperion's forum and spoke to Steven Solie at AmiWest 2017 about getting a fully functional gadget class source code posted so we could start making our own classes. We need to see all the bells and whistles so we know how things work.

Has this happened? Or course not. Will it? Probably not.

dbstastny
dbstastny's picture
Offline
Last seen: 3 years 2 weeks ago
Joined: 2017-02-04 00:01
Re: Silly question

Thank you gentleman I appreciate that I am not alone it the bit of frustration surrounding this.

Regards

DStastny

broadblues
broadblues's picture
Offline
Last seen: 4 years 10 months ago
Joined: 2012-05-02 21:48
Re: Silly question

So I have been exploring building my own gadgets.

It can be a bit daunting at first as the information is dotted arround quite a few places, but it's not actually that hard.

I am bit stumped as to what defines a BOOPSI gadget to be a Reaction gadget.

There is no such thing as Reaction under AmigaOS 4 just BOOPSI. So don't even worry about this.

I clearly see distinction with MUI as it has its own messaging and base classes, but for Reaction I don't see any characteristics that clearly define any functional requirements for a Reaction gadget.

MUI is a totally customsystem derived from rootclass, it's various gadgets are not actually gadgets in the intuition sense. What you are wanting to call Reaction gadgets are derived from gadgetclass and thus have intuition gadgets embeded in them.

I do see a lot of selective implementation of base GadgetClass attributes. For example GA_Hidden, does it work or not who knows until you try.

'gadgetclass' has no caps :-)

GA_Hidden is implmented by gadgetclass and sets the GMORE_HIDDEN flag, when that flag is set the gadget will not recieve input, will not be rendered etc, but it wont just disappear, without somekind of window refresh or rethink. It's not a flag I've ever used to be honest.

Is there a clear helloworld gadget example that shows a skeleton of a gadgetclass derived gadget?

http://wiki.amigaos.net/wiki/BOOPSI_Gadgets has a basic gadget. The version of that on the DevCD 2.1 is where I started from when I wrote my first gadgets.

Is the answer really only go read autodocs and headers?

Yes do that. people spent ages writing those thjings and every one just says there no documentation. Then ask questions. No question is too 'silly' fi you need to ask it odds are someone else will too.

Half of TextEditor gadget don't work.

Text editor is weird, half it's functionality is only accessable by sending it arexx commands. If you need to display blocks of read only text ot need basic multiline text input functionality then it's fine, anything more don't botther with it. I've wrung just about every drop of functionality out of it with MultiEdit, leaves alot to be desired.

dbstastny
dbstastny's picture
Offline
Last seen: 3 years 2 weeks ago
Joined: 2017-02-04 00:01
Re: Silly question

Well thanks for additional support as always. I am pleased I have gotten a basic gadget starting to work that is base "GadgetClass" :)

Not much so far but basic drawing and responding to activation and deactivation. Lots of crashing until i read a blurb about mandatory implementation of GadgetClass in the Autodocs.

I am curious about comment about the backfill hook. I don't think I need to worry about it as I am filling the background of entire gadget area but please let me know if that is not case.

DStastny

trixie
trixie's picture
Offline
Last seen: 7 months 3 weeks ago
Joined: 2011-02-03 13:58
Re: Silly question

@dbstastny

Well done on that! When you get the thing going, and if you feel like sharing your work to help other lost seekers, I'll be happy to include your code as an example in the AmigaOS4 Dev wiki.

AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2

dbstastny
dbstastny's picture
Offline
Last seen: 3 years 2 weeks ago
Joined: 2017-02-04 00:01
Re: Silly question

@trixie

I don't know if I will get a full on example as the parts I am developing is a replacement for the the crappy edit control. I will though make it fully open source under a very liberal open source license(non gpl). So that others can learn from and point out my mistakes as I am sure I don't have it fully optimal. But end goal is to support proper syntax highlighting mechanism.

I can mark up and fix the example broadblues linked. I don't know how I missed that. As it seems I have been all over the available wiki and documents. That example does have quite a few bugs in it and is clearly not up to par with proper calling methodologies in OS 4.1 It works but not all that well but enough to get me moving. Time permitting I'll update that source to be more 4.1 compatible and fix the few bugs I noted playing with it. I really wish we had access to source the reaction subsystem as there is stuff just very inconsistent. I don't know if it was merging capability into AmigaOS from ClassAct but some of its half-baked. I know there are those that like MUI but for me there are some design ideas they choose that I don't care for and it always feels foreign and I have no desire to pay money for the OS GUI kit so I can skin it. It just a weird license model.

DStastny

dbstastny
dbstastny's picture
Offline
Last seen: 3 years 2 weeks ago
Joined: 2017-02-04 00:01
Re: Silly question

So resurrecting this thread a bit. I am further along in developing my gadget class and I would like to put it into a library. But I can not find example of how to build a gadget library. There is no example of how to implement library that allows the Intuition function OpenClass to work? Anybody point me at example or have fragment of a library. I would just be guessing at how to implement correct entry points.

Thanks as always
Doug

DStastny

thomas
thomas's picture
Offline
Last seen: 1 week 19 hours ago
Joined: 2011-05-16 14:23
Re: Silly question

For OpenClass to work, your library base needs to be a struct ClassLibrary, which is a struct Library followed by a Class pointer. You need to fill in the Class pointer in your lib_open routine.

To be fully backwards compatible you should also implement a main interface with a GetClass routine, as well as a 68k jump table with the GetClass routine at offset -30.

The GetClass routine just returns the class pointer from the library base.

This is what OpenClass actually does:

  1. struct ClassLibrary *OpenClass (CONST_STRPTR name, uint32 version, Class **class_ptr)
  2. {
  3. struct ClassLibrary *base = (struct ClassLibrary *) OpenLibrary (name,version);
  4. if (base != NULL)
  5. *class_ptr = base->cl_Class;
  6. return (base);
  7. }
dbstastny
dbstastny's picture
Offline
Last seen: 3 years 2 weeks ago
Joined: 2017-02-04 00:01
Re: Silly question

Thank you Thomas,

After I posted this last night I was digging in includes and saw the ClassLibrary struct extend a struct Library and you verified my hypothesis. I am hesitant to assume anything.

Regards
Doug

DStastny

trixie
trixie's picture
Offline
Last seen: 7 months 3 weeks ago
Joined: 2011-02-03 13:58
Re: Silly question

@dbstastny

To be fully backwards compatible you should also implement a main interface with a GetClass routine, as well as a 68k jump table with the GetClass routine at offset -30.

But if you only aim at OS4.1 and newer, you don't need to bother with legacy stuff. GetClass() was deprecated yonks ago.

AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2

salass00
salass00's picture
Offline
Last seen: 7 months 1 week ago
Joined: 2011-02-03 11:27
Re: Silly question

For OpenClass to work, your library base needs to be a struct ClassLibrary, which is a struct Library followed by a Class pointer. You need to fill in the Class pointer in your lib_open routine.

The class creation and initialisation of library->cl_Class should be done in the libInit() function, with cleanup happening in the libExit() function.

To be fully backwards compatible you should also implement a main interface with a GetClass routine, as well as a 68k jump table with the GetClass routine at offset -30.

Only ClassAct/ReAction BOOPSI classes follow this convention as far as I'm aware. Datatype classes have something very similar with their ObtainEngine() vector, but they're a bit special since they have to be able to be opened by datatypes.library and so there needs to be a common way to obtain the class pointer.

Most other BOOPSI classes I've seen create a public class at libInit() time and programs then create instances of it using the public class name (which is often the same as the name of the library file) or use FindClass() to get the class pointer.

thomas
thomas's picture
Offline
Last seen: 1 week 19 hours ago
Joined: 2011-05-16 14:23
Re: Silly question

The class creation and initialisation of library->cl_Class should be done in the libInit() function, with cleanup happening in the libExit() function.

Yes, sorry that's what I meant. Lib_init should fill the class pointer.Lib_open only increases the use counter.

Only ClassAct/ReAction BOOPSI classes follow this convention as far as I'm aware.

The problem is that ClassAct/ReAction was misdesigned from the beginning. The classes didn't have a ClassLibrary base. So a simple back-port of the above OpenClass function to 68k would fail.

trixie
trixie's picture
Offline
Last seen: 7 months 3 weeks ago
Joined: 2011-02-03 13:58
Re: Silly question

programs [...] use FindClass() to get the class pointer.

Or they can of course obtain the class pointer right away from OpenClass():

  1. Class *classPointer; /* global variable */
  2.  
  3. MoronBase = IIntuition->OpenClass("gadgets/moron.gadget", 52, &classPointer);

AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2

Log in or register to post comments