Free GUI: Containerized Apps (Plus Segues)

 All Posts Tagged: Free GUI  

A desktop and application menu should be able to recognize and handle designations of containerized GUI applications to maintain a UX that makes sense with their usage context and priority.

This is perhaps a complicated issue, but the answer is generally to try to be able to accommodate many possible types of containers by creating a format for the GUI to be able to handle different user-created labels or classes or preferential tiers of containerized applications.

Fast-Track Containers

In terms of the fast-track philosophy, the idea would be to choose one container technology for this, and to fast-track that technology to work really well with the rest of the system, while leaving the door open for communication between other container technologies and the GUI.

Segue to API

Building out the Free-GUI API to handle something like switching container technologies would mean that whatever container technology was used could be adapted to the API. The API would include commands that are critical to how the system uses containers and certainly some extra general container stuff. One container technology would come with the system with the API commands linked up to the pertinent system commands. Then if users wanted to, they could perhaps enhance or replace those commands behind the API in sets that could be shared or stored in separate profiles.

This raises questions about what the API is: 

1. a series of critical commands that can be reassigned
• (I call it a floating abstraction)
2. a compiled, hard-coded API
3. some combination

Floating Abstraction

This method could be used more broadly as a logical, common sense API for many areas like:

• disk management
• backups
• log checks
• regex-type parsing of commands and files for custom data extractions
• system process management

This simple type of abstraction could leverage systemd commands or any kind underlying technologies as the system happens to be built. The API floats on top of whatever is on the system to create a common set of consistently formatted commands. Depending on how this would get implemented, the distribution, or a desktop, and/or users would customize the commands behind the floating API to their liking.

There are of course various means of handling security and permissions to do this including the likes of AppArmor and SELinux.

Or

Or, this whole idea of a floating API abstraction is worse than another way of doing things that subsumes that functionality. In any case, user acquisition of a logical, common sense UX has an unprecedented focus.

Segue to Custom Applications

The whole drive of Free GUI is that a user can build custom interfaces that run either regular bash commands or compiled scripts (that can work in a secure way.)

The area of managing containers is just one example out of all the things one can work with. Applications that could manage disk space, manage backups, and many more areas including mixed areas - could be created in the way that you, the user find beneficial conceptually. 

Segue to Easy Custom Widgets

A widget creation application can greatly assist to easily punch out custom GUI widgets that pertain to the way you think about your use-case, and to group together the commands you use, for the tasks you use to accomplish the level of usage that matters to your workflow and level of investment. This application would be an example of a highly refined tool akin to, but less complex than, an office presentation application, Blender, or a game creation studio. 

Again, this is about much more than just this example of container management. If the technology that you're creating a GUI UX around deals with other kinds of tasks that revolve around it in your workflow, then you can incorporate those tasks that deal with other commands. So then a given UX can do what you personally do around those larger workflows.