Introduction to the desktop environment and its applications

The UntitledDesktopEnvironment(shortened to UntitledDesktop or UDE) is an experimental homebrew desktop environment base for Linux and other operating systems that use components made by the freedesktop foundation.

The main goal of UDE is to explore the development of Linux desktop technologies that are independent of large desktop development toolkits, such as QT or GTK.

The Linux desktop has been relying on QT and GTK for general desktop tasks to a point, where there is a general lack of small libraries that do individual tasks related to integrating with the underlying OS or desktop environment. Using these toolkits is great for applications that need their stability, or for applications that use most of the features that these toolkits provide. However, why should authors of small applications that require only 1 or 2 desktop features to work need to pull such toolkits, just because nobody bothered to create a small and pluggable alternative to them?

Additionally, with the consolidation of the Linux desktop, there will also be a gradual decrease in the general developer knowledge of how such desktop integrations work or function, leading to general problems with the entire Linux desktop development supply chain.

The UntitledDesktopEnvironment project aims to fix this by creating a base for creating an independent desktop environment. The project strikes a balance between using our own custom implementations and working with established Linux desktop standards. Finally, to fix the issue of depending on large toolkits in small projects, most desktop integrations we develop for our first-party applications are split into self-contained libraries, which are always developed in a generic manner that makes them easy to implement in completely unrelated contexts.

In many ways, one can think of the UntitledDesktopEnvironment as a collection of generic reference implementations that developers can pick and choose from to their liking. This is largely why we use the "Untitled" prefix for almost every one of our applications and libraries 😁

The UntitledImGuiFramework

The UntiltedImGuiFramework is a cross-platform desktop application development toolkit that utilises dear imgui as its UI library.

The goal of the framework is to build on top of dear imgui's easy to use and versatile UI library by creating a pleasant development environment for developing desktop applications with complex requirements.

It abstracts away many of the boilerplate-ey bits of developing a dear imgui application from scratch, while bundling a number of useful widgets and libraries for integrating with the host operating system or desktop environment.

You can read more on the project's GitHub repository.

Try out the interactive demo:

UntitledApplicationSuite

The UntitledApplicationSuite is a collection of first-party applications that use the UntitledDesktopEnvironment's tooling:

1. UntitledGameSystemManager
2. UntitledIBusHandwriting

UntitledDesktopEnvironment's native desktop components

The following applications constitute the UntiltedDesktopEnvironment's base desktop tooling:

1. UntitledDESessionLogout

Development goals

We have the following goals:

1. User freedom
2. Cross-desktop compatibility
3. A fully community-centered approach to development
4. A great UX, no matter the level of the user's knowledge
5. A fully modifiable and hackable application suite out of the box
6. A great multilingual experience
7. A great distribution experience
8. A great theming experience

User freedom

We prioritise user freedom and system customisability. We think that our users should have the right to:

1. Replace most desktop components without issues *1
2. Be provided with transparent, and easy to read, maintained documentation of all configuration formats
3. Have the ability to develop plugins for first-party applications using whatever technology stack they find the most suitable *2
4. Modify features of any applications(when available) in order to tune enabled code and features at compile time for whatever purpose

*1 - This applies to most applications, though when talking about ones like the settings manager, this might not be completely possible.

*2 - This includes active developer involvement by the developers to implement flexible plugin interfaces that can be consumed by any programming language.

How do we achieve this?

1. The desktop is developed as a bunch of swapable modules, rather than a fully integrated solution
2. Applications are built as self-contained atoms that don't necessarily depend on any other UDE application(not necessarily when talking about libraries)
3. Documentation of features is our top priority when developing any feature. The moment it is pushed to a repository, it should be fully documented
4. For formats such as foreign themes, we build multidirectional adapters and conversion tools
5. All our libraries provide a C and C++ API. The C API can be used to create bindings to any programming language
6. We utilise compile flags to enable and disable any optional features. This applies to our toolkit when compiling an application statically, or to a number of our applications, where some additional features can be disabled through these flags

Cross-desktop compatibility

We achieve cross-desktop compatibility in the following ways:

1. By being a flexible framework that is not opinionated
2. By following all standardisation efforts by the freedesktop group
3. By building adapter utilities and libraries to convert between incompatible formats
4. By collaborating with other desktops to improve compatibility

A great multilingual experience

Make all applications have UI and docs in multiple languages, allow for easy translation of text and conform to i18n standards. More information about the subproject can be found here.

A great distribution experience

Through tools, such as pkggen, the UntitledDesktopEnvironment is being built to be distributed as widely as possible in a sustainable matter.

A great theming experience

We aim to achieve a great theming experience in the following ways:

1. We use a simple YAML format for themes
2. Themes are minimal and only cover colours and sizes of some elements(in contrast to Gnome CSS files)
3. Restricting theming only to the colours and scaling of an application
4. Multi-directional compatibility tools for converting themes between the theme formats of other desktops:
   • They allow us to use the large collection of already available GTK and QT themes
   • They allow us to generate GTK and QT themes on the fly, so that the user doesn't have to deal with matching and setting them separately
5. Themes have full inheritance: an application can use the root global theme or inherit from another application's
6. Themes are not forced on developers: Turning off theming support doesn't require an action from the developer when using our toolkit
7. The theme formats are well-documented and are made to be easy to use without breaking any applications along the way

To be added

We're still developing our scope so this section should be expanded in the future

Specifications

Misc

1. UntitledDesktopKeybindings Core Specification