Saturday, August 8, 2026

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 functions and/or 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.

Sidenote: A Creative Process

As I have said in a previous post about Free GUI, the idea of my posting is to spout out all kinds of feature 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 features would have to get cut to maintain its value, but also fit into existing infrastructure or any other limitations? . . . 
    • Answer: I do not know
  • Would an idea be powerful enough to have technological negotiation power, in terms of changing how a system is built?
    • Answer: Not so easily
  • If the idea had to get cut so much, would it still be valuable to justify its work requirements?
    • Answer: Up in the air and 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), and hopefully coming around again to a more complete picture.

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.

Free GUI, and ideas of usability that could venture far into the OS territory as far as the eye could see 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 meet the API in order to create desktop workflows of many different kinds without having to develop an entire desktop from scratch.

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

Window Positioning


Window positioning would deal with:
  • An X,Y coordinate interface for windows/tiles
  • A window / tile / widget ID system for positioning
  • workspace resolution
  • attributing graphical layering modes per custom scenario
  • handler for custom scripts to do positioning of ID'd items:
    • create all manner of classes for identification
    • workspace, monitor, 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 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
  • treat a workspace as an extra system display
    • does not add workspace resolution to total GPU demand
    • can have a distinct resolution
  • split a workspace into multiple extra system displays
    • does not add workspace resolution to total GPU demand
    • can have distinct resolutions
    • does not leave extra hardware display real estate unless perhaps it is blacked out
Make it as locally resource efficient as possible in terms of overhead above the obvious resource consumption of adding the extra resolution. Users decide how to limit their use of added resolution according to their GPU's power.

Some examples of uses:
  • Use virtual displays for ultra wide monitors, where otherwise a special hardware-based split screen technology is required
  • Develop a method to use the same virtual displays for virtual machines.
  • 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

Application Window Zoom


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
  • pan application within the application window
This could be a very simple kind of zoom. It might attempt some kind of anti-aliasing. Furthermore there could be multiple options to use different performance enhancements for the zoom.




No comments: