10 ms·

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 enabli

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.

scrollaway 11y ago
A few posts on the subject of CSDs, by the developer of KWin (he knows his shit): * http://blog.martin-graesslin.com/blog/2010/05/open-letter-the-issues-with-client-side-window-decorations/ http://blog.martin-graesslin.com/blog/2010/05/open-letter-th... * http://blog.martin-graesslin.com/blog/2010/05/why-you-should-not-use-client-side-window-decorations/ http://blog.martin-graesslin.com/blog/2010/05/why-you-should... * http://blog.martin-graesslin.com/blog/2010/05/follow-up-on-client-side-decorations/ http://blog.martin-graesslin.com/blog/2010/05/follow-up-on-c... * http://blog.martin-graesslin.com/blog/2015/11/october-plasma-on-wayland-update-all-about-geometry/ http://blog.martin-graesslin.com/blog/2015/11/october-plasma...
- ronjouch 11y ago
  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?
  - kuschku 11y ago
    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.
    - zanny 11y ago
      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.
      - kuschku 11y ago
        And that’s exactly what the KDE guys are aiming for ;)
        zanny 11y ago
        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.
        kuschku 11y ago
        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-candidate-for-kde-window-decorations/ https://kver.wordpress.com/2014/10/25/presenting-dwd-a-candi...
- DonHopkins 11y ago
  Is my vision going out, or is it snowing on those web pages?
  - kuschku 11y ago
    Yup, it’s snow.
moonchrome 11y ago
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 ...
- ronjouch 11y ago
  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.
  - ronjouch 11y ago
    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 https://wiki.gnome.org/Projects/GTK%2B/Inspector
  - anon4 11y ago
    Oh god thank you so much
creshal 11y ago
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.
- ronjouch 11y ago
  > 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.
  - creshal 11y ago
    That was in GTK2, not GTK3. GTK3 is even worse in that regard because it went full finger-input centric.
- anon4 11y ago
  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).
  - hugs 11y ago
    What about laptops with touchscreens? Not a valid use case?
bjourne 11y ago
> 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.
- ori_b 11y ago
  > c89 because some arcane compiler somewhere doesn't support c99 yet That would be Microsoft Visual C.
  - bjourne 11y ago
    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.
    - awalton 11y ago
      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.

scrollaway 11y ago

A few posts on the subject of CSDs, by the developer of KWin (he knows his shit): * http://blog.martin-graesslin.com/blog/2010/05/open-letter-the-issues-with-client-side-window-decorations/ http://blog.martin-graesslin.com/blog/2010/05/open-letter-th... * http://blog.martin-graesslin.com/blog/2010/05/why-you-should-not-use-client-side-window-decorations/ http://blog.martin-graesslin.com/blog/2010/05/why-you-should... * http://blog.martin-graesslin.com/blog/2010/05/follow-up-on-client-side-decorations/ http://blog.martin-graesslin.com/blog/2010/05/follow-up-on-c... * http://blog.martin-graesslin.com/blog/2015/11/october-plasma-on-wayland-update-all-about-geometry/ http://blog.martin-graesslin.com/blog/2015/11/october-plasma...

ronjouch 11y ago
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?
- kuschku 11y ago
  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.
  - zanny 11y ago
    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.
    - kuschku 11y ago
      And that’s exactly what the KDE guys are aiming for ;)
      - zanny 11y ago
        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.
        kuschku 11y ago
        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-candidate-for-kde-window-decorations/ https://kver.wordpress.com/2014/10/25/presenting-dwd-a-candi...
DonHopkins 11y ago
Is my vision going out, or is it snowing on those web pages?
- kuschku 11y ago
  Yup, it’s snow.

moonchrome 11y ago

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

ronjouch 11y ago
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.
- ronjouch 11y ago
  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 https://wiki.gnome.org/Projects/GTK%2B/Inspector
- anon4 11y ago
  Oh god thank you so much

creshal 11y ago

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.

ronjouch 11y ago
> 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.
- creshal 11y ago
  That was in GTK2, not GTK3. GTK3 is even worse in that regard because it went full finger-input centric.
anon4 11y ago
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).
- hugs 11y ago
  What about laptops with touchscreens? Not a valid use case?

bjourne 11y ago

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

ori_b 11y ago
> c89 because some arcane compiler somewhere doesn't support c99 yet That would be Microsoft Visual C.
- bjourne 11y ago
  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.
  - awalton 11y ago
    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.