Has anyone seen this video before?
https://www.youtube.com/watch?v=AItTqnTsVjA

I saw this years ago and still haven't had anything game changing trickle down to my ears. Are there any GUI Mr. Miyagi out there who can share there wisdom? How can we make the GUI better?

When I first saw it, I agreed with Ross on this. The second time I saw it once I moved to using Linux on a ThinkPad though, I realized it was a mix of Windows' piss-poor design and Ross' skill issue.

One absolutely crucial thing that Ross doesn't mention (likely because he didn't think about it) is keyboard shortcuts. Consider this: none of us use the mouse in an MMO or something to click on the map or inventory, we just use M or I. Nobody clicks on Tool -> Flip Vertically in painting programs to mirror their canvas, they also use M, or maybe V. But in Windows nobody considers using shortcuts and that's because they can't. Well, they technically can, it's just hard-coded to sometimes very uncomfortable keybinds not mentioned anywhere.

Linux does let you customize it though, down to even single-keys in some DEs. Most programs also have their own shortcuts too, and you can just take some time to tailor it to whatever you need. Once you realize this thing you've been using in a bunch of other places are the way to go, you are going to use the mouse a lot less. Not on Windows though, obviously.

I'm going to second >>2 on this, I have a massive sxhkd file with a million keybinds which makes my computer completely unusable to anyone who isn't me. Every time I end up using a mouse-forward interface it feels clunky to me. For example I don't think about programs as their icon or logo, I think about what they're called, so even though it might seem more efficient to just double click on an icon, it's much more intuitive for me to type the name into dmenu or rofi. I even use this launcher on my phone https://github.com/fandreuz/TUI-ConsoleLauncher for the same reason. It's all text under the hood anyway. That being said I think some plan9 evangalists have good things to say about rio but I haven't looked into it.

>>1

there is no gui enlightenment, keybindings are everything... the gui is being raped by faggots who switch from the keyboard to the mouse...

>>4
There is a place for mouse use, selecting functions isn't it. Unfortunately that's essentially the primary thing it's being used for so it understandably gets a bad rep.
If only there were some kind of counter example...
See, the true utility of a mouse, amazing as it is, is selecting positions. Art tools, cad software, hell even spreadsheet software, all use this quite well, some of the time. It's much much much easier and faster to see that there is something wrong 'there' and point to it with the mouse than to figure out the correct number of lines to move down then words to move across, as an example.
*cough*vi is just a shitty extension to ed, and the ed way (regex) is often better than my example, and can be done in vi, but that is neither here nor there*cough*
putting features/functions at locations and making all functionality go through that layer does suck. Having context menus that pop up at the mouse location is better. Being able to send any text on screen to a context interpreter which handles the text to "do the right thing" in a tightly integrated system, by just clicking it seems better than hotkeys. Don't get me wrong, having hotkeys is great, if you want to store that information in your brain. I'd rather store that in a file. But the problem with hotkeys in the consumer space is multiplied by incompatibilities between vendors and even versions. No one has a problem remembering ^c+v ^c+c ^c+x because it became universal. let us pray for the zoomers who will never learn these things

But ima be 900% with you. If you are so keyboard pilled, vim is shit. learn emacs, coward.

>>3
In the case of rio, the real power comes from the power of the way the system operates on the whole. There is a simple program called the plumber, it could be used in linux, dmenu does something /similar/, it just takes in a string then runs it through a rules file that decides what to do with it. That could be passing it to a script or program, like sending a url to a browser or a song to play(1).
It's trival, and seemingly not terribly important, but because it essentially works on all text in the whole system it becomes pretty powerful.
For instance plumbing the string play(1) above on my system opens a troff formated version of the manual for play. Plumbing a text file's name opens it in acme. Listing a dir then plumbing a picture or song just opens it. Sure you can get by with typing "mpv startOfFileName^t" most of the time on linux sometimes not, often i ended up needing to go back and add quotes because some annoying character in the file. clicking the name is just faster.
It's especially faster when considering someone who mistypes just often enough to need to enter the command multiple times to do what you want.
No need to remember the full command to do something specific either, have a rule for "_t ([^ ]+{png|gif|bmp|jpeg|jpg})" that pipes the file through a check for a hash of the file check to see if that hash exists in a cache open if it does, or else resize the image to be smaller and save it in the cache with it's hash name and opens it and now any time you want to preview an image without opening the full image just add the little _t to the start and then plumb it.
Ya, you can do all that with a script, but then you have to remember the script name, which i suppose could be _t but then if you want something else also named _t you have to handle that in the script, and now there's dissimilar things in the same script file. With the plumbing rules the _t is contextual to the rest of the text which already filters for image file extensions.

Acme works with the plumber but also has another layer of plumbing, it will pipe any highlighted text as the stdin for a command that is middle clicked. That command can be a script, a program, or a shell command you just wrote into the menu seconds before to do some one off thing. The gui in this case becomes whatever you need it to be, extending it on the fly as you go, by writing simple rc scripts or commands, putting the "buttons" (just text) anywhere you want them to be.
I will say, it's better to know C in plan9. Rc is similar enough to bash that it's not hard to move over. but not knowing C can be a limiting factor. Tho, for what it's worth, the suggested http(s) server in 9front is written entirely in rc, no c code at all, so what can be done with simple shell scripts is quite substantial. This is possible because even network sockets in plan9 are just text files.

Anyway i think i've written more than enough, and don't want to derail too hard.

https://9p.io/wiki/plan9/mouse_vs._keyboard/index.html
hatred for mouse is uncalled for

time for a silly joke:
have you considered enlightenment? https://www.enlightenment.org
in reality don't bother it's quite terrible, even if it is probably the most hackable 'posix'y gui avalible

You people are sperging out about how Windows and mouse usage is his problem, but neither is. It should also just be said that he doesn't even really have any huge problem, it's just that GUIs are far from utopian. If you're somewhat familiar with Ross or hell he gives you his whole computing backstory in the video, but you'll know that he's been making videos and also doing perfectionist mod installs of obscure games so he does a lot of crap on his computer. Seems like he's worked out good solutions in general even if they may seem like janky ones. He must have a slightly different set up since he has moved to Windows 10 more recently.

Anyway, GUIs are not utopian wherever you go and you should just slowly adapt to something that seems like it's gonna work well and just make adjustments along the way. I am on Sway and I also am spending more and more time in Emacs since I find it novel and convenient. On Sway the mouse feels pretty damn good and convenient whenever I feel like using it although I can get away with doing anything on keyboard too. The mouse is going to be more quick and intuitive in some specific situations no matter how much you wish it wasn't, although I find having a maximum amount of achievable things on the keyboard to be important.

He could be on Linux but he has a slightly changed environment to what he's had for the past 20+ years and he probably intends to keep his productivity and his large amount of game installations the same way they are right now for convenience

And if he moved to Linux there's always caveats to GUI. I think what people should do is try to have less programs to switch between if they can help it. Less programs and ones that are optimized well for you seems like best way to do things fast and comfortably. A video editor/game mod installer might have issues reducing the amount of programs he fucks with though.

Use whatever you like. Don't identify with computer programs.

Are there any GUI Mr. Miyagi out there who can share there wisdom? How can we make the GUI better?

Literally by making it possible to make the GUI better.

Many don't know or have forgotten, but when the PARC team showed Jobs their new mouse-first GUI, Jobs carried over essentially nothing back to the Mac except for its superficial appearance, and only a pale shadow of the features left behind ever got copied back in. Preface example: I'm assuming you're using NT-Windows or Linux over OSX so it's not really relevant, but the original Alto had a mouse with three buttons, and made heavy use of combined presses and keyboard shortcuts to combinatorially explode what the mouse could do at any one time. Alan Kay had been in the audience for Englebart's NLS demo, and saw he was much more effective with his hands either on the keyboard or on a mouse *and macro pad*; the PARC team even built and used their own version to make pointing an operation that actually compared in power to what you want to do with it. The LispM was similar: with its three mouse buttons, four bucky keys, and small swarm of mode modifiers, Symbolics' electronics ebgineers could reportedly operate their in-house chip design suite both faster than any other product and almost entirely without needing to key in commands. Years later, AutoDesk for DOS would gain breakthroufh legendary status on the LispM's shoulders through letting you do the same type of commanding at a fraction of the effectiveness through the keyhole interface of the AutoLISP command line. The Mac, though? One mouse button, and intentionally as few modifiers as possible to keep the power of the machine from scaring away Jobs' target market. Microsoft and the Unixen of the time mildly improved from Apple's intentionally botched abortion, but got not even halfway to filling in Jobs' tar pit. You don't hate GUIs, you hate GUIs designed for emotional children.

But this would matter much less if Jobs had copied over any of the rest of what made the Alto worth copying, such as the actual thing PARC invented and wanted to show people: The Smalltalk-80 live object GUI model. In the Smalltalk "operating system" (technically the thing that would become Mesa was the real OS, but its job for now was just to run an optimizing disc-paging interpreter S-80 sat on top of), everything you can interact with is a live, almost-pure messaging object system, and so can be modified and improved by the user on the fly. For example, when Ingalls was showing Jobs their officework suite, Jobs commented how he didn't like the look of text selection, which at the time inverted the color of whatever block of text was selected so you got a black "hole" in the paper-like screen with white text, Ingalls spent a few seconds modifying how the selection class messaged and positioned the rectangle display class and immediately had a new behavior where the text was surrounded with a black outline, across the whole system, with no recompilation and no efficiency loss thanks to Alto's bytecode-optimized custom cpu. Smalltalk's true-object system design made it trivial to do this with any element at any time. LispMs were similar: As he wished, the user could point the Lisp Listener at any element of any data on-screen, and get back a readout of its Sexp data as it sat in memory together with hyperlinks to all of its calling source provided by the integrated debugger. After modifying it any which way, the Listener would inject itself into the links into and out of the cooresponding binaries and simulate the new behavior between the rest of the code on-the-fly, while the incremental compiler quickly and automatically replaced just what the listener needed with native-speed object code. Again, obviously from the description this applied to literally everything. Want to hose the system builtins? Get the right permissions and it's a few commands away. Want to *repair* the system builtins after a bad patch hoses them, while everything's live in memory, so it's like nothing ever happened and nothing is lost? There's war stories of lispers attaching a fresh listener and doing exactly that while the rest of the wirld thought core dumps were a valuable and innovative step forward. Point is, it's not PARC's fault Jobs hadn't seen a GUI before he went to visit them, and didn't get what made this new breed so much more notable than what came before.

If the point of a GUI is to make your work more efficient, your OS has done half a job no matter what it's like until they give the user the complete power to tailor it to upping the efficiency of your particular workflow quickly, on the fly, and reversibly/harmlessly so everyone can experiment freely. As Alan Kay describes it, when they built the Alto GUI they would do their systems work in the morning, go off to a Palo Alto garden bar and get reasonably drunk at lunch, and come back to build and A/B each other on tens to hundreds of interface modifications and prototypes until close. Later they built a whole 2000 Altos, each costing as much as a car, and a whole networked lab to run them in, to bring in crowds of people and observe how they used the system to make improvements. Not only did it work (MS Office was invented at PARC, the first standard graphics circuit builder and simulator was invented by a teenager on an Alto, half of Adobe's software suite today started as PARC systems, etc.) but it probably can't be done another way. No matter who my vendor is, they have no clue in what particular or peculuar ways I want their OS to enable me to use my hardware, so they can't hope to ensure their GUI is specific enough to enable me without also being too bloated to not get in anyone else's way, just as the user in the OP's video experienced. Far better to build it out of a system that can be efficiently modified and streamlined by everyone efficiently than continue putting everyone in the same Mac box because it's "sleek" and "standard" and "efficient". Completeness beats simplicity, and interface simplicity beats implementation simplicity.

>>11
a lisp os with chording mouse controls does sound really interesting.
I wonder if part of the reason for the aggressive move away from lispy systems to compiled systems was because it allowed corpos to more easily define their intellectual property and prevent unsanctioned modifications.
things would be murky if any lisper could start making modifications to their systems and there's no hiding anything from being cloned.
but i also see why they don't want to give that power to the avg user. a single assignment easily could cause changes that do unrestorable damage to the system. you could have different tiers of permissions to allow changes to user stuff, but not core system stuff, but there's always going to be missed things. also not really sure how networking security would look in a lispy system. it's easy enough to set up networking between systems, but that's only a closed network without malicious actors. the current internet is well over 80% of unprompted connections actively trying to fuck with you. definitely solvable but it's interesting to think about how the osi model might differ.

i need to put "look for lispy plan9 experiments" on my todo list.

I wonder if part of the reason for the aggressive move away from lispy systems to compiled systems was because it allowed corpos to more easily define their intellectual property and prevent unsanctioned modifications

Looking at the story behind Richard Stallman, the reason may be simpler. Lisp machines were just too expensive for anyone besides universities, while Unix machines weren't at that time. UNIX caught on primarily because it was a compromise. Richard Stallman created the GNU project not because he believed in UNIX, rather it had become popular and everyone was using it. Emacs vs Vi war was won by Emacs long time ago, because the processing power decreased to a point where running minimal programs written in C are no longer economically required. If you really want an actually good low-level and low processing power OS looking into Forth OSes {http://collapseos.org/}.

How >>11 mentioned, there is AutoLisp. You don't see AutoCAD people publishing the program's source code online, because you can compile Lisp. In conclusion, the reason why C and C++ reign is due to the fact UNIX took off, became the standard and spread the disease of C.