More on Free GUI

Window Positioning API

The desktop focuses on providing some default features, but all of these features are constructed using commands. The idea is generally that tiling and and windowed modes are accomplished through calculations on top of the window positioning API, and other API functions. But the API is used to intercept the process one way or another to do custom configurations.

Config profiles can make it so there are different positioning configurations to choose from.

Screen Purposes

A byproduct of the API and/or config settings must be to be able to use a screen or workspace in custom ways. This would include something like being designated for a single application. Large and small auxiliary screens can be designated for touch interfaces that might equate to something like a Stream Deck.

Text to GUI

This idea is one of the most important. It is about providing offline and commandline methods for customization and implementation that can also be used by the GUI - on the desktop and in the applications.

Broadly speaking, there is a matrix of skill-based modifications crossed with redundant methods of doing effecting the GUI's functions. Every GUI has a graphical means to unlock it, and the re-arrange GUI components to one degree or another, as well as accessing or even modifying scripts on the fly.

There are more intense ways of doing this, and there are less intense ways of doing this, and it is somewhat up in the air. Should the scripts require a pre-configured compilation environment to be faster? Should they be simple Bash scripts? Whatever the GUI standard is, there is still a way to do anything you would like outside the GUI.

In a real-world feasibility estimation, these decisions would have to be somewhat flexible, although it seems valuable to flesh out the most intense versions to illustrate the fullest extent of possibility.

Portable Configurations

The API commands and configuration files must be able to function by themselves, independent of any online intervention.

Next however, they also need to be able to be exported and imported through a compilation and/or profile system. 

These configuration profiles/compilations can be stored on a portable drive. They can be emailed. They can be shared on a website. And high quality configurations can be refined and shared on more official distribution stores.

Configuration Standard

and in online sharing, consumption and implementation of software customization, installation, and sharing. The standards exist in order to be commonly transferable between desktops, platforms, users, stores, and methods of construction.

Design Philosophies

Enabling Philosophy

The Screen Purposes example and the position examples above are quite specific, but they represent a larger general type of feature that should be available at the level of user-modified configuration files as opposed to what is typically relegated to compiled programs.

This particular philosophy requires some involved thought about what should be included in this set of features, and how the API would be granulated in order to achieve some amount of open-endedness with relative simplicity. There might be some capabilities that do not make the cut.

The idea is to create something that has simple rules that can be combined to create higher-order features.

Organization Philosophy

What makes this idea different is that it is a system designed to create refined environments that enable  a wide range of customization methodology, from fully offline customization - to highly decentralized  contributions from many people - at varying tiers of skill level. You can never share any of your configurations, or people can create stores of configurations that can be easily uploaded and downloaded.

Whereas the goal is to create this system with a philosophy of the most open-ended means of contribution, the philosophy of designing and creating the infrastructure for the system cannot be that decentralized and individual. It requires precisely coordinated design of syntax standards and advanced GUI tool development: Two separate philosophies.

A metaphor to such a system is a game engine, or even a higher-level game creation studio. Higher level infrastructure for the greatest amount of creativity, with the ability to go completely outside the sandbox and use custom languages, configs, GUIs, etc.

The Fast-Track Philosophy

This is very much about mitigating a chasm between capability and freedom. Perhaps one might reference the book: "The Cathedral and the Bazaar" do discuss this chasm. I don't know if that really fully embodies the issue per se, but I think it is related.

What are standards? What if they are not about enforcing something? What if the standards are there to fast-track certain methods of technical engagement, and those standards allow braking them. It means that there is a consolidation of requisite skills to contribute to the resulting system (once it is finally built).

Building on such open standards means that the system is designed to create efficiencies between the fast-tracked skillsets. This is one of the most important aspects of the idea, as well as what makes it unique and more difficult to develop. Multiple open standards function in tandem to create more efficient contribution by way of languages, preset compilation environments, easy plugins, custom widget creation, and configurations.

The whole idea is that it is a new level of refinement: Hence, it requires TEN-X the effort to design and develop the initial system. This is what it means to require a re-balanced development effort with greater reward.

These standards can go very far if you want them to, all the way to many levels of the operating system beyond just a desktop or an application ecosystem - to fully consistent file types and data formats that create compatibility between the commandline, editing text, and the GUI.

The general idea is to create standards that are beneficial to learning the system. They are focused on enabling the user by having things make sense. The philosophy is that it is more than ok to have things be logical and consistent on the commandline and elsewhere. Generally it is about opt-out for this philosophy.

This is a hard thing to get right - or rather it requires some really heavily coordinated design, and it is very easy to make it self-defeating.

There is no magic bullet here. With such an intense type of idea, the idea will almost definitely be incredibly alienating on early encounters. 

Development is a patience game. It is however also highly conditional on earnings, skilled contributions, cooperation, and drama.