Hacker News Reader

A few posts on the subject of CSDs, by the developer of KWin (he knows his shit):

Thanks! They're dense, will read them at home.

But looking at the first link (which is kind of a summary if my understanding is correct), I don't see any mention of the most important benefit to me: controls-in-titlebar.

Am I missing something? Is Martin avoiding it, or is it a non-problem that could have been solved without CSDs?

Indeed it is a non-problem that can be solved without CSDs.

In KDE, the current plan of some is to allow the window to give the window manager the info that it should put some widgets in the window bar.

The manager could then put them in the window bar – or at the top of the screen – or in a separate toolbar.

This provides the advantages, and avoids the disadvantages.

I have no idea why we do not have a freedesktop spec for this like with Notifications or StatusNotifiers. Honestly thinking about it I am wondering why all this information is not consolidated to one API standard, since it is all the application presenting information in the outlying shell. It seems like something that would make a lot of sense to make one extensible API standard for telling your desktop environment what you want to show users outside the application window.

And that’s exactly what the KDE guys are aiming for ;)

Is there any working group on it? I'd love to read more on what KDE is doing on the topic, my casual searches just find Dave Edmundson making some fantastic rants on how terrible the field is.

It’s currently only a bunch of ideas that the people are discussing, but Martin Graesslin has already shown interest in the idea as being a better solution, here the original post presenting the idea, I haven’t checked up on the topic for a whole year yet, though:

https://kver.wordpress.com/2014/10/25/presenting-dwd-a-candi...

I wonder if, in time, this won't morph into just telling the window manager the layout and widgets in your window... then we can have full abstraction over all widget toolkits. Like, you send it some sort of xml description of your window and callbacks are delivered over dbus. Maybe we can also include a scripting language to do some light scripting of the controls so simple operations don't go over the entire callback mechanism.

Is my vision going out, or is it snowing on those web pages?

Yup, it’s snow.

> However, does GTK have much choice given the resources at hand?

Well, maybe I'll get some flack for saying this without providing much evidence. But they aren't a very welcoming group. They have been very insular and tied to RedHat which is driving a lot of the GTK development.

The GTK developers are also incredibly resistant to changes. For example, the code base is still required to follow c89 because some arcane compiler somewhere doesn't support c99 yet and because the greybeards at RedHat thinks it looks nicer with all the variables declared at the top. New developers also struggle with autotools and there has been several calls on the mailing list to replace it with something else (virtually anything) but those suggestions also get shot down because autotools is what the GTK developers know and use.

Just to be clear, I'm not blaming. It is not objectively wrong to be incredibly resistant to change. And GTK is a decent and very polished product. But it is one of the main reasons why GTK doesn't get a lot of new contributors, or resources as you call them.

> c89 because some arcane compiler somewhere doesn't support c99 yet

That would be Microsoft Visual C.

I don't think building GTK with MSVC is supported anyhow? :) Maybe it works now, it used to require a unixy toolchain. And the compiler has gotten a lot of c99 features since 2013. In practice, you could always set the compiler to c++ mode and everything would compile just fine.

GNOME software is written conventionally so you can't just "put things in C++ mode and it's fine" - lots of churn would be needed to make it C++-clean (e.g. the 'class' and 'new' keyword are used as variable names, etc).

Gtk+ on MSVC is supported, sadly. It'd be really nice if it weren't, because then glib could be C99 and we'd all be really happy about it - the glib developers aren't stooges refusing to go forward, they're stuck between a rock and a hard place by Microsoft's amazing reluctance to build anything resembling a sane compiler and over a decade of binary stability.

Yeah, Gtk+ could've thrown the "fuck you" to the Microsoft compiler when they broke for 3.x, and in a lot of ways, I wish they would have, but making those decisions usually means porting software, and so nobody's willing to do it in a 3.x branch. Maybe when the fabled Gtk+ 4.x rolls around.

But we aren't talking about all GNOME software, we're only talking about GTK+ and perhaps supporting libraries like glib, gobject, pango etc. It's not hard to write gobject-based C code which compiles in msvc's c++ mode. I know because I have done it myself.

On a cursory grep through the gtk+ codebase, I can't find a single use of "new" as a variable name and only a scant few instances of "class". The gtk+ coding guidelines already recommends you to write "klass" instead of "class" probably for this reason. Replacing the remaining bad names isn't an onerous task. It's a days work for one person at most.

I'm very involved with (lately less so, been busy) and IMO you're pretty accurate.

Some more details: Replacements for autotools often only handle the simple case. Widely known that autotools is difficult, however, the replacements cannot do what the GTK autotools is used for at this moment.

For the compiler: I think the Microsoft compiler is holding us back? Further there are two important parts: glib is used almost everywhere, so you have to be very strict in what you accept. GTK+ should be more easy going. They did add that support for (IIRC) automatically freeing variables.

Tied to Red Hat is very unfortunate. However good willed, it is better if there is a group of similar sized companies. I'd wish there were more (free software) companies the size of Red Hat.

Autotools can be replaced. I know because I've done it. :) And so have KDE which replaced it with cmake. But unless you have a redhat.com address, good luck trying to convince the GTK developers that it should be done. It's essentially Red Hat's product and they decide what to do with it. Which makes it very hard for contributors to drive meaningful change which makes few contributors interested -> resource shortage.

So if the question is "why does GTK have a resource shortage when Qt does not?" then, imho, that is very easy to answer.

This is what forks are for, isn't it? If it's that simple, I'd think a fork could pretty easily start to solve some of GTK+'s issues.

From my perspective, GTK has been mired for a very very long time. Essentially from its inception it was something that was required for other missions. There have been tons of volunteers and people working on it but I'm not sure how much of that was because they needed it vs because that's what they love to do. I also have some suspicions that certain UXy/visual type problems just don't seem to be good fits for the bazaar model, all my evidence would be tied to GNOME, GTK, and GIMP for the most part so I could see how I might be wrong. If it's being held back by some Redhat folks that are paid to maintain it because Redhat went all in with it decades back, a fork could potentially revitalize it.

> and because the greybeards at RedHat thinks it looks nicer with all the variables declared at the top.

Why do people always assume newer = better? Get the basics right. Yes, declaring your variables at the top does usually look nicer. It requires more code discipline, it often forces you to better decompose your code, but usually results in better code structure and readabilty.

C is not a language to program at scripting speed in the first place.

[citation needed]. This is pure personal taste (and has nothing to do with C vs. any other language, unless by "C" you mean K&R era)

The notion of cohesion is actually fairly common. Declaring variables at the top helps cohesion. It makes obvious when too much is done in one procedure.

Among other small refinements, C99 is a set of features on top of C90, such as declarations anywhere, restrict pointers, and complex numbers. If you don't need these features, restricting to C90 is a very effective way to have your code auto-linted.

Yes, I agree with the upsides to declaring variables at the top.

However, declaring variables close to where they use is a different kind of "cohesion", since it's keeping related things together -- just related in a different way.

I see your point, but it's still a matter of taste.

> However, declaring variables close to where they use is a different kind of "cohesion", since it's keeping related things together

Cohesion is about keeping unrelated things apart (to avoid accidental complexity).

If two things are semantically unrelated, you should be able to name both (yes, it is hard). If you want the separation statically asserted keep them syntactically separated [1]. There you go -- make two smaller functions, each with a clear scope and a descriptive name.

If you feel a function is doing unrelated things (because the data is not very "cohesive") but can't tell why, why not being honest about it and still host all the variables at the top.

Being disciplined in this way has found me appropriate code factorings, and many bugs in previously ill-factored code, both syntactic and semantic.

[1] in John Carmack's words "what's syntactically allowed will eventually end up in your codebase"

>Why do people always assume newer = better

I can't help but to notice the irony of your statement in a thread about GTK3 (since they are ripping out functionality in the pursuit of newness)

One big thing about GTK is how inefficient with space it is. I like that kind of design in Gnome and stuff where the interaction is minimal and the UI is just about presenting content - but it completely sucks for tool development.

Just look at stuff like Gimp and Inkscape - those things are atrociously bad from GUI perspective - huge ugly icons, huge panels with pointlessly large input fields/sliders and other controls - the ammount of space you need to scan and is effectively wasted is staggering.

It's like they want to make GTK+ a toolkit for pretty "two button apps" and "image viewer software with all the controls on the toolbar". Don't get me wrong - I like those designs - but those are of very very limited use - doing anything complex in GTK+ is just a no-go as shown in numerous IDEs/tools that use it. It's just built with the wrong set of defaults IMO. And I have no doubt that with some work you could reshape it to be much more usable - but the thing is most developers don't have that kind of knowledge, time or affinities.

If it integrated into native file dialogs and such I wouldn't care if it "looks non native" - intellij IDEA looks non-native as well - it still looks great. Can you imagine how IDEA would look like if it used GTK+ controls ...

True. I hate this padding so much I get rid of most of it with this ~/.config/gtk-3.0/gtk.css :

    GtkToolbar {padding: 1px;}
    GtkButton {padding: 4px;}
    GtkComboBox GtkToggleButton {padding: 2px;}

On this side, it feels like the GNOME folks are just trying to shoehorn a start of tablet-friendliness ("two button apps" with huge padding). I wish they had instead a "Tablet" on/off switch that would increase/decrease padding.

Hint if you're looking for other css selectors to make additional customizations: to inspect any GTK3 app under GNOME ≥ 3.14, just set the gsetting mentioned at [1], and Ctrl+Shift+I to get a Chrome/Firefox devtools-like inspector :)

[1] https://wiki.gnome.org/Projects/GTK%2B/Inspector

Oh god thank you so much

> Just look at stuff like Gimp and Inkscape - those things are atrociously bad from GUI perspective

GTK exists because of Gimp. Gnome came later. Sadly, the GUI of Gimp is still behind of Photoshop.

Gnome 2 and KDE 3 were fine, then everthing went downhill. Nowadays Ubuntu and Gnome2-fork (Mint) are okay.

Maybe implement a transparent theme that looks familar to Vista/Win7 users? Most users aren't that happy with the Win8/10 theme, that can't be changed.

I know what GTK stands for :) I'm just saying it fails at that use case. It's actually fine for Gnome, I don't mind Gnome 3 at all, took some getting used to but it's working fine for me and I like the way it looks with some themes and extensions (Arc theme is great IMO and dock extension + alt-tab no group is all I need). Where GTK+ fails is providing GUI components that can be compact and information dense, all of it's widgets and layouts are designed arround white space heavy low density content/GUI - that just doesn't work for complex apps - GIMP/Inkscape being prime examples of bad GUI it creates.

I elaborated on the general problems with them above, and Martin's blog posts are on spot.

It really is more of a theming problem – Gnome 2's standard themes were in the really awkward spot where the controls are far too big than they need to be for mouse or stylus input, yet not big enough for touch input.

(Back then, I had a stylus-enabled X60 Tablet – with a whopping 1024x768 12" screen. I modded my GTK2 theme to have 8x8, 12x12 controls and icons, instead of the standard 24x24, 48x48. 30% more usable screen size without any changes to applications.)

With Gnome 3 deciding to focus on touch screens, they had to do… something! And that something was making controls even bigger. And to offset that, they decided to introduce CSDs. There's a dozen other ways that could have been taken instead, like not using a touch interface on non-touch devices.

> Gnome 2's standard themes were in the really awkward spot where the controls are far too big than they need to be for mouse or stylus input, yet not big enough for touch input.

Completely agreed, see my other answer to user `moonchrome`: I, too, make tweaks to my gtk.css to fix this, and I wish they had instead a "Tablet" on/off switch that would increase/decrease padding and widget sizes.

That was in GTK2, not GTK3. GTK3 is even worse in that regard because it went full finger-input centric.

I call bullshit on the theory that Gtk devs decided to focus on touch. There are exactly 0 projects for tablets running vanilla linux distros (i.e. not Android).

What about laptops with touchscreens? Not a valid use case?