Live data from Hacker News

Egui – An immediate mode GUI written in Rust

egui.rs

121–130 of 143 posts

Re: Egui – An immediate mode GUI written in Rust

#121

Earlier quoted context omitted.

Just click on the link and you can easily see it only redraws when something on the screen changes. It's amazing how quickly people will dismiss something these days based on their own made up reasons.

The poster above me explained to me that it's not like that?

Click the link, open the backend tab, and look where it says "Only running UI code when there are animations or input."

Then you won't have to waste cycles deciding which random internet comment from a stranger to believe

Re: Egui – An immediate mode GUI written in Rust

#122
post #79

Earlier quoted context omitted.

> You generally can't copy text in native UIs You mean mobile apps, right? With desktop UIs this has traditionally never been an issue.

Desktop UIs only started adding that around 2000 or so (Gtk2?), it generally hadn't been possible before in the Windows/Linux world. Even today it still doesn't work as well as the Web, as the select ability is limited to a single widget, e.g. you can't copy&paste the complete text of the About box in Gimp in a single go and many other widget with text don't allow text selection at all. That said, even on the Web it…

Ah, I misunderstood! You are absolutely right.

Re: Egui – An immediate mode GUI written in Rust

#124

Earlier quoted context omitted.

I'm not sure. Phones and Macs are already all high density enough. Apparently it's been removed on Mac. Probably not too long before even cheap windows laptops and Chromebooks have hidpi screens. Plus modern displays can have all sorts of weird subpixel layouts so it's not as simple as it used to be.

Even if you are using Retina 5k 27", the subpixel rendering is still necessary to get sharper fonts.

Apple dropped support for sub pixel rendering in MacOS years ago.

Re: Egui – An immediate mode GUI written in Rust

#125
post #99
post #60

I'm afraid that until browsers provide APIs to help render fonts with sub-pixel rendering (note: that would add fingerprinting bits), canvas-based UI rendering libraries will always have a big disadvantage (vs DOM-based) on all but the high pixel density devices. (This is well known by the egui authors, which is a great library!)

Why would that add fingerprint bits if everybody uses the same algorithm to render this?

The correct subpixel rendering depends on your monitor's pixel layout.

Re: Egui – An immediate mode GUI written in Rust

#126

Earlier quoted context omitted.

I’m a software developer, and it seems like a positive to me? Why wouldn’t you want the ability to post-facto manipulate with script the interfaces you are presented with?

Because if I added ads to my application, I want those ads to be shown to user, so I can have my money.

I think this we’ve discovered the inflection point between the traditional hackers and the SV growth hackers that HN tries to court both of.

Re: Egui – An immediate mode GUI written in Rust

#127
Cool, but the input response is super slow. Like, when I’m typing fast on my phone (yeah, I’m that crazy Gen-Z who types a thousand words per minute on mobile), it just can’t keep up. Instead of ‘This is a test,’ I got ‘his i aes.’ It’s probably an architectural bottleneck that’s hard to fix. Also, I noticed you can’t select and copy text, which is a major headache for custom GUI implementation. Happy holidays and good vibes to everyone!

Re: Egui – An immediate mode GUI written in Rust

#128
post #60

I'm afraid that until browsers provide APIs to help render fonts with sub-pixel rendering (note: that would add fingerprinting bits), canvas-based UI rendering libraries will always have a big disadvantage (vs DOM-based) on all but the high pixel density devices. (This is well known by the egui authors, which is a great library!)

I'm not sure. Phones and Macs are already all high density enough. Apparently it's been removed on Mac. Probably not too long before even cheap windows laptops and Chromebooks have hidpi screens. Plus modern displays can have all sorts of weird subpixel layouts so it's not as simple as it used to be.

You tend to use the web platform for maximum portability, even for people not having high-end devices. If you only need to target people with a higher-density screen, then of course my comment is moot. I posit that it will still be a problem for large enough number of people, for a long time.

Re: Egui – An immediate mode GUI written in Rust

#129
post #54

Earlier quoted context omitted.

Selecting text can be useful, but it can also become its own usability problem. I recently created a touch interface using a websocket/browser based stack and one of the problem was that users kept selecting the text on buttons because they expected some action while holding the button.

https://caniuse.com/user-select-none + pointer-events + touch-action : )

This is what I used

Re: Egui – An immediate mode GUI written in Rust

#130
post #91
post #58

> panicked at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/glow-0.16.0/src/web_sys.rs:282:78: called `Option::unwrap()` on a `None` value Someone's been naughty for Christmas, forcing option unwrapping instead of pattern matching. On the mobile version of Brave.

At the very least, one should use `expect` over `unwrap` so the error is useful.

I just opened https://github.com/grovesNL/glow/pull/331 to do exactly that.
Post reply on HN