Screensaver over-ride

[djrikki]

Hello,

I've got time I'll give the long version of my feature request.

In April I am attending a local exhibition to showcase my business, ( http://www.printandpromo.co.uk ), an opportunity to network, hopefully get some sales - anyways I am taking my AmigaOne 500 with me - it will be running a Hollywood Designer presentation on loop all day long.

In order to do run the presentation properly I have to disable the Screensaver using Exchange. From my experience of AmigaOS it does not presently seem possible to programmatically tell the Screensaver - 'you are not allowed to initiate at this time'.
Also I have noticed that when playing games in the past through RunInUAE - the blasted thing (screensaver) appears because it also doesn't appear to monitor joystick input - ha usually when I have 1 Life left or something.

[jaokim]

Application.library has that functionality.
I've been thinking of writing a small utility/wrapper that can register a custom application in order for old legacy applications to register themselves (and get entries in last applications and documents) but haven't gotten around to it.

[djrikki]

Perhaps Andreas Falkenhahn (Hollywood Dev) is not aware of this in application.library - is it a new function?

[gazelle]

Nope, it was allready in SDK 51.22

Code: Select all

       REGAPP_AllowsBlanker - (BOOL) Defaults to TRUE.
           [...]
   
       REGAPP_NeedsGameMode - (BOOL) Defaults to FALSE.
           [...]

Of course the screenblanker engine has to support the "Blanker Notifications" form application.library.

[djrikki]

I'll mention it to Andreas, I am not using the latest version of Designer anyway perhaps he has introduced in since.

[trixie]

@jaokim

Application.library has that functionality.

Yes, Application Library provides a notification mechanism that allows controlling blanker activity. However, this mechanism works pretty much on a theoretical level, and requires cooperation. First, the blanker must REGAPP_BlankerNotifications, TRUE and handle all blanker-related messages sent from registered applications. Second, the application must set APPATTR_AllowsBlanker, FALSE whenever it doesn't want to be disturbed by the blanker (and TRUE when it gets back to normal mode). The blanker must respect it and not kick in. But if the blanker or the application fails to play by the rules, the notification mechanism simply doesn't work. It's just a framework, not a ready functionality.

I've been thinking of writing a small utility/wrapper that can register a custom application in order for old legacy applications to register themselves (and get entries in last applications and documents) but haven't gotten around to it.

I'll save your programming time and kindly tell you not to develop such a terrible hack. An application is not supposed to register as another application, this would be a misuse of the API.


@djrikki

I'll mention it to Andreas

Please make sure that he knows of the Application Library documentation in the wiki:
http://wiki.amigaos.net/index.php/Application_Library

[jaokim]

@jaokim

Application.library has that functionality.

Yes, Application Library provides a notification mechanism that allows controlling blanker activity. However, this mechanism works pretty much on a theoretical level, and requires cooperation. First, the blanker must REGAPP_BlankerNotifications, TRUE and handle all blanker-related messages sent from registered applications. Second, the application must set APPATTR_AllowsBlanker, FALSE whenever it doesn't want to be disturbed by the blanker

Well, I can only assume that the screen blanker engine packaged with AmigaOS 4 supports the functionality. If it doesn't I think a bug report is in place.

Otherwise I dont know how to to solve this, apart from making a far worse hack (like triggering mouse moves...? *shrug*), or possibly the best option, manually disable any blankers.

I'll save your programming time and kindly tell you not to develop such a terrible hack. An application is not supposed to register as another application, this would be a misuse of the API.

Sure, it isn't supposed to, but given an old legacy application I don't really see the harm. Of course, users might get confused if they'd use their own application identifiers, and made other assumptions, but I don't see the real harm.
As it is now, very few applications use all application library functions, and the various utilities on os4depot relying on the its functionality have limited use. For instance, some clever arexxing could make Wordworth support much of the functionality.

If you have any more exact reasons to why it might be a bad idea, I'm all ears. But just stating its a hack, nah, not good enough.

[trixie]

@jaokim

If you have any more exact reasons to why it might be a bad idea, I'm all ears.

OK, let me explain.

In the near future, a new application manager will be released that will control registered applications and commodities through a single interface. What you know from Exchange will now also be available for applications, in one program. In order for this to work and offer a plausible user experience, application developers have been encouraged to implement a minimum set of Application Library features to allow the manager (or any taskbar-like application) to perform basic operations (quit, iconify, and uniconify) and display some info about the running app.

The meaningfulness of such a tool will grow with the number of compliant applications. Once BOOPSI/ReAction gets an Application Class (stay tuned), all new programs developed using this class will automatically become registered applications, so the number will increase considerably.

Now back to the problem. If you register a legacy application from your program, the application will appear as registered in the system. Now, the user may use the manager and try to control the "fake-registered" legacy application, but the control commands will of course be sent to your program (the registerer). It would be your responsibility to ensure that the control command is somehow delivered to the particular legacy application and that the application acts adequately. I don't think you can ensure that. You'd perhaps be able to use ARexx to quit applications that implement an ARexx port, but you'll not always be able to ensure that the legacy application iconifies/uniconifies because such a feature was rare in the past and most legacy apps don't support it. In the end you'll only confuse the user because he'll see the legacy apps as registered but will not be able to control them like other apps. User confusion is, of course, a situation every sensible developer wants to avoid, whereas your "solution" would only create it.

The bottom line is: applications that do not support Application Library themselves had better be left as they are, and not mess with the application registration system.

[jaokim]

Yes, I see, and understand your points. However, I don't think they really stand in the way of what I'm thinking of. I believe the minimum requirements can be met:

Provide a short description for a better identification of the application.

No problem.

[The application should] Tell the OS whether the application supports iconification

No problem, it'll just tell the OS it doesn't support iconfication.

Allow the application to be shut down externally in a safe and graceful manner in reaction to the APPLIBMT_Quit message.

Well, okay, safe and gracefully can't really be promised. But it's no less safe and graceful than quitting the program using its ARexx port.

Now, perhaps it isn't wise to release an all-purpose application library wrapper that anyone can modify, but rather package customized wrappers for Wordworth and such to allow for a neater integration with OS 4. I mean, intergration is all what ARexx is for.

So, I get your arguments, I just don't think they are valid in order to disregard this idea. The only aim is to provide some minimum support for old legacy applications. I mean, the 68k emulator must be considered an even worse "hack".

Edit: Now, the probablity of me actually doing this is close to zero, so perhaps there's no risk of this being an issue.

[trixie]

@jaokim

I just thought valuable developer time could be spent elsewhere but hey, it's your time not mine

Perhaps I worry too much in this particular case but there's a reason. AmigaOS bears a certain legacy of programmers who got around, bent or even hacked into APIs and who felt "creative" while doing this. So many apps stopped working in OS4 not because the dev team were incompetent but because the new OS enforced stricter rules on using system APIs. This revealed a lot of malpractice that simply had gone unnoticed under OS3.x. The OS4 Documentation Wiki has been going to great lengths to encourage compliance and good practice: for a better and safer AmigaOS, of course.