Hacker News Reader

Comment by rabf | Hacker News Reader

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.

View on HN

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

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.

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.

Reply on news.ycombinator.com