Feature request: Lock window to be at top

[Rigo]

This is exactly how WA_StayTop works already. Any windows that have that tag set will always be "on top" of windows that do not have it set. You can still depth arrange the "on top" windows.

The biggest problem is that it is not a dynamic setting, you have to specify it when opening the window, and it cannot be changed while the window is still open.

Simon

[trixie]

@all
All the "Always on top" windows will be above the other windows, and the user must use the front/back button to order them. I don't know how difficult is to implement this, but it might be really usefull some times.

As Rigo said, that's what we have already. But I really think it should stay the programmer's choice to provide a stay-on-top window, not the user's.

[trixie]

@ nexus

If this were such a great and much-needed feature, surely operating systems would have implemented that in their windowing environments years ago? And I'm quite sure that OS and UI developments are pushed forward by greater brains than mine or yours

But seriously: adding another gadget to the window bar would not be an optimal solution anyway. Rather, I'd suggest using the MUI-style Window Pop-Up gadget that has recently been introduced in Window Class. Thus, all window-related features (remembering size and position, iconification, staying-on-top, etc.) could be put in the menu that pops up after clicking the gadget.

[Deniil]

@trixie

I agree with Calgor and nexus. The way Clagor describes the behaviour is the correct, and current, behaviour. I also think like nexus that it should be up to the used to decide when and if to use this.

WindowsXP has this feature and has had it for long. However, the gadget needs to be put there by the programmer. I'm looking at one such gadget as we speak in DOpus 10. The Windows Task Manager has had this feature as a setting forever AFAIK.

About extra gadgets: This should also be a user's choise, just like how MUI allows the user to decide what to put in the window border. In MUI the user even has the choise to put all gadgets in one pop menu to reduce the number of visible gadgets. AmigaOS itself is way far behind when it comes to window border gadgets. I think Hyperion is too shy when it comes to adding this kind of simple-to-implement user-experience-enhancing features. The MOS team has not been nearly as shy when it comes to Ambient.

There is a bug though (last time I tested): If you have two normal windows behind a StayTop window it is impossible to depth arrange these normal windows correctly because they can never become ontop of the StayTop window, and therefore can never be put to back (because the can never get tofront in the first place). This is a pure bug (a normal win should never *attempt* to get ontop of a StayTop window) and I hope it has been fixed.

[trixie]

I'm fine with any solution that

• is not inherent to all windows;
• doesn't defeat the purpose of a multi-window environment by making windows compete for priority;
• doesn't clutter the window bar with unnecessary gadgets. Like I say, the pop-up menu is a neat solution.

[Calgor]

About extra gadgets: This should also be a user's choise, just like how MUI allows the user to decide what to put in the window border. In MUI the user even has the choise to put all gadgets in one pop menu to reduce the number of visible gadgets. AmigaOS itself is way far behind when it comes to window border gadgets. I think Hyperion is too shy when it comes to adding this kind of simple-to-implement user-experience-enhancing features. The MOS team has not been nearly as shy when it comes to Ambient.

I agree, great idea. Best of all worlds, pleases everyone.

Would be good to have some themes of the common combinations. The default can be the theme that is determined should provide the most useable interface to the majority of users. As much functionality as possible, but without overwhelming or confusing the average user.

[ChrisH]

There is a bug though (last time I tested): If you have two normal windows behind a StayTop window it is impossible to depth arrange these normal windows correctly because they can never become ontop of the StayTop window, and therefore can never be put to back (because the can never get tofront in the first place). This is a pure bug (a normal win should never *attempt* to get ontop of a StayTop window) and I hope it has been fixed.

Someone (possibly Rigo) reported that this had been fixed, as I recall. Thankfully, because it means Ringio notifications stop windows from being depth arranged.