Hyperion Entertainment Message Boards

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 ?

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

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

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.

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 ?

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.

MPlayer supports this game mode since a long time. And it is sometimes very annoying when it crashes with game mode on..

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

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.

It probably should be a commodity as it is a background program with no user interface.

Search for AppManager on OS4Depot and you will find exactly what you are describing.

Otherwise we will never be rid of commodities.

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.

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