3 ms·

They effectively have no choice. Right now there are two major toolkits for DEs, GTK and Qt. And the former is under the control of Gnome, and thus more and mo

They effectively have no choice. Right now there are two major toolkits for DEs, GTK and Qt. And the former is under the control of Gnome, and thus more and more Gnome-isms will make their way into it. So either the already notoriously understaffed XFCE has to fork GTK2, or move to Qt. Effectively we are learning that there is yet another way to hijack freedoms that the FSF do not consider, code churn. Or if one want to be a bit conspiratorial, code churn is what the FSF relies upon to maintain its other freedoms.

byuu 10y ago
I feel like they still have a choice ... at least for now. CSDs are still optional in GTK3. True, they are forced on for the common dialogs, so if you use GTK's file chooser or font picker, then you're going to end up with them. But at least then they're child modal dialogs to a parent application. The Gnome 3 desktop team decided to move every application possible to them, but there's no reason Xfce has to follow suit there. Again, at least for now. It's certainly possible the GTK team will decide to enforce this and remove the option for window manager decorations in a future release. I would really love to see a maintained fork of GTK2, however.
- irq-1 10y ago
  CADT == Cascade of Attention-Deficit Teenagers https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html
zanny 10y ago
It isn't the job of people writing code for free to write anything but what they want to with it. If XFCE wanted to stabilize GTK, they could try to do that with a fork, but there was no bait and switch - it has always been the Gnome ToolKit. You should probably consider that before building desktops based off it that are not Gnome - its future developments are by Gnome, for Gnome. If the fragmented ecosystems on the fringes of GTK - Elementary, XFCE, and Mate - were united, they could have easily forked GTK2 or 3 and maintained their own independent stable toolkit. Hell, the Gnome developers might have appreciated a wider swathe of developers working on it and switched to the fork with a transition to a plugin model for all the Gnome extras than constant churn in the toolkit. Code churn for the sake of it can definitely be a hostile tactic, but GTK churns because Gnome is constantly changing at the whims of its developers in their pursuit of their own ideal desktop. Unless you are paying them for their time or contributing code yourself to their projects, why should you have higher priority over their own desires or those of their immediate users of their whole software suite?
- gnutun 10y ago
  > it has always been the Gnome ToolKit To be fair, to the extent that GTK has ever been an acronym, it is the "GIMP ToolKit".
- captainmuon 10y ago
  I really don't like that argument. Nobody is claiming that the Gnome dev's had to maintain GTK for everybody, or that it was their job. But it would be really nice, and it is disappointing that they don't. For very long, the focus was ambiguous, and for some devs it was intended as a cross-platform toolkit (that's why there are Mac and Windows ports). Only "recently" (a few years) the focus has been on Gnome only. > they could have easily forked GTK2 or 3 and maintained their own independent stable toolkit. They could have, but almost nobody wants that. There is little utility in making yet another toolkit for a couple of new apps. What people want is to keep certain features in the mainline GTK, so mainline GTK apps retain them (non-CSD titlebars[1], icons in menus, stock actions, window-resize grippers, ...[2]) About code churn; I find the new versioning scheme of GTK particularly frustrating and backwards. Now they do have "stable" versions, but what they do is once they declare a version as stable, they break ABI, change the version number, and move all development to a new version. I think this is a useless definition of stable: People can already just throw the .so files in with their app if they want something frozen in time, there is no need for that kind of "stable" release. What they used to do (in the late Gtk 2 days) was to keep backwards compatibility (within reasonable bounds) while adding new features. This is what I'd call stable - write code against 2.18, and it still runs against 2.28 a few years later, supporting new features and bugfixes. Now, that mode of development is harder, I understand, and they have no obligation to go that route. But it would be really beneficial if they want GTK to succeed. And I really want to like and use GTK (I prefer it and Gnome to some extent over Qt and KDE), this is why I get a bit worked up about the state of GTK... [1] The titlebars are a bad example, AFAIK you can still get server side titlebars in the latest GTK. [2] There are so many lost features, I actually made a list and at one point wanted to make a "Gnome Feature Graveyard" website in protest.
  - xorcist 10y ago
    > the new versioning scheme of GTK particularly frustrating and backwards I was absolutely certain this was a parody when it was announced. I thought it was brilliant, and showed a great deal of self-concious humour.
Analemma_ 10y ago
> Or if one want to be a bit conspiratorial, code churn is what the FSF relies upon to maintain its other freedoms. It's not even a conspiracy, at least in the case of gcc. rms has said outright that gcc's code is deliberately terrible, to keep people from building proprietary frontends on it. Hooray for freedom to tinker.

byuu 10y ago

I feel like they still have a choice ... at least for now. CSDs are still optional in GTK3. True, they are forced on for the common dialogs, so if you use GTK's file chooser or font picker, then you're going to end up with them. But at least then they're child modal dialogs to a parent application. The Gnome 3 desktop team decided to move every application possible to them, but there's no reason Xfce has to follow suit there. Again, at least for now. It's certainly possible the GTK team will decide to enforce this and remove the option for window manager decorations in a future release. I would really love to see a maintained fork of GTK2, however.

irq-1 10y ago
CADT == Cascade of Attention-Deficit Teenagers https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html

zanny 10y ago

It isn't the job of people writing code for free to write anything but what they want to with it. If XFCE wanted to stabilize GTK, they could try to do that with a fork, but there was no bait and switch - it has always been the Gnome ToolKit. You should probably consider that before building desktops based off it that are not Gnome - its future developments are by Gnome, for Gnome. If the fragmented ecosystems on the fringes of GTK - Elementary, XFCE, and Mate - were united, they could have easily forked GTK2 or 3 and maintained their own independent stable toolkit. Hell, the Gnome developers might have appreciated a wider swathe of developers working on it and switched to the fork with a transition to a plugin model for all the Gnome extras than constant churn in the toolkit. Code churn for the sake of it can definitely be a hostile tactic, but GTK churns because Gnome is constantly changing at the whims of its developers in their pursuit of their own ideal desktop. Unless you are paying them for their time or contributing code yourself to their projects, why should you have higher priority over their own desires or those of their immediate users of their whole software suite?

gnutun 10y ago
> it has always been the Gnome ToolKit To be fair, to the extent that GTK has ever been an acronym, it is the "GIMP ToolKit".
captainmuon 10y ago
I really don't like that argument. Nobody is claiming that the Gnome dev's had to maintain GTK for everybody, or that it was their job. But it would be really nice, and it is disappointing that they don't. For very long, the focus was ambiguous, and for some devs it was intended as a cross-platform toolkit (that's why there are Mac and Windows ports). Only "recently" (a few years) the focus has been on Gnome only. > they could have easily forked GTK2 or 3 and maintained their own independent stable toolkit. They could have, but almost nobody wants that. There is little utility in making yet another toolkit for a couple of new apps. What people want is to keep certain features in the mainline GTK, so mainline GTK apps retain them (non-CSD titlebars[1], icons in menus, stock actions, window-resize grippers, ...[2]) About code churn; I find the new versioning scheme of GTK particularly frustrating and backwards. Now they do have "stable" versions, but what they do is once they declare a version as stable, they break ABI, change the version number, and move all development to a new version. I think this is a useless definition of stable: People can already just throw the .so files in with their app if they want something frozen in time, there is no need for that kind of "stable" release. What they used to do (in the late Gtk 2 days) was to keep backwards compatibility (within reasonable bounds) while adding new features. This is what I'd call stable - write code against 2.18, and it still runs against 2.28 a few years later, supporting new features and bugfixes. Now, that mode of development is harder, I understand, and they have no obligation to go that route. But it would be really beneficial if they want GTK to succeed. And I really want to like and use GTK (I prefer it and Gnome to some extent over Qt and KDE), this is why I get a bit worked up about the state of GTK... [1] The titlebars are a bad example, AFAIK you can still get server side titlebars in the latest GTK. [2] There are so many lost features, I actually made a list and at one point wanted to make a "Gnome Feature Graveyard" website in protest.
- xorcist 10y ago
  > the new versioning scheme of GTK particularly frustrating and backwards I was absolutely certain this was a parody when it was announced. I thought it was brilliant, and showed a great deal of self-concious humour.

Analemma_ 10y ago

> Or if one want to be a bit conspiratorial, code churn is what the FSF relies upon to maintain its other freedoms. It's not even a conspiracy, at least in the case of gcc. rms has said outright that gcc's code is deliberately terrible, to keep people from building proprietary frontends on it. Hooray for freedom to tinker.