Le nonidi 29 fructidor, an CCXXV, Daniel Kasak a écrit :
> Come on. It's troll bait.
I am very sure you will consider this mail troll bait too, but I assure
you it is not, and an honest reading of its contents, with the
definition of troll in mind, will show that it is not.
This thread shows a trend that is very typical of the evolution of Gtk+.
In the beginning of the 2000's, Gtk+ was arguably the best toolkit
available: Libre, of course, best Unicode support, best ergonomics, best
set of supported languages, best API, etc. In the more recent years, on
the other hand, we have seen a growing dissatisfaction from a certain
category of users, about both the ergonomics and the API design.
A friend of mine, historian, likes to say "a false idea is a true fact":
"people are dissatisfied" is a fact, even if one disagrees with their
reasons for being dissatisfied.
Some of the complaints are just silly or otherwise unfounded, there is
little doubt about that. But on the other hand, some of them are founded
and valid. Amongst them, some are a matter of taste, priorities and use
style while some may be universally valid points. Somebody who aims to
enhance Gtk+ needs to heed the valid complaints. And in order to know
which one is what, all complaints need to be read with an open mind.
Therefore, requesting features or expressing critics in a constructive
way is good for Gtk+ and perfectly acceptable on its mailing-lists, it
is not a troll. It becomes "troll bait" because some people do not read
them with an open mind and reply in non-constructive ways, sometimes
bordering on insulting. Of course, when polite requests are met with
impolite replies, the ambiance eventually deteriorates on both sides,
and the critics become less polite. All sides should make conscious
efforts to avoid it.
As I said, some critics are a matter of taste and use style. I think
they should still be heeded: a toolkit like Gtk+ should strive to cater
for all users and all use styles; it is possible to make a GUI more
usable for certain users without making it less usable for others.
Furthermore, general principles about usability often have to give way
to other considerations. For example, if somebody is forced to work a
lot with applications developed with a mediocre toolkit, they will want
their few Gtk+ applications to behave as much as possible the same way:
even if it is not the "best" way, it is still more convenient for them,
and Gtk+ should propose it as an option.
Of course, implementing options and alternate behaviours costs time and
efforts, and testing the various combinations even more so. The work of
the Gtk+ team is given to the community gratis, nobody has any right to
demand anything about it: "sorry, we do not have time to implement it"
is always a valid answer in a Libre software project, but it should be
followed by "but if you implement it well and maintain it, we will
accept it gratefully".
According to many discussions here and elsewhere, it would seem that the
drop in ergonomics observed by a certain category of users came with the
release of Gtk+ 3. I think it is a mistake. I remember that the
behaviour of the file chooser evolved in a direction that I do not like
with the releases of Gtk+ 2. Also, even though I like Cairo very much
and I think it is a very good thing that it can be use so easily with
Gtk+, I am not sure I approve the use of Cairo for the core of the
drawing, and I am sure I disapprove the dropping of the ugly low-level
primitives.
I think the bend of the evolution happened around 2005, and I observe a
shift in the most frequent names in git log at that time. I think it
matches the time where the development of Gtk+ was taken over by GNOME
developers. I do not know how nor why this take over happened, and I do
not think it is relevant to the discussion. But the net outcome is that
progressively around 2005, Gtk+ stopped to be the GIMP toolkit and
became the GNOME toolkit.
With that in mind, I think the development and release of Gtk+ 3 is not
the cause but the consequence of the evolution: the new generation of
developers needed a major break to be able to implement the changes they
wanted.
I think that the nowadays Gtk+ developers should make their priorities
more explicit: do you want to make a toolkit that is designed to be used
everywhere or a tookit that serves primarily the needs of GNOME? But if
they do not say it explicitly, they let their actions speak for them.
One of the core aspects of the problem is that Gtk+ is the only decent
toolkit that have an API in plain C. If I am mistaken, please let me
know. Application developers who do not like C++ have no choice about
the toolkit they use.
Another of the core aspects of the problem is that the end users, who
benefit from good ergonomics and suffer when it is bad, are not the ones
who choose the toolkit.
For both these reasons, choosing another toolkit is not an option.
Therefore, if the Gtk+ developers continue to be deaf to the requests of
a certain category of dissatisfied users about ergonomics, the principle
of Libre software leaves only one option:
Fork!
Take the current Gtk+ tree, fix the ergonomics issues, publish it and
lobby applications to use it, or at least to be compatible with it.
If the fork only changes high-level user-facing behaviours, like the
layout and reaction of the file chooser, then it can have the same API,
ABI and SONAME, and installing the alternate version in /usr/local/lib
would be enough to "fix" all applications on the system.
Personally, the feature I dislike the most in Gtk+ 3 is the disabling of
the window manager's decorations on application windows. I, as a user,
chose the window manager that I like and configured it to give windows
decorations with the appearance and behaviour that is most efficient for
me. Any application that deviates from that is an annoyance. Some time
ago I gave a cursory glance at the code to find the few lines in Gtk+
responsible for that, but I was not able to find them and had no time to
experiment more. If somebody could tell me where they are, I think that
today I would install a "fixed" version on my system, and very quickly
publish it on GitHub. If not, I will eventually get to it, probably next
time an application that I use a lot moves to Gtk+ 3 and starts using
that misfeature.
Tweaking the behaviour of the file chooser can work that way too, and if
I were to maintain a shallow fork of Gtk+, I would be happy to accept
it. The same goes for other examples of behaviour fixes.
As a side note, I have an awesome name for a de-GNOMEized version of
Gtk+. If I publish a version without WM decorations disabling and
possibly other fixes, I will use it. If somebody wants to do that before
I have time to get to it, I would be happy to share it.
Now, this is the Gtk+ mailing-list, hosted by the GNOME project. If
people want to discuss the ergonomics of the file chooser in a
constructive and polite way, I think it is the place to do so, but I
have no authority about it.
On the other hand, here is not the place to discuss a possible fork of
Gtk+, and I urge people to not continue this aspect of the discussion
here. On the other hand, if a discussion about it appears somewhere
else, I would appreciate to be personally notified.
Regards,
--
Nicolas George
_______________________________________________
gtk-list mailing list
gtk-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-list