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
Feature request: Lock window to be at top
Re: Feature request: Lock window to be at top
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.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.
The Rear Window blog
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
Re: Feature request: Lock window to be at top
@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
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
Re: Feature request: Lock window to be at top
@ 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.
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.
The Rear Window blog
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
Re: Feature request: Lock window to be at top
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))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
I even think it's available on the stone-age window manager TWM. When you have installed AmiCygwin, you could check it on AmigaOS4
sure, that's fine.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
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
Re: Feature request: Lock window to be at top
@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 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.
Re: Feature request: Lock window to be at top
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.
The Rear Window blog
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
Re: Feature request: Lock window to be at top
I agree, great idea. Best of all worlds, pleases everyone.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.
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.
Amiga 4000T: CSPPC 604e@233/060@50 146MB RAM/CVPPC/Mediator/Radeon 256MB/Realtek 8029AS/TerraTec Solo1-N/Picasso IV (Paloma Pablo Concierto)/Deneb/ZorRAM 256MB/Indivision AGA MKII/OS4.xBETA/OS4.1u4/OS3.9BB2
AmigaONE X1000: Nemo 2.1 PA6T-1682M@1.8 2GB RAM/Radeon HD 4770 512MB/Catweasel MK4+/Audigy 2 ZS/Realtek 8139D/OS4.xBETA/OS4.1u5
AmigaONE X1000: Nemo 2.1 PA6T-1682M@1.8 2GB RAM/Radeon HD 4770 512MB/Catweasel MK4+/Audigy 2 ZS/Realtek 8139D/OS4.xBETA/OS4.1u5
Re: Feature request: Lock window to be at top
Someone (possibly Rigo) reported that this had been fixed, as I recall. Thankfully, because it means Ringio notifications stop windows from being depth arranged.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.