@Chris Imho (i not know roots, just imho), application library way also based only on screenblankerengine ones, as only them are system/os4/real ones. How application way can know if there some 3d party hacky blanker, which not register itself, and have no references to screenblankerengine, but just reacts like screen blanker ?
Imho both ways just the same. Just with application library is more hi-level and you have it all as bonus together with other features of application library, while with commoditie way its a bit oldschool and do pure disable/enable without needs to use application.library, and that all difference. And probably, at some level application way may do the same call to commoditie, just programmer don't do it itself, as application library use do it for him when he do all those "applicationsetattrss blanker true/false"
How application way can know if there some 3d party hacky blanker, which not register itself, and have no references to screenblankerengine, but just reacts like screen blanker?
The library can't know that, of course. AFAIK Application Library only interacts with the system-provided screenbanker engine. No one stops anybody from writing/using a blanker based on something else but 1) why bother, and 2) you simply run the risk that your custom blanker will disturb applications that don't want to be disturbed. You choose. The message here is: "Install and use whatever you want in your system, but you bear the responsibility. Don't come complaining that someting doesn't work if you chose to follow non-standard ways."
Quote:
Imho both ways just the same. Just with application library is more hi-level and you have it all as bonus together with other features of application library, while with commoditie way its a bit oldschool and do pure disable/enable without needs to use application.library, and that all difference.
There is one slight difference, though. If an app disables the commodity broker and forgets to enable it, the blankers will stay disabled when the app quits. Whereas with a registered application even if you forget to set APPATTR_AllowsBlanker back to TRUE, the unregistration process will remove the no-blank request automatically. (Or at least it should; the library is such a mystery that we're all still learning what it actually does, and how.)
There is one slight difference, though. If an app disables the commodity broker and forgets to enable it, the blankers will stay disabled when the app quits. Whereas with a registered application even if you forget to set APPATTR_AllowsBlanker back to TRUE, the unregistration process will remove the no-blank request automatically. (Or at least it should; the library is such a mystery that we're all still learning what it actually does, and how.)
Yes, that was good surprise i found today when add it to mplayer: in some driver for first tests i forget to enable blankers back on exit, but they auto-enables once i exit. So while i fix it of course, i still got it like "woah, application library is good stuff, do clean things which done from my app , not keep it for whole system while i exit from". So yep, it do it like you says , and imho pretty logical and right to do it like this.
And I'm quite sure people will like Application Class too, for it not only provides a more streamlined access to Application Library functionality but also puts all application-level messaging under one roof, as well as bridges the gap between applications and commodities. As certain boring chores will be off-loaded to the class, application development will be easier and faster.
Imho (i not know roots, just imho), application library way also based only on screenblankerengine ones, as only them are system/os4/real ones. How application way can know if there some 3d party hacky blanker, which not register itself, and have no references to screenblankerengine, but just reacts like screen blanker ?
All screen blankers, provided they register themselves with application.library using the REGAPP_BlankerNotifications tag, will get the messages telling them to disable or re-enable themselves. It is not restricted to just ScreenBlankerEngine, that's just an example of a screen blanker which registers itself properly and reacts to the messages.
Of course if some hacky blanker doesn't bother to register itself, there's nothing you or anybody else can do to stop it interfering.
AFAIK Application Library only interacts with the system-provided screenbanker engine.
Any app can register itself as a screenblanker and get the enable/disable messages. This is (thankfully) not hard-coded to ScreenBlankerEngine, and making the assumption that ScreenBlankerEngine is what is being used is a bad idea.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
