In this page we are going to detail some of the features and plans for our desktop envirionment,
we hope that this page can clear up any questions on what we desire to achieve with this project.
Introduction to the desktop environment and its applications
The UntitledDesktopEnvironment(shortened to UntitledDesktop or UDE) is a desktop environment for Linux and other operating
systems that use components made by the freedesktop foundation.
The UntitledDesktopEnvironment is an umbrella term for the following 3 projects:
- The UntitledApplicationSuite
- The UntitledDesktopEnvironment
- The UntitledDesktopEnvironment Flow
The UntitledApplicationSuite is a collection of cross-platform applications that serve as utilities for a desktop environment
and are not actual required components of it. This includes applications such as:
Most of these applications are cross-platform.
This is the base for the desktop environment. It includes applications, such as:
When used together, the desktop is almost complete, however, the desktop shell is still missing.
* Logo derived from Chinese character 川, meaning river/stream.
UntitledDesktopEnvironment Flow or UDF is a minimal reference implementation of such a shell.
It includes the following 2 applications:
- A minimal application launcher - UDFApplicationLauncher
- A minimal and highly customiseable bar/panel - UDFPanel
We have the following goals:
- User freedom
- Cross-desktop compatibility
- A fully community-centered approach to development
- A great UX, no matter the level of the user’s knowledge
- A fully modifiable and hackable application suite out of the box
- A great multilingual experience
- A great distribution experience
- A great theming experience
We prioritise user freedom and system customisability. These are the rights of our users:
- The user shall be able to replace most application with any other equivalent without breaking the system *1
- The user shall have the ability to transparent documentation of all configuration formats
- The user shall have the ability to use any configuration and/or programming language of their liking when
configuring software or developing plugins for software part of UDE *2
- The user shall have the freedom to modify features of any applications(when available) in order to tune enabled
code and features at compile time for whatever purpose
- The user shall be allowed a way to develop plugins and addons for our applications regardless of their preferred
programming language *3
*1 - This applies to most applications, though when talking about ones like the settings manager, this might not be
*2 - When talking about configuration files, this is not to say that an application using a YAML config should also
open TOML, just for the case where a user might want to use TOML. Instead, for most popular formats, such as theme files,
we apply the adapter model, where an application may convert TOML to YAML. We might develop such tools for aforementioned
popular files, but any formats that are not of high demand shall be adapted by third party users.
*3 - Where it is reasonable to implement such support. Some applications, like those that are narrowly specialised
may not recieve plugin interfaces.
How do we achieve this
- Our desktop environment doesn’t assume specialised desktop convention and acts more like a DE framework
- Applications are, in most cases, built as self-sustained atoms that don’t necessarily depend on any other UDE application
- Documentation of features is our top priority when developing any feature. The moment it is pushed to a repository it
should be fully documented
- For formats such as foreign themes, we build multidirectional adapters and conversion tools
- All our libraries provide a C and C++ API. The C API can be used to create bindings to any programming language
- We utilise compile flags to enable and disable 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 compile flags
We achieve cross-desktop compatiliby in the following ways:
- By not assuming a specific desktop convention and acting more like a DE framework
- By following any standardisation effords by the freedesktop group
- By building adapter utilities and libraries to convert between incompatible formats
- By collaborating with other desktops to improve compatibility
Our approach to development is fully community centered. We run on a 2 tier developer system:
- Staff - Has additional administrative and moderative rights such as the ability to review pull requests
- Developer - Any other user that contributes to our projects
However, apart from this, we’re all users of the software. Some of us may be developers of the software, but we shall never
loose touch with the simple fact that we’re all users of the software. As users, we shall be focused on our shared experience
and shall make it easier for any user even non-technical ones and the subset of beginner non-technical users.
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
Make all our applications have a unified build process, so that we can easily package them for many platforms. We’re already
developing a tool that can package our software as the following formats:
- ebuilds for Gentoo and Funtoo
- arch linux packages
- MSI installers for Windows
A package manager for UDE plugins. Using it improves the plugin installation experience, leaves less work for the user and makes
The package manager also supports custom package repositories.
A great theming experience
We achieve a great theming experience using the following ways:
- We use a simple YAML format for themes
- Themes are minimal and only cover colours and sizes of some elements(in contrast to Gnome CSS files)
- Animation theming is completely not supported
- Multi-directional compatibility tools for converting themes between our format, GTK and QT
- 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 setting them
- Themes have full inheritance, an application can use the root global theme or inherit from another application’s
- Themes are not forced on developers - Turning off theming support doesn’t require an action from the developer when using
- Themes and theme formats have official* specifications, that define the format of a theme. These specifications can be
extended using extensions to the standard.
* Official to the UDE theme formats. To clarify, it means that, since these theme specifications are based on the theming
interfaces of a number of GUI libraries which we aren’t the developers of, they only exist to standardise the naming of fields
in such theme files. We do not standardise the theme interface, as we’re not the developers of these libraries. Theme
standards are also updated when the uderlying library changes their theme interface.
You can find more about the UntitledDesktop colour theme specification here:
- UntitledDesktopThemes Core specification
- UntitledDesktopThemes Official Extension: ImPlot
- UntitledDesktopThemes Official Extension: ImGuizmo
- UntitldeDesktopThemes Official Extension: Knobs
- UntitledDesktopThemes Official Extension: Spinners
- UntitledDesktopThemes Official Extension: Console(For UntitledLog’s imgui widget and projects like ImTerm)
Additional theme specifications we comply with:
- Freedesktop Audio Theme specification
- Freedesktop Icon Theme specification
- Freedesktop Cursor Theme specification
- Freedesktop Thumbnail Management specification
- Freedesktop Shared Default Keyboard Shortcuts specification
To be added
We’re still developing our scope so this section should be expanded in the future
- UntitledDesktopKeybindings Core Specification