Custom Linux Desktop Environment

[regular]

I want to switch to a Linux laptop for my primary development machine. I need a pretty limited set of features from my desktop environment:

• [x] full screen magnification controlled by two finger touchpad gesture
• [x] terminal emulator
• [ ] browser

Additionally, it would be nice to be able to extend the GUI shell with small JS scripts (like gnome-shell, but NodeJS/npm compatible).

• [ ] JS shell extension support.

[regular]

Magnification / Desktop zoom in libweston

Wesron (wayland's default implementation of a compositor) implements desktop zooming exactly in the right way (like OS X). Even under extreme load (8 CPU cores under 100% load while compiling chromium), zoom is still perfectly smooth.

I changed two finger scroll direction to what Apple calls "natural scrolling" and disabled texture filtering on the output texture, because I want to see the actual pixels without interpolation. It wasn't hard to find the respective source code locations in libweston.

[regular]

Chromium on Wayland

There's a chromium-wayland in AUR, but it is not being maintained anymore because the author hopes that the wayland backend gets merged into mainline soonish. Some of that already was merged, so I build chromium-dev from AUR. It starts and displays webpages but seg faults as soon as a key is pressed. This seems to be quite typical for a gtk3 build of chromium running on wayland. Some part of the system seems to assume that chromium is a native wayland application because of the fact that it uses gtk3. However, that's not the case, at least not for keyboard input. A workaround seems to be to force GTK to use its x11 backand, which in turn will cause wayland to use its xwayland server adapter thing. I could not make it work (did not try very hard yet though)

• [ ] make current chromium-dev run on xwayland
• [ ] make chromium run as a native wayland application

[regular]

Chromium Privacy Forks

There's a Chromium fork called "Iridium" that removes tracking and integration with google cloud services. There's also a patchset with the same goal.

• [ ] build Iridium. How far does it lag behind chromium-dev?
• [ ] apply the patchset to chromium-wayland

[regular]

Electron-wayland

The nicest way to implement JS shell extension support would be a fullscreen electron application that runs as sort of an interactive desktop background.

• [ ] build libchromiumcontent with wyland support
• [ ] replace gtk2 code in electron's codebase with gtk3

[regular]

I was investigating different approaches to implement wayland desktop applications/apps/widgets using NodeJS. Here's what I came up with:

2D

• node-canvas implements a canvas 2D context based on cairo.
• node-wayland provides node bindings for wayland clients.
• Here is an example of controlling pixel data of a wayland window and the mouse cursor from js code. The window's back buffer actually is a cairo surface. Thus, if we hack node-canvas to work with pre-existing cairo surfaces, we'd have a canvas 2d context for a wayland window.

[regular]

3D

• build glew 2.0 from sources: SYSTEM=linux-egl make prevents crash on wayland
• build anttweak
• build node-glfw
• build node-webgl

Now we have a 3D canvas and can use GL shader language.

[regular]

HTML5

• webkit2gtk-unstable (AUR) can be controlled with node via npm package webkitgtk
• frame rate is poor because webkit is updated based on a timer. The main purpose of the npm package seems to be making screenshots of web pages.

Instead I compiled a little C program that hosts a webkit2gtk webview in a fullscreen window. This is the basis for regular/html-terminal. With an RPC module like dnode, this is actually a pretty nice replacement for Electron, at least until Chromium (and therefor Electron itself) has full wayland support.