Hacker News Reader

Comment by bkor | Hacker News Reader

I mostly disagree with you entirely.

Client side decorations give way more space to the actual content than to waste space for an almost empty titlebar. It allows to combine the titlebar with content from the application itself. You regard them entirely off as a "sin". Very strong language but you don't explain _at all_!

For the file chooser, some never things that were never implemented were added recently: double vs single clicking, renaming and some other super old bug.

Regarding mouse wheel support: What basis do you say that 1) it was removed 2) it was made out of spite?

Too many people have way too much time talking down on the work of others. You go out of your way to imply that GNOME developers are intentionally evil. What the hell.

PS: I agree it needs way more developers. But that's nothing new.

View on HN

> Client side decorations give way more space to the actual content than to waste space for an almost empty titlebar.

If Gnome 3 wanted to fix that, it should just replace its space-wasting default theme. And in reality it's a non-issue everywhere else. No other desktop environment even has this debate.

> Very strong language but you don't explain _at all_!

Very easy: Consistency. Look at how absolutely, utterly shit Windows looks nowadays. Word doesn't blend in with Explorer doesn't blend in with regedit doesn't blend it with (the still XP-themed) GPO editor doesn't blend in with the new settings app doesn't blend in with the control panel doesn't blend in with Edge …

My window manager should dictate how windows looks. This works for all toolkits, from GTK2 over FLTK over Qt all the way to Mono's GDI. All, except GTK3.

And yet, it does not have to be a problem! A few years ago, this would have been a no-brainer: When GTK was presented with behavioural differences between desktop environments, it was implemented as a run-time option, configured by the GTK theme to allow desktops to configure GTK to its needs (like "images on buttons", mandatory in Xfce, shunned in Gnome).

Client-side decorations are a compile-time switch. What the hell.

> Regarding mouse wheel support: What basis do you say that 1) it was removed 2) it was made out of spite?

GTK's notebook widget. It was removed for no reason, and users were told to just reimplement it in all applications they needed it in. What the hell.

> > Client side decorations give way more space to the actual content than to waste space for an almost empty titlebar.

> If Gnome 3 wanted to fix that, it should just replace its space-wasting default theme. And in reality it's a non-issue everywhere else. No other desktop environment even has this debate.

Yes, other desktop environments have this debate. In Mac OSX, open any recent app and you'll see titlebars with actions (e.g. play/pause in iTunes, addressbar in Safari, etc.), presumably to compact window chrome.

Regarding client side decorations: Lots of Windows applications draw on it.

I now the technical separation of window manager vs toolkit. It's nice that you can always close the window. But practically speaking, CSD gives me way more space vs some theoretical idea that "it should not be done".

The consistency argument I don't see. GTK+3.x apps can disable their CSD when running on other desktops. Within GNOME 3 though, it is consistent. Initially the apps would default to showing CSD but AFAIK latest GTK+3.x ensure they don't.

Anyway regarding consistency: It is way nicer! If it is way nicer, then why hold back for consistency? You'd never be able to make a change. And basically there are two toolkits anyway, Qt and GTK+. I've been around for ages, but FLTK/Java stuff, etc... eventually you'll go down to a: no change ever.

You said it is a compile time option. AFAIK it is not at all. Though with Wayland the use of xsettings is more difficult. They are specific to X after all.

Regarding mouse wheel support you didn't give an example?

In case of anything else you disagree with, please speak up as changes happen (d-d-l). It is pretty difficult to go against a decision that happened a long time ago. E.g. I could give a "this is bad / better revert" but unless people complain when things happen it is pretty hard/difficult. Notebook I didn't notice nor knew for instance.

I do see other changes that are made, but usually when that is done they seem to have investigated how often it is used (not just git.gnome.org). Usually they find 0 or 1 app and that app is on git.gnome.org.

>space-wasting default theme

GNOME 3's default theme has the slimmest window chrome any GNOME has ever had. People think it's space-wasting because the fonts are larger, but they got larger-looking buttons in fewer pixels by compressing everything into one place. It's only space-wasting if you're using applications that don't support menus in the title bars, and even then it's about the same as GNOME 2. You can check it by running GNOME 2 and 3 side-by-side.

> GNOME 3's default theme has the slimmest window chrome any GNOME has ever had

Even if that was true, what your parent said is that it's space wasting (in absolute terms). Which is actually an understatement.

> It's only space-wasting if you're using applications that don't support menus in the title bars

That's really two pairs of shoes. And assuming support for the gimmick of the day (which also presumably only works for GTK3 apps) is totally insane.

And btw the default theme also sucks in that you can't easily see which window has keyboard focus. And if you change the theme, it gets messier as your parent described.

I totally agree with you.

Sorry to get meta, but what is the rationale that HN doesn't show the number of upvotes to your comment? I hate that you get three counter-comments and zero agree comments (because it's dumb to comment "I totally agree"), but the fact that (presumably) most people agree with you is hidden from the user.

HN tries to discourage the us vs. them herd mentality that you're talking about. It's not about winning an argument, it's about having a discussion. There's no need to know how many other people agree with a particular comment, we should make up our own minds about it.

I agree it's wrong to center on votes instead of content.

However, I'm often very interested what people's opinion is. For example, that has a strong influence on my temptation to raise my voice if I have strong opinions. So accessible vote counts might help reducing noise and pointing out where the controversy is.

I think it would be a great compromise to have the vote count one or two clicks away.

that has a strong influence on my temptation to raise my voice

These days, they have a person running around reminding people who succumb to that temptation not to. Seems to work well.

So accessible vote counts might help reducing noise

It introduces noise very similar to the 'visible downvotes' noise.

Raising your voice isn't really a great way to convince other people to consider your side of an issue.

How'd you do it instead?

Read that in the form of TALKING LOUDER when people seem to not "get" your point.

Because it doesn't matter how many people agree with you. The only important thing is what you are actually saying.

> My window manager should dictate how windows looks. This works for all toolkits, from GTK2 over FLTK over Qt all the way to Mono's GDI. All, except GTK3.

So you're arguing that because the window decorations are consistent, apps are consistent?

Hate to break it to you, but running a GTK2 app under KDE/KWin will still look inconsistent.

The only way you get to be consistent, is by having your app developers use the same toolkit. I don't see why the windows' frame should be regarded as "special" when all the button/tabs/filechooser/… widgets are different depending on the toolkit.

> The only way you get to be consistent, is by having your app developers use the same toolkit.

Will never happen. Instead, if you want consistency, avoid redundancy in the first place (where it's practical)

I agree, but well, you can choose to run only or mostly GTK or QT apps, and stop caring the occasional out of place app (Blender? Steam?) doesn't look consistent.

And to be honest, I don't see why I would care that apps like Blender or Steam have a window frame that looks exactly like the window frames of my (non-CSD) desktop environment/window manager, when the apps themselves are completely out of place. But that's me, I suppose.

> I don't see why I would care that apps like Blender or Steam have a window frame that looks exactly like the window frames

Unless you use blender or steam, or evince (!) with anything other than gnome3 and default theme, that is, and unless any of the many reasons against CSDs resounds for you (as somebody below posted)

http://blog.martin-graesslin.com/blog/2010/05/open-letter-th...

Sounds very unrealistic, doesn't it?

> Hate to break it to you, but running a GTK2 app under KDE/KWin will still look inconsistent.

Certainly, but at least I can be sure that the inter-application[1] inconsistency in terms of overall window behavior/L&F is minimized (as far as practical) if the decorations are server-side.

... and that's a real win, at least from my perspective.

Others may place a higher value on the intra-application consistency of client-side decorations. Obviously, if, say, you're using KWin, but only GTK/Gnome apps you're probably going to prefer this option.

Thankfully, it seems that KWin[2] is going to allow both and is going to try to standardize a wayland protocol, so that users can choose what they want. Hopefully most Wayland clients will eventually respect this protocol -- we'll see.

EDIT: I should also just give a shout out to Mr. Gräßlin. He's been an incredible boon to KDE. (No affiliation, don't know him personally -- just a fan. Hopefully he'll read this!)

[1] For applications using different toolkits, obviously. Otherwise it doesn't really matter much except for misbehaving-application cases.

[2] http://blog.martin-graesslin.com/blog/2015/12/server-side-de...

IMO, to hell with consistency. Windows is perhaps the most inconsistent ecosystem out there, but at the same time the most used one.

> Client-side decorations are a compile-time switch. What the hell.

See my other comment here:

https://news.ycombinator.com/item?id=10759579

As a TWM user, I have no idea what you're arguing against. GTK-3 is prettier, more functional and normally more compact than GTK-2. On top of that, smooth scroll is a blessing and touch support was lovely for PDFs when I had a touch screen.

I just hate the new file chooser.

In GTK2 applications I can start typing the file name and the selector jumps to the file. E.g. I type "f", it jumps to the first file with name starting by "f", then I type "e" and it jumps to the first file with name starting with "fe", and so on.

In GTK3 they implemented some kind of filter, so when I type "f" the selector doesn't move but the dialog will show only everything containing "f" in its name, even in subdirectories! In big directories with many subdirectories and files it slows down everything while it's doing its filtering.

Yeah this is massively annoying. If you use arch there's https://aur.archlinux.org/packages/gtk3-typeahead/ which patches it back in.

And this is a great example of why Gnome is such a PITA: to change anything like that, you have to go download and install some extension, which of course will break the next time Gnome updates.

> Client side decorations give way more space to the actual content than to waste space for an almost empty titlebar. It allows to combine the titlebar with content from the application itself. You regard them entirely off as a "sin". Very strong language but you don't explain _at all_!

You can do that without client side decorations.

KDE with Qt even plans to allow telling the Window manager to render specific widgets in the toolbar.

The manager can ignore that, and render them as separate toolbar – or even render them in a bar at the top of the screen.

Ever used a tiling window manager? Client-side decorations are quite annoying to deal with, since otherwise I don't have title bars.

Also the Gtk developers are (probably) not evil, they just happen to also be the Gnome devs and have made some choices that are a little questionable to the rest of us.

Wait ... wait ...

I used ratpoison/ion3 from about 2000 through 2007 and then switched to OSX. So I never saw this ...

You're saying that in modern Xwin/Xorg, the actual applications have title bars and so on ... such that if I were using RP/ion I would see the titlebars ?

Is that what you're saying ?

That is what client side decorations are. The application draws in their own windows their own title bars / frames / min / max / close buttons and that will happen everywhere.

Go open the Steam client on Linux, it is using CSD so it always has min / max / close in the top right.

And when things lock up, you can't move or close anything because the buttons are unresponsive?

That's a sort-of-misconception, I think. AFAIK the client has to "advertise" the general location of the standard buttons, so if it's generally well-behaved, but just randomly locks up (via bug, not malicious intent), then you should generally still be able to close it.

(That's my understanding from the pro-CSD crowd, I'm personally pro-SSD, so I may have misunderstood unintentionally, but I think I'm being as charitable as possible in the above interpretation/description.)

Yes. Just tested starting a gedit and sending it Ctrl-Z in the terminal. Completely unresponsive window, can't drag titlebar, can't click on X. But that's what users want, right? Feature parity with Mac OS X and Windows.

Yep, Steam frequently locks up like that for me. It hasn't crashed, but it takes some jiggling to be able to click on any menu items within Steam again.

Yes, and no.

You'll see the titlebars anyway because they contain worthwhile controls now. You know, like with Chrome putting the close buttons on the tab bar. Evince (a document viewer) has the page number, back-next, find, annotate button, zoom controls, options dropdown and a lil' more on there, for example.

The other thing is that the control buttons you won't want are opt-out:

https://wiki.archlinux.org/index.php/GTK%2B#Client-side_deco...

Good thing they're optional, then.

https://wiki.archlinux.org/index.php/GTK%2B#Client-side_deco...

By diving the theme scripts and dumping a crapload of settings in there, lovely...

You only need the one line in ~/.config/gtk-3.0/settings.ini. The other stuff is for, well, theme stuff.

At least in this version of GTK. Disabling client-side decorations seems to be frowned upon, so expect this to break in the next Gnome release.

>Client side decorations give way more space to the actual content than to waste space for an almost empty titlebar.

That's a problem that's better solved by the window manager, not by the application.

I've been benefiting from additional screen space for various years. There's no specification to do this within the window manager. Even if there is, you need to think of Wayland as well.

Ideally it would be nice to enhance all window managers and somehow make this possible in a different way. You'd still have practical problems in that the theme of the window manager won't align with your toolkit though.

But I prefer actual progress instead of the theoretical ideal solution that's way more work and involves co-operation with everyone.

>But I prefer actual progress instead of the theoretical ideal solution that's way more work and involves co-operation with everyone.

Oh for the good old days when window management was so simple and straightforward, that all you had to do was memorize and follow every nuance and implication and extension of the ICCCM, before testing against every other application under all possible window managers in every platform environment with each possible hardware variation.

> Ideally it would be nice to enhance all window managers and somehow make this possible in a different way. You'd still have practical problems in that the theme of the window manager won't align with your toolkit though.

> But I prefer actual progress instead of the theoretical ideal solution that's way more work and involves co-operation with everyone.

You know what? Let's start by not making these silly thick titlebars, and not making these silly assumptions that everyone uses the library / framework of the day. Because these are actually idealistic and will never work out in practice.

GTK hasn't learned from the Windows 95 style GUIs (don't know any names) which never had any space problems in the first place. But I think it has a lot to do with portability to netbooks / tablets / smartphones in that they drove this development (look at Windows 8).

There are plenty of window managers that don't draw title bars (or anything)

I use one that merges the title bar and the task bar! Like so

https://i.imgur.com/Zb5BoMf.png

> Even if there is, you need to think of Wayland as well.

I prefer not to.

worked with GTK2/3 and QT 5+ years and got the feeling that GTK has been turning into the GNOME toolkit as well. not very pleasant to work with if you want your application to support the look&feel of different linux-DEs and not suited for cross-platform applications at all

GTK3 is perfect if you want to develop for the GNOME desktop. for anything else it would need way more developers that are not focused on GNOME

How is that surprising? The people that do the work get to set the course of the project; the Gnome devs are scratching their own itch.

QT caters to more platforms, because QT _is_ Digia/The QT company's product. For Gnome devs Gnome is the product.

So yeah, I agree with you: GTK3 is great if you do Gnome, QT otherwise. But some people in this thread (not you) seem to blame or resent Gnome developers for doing their jobs, which strikes me as odd, to say the least.

Well I really dont want to critize GNOME developers for working on free software, paid or not. But GTK is still perceived as a more universal toolkit than "just GNOME" and this might be a time-consuming surprise that hits application developers

furthermore it is still advertised like this as well (from gtk.org):

What is GTK+, and how can I use it? GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical user interfaces.

Where can I use it? Everywhere! GTK+ is cross-platform and boasts an easy to use API, speeding up your development time.

from my point of view, this is not exactly true anymore ..

GTK2 was a universal toolkit. Only with GTK3 the developers stated they're absolutely focusing only on a toolkit for GNOME and everyone else can take a hike.

> everyone else can take a hike.

More like: if anybody else wants to make GTK work better with other platforms, they're welcome to do it.

It may have been a universal toolkit, but if the people that made it so disappear, it's unlikely it will continue to be universal in the future; that's just the way it is.

>You go out of your way to imply that GNOME developers are intentionally evil.

Not really evil, just focused on other areas.

You are obviously a Linux desktop user.

From the article "The main reason behind the change was to better support Mac OS X, which is something of second-tier platform for GTK+"

From the perspective of 'UI toolkit for cross platform development' Qt is superior over GTK+. If you want the best Linux desktop toolkit GTK is probably a better choice.

"the best Linux desktop toolkit" depends primarily on the language you choose and the quality of its bindings to the toolkit

but consider that Qt aims to blend nicely into a GTK-based desktop environment, while its sometimes not even possible the other way round - eg using the "native" widgets of the desktop environment like file dialogs etc

"cross desktop environment" or whatever you might call this, is definitely not a top priority for the gtk-devs (see https://bugzilla.gnome.org/show_bug.cgi?id=735211 for example)

its all fine if you develop for GNOME only, but you should be aware of GTKs current limitations when it comes to writing applications that look nice on all linux desktops

and porting from one toolkit to another can be heaps of work, so choose wisely..

You mostly disagree with him entirely?

Reply on news.ycombinator.com