Hyperion Entertainment Message Boards

There is situation : we have for example some app which do lock of screen and so it unpossible to change settings of os in realtime (such as gui ones, etc), and we have window with words "Intuition is attempting to reset the Workbench screen. Please close all windows, except drawers".

Now, my question is: is it possible to detect what app exactly do that lock, so, if it possible, i can make a feature request which will mean to change that window to something like "Intuition is attempting to reset the workbench screen, but appX1, appX2, appX3, are locking screen, so you should close them before". Of course, those apps should be fixed to not lock the screen (those are currently dopus4 and winamp for example), but still, have update of system component can be good as well.

If that not possible (i mean to detect which app do lock screen), then at least that window can be a bit rephrazed to more understandable and logical phrase, like "Intuition is attempting to reset the Workbench screen, but some application lock it. Close it and try again". Because as it now , i.e. that "close all windows except drawers", looks a bit non-understandable and not clear enough explain what happens.

@kas1e

those are currently dopus4 and winamp for example

I think any app that can iconify but does not free the screen lock will be an offender. If applications keep a screen lock for some reason, the lock should always be released when iconified. I'll make a specific mention of this problem in my Screen Programming article.

Have you reported it to Thomas "TomSoniq" yet, to fix WinAmp? I made comment on OS4depot but didn't contact him directly.

@Trixie
I am mostly in general, not about particular apps (those two as example). I mean for sure there present and will be in future some apps which lock the screen, just somehow to make information about it better in system-warning window + if show what app do it, then user can close exactly that app,not all the windowses as said in the system warning

I agree - it's difficult to tell which app has the screen locked, and the old wording is a bit out-of-date (as you *can* leave app windows open now under most circumstances, and WB will close/re-open them).

Put it in as a feature request

I looked into this a long time ago because I was annoyed that it didn't tell me what to close. You can't tell what has a lock because the only information you have is a lock count (at best). The change is not trivial and needs to happen inside intuition.library.

@Steven

Maybe in meantime just rephrase that system warning (as it now as Chris say indeed say it wrong). I.e it says you need to close all windowses, but in reality you need to close only apps which do lock screen, you no need to close all windowses and so its even wrong and misleading. Also that note about "drivers" not need it anymore in that requester too.

In other words, maybe something like "Intuition is attempting to reset the Workbench screen, but some application badly lock it. Try to found and close that application to let intuition reset the Workbench" ? Clean and understandable imho. And point on roots, and point that app is "badly lock it" and everyone get what happens and why reset can't be done.

@kas1e:

Well, the words of RKM still are valid. If somebody uses non-RA/non-MUI windows (which is still allowed and sometimes also makes sense), the screen is locked as long as the window is open or the program reacts on ICONIFY messages accordingly. There is no possibility for a normal user to distinguish between normal working RA-based programs, faulty RA-based programs (which e.g still hold a lock or don´t react on iconify the right way), programs using normal windows and processing ICONIFY the right way and more-or-less-faulty programs using normal windows.

For some special cases (like AmigaAMP or any program doing direct screen bitmap access), "permanent" locking of the screen bitmap indeed makes sense (drawing of the spectrometer, pens should be fixed all the time, SGrab locking the bitmap for read access). So the RKM should be updated to say that every program, which needs a screen bitmap lock more than once at startup or for a longer period of time, MUST react on ICONIFY etc. messages and release any locks on visible bitmaps, if such a message arrives. This involves more work, btw.

Regarding the closing of only those applications that are locking the screen, this is nitpicking. How does a user know, which Application holds this lock? The user doesn´t know, so the user must close all windows until the Workbench reset actually happens. IMHO, the wording is quite right, simple and accurate.

Close all windows (except drawers, which are guaranteed to not block the Workbench reset) until the Workbench reset happens. Short and simple. As it is, actually

Users who are feeling not good with this should contact the software´s developer to change the behaviour of the software. They will know which program it is, right in the particular moment they close the window of the faulty application

Edit: regarding userfriendlyness, we are missing some good Workbench User´s manual atm. This would be the place to actually give some explanation of this effect and could be used to make the user nag the developer of the "offending" software, so that there is no major overhaul of intuition.library needed just to tell which application holds a lock...

whose wrote:For some special cases (like AmigaAMP or any program doing direct screen bitmap access), "permanent" locking of the screen bitmap indeed makes sense (drawing of the spectrometer, pens should be fixed all the time, SGrab locking the bitmap for read access). So the RKM should be updated to say that every program, which needs a screen bitmap lock more than once at startup or for a longer period of time, MUST react on ICONIFY etc. messages and release any locks on visible bitmaps, if such a message arrives. This involves more work, btw.

Here are the RKM sections I think you are referring to
http://wiki.amigaos.net/index.php/Intui ... _Functions
http://wiki.amigaos.net/index.php/Intui ... rogramming

What do think we need to change?

Edit: regarding userfriendlyness, we are missing some good Workbench User´s manual atm...

I'm working on importing the manuals right now actually. They need updating to AmigaOS 4.x of course.
http://wiki.amigaos.net/index.php/AmigaOS_Manual

Any help with improving the documentation wiki is most welcome. Email me if you want an editing account.

trixie wrote: Have you reported it to Thomas "TomSoniq" yet, to fix WinAmp? I made comment on OS4depot but didn't contact him directly.

It would be nice if 3rd party programs worked correctly but at the very least all system programs should be closing their windows and/or releasing a lock on the screen. AmiPDF doesn't appear to release a lock on the screen when it's iconified. Picasso96Mode, ScreenBlanker prefs, Internet Connection Editor and other system programs don't close their windows when you attempt a screenmode change. How can you expect programmers to comply with the system documentation when system programs don't??

I think the problem is that older programs don't support Iconification. AmiPDF does have an iconification gadget, so it should iconify when asked, but perhaps it does not support external Iconify requests from Intuition.
Real old things like Picasso96Mode are so old that Iconification wasn't invented. To fix them up would require a rewrite of the whole program and it just isn't worth the effort.