Start_on_Pubscreen allows any program, file or drawer's window to be started on a chosen public screen.

To open all files of a given type (e.g. a PDF) on one specific public screen, the file may be opened through its icon or via drag-and-drop onto Amistart.

Different programs, files and drawer windows may be mixed on one public screen by either opening via the cli or by drag-and-drop onto View_Pubscreen (see below).

The public screen is automatically closed when all windows on it have been closed.

Start_on_Pubscreen_Control is a commodity opened by hotkey which sets a global switch for Start_on_Pubscreen; in this way the use of public screens can be switched on and off as needed.

View_Pubscreen allows any public screen to be viewed in a window on Wanderer, and any file, program or drawer drag-and-dropped onto the window will be opened on that public screen.

All of the above are Hollywood applications and are started from Hollywoodplayer.

Any feedback on these programs would be much appreciated before I commit them to AROS archives.

Cheers,
Nigel.

P.S. for anyone that used FixAmistart (the program to close Amistart when a screen other than Wanderer is open), there were some conflicts with this so a new verion is attached.

New versions of Start_on_Pubsceen and Fix_Amistart attached.

For Start_on_Pubscreen, it's just View_Pubscreen that's been tweaked. I noticed that when using a CPU intensive program such as JanusUAE, there as a noticeable stutter every time the screen image & cycle gadget were updated, so I've added a variable time for the update from 5 s to 300 s including 'Never'. There is also a manual update button.

For Fix_Amistart I found occasionaly it was still not working as expected. After some experimentation I found the Hollywood function getfrontscreen() was not working as per the documentation; instead of reporting the frontmost screen it was reporting the screen with the current acive window (I think the same issue is with LilCalendar when, after going back to the calandar display from the event input window it can open on the wrong screen).

I've found a work-around, but it now requires Activatewin is in c:; full informationion the included documentation.

Any comments much appreciated before I commit to the AROS archived.

Cheers,
Nigel.

Yet another tweak for Start_on_Pubscreen.

The program launches a background task to monitor the pubscreen and close it when there are no longer any windows or programs open on it. There was a delay to allow the background task to start before Start_on_Pubscreen closed, but I found this week that if the system is under heavy load this timing can go wrong and the backgrounfd program does not launch. Thid version eliminates that problem.

If anyone is using this, just drop it in as a replacement for the old version, everything else is the same.

Cheers,
Nigel.

@ntromans

The background work of Fix_Amistart is not good, as it remains active all the time, you can no longer use “Sashimi” which displays data continuously without ever stopping!

The program is not constantly active (i.e. a busy loop), it's on a timer which triggers every 1 s to see which screen is open and open/close Amistart accordingly. In-between activation periods it 'sleeps'.

The big problem is there's a bug in Hollywood (reported) - the function that is supposed to return the frontmost screen actually returns the screen with the active window (I do wonder if that's why LilCalendar always jumps to the wrong screen when it re-opens its display after editing its entry). Anyway, this is why I'm now having to use Activatewin to try to work out which screen is at the front; it's probably this that's generating the data display in Sashimi. Until the new version of Hollywood is released with the function fixed the only other solution is to simply not use it I'm afraid.

Cheers,
Nigel.