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 projects:

  1. The UntitledApplicationSuite
  2. The UntitledDesktopEnvironment

UntitledApplicationSuite

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:

  1. UntitledGameSystemManager
  2. UntitledIBusHandwriting

UntitledDesktopEnvironment

This is the base for the desktop environment. It includes applications, such as:

  1. UntitledDEWelcome
  2. UntitledDEPolkitAgent
  3. UntitledDESessionLogout

This is the core of the desktop. Users shall then create their own shell.

Note: More applications are planned to be developed at a future date.

UntitledDesktopEnvironment Flow

UDE Flow

* 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 applications:

  1. A minimal and highly customiseable bar/panel - UDFPanel

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. These are the rights of our users:

  1. The user shall be able to replace most application with any other equivalent without breaking the system *1
  2. The user shall have the ability to transparent documentation of all configuration formats
  3. 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
  4. 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
  5. 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 completely possible.

*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

  1. Our desktop environment doesn’t assume specialised desktop convention and acts more like a DE framework
  2. Applications are, in most cases, built as self-sustained atoms that don’t necessarily depend on any other UDE application
  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 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

Cross-desktop compatibility

We achieve cross-desktop compatiliby in the following ways:

  1. By not assuming a specific desktop convention and acting more like a DE framework
  2. By following any standardisation effords 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

Development

Our approach to development is fully community centered. We run on a 2 tier developer system:

  1. Staff - Has additional administrative and moderative rights such as the ability to review pull requests
  2. 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 theming experience

We achieve a great theming experience using 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. Animation theming is completely not supported
  4. 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 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. Themes and theme formats have official* specifications, that define the format of a theme. These specifications can be extended using extensions to the standard.

To be added

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

Specifications

Misc

  1. UntitledDesktopKeybindings Core Specification