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

301–310 of 666 posts

Re: The end of the nice GTK button

#301

Post by audidude »

imglorp wrote: post #181

I may be alone here, but maybe there are mountains of functionality never tackled in Gnome. Basic things like trackpad gestures are just now arriving for example. Meanwhile, the visual design has been hashed over and over: I've lost count. Why is L&F consistently prioritized over basic capabilities?

> Basic things like trackpad gestures are just now arriving for example.

All they had to do was go fix the input drivers, the user-space library to communicate them, the compositors to be able to mediate gestures, the toolkits to process them, the X11 server extensions, wayland protocols, etc...

One of the biggest problems in this is that you can't just fix one input driver. You have to go fix them all so that the experience is consistent across as much as hardware as possible.

Re: The end of the nice GTK button

#302

Post by josefx »

snerbles wrote: post #86
bqmjjx0kac wrote: post #77

Earlier quoted context omitted.

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.

I look forward to hieroglyphic CLI interfaces, where we compute like it's 2600 BC.

At 2600 BC hieroglyphs already included symbols used for phonetic spelling, so hieroglyphs are not the way to go if you want to get rid of spelled out words unless you ban the subset that can be directly mapped to greek letters[1]. Otherwise it just ends up a fancy font.

[1]https://youtu.be/NIxn9auks24?t=2009

That literally every ancient civilization went from pictures to words as fast as they could should say something about modern icon only design.

Re: The end of the nice GTK button

#303

Post by jcelerier »

jchw wrote: post #215
hedora wrote: post #195

Earlier quoted context omitted.

I really don't understand what was wrong with the X11 approach. I had a high DPI monitor in 2001. I typed the DPI into /etc/XFree86.conf or whatever, and it all Just Worked (TM). Edit: I think modern web browsers implement ctrl-+ and ctrl-- the same way, except X11 apps kept separate directories of icons rendered for different DPIs, because 1GHz single core still seemed luxurious. Web browsers scale the bitmaps using…

Well, how much it Just Worked really depended on what you were doing and how. At a point, it all stopped Just Work-ing. Old old X11 apps used X11 drawing commands. These sucked, and nobody liked them. If you think you liked them, please show me your clean Xlib codebases for proof :P As far as I can recall, these still dealt with pixels, so clients were on the hook for dealing with scaling, though in theory it wasn’t…

> More modern apps (— early 2000s should be “modern” enough by X11 standards, but my memory is foggy and I’m too young to really be an expert here —) instead blit pixmaps sent over shmem, defeating both network transparency and the inherent “vector” nature of many of the old drawing commands. X11 didn’t really handle anything other than knowing the DPI (… that you told it …)

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.

And I can set my Xft.dpi to, say, 144, ssh -X somewhere and the apps I launch (tried gtk2, gtk3, Qt 4 to 6) will so far all use the correct local DPI. Which other remote UI technology supports that ?

Re: The end of the nice GTK button

#304

Post by Sophira »

The design of HN has similar issues, honestly, especially on links you've already visited:

https://matrix.theblob.org/hn-original-style.png

Which parts are links? Which aren't? It's a little more obvious that the main text is a link but not obvious that you can click to view the comments. (It can be inferred, of course, but I don't believe that should be necessary.)

A little styling to add underlines back to links, plus a little bold to indicate the comments page, fixes this:

https://matrix.theblob.org/hn-my-style.png

Some might say that this looks ugly, and that's a valid view. But to me, it's usable.

(Why are both the "time posted" link and the comments link bolded? Because they both go to the same place. I didn't even know before I made this style that that was the case! I was surprised to see that the style I made did both, but I'm not complaining.)

Re: The end of the nice GTK button

#305

Post by eloisius »

happymellon wrote: post #282
nojs wrote: post #272

Earlier quoted context omitted.

> Whenever I see a hamburger menu I silently think "Here someone has given up" Can you explain what you don’t like about hamburger menus?

Is a dumpster of features, you have no idea what you'll find in there. Has someone hidden the zoom buttons in there? How about print? Perhaps that's also where save is, or tab colour? Most things in the hamburger menu are completely unrelated but exist for the removal of context. Button outlines so you have no idea what you can and cannot click on as well, which is mentioned in the fine article, are all modern design…

Yep. It's the miscellaneous everything bucket. It also seems to only be motivated by either scarce screen real estate (it first showed up in mobile interfaces), or graphic designers who think everything is "clutter" and by sweeping it away into the hamburger menu they can have their beautiful screenshot-worthy interface. I have a 27" monitor, but tons of websites and even Firefox itself hide half the functionality behind a hamburger.

Re: The end of the nice GTK button

#306

Post by simion314 »

harry8 wrote: post #211
azinman2 wrote: post #42

So basically the new GTK is iOS but without the professional designers behind it. What I cannot understand is how Canonical, Red Hat, or some rich SV person hasn’t thrown money at the problem and hired a big wig design firm or person to overhaul it all. Johnny Ive is now even available (if he’d take the project). But even going thru a site like dribbble there are so many amazing designers out there. To me it would be…

If you're Apple and you make your desktop more attractive and pleasant you drive sales and market share. If you're redhat and you resource that you drive market share, to Ubuntu, who I believe still have a policy of never paying for development except for Ubuntu things, eg their failed desktop nobody else would use, Mir, bzr, etc. Is that still the case? It would be a huge disincentive for other distros to contribute…

>If you're redhat and you resource that you drive market share, to Ubuntu, who I believe still have a policy of never paying for development except for Ubuntu things, eg their failed desktop nobody else would use, Mir, bzr, etc.

Fact check, Gnome was filled of memory leaks and performance issues until some competent Canonical developer started working back on GNOME and fixing them.

So while Ubunut was not using GNOME the RH could have safely put their money into GNOME and it would not have benefited Canonical but the reality is that Canonical had to pay competent people to fix GNOME bugs, but probably Canonical can't change the desinger dictator so they usewd for a while a fixed theme and not the shity GNOME default.

I disconnected myself from Linux news so I don't know what drama happened in latest 2-3 years.

Re: The end of the nice GTK button

#307

Post by swiftcoder »

grishka wrote: post #269
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…

Borderless buttons to have the right to exist, but you should be very careful with their use. For example, take this UI I made recently: https://mastodon.social/@grishka/107998100334356147 , 2nd screenshot. The button to decline invitation looks like a link (same color) and it's next to a real button. No one would ever get confused by this, it's pretty clear it's clickable. But a black word in a larger font among bla…

> No one would ever get confused by this, it's pretty clear it's clickable.

I don't know how you can reach that conclusion, because we only recognise it because of how many times we've been fed this exact pattern over and over again in flat UIs (and failed to realise it was clickable the first N times)

Re: The end of the nice GTK button

#308

Post by [deleted] »

eqvinox wrote: post #294
rezonant wrote: post #292

Earlier quoted context omitted.

So on desktop applications, I assume you prefer all your functions to be on toolbars, and you have similar disdain whenever you encounter a File menu? I guess if there's a lot of functions, you probably need some tabs on your toolbar- so the Office Ribbon interface is idyllic I assume?

The difference between a file menu and an hamburger icon is that the file menu hides file operations while the hamburger icon hides… anything. something. dead bodies.

[deleted]

Re: The end of the nice GTK button

#309

Post by heisenzombie »

rezonant wrote: post #299
eqvinox wrote: post #294

Earlier quoted context omitted.

The difference between a file menu and an hamburger icon is that the file menu hides file operations while the hamburger icon hides… anything. something. dead bodies.

Almost every desktop application has a File menu whether or not it deals with files. The File menu has an "Exit" item. Does it Exit the File? OBS has "Always on Top" as an option within "File". Or we can look at it from the other side. "Where do I find the settings for this app?". Is it in File, Edit, View, Tools or Help. The answer depends on the app. Menus can be well organized or poorly organized but I don't think…

There are guidelines for what should be in menu bars, what order the items should be in, and how they should behave for different sorts of application.

For example, on Mac: https://developer.apple.com/design/human-interface-guideline...

And on Windows: https://docs.microsoft.com/en-us/windows/win32/uxguide/cmd-m...

> "Where do I find the settings for this app?". Is it in File, Edit, View, Tools or Help?

On Mac, it should be in the "App" menu and called "Preferences...", it should be the first item in the menu, except if you have an "About YourAppName" item which always goes at the top with a seperator underneath.

On Windows, it should be in the "Tools" menu, and called "Options...". 4 On Linux, it should be under the "Edit" menu, and called "Preferences".

If it's not, then the app (in my opinion) is broken. Of course, many apps are lazily ported across platforms or "hamburgerized". The Windows situation is obviously also more messy because of the newer "ribbon" standards complicating things a bit, but there are right answers.

(edit: fixed links)

Re: The end of the nice GTK button

#310

Post by zestyping »

grishka wrote: post #269
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…

Borderless buttons to have the right to exist, but you should be very careful with their use. For example, take this UI I made recently: https://mastodon.social/@grishka/107998100334356147 , 2nd screenshot. The button to decline invitation looks like a link (same color) and it's next to a real button. No one would ever get confused by this, it's pretty clear it's clickable. But a black word in a larger font among bla…

It does not look like a button. It's just a label floating around.

When designing user interfaces, use the mantra: "Don't make me think!" Don't make the user think about whether something is a button or not. Don't make them have to infer that the label is in fact a button due to context.

Just make it look like a button!

Post reply on HN