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

141–150 of 666 posts

Re: The end of the nice GTK button

#141

Post by jchw »

zozbot234 wrote: post #121
jchw wrote: post #106

Earlier quoted context omitted.

It’s going to be a bloody mess for a long time, because the choices for how to handle resolution independence are all inherently filled with compromise. With font rendering, I think there is hope. Horizontal subpixel positioning with vertical hinting seems like a good tradeoff to me. Grid fitting vertically is not too jarring, and grid fitting horizontally to subpixels instead of pixels looks pretty good too, on low…

> For example, if you want a crisp 1px border on 96 dpi, you could specify it to be a 1px border at 96 dpi… but then what happens at 1.5x or 1.75x scale? The border width should get snapped to the physical (sub-)pixel resolution as part of rendering. Typically, this should come with changes in contrast too, such that if a line is forced to become thinner it also gets drawn with higher contrast wrt. the surroundings,…

> All of this stuff can be made to work.

We’ve tolerated a great degree of complexity just to make fonts look good at 96 DPI. Looks like we’re able to tolerate a bit more complexity to enable GPU rendering. However, many years into having high DPI displays, it’s not obvious people are willing to take the complexity to make low DPI and high DPI screens look good simultaneously.

The thing is, with fonts, we already bear the burden of font rendering being complex because that was needed for 96 DPI displays. But, we won’t need much of this magic or complexity when a vast majority of people are using higher DPI displays, because at >200 PPI the difference between a blurry line and a sharp line is basically nil. That is obvious enough on Apple platforms, where many are perfectly happy with the scaling even though it uses 2x as a base for all scales.

I think the future is simply pain. People want cleaner graphics pipelines, and only high DPI displays will get them anywhere.

Re: The end of the nice GTK button

#142

Post by Aeolun »

wolpoli wrote: post #48

I don't understand why modern toolbar icons are basically abstract shapes represented by lines. It's 2022, we have 32 bit colors, but toolbar icons have less color than back 30 years ago in Windows 3.1.

> I don't understand why modern toolbar icons are basically abstract shapes represented by lines

Much, much easier to style based on whatever the surroundings are. Also easier to maintain a good look if you switch to a completely different theme, and for third party icons to mesh with the OS set of icons (only so many ways you can mess up the sillouette of the shape).

Oh, and they scale to basically infinite proportions without looking weird, which cannot be said for color vector icons.

Re: The end of the nice GTK button

#143

Post by zozbot234 »

bodge5000 wrote: post #111

Perhaps I'll be crucified for saying this, but I actually like flat design. Or at least, I think I do. I always thought flat design was as the name suggests; flat. As in, no gradient, no faux 3D, and I guess no borders. I'm not such a fan of rounded buttons, I think they often scale badly (pretty much anything round will unless its a vector I guess), but I didnt think that was a requirement of flat design. That being…

The original button has gradients and 3d-lighting effects. They're just subtle, but suffice to convey useful information.

Re: The end of the nice GTK button

#144

Post by traverseda »

zozbot234 wrote: post #104
xedrac wrote: post #90

Earlier quoted context omitted.

I for one don't want the phone form factor to influence my desktop experience. They are two completely different workflows that have conflicting needs IMO.

The main influence so far has been enabling smaller window sizes for gtk+3/libhandy apps, which is good for all users especially those on older, lower-res hardware. Hopefully libadwaita can get forked into something like a libhandy equivalent for gtk+4, that otherwise preserves sane defaults doesn't enforce their silly "flat" theme choices.

>The main influence so far has been enabling smaller window sizes for gtk+3/libhandy apps

I don't think so, touch targets are a lot bigger. Using the default theme for both a KDE App with equivalent functionality will take a fair bit less space than a similar gnome app. Of course I think plasma mobile uses a theme that makes the touch targets bigger...

KDE also manages to get a lot more functionality into their similarily sized windows. Take a look at this page showing comparisons:

https://www.linuxadictos.com/en/aplicaciones-de-gnome-y-apli...

Re: The end of the nice GTK button

#145

Post by andrewf »

bqmjjx0kac wrote: post #77
HeckFeck wrote: post #22

Earlier quoted context omitted.

This is why I have reverted to the CLI whenever possible. There's something deeply assuring knowing that I don't have to relearn my whole workflow every few months when the trends change. ls, grep, find, ps, htop will always be what they are. Even the Windows CLI is thankfully consistent. All I want is to get work done the way I want, and I've found the CLI is increasingly the path of least resistance.

I regret to inform you that the latest release of `find` has been renamed to [magnifying glass emoji]. For example, # Find directories the old way. find . -type d # The cool new way! [magnifying glass emoji] . -[keyboard] [folder emoji] Edit: HN appears to strip emojis, so my new edited comment doesn't pack the same punch.

similar c++ proposal from April 1998: https://www.stroustrup.com/whitespace98.pdf

Re: The end of the nice GTK button

#146

Post by TillE »

naoqj wrote: post #9
von_lohengramm wrote: post #5

The font rendering on that example of "the perfect button" is rather atrocious. It's kind of sad that Windows is (was?) the last bastion of serviceable font rendering.

I agree that the defaults are atrocious, but freetype can be configured and the options are limitless.

Maybe there's some configuration magic you can do, but I don't think I've ever seen decent font rendering on a Linux distro out of the box.

It's one of the biggest reasons I've never switched to desktop Linux, and I'm not even one of those super picky people who talk about the intricacies of typefaces all day.

Re: The end of the nice GTK button

#147

Post by taf2 »

Regarding flat - theme movement… it was iOS7 that my daughter 3 was happily able to use her new iPad running iOS6 when I set her up and she could press play on her show. Then one morning we had her in the stroller and taking a walk and I handed her upgraded to ios7 iPad… it was instant tears she couldn’t figure it out… just to get the walk started I pressed the play button for her after many tears… later on during the walk her show ended and in her frustration at not being able to find the play button she raged on the iPad … that iPad is no more… IMO following that experience the flat movement was really bad for usability… driven by a form over function that I’ve seen harm younger and older people alike… my then 92 year old grandfather I remember also seriously struggling with ios7 compared to 6… just my observations… but yeah flat looks better…

Re: The end of the nice GTK button

#148

Post by [deleted] »

eptcyka wrote: post #122
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.

Funny, I usually have the same opinion of iOS user interfaces.

[deleted]

Re: The end of the nice GTK button

#149

Post by Aisen8010 »

jraph wrote: post #89

It seems like KDE and Plasma is the place where look and feel is constantly but incrementally refined; we've been saved from this flat design trend so far and things keep looking pleasant and modern and being usable. We know they care, and have great attention to details because that's documented weekly [1]. I find the Breeze theme really well done and its GTK port, Brise, is also very nice, to the point Gnome looks…

I would not be so sure. Sooner or later there will be a QT6 port and most of the work will be lost.

I was a happy GNOME user before the version 3 fiasco. It took years to have a usable GNOME desktop again.

Re: The end of the nice GTK button

#150

Post by notriddle »

userbinator wrote: post #123
warning26 wrote: post #113

Earlier quoted context omitted.

> Back when it was just programmers you could tell a button was a button, a tab was a tab and we didn't hide basic functionality behind a swipe gesture or long press that users were supposed to just know. Keep in mind that programmers also gave us this: http://www.martin-achern.de/wgetgui/images/linux_wgetgui.jpg People across all disciplines are capable of making poor design choices

Keep in mind that programmers also gave us this You're basically proving the point. That is so much clearer and obvious to use than the screenshots in the original article, and it doesn't treat you like an idiot.

Yes, I know which things are buttons, which things are text entry, and which are checkboxes. This was a strength of early 2000's UI design, and it's a shame that so many applications don't give such clear indicators any more.

This application still has an absolutely crap design.

* How do I specify where the downloaded data goes? Why are there onscreen options for literally everything else, but not that?

* Which text entry fields are disabled, and which ones are enabled? This is something Win95 got right.

* What even is "force directories"? And it looks like checkboxes are used for both it and "no directories", so what happens if I check both?

* What's the difference between Spider and Recursive? Those sound like the same thing to me, and I know I'm in a pretty elite club just knowing what web spiders are at all.

* Are jpeg/gif/etc only used when Reject is turned on, or are they also used when Accept is turned on?

* Is the wget-list input field connected to the Input file checkbox? It's right underneath it, and presumably I have to specify the input file somewhere, but the spacing implies it's not.

* What's the difference between "quiet" and "non verbose"? What happens if both are turned on?

* The rest of the buttons are pretty well labeled, but what's AG?

* Does it really need its own quit button? The window manager already provides one.

Post reply on HN