Major desktop environments develop "core applications" that use the right GUI tools to make them ultra-compatible with the environment. This typically consists of a couple system utilities, a settings manager, a file manager, and a terminal emulator.
Free GUI's equivalent alternative to developing core applications is a set of assistive tools for creating its special form of custom applications.
The form that these tools come to exist in is a large contributing factor in why the application ecosystem generally is so up in the air.
But I am going to describe these ideas in this post (and maybe some more posts) and attempt to describe their respective reasoning.
Most of these ideas that I have floating around would each require heavy development, and it is unclear to me as of yet, how they would be refactored or consolidated in a final cohesive design.
I am going to brake these ideas up into a few temporary categories, perhaps just for the sake of this post:
- Core assistive applications
- full applications
- Application chassis blanks
- graphical engines / cores
- interface to be used in full applications
- multi-purpose, reusable
- morph according to configuration
- Graphical window and toolbar framework
- lock / unlock, import / export
- configure toolbars
- configure widgets
- configure chassis
- Core system functions
- help smooth usability between workflows
- attempt to be somewhat open-ended
Plus, the UX Languages
In combination with the ideas in this post, there is also an accruing number of potential approaches for user-facing UX languages that might span from:
- a designated markup-type language
- text elements
- GUI positioning
- simple action calls
- API comprehension
- to a designated configuration language
- speaks the markup language
- simple action calls
- API comprehension
- to a designated json-type data format
- predefined dictionaries
- custom dictionaries
- to a designated simple scripting language
- to a designated API
- to a dedicated, full development language
- with special compilation sandbox
- to ultimately, the ability to opt out of the sandbox to develop with "any" liberties
- to all of the above
Note: The version of each of these languages might specifically correspond to respective DE versions
Core Assistive Applications
Core assistive applications are highly developed applications that are primarily about helping people create things in what has been thought to this point to not be worth it to make things easier. It is about reducing the path of resistance for creating custom applications.
Graphical Widget Creator
This is an application that
- lets you arrange shapes and images
- perform motions and deformations on the graphics
- create trigger action interfaces for the graphics
- connect graphics to existing widgets, or custom widgets.
Specialty Editors
These would be for any UX language syntax that Free GUI implements. Part of the idea of picking a fast-tracked set of languages, is to not leave any of them behind for having specially enhanced editors and features that give specific attention to particular nuances of these languages.
- IDE with specific accommodations for execution environment
- Graphical translation editors for any markup or styling languages
- Graphical cell-based system for any required data formats, with attention towards handling key, value pair systems.
Central Configuration Manager
One of the key aspects of this environment and application ecosystem is that the configurations of all applications on the system can be managed on each application individually, or centrally through a configuration manager.
This configuration manager will be able to select any grouping of applications, and create imports and exports as profiles or delete them.
This application might be combined with another application that would manage other settings, like permissions, on a per application basis, or on the basis of a group of applications.
Set and Tier Manager
This is a strange idea, but one that I think could be highly beneficial. This is about creating a signature style of configuration for as many kinds of things as possible. It is a somewhat tentative idea.
This would be a graphical application with predefined structure of tiers and sets, organized vertically and horizontally in rows and cells and indentations, as well as macro choice selectors. It might be the same application as the application that can graphically assist management of data-file formats, as in something like json or xml.
The point is that if anything can be made to be organized in such a way then it should be - to make it manageable by this graphical application.
In the case of icons for instance, a selection utility allows for the choice of a set of icons. A second priority of icons can be selected as a fallback. Users see each icon. Icons can be swapped to create a new icon set. Sets can be extended to include more icons that are used for other purposes.
This graphical application could be used for creating prioritization tiers for any purpose, whether it be for:
- security profiles
- with individual settings in a row
- application profiles
- with individual settings in a row
- icon or image sets
- audio resource sets
- package lists with settings
- theme setting sets
This is an idea that I have at times visualized in my head, but how it would be manifested in final form would require a lot more attention.
If this application were to be created, then it would effectively become a hub for any situation where detailed settings are important. It would effect the way these various resources and settings would be formed in order to be compliant to being used by this application.
In other words, it would be a pretty big deal. But also, it would only be worth creating if becoming familiar with it meant that the knowledge would be able to transfer to many different areas on the system. (An important design principle for Free GUI)
Application Chassis Blanks
These are relatively complex sets of graphical components that intended to be hooked up and reused in multiple applications.
I imagine them as being very feature rich, but they have the ability to be trimmed down in size.
One example of a chassis might consist of a way of combining these things for something that can be used in both a file manager, a software store, or a music application. These applications have multiple columns of data rows, where rows can be zoomed, or expanded, interacted with, or show thumbnails inline or in a side pane. They have a set of complex features in common.
In this example, having a system that can be used across applications might save a significant amount of time. If this particular row, column system can handle most features you throw at it, it can also be implemented in a way that opts out of any number of these features to be used in more narrow capacities.
I will have to think up some more examples, and if I don't, then maybe this particular idea is not as great as I thought. But there is something to it.
The General Window / Toolbar Framework
An attempt at including as many toolbar type features as possible, and working them into a set of features that works with any positioning language, as well as any configuration profile system that might be used along with Free GUI.
Toolbar Systems
- Menu Options
- Regular Toolbar buttons
- Toolbar Tabs
- Ribbon Interface
- Popout / Dockable Windows (Think Gimp)
Graphical Layers
- cell-based graphical layer
- graph-based graphical layer
- grid-based graphical layer
- table-based graphical layer
- list-based graphical layer
Configuration Access
Every application's configuration can be dealt with individually, or on a the basis of groupings of applications in a central configuration manager.
Every individual application has window-level controls, perhaps in the form of a dropdown menu, that give options to unlock or lock the application for the sake of editing the toolbars, as well as options to export and import settings changes, or to fork a new profile.
Core System Capabilities
Core system functions are anything that smooth out system workflow and workflow between applications, such as:
- copy / paste
- 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
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
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.
(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 like 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 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 of whatever you'd want, and you do not need to go searching in 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.
No comments:
Post a Comment