It's a shame how far GTK is falling behind. From a user's perspective, I liked GTK2's smooth, clean interfaces much more than anything made in Qt, so much that I didn't even mind putting up with its insane APIs.
But now? GTK3 interfaces are horrible from an user's perspective – client-side decorations are a sin that we should know better than to repeat, plus a whole load of changes just for change's sake to spite users (the file chooser dialog has a much worse UX; mouse wheel support was widely gutted because apparently I'm supposed to want touch interfaces instead?) –, and the APIs are still as bad to use, most changes seem to have been made out of spite; a small shim would have allowed most programs to switch from GTK2 to 3 without code changes, had it not been for those.
Now I find myself increasingly switching to Qt programs. While the interfaces are still somewhat rougher than GTK2 ones and not as unified, it still beats GTK3 crap. That seems to be turning from "a reasonable toolkit for all X11 invironments" into "the official Gnome 3 toolkit, beg us if you want interoperability".
If only it was! It would then fit in with the OS on OSX. As it currently is, it sticks out like a sore thumb and feels like you've SSH'd to a remote Linux box.
Yes, for the most part. Many of them spew messages to the console log for bad font handling etc. but for the most part they look native.
wxWidgets is different because the code is native - it is a C++ wrapper around the Cocoa code, so you make calls in C++ and it actually calls Obj-C code behind the scenes (plenty of .mm files in wxWidgets). I do not know if Qt does this or whether they do their own drawing of controls in some instances. (wxWidgets does draw some of its own controls, eg. toggle button on platforms older than Yosemite/El Capitan I think)
It really is. GTK can basically be used with any language, C bindings are extremely common and there are bindings for all my favorite languages, Go, Rust, C#, etc.
But the Windows compatibility of GTK is just horrendous. It seems to work now with the help of some people GTK 3+ can be used on Windows, but the icons sometimes don't work, transparency never works, expander window grippy thing doesn't look right, fonts look terrible, responsiveness is terrible, form fields look terrible and don't function normally, the list goes on and on.
I think Qt is great, but because its C++ the bindings just aren't there. Python has excellent bindings but that is a huge project in itself.
If there was a decent C port of Qt then you'd get support for almost every language (well any one worth its salt) through things like ffi.
I'm sure going from your favorite language through FFI to some C wrapper around a C++ library isn't the most efficient thing in the world, but for UI programming it shouldn't matter.
AFAIK both GTK and GIMP severely lack Windows contributors - what else is to be expected, than shitty experience on that platform? If I remember well, a few years ago GIMP even stoped publishing it's Windows builds, because there wasn't no one to take care of them. Complaining won't make much of a difference - but sending bug reports, patches will.
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.
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.
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.
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).
> 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.
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.
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.
> 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.
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)
> 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.
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.
> 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.
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 ?
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.
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.
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:
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.
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.
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
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..
Can you elaborate why "client-side decorations are a sin that we should know better than to repeat" ? From a subjective user perspective, I like them for enabling controls in titlebar, which paved the way for compact, elegant windows --i.e. height(clientside_titlebar_with_controls) < height(regular_titlebar + menubar + toolbar)--. What's objectively bad about them?
Other than that, describing GTK3 as "the official Gnome 3 toolkit, beg us if you want interoperability" seems pretty accurate. I personally enjoy the experience provided by GNOME 3, but will never, ever, use a GTK app under Windows or Mac OSX. They just look and feel terribly out of place.
However, does GTK have much choice given the resources at hand?
- With the Adwaita theme now being rolled into GTK itself, it's becoming clear the GNOME/GTK folks are not aiming at a good Mac/Windows experience, they're maximizing for Linux + the whole GNOME shebang.
- Could they do otherwise? Qt is backed by a big team at the Qt Company (ex Digia / Nokia / Trolltech) with commercial interest to support big $$$ Windows/Mac-based enterprise apps, while GTK seems maintained by a smaller core team of RedHat/Fedora folks, Canonical not so much, and individual contributors. I think they're just focusing.
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?
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.
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:
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.
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 ...
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 :)
> 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.
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).
> 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.
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.
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"
Frankly, I don't care about GTK vs. Qt. From a user standpoint, what I wish for the most is that apps have a unified look and consistency. File dialog bookmarks should be synced. If I change theme in one, it should change theme in the other. If I change fonts in one, it should change fonts in the other. If I plug in a 4K display, all apps should scale DPI identically.
And from a programmer's standpoint, I wish we could end this battle already and someone just tell me what to use so that my app can become a part of everyone else's consistent look.
At this point in time i feel the Linux world is split in two camps.
The "old" camp that has been with the ecosystem since the late 90s, and the new camp that came in with the post-dot-com/browser-war cheap and easy access to LAMP servers.
The former knows Linux from the kernel up, where the desktop is for the most part a way to deal with things that can't be represented in text.
The latter knows Linux from the desktop down, and want those shiny graphics everywhere.
GTK2 is of the old group, where tweaking and maximizing personal efficiency was king.
GTK3 is old the new group, where presenting some kind of top down design experiences is paramount.
Hell, it may not even be limited to Linux. Look at how Slack is getting all manner of attention, even though at its base it is IRC recreated. But now you can plaster every line with emoji(?!).
Damn it, i should not be feeling like a grumpy old geezer. I'm not even half way to retirement...
Slack may be IRC recreated, but at least for groups/businesses, they've definitely fixed a lot of the pain points of IRC. No arcane signup process, extremely simple sharing of files, perpetual history, etc.
I kinda feel like Gnome/GTK peaked about 2001 or 2002, and has been in a steady decline ever since. OTOH, KDE/QT hit a local maxima around the same time, then dropped off, but has been improving for the past couple of years (with a few small ups and downs mixed in).
I've switched to KDE Plasma desktop on Fedora as my primary work environment now and couldn't be happier. If I wanted to write a native X app now, I'd definitely be thinking QT.
When QT first switched to LGPL, I hoped it would result in an explosion of interest in that environment. In hindsight, "explosion" would probably be an overstatement, but the K/QT world does seem to have been growing and improving since then.
> There are many more keyboard shortcuts in Wireshark 2. The full list of those shortcuts can be found from the "Help" menu. In addition, individual windows have their own shortcuts, which can be listed from the window itself.
More keyboard shortcuts always makes me happy. Less usage of that tiny little touchpad on my laptop.
Please stop with the HTML5 UI madness. While HTML/CSS is, imo, a great UI toolkit, nobody wants a browser engine in every separate application. A browser engine that needs to be kept up to date with upstream on an extremely regular basis, separately for every app, lest you are vulnerable to whatever exploit of the month.
It's a browser engine running trusted code (i.e., code that is currently running with full privileges on your account), so the attack surface is much lower than a browser engine visiting random web pages. Wireshark won't suddenly start playing a Flash animation or use WebGL or anything.
And it's not like GTK+ or Qt are immune from having security vulnerabilities. They're rarer than the general class of browser vulnerabilities, but they exist (e.g. Qt had a few image decoder vulnerabilities earlier this year). I'd guess they're about as frequent as the specific subset of browser vulnerabilities when viewing a trusted website.
If it's a helpful analogy, this is roughly like how Java is a terrible platform for running untrusted applets, but a perfectly fine platform for running software and a very common one for security-sensitive servers. (Except the browsers themselves are way better than the Java plugin.)
You must be joking by complaining about the need for security updates. Most apps need regular updates regardless of platform. Have you seen how often MS office or Adobe apps get security patches? Arguably the security of Chromium is better because of how widely it's used and tested.
On top of this, Qt 5 is a browser engine. Kind of. That is what QML is meant to be. Its application javascript done right, rather than the mutant horrible diaster that is web standards. If you write a full application in QML today and experience how amazingly easy it is to do fancy visual effects since the whole thing is hardware accelerated you will never be able to develop web app code again without desperately praying for sweet release.
I dream of the day QML is standardized as webapp tech in browser standards, so we can have cross platform native applications over the browser that use a reasonable programming paradigm rather than trying to turn markup documents into mission critical applications.
Couldn't agree more. I've used QML for a Go app and the sanity prevalent in QML vs. web standards is like night and day.
I actually don't want anything more to do with web front end development - leave all the react/flux/angular nonsense to the JS package manager of the month crowd.
So I have used QML plenty too and it isn't all that great honestly. In fact in many ways it is backwards.
For example, all Qt widgets instantiated via C++ can be styled using an external stylesheet, but not so for QML stuff. All the margin, padding you have to specify inline in the code. If that is not going backwards, I dunno what is.
Ah well that may be an area I've yet to encounter - I've used a third-party set of qml widgets styled to adhere to googles material visual vocab, so it has been trivial to style up applications that look and act fantastic.
Though I will say that the inability to expose a go strict/object as a model is quite frustrating; there's lots of back and forth mapping your go objects to update your qml models. It would be much nicer if it was easy to implement as adhering to an interface or embedding an existing type :(
This is how many new apps are coming out using QML and doing their own custom UI theming rather than doing system default. It also beats the hell out of CSS by using the same object model relationships you are already using when laying out QML objects.
Yes, if you use language primitives like rect's and text's then you have to create either your own theming engine template classes and then use those, or manually manage all the styling per object. But then you are doing it wrong if your project does not warrant that kind of ground up custom craftsmanship.
Note that 2.0 still can be used with GTK. I'm a daily wireshark user and had to switch back to the GTK version - the Qt version is currently incredible buggy - at least on Windows.
Yeah, I've noticed a few issues, particularly with copying bytes via context menus, sometimes the sub menus don't appear. Ah well, overall I'm glad they went in this direction as now I can use it on my MacBook without having to get X11.
I've found it locks up on Linux sometimes. Like I found Clementine when I was stuck on Windows. Having worked with QT, and it's asynchronous'ness, I can see it's easy to make dead lock mistakes, and I think that is probably what is happening.
I'd say good riddance GTK3. I really liked GTK1/2, to be honest. I liked the column-based (unixy) file dialogs, detachable menus that you could use as a poor-mans toolbars, and many minor tweaks.
The API was always horrendous (it still is!), but as user I liked it so I just coped as a developer anyway.
Since the full embrace of gnome, I started to dislike GTK2/3 more and more. The stupidity of file dialogs starting in "recents mode" also for save, to name one. Saving a file again? You see restarting at the top directory, just like in windows. Well, it's because the file dialogs don't have any saved state if you happen to destroy the dialog instance. A tweak that costs literally nothing to implement, but probably "not granma friendly"?
GTK3 is also downright slow. The new theming mechanism might be fancy, but objectively I have some UIs that I left at GTK2 intentionally for lower latency.
I re-evaluated QT4 as a user. The API and developer tools are just light-years ahead.
It's unfortunate that I cannot say I like the evolution of QT5.
As for GTK3, rendering performance, latency and memory usage in QT5 suffer significantly. QT4 is not light, but QT5 adds overhead for no reason.
I like the general polishing in the core modules, but I have really no use for qtquick. For this reason, I really encourage anyone to get onto copperspice (http://www.copperspice.com/). Without MOC, QT really feels an awesome API.
While I can't say I've experienced any significant memory usage or latency issues (possibly because I'm targetting recent hardware and working with large volumes of data), I'm completely in the same boat with QtQuick and CopperSpice does look quite interesting, I'll have to check it out.
I use Qt a lot on smaller embedded targets and I haven't moved to 5. Don't really want to mess with the new windowing system and I can't put Wayland/Weston on a lot of my smaller projects.
I'm pretty much locked into 4.8 (and it's eternally open tickets) for life.
The thing to note here is that the stripped out the windowing system implementation for embedded machines. So if you're using framebuffer without X11 or Wayland you're on your own for windowing now, which was previously provided in Qt4.
That's my understanding at least, I don't use Qt on embedded platforms though, can anyone confirm this?
Yes, MOC and QT's C+++ is really an awful thing. Copperspice being just normal C++ is interesting. Have to see what happens. But for me, C is where my heart is, so there is still two + that need to go for me. ;-)
I use Qt5 extensively and these are the things I don't like (mostly QML-specific):
* It's HUGE. A "hello world" QML program is like 50 MB. You can get it down to about 20 MB is you use a custom Unicode library build (there is a 20 MB DLL which just contains Unicode data).
* The QML compiler is only in the commercial version. I know there is a third party open source version, but that is too much hassle. And yeah maybe I should pay, but hey!
* Lots of things still are impossible with QML. There's no decent basic text widget (e.g. for a log output).
* You can make custom QML widgets, but they can't render text. Kind of limiting!
* I don't think the basic premise of QML works that well. There is such a big difference between C++ types and QML types most of your code ends up dealing with the mapping. Especially lists of things are very hard to get right (and the documentation doesn't really point you to the "right" solution - which is to subclass QAbstractListModel if you were wondering).
* QML seems very hacky and javascripty - it doesn't scale well. Especially scopes and id's.
* Some QML things are weirdly hard, for example
- Rich tooltips
- Adding padding around list items
- Doing anything with the rich text widget.
That said, I still really like it. I'd just like it more if they:
1. Reduce the size.
2. Redo QML (again!). I'd be even ok with a custom language. It can be similar to Javascript, but it should support the native C++ Qt types (and custom ones) much easier.
It might be, but last time I tried Qt on mobile I ended up redoing the app in Java, C++/CX with XAML with C++ for the common code.
The effort for doing from scratch native widgets in QML was greater than the approach I took, specially because Qt didn't provide wrappers for the APIs I cared about.
Two things about Witeshark that I hadn't realised until recently but that changed my life:
- Wireshark has a Command Lime Interface that is very usable and incredibly useful to debug a machine you can only ssh to: tshark
- you can look at packets captured with tcpdump with Wireshark/tshark
browser.html makes more sense. Web standards are, at this point, their own form of GUI toolkit, and why does Firefox need more than one? It is just bloat.
Mozilla rejected this webbiness approach in their own release on Android using the excuse that Android applications cheat because Android runtime is always loaded in memory, while any other runtime has to be loaded which causes a startup delay. It actually caused them to kill Fennec which had portable UI, and instead create an unportable Android UI.
So if they already stick with native UIs, let them use Qt.
Watched someone via GoToMeeting try to use 2.0 yesterday on a Windows server. They couldn't start capture on the interface; start button grey'd out with no explanation. Installed the older version (1.12.8) and it worked perfectly. QT is great and all but I'll have to stick with the legacy stuff for a while.
I've used 2.0 on a Server 2016 TP4 and two different Windows 10 with zero problems. The person you've seen running it probably didn't install Winpcap or something along those lines, hence why installing 1.12.8 solved the issue.
My main criticism is that I don't get a separate window telling me the progress of the file loading. I work sometimes with big files and it takes a few seconds to load them. On 2.0 at first I didn't know what was going on, because there's only this very tiny progress bar at the bottom.
152 comments
[ 6.8 ms ] story [ 266 ms ] threadBut now? GTK3 interfaces are horrible from an user's perspective – client-side decorations are a sin that we should know better than to repeat, plus a whole load of changes just for change's sake to spite users (the file chooser dialog has a much worse UX; mouse wheel support was widely gutted because apparently I'm supposed to want touch interfaces instead?) –, and the APIs are still as bad to use, most changes seem to have been made out of spite; a small shim would have allowed most programs to switch from GTK2 to 3 without code changes, had it not been for those.
Now I find myself increasingly switching to Qt programs. While the interfaces are still somewhat rougher than GTK2 ones and not as unified, it still beats GTK3 crap. That seems to be turning from "a reasonable toolkit for all X11 invironments" into "the official Gnome 3 toolkit, beg us if you want interoperability".
wxWidgets is different because the code is native - it is a C++ wrapper around the Cocoa code, so you make calls in C++ and it actually calls Obj-C code behind the scenes (plenty of .mm files in wxWidgets). I do not know if Qt does this or whether they do their own drawing of controls in some instances. (wxWidgets does draw some of its own controls, eg. toggle button on platforms older than Yosemite/El Capitan I think)
But the Windows compatibility of GTK is just horrendous. It seems to work now with the help of some people GTK 3+ can be used on Windows, but the icons sometimes don't work, transparency never works, expander window grippy thing doesn't look right, fonts look terrible, responsiveness is terrible, form fields look terrible and don't function normally, the list goes on and on.
Qt makes that relatively easy and painless.
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.
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
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.
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 ..
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.
Not really evil, just focused on other areas.
That's a problem that's better solved by the window manager, not by the application.
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.
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.
> 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).
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
Will never happen. Instead, if you want consistency, avoid redundancy in the first place (where it's practical)
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.
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?
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...
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.
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.
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.
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 ?
Go open the Steam client on Linux, it is using CSD so it always has min / max / close in the top right.
(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.)
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...
https://wiki.archlinux.org/index.php/GTK%2B#Client-side_deco...
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.
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.
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..
Other than that, describing GTK3 as "the official Gnome 3 toolkit, beg us if you want interoperability" seems pretty accurate. I personally enjoy the experience provided by GNOME 3, but will never, ever, use a GTK app under Windows or Mac OSX. They just look and feel terribly out of place.
However, does GTK have much choice given the resources at hand?
- With the Adwaita theme now being rolled into GTK itself, it's becoming clear the GNOME/GTK folks are not aiming at a good Mac/Windows experience, they're maximizing for Linux + the whole GNOME shebang.
- Could they do otherwise? Qt is backed by a big team at the Qt Company (ex Digia / Nokia / Trolltech) with commercial interest to support big $$$ Windows/Mac-based enterprise apps, while GTK seems maintained by a smaller core team of RedHat/Fedora folks, Canonical not so much, and individual contributors. I think they're just focusing.
* http://blog.martin-graesslin.com/blog/2010/05/open-letter-th...
* http://blog.martin-graesslin.com/blog/2010/05/why-you-should...
* http://blog.martin-graesslin.com/blog/2010/05/follow-up-on-c...
* http://blog.martin-graesslin.com/blog/2015/11/october-plasma...
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?
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.
https://kver.wordpress.com/2014/10/25/presenting-dwd-a-candi...
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 ...
[1] https://wiki.gnome.org/Projects/GTK%2B/Inspector
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.
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.
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.
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.
That would be Microsoft Visual C.
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.
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.
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.
So if the question is "why does GTK have a resource shortage when Qt does not?" then, imho, that is very easy to answer.
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.
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.
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.
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.
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"
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)
And from a programmer's standpoint, I wish we could end this battle already and someone just tell me what to use so that my app can become a part of everyone else's consistent look.
No great loss.
The "old" camp that has been with the ecosystem since the late 90s, and the new camp that came in with the post-dot-com/browser-war cheap and easy access to LAMP servers.
The former knows Linux from the kernel up, where the desktop is for the most part a way to deal with things that can't be represented in text.
The latter knows Linux from the desktop down, and want those shiny graphics everywhere.
GTK2 is of the old group, where tweaking and maximizing personal efficiency was king.
GTK3 is old the new group, where presenting some kind of top down design experiences is paramount.
Hell, it may not even be limited to Linux. Look at how Slack is getting all manner of attention, even though at its base it is IRC recreated. But now you can plaster every line with emoji(?!).
Damn it, i should not be feeling like a grumpy old geezer. I'm not even half way to retirement...
I've switched to KDE Plasma desktop on Fedora as my primary work environment now and couldn't be happier. If I wanted to write a native X app now, I'd definitely be thinking QT.
When QT first switched to LGPL, I hoped it would result in an explosion of interest in that environment. In hindsight, "explosion" would probably be an overstatement, but the K/QT world does seem to have been growing and improving since then.
More keyboard shortcuts always makes me happy. Less usage of that tiny little touchpad on my laptop.
And it's not like GTK+ or Qt are immune from having security vulnerabilities. They're rarer than the general class of browser vulnerabilities, but they exist (e.g. Qt had a few image decoder vulnerabilities earlier this year). I'd guess they're about as frequent as the specific subset of browser vulnerabilities when viewing a trusted website.
If it's a helpful analogy, this is roughly like how Java is a terrible platform for running untrusted applets, but a perfectly fine platform for running software and a very common one for security-sensitive servers. (Except the browsers themselves are way better than the Java plugin.)
If you are hiding the fact that you're browsing pages random page from the web in your native UI, then you have bigger problems than the update cycle.
I dream of the day QML is standardized as webapp tech in browser standards, so we can have cross platform native applications over the browser that use a reasonable programming paradigm rather than trying to turn markup documents into mission critical applications.
I actually don't want anything more to do with web front end development - leave all the react/flux/angular nonsense to the JS package manager of the month crowd.
For example, all Qt widgets instantiated via C++ can be styled using an external stylesheet, but not so for QML stuff. All the margin, padding you have to specify inline in the code. If that is not going backwards, I dunno what is.
Though I will say that the inability to expose a go strict/object as a model is quite frustrating; there's lots of back and forth mapping your go objects to update your qml models. It would be much nicer if it was easy to implement as adhering to an interface or embedding an existing type :(
http://doc.qt.io/qt-5/qtquickcontrolsstyles-index.html
This is how many new apps are coming out using QML and doing their own custom UI theming rather than doing system default. It also beats the hell out of CSS by using the same object model relationships you are already using when laying out QML objects.
Yes, if you use language primitives like rect's and text's then you have to create either your own theming engine template classes and then use those, or manually manage all the styling per object. But then you are doing it wrong if your project does not warrant that kind of ground up custom craftsmanship.
https://www.cloudshark.org/captures/184a2df0b16d
The API was always horrendous (it still is!), but as user I liked it so I just coped as a developer anyway.
Since the full embrace of gnome, I started to dislike GTK2/3 more and more. The stupidity of file dialogs starting in "recents mode" also for save, to name one. Saving a file again? You see restarting at the top directory, just like in windows. Well, it's because the file dialogs don't have any saved state if you happen to destroy the dialog instance. A tweak that costs literally nothing to implement, but probably "not granma friendly"?
GTK3 is also downright slow. The new theming mechanism might be fancy, but objectively I have some UIs that I left at GTK2 intentionally for lower latency.
I re-evaluated QT4 as a user. The API and developer tools are just light-years ahead.
It's unfortunate that I cannot say I like the evolution of QT5.
I like the general polishing in the core modules, but I have really no use for qtquick. For this reason, I really encourage anyone to get onto copperspice (http://www.copperspice.com/). Without MOC, QT really feels an awesome API.
I'm pretty much locked into 4.8 (and it's eternally open tickets) for life.
Huh? Qt5 doesn't require Wayland; I've used it on X.
Yeah, um, not possible for me. I use the Linux framebuffer and that's it.
http://doc.qt.io/qt-5/embedded-linux.html
That's my understanding at least, I don't use Qt on embedded platforms though, can anyone confirm this?
http://doc.qt.io/qt-5/embedded-linux.html http://stackoverflow.com/a/21489384/331041
* It's HUGE. A "hello world" QML program is like 50 MB. You can get it down to about 20 MB is you use a custom Unicode library build (there is a 20 MB DLL which just contains Unicode data).
* The QML compiler is only in the commercial version. I know there is a third party open source version, but that is too much hassle. And yeah maybe I should pay, but hey!
* Lots of things still are impossible with QML. There's no decent basic text widget (e.g. for a log output).
* You can make custom QML widgets, but they can't render text. Kind of limiting!
* I don't think the basic premise of QML works that well. There is such a big difference between C++ types and QML types most of your code ends up dealing with the mapping. Especially lists of things are very hard to get right (and the documentation doesn't really point you to the "right" solution - which is to subclass QAbstractListModel if you were wondering).
* QML seems very hacky and javascripty - it doesn't scale well. Especially scopes and id's.
* Some QML things are weirdly hard, for example
- Rich tooltips
- Adding padding around list items
- Doing anything with the rich text widget.
That said, I still really like it. I'd just like it more if they:
1. Reduce the size.
2. Redo QML (again!). I'd be even ok with a custom language. It can be similar to Javascript, but it should support the native C++ Qt types (and custom ones) much easier.
QML is designed with mobile in mind. For heavy desktop UI, Qt Quick Components, kinda fills the need.
Qt Quick 3 would be unwarranted, but a lot of maturation needs to happen.
The effort for doing from scratch native widgets in QML was greater than the approach I took, specially because Qt didn't provide wrappers for the APIs I cared about.
Jokes aside (sorry), it's an absolute godsend when trying to debug embedded systems.
Life saver when debugging even mundane web servers:
This is one place where TLS (https) everywhere is a pain.https://github.com/mozilla/browser.html
So if they already stick with native UIs, let them use Qt.
My main criticism is that I don't get a separate window telling me the progress of the file loading. I work sometimes with big files and it takes a few seconds to load them. On 2.0 at first I didn't know what was going on, because there's only this very tiny progress bar at the bottom.