But the worst part is all code snippets are followed by an image which is not related to the code snippet. It's not what you get by typing the code... it's something completely different.
I remember someone once created a GitHub issue requesting I turn the README into some verbose technical thing with full API docs and a bunch of people replied saying they greatly preferred the "pitch + high-level examples" style.
To the project maintainer: don’t ask people to read a terrible AI generated sales pitch novella that quantifies your AI generated port against every UI framework out there.
Here’s the obvious giveaways:
“ 4. The many ways in” “ Python, four ways”
“ tkinter: all 7,846 public names of tkinter and ttk. Nine real programs behave identically on the standard library and on BUI.”
“ Rust: the web platform, natively”
Ugh it’s excruciating. You’re better off with a readme that shows a few screenshots and installation instructions.
"Blender's user interface, as a library you can use from Python, Rust, JavaScript (React, Svelte), C, C++ and Dear ImGui."
This tells me a huge amount of what I need to know, if I'm interested in this project or not.
Compare it to another very recent example posted on hn: https://github.com/rivet-dev/rivet - You need to get some way down the page until it discloses what you might be able to do with the project. https://github.com/rivet-dev/rivet#use-cases
But by that stage, even though it isn't very far down the page, I'm already checked out.
We also have a discord server, lmk if you're planning on using BUI!
And I do appreciate the effort that goes into it, especially in the latest versions as it got much better,
But I really really really REALLY don't want that UI in anything else other than Blender.
Please don't.
If you're already using Blender to make assets, there's some benefit to stuffing Blender's UI into your game editor too.
Not in an age of AI.
I mean if you want to code all this stuff by hand, I get it. But that's a choice. And since it's a choice that means shoehorning a Blender UI into a "bargain-basement game editor" (and having a "bargain basement game editor) isnt really needed. You absolutely don't need to spend a lot of time arranging UI stuff.
Game tooling is pretty trivial now and it's not user-facing. Again, I fully understand why someone would want to do this themselves still but let's not pretend thats not a choice at this point.
I have used 3Ds max, maya, lightwave, cinema4D, milkshape, wings, Houdini, unreal engine 1 - 5, Hammer, Threejs editor and probably more. The Blender UI is worse than all of the above.
You've given quite a list of tools with different purpose.
For 3D work I would personally rate
Modo 3D, Zbrush > Blender, Houdini > Softimage XSI > Maya > space intentionally left empty :P > 3Ds max
Blender UI looks very nice and is very customizable. I think it's "ok" in beginner discoverability (none of 3D softs is great at that really) but when you get experienced with it it's one of the best.
I really like how they managed to keep all the tools and views pretty consistent given how many things you can do in it. Whether you are working on objects, vertices, nodes, movie clips you get the same shortcuts where possible.
Maybe some of them do, but even though I disliked the UI at first, I've come to appreciate it as I've learned it. It's simply different from most other software, so that obviously causes friction. However, I think once you learn it, it's quite a good system. There's a tradeoff between optimizing for familiarity/new users, and providing an optimized experience for advanced users.
Blender does a LOT of stuff. Its not an easy product to create an UI for. But I think the problem is much bigger when coming from a different 3D package than when learning from scratch.
My teenage kids use Blender as the first 3D package they've ever learned. I was impressed with how quickly they ramped up through videos and learning from each other.
My baby duck fingers could probably pick up LightWave 3D again in an hour or two. I could never gel with Blender.
A lot of people go "Blender UI was horrible, but they redesigned the whole thing and now it is good" Having used blender in a minor role for 20 years(i think I started on 1.7), I think this was just a big psyop by the blender team. Sort of how the client goes "Change things" and you change nothing, wait a day, and tell the client "I made the changes you requested" client: "I love it"
I am not saying the blender team has not made substantial improvements to the UI over the years, but the core is still that same quick blender workflow, This is very different from the normal clunky GUI design of 3d modelers of the era and as such blender got a reputation for having a weird UI which was easily translated to blender having a bad UI. So what do you do when you have an unwarranted bad reputation? Especially now that the rest of the world has caught up and is using your flows and they are not so weird anymore. Make a dark mode and put out a big press release "we redesigned everything, it's good now" so people will try it.
> Baby duck syndrome is a cognitive bias where people automatically prefer the first system, interface, or product they learn to use, judging all later versions or alternatives by how well they match that initial experience.
That's actually extremely common in scientific (GUI) software. And in any professional setting I guess.
I don't think that qualifies. There's an important distinction to be made between an aesthetic preference versus a professional not appreciating a tool being mucked with. Anything that interferes with my workflow without immediately providing substantial benefit is something that's actively harmful. In fact even if it does hypothetically provide huge benefits I still might not want to deal with it right this second.
So if it's for an employer it's rational but if you're making the same choice for yourself it isn't? If one of those is baby duck syndrome they all are.
As in, that people who refuse change in their play activity are in some way different (less rational? more "syndromatic"?) than those who refuse change in their breadwinning activity.
I see the distinction, but am not sure I agree. It's just a neurotype spectrum of the same phenomenon. Baby duck is baby duck
It is actually a miracle that it is as good as it is considering other open source graphics programs like GIMP are horrendous to use.
I absolutely detest it (TBF I haven't used it for the past ~2 years) but I also recognize that it's an incredibly difficult problem space that lacks an obviously good solution, the tool itself is inherently and irreducibly complex, it's a free project with extremely limited resources, it's been consistently improving over time, etc, etc.
Fundamentally all 3d modelers have inherent degree of complexity. The ones that give a "simple" facade with fewer options make other things harder or having to look into obscure places.
All of that are beside the point however: people will use this as a GUI library, not as a Blender's UX design.
It is not a UI paradigm that you would use for just anything, but for certain poweruser software it is one of the best paradigms I have seen, especially since they managed to get rid of 90% of the rough corners in the past decade of development.
But a good design system does the trick. Artcraft apps use this library and their Adobe clones come very close to the original apps.
Q: “Whats wrong with tkinter?!?!”
A: It sucks, that’s what!
That UI is fine to be on many more places than Blender, given that many libraries people use are way worse. Imgui for one example.
Yeah you can do that. If you have low standards and don't need control of the details.
I do hate vibe coding. So I took a different approach for BUI.
Instead of asking the agent to decouple the UI, I asked it to remove all the parts which isn't a part of UI logic.
Turns out AI is pretty good at removing than generating.
Median update+build time per frame (ms), lower is better
Machine: macOS 26 VM, Apple M4 (virtual)
benchmark (ms) Dioxus Iced egui Slint GPUI
create 1k 12.91 17.57 10.66 26.99 22.32
replace 1k 14.46 14.48 7.48 17.07 17.41
update every 10th 2.12 1.94 4.17 5.55 10.65
select row 1.16 0.37 3.50 6.62 10.68
swap rows 1.45 0.42 3.53 4.10 10.26
remove row 1.32 0.39 3.27 4.46 11.95
create 10k 124.97 152.52 58.97 136.07 164.58
append 1k to 10k 28.12 157.67 33.01 69.93 117.70
clear 1k 3.00 0.86 0.07 4.60 0.04
scroll frame 0.28 0.10 0.55 4.23 3.79
These are CPU-only times for the state management / style / layout / etc, but don't include rasterization (additional work in the benchmark harness required to measure GPU time sensibly), probably aren't fully apples-to-apples, and could probably do with testing some more complex layouts.
The main thing GPUI has going for it is mind share and that's a great thing to have. The mind share is unfortunately highly fragmented though as the original authors are not interested in selling a GUI library. Hopefully the community efforts will come together to produce a more polished and general library. A well used library is better than a better designed one maintained by a single person.
It’d be like naming my http library HTTP.
And it’s why Dear IMGUI isn’t just named “IMGUI”.
When they tried to jump on newer trends they made them all monochrome, and they don't have distinctive sillouettes so it's just completely inscrutable. That Inkscape screenshot is horrible. I count 129 icons.
And yet they still devote so much space to their bizarre colour palette, which is huge but still manages to omit most of the gamut? It's the kind of design that really only comes from decades of OSS development.
[0]: https://gradia.alexandervanhee.be/ [1]: https://www.pinta-project.com/ [2]: https://krita.org/en/
I’d be interested to know what you think about it
Was recently trying to learn a desktop toolkit again and was disappointed that the docs of pygtk and rust/iced end around page three. Many projects, little follow up. Probably should pick a toolkit from the 90s instead.
This seems different. Also, tabs that look like tabs! Love it.
Check out the docs here: https://bui.preetham.top/
Especially since v2 and v3 have vastly different consequences.
Also speaking of FastAPI, have you checked out FastRAPI?
GPL makes sense for applications like Blender. For a general purpose library, it's a dealbreaker.
But that wouldn't work for a straight derivative of a GPL project.
It's time to do it! Also we have a discord, if you end up reviving it, do share it over here:
> The drawing code is a C port of Blender's own widget code
How can we guarantee BUI is still performant?
I hope someone else uses this for a new Linux distro.
I'm an EGUI fanboy, but am looking to truly compare it to other things, especially non-immediate mode. I have no gripes with EGUI, other than it seems to create an application size floor, and I suspect memory use could be better. It has never blocked me, including for complex applications with GPU rendering etc.
Blender is peak OSS. I'm in! Will give this a shot for my next limited-scope application. I'm also experimenting with GPUUI.
I will try Slint if I ever do embedded with a full GUI.
I will poke at this, because I saw the same sentiment in a HN thread yesterday: >" You write Rust or React and want a native desktop UI without shipping a browser." You don't need to ship a browser to do GUIs in rust. Some people do, and justify it through comparisons to Electron (Tauri) - I suspect this is a pushback against that?
Another thing I will poke at from comments: If you're going to dismiss this as a non-native UI and therefor inferior: Post specifically what features your OS-native toolkit or OS conventions have that won't work here. (Is it hotkeys, color scheme, a Je-ne-sais quoi? What OS specifically? My pet theory is these are all MacOS users, but I'm not sure)
But, if I did not invest last two years into my own toolkit, I'd definitively consider.
Direct3D is at version 12 on Windows[1].
What tech on macOS? OpenGL?
But what is actually in that project? All of those things? Just a C runtime? Why not talk about what the barebones C runtime gives you first (memory, runtime), then add whatever layer on top? Or is it all-in-one always?
I think I will keep going with my own efforts, but this looks nice!
We also have a kotlin binding support coming soon, btw!
Swapping it for UI that's as battle tested as Blender might improve things.
GPUI and Makepad are the two Rust UI frameworks that seem the most interesting for what I'm looking for in a UI framework (hybrid immediate/retained mode, self-drawn widgets, open source).
>The repository is built entirely using LLMs, with no human-written code. ...
I’ve not once thought “Man, those widgets are slow!”
Do Maya and others have better UIs? Honestly, I find them more repulsive than Blender's
Just because you can...
Who is "we," and what's the long term plan?
It's a shiny presentation, but I don't see anything on offer more than a solo dev who pointed AI at the Blender codebase. I could do that myself, and many of the reasons I don't do that apply directly to why I'd never use this project.
I think the GitHub readme and the docs site are dishonestly presenting the state of the project.
> The repository is built entirely using LLMs, with no human-written code. The drawing and interaction code is ported from Blender's sources, and the behavior is checked by tests: C, Python, Rust and JavaScript suites, the tkinter side-by-side programs and the GPU parity test.
...wasn't it?
Is it retained mode UI?
I just tried few very standard operations that every Blender user knows:
1) Drag vertically across multiple number inputs to enter multiedit mode - failed (even though main page advertises this: "Drag down across X, Y and Z to edit all three at once")
2) Hover on field, press Ctrl+C, hover on another field - press Ctrl+V - failed
3) Press shift while dragging - it glitched
4) Scale UI - failed
5) Collapse collapsible block - failed
6) Right click - reset to default - failed
7) Jump to next field with Tab (while editing) - failed
8) Automatic alt accelerators - failed
9) Tooltips - N/A
10) AI slop: funny cursors, focus outline
So basically it is more like styled imgui (less polished than Blender), rather than Blender's UI.
I'm not saying that it is impossible to do a honest implementation, but one needs to kick agent much more to prevent cheating, and actually know how Blender UI works.
It works perfectly on my machine, and another friend's machine. Just to be sure, which demo did you try? the website or python or rust?
Probably it works in other implementations (I did not try); in web it produces <input type="text"> and agent likely gave up trying to simulate such details there.
Let me update the web samples. Thank you!
I don't think we can use LGPL since we were derived from Blender's Source code, which is GPL.
A quarter-century ago, yes. If they haven't migrated to native widgets in 25 years, that might be an indicator of something
But the premise is silly: if Linux has two native toolkits, how is this a sensible recommendation?? Hint: it isn’t, because GTK/Qt are not the native, but rather simply the most used.
Also, go to Mac, and SwiftUI still doesn’t support all that AppKit used to, leaving an incentive for developers to deviate from the platform’s recommendation.
And back to Windows, WinUI still doesn’t fully replace Win32 or Windows Forms, so same conclusion applies.
I’m going to hazard the claim that in probably most people’s conception of the term, GTK is native in GNOME, Cinnamon, Xfce, etc. and Qt is native in KDE, LXQt and Sailfish OS.