Free GUI: Window Manager Capabilities

 All Posts Tagged: Free GUI  

This post here mentioned some things about a window position API. This post is about describing some more API specifics and window manager capabilities.

I make a low key distinction between "capabilities" and "features" here, because capabilities could emerge into various custom features, or they could be prevented from becoming available to a use-case or workflow. It would all depend on any given system's configuration and scripting.

Sidenote: A Creative Process

As I said in a previous post about Free GUI, the process of my posting is to spout out all kinds of ideas to draw from at a later time of more holistic design and technical consideration. 

While the overall idea can be very valuable, it could also end up technically in an unfortunately awkward place, like fitting a square peg into a round hole (being Wayland or X11 or other infrastructure). 

• What capabilities would have to get cut in order to attempt to maintain the ideas' value while also trying to fit into existing infrastructure or any other limitations? . . . 
• Answer: I do not know
• Would the overall idea be powerful enough to have technological negotiation power, in terms of persuading others to make necessary developments to undergirding infrastructure?
• Answer: Not so easily
• If the idea did have to get strategically cut down to size, would it still be valuable enough (to me and others) to justify its work requirements?
• Answer: Diminishingly so. Up in the air. Dynamically volatile. Highly subjective. 

Free GUI is NOT:

• This ideation about Free GUI is not a call to arms for any FLOSS development community per se. My posting represents a process of describing parts of an elephant (or perhaps a killer whale in this case), with the intent of coming around again to a clearer picture of value offerings.
• A killer whale is not about eating penguins (Linux). That's stupid, and there's Linux, BSD, Redox, and Windows: too many operating systems to eat, and Windows would be the first on the list anyway.
• The Free GUI concepts of logical, common sense usability could venture far into the OS territory as far as the eye could see. That extensive idea would be about dreaming up an OS that would be very work intensive, and it would fall into a different category of OS than Linux. Yet it would still fall into an area of technological feasibility. It would probably be specifically desktop user focused - have a fully FOSS licensing scheme - and not be Unix based.

Free GUI Windowing Capabilities

These capabilities have to be interface with [undecided] scripting techniques and API to be used to create desktop workflows of many different kinds without having to develop an entire desktop from scratch every time a slightly different preference is desired.

The idea would ideally be to create capabilities that could become granular functions that could build higher level features for intended workflows.

Window Positioning

Window positioning would deal with:

• An X,Y coordinate interface for windows / tiles
• A window / tile / widget ID / workspace ID / display ID system for positioning (duh)
• workspace resolution management (duh)
• attributing graphical layering modes per scripted conditions
• handler for custom scripts to do positioning of ID'd items:
• create all manner of classes for identification
• workspace, display, layer, custom class, order of usage, any useful distinction

The point of the positioning API is to create a means to do window management any conceivable scheme a desktop creator would want to without developing an entirely new desktop environment every instance.

Virtual Display Capable

The system can reference virtual displays in the API and configs in the same ways as physical displays.

This virtual display system can:

• treat a window / tile as an extra system display
• own resolution
• stretched resolution
• adds resolution to total GPU demand
• move and resize like any window / tile
• treat a workspace as an extra system display
• can have a distinct resolution
• affixed as a workspace - not a floating or moveable window / tile
• does not add workspace resolution to total GPU demand (or does it?)
• split a workspace into multiple extra system displays
• can have distinct resolutions
• does not leave extra hardware display real estate unless perhaps it is blacked out
• affixed to a single workspace - not a floating or moveable window / tile
• does not add workspace resolution to total GPU demand (or does it?)

Make it as locally resource efficient as possible in terms of overhead above the obvious resource consumption of adding the extra resolution real estate. Users decide how to limit their use of added resolution according to their GPU's power (Much like users deciding what games their system is capable of).

Some examples of uses:

• Use virtual displays for ultra wide displays (or any physical displays), where otherwise, special hardware-based split screen or picture-in-picture technologies would be required
• Develop a method to use the same virtual displays for virtual machines
• Develop a method to use the same virtual displays for container-based applications
• or even container-based desktop environments?
• Use the virtual display for playing old games that require unique resolutions
• Use the virtual display for other fullscreen applications
• Use virtual displays for open-ended reasons

In these ways, virtual displays could be a generic system capability to be interfaced with through a protocol, to act as another physical display in most regards.

Application Window Zoom-1, Zoom-2, Panning

Application windows should be able to contain a zoomed portion of any application within its borders, for any application. 

So this system should be able to perform actions on windows like:

• zoom in/out application within the application window, which is kind of like magnify (Zoom-1)
• designate a separate application size, than the window / tile size (Zoom-2)
• pan application within the application window

Panning could be useful for both kinds of zoom, along with panning position memory, according to scripted conditions.

Zoom-1 is closer to a magnify / de-magnify kind of zoom capability.

Zoom-2 is an enlarge / shrink capability for the application size, to change the way the application must squeeze itself into the strict borders of a window or tile. In many cases, the intent is to be able to toggle the application size to and from the larger size, where the whole application gets seen when toggled. 

• Pan can then be conditioned to remember the position to graphical or terminal alerts when small for instance.
• Application tiles can accommodate larger applications in a smaller position on the workspace - to be double clicked (for instance) to maximize or increase the size of the tile according to scripted conditions. This use-case is like an adapted realtime application thumbnail for tiling, which could double as an alert system, or to visually denote some stage of a terminal process, such as a presented y/n cli option. (whatever you want)