gadget down locking window

[meynaf]

Hi,

When a new window opens, it does not get activated immediately if the user is currently playing with gadgets.
For example, if you press a button (or move a knob) but do not release it, the other window will open but remain inactive. Once you release the mouse button, the other window suddenly becomes active.
So far so good, but it doesn't work when playing with window areas that are not gadgets.
Is there a way to 'lock' the window without having to create a gadget on it ?

[Thomas Richter]

This is a result of the rather particular intuition event system. Changing the input focus while a gadget is active is prevented from intuition - another one is if the menu is active, this will also prevent the input focus from changing.

I'm not sure whether this helps, but you could try intuition requesters. By that I do not mean the autorequesters, but the old "struct request".

[meynaf]

Originally Posted by Thomas Richter

This is a result of the rather particular intuition event system. Changing the input focus while a gadget is active is prevented from intuition - another one is if the menu is active, this will also prevent the input focus from changing.

This is precisely what i want to replicate - but without any actual gadget.

Originally Posted by Thomas Richter

I'm not sure whether this helps, but you could try intuition requesters. By that I do not mean the autorequesters, but the old "struct request".

I don't see the link.
I just want to have intuition 'think' a gadget is currently active.

[Thomas Richter]

Originally Posted by meynaf

I don't see the link.
I just want to have intuition 'think' a gadget is currently active.

The link could be that the input focus might be bound to the requester. Why don't you try?

[meynaf]

Originally Posted by Thomas Richter

The link could be that the input focus might be bound to the requester.

Binding the input focus isn't enough. My window has the input focus and it doesn't block others when mouse button is pressed.

Originally Posted by Thomas Richter

Why don't you try?

Because i have no idea what to try.
What's an 'old' requester anyway.

[Thomas Richter]

Originally Posted by meynaf

What's an 'old' requester anyway.

    NAME
        Request -- Activate a requester.

    SYNOPSIS
        Success = Request( Requester, Window )
        D0                 A0         A1

        BOOL Request( struct Requester *, struct Window * );

    FUNCTION
        Links in and displays a requester into the specified window.

        This routine ignores the window's IDCMP_REQVERIFY flag.

[meynaf]

And so ? What am I supposed to do with that ? I don't want to display anything.

[Bruce Abbott]

Originally Posted by meynaf

Binding the input focus isn't enough. My window has the input focus and it doesn't block others when mouse button is pressed....

Is there a way to 'lock' the window without having to create a gadget on it ?

I don't think so.

Do you have a reason for not wanting to create a gadget on the window?

[meynaf]

Originally Posted by Bruce Abbott

Do you have a reason for not wanting to create a gadget on the window?

I perform all the rendering myself.

[mark_k]

You can create a gadget without Intuition doing any rendering?

From intuition.h:

/* --- Gadget.Flags values	--- */
...
#define GFLG_GADGHNONE	  0x0003  /* don't highlight */

[meynaf]

Creating a giant, invisible gadget covering the whole window's surface is an idea.
I guess i will try that.
I just hoped there was a quick, easy way to tell intuition to not remove focus from my window.

[meynaf]

Originally Posted by meynaf

Creating a giant, invisible gadget covering the whole window's surface is an idea.
I guess i will try that.

Just tried.
It is successful in keeping the focus on the window when left mouse button is pressed.
... but it prevents mousebutton events from being sent.

[Thomas Richter]

I still fail to understand the use case. Why is this required?

[meynaf]

Originally Posted by Thomas Richter

I still fail to understand the use case. Why is this required?

It is explained in post #1. What's unclear ?
I draw things on the window that are not gadgets, but do everything as if they were. Oh, i could perhaps have tried to do custom gadgets, but it ended up simpler this way.
Owner-drawn gadgets with custom behaviour, for my UI library.
Think about things such as real combo box without having to use third-party software, for example.

[Thomas Richter]

Originally Posted by meynaf

I draw things on the window that are not gadgets, but do everything as if they were.

Then, why not just make them gadgets?

Originally Posted by meynaf

Oh, i could perhaps have tried to do custom gadgets, but it ended up simpler this way.

Actually, you make it a lot more complicated because you're not playing the rules of the system. If you want something like a gadget, make it a gadget. If you want custom rendering, make it a boopsi.

Originally Posted by meynaf

Owner-drawn gadgets with custom behaviour, for my UI library.

Owner-drawn gadgets are called boopsis. That's pretty much what they are good for. You are using the wrong tool for what you want to achieve.

[Bruce Abbott]

Originally Posted by Thomas Richter

Owner-drawn gadgets are called boopsis.

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

I have been working with 1.x gadgets for compatibility and for the challenge (imagining I'm back in 1990...), but they have some annoying limitations and take a lot of fiddling to get the features I want. So I have been thinking of building my own from scratch.

That's pretty much what they are good for. You are using the wrong tool for what you want to achieve.

The Amiga is a retro platform. "What you want to achieve" could well be just enjoy programming challenges. I get more satisfaction out making something myself, even if it means 'reinventing the wheel'.

So I looked up BOOPSI, and as expected my eyes were glazing over within seconds.

"In general, BOOPSI objects are "black boxes". This means the inner workings of BOOPSI objects are not visible to the application programmer, so the programmer does not know what goes on inside it."

Oh yay. Next we will see 'the code is the documentation'.

[Thomas Richter]

Originally Posted by Bruce Abbott

So I looked up BOOPSI, and as expected my eyes were glazing over within seconds.

"In general, BOOPSI objects are "black boxes". This means the inner workings of BOOPSI objects are not visible to the application programmer, so the programmer does not know what goes on inside it."

Oh yay. Next we will see 'the code is the documentation'.

That is not what is meant here. What is meant here is that boopsis are abstract objects and act "as if" they were intuiImages, boxes or gadgets, regardless of what goes on within them. Of course there is documentation how to work a boopsi - in case you write it yourself of course *your* documentation, in case of a system boopsi, the official documentation of that boopsi, e.g. its autodocs.



This principle is called "information hiding" and is quite valuble when writing complex programs. They reason why it is valuable is that such components are interchangable, regardless of what the actual implementation does, provided the interface is satisfied. You can plug in a boopsi of an Image class into whereever an IntuiImage would fit, *regardless* of what is within the "black box", and you can plug in a gadget class boopsi whenever a gadget fits, *regardless* of what is going on within the boopsi.



This is also exactly the reason why boospis are recommended - you do not need to "code around" assumptions on the intution system that are not documented. Silently, it is here assumed that intuition blocks windows activation functions on gadgets, but there is no documentation on this, and this assumption may be even wrong with various patches, improvements or versions of intuition. If you depend on undocumented behavoir, it is quite likely that you creating a fragile program, a program that breaks in certain configurations. So, just: don't.

[meynaf]

Originally Posted by Thomas Richter

Then, why not just make them gadgets?

I tried and they didn't behave properly.
Ordinary gadgets can use borders or images but never both. I also ended up with large structures consisting of many images.
Gadtools does not provide bitmap buttons at all (among other things), its radio buttons can't be freely placed - and it does not mix well with non-gadtools stuff (if at all).

Originally Posted by Thomas Richter

Actually, you make it a lot more complicated because you're not playing the rules of the system. If you want something like a gadget, make it a gadget. If you want custom rendering, make it a boopsi.

I tried boopsi as well. Couldn't even make a working button out of it. I could eventually draw something but not catch events.
Complicated ? Yes, but it was boopsi that was complicated, not my own way.

Originally Posted by Thomas Richter

Owner-drawn gadgets are called boopsis. That's pretty much what they are good for. You are using the wrong tool for what you want to achieve.

Last time i've looked they weren't even close to good.
I might be using the wrong tool, but the one you're suggesting is even worse.

Will for example boopsi allow gadgets that overlap and do proper refresh of them in the right order ?
They are not layered and can draw anywhere on the window, including the border.

If you think boopsis are good and easy to use, then please provide me with some skeleton code of a custom gadget. I need to have a suitable place to draw the gadget, and another where it receives input events.

[Thomas Richter]

Originally Posted by meynaf

Ordinary gadgets can use borders or images but never both.

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.

Originally Posted by meynaf

I also ended up with large structures consisting of many images.
Gadtools does not provide bitmap buttons at all (among other things), its radio buttons can't be freely placed - and it does not mix well with non-gadtools stuff (if at all).

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.

Originally Posted by meynaf

I tried boopsi as well. Couldn't even make a working button out of it. I could eventually draw something but not catch events.

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.

Originally Posted by meynaf

Complicated ? Yes, but it was boopsi that was complicated, not my own way.

Look, it's time to learn something, but once you have understood how these things go, it is really not hard. "Your own way" is the wrong way as it depends on undcoumented system behaviour that may or may not change.

Originally Posted by meynaf

Will for example boopsi allow gadgets that overlap and do proper refresh of them in the right order ?

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


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.

Originally Posted by meynaf

They are not layered and can draw anywhere on the window, including the border.

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.

Originally Posted by meynaf

If you think boopsis are good and easy to use, then please provide me with some skeleton code of a custom gadget. I need to have a suitable place to draw the gadget, and another where it receives input events.

A "bit hard right now" as I'm 10000 feet over ground and on a business trip, but for the time being, I suggest to look at the skeleton in RKRM libraries. Otherwise, I can find something when back home. There should be also plenty on Aminet.


(Yes, they do have internet in planes nowadays...)

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

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.

The ViNCEd "iconification" gadget is under 3.1 a boopsi as this version still lacked a system iconification sysiclass image. It uses sysiclass from 3.2 onwards to allow customization of the "look and feel", which I consider "a good thing" (leave the style to the user, do not enforce your own style upon the user). That's one of the advantages if you use system provided classes.

But, again, not accessible right now, sorry.