Something missing from AmigaOS's Screens concept

OK, this is a really basic thing, but something which long time AmigaOS users might not notice:

AmigaOS has this great concept of virtual screens... But there's often no way to move windows BETWEEN screens. In particular, most programs open on Workbench's screen, and there is no way to move them onto another screen. The programmer must have implemented this particular feature, and very few programmers do.

e.g. It would be incredibly useful to be able to have OS4's Calc program on another screen where the data you are entering is. Same for NotePad. Same for a lot of utilities.

There are a lot of ways this could be added, but my suggestion is that if it was done by a system window gadget, then maybe OS4 could keep the window's internal pointer unchanged, such that it would work without a program needing to specifically support it. But if that wouldn't work (I guess there would be a lot of problems), then it should just be made some kind of standard feature of ReAction.


I think this feature could be extended to be even MORE useful: How many people heavily use AmigaOS's fantastic virtual screens? Probably few, because the ability to specify a screen is often hidden away (or even absent from small programs/utilities).

So in addition to moving windows on to existing screens, why not allowing moving them on to screens that aren't even open yet? That way we have a unified way of managing screens, and it's not hidden away. And it would bring us up to parity with Linux, where using virtual desktops is easy.

Quote:
Upon further thought, I realised that the necessary code probably mostly already exists: Intuition tries to close & reopen program windows when you change some GUI settings or the screen mode of Workbench.

All we need to do is get it to reopen the window on a *different* screen, rather than the same one. And call that function from some kind of window gadget or whatever. Sounds like it might be really easy to do (as these things go).

@ChrisH

Quote:
Yes it's easy because there's usually 2 or 4 pre-defined desktops by default. It doesn't add new desktops automaticly like you're suggesting. But making it better than any existing solutions is always a good idea.

MUI programs can do it already. And I think I made a feature request to make this work on all Intuition windows some time ago. (But adding such feature into every program is not a big deal either.)

@ChrisH

Hmm, I think thats what custom screens with "SHANGHAI" were meant for. The problem is, that some programs ignore the custom screen concept totally and explicitely open on Workbench screen instead. The other way round, most programs offering the option to open on a custom screen ignore the SHANGHAI flag/feature, too.

But from another POV, it would be much cooler to just drag those windows onto the other screen. But I think this is impossible right now, because this would imply an on-the-fly change of screen pointers which might collide with the often applied practise of buffered screen pointers and screen locking for the lifetime of the window/GUI.

Maybe its possible to install a mechanism for window-to-another-screen dragging in parallel to the old API, making it possible for future/updated applications to actually use this feature.

@whose

Oh, just an idea... for ReAction/MUI programs it should at least possible to drag them into another screen. Ok, its not suitable for opaque dragging, but for a simple dragging it should work. Its the mechanism that was already mentioned. The thing when e.g. Screenmode prefs were changed. In case a ReAction window is dragged into another screen, it could receive the message to close and reopen the GUI window. This way the screen pointer problem is circumvented (correct message handling is mandatory for such programs anyway).

Ok, it wouldnt work for non-ReAction/buggy programs and might lead to trouble, as Intuition would not be able to determine if the program changed its screen correctly, but it would be a start for future/updated/fixed programs at least.

Edit: typo

@ChrisH

I think the close/reopen feature when changing Prefs is implemented by Iconify/UnIconify operations. You know it won't work if a Shell is open? It's because it has no Iconify button. When I added it to the new console, the Iconify/UnIconify for Prefs changes just happened. Magic.

The main problem with changing screens is that the Window is so closely bound to the Screen (its RastPort, Fonts, etc). You can always change the RastPort to that of the new Screen, but what about the fonts?

I might do some experiments with the console.

@all

The moving screens are one of the great things of AOS that i missed very
much with the emulations.

I am using Gui4Cli intensively just (also) because switching my gui's (which comprise alot of sophisticated programs really), from one screen to another is just done with Ctl-J key combination. You can impose the screen the gui appears on with a simple
SCREEN OryginWebBrowser
command

(I am presently working on an OWB and Netsurf gui which should behave similarly for both browsers.)
Since the Gui4Cli source is available it could maybe inspire other programmers allready about this screeen switching features.

@tonyw Quote:
Ah, OK, this makes sense. Interesting kludge from OS3.x days.

I think my suggestion about the auto close/reopen could still work. What Intuition (or some patch) would have to do is intercept the re-opening of windows, and force it to use a different screen.

Quote:
Not sure I see the problem with fonts - I don't see why they would be tied to any screen/rastport (although I am only going from memory).

The worst I can imagine is that a window from the public screen might use the screen's default font, and if you then move it to another screen with a different default font, then that public screen could THEORETICALLY close itself (and it's font) while the window still used that font, leading to a crash. But this doesn't seem a very likely set of circumstances, and perhaps one can work-around it (either somehow keeping the font locked by opening it again, or otherwise changing the windows font to an identical one that is kept loaded for the duration of the window).

@ChrisH

Please for the love of Dawkins will someone implement this.

@DaveP

oh yes, and the "FRONTMOST" Tooltype in "NotePad" and "Calculator"! Please!