Update

gui.md

@@ -10,17 +10,20 @@ Expert computer users normally frown upon GUI because it is the "noobish", ineff
 
 ## When And How To Do GUI
 
-GUI is not forbidden, it has its place, but today it's way too overused -- it should be used only if completely necessary (e.g. in a painting program) or as a completely optional thing built upon a more [suckless](suckless.md) text interface or [API](api.md). So remember: first create a program and/or a [library](library.md) working without GUI and only then consider creating an optional GUI [frontend](frontend.md). GUI must never be tied to whatever functionality can be implemented without it.
+GUI is not forbidden, it has its place, but today it's way too overused -- it should be used sparingly, only if completely necessary (e.g. in a painting program) or as a completely optional thing built upon a more [suckless](suckless.md) text interface or [API](api.md). So remember: first create a program and/or a [library](library.md) working without GUI and only then consider creating an optional GUI [frontend](frontend.md). GUI must never cripple a program that can work without it. Say no to [frameworks](framework.md)! Absolutely **NEVER** let GUI dictate what languages, tools, file formats or [paradigms](paradigm.md) 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](suckless.md) 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](qt.md)? No.
+Still, when making a GUI, you can make it [suckless](suckless.md) 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](qt.md)? No.
 
-The ergonomics and aesthetic design of GUIs has its own field and can't be covered here, but just keep in mind some basic things:
+Also keep in mind this: **GUI doesn't have to have 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](bullshit.md) pimp feature no one really needs. Your program can be just a full screen [DOS](dos.md)-style GUI, don't just blindly implement windows because they're everywhere. THINK, do not imitate because the established way is [cancer](cancer.md) -- your GUI doesn't have to run of 60 FPS, you probably don't need a [framebuffer](framebuffer.md), full RGB colors, clicking sounds, font rendering library (maybe you don't need text at all) etc. Use the fucking white matter you have in your skull, if there is any.
 
-- Don't have too many elements (buttons etc.) at the screen at once, it's confusing as hell and drives noobs away.
-- Things must be intuitive, i.e. behave in a way that they normally do (e.g. main menu should be at the top of the window, not the bottom etc.).
-- Just use your brain. If a button is important and often used, it should probably be bigger than a button that's used almost never, etc.
+The ergonomics and aesthetic design of GUIs has its own field and can't be covered here, but just bear in mind some basics:
 
-The million dollar question is: **which GUI framework 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, look for a suckless one; e.g. [nuklear](nuklear.md) is worth checking out. The suckless community sometimes uses pure [X11](x11.md), however that's not ideal, X11 itself is kind of bloated and it's also getting obsoleted by  [Wayland](wayland.md). The ideal solution is to make your GUI **backend agnostic**, i.e. create your own very thin abstraction layer above the backend (e.g. X11) so that any other backend can be plugged in if needed just by rewriting a few simple functions of your abstraction layer (see how e.g. [Anarch](anarch.md) does rendering).
+- Don't have too many elements (buttons etc.) at the screen at once, it's confusing as hell and drives noobs away. On the other hand too many submenus can be confusing as hell -- 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.
+- Things must be "intuitive", 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.
+- Just use your brain.
+- ...
+
+The million dollar question is: **which GUI framework to use?** Ideally none. GUI is just [pixels](pixel.md), 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, look for a suckless one; e.g. [nuklear](nuklear.md) is worth checking out. The suckless community sometimes uses pure [X11](x11.md), however that's not ideal, X11 itself is kind of bloated and it's also getting obsoleted by [Wayland](wayland.md) which is also shitty. The ideal solution is to make your GUI **[backend agnostic](portability.md)**, 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](anarch.md) does rendering).
 
 ## State Of Mainstream GUI