Can I run GUI programs without needing a desktop environment?

Question

I use Raspbian (i.e. Debian) Linux. I have been doing some reading but am still unclear.

It seems to me when you boot to command line, it's not really made to use GUI stuff like mpv. Is there a compromise between full blown Desktop and CLI? Something which is just terminal windows, but can launch mpv, photo viewer etc?

I can use lf/uberzug on desktop, but I wanted something which runs with less resources than desktop.

Answer 1

You can get apps that talk directly to the framebuffer (VLC or fbi), but IMHO, it's not worth the hassle. Just go for a lightweight window manager, like OpenBSD's cwm, dwm, i3, spectrwm... the list goes on. You'll still need a display server (X11 or Wayland), though, but if your machine can handle playing videos, it sure can handle a display server.

Answer 2

A Window Manager (wm) is what you are thinking of. It's not a full-blown Desktop Environment (de), but can open apps/terminals with a keybinding and uses less resources.

There are lists of window managers for Wayland (called compositors there) and for X11 display servers you can check out that are light and can do what you ask for.

Answer 3

Yes, this is perfectly possible; I used to do this all the time. A bit of background: What we talk about under the name 'X Windows' is in fact 'the X Window System', which encompasses a network protocol: the X protocol. This allows you to run an windowed 'X program' on the remote machine, which displays its window(s) on your desktop; to do this, you need:

• What is confusingly called an X Server, which runs on your local machine - ie your PC, Workstation, laptop, ...
• And on the remote system, you set an environment variable DISPLAY, eg export DISPLAY=192.168.1.100:0, if your workstation has IP address 192.168.1.100

And that's all; if you have linux on your PC, you already have an X Server. On Windows you have to install something which may cost money; on MacOS I expect it is part of the system (maybe hidden), since it is a variant of a BSD UNIX.

About the terminology: the X Server is a server because it serves the requests sent by the X Client - your X program. X is an exciting system if you enjoy trawling through endless configuration options, but in practice it isn't actually too bad.

Answer 4

It sounds like you want an X11 (or Wayland) window server running for graphical applications.

I suggest you install and configure a minimal window manager (I recall that pekwm doesn't get much in your way or hog resource). This will allow you to move windows around, for example, and iconify them as desired.

Then you would configure your .xsession file to start a terminal and the window manager:

#!/bin/sh

xterm &

exec pekwm

Now you can start a graphical environment by running startx and terminate it by exiting the window manager.

If you install a greeter such as xdm, this will allow you to log in graphically, rather than having to run startx after logging in.

When the .xsession process (now running the WM) terminates, XDM will prompt for the next user to log in.

Answer 5

It is not clear to me if you want to run "GUI stuff" on the Rpi or from a remote login. If the latter, assuming you run linux as your primary desktop, you can just ssh into the Rpi using the -Y option like so:

ssh -Y user@rpi

Thereafter, just run the GUI executable. I find the "xeyes" package to be a good test (if not installed, run apt install xeyes). Just run xeyes after logging in and it should start on your own desktop. You are essentially enabling trusted X11 forwarding. Note that trusted X11 forwardings bypass X11 SECURITY extension controls.

Answer 6

You can run them on a virtual server:

Install:

xorg-server-xvfb

Then run:

xvfb-run [command]

Answer 7

Yes. It is also possible to run a GUI program without a local display. Which I only mention for those looking to play with stupid '90's UNIX parlor tricks-- but since you have a Pi...

Suppose I have a big beefy VM (or a Pi) named marvin.example.com. Brain the size of a planet and it just runs xeyes, etc. You have a tiny little laptop we'll name "lappy386" (doesn't need a domain).

As long as the correct client libraries are installed, you can log into marvin with "X forwarding enabled" and start a GUI application:

user@lappy386$ ssh -X marvin.example.com
<login stuff happens>
user@marvin$ xeyes

The -X option (among other things) sets the $DISPLAY environment variable on the remote host. When the xeyes program is started, it checks $DISPLAY to figure out where to draw things on the screen. This environment variable sets the location of the X Server-- which, confusingly, runs on your laptop. The laptop "serves" a display environment to the individual program (xeyes), hence the name. The tiny little program on the giant VM hosted in a datacenter somewhere is a client to the display server on your tiny laptop at Ye Local Coffee Shoppe. This arrangement has been confusing people since Bush was vice president (H.W., obv-- I'm not that old, but seems like a safe bet).

You don't need any window manager installed for this to work. You do need whatever libraries are necessary for the X client to work (so QT/GTK/whatever and all the dependencies down to X) but you don't need an X server running locally on marvin. Which can save quite a bit of RAM, if you're into that sort of thing.

This works OK. ssh even tunnels the traffic through a handily-encrypted link. You can also find X Server implementations for annoying operating systems, e.g., windows (under Cygwin) or presumably OS X (haven't checked in a decade). The individual "draw stuff to the screen" commands are forwarded from marvin to lappy386 which is much more efficient than sending a full screen rendering. Much of the rendering is also done by lappy386, relieving some of the GUI load from marvin so it can support more clients or something.

However...

• On the modern Linux desktop, there are ways to bypass all this overhead stuff and interact directly with the graphics card. If the graphics card isn't sitting there on a local bus that doesn't always work so good.
• Any resources on the client side have to get network-transferred to the server. This used to lead to all sorts of issues (i.e., die X Font Server die), but these days mostly means lots of stuff gets downloaded by the server. Rather negating the performance advantages.
• It's 2024. Compute, memory and bandwidth are WAY cheap compared to the original X11 specification of 1987 (when an inflation-adjusted $40,000,000 would buy a Cray X-MP that probably loses out to your Pi). We have cool stuff now, like VM environments that can expose your local graphics card to a remote VM.
• It's 2024. We have better client/server architectures, and have even figured out which side is the server! Depending on the goal, you might be better off e.g., running a gdb server and connecting a modern IDE to it from your laptop. Or running a web server and letting clients render everything. If you're trying to have the Pi Just Display Some Stuff, consider editing your .xinitrc file to run just vlc / web browser / whatever and turn the Pi into an appliance.

Still, it's a fun parlor trick.