Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The end of the nice GTK button

blog.brixit.nl

Post reply on HN
Print view View original

561–570 of 666 posts

Re: The end of the nice GTK button

#561

Post by jordibc »

andai wrote: post #530
fxtentacle wrote: post #370

Earlier quoted context omitted.

That is one of the main reasons why I switched from XCode to CLion. XCode lost keystrokes, which drove me crazy. The other thing was that I could reliably type faster than XCode could display the letters, which made me feel like I'm drunk. CLion seems to be quite excellent at recording and replaying everything, including stuff I type while the auto-completion is loading. Plus it has a really fast key to screen loop.

JetBrains did a lot of work to reduce typing latency of their IDEs: https://blog.jetbrains.com/idea/2015/08/experimental-zero-la... As an aside, I find it amusing that more latency is introduced by a USB keyboard than existed in an entire 80's computer (from keypress to rendering on screen). See also: Carmack's rant about how it takes longer to put a pixel on the screen than ping across the Atlantic.

About the USB keyboard, that may be true only for the cheapest keyboard you could find, but basically not applicable anymore nowadays. Rather than giving you the details, let me link to this video, which is awesome at explaining it and much more -- the USB vs PS/2 part starts here: https://www.youtube.com/watch?v=wdgULBpRoXk&t=1766s

Re: The end of the nice GTK button

#562

Post by d1sxeyes »

kaba0 wrote: post #524
tsimionescu wrote: post #501

Earlier quoted context omitted.

GP's (I think reasonable) point was that typing A on the keyboard of a locked (or worse, sleeping) computer has no reason to be interpreted as "input the letter A into the password field that will be displayed on screen", which is what the original post is assuming it should mean. There's no real reason it should even mean "input the letter A into the first field that comes into focus", which may anyway not be the pa…

Well, you usually see the logged in user’s name and icon on the screen, and presumably you left your own computer there. And frankly, UX is about finding the little practices that make the experience better — arbitrarily waiting for windows to bring up a prompt is not making me any good, since I know what I want to do. So in my opinion in this very special case, windows is simply doing an incorrect thing — making the…

> Well, you usually see the logged in user’s name and icon on the screen

I don't have this experience. On Windows (10, at least), normally I see either a black screen (if it's asleep) or a wallpaper, clock, and a message saying 'Press Ctrl + Alt + Delete to unlock.'

> arbitrarily waiting for windows to bring up a prompt

I don't think it's arbitrary. It's doing something - it's calling Winlogon, spinning up disks and reading hibernation data into memory, restarting power to powered down components, probing authentication methods available (eg: fingerprint/card readers), in case of domain joined computers, validating whether the domain is available (which means firing up network interfaces), and if so, whether the user's password has changed, etc.

There are definitely downsides to Microsoft's approach here - as you mention, in a large number of cases, it takes more time to unlock the computer.

However, there are also upsides if you accept that UX is only one consideration when designing a secure log on prompt, and there may be other priorities.

Re: The end of the nice GTK button

#563

Post by the_pwner224 »

NovemberWhiskey wrote: post #553
andai wrote: post #530

Earlier quoted context omitted.

JetBrains did a lot of work to reduce typing latency of their IDEs: https://blog.jetbrains.com/idea/2015/08/experimental-zero-la... As an aside, I find it amusing that more latency is introduced by a USB keyboard than existed in an entire 80's computer (from keypress to rendering on screen). See also: Carmack's rant about how it takes longer to put a pixel on the screen than ping across the Atlantic.

> 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 often than your display is updating.

Re: The end of the nice GTK button

#564

Post by thomastjeffery »

tonyedgecombe wrote: post #407
wolpoli wrote: post #360

Earlier quoted context omitted.

> In modern Windows, press Win-key and start to type, oops, it missed the first keypresses, presented the completely wrong results and made a mess of your workflow. Every time I bump into these interaction issues, my stomach churns a little bit. Right now, Windows 11 is especially bad because they have new and old code working side by side. It'll take a few years for Microsoft to rewrite enough of the Shell so everyt…

By then Microsoft will have moved on to the next bit of Apple envy and it will all be out of sync again.

Windows 11 is that next bit. They never finished windows 10.

I still have to dig through windows 7's control panel to change my microphone volume.

Re: The end of the nice GTK button

#565

Post by pmontra »

toqy wrote: post #471
pmontra wrote: post #457

Earlier quoted context omitted.

The first time somebody handed me an unlocked iPhone asking me to send a SMS (she was driving) I wasn't able to do it. I had to ask her where to touch. She was really surprised. I had a few years of experience on Android and 10+ with feature phones. On the other side, I asked another friend of mine to take a picture with my Android phone a couple of weeks ago and she (an iPhone user) wasn't able to find the camera ap…

On iPhone you can swipe left on the Lock Screen, or press the icon on the Lock Screen, or you can pick it from a menu you pull down from the top of the screen, or find the app via icon, search, full app list. Maybe other ways I don’t use or know. I would assume that it’s similar on android, access the camera from lock screen or app. I’d probably try the iPhone style swipe the lock screen if I didn’t see a shutter or…

Maybe that's what happened. I removed everything from the lock screen and she could have inadvertently locked the screen.

Re: The end of the nice GTK button

#566

Post by jchw »

jcelerier wrote: post #473
jchw wrote: post #461

Earlier quoted context omitted.

> This is entirely untrue. Did you even try ? Qt even at version 6 still supports rendering through X11 commands, and afaik does that by default when ssh'ing on Debian distros. When you connect over SSH, it will fail to setup XShm and then it will work as expected, only slower than the speed of smell, because now it’s shipping pixmaps over the network. Not all X11 clients continue to work properly if XShm can’t be es…

> When you connect over SSH, it will fail to setup XShm and then it will work as expected, only slower than the speed of smell, because now it’s shipping pixmaps over the network. no, this is false . Here's a video of dolphin, KDE's Qt 5 file manager, run over ssh on another computer: does that look like it's blitting pixmaps over the network ? https://www.veed.io/view/d822f1b3-305a-4af1-8df6-61439515ccc... When chec…

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 QPainter somewhere in Qt 4, but it’s not plainly obvious that they did. I’ll concede on that. It’s still mostly shipping pixmaps either way, especially depending on how things nest, because the text is absolutely all pixmaps, but it would be more efficient by a decent bit than shipping the entire app as pixmaps due to being able to do compositing on-server.

It doesn’t change anything about DPI independence, because neither XRender nor the basic X drawing functions provide you with scalability built-in.

Re: The end of the nice GTK button

#567

Post by nanochad »

SkeuomorphicBee wrote: post #15

I agree 100% with the author, the old GTK button was gorgeous, it will be missed. > I have had to explain to people tons of times that the random word in the UI somewhere in an application is actually a button they can press to invoke an action. This is one of my biggest complaints with the super flat modern designs. Many widgets lost their skeuomorphic depth, which encoded a lot if visual information (the clickabili…

No post body was provided.

Re: The end of the nice GTK button

#568

Post by ghostpepper »

0x38B wrote: post #496
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…

Related: If I type 'ha' for "Hacker News" in Safari's address bar on my iPhone, by the second letter it'll show "Hacker News". But if I'm too quick to hit "Go" on the keyboard, Safari instead searches DuckDuckGo for "ha". The UI must update sooner than some underlying state; this bites me multiple times a day.

I was just thinking about how windows xp and old linux DEs (Gnome 2, KDE3) somehow felt snappier and now I'm wondering if the rise of multicore/multiprocessing is to blame. When the windowing stack is running in the same physical core as the kernel maybe it's harder for these things to become disconnected.

Re: The end of the nice GTK button

#569

Post by brimble »

inetknght wrote: post #534
Derbasti wrote: post #348

Earlier quoted context omitted.

> In modern Windows, press Win-key and start to type, oops, it missed the first keypresses, presented the completely wrong results and made a mess of your workflow. The worst offender is the login prompt. In Gnome, from the lock screen, I simply start typing my password. As soon as I type the first letter of the password, the password prompt appears, and when I'm done I hit enter and it unlocks. On Windows, the first…

> In Gnome, from the lock screen, I simply start typing my password. As soon as I type the first letter of the password, the password prompt appears, and when I'm done I hit enter and it unlocks. Congratulations! You were able to recognize that it's a _login screen_ without seeing that there's a hidden password field. The first time I booted to Gnome I waited damn near ten minutes for it to tell me it's ready for my…

Miming mobile OS lock screens is one of the weirdest damn things about modern desktop trends. It's so obviously a bad idea. I can't even figure out what useful functionality anyone thought that would provide. It's a fucking desktop, there's plenty of room to stick notifications or the weather or whatever on the same screen as the login prompt, if that's what you want.

Re: The end of the nice GTK button

#570

Post by jcelerier »

jchw wrote: post #566
jcelerier wrote: post #473

Earlier quoted context omitted.

> When you connect over SSH, it will fail to setup XShm and then it will work as expected, only slower than the speed of smell, because now it’s shipping pixmaps over the network. no, this is false . Here's a video of dolphin, KDE's Qt 5 file manager, run over ssh on another computer: does that look like it's blitting pixmaps over the network ? https://www.veed.io/view/d822f1b3-305a-4af1-8df6-61439515ccc... When chec…

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 network traffic when resizing it madly.

> It doesn’t change anything about DPI independence, because neither XRender nor the basic X drawing functions provide you with scalability built-in.

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 ?

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).

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.

Post reply on HN