Ringhio messages blocked by Pull-Down menus (Solved)

A forum for general AmigaOS 4.x support questions that are not platform-specific
Post Reply
Raziel

Ringhio messages blocked by Pull-Down menus (Solved)

Post by Raziel »

OK, once again changed the title.
This is only happening with Ringhio pop-ups

After setting both menus in GUIPrefs to Non-Blocking only the Ringhio pop-ups get blocked

Notification pop-ups will be "locked" while one uses the Workbench pull-down menus.
That is, if one keeps the pull-down menu open (right click) the Ringhio pop-up will stay on screen (as long as one keeps the menu open, and in every state one "catches" the pop-up, i.e. nearly visible)

What i don't quite understand is, why is Notification bound to the pull-down menus?
And a (little problem) too, as every pop-up gets blocked before it can actually pop up if the Pull-down menu is open

Reproduce:
In Sys:Documentation/Ringhio/
1) Click on rx_testringhio.rexx (to make a pop-up appear)
When the pop-up is visible
2) Use either of the following pull down menus
o Workbench main pull-down (top bar)
o ANY programs pull-down (either free on screen -right mouse button on an active programs window or from Workbench's top bar)
(Tested with MUIOWB, YAM, AmigaAmp)

Now comes the inconsistency:

Start Sys:Utilities/Commodities/ContextMenus (V53.1)
Repeat the above to reproduce, but this time right click anywhere on the workbench to bring the ContextMenu up.
It will *not* lock the Ringhio pop-up, it will vanish fine after displaying.

Is this a bug?
Or could it at least be changed to act on all Pull-Down Menus (all menus?) accordingly?

I'd prefer the pop-ups not to be locked by menus, btw :-)

Thanks a lot

AmigaOS4.1 - Update 6 (all updates)
Notifications 53.26 (30.3.2012)

Thank you very much
Last edited by Raziel on Wed Nov 06, 2013 7:21 pm, edited 1 time in total.
Raziel

Re: Ringhio messages blocked by Pull-Down menus

Post by Raziel »

So i've been told by a dev that this behaviour is intended.
User avatar
trixie
Posts: 411
Joined: Thu Jun 30, 2011 3:54 pm
Location: Czech Republic

Re: Ringhio messages blocked by Pull-Down menus (Solved)

Post by trixie »

So, what was the explanation? Why does it behave differently for Intuition and context menus? I would really like to know.
The Rear Window blog

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
Raziel

Re: Ringhio messages blocked by Pull-Down menus (Solved)

Post by Raziel »

Well it wasn't much what i've been told and i'm not that into the inner workings of AmigaOS4, but the answer was sufficient for me not to bother any longer :-)

The answer effectively was, that the reason for the "freeze/block" (whatever it is really) is the fading effect of Ringhio's pop-up windows.
It has nothing to do with Notifications.
The fading effect will block any window (featuring it) when one has the pull-down menu button held.

And this is intended

EDIT: Please, correct me if i have something gotten wrong
User avatar
thomasrapp
Posts: 318
Joined: Sun Jun 19, 2011 12:22 am

Re: Ringhio messages blocked by Pull-Down menus (Solved)

Post by thomasrapp »

Intution menus have always blocked all gfx output on the screen. This means you can stop every animation or such by opening the menu.

ContextMenus behaves differently because it is an external program, just a normal application. There is no way for an application to block gfx output like Intuition does it internally.

What yet has to be answered is why Intuition needs to block gfx output for menus or if this can be made an option in GUI prefs.

(Actually I am used to the blocking behaviour and would probably miss it.)
chris
Posts: 564
Joined: Sat Jun 18, 2011 12:05 pm
Contact:

Re: Ringhio messages blocked by Pull-Down menus (Solved)

Post by chris »

thomasrapp wrote:What yet has to be answered is why Intuition needs to block gfx output for menus or if this can be made an option in GUI prefs.
It already is an option - "non-blocking menus"

Why this doesn't work for fading windows is a mystery, I guess the non-blocking aspect isn't truly non-blocking, and Intuition still blocks some things when menus are active.

I believe the reason it used to block, was so programs that directly drew to the screen wouldn't overwrite the menus. Now with MENUVERIFY and big warnings not to write directly to the screen BitMap, it isn't usually a problem, as the RastPort will do the clipping and the program can stop output manually if it needs to.
Post Reply