Re: Abysmal state of GTK build

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Suppose you discover that some people are writing customization recipes
> on a popular Wiki page that make use of internal Emacs code for whatever
> purpose, and you know that once you change that code people will come to
> complain about you for breaking their setups.

We will not change such code on purpose, just because someone is writing
customization recipes based on it.  In fact, I would look into making it
"not internal", should it prove useful.

And we will never, ever, resort to name-calling!

> Of course, that's no excuse for calling names on anyone, but otherwise
> what he did is not unreasonable.

All of it is unreasonable.

> Well, I said that he is an occasional contributor after looking at his
> activity map, which is not very colorful.
>
> OTOH, he belonging to the official team may explain why he was not
> censured. That doesn't mean that other team members sympathize with his
> action.

All of the GTK developers do it.  This is the personal experience of
almost everyone who has tried to write real software with GTK.

> There is a bitter disagreement there, for sure. But I've experienced
> worse dealing with KDE/Qt maintainers and I still am a happy KDE user.
> That is, if you think that by switching to Qt you will deal with more
> reasonable and polite people, you are wrong. They are the same kind of
> human beings, like we are here.

I don't think Qt maintainers will proactively seek to break user's
customizations and call them names.

> There is no assurance whatsoever that you will not get that type of
> reaction from a Qt developer. I had similar discussions with highly
> competent maintainers of top-tier projects and it requires empathy,
> politeness, patience and skillful dialogue. Not to say that this
> guarantees success, but starting with the attitude of "I'm obviously
> right and you are doing wrong" poses a big risk of a strong-headed
> rejection.

I've never seen that kind of reaction from a Qt developer, or even a GTK
developer in the 2.x days.  Such behavior is not excusable and
immediately excludes such a toolkit from being suitable for any
software, including Emacs.