Hyperion Entertainment Message Boards

ssolie wrote: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?

I will make up some info for these chapters tomorrow (today, that is ). trixie´s guide to screen programming on OS4 Coding is a really good source for hints about screen locking and the problems one could run into. Should have been included in these chapters already, IMHO.

The thing is, that there is much more stuff affected by this special problem. Non-RA/non-MUI windows have no chance to get any notification about a Workbench reset request. Therefore, a new IDCMP message would be needed, so that future programs based on simple windows could see such a request. I still wonder why this problem wasn´t addressed by C= developers already...

Or we should urge developers to use RA windows, if they plan to hold a repeating or permanent lock on the screen their window is opened on. Because then it is possible to react on the iconify message and suspend any operation on the screen´s bitmap (and related structures) which might require a lock, until the window is re-opened (and new screen related pointers are gathered). It´s more work for the developer, first, but it´s highly reusable code.

I don´t know how hard it would be to introduce a new Intuition message to indicate a Workbench reset, but possibly the second proposal (to use RA windows as much as possible and emphasize this within the updated RKM) would be more easier to do. Some example code regarding this problem wouldn´t hurt, too.

tonyw wrote: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.

I wonder, why there is still the need for Picasso96Mode? The screenmodes defined in the monitor driver´s icon are essentially the same (with the same old problem regarding the pixel clock adjustment. It´s still slightly off ) and I think they work well enough now. At least I didn´t have any problems since their introduction.

I agree to xenic, that at least the programs of the system software should do proper iconify. If there is a program that doesn´t, it should be modernized or dumped. Is it really that hard to change Picasso96Mode to use ReAction instead?

@whose

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.

You talk as developer, not as user. Currently, when user can't change os settings in realtime, because of "close all windowses" he just in guessing called "what it all about", and that user, will never go on any wiki page to found something where explained what it and for what. Messages from os to user should be self-explained, and contain necessary info. Not some vague "close all windowses". Because not all windowses should be closed. And for user, window its window, app is app. Window can be WB window, and he will try to close them (as i do for few years before understand that its not about WB windowses , but about APP which make stuff wrong).

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.

But its misliading. You should not close all the windowses ! You should close that one, which come from program which do things bad. "Windowses" sounds for users (and for newbes too) as windowses, and he will try to close WB windowses, or whatever, which is wrong. As he should close APP which do lock screen. And because of that warning misleading. User can like a madmann close all windowses which he see, but there can be some app which didn't show window as window, but still lock the screen. I.e. its all about APP which do things bad, and warning should point out on that. Not on vague "all windowses". There can be one, or two, or more bad , but not all of them, and message should mean that, so any new user will get what it mean without any needs to learn aos internals and be developer or whatever. I even didn't point about "except drivers", which make system warning be misleading twice, because user for sure will think that its about WB windowses only.

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

Like we live in ideal world.. No one will contact anyone, because users mostly give a shit about, they have their time, and for them enough that they buy os4 and use it, and they not want and will not contact anyone (maybe only in some lucky for us cases). They will just know (as i know for years before i udnerstand the roots), that "you can't in realtime change system settings, because it bring warnings about some strange windowses which i need to close, while before i close all WB windowses and it didn't help, so os4 just cant change settings in realtime, pity". And that will be final understanding of pure user who first time (or second if we will be lucky) run os4.

And you say "they will know what app is it, right when they close faulty application", but that mean exactly that ! They _found_ faulty app. But warning says "close all windowses" : its wrong. Not _ALL_ windowses should be closed. Its app should be closed which lock screen. Not all wnidowses of all other apps. Warning should point like "try to close all the apps to found faulty one" or something. Not like it now, which can be undersanable by us, who already break our minds by years of amigaos, so we think that bad messages its good message for users

Is it really that hard to change Picasso96Mode to use ReAction instead?

I think no, but is there free devs who will do so ? Taking aside that devs want to depricate p96 (but that will take years as usual), there is just no devs who aren't busy with anything else. But i think if whose will write p96settings replacement in reaction, then os4devs will happy include replacement for meanwhile till p96 not removed totally

@kas1e

I fully understand your point with this. I just think that it´s overkill to rework the system just to get some info for the user, which window to close, when he gets this info today at the point he closes the right windwow. And I don´t think that absolutely no user will report, if something is wrong with e.g. DOpus or MUI_OWB

For older software (development ceased), this is problematic, I know. But it´s more a question of time until such software vanishes, and it´s users very often know about its problems and caveats. I think, the wording of the requester could be more precise in the form "Close all windows except Drawers until Workbench reset actualy happens". Oh, and the system programs should definetly follow the rules regarding screen locking.

I think I could do a ReAction GUI for Picasso96Mode, as long as the Drag&Drop mode adding is not a must have. This was always a thing I didn´t (and don´t ) like

@ssolie:

Here a proposal how to word the chapter "Accessing a Public Screen by Name". I just modified the part regarding the need to unlock the screen when done with examination...

---
Be sure to unlock the public screen when done with examination. Once a window is open on the screen the program does not need to hold the screen lock, as the (open) window act as a lock on this screen. Note that this is not necessarily the case for ReAction windows that might become iconified by external events (e.g. Workbench reset).

The pointer to the screen structure is valid as long as a lock on the screen is held by the application, or the application has a window open on the screen. If a window is in iconified state, this isn't true anymore. Remember to handle iconify correctly. See Window class (link) autodocs for more information about iconifying and screen structures.

Locks should not be held without reason. There are quite few reasons to hold a lock on a public screen permanently.

Holding unnecessary locks on screens may prevent the user from closing a public screen that has no apparent activity. It also prevents Workbench resets requested by the user (e.g. changing Workbench screen properties), if your program's window resides on the Workbench public screen. Keep in mind that as long as you have a window open on a public screen and your window doesn't make use of the ReAction window iconify feature, the window acts as a lock preventing the screen from closing. If you use the ReAction window iconify feature, keep in mind that you are obliged to free all screen locks you aquired if your window is told to iconify (and it does so).
---

I think that the "Screen Locking" chapter is good. Lots of warnings and "how to". That is the way I believe documentation should go

whose wrote:I fully understand your point with this. I just think that it´s overkill to rework the system just to get some info for the user, which window to close, when he gets this info today at the point he closes the right windwow.

You are assuming there are actually some windows open. Quite often WB tries to reset here when I'm not running anything, and I don't know if it is something iconified that still has a lock on the screen or some docky or something else that didn't release a lock when it quit. The only cause of action is to reboot.

And I don´t think that absolutely no user will report, if something is wrong with e.g. DOpus or MUI_OWB

You'd be surprised.

I think I could do a ReAction GUI for Picasso96Mode, as long as the Drag&Drop mode adding is not a must have. This was always a thing I didn´t (and don´t ) like

I agree with the comments above - there's no reason for P96Mode to even exist. Maybe shove it in the "Contributions" area just in case somebody needs to use it, but take it out of Prefs by default. It's a waste of developer's time to rework the GUI.

I also agree with the other point that there should be an IDCMP message for standard Intuition windows to catch, when the WB screen is trying to close. I suspect internally there already is something, it just needs to be made public.

chris wrote:You are assuming there are actually some windows open. Quite often WB tries to reset here when I'm not running anything, and I don't know if it is something iconified that still has a lock on the screen or some docky or something else that didn't release a lock when it quit. The only cause of action is to reboot.

I know... but in these cases there is a bug in the software which needs to be squashed. Iconified windows imply the release of any screen related locks. The screen´s properties could change within the time the program´s window is inconified. It´s all about correct handling of the Iconify state.

In the case of an orphaned lock, an overhaul of Intuition to show the application not releasing the lock wouldn´t have any advantage. There is no application anymore...

And I don´t think that absolutely no user will report, if something is wrong with e.g. DOpus or MUI_OWB

You'd be surprised.

I know that there are lots of user not reporting bugs/problems. But I definetly know that there are some doing reports And there are OS4 betatesters, who could do an error report to certain developers, too

I agree with the comments above - there's no reason for P96Mode to even exist. Maybe shove it in the "Contributions" area just in case somebody needs to use it, but take it out of Prefs by default. It's a waste of developer's time to rework the GUI.

Definetly.

I also agree with the other point that there should be an IDCMP message for standard Intuition windows to catch, when the WB screen is trying to close. I suspect internally there already is something, it just needs to be made public.

Yeah, there definetly is something, as RA Window class is making use of such a thing (otherwise there would be no iconify message when Workbench reset occurs). But in case it would need a bigger reconstruction, we should first update the developer documentation to outline these problems and how to deal with it. Spread the word, so to say

whose wrote:

chris wrote:You are assuming there are actually some windows open. Quite often WB tries to reset here when I'm not running anything, and I don't know if it is something iconified that still has a lock on the screen or some docky or something else that didn't release a lock when it quit. The only cause of action is to reboot.

I know... but in these cases there is a bug in the software which needs to be squashed.

I'm aware of that. But if you don't know which software is causing the problem it's impossible to report it (or fix it).

Iconified windows imply the release of any screen related locks. The screen´s properties could change within the time the program´s window is inconified. It´s all about correct handling of the Iconify state.

Not sure what you're getting at there, but just because a window has an iconify gadget and/or supports iconification or hiding, does not mean it has been implemented in a way that releases the screen lock.

In the case of an orphaned lock, an overhaul of Intuition to show the application not releasing the lock wouldn´t have any advantage. There is no application anymore...

No, but if Intuition has been updated to keep hold of a list of which tasks locked which screens, it can refer to this list whether the application is running or not.
Also, something along the lines of the "program exited with unfreed signals" warning wouldn't go amiss. Intuition could then free any outstanding locks.
If public screen locks were brought up to the same standard as AllocSysObject, they could be tracked and freed automatically.
So many possibilities...

tonyw wrote: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.

At this point, supporting iconify request isn't the issue yet. AmiPDF blocks screenmode changes when it's iconified. Just iconify AmiPDF and try to change screenmodes; it won't work. AmiPDF needs to be fixed to recieve notifications and release a screen lock when it iconifies.

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.

In that case, why would it be worth the effort to fix any 3rd party programs?

@whose

I don´t know how hard it would be to introduce a new Intuition message to indicate a Workbench reset, but possibly the second proposal (to use RA windows as much as possible and emphasize this within the updated RKM) would be more easier to do. Some example code regarding this problem wouldn´t hurt, too.

I thought there was already an intuition message to indicate Workbench (or any screen) reset. Isn't that the purpose of the Intuition StartScreenNotifyTagList() function??