Hi,
I'm using DvPlayer or MPlayer in order to watch movies. I'm also using Wet and AmiFlipClock. These two send notifications on a regular basis to Ringhio to inform about the weather.
Is there a way to configure Ringhio to avoid the display of these notifications when a video is read in full screen ?
Ringhio and Video Player
Ringhio and Video Player
--
AmigaONE X1000 / Radeon 2400 Pro (R610LE) / AmigaOS 4.1 Final Edition
Samm440ep/733Mhs (o/c) / Radeon M9 / AmigaOS 4.1 Final Edition
AmigaONE X1000 / Radeon 2400 Pro (R610LE) / AmigaOS 4.1 Final Edition
Samm440ep/733Mhs (o/c) / Radeon M9 / AmigaOS 4.1 Final Edition
Re: Ringhio and Video Player
Unless the Rhinio prefs has an option "Always on top" which you can turn off (not sure if there is one, i think the "Always on top" is default), i dont think so
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Re: Ringhio and Video Player
No, there isn't, there is only : do not cover AmiDock.
I think Ringhio should be enhanced to avoid covering videos in fullscreen (as it is done for the screenblanker not to start when a video is played).
I think Ringhio should be enhanced to avoid covering videos in fullscreen (as it is done for the screenblanker not to start when a video is played).
--
AmigaONE X1000 / Radeon 2400 Pro (R610LE) / AmigaOS 4.1 Final Edition
Samm440ep/733Mhs (o/c) / Radeon M9 / AmigaOS 4.1 Final Edition
AmigaONE X1000 / Radeon 2400 Pro (R610LE) / AmigaOS 4.1 Final Edition
Samm440ep/733Mhs (o/c) / Radeon M9 / AmigaOS 4.1 Final Edition
Re: Ringhio and Video Player
Yes, Ringhio needs to use application.library and listen for the multimedia signal or wherever it was.
It should be a configuration though, since some of use only use programs that use ringhio for important messages that you don't want to miss, but that you want to show up while playing a video.
Ringhio is also not a commodity. It should not need to be a commodity if we had an Exchange for application.library. I think Hyperion should devote half an hour rewriting Commodities Exchange into an application.library aware tool (stand-alone or merged with the current Exchange) that we can use. Otherwise we will never be rid of commodities.
It should be a configuration though, since some of use only use programs that use ringhio for important messages that you don't want to miss, but that you want to show up while playing a video.
Ringhio is also not a commodity. It should not need to be a commodity if we had an Exchange for application.library. I think Hyperion should devote half an hour rewriting Commodities Exchange into an application.library aware tool (stand-alone or merged with the current Exchange) that we can use. Otherwise we will never be rid of commodities.
Re: Ringhio and Video Player
The video players you are complaining about need to be updated to use OS4's application.library's ill-named Game Mode, which is intended for the exact purpose you are asking for.K-L wrote:Is there a way to configure Ringhio to avoid the display of these notifications when a video is read in full screen ?
Re: Ringhio and Video Player
MPlayer supports this game mode since a long time. And it is sometimes very annoying when it crashes with game mode on..
Re: Ringhio and Video Player
@Raziel
There's is a "show on topmost screen" option (APPMSG_PubScreenName, "FRONT") , but it only appears to be available via the API, not through global prefs. The default is Workbench, but the sensible option is to change it to FRONT which is what I do. Workbench is better for when you have other screens open running video players that you'd rather not have disturbed. There ought to be an override in Prefs, and that should have been present before apps started using the API.
Search for AppManager on OS4Depot and you will find exactly what you are describing.
And, as you say, the commodities and application Exchange interfaces could be combined as there is a lot of commonality and the user doesn't really need to know whether something is a commodity or an application. I can see a problem for programs that register themselves with both, but the instances of that are probably quite low anyway (commodities that want to show application dockies or notifications are the only valid excuses).
There's is a "show on topmost screen" option (APPMSG_PubScreenName, "FRONT") , but it only appears to be available via the API, not through global prefs. The default is Workbench, but the sensible option is to change it to FRONT which is what I do. Workbench is better for when you have other screens open running video players that you'd rather not have disturbed. There ought to be an override in Prefs, and that should have been present before apps started using the API.
It probably should be a commodity as it is a background program with no user interface.Deniil wrote:Ringhio is also not a commodity. It should not need to be a commodity if we had an Exchange for application.library. I think Hyperion should devote half an hour rewriting Commodities Exchange into an application.library aware tool (stand-alone or merged with the current Exchange) that we can use.
Search for AppManager on OS4Depot and you will find exactly what you are describing.
Applications and Commodities are two entirely different things. Commodities can mess with the input event stream and are generally OS extensions with particular rules for tooltypes, activation etc. Applications are full-blown programs with a user interface that the user consciously interacts with. Ringhio server is a commodity (although probably needs to register itself as an application to pick up application.library notifications). A lot of things that register themselves as commodities are actually applications - most MUI stuff for instance - but as that is all apps could register with in the past it's unsurprising. Probably MUI for OS4 needs modifying to register things with application.library instead.Otherwise we will never be rid of commodities.
And, as you say, the commodities and application Exchange interfaces could be combined as there is a lot of commonality and the user doesn't really need to know whether something is a commodity or an application. I can see a problem for programs that register themselves with both, but the instances of that are probably quite low anyway (commodities that want to show application dockies or notifications are the only valid excuses).