Re: CSS to look more like Gtk+ 2
- Date: Mon, 19 Dec 2016 14:01:47 +0000
- From: Emmanuele Bassi <ebassi@xxxxxxxxx>
- Subject: Re: CSS to look more like Gtk+ 2
On 19 December 2016 at 13:39, Nicolas George <george@xxxxxxxx> wrote:
>> Not that I know of, but I am far from an expert in this area. I am
>> just someone so sick of the "new look" that I felt the urge to start
>> designing my own themes. If you find a way, please let me know. I
>> don't like client-side decorations either.
I honestly could live without the contempt and entitlement that have
been expressed in this (and other) threads.
I've already had to say this multiple times, but I guess I'll to keep
repeating this forever because people do not look in the archives:
It's an application developer prerogative and request to use
client-side decorations. The toolkit, in this case GTK+, only provides
the API — and the API is provided because application developers and
designers asked for it, not because the code appeared fully formed in
our Git repository.
> Michael suggested PCMan/gtk3-nocsd.
"gtk3-nocsd" is a massive hack that undoes what application developers
want to achieve in the first place.
If you want for applications that you use to *not* use client-side
decorations, please: open a bug against those applications.
Of course, there's the chance of those bugs getting closed because
application developers do not want to have two different user
interfaces for their code.
> I think a more reliable approach would be to `apt-get source libgtk-3-0`,
> edit gtk/gtkwindow.c, change gtk_window_should_use_csd() to give more
> precedence to $GTK_CSD than to priv->csd_requested, and then build and
It's entirely your prerogative to hack on your own copy of GTK+, but
that's simply a broken approach. GTK has nothing to do with
client-side decorations, outside of:
* providing an API for using them from applications
* using them for the dialogue windows it creates — *if* the
configuration toggle for them is set
Changing the code inside GTK won't change the applications that expect
GtkHeaderBar to work and exist, for instance.
> And maybe the Debian maintainers would be more amenable to the principle
> that the user should be the one to decide eventually.
This is ridiculous.
The people that "get to decide" are:
* application developers
* toolkit developers
A "user" — i.e. the person that is not directly involved with the
development of the application and operating system — only gets to
"decide" when they get directly involved with the development.
Configuration is not "decision", and there is no mandate for
application and toolkit developers to provide anybody with
configuration options. You get what you get if it's sustainable in
terms of maintenance and in terms of usabilty.
Additionally, you're entitled by the license used to take the code and
do what you want with it.
Those are the only two things you can "decide": whether to involve
yourself in the development upstream, or fork it and take matters in
your own hands.
>> Another note: GTK 3.18 CSS is entirely different from GTK 3.20 and
>> later. Why? I don't know. I guess people like to break things. ;-)
Once again, with contempt.
The CSS theming classes and selectors were not API, they were
intentionally not documented, and thus fell under no stability
guarantee — until GTK+ 3.20, when they were finalized and deemed
expressive enough to allow you to write themes without necessarily
ending up writing C code to inject into applications.
> It is a tragedy that Gtk+ has turned into the Gnome credo of knowing
> better than users what is good for them.
GNOME developers are the reason GTK+ exists in the first place, and
keeps existing to this day, 20 years on. This is a do-ocracy: those
who do, decide.
Writing free software is not software development camp. You don't get
a prize just for showing up. Either you put your money where your
mouth is, or you don't get to say "you know better".
[@] ebassi [@gmail.com]
gtk-list mailing list