Hoping we get a reguler evdev driver like hid-steam did for the original one

Either the UI is defined in some DSL, that’s loaded (or compiled) and then you spend most of the time writing getElement(pathToElement) and wiring it up, or you have to boilerplate create each element and parent.addChild(element).

Im saying “there are no elements” because of what OP says here, the system i’m using now doesn’t have that.

You have a panel+border+text “primitive” drawing functions. Nothing is stopping you from creating a single function that calls all 3 of those. You probably should, since it’s probably a common pattern. You could call it DrawBoxedText. There is no difference between a DrawBoxedText function and a BoxedText element with a draw() method.

yeah i could make a function for that, but i would argue that “here is no difference between a DrawBoxedText function and a BoxedText element with a draw() method.” there is a big difference between these. Personally i find using a function like DrawBoxedText much easier.

I had my own library for UI that tried to have a element model, but it was bloated and didn’t scale well. Now im drawing everything via vulkan compute shaders and its fast and looks great.

I think the philosophy needs to switch from elements back to pixels, atleast that is what worked for me.

i dare to say its as easy as webdev

snippet from my game:

DrawMenuButton(buf, btnExit, "Exit to title", exitHover, exitHover && window.mouseLeftHeld, false, font, topFontPx, exitCol);
DrawMenuButton(buf, btnSave, "Save changes", saveHover, saveHover && window.mouseLeftHeld, false, font, topFontPx, saveCol);
PushPanel(buf, titleRect, panelBgColor, 6.0f * s);
PushBorder(buf, titleRect, borderColor, 6.0f * s, 1.5f * s);
DrawText(buf, "OPTIONS", titleRect.x + titleRect.w * 0.5f, titleRect.y + titleRect.h * 0.5f + topFontPx * 0.32f, font, topFontPx, textUnfocusedColor, TextAlign::Center);

this is in the draw function, and along with the other code produces this menu:

I’m running 2x4090, the 35B fits very comfortable in that.

For large models like the 397B without a ton of money there are several ways, ive seen posts of people using arrays of used 3090s with good results.

The other option is CPU inference although with current RAM prices that is less cost effective.

I was looking at maybe an array of Milk-V JUPITER2 since vllm added riscv support which could be very cost effective.

Depending what OP was using before but going from something like GPT5.2 to LLama 3 8B will be a massive difference (Although OP says to use it only for basic tasks so that does offset it)

LLama 3 already being a very old model doesn’t help either

I run Qwen3.5-35B-A3B-AWQ-4bit which while leagues ahead of LLama 3 8B still is a very noticeable difference.

This is not to say open source is bad, if one had the resources to run something like Qwen3.5-397B-A17B it would also be up there.

Losing a vital plane now when you are at war then it doesn’t really matter if it might get replaced sometime far in the future

You don’t have to be a tankie or a wankie to recognize the fact that a loss ratio of 0% is very good for an aircraft.

If it was a Russian or Chinese aircraft doing this then that would also be a fact.

It’s stupid to say that a single aircraft being damaged makes the entire type worthless like many here are saying when the F-35 is the only aircraft flying these missions and come back with only damage to a single plane.

That is not a political statement or approval of the strikes. That’s just a statement on the plane.

For the all the probably hundreds of sorties flown with a result of zero losses and only a single aircraft being damaged they might aswell be invisible.