The end of the nice GTK button • Hacker News Board

Re: The end of the nice GTK button

#581

Post by copperx » Fri, Mar 25, 2022, 4:49 PM UTC

mjevans wrote: post #333

lelanthran wrote: post #320

Earlier quoted context omitted.

> And there are a lot of behaviors that are not functioning well. The worst of which are dropdowns, lists or menus that inserts new items right over where your mouse is so that you accidentally click on the wrong thing. All browsers do this for the dropdown that appears when typing in the URL bar. I type a few letters, see the site I want is 3 down in the dropdown, hit the down arrow three times and press enter, only…

That is the worst thing. Updating a UI while the user is interacting with it. Everything that reaches the screen should remain FIXED in place unless moved //by the user//. This might happen E.G. because something was loading and now gets a resize event; so some list suddenly changes the position of everything rather than force the user to click something else to resize the misbehaving entry. (Scrolling could also do…

I estimate I have about 100 daily counts of frustration because of elements moving while I'm interacting with the UI. It drives me crazy, and I assume it drives younger people even crazier because they have quicker reaction times.

It's a disgrace that modern UIs haven't dealt with this.

I had high hopes for Windows Phone because it was the only mobile OS that had a realtime UI. I don't care how long an operation takes. Just give me immediate feedback! And respond to my input as if it was mission critical. Why is it so hard?

Re: The end of the nice GTK button

#582

Post by pessimizer » Fri, Mar 25, 2022, 4:50 PM UTC

pornel wrote: post #541

j1elo wrote: post #156

> I feel like the designers of this new theme have never sit down with anyone who's not a "techie" to explain to them how to use a computer. The designers of this new "everything is flat and devoid of visual hinting" trends are maybe, at most, enthusiast, but not professional designers. I don't mean professional in the "hired for work" sense, but in the "really has the knowledge and has studied the psychology behind…

macOS has the same problem: everything is flat. There are no borders around many buttons. It's hard to tell what is a label and what is a button, or which controls are disabled, and which are merely de-emphasized. Apple used to be held as the pinnacle of design, but what does it say when their latest UI is indistinguishable from an amateur design?

Apple marketed itself as the pinnacle of design.

Re: The end of the nice GTK button

#583

Post by formerly_proven » Fri, Mar 25, 2022, 4:51 PM UTC

the_pwner224 wrote: post #563

NovemberWhiskey wrote: post #553

Earlier quoted context omitted.

> As an aside, I find it amusing that more latency is introduced by a USB keyboard than existed in an entire 80's computer Uh what?

Most normal keyboards, mice, and USB HIDs report events at a rate of 125 hz == 8 ms between reports. Gaming mice usually go up to 1000 Hz / 1ms, the wireless ones usually let you configure down to 500/250/125 Hz if you want a bit more battery life. I'm sure that gaming keyboards also have a high refresh rate. If you have a 144 Hz monitor that actually means your (normal) keyboard and mice are reporting events less of…

A lot of gaming hardware is trash. 1000 Hz on the package, endless latency inside, buggy firmware, buggier and resource-hogging companion apps, which are always Windows-only, and there are still even "gaming keyboards" which are 2KRO, bad materials and so on

That being said pretty much any 1000 Hz mouse is better than any 125 Hz mouse when using high refresh rates because the discrepancy between the 125 Hz mouse poll rate and the 120 or 144 Hz display causes very noticeable jitter. If you have a mouse where the poll rate can be adjusted, this can be easily A/B tested; it's quite visible in high-framerate recordings as well (this can be done in OBS by using the fractional frame rate selector and just inputting 144:1).

Re: The end of the nice GTK button

#584

Post by kirbyfan64sos » Fri, Mar 25, 2022, 4:54 PM UTC

smoldesu wrote: post #237

kirbyfan64sos wrote: post #227

Earlier quoted context omitted.

This is an unfortunately very common misconception: you can still set GTK_THEME on libadwaita apps, it's only the gsettings configuration that doesn't work (due to implementation constraints, unfortunately).

I've tried that, and besides it being a highly inconvenient workaround, it doesn't work on any of my machines.

That's...strange, I just had it successfully tested yesterday. Are you actually testing with a GTK4-compatible theme?

Re: The end of the nice GTK button

#585

Post by jchw » Fri, Mar 25, 2022, 4:54 PM UTC

jcelerier wrote: post #570

jchw wrote: post #566

Earlier quoted context omitted.

Honestly, I regret arguing on this point. There’s no reason for me to continue on it, since it has nothing to do with what I was really trying to discuss about X11 apps. Still, 8 MiB/s is a shit ton of data, and given that it is screen data I’m sure it would zlib compress very well. Is it shipping the whole app as one pixmap? I am not really making that claim, though I actually thought they dropped XRender based QPai…

> Still, 8 MiB/s is a shit ton of data, it is minuscule , and it is the peak I managed to get when moving as fast as possible. At the same refresh rate, blitting, say, 1024x1024 pixmaps would yield 576MiB/s so here we are talking about 72 times less. And it's while running a moderately image-heavy app with most likely room for optimization. One I often use is pavucontrol-qt: this one gives me less than 1MiB/s of netw…

> it is minuscule, and it is the peak I managed to get when moving as fast as possible. At the same refresh rate, blitting, say, 1024x1024 pixmaps would yield 576MiB/s so here we are talking about 72 times less.

If 70% of the pixels are the same shade of gray, that’s not impressive at all. If you are serializing image data and storing it over the network, you can do better than uncompressed with virtually no CPU load increase. Even moreso if you’re doing multiple correlated frames.

> when I set Xft.dpi to 144 on my machine and run the same thing over ssh I see this: https://i.imgur.com/JQhEcvG.png icons are scaled, images are scaled, text is scaled... what is missing ?

Nothing.

That scaling is done by Qt, and has all of the aforementioned issues with regards to scale factor. That’s why we’re talking about X11; there is no “X11” way of handling scaling. X11 clients are responsible to scale things. Even events do not get their coordinate spaces scaled, either.

The point of this thread is not that you can’t scale UIs. It is that GTK+4 looks bad on low DPI monitors because it has stopped attempting to do pixel perfect UI and instead uses truly scalable layout and rendering. In the truly scalable world, 96 DPI is as blurry as 200+, only you don’t see it when there are more pixels.

That said, Qt has plenty of UI scaling bugs.

> Also, regarding zlib: I took a screenshot of this window and compressed it as png (which uses zlib if I'm not mistaken ?) which gives me 137KiB, or 19MiB at 144fps. So more than twice as much as what X11 manages (and that is raw X11, IIRC there are X11 protocol extensions which also pass the X11 messages through gz, but I've never felt the need for that as things are already perfectly fast).

Yeah, because even raw X11 with pixmaps won’t redraw the whole screen at once. It will use dirty rects. When scrolling this could still be a substantial amount of data, but nonetheless.

As I suspected, as far as I can ascertain, it really is just shipping pixmaps. 8 MiB/s sounds very consistent with what bug reports are saying;

https://bugreports.qt.io/plugins/servlet/mobile#issue/QTBUG-...

This was changed in Qt 4.8, exactly like I remember it. But what I didn’t know was that XRender rendering was reintroduced in 5.10, because of this exact problem.

(Just to be clear, that means you get efficient SSH for most Qt apps, which have native mode enabled, from Qt 4.0 to 4.8, then 5.10 onward. A substantial slice of history to be sure, but more limited than it seems people think.)

If you’re on 5.10+, you should be able to get dramatically better performance with `-graphicssystem native`

> If you can show me any video-compression-based implementation that allows me to get this close to zero latency with zero image degradation (especially for text, you really don't want subpixel font AA to be video-compressed) and as little network overhead as what Qt gives over X11 I'll be super happy, but I really think it is unrealistic.

What can do better? Yes, it’s true, compressing text with lossy algorithms could pose a problem.

However, consider the following: if you wanted to compress frames, you would Never ship PNGs over the network, at least not like this. You’d get dramatic savings just by XORing the current frame with the last frame and the RLEing that. Boom, smooth scrolling achieved. Combine it with dirty rects and possibly some other techniques and it should be good enough.

Besides, at 8 MiB/s, lossless video codecs are pretty doable for fullsceen UI. Modern VNC implementations (Ultra, Tiger, etc.) make a joke of this figure and can still get good text quality.

Re: The end of the nice GTK button

#586

Post by zzo38computer » Fri, Mar 25, 2022, 5:05 PM UTC

I dislike GTK; my opinion is that Xaw is better in many ways.

GTK has problems including bad designs of many things including file selection dialog box, scrollbars (which are not always consistent), bitmap fonts sometimes don't work properly, always uses Unicode and although you can enter Unicode control characters they are not displayed while editing (which makes it difficult to use), some things are not documented well, configuration is difficult, kerning in editable text, etc.

So, I do not use GTK in my own programs.

(Some people say that if a program does not need to be documented then it is easy to use, but I disagree; a program is difficult to use because it is not documented well.)

Re: The end of the nice GTK button

#587

Post by jcelerier » Fri, Mar 25, 2022, 5:09 PM UTC

jchw wrote: post #585

jcelerier wrote: post #570

Earlier quoted context omitted.

> Still, 8 MiB/s is a shit ton of data, it is minuscule , and it is the peak I managed to get when moving as fast as possible. At the same refresh rate, blitting, say, 1024x1024 pixmaps would yield 576MiB/s so here we are talking about 72 times less. And it's while running a moderately image-heavy app with most likely room for optimization. One I often use is pavucontrol-qt: this one gives me less than 1MiB/s of netw…

> it is minuscule, and it is the peak I managed to get when moving as fast as possible. At the same refresh rate, blitting, say, 1024x1024 pixmaps would yield 576MiB/s so here we are talking about 72 times less. If 70% of the pixels are the same shade of gray, that’s not impressive at all. If you are serializing image data and storing it over the network, you can do better than uncompressed with virtually no CPU load…

> Besides, at 8 MiB/s, lossless video codecs are pretty doable for fullsceen UI. Modern VNC implementations (Ultra, Tiger, etc.) make a joke of this figure and can still get good text quality.

Here's how tigervnc looks on the exact same situation:

https://www.veed.io/view/0ca6898a-a535-4f0a-accb-b22e2e184b0...

Sure, it uses less bandwidth (between 2 and 2.5 MiB for the busy part of this video) but it is also full of artifacts (https://i.imgur.com/4QrV9xl.png), super slow compared to X11 and does not respect my local settings. no thanks !

Re: The end of the nice GTK button

#588

Post by klibertp » Fri, Mar 25, 2022, 5:13 PM UTC

d1sxeyes wrote: post #577

klibertp wrote: post #552

Earlier quoted context omitted.

> Arguably, you have been 'taught' or you have inferred yourself that you should expect a sleeping system to immediately accept your keypresses as a password, which although reasonable is not necessarily a good practice . I fail to see why that wouldn't be a "good practice". Last weekend I read some articles on Canon Cat[1], and Jef Raskin referred[2] to the feature as something desirable: > In many ways it was, for…

Thanks for sharing. I can definitely see why it might be appealing. However, using Ctrl + Alt + Del guarantees that only Winlogon can handle the logon, no other process can be simulating the login prompt. My dad told me about a program he wrote for a PDP-11 which would just simulate a login prompt. When a username and password were entered, it would append it to a file somewhere, then print the 'Incorrect username or…

I see. It makes sense, and it's a valid concern that I didn't think of. Personally, I prefer the convenience of continuing where I left off with as little friction as possible, so I don't even lock the session when the screensaver kicks in. But I never take my laptop outside, and the threat of malware is considerably lower under Linux. If that wasn't true, I would probably also want to err on the side of caution. Choosing a specific key (I have a very conveniently positioned X86WakeUp physical button) or combination for waking up and getting to login prompt seems like a good idea in that case.

Re: The end of the nice GTK button

#589

Post by mjevans » Fri, Mar 25, 2022, 5:20 PM UTC

kaba0 wrote: post #525

mjevans wrote: post #333

Earlier quoted context omitted.

That is the worst thing. Updating a UI while the user is interacting with it. Everything that reaches the screen should remain FIXED in place unless moved //by the user//. This might happen E.G. because something was loading and now gets a resize event; so some list suddenly changes the position of everything rather than force the user to click something else to resize the misbehaving entry. (Scrolling could also do…

I would add that adding to an end of a list dynamically can be okay (if it doesn’t cause previous content to jump as you mention).

It's less egregious, but remember that clicking away from the list (e.g. to close it) is also often an input option. Even though that's a lower input priority it could still disrespect the user's desires if they were trying to leave the list.

Re: The end of the nice GTK button

#590

Post by michaelmrose » Fri, Mar 25, 2022, 5:28 PM UTC

berkes wrote: post #410

adhesive_wombat wrote: post #55

Earlier quoted context omitted.

I spend far too long in GTK apps looking for the right menu to do basic stuff. It's like someone once saw an iPad from across a room and tried to implement what they remembered of it.

This is really not the best place to throw condescending anecdotes around to insult FLOSS. What, on an iPad, should a designer look at in detail to improve the GTK app, for example?

The first step is them realizing they have a problem.