Can you install a stripped-down version of linux that only runs a single, full-window app?

Question

Trying to take my Pi Zero W and embed it in one of my projectors to create an information appliance. In other words, I don't need, or even want the overhead of a full desktop with window management, etc.

I've read all I should need is Linux running a X11 server, then my app--the client--would simply talk to that. I've also heard my app can act as both the X11 server and client.

I've seen people talk about booting Raspbian straight into a full-screen app, but if I'm correct, that's technically still loading the full Raspbian desktop--it's just hiding it--so it's still using critical resources.

So is what I'm after possible? A bare-bones linux install with networking, but no UI except a single window application? Things like wireless could be handled via config files, etc. What's the best way to approach this?

Answer 1

I would start with the official Raspbian-Lite since it is already pretty much as stripped down as one could need, and works out of the box with the hardware.

By Default You Get a fully functional, light weight linux for free (time, money, freedom)

1. Kernel
2. Coreutils (Shell and basic shell tools)
3. Networking Tools (wlan and ssh)
4. System Frameworks like python ruby perl

"A bare-bones linux install with networking, but no UI except a single window application? Things like wireless could be handled via config files, etc. What's the best way to approach this?"

Check! (Note, config is already done via files, the GUI tools are just interfaces to edit config files and periodically read status files to track dynamic information)

Only thing that you Don't get is a GUI of any sort. More on that below.

---

GUI Options

When you write a GUI application, there are common elements that you usually need to have. E.G.

• Button (Events and Mouse Handling)
• Window/Subwindow (Overlapping Buffers)
• Tool Bar (Context Dependent Visibility)
• Text Box (
• Image

When choosing a framework, a trade-off exists between functionality that is done for you and functionality you must reinvent.

Note: Calculating the pixels to draw for a button is simple, but to create a system that can detect and respond to all kinds of arbitrary input (click, double click, drag, swipe, scroll, etc.) is actually very very hard (read: tedious and error prone).

What follows is a brief description of a few options for bare-bones displays.

1. Framebuffer

The Raw Graphical Output on your screen actually is itself a file. This file is there even if X is not installed.

/dev/fb0

An description of what this thing is can be found in the kernel documentation.

However, for us it is suffice to imagine this as a "bitmap" of your screen. With many caveats, because the formatting of the data is platform dependent.

Your application (written in c, python, java, whatever). Would open this file, and write (Platform Dependent!) bytes to it to display and modify an image on the display. It would also need to grab raw input from mouse and keyboard and interpret that as button clicks, and distribute events (calls) to appropriate functions.

For example

cat /dev/urandom >/dev/fb0

Will make colorful pixels randomly populate your screen

• Is it possible to access to the framebuffer in order to put a pixel on the screen from the command line?
• How to use /dev/fb0 as a console from userspace, or output text to it

2. X Windowing System (X11 aka Xorg)

The most infamous user of framebuffer. In a nut-shell This provides

1. Windows (Possibly Overlapping Independent Regions)
2. Input (Mouse and Keyboard)
3. Events

Most people will use a higher level GUI library like GTK Qt or wxWidgets to create usable objects like buttons and toolbars using the basic features provided by X. These libraries also greatly simplify creating "event handlers" for things like buttons and key presses.

You can also directly draw graphics using OpenGL

You do not need to have a full featured GUI Desktop Running or even Installed to use X to run a graphical application

Your application (Again, python, c++, whatever) would use the GUI Tools together with Xlib (API for Xorg) to draw widgets, windows, etc. on the screen.

NOTE: When running a Full-Screen Application with a desktop environment, there are pretty much no other GUI tools running in the background anyway, mimicking this use.

• How do you create a window in Linux with C++?

3. Text Based User Interface (nCURSES!)

Text Based User Interfaces are a simple alternative to all of the above, and may be a cool and elegant solution to your "Information Appliance" concept.

This application uses the terminal shell directly to create visual displays with ASCII characters. The library ncurses is supported in many languages and provides GUI-like concepts of windows, buffers, buttons, tabs, input, etc. in a console environment

You can actually create a very simple Menu-Based Interface using just a shell script with the built-in linux utility

dialog

which creates the type of interface shown in the top left of the following image.

Answer 2

I did something similar here. A key point in response to your 3rd paragraph: X is implemented very differently than Windows or MacOS. It's not "all or nothing", so you never need to load "the full desktop" if you don't need it. There are several layers which can be simplistically summarized as:

1. The X window system. If you launch X with no additional layers, you get a gray background and nothing else, with no means to launch programs in the GUI. You can write startup scripts to launch programs. Typically, you'd launch a terminal (e.g. xterm) that you could use to launch additional programs from. You get no nice title bars or buttons to manipulate windows with.
2. A window manager. This is the layer that adds a colored desktop, title bars and buttons to manipulate windows. You can, but do not have to, add file managers, launch bars and other niceties. Things look nicer, but there's little integration between programs.
3. A desktop environment. These roll everything together, providing features like an integrated clipboard, sound management and other features that feel more like a consumer "desktop".

What I think you want is layer 2. A window manager but nothing else so you can launch a GUI program. There are some very lightweight window managers available. I chose OpenBox for the project in the video.

Of course, you could forego a GUI entirely and build it using a text interface, but if you want to take advantage of web technologies, or use GUI toolkits, you'll likely want a minimal GUI.

Wikipedia has a nice summary if you want more info.

Answer 3

I was in a quite similar case, and did choose to use pygame, a python binding to SDL, a graphic library.

Good points :
As SDL don't rely on X11, pygame can be run from console, and shows a nice fullscreen graphical application, heavily customizable (aka : you start from a black screen, then draw what you want on it)
Pygame is quite well documented and discussed, quite easy, offers all the base functions you will need to manage user interactions and interface in a single library.

Bad points :
Pygame lacks GUI content: it's up to you to draw every buttons, icons, boxes, as image files. (You still can display geometrical shapes and texts to screen just with code.)
Some user input have to be manually managed : by exemple don't expect to use a text field object "out of the box" : you will only be able to read raw keyboard press and have to edit the right button in the right page, then refresh your screen, at each press ! Don't worry too much about this, it's not dramatic, just a bit annoying.

If you want to give a try to pygame, take a look to this software from adafruit, it's a very good inspiration when building a GUI : The Button and Icon class are very well written, the page management is quite nice too.

Alternatives
There are other tools to write graphic interfaces running without X11, and even GPU optimized : dispmanx and openMax. They are far more difficult to work with (gpu memory management is a pain) and your client would need to be written in C/C++. Worst, these libraries lack tons of tools that pygame can provide (no user input management ..)