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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
