Tired: Forking #GIMP because the name is bad.
Wired: Forking GIMP to keep it GTK2, or somehow (lol) switch it over to a sane UI toolkit, like Qt... or WxWindows... or Tk... or XForms... or QuickBasic... or a flipping Abacus.

Any takers? 🤣

Addendum:
Inspired: Saying 'Eff this' and just using KolourPaint... or a pen and a napkin 😂

@rl_dane Dream big: Curses!

@RootMoose

lol, I did mention QuikBasic's groovy TUI kit (which, sorry, not sorry, is better than 99% of the *nix TUIs I've used 😆)

@rl_dane @RootMoose IMGUI or bust.

@jens @RootMoose

Hadn't heard of that. What use[sd] it?

@rl_dane @RootMoose Oh, it's a partially shitpost remark. The IM in it stands for "immediate mode", so you write stuff like:

if (button(...)) {
// handle button press
}

It's mostly used in games, I think.

I don't love it, but find it refreshingly different.

GitHub - ocornut/imgui: Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies

Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies - ocornut/imgui

GitHub
@rl_dane I tried learning GTK once... once.

@bryanredeagle

Heh, I got the book on it circa 2001.

I got as far as "Here's how we fake OOP in plain C...." 🤣

@rl_dane An abacus has significant design advantages over #libadwaita so long as the theme is joined with the TK :')

By theme, I'm talking about basic things like widget sizes, basic background/foreground color selections, and disabling #ClientSideDecorations . I understand developers' frustration with full custom CSS, but missing these things is sad.

#GNOME #theming

@golemwire

I'm just saying let's reset everything to what it was in 2009. UI was bloody perfect then.

Ok, start menus sucked, but we had launchers for the adventurous. It was a totally usable system!!

@rl_dane If I wanted to make an OS, what would you think I should use as a basis for a UI?
Do you have a link to an emulator of your favorite OS, UI-wise? I know there's that one Mac OS X system you harp on, but that's probably a bit complicated.
Every time I spend some time playing around with #ClassicMacOS , I end up refreshed (thanks for the System 1.0 link above). Elegant.

@golemwire

Yeah, Macintosh System 7.1 or so is pretty peak #UI.

You can also spin up a VM for, let's say, Ubuntu 10.04 pretty easily. Whatever was the last Gnome 2.x Ubuntu release.

Also, some distros and probably BSDs have #TDE, the #TrinityDesktopEnvironment, which is based on KDE 3.x, I believe.

You could also just try Mate, but I actually prefer old Gnome 2 to Mate in side-by-side comparisons.

@rl_dane

(meanwhile Debian is trying to drop GTK2)

@cerement

They've been fully fifth-columned by corporotailchasers, it seems.

@rl_dane I have genuinely been tempted to write a full software suite in TCL-TK, including media players, converters, and editors
@rl_dane The really hard part is, I'm a total idiot when it comes to things like video codecs, so this software suite is gonna have a lot of dependencies, and I _hate_ dependencies :P

@OpenComputeDesign

Here's some inspiration:

Go here and run this emulator in yon web browser:

https://infinitemac.org/1984/System%201.0

Click on the little apple menu on the top left, then try each and every option under that.

And write one tool each to replicate all of those options (the about box and the 8 "Desk Accessories").

Well, don't try to replicate Monkey, that's just a test program to try to make the OS crash.

Infinite Mac

A classic Mac loaded with everything you'd want.

@OpenComputeDesign @rl_dane
isn't there already a desktop environment where all the accessory applications are written in interpreted languages?
Only one I know of is Sugar, the OLPC thing.

speaking of interpreted languages, I have a burning question about them:
https://fe.disroot.org/notice/B51XicnDWO8ERigguu

(basically want to develop videogames in a way that allows me to adjust movement speed and damage output in the middle of a playtest)
Moses Izumi (@[email protected])

#askfedi What are the best programming languages to learn if I wish to modify an application while it's running? Would be incredibly useful in game development (i.e fine-tuning the speed/size/mass...

@moses_izumi @OpenComputeDesign

#uxn would be a trip ;)

But yeah, the recommendation of Lua with something like Löve2D would probably be a great starting place.

@moses_izumi @rl_dane

I'd probably also recommend Love2D. Tcl-Tk is really not designed for video games (says the guy who refuses to use anything else for game development)

I generally prefer compiled languages in principle. But, most compilers, and all graphics toolkits for compiled languages, absolutely suck vastly beyond any possible reasonable degree.

And besides, as long as you're only like one or two abstractions deep, you're still better off than most modern stuff :P

@OpenComputeDesign @rl_dane
on that note: it always irked me how ZDoom reimplemented all of Doom's game logic in an interpreted language (Decorate/ZScript) to make it more extensible, but never exposed a way of editing things at runtime.

not to mention all the mods that leveraged the compiled language ACS (invented for Hexen) for various features that ZScript hadn't incorporated.
Let me share with you a magical function known as dlopen!

That's how I'd hot swap stuff in a video game. Unload the old module, load the new one, update all references to it, and boom. New game!

That being said, movement speed and damage output should be variables, which you can just increment or decrement without changing the code... like if(key.tweak && key.M && key.plus) { ++target->movement.speed; } or something.

CC: @[email protected] @[email protected]
Oh, I should add... language transition boundaries are Hell. Before you add a "scripting" language to your game, be very aware that something WILL go wrong in the transition. The parent language can't tell what the fuck the interpreter is doing, while the interpreter hasn't a clue what the parent is getting up to. You will be examining ridiculously complicated binary structures, syntax trees, and synchronization states. That's what ultimately put me off of python. I'd make a call in C, in python, and it would just randomly segfault once an hour or so. No way to debug it without unwinding the whole python interpreter and figuring out what in its internal state is getting corrupted.

CC: @[email protected] @[email protected] @[email protected]
@rl_dane Why not GTK4?

@steeph

I'm guessing it's worse than GTK3, even more gnomisms.

@rl_dane You know what GTK stands for, right? 😂

@Aradayn

lol, yes, that's why I was laughing at myself 😁

@rl_dane Well, the original Motif version of GIMP is still there, just needs a few decades of updates ;)

@mhd

I had no idea Gimp was originally based on Motif. That would be amazing to see!!

@rl_dane I think it was version 0.54 that was Motif, and sometimes after that they changed due to it still being proprietary at the time (I think you had to download a statically linked binary).

I never quite understood why they didn't base their new version on Xt, too, instead of also re-inventing that layer with glib/gobject. But well, these days they probably would invent another language to go along with it ;)

@mhd

I mean, GTK1 was pretty dang nifty at the time. It wasn't a crime to reinvent the wheel when most of the preexisting wheels were kinda wobbly. ;)

I think we love stuff like Motif because it's like a metonym for a sane era of UI design. But there were probably nicer options at the time, or soon after.

@rl_dane All wheels are wobbly, to be honest. And heck, I'm as guilty as the next guy when it comes to reinventing GUI details. In the beginning, Qt was missing some common controls (I think it was things like tabs and comboboxes), and thus the "Linux Widget Project" was born, and then we all went "C++ isn't the optimal OO language, and we can learn so much from NeXtStep/Taligent/OpenDoc etc", rebranded to the "Linux Interface Project"… and quickly succumbed to death by scope creep. At least the GIMP people delivered.

And not having Xt also meant not having the mandatory "X" in there, so porting was assumed to be easier. But I still sometimes picture an era where Xt and its resources would be the common ground, and we'd get a good selection of widget kits you can pick from (or even combine).

As for "sane", I've seen too many Motif 1/Qt/Tk applications where the lack of proper mid-90s widgets lead to some rather interesting design choices…

@mhd

I'm sad that we don't have toolkit-agnostic graphics primitives.

That could have absolutely been a thing.

Now the Wayland sessions are just schlepping pixels from the desktop of choice, and X11... is schlepping pixels painfully.

Bare X GUIs weren't pretty, but dang, they were efficient. :P

And as fugly as the Athena widgets were, they were... well... functional, in a "ooo, look at this alternative operating system GUI from a bizarre parallel-universe version of the 1980s!!!" kind of way. 😅

@rl_dane I think we had and have lots of agnostic chunks, they're just combined in ever-changing ways, with gaps at different places. If you had something like the Athena widgets, Motif or OOLIT, you had the Xlib/Xt foundation, so only the top of your software stack changed.

These days things are distributed over many platforms, so the "chunky" bits seem more in the middle, like OpenGL for drawing/blitting or Harfbuzz for fonts. Maybe XML or CSS of some kind for layout…

So it's not like the wheel is reinvented top to bottom. Sadly, that doesn't seem true for the actual things that reach the user, where mystery meat widgets are a joy to behold and you never know what surprises you get when you touch something with a rounded border.

@mhd

The mystery-meat toggles are especially fun.

"The button says 'HIGH RADIATION.' Does that mean that we're currently experiencing high radiation, and I should press it to somehow shield us from radiation, or will pressing the button instantly kill us all?!?!??"

This was FIXED and working perfectly in 1984, ye flipping philistines.