gadget down locking window

[meynaf]

Originally Posted by Thomas Richter

Again, if you need an "ordinary button" with an "unordinary rendering", create a "struct Gadget" as you now it, make the gadget rendering an "IntuiImage", but instead of putting an old-style IntuiImage, use a boopsi of the image class there, then in its rendering call, do whatever rendering you seem necessary. I believe there was an example in RKRM libraries to give you a quick start, but it's really not complicated.

The button is only an example, and unordinary rendering a small part of the problem.
Now what about a prop gadget ?
Or some edit box ? I'd like to add copy-paste in them.

Originally Posted by Thomas Richter

GadTools is not boopsis. GadTools is a helper library for building average "regular" gadgets that do regular rendering. This library is for the "boring" GUIs (I like so much) that look like the system preferences.

The radio buttons cannot be placed freely, but they do not need to. You can add spacing between them, and you can scale them (or even let them scale with the font size from v47 onwards).

But gadtools is something entirely different than boopsis.

I only mentioned Gadtools as something that i tried.

Originally Posted by Thomas Richter

You catch events in your event loop as usual. The boopsis themselves methods that are called if intuition wants something from them. But that's not for "interaction" with your main program.

And what if the boopsi wants to notify main program about something ? An item might have been selected in a list view, or the list might have been scrolled.

Originally Posted by Thomas Richter

Look, it's time to learn something, but once you have understood how these things go, it is really not hard.

And all this to discover it doesn't work either.
Simply inheriting from gadgetclass does not provide the wanted behaviour.

Originally Posted by Thomas Richter

"Your own way" is the wrong way as it depends on undcoumented system behaviour that may or may not change.

My own way is currently just drawing these gadgets myself.
If this is wrong, then MUI is wrong as well.

What's wrong is how the OS handles that. It should really have made this feature available for programs.
Open some console window and start selecting text on it. This won't block new windows catching the focus. You're obviously playing with something that's not a gadget but perhaps should behave like it was. However, the OS is simply unable to do this, and what if you want to write a console that does ?

Originally Posted by Thomas Richter

The refresh order is up to intution to decide - actually, it is up to the order of the gadgets in your gadget list. However, having something overlapping may be quite confusing to users, so I would really not recommend that.

Typical case of overlapping would be gadgets drawn over something in the like of a fillrectclass instance.

Originally Posted by Thomas Richter

We not only have system gadgets and boopsis, we also have a "RKRM user interface style guide" that is a good start for recommendations how to create a GUI.

I do not care that much about how to create a GUI for Amiga, as the library is just the implementation of something that might work on any platform (namely, my VM).

Originally Posted by Thomas Richter

What you render, and how you render in a boopsi is up to you. Thus, if you really realy want something overlapping, you can always clip rendering through a mask, or simply do not render into parts that overlap. But, again, RKRM user interface style guide.

That is doable inside of the library. But i also give the ability to create custom controls out of existing ones. For example, the client program might use some text and a normally invisible border. When the mouse hovers on the control, the border becomes visible, giving an underline effect (like the links in the winuae about page).
Again, portable GUI with no care about what RKRM says.

Originally Posted by Thomas Richter

That is another "not recommended" idea. Sure, you can add border gadgets, but then mark them as border gadgets as intuition may need to know when rendering the border on its own. However, do not mix with "in window" gadgets.

The point was that rendering inside a boopsi would perhaps have been better done by providing a rastport limited to the gadget's area.

Originally Posted by Thomas Richter

After only 5 minutes browsing, here is an example:

https://amigadev.elowar.com/read/ADC.../node0580.html

This is not the "simplest possible", but maybe a starter. Again, if you just need custom rendering (but nothing very specific as a gadget), I would start to derive from the image class, but that's all up to your likings.

That example gives a feeling of déjà vu.

Originally Posted by Thomas Richter

The good part about boopsis is that they have many more rendering options than regular gadgets, i.e. it is not only "pressed" or "releaesed", but also also "inactive", "activated" etc. as states such that you can customize the pens.

Rendering by hand has even more options.

[Olaf Barthel]

Originally Posted by Bruce Abbott

Horrible name, can't be bothered finding out more. I bet they don't work in 1.x either.

Naming things is hard, even in the real world.

Post Kickstart 1.3 work was underway to open up the building blocks of the intuition user interface, removing the limitations baked into them. Among the first changes made were the so-called custom gadgets. They enabled much finer control over how gadget input was processed and how the gadget was rendered. But that was not enough and a more general foundation for Gadgets, Images, etc. was introduced. This brought object-oriented programming to Intuition, which is what the BOOPSI acronym stands for: basic object-oriented programming system for Intuition. With emphasis on the "basic".

If the name sounds funny (but nobody's laughing), wait until you have seen how it works. It uses an object model adapted from Smalltalk, which is possibly the most powerful and at the same time least complex and most memory efficient option that works.

It is sufficiently powerful to both underpin Intuition data structures and to encapsulate, if so desired, complex user interface controls as well as images, sound, windows, etc. The DataTypes system of Kickstart 3.0 and beyond is built from BOOPSI classes. The colorwheel.gadget and gradientslider.gadget introduced in Kickstart 3.0 are loadable BOOPSI class libraries and gradientslider.gadget even has its own API.

This is powerful stuff which enables crazy degrees of control and leverage. If you haven't looked it up and read a bit about how it works and what it delivers, I certainly won't blame you. When this was new, I waited years because there was just so much to digest and put into context, never mind how this could become useful for your own work.

You are missing out on something, though, even if you should decide that this is not really a tool you would consider essential or even helpful for your own work. If you never heard about Smalltalk, you are certainly missing out on some major piece of tech which even so far has not gotten its due (Smalltalk is 52 years old by now).

That said, it definitely works better if it is integrated with a programming language. In its raw form the API surface, its data structures and its operations tend to be spare and crude. Which is why BOOPSI tends to be wrapped into more comfortable layers of APIs. This is not for everybody, but, as I mentioned, you may just be missing out on something here.

[meynaf]

Originally Posted by Olaf Barthel

The colorwheel.gadget and gradientslider.gadget introduced in Kickstart 3.0 are loadable BOOPSI class libraries and gradientslider.gadget even has its own API.

And they are together larger than my whole GUI system, which has 11 different control (gadget) kinds.

[Thorham]

Originally Posted by meynaf

And they are together larger than my whole GUI system, which has 11 different control (gadget) kinds.

Probably the usual C binary bloat, yuk

[Thomas Richter]

Originally Posted by meynaf

Now what about a prop gadget ?

Sure, can do. There is this propiclass (sp?) boopsi from which you can derive. It is used as ingredients in several other boopsis as well. IIRC, the colorwheel has a custom prop-type gadget in it. You can look it up there.

Originally Posted by meynaf

Or some edit box ? I'd like to add copy-paste in them.

Sure, can do. Look at the info box of the workbench "info" menu. That's another boopsi that allows editing, copy & paste.

Originally Posted by meynaf

I only mentioned Gadtools as something that i tried.

That something is however something completely different. (To quote the Pythons)

Originally Posted by meynaf

And what if the boopsi wants to notify main program about something ? An item might have been selected in a list view, or the list might have been scrolled.

Sure, can do. There is an interconnection class as well. Or you create a superclass of a container of two gadgets. The colorwheel is an example for this.

Originally Posted by meynaf

And all this to discover it doesn't work either.

That problem is, however, on your end. Do it properly, and it does work. I just pointed you to one pretty basic example.

Originally Posted by meynaf

My own way is currently just drawing these gadgets myself.
If this is wrong, then MUI is wrong as well.

I do not know what MUI does in detail, but from what I heard, it is using Boopsis. Drawing yourself and depending on intuition internals is *not* the right way of approaching this problem.

Originally Posted by meynaf

What's wrong is how the OS handles that. It should really have made this feature available for programs.

But.. it is available for programs. That's exactly what these intuition classes are good for.

Originally Posted by meynaf

Open some console window and start selecting text on it. This won't block new windows catching the focus. You're obviously playing with something that's not a gadget but perhaps should behave like it was. However, the OS is simply unable to do this, and what if you want to write a console that does ?

The right answer to that is to have an edit-boopsi. Actually, there are some. That was always planned for ViNCEd in a future edition, but it never became reality - because that would be the correct design for such a thing. The console-handler would be just the user of a console-type device which would be just the user of an intuition boopsi.



The reason why that project never became reality was, just to continue another discussion, that the whole thing is in assemler, which makes this an experience that was too tedious to start working on. This said, if I recall correctly, there is now an edit boopsi in 3.2 which you can just use for that. On my end, it is a bit too late, but hey, there is surely progress.

Originally Posted by meynaf

I do not care that much about how to create a GUI for Amiga, as the library is just the implementation of something that might work on any platform (namely, my VM).

Then you would need to work on top of a platform-independent abstraction anyhow. SDL might be one, but it does not have gadgets. It is too simple for that.

Originally Posted by meynaf

That is doable inside of the library. But i also give the ability to create custom controls out of existing ones. For example, the client program might use some text and a normally invisible border. When the mouse hovers on the control, the border becomes visible, giving an underline effect (like the links in the winuae about page).

Sure, doable.

Originally Posted by meynaf

Again, portable GUI with no care about what RKRM says.

Well, but if you do not care about what the Amiga does, then why ask Amiga specific questions?




[QUOTE=meynaf;1637268]

The point was that rendering inside a boopsi would perhaps have been better done by providing a rastport limited to the gadget's area.
[QUOTE]
That is pretty much what you get within your boopsi renderer. You get your own RP to render within, with offsets correctly adjusted.

Originally Posted by meynaf

Rendering by hand has even more options.

Actually, no. Look, Boopsis can communicate to your main program to set rendering options to whatever you like. In the OM_DRAW (IIRC) method, you get a series of flags what the system provides you as "context" for rendering. Raised-recessed-activated-deactivated, and a couple of more. But, of course, you can create your own methods to deliver any other option into the boopsi (transmogrified - on or off?) and let it draw depending on that state as well.


The system is really very flexible. In essense, it is just a "hook" structure with a call-back that goes into your code, and within that code, you dispatch from a delivered activity, and within that, you can do whatever you want with the resources you get.


The drawback is that some boopsis do *too much* in that context, and that context is in the intuition input event hook. So, with great power comes great responsibility.

[Thomas Richter]

Originally Posted by meynaf

And they are together larger than my whole GUI system, which has 11 different control (gadget) kinds.

That's because it already does quite a bit. Remember, it has to find proper rendering with a limited number of palette colors for the color-wheel. I believe it is one of the rare boopsis that requires services from the math libraries for all color-correct rendering.

[Thorham]

Originally Posted by Thomas Richter

I believe it is one of the rare boopsis that requires services from the math libraries for all color-correct rendering.

Don't tell me it needs square root.

[Thomas Richter]

If I recall correctly, it needs trigonometric functions, but it's been a while since I checked the code. It is mostly for calculating from the "hot spot" location the color to render, not to compute the "nearest possible color in a palette".

[meynaf]

Originally Posted by Thomas Richter

Sure, can do. There is this propiclass (sp?) boopsi from which you can derive. It is used as ingredients in several other boopsis as well.

I can derive from propgclass but it won't help. I'd have to rewrite everything so the class would be useless.

Originally Posted by Thomas Richter

IIRC, the colorwheel has a custom prop-type gadget in it. You can look it up there.

I've just looked it up. v39.6 colorwheel.gadget does not derive from, or use, boopsi's propgadget.

Originally Posted by Thomas Richter

Sure, can do. Look at the info box of the workbench "info" menu. That's another boopsi that allows editing, copy & paste.

The version i'm using doesn't do that. Not at all.

Originally Posted by Thomas Richter

That something is however something completely different. (To quote the Pythons)

And apparently not using the boopsis internally...

Originally Posted by Thomas Richter

Sure, can do. There is an interconnection class as well. Or you create a superclass of a container of two gadgets. The colorwheel is an example for this.

So basically i will need to instanciate lots of things, eat loads of memory, write a lot of code, just to make that blocking effect to work ?
Unreasonable.

Originally Posted by Thomas Richter

That problem is, however, on your end. Do it properly, and it does work. I just pointed you to one pretty basic example.

That the boopsis won't block the other windows is certainly not on my end. No no no.

Originally Posted by Thomas Richter

I do not know what MUI does in detail, but from what I heard, it is using Boopsis. Drawing yourself and depending on intuition internals is *not* the right way of approaching this problem.

If it is using the boopsis, even worse. Its buttons do *not* block other windows !
So i will have to rewrite everything to get a behaviour... that will not be there at the end !

Originally Posted by Thomas Richter

But.. it is available for programs. That's exactly what these intuition classes are good for.

These intuition classes do not procure this behaviour.
So no, it is not available for programs. Not at all.

Originally Posted by Thomas Richter

The right answer to that is to have an edit-boopsi. Actually, there are some. That was always planned for ViNCEd in a future edition, but it never became reality - because that would be the correct design for such a thing. The console-handler would be just the user of a console-type device which would be just the user of an intuition boopsi.


The reason why that project never became reality was, just to continue another discussion, that the whole thing is in assemler, which makes this an experience that was too tedious to start working on. This said, if I recall correctly, there is now an edit boopsi in 3.2 which you can just use for that. On my end, it is a bit too late, but hey, there is surely progress.

I'm not using 3.2 and certainly won't require it from my programs.

Originally Posted by Thomas Richter

Then you would need to work on top of a platform-independent abstraction anyhow. SDL might be one, but it does not have gadgets. It is too simple for that.

I do not work on top of a platform-independent abstraction. I provide it.

Originally Posted by Thomas Richter

Sure, doable.

Done, actually. But dependent on the order things are displayed.

Originally Posted by Thomas Richter

Well, but if you do not care about what the Amiga does, then why ask Amiga specific questions?

I want it to work on the Amiga as well as on other platforms, that's all.

Originally Posted by Thomas Richter

That is pretty much what you get within your boopsi renderer. You get your own RP to render within, with offsets correctly adjusted.

No this is not what i got. I only got rp with same properties as the window's rp.

Originally Posted by Thomas Richter

Actually, no.

Actually, yes. Rendering myself can only offer more options. There is nothing boopsi can do that i can not do too.

Originally Posted by Thomas Richter

Look, Boopsis can communicate to your main program to set rendering options to whatever you like. In the OM_DRAW (IIRC) method, you get a series of flags what the system provides you as "context" for rendering. Raised-recessed-activated-deactivated, and a couple of more. But, of course, you can create your own methods to deliver any other option into the boopsi (transmogrified - on or off?) and let it draw depending on that state as well.

I can provide the same information to any custom drawing, boopsi or not. It's just easier to do it directly.

Originally Posted by Thomas Richter

The system is really very flexible. In essense, it is just a "hook" structure with a call-back that goes into your code, and within that code, you dispatch from a delivered activity, and within that, you can do whatever you want with the resources you get.

But i do not need the boopsi to do whatever i want.

Originally Posted by Thomas Richter

The drawback is that some boopsis do *too much* in that context, and that context is in the intuition input event hook. So, with great power comes great responsibility.

This leads us to another issue : debugging in that context is far from obvious. I can do it, but it is more difficult.
And indeed, using a little bit too much cpu power isn't problematic in the app's context - as with my current solution. So the boopsi will add another problem that i didn't have before.

Originally Posted by Thomas Richter

That's because it already does quite a bit. Remember, it has to find proper rendering with a limited number of palette colors for the color-wheel. I believe it is one of the rare boopsis that requires services from the math libraries for all color-correct rendering.

Only libraries used in colorwheel.gadget 39.6 are graphics, intuition, utility.

[aros-sg]

I wonder if it would not make sense for the OS (or a little patch) to check in openwindow if left mouse button (maybe other buttons, too) is pressed, and if so, force the new window to open in inactive state, even if the guy who made the openwindow call set WFLG_ACTIVATE or WA_Activate,TRUE.

Can anyone think of a case, where this would not be more desirable than Intuition stealing the focus while user is obviously doing something in current active window?

[meynaf]

Originally Posted by aros-sg

I wonder if it would not make sense for the OS (or a little patch) to check in openwindow if left mouse button (maybe other buttons, too) is pressed, and if so, force the new window to open in inactive state, even if the guy who made the openwindow call set WFLG_ACTIVATE or WA_Activate,TRUE.

Can anyone think of a case, where this would not be more desirable than Intuition stealing the focus while user is obviously doing something in current active window?

If done this way, the new window isn't gonna be activated when the mouse button is finally released.

[Thomas Richter]

Originally Posted by aros-sg

I wonder if it would not make sense for the OS (or a little patch) to check in openwindow if left mouse button (maybe other buttons, too) is pressed, and if so, force the new window to open in inactive state, even if the guy who made the openwindow call set WFLG_ACTIVATE or WA_Activate,TRUE.

This is the wrong type of test. The right type of test is whether intuition is currently in a state where it is in some interactive feedback from the user, and that is not limited to the mouse buttons. Actually, that is all codified in the intuition internal state machine and as such handled correctly.

[Thomas Richter]

Originally Posted by meynaf

I can derive from propgclass but it won't help. I'd have to rewrite everything so the class would be useless.

Why "does it not help"?

Originally Posted by meynaf

I've just looked it up. v39.6 colorwheel.gadget does not derive from, or use, boopsi's propgadget.

That's the gradient slider then. It is used by the color preferences together with the color wheel.

Originally Posted by meynaf

So basically i will need to instanciate lots of things, eat loads of memory, write a lot of code, just to make that blocking effect to work ?
Unreasonable.

What's unreasonable is the "lots of memory". Let's count. You need a hook structure, and the boopsi class and the boopsi. That accounts for each class for less than 100 bytes, plus probably 30 bytes per instance. Lots of memory? No. It is not "making the blocking to work", it is "for interacting with the system in the intended way", potentially allowing for customization if using the system classes.

Originally Posted by meynaf

I want it to work on the Amiga as well as on other platforms, that's all.

I'm not aware of a cross-platform GUI that also covers the Amiga. There is a cross-platfrom graphics interface (SDL) that also works on the Amiga, but that is too low level for you.

Originally Posted by meynaf

No this is not what i got. I only got rp with same properties as the window's rp.

Huh? Of course it should share the properties of the window RP. It need to. In particular, it need to render into the same layer and same bitmap, but you have your own mask, font... So that is exactly what is needed.

Originally Posted by meynaf

Actually, yes. Rendering myself can only offer more options. There is nothing boopsi can do that i can not do too.

Yes, it has the internal states of intuition availble which is what you do not have. It knows what *intuition knows* on the state of the object, and thus intuition messages are consistent with rendering. In your own code, you do not have such information at hand because intuition does not expose it (correctly so).

Originally Posted by meynaf

I can provide the same information to any custom drawing, boopsi or not. It's just easier to do it directly.

And just so wrong... With this type of argument, you can just wash away AmigaOs in total, "I can do it myself". The problem is - it plays badly with the user. Your GUI will not integrate well into the system, will not respect user preference and system customization.

Originally Posted by meynaf

And indeed, using a little bit too much cpu power isn't problematic in the app's context - as with my current solution. So the boopsi will add another problem that i didn't have before.

Which "additional CPU power"? For calling your hook from the intuition input hook? Be serious...

[meynaf]

Originally Posted by Thomas Richter

Why "does it not help"?

Let me repeat myself :
"I'd have to rewrite everything so the class would be useless."
If you want to make the boopsi look like f.e. a gadtools slider, you have to draw it yourself and ignore the base class rendering completely.
And about the events, you'd have to do it too because you do not have access to the base class internal state (or you have to tell me how).

Originally Posted by Thomas Richter

That's the gradient slider then. It is used by the color preferences together with the color wheel.

Neither.
All two contain the string "gadgetclass" but no other base class name.

Originally Posted by Thomas Richter

What's unreasonable is the "lots of memory". Let's count. You need a hook structure, and the boopsi class and the boopsi. That accounts for each class for less than 100 bytes, plus probably 30 bytes per instance. Lots of memory? No.

That amounts for a few kb, which still looks unreasonable considering that today there is no host memory associated with the current gadgets.

Originally Posted by Thomas Richter

It is not "making the blocking to work", it is "for interacting with the system in the intended way", potentially allowing for customization if using the system classes.

Come on, if drawing yourself on a window wasn't an intended way, there would be no APIs for doing it.

Originally Posted by Thomas Richter

I'm not aware of a cross-platform GUI that also covers the Amiga.

It's not easy to achieve.
Perhaps you could help, instead of criticizing.

Originally Posted by Thomas Richter

There is a cross-platfrom graphics interface (SDL) that also works on the Amiga, but that is too low level for you.

SDL didn't even do the job for the PC version of the graphics (not UI) part. I had to use DX11.

Originally Posted by Thomas Richter

Huh? Of course it should share the properties of the window RP. It need to. In particular, it need to render into the same layer and same bitmap, but you have your own mask, font... So that is exactly what is needed.

As long as it does not use coordinates relative to the gadget and cut any rendering not made in the gadget's area, no, it's not exactly what is needed.

Originally Posted by Thomas Richter

Yes, it has the internal states of intuition availble which is what you do not have. It knows what *intuition knows* on the state of the object, and thus intuition messages are consistent with rendering. In your own code, you do not have such information at hand because intuition does not expose it (correctly so).

I don't have more information about intuition's internal state inside of a boopsi than outside. Can i tell intuition the user is doing something with a gadget from inside a boopsi ? No.

Originally Posted by Thomas Richter

And just so wrong... With this type of argument, you can just wash away AmigaOs in total, "I can do it myself".

Ha!
I'm drawing with graphics primitives and receiving intuition idcmp messages. If that's washing away AmigaOs in total...

Originally Posted by Thomas Richter

The problem is - it plays badly with the user. Your GUI will not integrate well into the system, will not respect user preference and system customization.

Why would it not ? System preferences are not hidden in such a way programs can't access them.
And boopsis wouldn't fare better. That's complete nonsense. As if drawing inside of a boopsi would have given a different result than drawing outside !

Originally Posted by Thomas Richter

Which "additional CPU power"? For calling your hook from the intuition input hook? Be serious...

It was you who told me many boopsis could make the system unresponsive...

[Thomas Richter]

Originally Posted by meynaf

Let me repeat myself :
"I'd have to rewrite everything so the class would be useless."

Why the class code would be useless? It would be used.

Originally Posted by meynaf

If you want to make the boopsi look like f.e. a gadtools slider, you have to draw it yourself and ignore the base class rendering completely.

Why?

Originally Posted by meynaf

And about the events, you'd have to do it too because you do not have access to the base class internal state (or you have to tell me how).

The corresponding OM_GET methods of the base class. Which states the base class exposes is up to the base class, of course.

Originally Posted by meynaf

Come on, if drawing yourself on a window wasn't an intended way, there would be no APIs for doing it.

Drawing graphics on a window has its purpose, of course. Mainly, to draw (non-interactive) elements there. Interactive elements should (shall?) be represented by intuition.

Originally Posted by meynaf

It's not easy to achieve.
Perhaps you could help, instead of criticizing.

That would be next week then, sorry. Right now, I'm in SAN, a couple of thousand miles away from the Amiga and I need to respond from memory. It's been a while I worked with Boopsis. Most GUIs I do are "boring gadtools" because that's all I need.

Originally Posted by meynaf

SDL didn't even do the job for the PC version of the graphics (not UI) part. I had to use DX11.

While I do not know how SDL works internally, it is probably build on top of DX11, but I'm not sure. It may also depend on the version of SDL. 1.2 is probably based on direct draw, but I really do not know. Is there any particular reason to depend on a particular graphics system? If platform independence of (simple) graphics is what counts, SDL is a good choice. If you need a platform independent GUI, then gtk or Qt are good options, but they exclude the Amiga.

Originally Posted by meynaf

As long as it does not use coordinates relative to the gadget and cut any rendering not made in the gadget's area, no, it's not exactly what is needed.

If I recall, it adjusts offsets for you, but it has been a while. Rendering outside of a gadget area is not such a nice idea, but for that it would need to install a cliprect, and it probably does not. But again, I would need to check. This is all OM_DRAW magic.

Originally Posted by meynaf

I don't have more information about intuition's internal state inside of a boopsi than outside. Can i tell intuition the user is doing something with a gadget from inside a boopsi ? No.

Yes, you do. This is exactly what I said before. From the gadget itself, you only have "raised/recessed" available, and intuition does "ghosting" for you for on/off. Within a boopsi, you had on/off, active/inactive, on/off or so, but I need to check. But, again, that is documented material, you find that in the RKRM on boopsis. For the border "iconification" gadget I did iI remember that its rendering also depended on the state of the window (i.e. whether the window was receiving input or not) and that is available as state as well.

Originally Posted by meynaf

Ha!
I'm drawing with graphics primitives and receiving intuition idcmp messages. If that's washing away AmigaOs in total...

You (and intuition) are always drawing with graphics primitiviities of course, but *where* and *triggered how*.

Originally Posted by meynaf

Why would it not ? System preferences are not hidden in such a way programs can't access them.

System preferences are not necessarily something you can anticipate today. It would not surprise me if we will have (at some point) a system preferences that changes the look and feel of the system gadgets. Actually, we do have VisualPrefs for this today, and of course that works for programs using system components for their GUI.

Originally Posted by meynaf

It was you who told me many boopsis could make the system unresponsive...

That is not so much a problem of "having a hook and a dispatcher". The problem arises because some boopsis have a complex problem to solve. A particular example is the layout class. If a window gets resized, the layout boopsi has to go through all its children, potentially being layout boopsis as well, and tell them (hierarchically) to resize themselves and adjust themselves to the new window size. Depending on the number of boopsis and the number of levels, this will simply take a while, no matter how exactly the boopsi calling mechanism works. The problem is a complex problem and requires a lot of coordinate adjustments.


Now, that complexity itself cannot be avoided, but with the current design, the computation is performed in the wrong task, namely as part of the input event handler of intuition and as such as part of the input device. Thus, when the layout is redone, the mouse pointer cannot move because it is done by the task that is responsible for moving the mouse pointer itself, and *that* makes the system irresoponsive. So the design problem is not such much that we have boopsis or hooks, but that their rendering and activation is run as part of the intuition input event handler.


This problem would neither go away by having a different or more (or less?) sophisticated calling mechanism for boopsi code. The problem would go away if intuition would dispatch such activitiy to the user code as part of IDCMP handling. Unfortunately, the damage is done at this point, and I would have no clear idea how to resolve that. But I'm not the intuition expert either. Massimo is.



Long story short: Boopsis are fine, as long as you don't create huge hierarchies of them and nest them. Complex GUIs are a problem for underpowered machines like the Amiga anyhow, but the boopsi design of "letting intuition do everything" is too simple to address this issue.

[meynaf]

Originally Posted by Thomas Richter

Why the class code would be useless? It would be used.

The parent class code wouldn't be used, no. At least, not the display part.

Originally Posted by Thomas Richter

Why?

Because the base class won't draw the expected result. A boopsi propgadget looks like... well, a boopsi propgadget.

Originally Posted by Thomas Richter

The corresponding OM_GET methods of the base class. Which states the base class exposes is up to the base class, of course.

And what does it expose ? Where is it documented ?

Originally Posted by Thomas Richter

Drawing graphics on a window has its purpose, of course. Mainly, to draw (non-interactive) elements there. Interactive elements should (shall?) be represented by intuition.

There are elements intuition can't represent. Why do you think we got third-party UI software.

Originally Posted by Thomas Richter

That would be next week then, sorry. Right now, I'm in SAN, a couple of thousand miles away from the Amiga and I need to respond from memory. It's been a while I worked with Boopsis. Most GUIs I do are "boring gadtools" because that's all I need.

Next week is better than never.

Originally Posted by Thomas Richter

While I do not know how SDL works internally, it is probably build on top of DX11, but I'm not sure. It may also depend on the version of SDL. 1.2 is probably based on direct draw, but I really do not know. Is there any particular reason to depend on a particular graphics system? If platform independence of (simple) graphics is what counts, SDL is a good choice. If you need a platform independent GUI, then gtk or Qt are good options, but they exclude the Amiga.

SDL wasn't up to the job. Poor pixel scaling, messaging system (window events) not giving the right information (f.e. keyboard positional information).
For making it work, i would have had to alter it in heavy ways - it ended up better to base myself on something of lower level.
After all, SDL itself is based on something else - i just did the same.
Of course, using SDL on the Amiga itself was just out of question, for performance issues.

And, do not confuse the needs here. DX11 was to provide 2D frame buffer, not at all for GUI using gadgets - that part is regular GDI.

Originally Posted by Thomas Richter

If I recall, it adjusts offsets for you, but it has been a while. Rendering outside of a gadget area is not such a nice idea, but for that it would need to install a cliprect, and it probably does not. But again, I would need to check. This is all OM_DRAW magic.

All i can say is that when responding to GM_RENDER i could get a rastport in two ways - in the message and by calling ObtainGIRPort - and both gave me a rp relative to window position (including borders).

Originally Posted by Thomas Richter

Yes, you do. This is exactly what I said before. From the gadget itself, you only have "raised/recessed" available, and intuition does "ghosting" for you for on/off. Within a boopsi, you had on/off, active/inactive, on/off or so, but I need to check. But, again, that is documented material, you find that in the RKRM on boopsis. For the border "iconification" gadget I did iI remember that its rendering also depended on the state of the window (i.e. whether the window was receiving input or not) and that is available as state as well.

No i don't. I repeat the question : Can i tell intuition the user is doing something with a gadget from inside a boopsi ?
(Remember, this is the whole purpose of this thread.)

Originally Posted by Thomas Richter

You (and intuition) are always drawing with graphics primitiviities of course, but *where* and *triggered how*.

As long as it works fine, i won't care about where and triggered how.

Originally Posted by Thomas Richter

System preferences are not necessarily something you can anticipate today. It would not surprise me if we will have (at some point) a system preferences that changes the look and feel of the system gadgets. Actually, we do have VisualPrefs for this today, and of course that works for programs using system components for their GUI.

My UI is designed to be portable. It has to be.
Therefore Amiga-specific stuff either works for my needs or is thrown away.
The current system is weak and it's too late to change it, as the software will have to work ideally down to v36. It does not differentiate between button background color and window background color. Window background is of color 0 and knows nothing else. There is no pen dedicated for a text cursor, or selected text, or even knob colors.

Originally Posted by Thomas Richter

That is not so much a problem of "having a hook and a dispatcher". The problem arises because some boopsis have a complex problem to solve. A particular example is the layout class. If a window gets resized, the layout boopsi has to go through all its children, potentially being layout boopsis as well, and tell them (hierarchically) to resize themselves and adjust themselves to the new window size. Depending on the number of boopsis and the number of levels, this will simply take a while, no matter how exactly the boopsi calling mechanism works. The problem is a complex problem and requires a lot of coordinate adjustments.


Now, that complexity itself cannot be avoided, but with the current design, the computation is performed in the wrong task, namely as part of the input event handler of intuition and as such as part of the input device. Thus, when the layout is redone, the mouse pointer cannot move because it is done by the task that is responsible for moving the mouse pointer itself, and *that* makes the system irresoponsive. So the design problem is not such much that we have boopsis or hooks, but that their rendering and activation is run as part of the intuition input event handler.

This is just another reason to not use boopsi.

Originally Posted by Thomas Richter

This problem would neither go away by having a different or more (or less?) sophisticated calling mechanism for boopsi code. The problem would go away if intuition would dispatch such activitiy to the user code as part of IDCMP handling. Unfortunately, the damage is done at this point, and I would have no clear idea how to resolve that. But I'm not the intuition expert either. Massimo is.

And what do you think i'm currently doing ?

Originally Posted by Thomas Richter

Long story short: Boopsis are fine, as long as you don't create huge hierarchies of them and nest them. Complex GUIs are a problem for underpowered machines like the Amiga anyhow, but the boopsi design of "letting intuition do everything" is too simple to address this issue.

Which is exactly what will happen in my GUI.
Of course it's gonna be complex, but the Amiga will still be up to the job.

I'd like to see such a complex GUI btw, to check if my library will be able to reproduce it.

[Thomas Richter]

So, here is a little bit of code. This creates a custom subclass of the image class which is used for rendering the "iconification" gadget of VINCEd. It is used as "intuiImage" drop in for the Gadget "Render" image.

First, the class constructor:

InitIconifyClass:
        saveregs a2-a3/a6

        move.l a6,a3
        sub.l a0,a0                     ;Klasse ist privat
        sub.l a2,a2                     ;Superklasse ist public
        move.l vc_IntBase(a4),a6        ;IntuitionBase
        moveq #0,d0                     ;wir brauchen keine privaten Daten
        moveq #0,d1                     ;noch Flags
        lea ImageClass,a1               ;Superklasse ist imageclass
        jsr MakeClass(a6)               ;erzeuge die Klasse
        move.l d0,a1                    ;sichern
        tst.l d0
        beq.s .exit                     ;bei Fehler hinaus
        lea IconifyImageDispatcher(pc),a0     ;den Dispatcher
        clr.l h_SubEntry(a1)            ;weiteren SubHook löschen
        move.l a0,h_Entry(a1)           ;eintragen
        move.l a3,h_Data(a1)            ;Data ist VNCBase
.exit:
        loadregs
        rts

The class starts with a hook structure which defines the entry point of the "message dispatcher". This is in this case a bit lengthy as it has to draw quite a bit and select the proper pens. As you can see from the "state" information, there is quite a bit more available than just what the gadget has:

;*************************************************
;** IconifyImageDispatcher                      **
;**                                             **
;** dies ist der Dispatcher für die Iconify     **
;** Klasse                                      **
;**     a0      =       Class                   **
;**     a2      =       Object                  **
;**     a1      =       Message                 **
;*************************************************
IconifyImageDispatcher:
        saveregs d2-d7/a2-a6

        move.l h_Data(a0),a5                    ;hole VNCBase
        move.l (a1),d0                          ;hole die Methode

        sub.l #IM_DRAW,d0
        beq.s .drawobject                       ;IM_DRAW?
        subq.l #4,d0
        beq.s .drawobject                       ;IM_DRAWFRAME?
;**
;**     hier die Default-Methode: An die Superklasse verweisen
;**
        move.l cl_Super(a0),a0                  ;Super-Methode holen
        bsr CallHook                            ;alles andere ist noch
                                                ;korrekt initialisiert
        bra .exit
;**
;**     hier OM_DRAW und OM_DRAWFRAME
;**
.drawobject:

        move.l a1,a4                            ;sichere die Message
        move.l vc_GfxBase(a5),a6
        move.l impd_DrInfo(a4),d0               ;haben wir eine DrawInfo?
        beq .nodri


        movem.w impd_OffsetX(a4),d2-d3          ;X,YOffset aus der Message
        move.l impd_RPort(a4),a3                ;RastPort holen
        add.w ig_LeftEdge(a2),d2                ;plus LeftEdge aus der Struktur
        add.w ig_TopEdge(a2),d3                 ;plus TopEdge

        movem.w ig_Width(a2),d4-d5              ;Breite,Höhe->d4,d5
        cmp.l #IM_DRAWFRAME,(a4)                ;ist das DRAW_FRAME
        bne.s .nodrawframe
        movem.w impd_DimensionsWidth(a4),d4-d5  ;ansonsten von hierher
.nodrawframe:
        add.w d2,d4
        add.w d3,d5
        subq.w #2,d4                            ;wg. TBI-Kollision.
        subq.w #1,d5                            ;rechten unteren Rand berechnen

        move.l impd_DrInfo(a4),a0               ;DrawInfo->a0
        move.l impd_State(a4),d1                ;Draw-State->d0
        move.l dri_Pens(a0),a0                  ;Pens->a0
        movem.w SHINEPEN*2(a0),d6-d7            ;Shine,ShadowPen->d6,d7
        move.w FILLPEN*2(a0),d0                 ;Fillpen
        subq.l #IDS_SELECTED,d1                 ;Draw-State=1? (Selected)
        bne.s .nodraw1
        exg.l d6,d7                             ;ja, so austauschen
.nodraw1:
        subq.l #IDS_INACTIVENORMAL-IDS_SELECTED,d1         ;oder fünf?
        beq.s .selectbgpen
        subq.l #IDS_INACTIVEDISABLED-IDS_INACTIVENORMAL,d1 ;oder sechs?
        bne.s .noselectpen
.selectbgpen:
        move.w BACKGROUNDPEN*2(a0),d0           ;Backgroundpen
.noselectpen:
        move.l a3,a1
        jsr SetAPen(a6)                         ;setze den Hintergrundstift
        saveregs d2-d3

        move.l d2,d0
        move.l d3,d1
        move.l d4,d2
        move.l d5,d3                            ;Koordinaten
        addq.l #1,d1
        subq.l #1,d3
        move.l a3,a1
        jsr RectFill(a6)                        ;ausfüllen
        loadregs

                                                ;now the upper and lower lines
        move.l d6,d0
        move.l a3,a1
        jsr SetAPen(a6)

        move.l d2,d0
        move.l d3,d1
        move.l a3,a1
        jsr Move(a6)                            ;upper left

        move.l d4,d0
        move.l d3,d1
        jsr Draw(a6)

        move.l d7,d0
        move.l a3,a1
        jsr SetAPen(a6)

        move.l d2,d0
        move.l d5,d1
        move.l a3,a1
        jsr Move(a6)

        move.l d4,d0
        move.l d5,d1
        move.l a3,a1
        jsr Draw(a6)

                                                ;left and right border
        move.l impd_DrInfo(a4),a0               ;DrawInfo->a0
        move.l impd_State(a4),d0
        move.l dri_Pens(a0),a0                  ;Pens->a0
        move.w SHADOWPEN*2(a0),d1               ;Pen für diese linke Kante: Immer Shadow
        subq.l #IDS_INACTIVENORMAL,d0           ;oder fünf?
        beq.s .selectfine
        subq.l #IDS_INACTIVESELECTED-IDS_INACTIVENORMAL,d0  ;oder sechs? (disabled)
        beq.s .selectfine
        cmp.w FILLPEN*2(a0),d6                  ;==Fillpen?
        bne.s .selectfine
        move.w BACKGROUNDPEN*2(a0),d6           ;Backgroundpen
        move.w FILLPEN*2(a0),d7
.selectfine:

        move.l d1,d0
        move.l a3,a1                            ;ShadowPen
        jsr SetAPen(a6)

        move.l d2,d0
        move.l d3,d1
        subq.l #1,d0
        addq.l #1,d1                            ;links oben
        move.l a3,a1
        jsr Move(a6)

        move.l d2,d0
        move.l d5,d1
        subq.l #1,d0                            ;schwarz links daneben malen
        subq.l #1,d1
        move.l a3,a1
        jsr Draw(a6)                            ;linke Kante

        cmp.w d6,d7
        beq.s .nodouble

        move.l d6,d0
        move.l a3,a1                            ;ShinePen
        jsr SetAPen(a6)

        move.l d2,d0
        move.l d3,d1
        addq.l #1,d1                            ;links oben
        move.l a3,a1
        jsr Move(a6)

        move.l d2,d0
        move.l d5,d1
        subq.l #1,d1
        move.l a3,a1
        jsr Draw(a6)                            ;linke Kante

        move.l d7,d0
        move.l a3,a1                            ;ShadowPen
        jsr SetAPen(a6)

        move.l d4,d0
        move.l d3,d1
        addq.l #1,d1
        move.l a3,a1
        jsr Move(a6)

        move.l d4,d0
        move.l d5,d1
        subq.l #1,d1
        move.l a3,a1
        jsr Draw(a6)
.nodouble:

        move.l impd_DrInfo(a4),a0               ;DrawInfo->a0
        move.l impd_State(a4),d6                ;Draw-State->d6
        move.l dri_Pens(a0),a0                  ;Pens->a0
        move.l d6,d1
        move.w SHADOWPEN*2(a0),d0               ;Shadowpen
        subq.l #IDS_INACTIVENORMAL,d1
        beq.s .isfine
        subq.l #IDS_INACTIVESELECTED-IDS_INACTIVENORMAL,d1  ;nonactive?
        beq.s .isfine
        cmp.w FILLPEN*2(a0),d0                  ;==FillPen?
        bne.s .isfine
        move.w BACKGROUNDPEN*2(a0),d0           ;then BGPen
.isfine:
        move.l a3,a1
        move.l d0,d7                            ;keep it
        jsr SetAPen(a6)

        move.l d5,d1
        sub.l d3,d1                             ;Höhe bestimmen
        addq.l #2,d1
        divu #5,d1
        swap d1
        clr.w d1
        swap d1                                 ;Randverringerung

        move.l d6,d0                            ;Drawstate->d0
        addq.l #4,d2
        add.l d1,d3
        subq.l #4,d4
        sub.l d1,d5                             ;shrink box
        subq.l #1,d0                            ;selected?
        bne.s .isnot
        move.l d2,d4                            ;shrink box further
        addq.l #7,d4
        move.l d5,d3
        subq.l #6,d3
.isnot:
        bsr.s _DrawFrame

        addq.l #2,d2
        move.l d2,d4
        addq.l #3,d4
        subq.l #2,d5
        move.l d5,d3
        subq.l #2,d3
        bsr.s _DrawFrame

        addq.l #1,d2
        addq.l #1,d3
        subq.l #1,d4
        subq.l #1,d5

        move.l impd_DrInfo(a4),a0               ;DrawInfo->a0
        move.l dri_Pens(a0),a0                  ;Pens->a0
        move.w SHINEPEN*2(a0),d0                ;Shinepen
        cmp.w d0,d7
        bne.s .isok
        move.w SHADOWPEN*2(a0),d0               ;sonst ShadowPen
.isok:
        subq.l #IDS_INACTIVENORMAL,d6           ;oder fünf?
        beq.s .selectbgpen2
        subq.l #IDS_INACTIVESELECTED-IDS_INACTIVENORMAL,d6  ;oder sechs?
        bne.s .noselectpen2
.selectbgpen2:
        move.w BACKGROUNDPEN*2(a0),d0            ;Backgroundpen
.noselectpen2:
        move.l a3,a1
        jsr SetAPen(a6)

        bsr.s _DrawFrame
.nodri:
        moveq #0,d0
.nomsg:
.exit:
        loadregs
        rts

_DrawFrame:
        move.l d2,d0
        move.l d3,d1
        move.l a3,a1
        jsr Move(a6)

        move.l d4,d0
        move.l d3,d1
        move.l a3,a1
        jsr Draw(a6)

        move.l d4,d0
        move.l d5,d1
        move.l a3,a1
        jsr Draw(a6)

        move.l d2,d0
        move.l d5,d1
        move.l a3,a1
        jsr Draw(a6)

        move.l d2,d0
        move.l d3,d1
        move.l a3,a1
        jsr Draw(a6)                            ;frame is drawn.
        rts

Finally, how to create such an image. There are three cases here: First, the code attempts to create a sysiclass object, then one of Massimo's image classes from VisualPrefs, and finally, one of mine:

AllocIconify:
        saveregs a2/a6

        moveq #0,d0
        ;btstm vc_OldOs,vc_Flags(a6)
        ;bne .exit

        move.l vc_IntBase(a6),a6
        cmp.w #47,lib_Version(a6)      ;sufficiently recent version?
        blo.s .oldintuition
        sub.l a0,a0
        lea SysIClass,a1
        deftag
         move.w cn_IconicWidth(a5),d1
         tag SYSIA_DrawInfo,cn_DrawInfo(a5)
         addq.w #1,d1                   ;+1, muß sein, das Gadget wird dafür verschoben
         tag IA_Width,d1
         move.w cn_IconicHeight(a5),d1
         tag IA_Height,d1
         moveq #ICONIFYIMAGE,d0
         tag SYSIA_Which,d0               ;Which Gadget
        endtag NewObjectA(a6),a2
        move.l d0,cn_IconifyImage(a5)
        bne .gotdimension

.oldintuition:
        ldbs
        move.l vc_IntBase(a6),a6
        sub.l a0,a0
        lea TBIClass,a1
        deftag
         move.w cn_IconicWidth(a5),d1
         tag SYSIA_DrawInfo,cn_DrawInfo(a5)
         addq.w #1,d1                   	;+1, muß sein, das Gadget wird dafür verschoben
         tag IA_Width,d1
         move.w cn_IconicHeight(a5),d1
         tag IA_Height,d1
         moveq #104,d0
         tag SYSIA_Which,d0               	;Which Gadget
        endtag NewObjectA(a6),a2
        move.l d0,cn_IconifyImage(a5)
        bne.s .gotdimension

        ldbs
        move.l vc_IconifyClass(a6),d0
        beq.s .exit
        move.l d0,a0
        sub.l a1,a1
        move.l vc_IntBase(a6),a6
        deftag
         move.w cn_IconicWidth(a5),d1
         tag SYSIA_DrawInfo,cn_DrawInfo(a5)
         addq.w #1,d1                   	;+1, muß sein, das Gadget wird dafür verschoben
         tag IA_Width,d1
         move.w cn_IconicHeight(a5),d1
         tag IA_Height,d1
         moveq #104,d0
         tag SYSIA_Which,d0               	;Which Gadget
        endtag NewObjectA(a6),a2
        move.l d0,cn_IconifyImage(a5)
        beq.s .exit
.gotdimension:
        move.l d0,a0
        movem.w ig_Width(a0),d0-d1
        subq.w #1,d0                            ;wird dafür verschoben
        movem.w d0-d1,cn_IconicWidth(a5)        ;Größe aufheben
.exit:
        tst.l d0
        loadregs
        rts

The 104 type for the image class is due to Massimo's agreement.

Thus, it is really not that complicated, actually. Just rendering is a bit lengthy, but that's unavoidable.

[meynaf]

Originally Posted by Thomas Richter

Thus, it is really not that complicated, actually. Just rendering is a bit lengthy, but that's unavoidable.

A bit lengthy, to say the least.
Perhaps you could factorize the code somehow.
Ok, it is not that complicated, but still a magnitude more than my current method. Now, what about a custom gadget showing an icon (whose drawing can be in fastmem), which renders backfilled (like normal buttons do) when selected - of course without having to ask the end user to provide two bitmaps ? And with the option to either behave like normal button or send repeated click events like arrow icons often do ?

[Thomas Richter]

Originally Posted by meynaf

A bit lengthy, to say the least.

That is mostly because the rendering function is quite long as it needs to pick the pens such that the gadget is recognizable even in 2-color screens.

Originally Posted by meynaf

Now, what about a custom gadget showing an icon (whose drawing can be in fastmem), which renders backfilled (like normal buttons do) when selected - of course without having to ask the end user to provide two bitmaps ?

Look at the above code. You only need to derive from the image class, and there check the draw state, and according to the draw state select the bitmap you want to render.

Originally Posted by meynaf

And with the option to either behave like normal button or send repeated click events like arrow icons often do ?

I'm not sure how to send repeated events, I would solve that by intuiticks (or at least solved this in the past this way - the arrow buttons in VNC work like this).

[meynaf]

Originally Posted by Thomas Richter

That is mostly because the rendering function is quite long as it needs to pick the pens such that the gadget is recognizable even in 2-color screens.

I pick the pens at startup, store them in some array, and end of story. Shouldn't be long.

Originally Posted by Thomas Richter

Look at the above code. You only need to derive from the image class, and there check the draw state, and according to the draw state select the bitmap you want to render.

There is more than just a draw state. There are also variants of the bitmap button. Some don't have a border (simple icons). Some may not like the backfill (ugly) so this is also an option.
I also have a special "removed" state, to hide a control without really removing it. It should be able to restore its background.

Originally Posted by Thomas Richter

I'm not sure how to send repeated events, I would solve that by intuiticks (or at least solved this in the past this way - the arrow buttons in VNC work like this).

Now, doing that from inside a boopsi should be fun, huh ?