# less_retarded_wiki

main page, file list (652), source, commit RSS feed, report abuse, stats, random article, consoomer version

# Graphical User Interface

"Always add a commandline interface to your software. Graphical User interfaces are for sissies." --bitreich manifesto

Graphical user interface (GUI) is a visual user interface that uses graphical elements such as images, many distinct colors and fine geometrical shapes. This stands in contrast with text user interface (TUI) which is also visual but only uses text for communication (TUI can further be pure line-based command line interface or a graphical, grid-based text interface that mimics a true GUI, e.g. with ASCII art).

Expert computer users normally frown upon GUI because it is the "noobish", inefficient, slow, limiting, cumbersome, distracting, hard to automate, hard to test, capitalist consumer-style way of interacting with a computer. GUI brings complexity and bloat. GUI is like baby pictures or simple books with drawings for illiterate people and Chimpanzees, for people who need to click on boxes and have flashing strip club colors to keep them entertained, while command line is for normal adults who can read and want to do things efficiently -- there is a reason why programming languages are plain text (with exception of the ones literally aimed at babies in kindergarden). Text is universal interface; text is a formal language that can be handled mathematically well, it is a stream of data easy to process by any language etc. So we try not to use GUIs and prefer the command line.

GUI is also bad for the following reason: it restricts and limits the potential of a computer and our program to just realtime interaction with a human. That is how normal people think about computers, but a programmer knows computers have much bigger potential: computer doesn't have to be just a box with screen and keyboard operated by human, computers may be interacting with each other, they may be tiny and have no screens, they may interact with machines, fly to space, sit somewhere and just record data. GUI kills all this potential, and that's what hackers dislike so much.

On top of this GUI has practically since its wide adoption been plagued by cancer called "desktop metaphor". The metaphor says that the operating system's GUI "should" be similar to the physical desktop (why? because why not), i.e. there "should" be movable icons (like items on the table), movable windows (like paper documents) and so on, plus the common things such as the three buttons in top right corner of each window, a bar on the bottom of the screen etc. This is like the OOP of GUI -- a stupid, arbitrary "paradigm" that's stuffed into everything only to make it familiar looking to retards which besides this does nothing else than complicate everything to maximum. It's important to realize that GUI does NOT have to be done this way, there is no need to have a desktop and graphical windows, just make every program run in fullscreen and let it draw its thing.

"Modern" GUIs mostly use callback-based programming, which again is more complicated than standard polling non-interactive I/O. If you need to do GUI, just use a normal infinite loop FFS.

## When And How To Do GUI

GUI is not strictly forbidden, it has its place, but today it's way too overused -- it should be used sparingly, only if completely unavoidable (e.g. in a painting program) or as a completely optional feature built upon a more suckless text interface or API. So remember: first create a program and/or a library working without GUI and only then consider creating an optional GUI frontend. GUI must never cripple a program that can work without it. First think about how it could be done without GUI (you may surprisingly find that even things like drawing programs can work this way), and only if you find it CANNOT possibly work start to think about GUI. Even if you decide for GUI, it can be minimized, only VISUAL input/output potentially requires GUI, major part of the program may remain text-based. Say no to frameworks! Absolutely NEVER let GUI dictate what languages, tools, file formats or paradigms you should use -- if there is to be a GUI, it must be your absolute slave, not the master.

Still, when making a GUI, you can make it suckless and lighthweight. Do your buttons need to have reflections, soft shadows and rounded anti-aliased borders? No. Do your windows need to be transparent with light refraction simulation? No. Do you need to introduce many MB of dependencies and pain such as QT? No.

Now if you at all can, avoid the fucking "desktop metaphor". GUI doesn't have to have bloody fucking windows. No, this doesn't mean you should have tiling windows instead of floating ones, this means you shouldn't have windows AT ALL. Graphical windows are a bullshit pimp feature no one really needs. Your program can be just a full screen DOS-style GUI, don't just blindly implement windows because they're everywhere. THINK, do not imitate because the established way is cancer -- your GUI doesn't have to run on 60 FPS, you probably don't need a framebuffer, full RGB colors, clicking sounds, font rendering library (maybe you don't need to render text at all, symbols can work even better) etc. Use the fucking white matter you have in your skull, if there is any.

The ergonomics and aesthetic design of GUIs has its own field and can't be covered here, but just bear in mind some basics:

- If possible, it's better to drive down the number of visual elements on the screen, too many can be confusing. On the other hand too many submenus can become a labyrinth too -- so find a way to minimize the number of buttons and if there's still too many, group them let's say under 3 general tabs and that's it. If the program is to be used by more expert users, it may however be fine or even BETTER to have a "plane cockpit" style GUI where everything can be seen at once and accessed immediately.
- Things ought to be "intuitive" and ergonomic, i.e. behave in a way that they normally do and what the user will probably expect: e.g. main menu should be at the top of the window, not bottom right, rarely used buttons should be small and not take too much space, "destroy everything" button shouldn't be right next to "save" button, "go left" button should be placed on left, "go right" on right etc.
- Aesthetic minimalism is probably a good idea, fewer colors may be better than a Las Vegas neons all over the place and so on.
- Just use your brain.
- ...

The million dollar question is: which GUI "framework"/library/system to use? Ideally none. GUI is just pixels, buttons are just rectangles; make your GUI simple enough so that you don't need any shitty abstraction such as widget hierarchies etc. If you absolutely need some "framework" (or let's rather say library), look for a suckless one; e.g. nuklear is worth checking out. The suckless community sometimes uses pure X11, however that's not ideal, X11 itself is kind of bloated and it's also getting obsoleted by Wayland which is also shitty. The ideal solution is to make your GUI backend agnostic, i.e. create your own very thin abstraction layer above the GUI system (e.g. X11) so that any other system can be plugged in if needed just by rewriting a few simple functions of your abstraction layer (see how e.g. Anarch does rendering).

## State Of Mainstream GUI

Nowadays there are a great many GUI libraries, frameworks, standards and paradigms, and it may be a bit hard to digest them at once.

TODO: some general shit bout graphical windows vs the "single window" mobile and web UI, analysis of the "GUI stack" (Linux framebuffer, X window, widget toolkits etc.), basic widgets etc.

Powered by nothing. All content available under CC0 1.0 (public domain). Send comments and corrections to drummyfish at disroot dot org.