Free GUI: Core System Capabilities

 All Posts Tagged: Free GUI  

Core system capabilities is referring to anything that smooths out system workflow and workflow between applications and development, such as:

• copy / paste and other typical functions
• data type / format recognition between applications
• system keystroke recognition
• other input recognition
• core graphical functions
• common application assets
• common graphical tooling
• common data formats and tooling

Most of these things sound pretty regular. But this post is more about discussing the system capabilities that make the difference between this Free GUI concept of system capabilities, and what has existed to this point. The differential between these is about the concept of what capabilities can (and should) be moved from the application level, to being taken on as generic capabilities of the larger containing desktop environment.

The Browser Example

I think some of the inspiration for this was the idea of transforming a browser application into a system where there was no browser that was individually capable of tabs - just a system that could handle multiple single browser windows that would be organized into desktop tabs.

Users of the tiling window manager: i3 / Sway for instance are somewhat familiar with grouping tabs in a group at a desktop level. It seems intuitive to simply push that function away from the browser, and completely onto the desktop system.

Examples:

• open link in new tab >>> open in new adjacent tile in the same tile group
• open link in new window >>> open in new window . . . open in a non-adjacent tile or window?
• any of the many functions that a browser fulfills in how it works across tabs
• potentially more functions that the system gains, that are not features of any of today's browsers

But it is actually more complicated than it seems for a browser if you really want full browser functionalities. The complexity and difficultly of the design decisions that revolve around this idea is how these capabilities effect the rest of the system's functionality, restrictions, and security.

Many of these kinds of features could potentially be beneficial system-wide across many kinds of applications - not just purely to accommodate browser features. Still, some of these kinds of features might not be appropriate for other kinds of applications.

This adds the need for intense contemplation about how the system will function from the ground up. It requires a lot of thought about overall design before the project begins development.

Extensive System-Wide Tools

While linking across tabs or browsers for instance seems like it is just a browser feature, what if capabilities like this could function across these custom applications?

What other capabilities and resources could the system share between these applications?

Note: These would not function across the traditional applications, including Flatpaks and Snaps, or even traditional repo-based applications.

Anyway there is a whole host of capabilities that could function across this local ecosystem of custom applications. Many application assets and tools might be held on the underlying system:

• media resources like icons, images, animations, audio
• graphing tools
• system time data
• system geography data
• 2D and 3D tools
• all widget and window and toolbar assets

This is a pretty big deal for ease and commonality of development. Assets of one application can be used by all local applications. Although, nobody should take my word for it if this is in fact a simpler matter.

(These concepts warrant their own blog post.)

System Resources and Security

How thoroughly does a concept like this effect how the system handles things? . . . Uh . . . Pretty thoroughly for these applications. Traditional applications run the same way they always did.

In a sense, the system that runs these custom applications is similar, but different to one large application. Individual components that have their own launchers are locally created, resourced from local pools of assets, run, secured, and allocated / de-allocated system memory and processing. They appear to run like separate, traditional applications in typical usage.

(Starting to Click and Jive)

Many parts of the overall concept of Free GUI begin to make sense together en lieu of considering this staple of local system resources and tools working for all these applications.

The concept of fast-tracking is coming full circle. We can start to see why a common set of tools actually becomes central to the idea. It is because resources and assets are held differently. Configurations and languages and required components of these systems need to be held commonly between systems.

The resources and assets that get shared are allowed to be created and shared in smaller portions. Assets that build on the system, build the whole system. 

In terms of development, there are less decisions about which tools to use. The tools that exist enable most, if not all of whatever you'd want, and you do not need to go searching in as many places for different ones.

But the idea of the system is not to restrict. Not only can developers still build traditional applications, but they can also include portions of their applications that use other tools. How this is done is . . . in the details. But it is possible.