Hyperion Entertainment Message Boards

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

walkero wrote:@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

I strongly disagree!

The programmer can't know the needs of each and every user.
Actually, he has *not* to domineer the user but should offer various
possibilities to the user such that he himself can adapt and use a
program according to his will/needs/preferences/habits!

If the user *wants* that a certain window stays on top of all others,
why not giving him the chance to do so?

If a user wants that the workbench window containing all the prefs stays on top
(maybe because he frequently has to access that window) then why not?

Also with shells. I prefer sometimes that shells stay on top, so I can easily
access them and if i don't need it to stay on top anymore, i only have to click
on a symbol or even briefly iconify it because of switching to an intermediate
or different work task.

I don't think that *you* know when *I* need to do it or when it could simply *my*
work flow.

Therefore, an additional symbol in the window bar (or a menu entry), maybe even
configurable like the iconfiy symbol on MUI windows does not harm the user
but the user can only benefit from it

regards,
nexus

@ 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.

trixie wrote:@ 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

Yes, exactly! And that's the reason why this feature *exists* since decades on Linux and all window managers (which are known to me (at least 4))

I even think it's available on the stone-age window manager TWM. When you have installed AmiCygwin, you could check it on AmigaOS4

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

sure, that's fine.

But again: although, I'm advocating that this a good-to-have feature, I think, there're more important features missing (like automatic windows placement). So, I'm not trying to fight to get this in

kind regards,
nexus

@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.

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.

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

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