Hacker News Reader

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.

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

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