solile Development: Week 1.5

You probably don’t know what solile is, so let me explain. solile (yes, without capitalization like a hipster) is a new mobile desktop environment that I am working on. It melds ideas I got from working on Lomiri with a more modern tech stack.

Let’s go over some ideas I have had and what I have been working on.

Compositor

This is the boring piece that nobody cares about until it breaks. The compositor will support wayland with no support for x11/xwayland. This is mostly so I reduce the workload on myself having to implement two different protocols that need to superficially act the same to the user. xwayland-satellite is there if a user really needs xwayland support. I did actually consider orbital and Arcan as alternatives, but from a pragmatic and user-focused stance, going with such young technologies with shifting / differing goals would be unwise.

Most work so far has been on the compositor itself since I want to implement gestures there (along with software / hardware buttons if people hate / can’t use gestures). I have been using the Smithay library for this. Smithay is a super cool project that aims to implement the low-level pieces of Wayland in a similar vane to wlroots. Smithay was chosen for a variety of reasons. Firstly, I am very bad with C. Like, I think if I wrote a “hello world” a CVE would have to be released and all source code burned. (I am not actually that bad. If I was you probably would have to close this post and pretend I didn’t exist until I gave up.) Rust I have a better handle on, seeing as it was my first programming language. I also considered Haskell since the functional approach entices me and I could bind wlroots and just use that. For this first iteration of the compositor I am deciding against it just so I can get a proof-of-concept out. Could go back and consider Haskell later.

Dock

Since I am attempting to replicate the Lomiri / Unity workflow with some modifications, the first thing to work on past the compositor is the Ubuntu-style dock. There is nothing too interesting about the dock itself, since it will act pretty much the same way as the dock in Lomiri or modern Ubuntu-themed Gnome does, but it is still important none-the-less.

UI Toolkit

I considered using SDL2 directly for the UI, but that seemed like a burden since I would have to consider many small details that I wouldn’t have to with a UI toolkit. Thus, to keep with the rusty theme, I decided to use iced. iced is a really cool native UI library inspired by the web UI toolkit elm. The COSMIC desktop makes use of it through its library libcosmic, which I might end up switching to to benefit from the accessibility improvements, layershell support, and general nicities. For now though, I am sticking with vanilla iced (or maybe the libcosmic fork of iced) to give myself some freedom.

Adaptivity

This freedom is needed so I can more easily implement adaptive widgets for iced. iced, and libcosmic, do not have the best adaptivity, which makes sense, since they have not been used for an adaptive use-case before. This shouldn’t be the highlight of the work, since this would just be modifications of basic iced and/or libcosmic widgets, probably being able to be upstreamed to their respective projects.

greetd and seatd

Login seat management should be handled by greetd and seatd, leaving logind out of the picture as much as possible. This isn’t because of some anti-systemd mumbo jumbo, but for a practical reason I will address later. Something personally important to me is using the greeter as the lock screen as well, or at least two programs with the exact same UI. My biggest pet-peeve is a boring, sad greeter acting as the user’s first interaction with the system. The greeter needs to be as fancy or robust as the regular lock screen.

Portability

One key point of solile is that it should be generic. Low-level details should be abstracted to the point that it is plug-and-play for supporting new system types. This is why logind (and even udev) should be avoided to the best of my abilities, as these are arguably the biggest linuxisms (and systemdisms) that desktops feed into. I have been looking at turnstile as a potential session tracker to suppliment not using logind as I don’t want to make something home-grown as that would increase desktop fragmentation. My only gripe with turnstile is that it is written in C++, but the Chimera Linux developers seem like they know what they are doing, so I will keep considering that as an option.

Random Implementation Ramblings

Virtual Keyboard

The virtual keyboard is arguably the second most important component of a mobile UI, behind the compositor. Without it, the user cannot interact with anything on there device. Now, you know this, but I need to rant so bare with me. There are two possible options for handling the virtual keyboard. I could either write my own keyboard using iced, or I could use the maliit keyboard, which is used by KDE Plasma Mobile and Lomiri. Both options have their positives and drawbacks. A custom keyboard would allow for better integration with the desktop and allow me to support squeekboard-style layouts. Yet, writing my own keyboard will take time and have less contributions since I wouldn’t be sharing them between projects. Using the maliit keyboard would allow me to avoid all of this and use something known to work. The drawbacks would be a lack of integration and having to use Qt alongside iced, which feels like extra dependencies that I don’t want to have. I am leaning towards a custom keyboard, but we’ll see.

Notifications, Panel and Quick Access

The notification daemon is honestly not that interesting either. The UI component is what I am most interested in. A lot of modern phone UIs allow for notifications to include actions for the user to take, which appear in the form of buttons. Most Linux UIs though require the user to open the app to make those actions. I would like to integrate the messaging app with an ipc to allow for the user to respond to messages directly from the notification itself. I think this would save a click and just make things smoother.

The notifications will be at the top of the screen and then in a menu that the user has to swipe down to open. This is okay because, since the notification will break the flow of the usage anyways, forcing the user to reposition their hands to swipe is okay.

A panel should be at the top of the screen when the notifications window is closed. This panel should display the time, Wi-Fi status, bluetooth status (if on), cellular status, notifications (either count or just a dot), and maybe be modular to allow for custom widgets? No tray or menus though to not clutter the small space at the top of the screen.

Quick access settings will be at the bottom of the screen, similar to iOS. These will include Wi-Fi, Bluetooth, data, audio and microphone volume, etc.

App Launching and Window Management

Apps will be launched with the launcher, appearing on top of any previously opened apps. Only one app can be focused at a time, taking up the whole screen but not being fullscreened automatically (e.g. the phone UI elements are still shown). The dock will hide to the left and the user will be able to switch apps by swiping to the left from the right side, showing all the apps in a vertical line. The user can also switch by swiping up and down on the right side of the screen, moving to the previous (swipe-down) and next (swipe-up) window respectively.

The End

That is all I have for this week. I’ll try releasing blog posts on Wednesdays or Saturdays (I haven’t made up my mind yet), which should have some more information about actual change records and repositories when I get them up. For now nothing is published yet as I get at least one basic POC of a component out. I plan to use a monorepo handled with pijul for my own sanity, but I might split the repositories and/or switch to git if something changes. For now though, stay tuned!