Hyperion Entertainment Message Boards

I wish there was a new window gadget, beside minimize, bring to back etc., that could lock the window to be all the time at the top of every other window. It must be two state gadget, that could be used to lock and unlock the window, looking like a pin. It would be really useful if you want to have a video player at the top right corner and underneath a website to read something.

My personal feature request is:

Windows (especially Shells) open at a free area of the workbench, not overlapping (if possible) with other windows instead of opening at a fixed position.
(Forcing windows to open at the same position could be done by a "snapshot" as usual)

Thanks,
nexus

@walkero

walkero wrote:I wish there was a new window gadget, beside minimize, bring to back etc., that could lock the window to be all the time at the top of every other window.

That is already possible but the programmer must enable this feature from within the code (by passing WA_StayTop, TRUE in the window definition). For instance, my WordNet dictionary interface lets you use this setting: it can be very practical when you translate someting in a multi-window-editor environment, and want the dictionary to stay at hand and always visible/accessible.

But this feature should be used sparingly and with consideration. What you are proposing is an idea that will defeat its purpose and end up in a user-interface failure. Think about it: if you could click your hypothetical gadget and thus make any number of windows on the Workbench screen stay on top, which of them would actually stay on top? The system would have to prioritize and choose one of them: that means, the others would not stay on top even with the gadget selected! This would be confusing rather than helpful.

I guess you'd have to program the support so that only one window could be set to "ON" at a time. When you select one window's "StayOnTop" button, the code would have to turn off the switch on every other window.

trixie wrote:@walkero

walkero wrote:I wish there was a new window gadget, beside minimize, bring to back etc., that could lock the window to be all the time at the top of every other window.

That is already possible but the programmer must enable this feature from within the code (by passing WA_StayTop, TRUE in the window definition). For instance, my WordNet dictionary interface lets you use this setting: it can be very practical when you translate someting in a multi-window-editor environment, and want the dictionary to stay at hand and always visible/accessible.

But this feature should be used sparingly and with consideration. What you are proposing is an idea that will defeat its purpose and end up in a user-interface failure. Think about it: if you could click your hypothetical gadget and thus make any number of windows on the Workbench screen stay on top, which of them would actually stay on top? The system would have to prioritize and choose one of them: that means, the others would not stay on top even with the gadget selected! This would be confusing rather than helpful.

You could have it similar to a dual playfield. Where for every window that has "stay on top" selected, they always remain in front of the windows that do not have "stay on top" selected. And you can use the front/back gadgets for these "stay on top" windows relative to each other. The default order can be as per standard windows (to maintain UI consistency) but within this front "playfield".

This would be more powerful, but I also agree it would be more confusing. Instead of "stay on top" you might want to use another term. And you could perhaps make the window borders a subtly different shade to make it obvious which "playfield" the window is in.

Calgor is right. That's the behaviour as it should be and as it is on other operating systems (where that feature is called "Always on top").

@Calgor, nexus

Of course there are ways to do it, I won't disagree on that!

But I was rather talking about something else. Walkero - if I understand him correctly - wanted every window to have a toggle gadget in the bar showing (and letting the user select) whether the stay-on-top feature is on or off. How would that work when Intuition is forced to "take sides" and choose the one-and-only top window? Would all the selected toggles become automatically unselected, thus disregarding the user's choice and preference? Bad solution. Would the selected toggles remain as they are but the windows put behind the top one? Bad solution because you'd be providing a visual clue (a selected toggle) for something that actually works differently.

@ trixie

The solution I suggested would have a toggle switch as per the OP's suggestion (or equivalent function, else how would you select the window to "stay on top"/be in the front "playfield"?).

The selection of the toggle would indicate whether it is in the front "playfield" or not. The visual clue (toggle switch and window border colour) is for which "playfield" the window is in, and the front and back gadget will let you move it on top of all the windows if you like.

So I do not see any problem there in terms of the toggle showing any wrong behaviour, but moreso whether the concept of two "playfields" would be too complex for the user interface. I know that for me such a feature would be superb, but others may find it confusing.

This kind of feature would be more useful on larger resolutions like Full HD which is common nowadays, where you can display more windows at once.

@ nexus

I was not aware other operating systems can exhibit similar control - which ones?

EDIT: trixie, I see your point regarding the "lock" on top (assuming you refer to a particular window *always* being on top). This solution would not provide exactly that but in my opinion would be more flexible and useful, and still provide almost the same functionality as "lock" on top.

Calgor wrote:@ trixie

The solution I suggested would have a toggle switch as per the OP's suggestion (or equivalent function, else how would you select the window to "stay on top"/be in the front "playfield"?).

The selection of the toggle would indicate whether it is in the front "playfield" or not. The visual clue (toggle switch and window border colour) is for which "playfield" the window is in, and the front and back gadget will let you move it on top of all the windows if you like.

So I do not see any problem there in terms of the toggle showing any wrong behaviour, but moreso whether the concept of two "playfields" would be too complex for the user interface. I know that for me such a feature would be superb, but others may find it confusing.

This kind of feature would be more useful on larger resolutions like Full HD which is common nowadays, where you can display more windows at once.

@ nexus

I was not aware other operating systems can exhibit similar control - which ones?

EDIT: trixie, I see your point regarding the "lock" on top (assuming you refer to a particular window *always* being on top). This solution would not provide exactly that but in my opinion would be more flexible and useful, and still provide almost the same functionality as "lock" on top.

@Calgor, trixie

Calgor is right again. Among the windows selected as "always on top", there has to be an order of course again. All those windows with such a switch selected are always on top of those with not such a switch selected. Usually, a user don't feel the need to select a lot of windows to stay always on top, but sometimes this is very useful and wanted (e.g. for transparent analog clocks, windows that update rss/atom feeds, music players, etc.).

I don't think this is confusing when done in the way Calgor described it (and also it is done by other operating systems).

@Calgor

Actually, this is a very old feature of very ancient Linux Windows managers. I used it already on Linux since "FVWM2" and recently, a year ago or so , I switched to XFCE4 where also the same feature exists (and on Gnome or KDE the same feature exists, of course, too). I usually don't use Windows but I'm sure something like that exists there, too.

On the other hand, there are more important things missing on AmigaOS/Workbench that are a little bit more annoying (like the feature request I stated above ).

Kind regards,
nexus

@all
The way that they should work is the way that Calgor described. 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. I wonder if this could be done with some arexx or not.