2015 bsd can-luminade

Lumina DE:Redefining the Desktop Environment for Modern

Hardware

Ken Moore PC-BSD/iXsystems

BSDCanJune 12th, 2015

Modern Problemswith Graphical Interfaces

From the OS-perspective, everything computer-related is heading toward unification.

● No longer need custom-written OS's for each individual device (not counting different builds for various architectures)

● Users want cross-compatibility between all their devices (not just files, but settings and preferences when migrating from one device to another)

● The main differences seem to come down to default/supported configurations, allowing the same OS to be used in a small router as well as in a supercomputer.


From the interface-perspective, this unification still has not occured.

● Interfaces have traditionally been designed for particular types of systems with little flexibility (just like the old OS's)

● I think interface designs have not made the transition to a general-purpose model for a few reasons:

– Physical screen size variations

– Input method variations

– Hardware capabilities (CPU & memory in particular)

Modern Problems:Display Sizes

Smartphones3” -> 5”

Tablets7” → 11”

Laptops10” → 18”

TVs30+”

Desktops16” → 30”

800x480 →2048x1536

320x480 →720x1280

800x600 →1920x1080

800x600 → 4096x2160

720x480 → 4096x2160

● How large should a button/icon be?● Should the screen have reserved

space?● Clearly, the interface should not be

identical across all the types of devices due to the differing physical size limitations!

www.xkcd.com/732

Modern Problems:Input Methods

● Some correlations can be made between different input types

Quick Touch ←→ Mouse Left-Click

Touch & Hold ←→ Mouse Right-Click● Virtual Keyboards also help bridge the gap

● Input methods determine the types of available interface elements

– Can lists be scrolled easily? (mouse wheel)

– Must buttons be large enough to touch?

Smartphones Tablets Laptops Desktops TV/Console

Touch TouchKeyboard

MouseKeyboard

MouseKeyboard

Controller(Keyboard)

Modern Problems:Hardware Specs

Smartphone Tablet Laptop Desktop TV/Console

CPU Speed

(GHz)1 to 2.5 1 to 2.5 1 to 2.5 2 to 5 1 to 3

CPU Cores2 or 4 2 or 4 2 to 7 2 to 8 2 to 8

Memory

(GB) 1 to 2 1 to 2 2 to 16 2 to 32 0.5 to 8

Storage

(GB)0.5 to 16 8 to 32 128 to 512 256+ 16 to 512

● Storage does not seem to be much of a problem – the amount available in even tiny devices is rapidly increasing

● The trends seem to favor multiple low-power CPU's● Memory available is still quite limited on small devices

compared to most desktop systems (particularly gaming systems)


In order to fix all of these problems, we need to perform a fundamental re-design of how a desktop environment is assembled and distributed.

● Ensure that the minimum requirements easily accomodate the least-powerful of the target platforms (smartphones in this case)

● Eliminate any platform-specific dependencies (web browsers, general-purpose applications). Let the platform distributor add in those applications as necessary.

● For every point of large variation, insert a generic abstraction layer where the functionality can easily be changed to support the current platform.

Modern Solutions:Display Sizes

There are a few things that can be done to accommodate all the various display sizes:

● Define all the element sizes by metrics which are resolution-independant (such as point sizes for fonts and percentage of screen for interface elements)

● Allow different window-placement algorithms for the various platforms

● Create multiple interface elements with duplicate functionality but tailored for different platforms

● Allow the interface to be initially created based on a single configuration file provided by the distributor, but able to be changed later by the user

Modern Solutions:Input Methods

Accounting for all the various input methods is actually not that difficult, it just needs a bit of planning ahead of time.

● Provide an optional set of input conversion routines in the background (touch/controller events to keyboard/mouse events for example)

● Provide a virtual keyboard plugin/utility

● Create multiple interface elements with duplicate functionality but tailored for different platforms

● Enforce a minimum size for buttons/actions as necessary

Modern Solutions:Hardware Specs

While available disk space does not appear to be a major hurdle, the amount of available memory seems to be the bigger issue that needs to be addressed.

● Seperate the overall desktop session (which is always running), from any optional interfaces/plugins (which may require more memory).

● Create multiple interface elements with duplicate functionality but with different runtime overhead.

● Use a pre-compiled language for development instead of an interpreted scripting language. Once selected, use that language exclusively.

The Lumina Desktop Environment

What is it?

● Created/distributed under the 3-clause BSD license

● Written from scratch in C++/Qt(5)

● Compliant with the FreeDesktop/XDG standards

● Currently version 0.8.4 (still in beta)

– Uses Fluxbox for window management

– Only requires some other X libs/utils – no Linux toolkits (DBUS, ConsoleKit, policyKit, systemd, HALD, etc)

● Already available for: PC-BSD, FreeBSD, OpenBSD, Dragonfly BSD, kFreeBSD, Debian, and “Linux”.


How is it designed?

● Based on a plugin-oriented design philosophy.

● The main components of the DE are:

– The library (libLuminaUtils.so)

– The session (non graphical, background management system)

– The desktop (graphical – one per output device)

– The interface plugins (desktop, panel, and menu)

– The “lumina-open” utility (tied into “xdg-open” for cross-DE application usage)

– Other small utilities are available for traditional desktop use

Lumina-DE: Utilities

xterm

lumina-fileinfo

lumina-fm

lumina-info

lumina-screenshot

lumina-xconfig

lumina-search

xscreensaver

Fluxbox

lumina-open

lumina-config

numlockx

Lumina-DE

Login Manager / X11 Startup

OptionalFunctionality Required

Required

xbrightness

Lumina-DE: Session

Operating System

Display Server (X11)

Visual Interface(s)Window Manager

Screensaver

Lumina Session

System Tray Task Manager Config Watcher

LDesktop

LuminaX11(ICCCM/EWMH)

Services &Applications

LuminaOS

Lumina-DE: Interface

Desktop Interface (Virtual root window with wallpaper – one per X11 monitor)

Panel(s)

Desktop Plugin Area

LPanel

Panel Plugins

● Usually Visible● Easy Access

● Limited Space● 1D Arrangement

Context Menu

LPPlugin

Desktop Plugins

● Covered by Apps● Size/Location Config

● 2D Arrangement● “Embedded Apps”

LDPlugin &LDPluginContainer

Menu Plugins

● Run on Demand● Menus/Shortcuts

● Desktop Lock/Unlock● Log Out Prompt


How is it configured?

● Text based configuration files located in the ~/.lumina directory.

● For new users, the configurations are generated based on the system-default luminaDesktop.conf file.

● For every new version of the desktop, the session/config files are evaluated for any changes that might be necessary for backwards compatibility (and those changes are performed automatically to prevent loss of service)

Lumina-DE: System Defaults

Located at: [/usr/local]/etc/luminaDesktop.conf

● Simple syntax: “<variable>=<value>” with “#” before comments

● Examples:

– session.playlog[in/out]audio=[true/false]– session.default.webbrowser=<path to *.desktop file>– desktop.backgroundfiles=<list of files for wallpapers>– desktop.backgroundrotateminutes=<positive integer>– [desktop/panel/menu].plugins=<list of plugins to use>– favorites.[add/remove]=<file/dir path>

● This routine is extremely easy to modify, so if there is some particular configurable which you need access to, just let me know!


Does the DE have a plan for supporting Wayland?

● The Lumina desktop project keeps the usage of all non-Qt libraries/standards highly segrated within the source code to attempt to ensure an easy transition to other systems at a later date.

● These components are located in specialized classes within the LuminaUtils library:

– LuminaX11 (X11/XCB library usage)

– LuminaXDG (FreeDesktop standards support)

– LuminaOS (Operating system support)

– LuminaThemes (Theme engine for the desktop/utilities)

– LuminaSingleApplication (Single application framework)

– LuminaUtils (General purpose functions)

Lumina-DE: OS Interface

PC-BSD FreeBSD OpenBSD DragonFly kFreeBSD Debian Linux

Control Panel Yes No No No No No No

App Store YesAppCafe

No No No No Yessynaptic

No

Qt5 Config No No Qt4-only Qt4-only Qt4-onlyYes

qt5ct Qt4-only

List Mounted Devices

Yes Yes Yes Yes Yes Yes Yes

Screen Brightness

Hardware & Software Software

Hardware w/ xbacklight Software

Hardware w/ xbacklight



Audio Volume

Yes Yes Yes Yes No Yes Yes

Audio MixerYes

pc-mixer No NoYes

pc-mixerYes

pavucontrolYes

pavucontrolYes

pavucontrol

System Suspend

Yes No No No NoYes

dbus → systemd

No

Battery Monitor

Yes Yes Yes Yes No YesNo est. time

YesNo est. time

Lumina-DE: OS Interface

PC-BSD FreeBSD OpenBSD DragonFly kFreeBSD Debian Linux

FilesystemCapacity Yes Yes Yes Yes No Yes Yes

Checksums Yes Yes Yes No No Yes Yes

CPU Temperature Yes Yes No No No Yes No

CPU Usage Yes Yes No No No Yes No

Memory Usage Yes Yes No No No Yes No

Shutdown Access Check

Yes, also with update

process checks

Yes YesNo

(Always enabled)

No(Always enabled)

Yesdbus → systemd

No(Always enabled)

Note: This chart is accurate as of Lumina version 0.8.5-devel (6/2/15)

Lumina-DE: Near-Future Plans

● Create a new window manager (lumina-wm)

– Combines functionality of a WM, screensaver, and power manager.

– This will remove Fluxbox and xscreensaver from the dependencies.

● Integrate Capsicum usage on FreeBSD

– Still in evaluation period

– If you are familiar with this security framework and want to help out, please talk to me!

● Continue to create additional plugins, color schemes, and themes

Questions?

Slides available online at:http://www.slideshare.net/beanpole135/

http://www.slideshare.net/beanpole135/