scrollbars and viewports, margins, padding, and layers of abstraction

Has a windowing system existed that has done its own scrollbars, rather than leaving it to the application (including GUI toolkits)?

Imagine if the application drew to virtual framebuffer (one of several possible names) of one size, and the user had their window sized to a smaller size, and the window manager (or windowing system) gave the user the way to move around the viewport thus existing, whether by scrollbars, some kind of dragging, scaling, or how ever it does it.  There's an obvious usability issue in porting existing applications, already doing their own scroll bars, to such an environment, because who wants two sets of scroll bars for the same thing.  So we have to also imagine that applications running in this environment are designed for this environment, not shoe-horned in, tho some shoe-horning would be inevitable should a transition occur, at a later stage.

Processes exist in an environment operated by the OS.  The whole promise of OS was: to each process, it looks like it has its own computer.  This is best illustrated with memory space: the process does not coordinate its memory space with other processes in general.  It has a space, starting at zero, and uses it, and the OS "virtualises" it (note we are not yet discussing virtualisation, which is a similar idea, and perhaps illustrates some shortcomings of OSs in being more comprehensive).  The point is, processes operate in an environment operated by the OS.

Processes launched from a shell also exist in the environment provided by the shell.  This is why (by default), job control (ctrl-c, '&', and friends) works the same way for all processes launched from the shell, as do standard input and output redirection, etc.

Windowing systems have never provided much in the way of containment or virtual environment (I haven't yet looked into the protocol aspects of compositing X window managers, so can't yet speak for this).  Taking X11 again, the app has a way to get a connection to the X server, and it goes from there.  Yes, there are windows and the things that go with them, and to some extent the window position and size and focus and raising are determined externally to the application, but overriding is too easy and too prevalent, and they're never really contained.

To illustrate what I mean by containment, imagine if you could drag-draw a rectangle, up pops a menu of applications, and the selected application is then run to display in that box, and only in that box, and it never knows nor cares about things outside that box, unless the user later deigns to let it out.  Try making that happen with an evince, say, and you're what, filtering X11 protocol elements based on policy of "app ain't allowed to do such and such things".  Not containment.

Another illustration is my previous example of "output redirection at different levels" [0], in which I pointed out that with ">" in a shell, the shell is doing it, whereas with "-geometry" in an X app, the app is sometimes maybe doing it, not the windowing system ("graphical shell").

[0] <https://wibblement.blogspot.com/2022/03/output-redirection-at-different-levels.html>

I should look at how plan 9 does windowing, I guess, because it's possible they do something like what I'm talking about.  I'd be interested to hear of any other examples too.

I think there is huge scope for simplification by getting layers of abstraction right, in everyday computing.

note: in the above there is of course scope for the application to still know its viewport size, and adjust its layout accordingly, etc

note: I didn't end up mentioning margins and padding, but the idea is why can't blank space around the application also be managed by the windowing system