Hacker News Reader

Comment by i_am_a_peasant | Hacker News Reader

And the user interface is all OpenGL... man I can't imagine how much time it would take to write a decent user interface starting with nothing but OpenGL. Like just rendering text to the screen is a pain. And it's so snappy and responsive and it looks sooooo good. Definitely not a one man project, there's just no way.

View on HN

Rolling your own UI in openGL is very doable and can make a lot of sense for any application that will require non standard custom widgets. Use your preferred truetype rendering library to generate your text textures, blender uses freetype I think. Widgets can all be done with vectors and gradients, start with functions that create primitives such as rounded boxes or different line types and build from there.

Yeah, it's doable in a few months of doing nothing but that. ;D

But then again you may be a much more productive programmer than I.

For a side project? I could never do it, not with everything else I got going on.

Having done both web and gl ux for a living, I think you might be overestimating the complexity of a gl implementation and underestimating the complexity of meeting the same specs using a web implementation.

While not quite the same thing, if you have the time, dip your toes into some immediate mode UI, for example imgui. It is enjoyable not a grind.

Do you think wasm has any chance of replacing the whole html/css stuff with just webgpu in a canvas? I have been playing a bit around with wgpu in rust and I can compile the same project either as a native binary or a .js that just renders to the browser. It seems to work pretty cool. Photoshop seems to be runable in the browser now, and I've seen a lot of other cool stuff, but things like fluid simulations seem to still be very laggy.

> webgpu in a canvas

Internally that's what Chrome/Firefox are, they render much of html/css on the GPU using OpenGL/DirectX/Vulkan/Metal.

> Do you think wasm has any chance of replacing the whole html/css stuff with just

No, you also need the DOM to enable frameworks like React which are used by a large number of sites.

Rendering everything into a canvas will realistically mean total lack of accessibility features. Also you won't be able to use the DOM inspector. I don't think that would be an improvement at all. If one could work with the DOM via Wasm (plus source maps so you can still use the debugger) it might be something.

Oh yeah, sure my friend. You're going to implement

  * text entry (right to left as well as left to right)
  * file browser
  * treeviews that scale to 50k nodes or 10x that
  * menus

in GL in a month. Not believable.

Never did they ever say that would implement the UI of Blender (I assume that's what you were referring to) using OpenGL. I think what they meant was that implementing just a UI in OpenGL isn't as hard as the other guy thought

There’s so much more than that though. You need to build your own accessibility tree and hooks into the OS’s assistive tech infrastructure just for a start.

Is Blender accessible this way? Or is it, as they said, just an OpenGL surface with some widgets painted on?

My apologies for the word "just" doing a lot of work in that sentence.

https://devtalk.blender.org/t/blender-and-accessibility-for-...

> As a multi platform OpenGL app everything we draw is quite hidden from screen readers. Without cross-platform open source libraries available I can’t think of a feasible way of interacting with existing screen readers.

https://blender.stackexchange.com/questions/301899/blender-a...

Or you can just not do that, which is what Blender does.

To be fair, there's not all that much use in Blender for folks who cannot see a screen clearly.

Assistive tech isn’t just screen readers. But yeah, Blender specifically is a visual design tool, I’ll give you that.

I know it's not just screen readers, but what a11y concerns would make sense for blender? It barely uses audio and what it does probably can be covered by external tooling. For visuals... the only things that occur are probably covered by Blender's UI scaling/zoom. But I could easily be forgetting something or ignorant.

Edit: Oops, somehow forgot input - but there again, I would natively expect most things to work via keyboard/mouse emulation, and beyond that you'd probably need custom integration, but it's got the Python hooks to facilitate that.

What comes to mind is someone with a tremor that is unable to use classic pointing devices and might have better luck using tab/arrow-key navigation to move through the buttons/menus/etc. From my cursory examination of the product I don't see much support for keyboard navigation, though as a professional tool I'm sure there's a plethora of keyboard shortcuts that one could learn.

Good point, I'd never noticed that before - menus seem fine once you get them open, but I can't find a way to open any menu without clicking, and ex. the preferences pane does seem completely impossible to navigate via keyboard. So yes, I agree that that appears a downside to their own toolkit.

FWIW you need to implement that yourself with basically any advanced enough toolkit. Even in HTML-land, any list widget worth it's salt is handling keystrokes itself.

Though I think all/pretty much all menu items can be accessed by pressing space and then typing the name of it. (If you use the setting space for command search.) There will be an auto completion list and it remembers the last action. So that is even better than what many other GUI applications do, where you have to search for ages in deeply nested menus for the action that you know how it is named, but don't know where the hell it is hidden. Quite frankly every program should have that feature.

I have an OpenGL personal project that I'm struggling with the UI on (using QT5 currently with GLCanvas with buttons around it). If I wanted to switch to a GL-only UI (and discard QT altogether), how would I add event listeners? I can get a borderless window as a GL viewport, but I don't know how to detect clicks and match them to which GL object.

You have a click at pixel 43, so what did you draw between pixels 40 and 50? That's what they clicked. You have to know what's on the screen, but you should know this, because you put it there. Or just use dear imgui.

Well, they basically wrote their own GUI toolkit. And IMO a very good one, with tiling windows and everything is nicely scaleable. I especially like the command search with space and little things like dragging over a column of checkboxes to toggle them all.

> and little things like dragging over a column of checkboxes to toggle them all

Little touches like this make the world of difference in professional tools

If your choices are Motif or the Athena toolkit, rolling your own UI is an understandable choice.

They should roll it out in to a separate library. Call it the Blender Toolkit, or BTK.

I think there have been attempts.. but it's too deeply married to the rest of Blender for it to be worth extracting I think.

BTK has a nice ring to it -- and it's an even more brilliant public relations disaster than the name "GIMP"!

What kinds of widgets would Dennis Rader have in his "Bind, Torture, Kill" tookit? ;)

It couldn't be any worse than Motif.

BTK would also imply the existence of:

BLIMP: Blender Image Manipulation Program

Oh the humanity!

BLOME Desktop: Blender Object Model Environment

I would totally be down for that.

or...

BIOME: Blender Interactive Object Model Environment

They're actually porting everything over to Vulkan now. That, and Apple devs are also working on maintaining and developing a Metal backend.

Vulkan is a drawing API, not a GUI toolkit.

Presumably they meant porting from OpenGL to Vulkan & Metal.

I wouldn't bother with vulkan and just go with wgpu, rewrite it in rust while you're at it ;D

when the whole application is OpenGL it makes perfect sense. Just like how the interface to managing sql databases is done using SQL tables.

I hate so much how it breaks many conventions. For example, when you right click, the menu opens onPress instead of onRelease.

I wish they had at least a setting to change that.

I've not used blender but it seems to me that Chrome is doing that too (at least it's doing that on my machine )

I think it's UX that commonly works differently in consumer software vs pro software. I think parent is talking about professional software.

Pro software made for speed and efficiency, you usually want to be able to do things quickly, even if sometimes people not used to the software might screw up. Holding right-click, selecting menu item and releasing I think is one of those things.

In consumer software, users would be confused because maybe they long-press the right-click, drag the mouse a little while holding down then releasing, and the menu would just appear and disappear. Confusing UX for most users, I bet.

It looks like Chrome is doing the pro software then.

Parent said blender was opening the menu onPress, which according to your comment is OK for pro software, Chrome is also doing the menu onPress

Maybe it depends on the platform? For me, on Windows with Chrome, it only opens the context menu once you've stopped holding down the button. In Blender (on Windows), the menu opens as soon as you hold the button.

I think I've seen that on some Linux distros. But on Windows, chrome works onRelease (like all built in windows programs do)

Hum that might explain the situation here. I'm on Ubuntu with KDE

It makes it way faster when you can right click, hold, and release on the item in one smooth motion. I believe most pro software is like this, it's hardly breaking convention.

I understand why some people like it, and yes a lot of software does that as well, but in my case sometimes I accidentally end up pressing some menu option because I'm not perfectly steady. That's why I'd like it to be an option.

Did you get those the right way round? All other software I tested opens menus on button press. IIRC, Blender defaults to opening menus on button release, adding unnecessary latency and making it feel slow. You can change it, but you have to go through the whole Keymap Preferences and find every menu and change it individually, so it's annoying.

On my Windows machine, all the "native" software like the file explorer and so on, opens when releasing the right click. Blender 3.6 opens as soon as you press the right click (allowing you to "drag" the cursor to the menu option and releasing it there)

That's the traditional Mac way. e.g. historically you would "pull down" on the menu bar at the top of the screen. You would click and hold, and slide the mouse down, releasing the button to choose an item. If you were to just click on a menu, it would quickly open and close again. I want to say it's typical for Linux desktop environments to open contest menus on mouse down, as well, but don't recall offhand.

Blender dates back to 1994, when many modern conventions weren't really a thing yet (Windows 95 didn't even exist)...and they have put a lot of time into modernizations in recent years. Back when I was dabbling in Blender, in the early 2000s, Ctrl+S was the keyboard shortcut for "erase everything and create a new scene."

Reply on news.ycombinator.com