Hi; On 13 April 2016 at 22:45, Daniel Espinosa <esodan@xxxxxxxxx> wrote: > But what about to promot a Standard Look &Feell, say in Freedesktop. It can > suggest how graphical objects should look, no matter of toolkit? You are vastly overestimating what Freedesktop.org does. Fd.o is a place to host shared specifications or their common implementations. It does not (it cannot, really) mandate that anybody actually use them; it was created because some people, 10+ years ago, thought that some implementation details of different projects should be communicated to other projects in the interest of interoperability. The reason why those specifications ended up being used was that there was enough buy-in from different projects already, in terms of overlap of functionality. A theme, in any tool kit, does not specify how the tool kit itself behaves; that's part of the implementation, and a sound themeing policy is to never let the implementation be accessible from the theme (which is why GTK 2.x themes are terrible, as it forces developers to write C code modules that inject themselves into the application's process space). This means that you cannot really create a theme for, say, GTK 3.x and then have it run exactly the same on every other tool kit; it will require you to write a theme for every tool kit you have installed on your system, in order to have them behave in similar ways. The idea to specify a theme for every tool kit that can be installed on your system is a monumental effort and it will most likely end with something that looks terrible everywhere and behaves differently — and if you have any recent Linux installation you likely have installed: * GTK 2.x * GTK 3.x * Qt 4.x * Qt 5.x * LibreOffice * Chrome/Chromium * Firefox and even if Qt5, Chrome, Firefox, and LibreOffice can use the GTK 3.x foreign drawing API to at least *look* like GTK 3.x applications, this still leaves out older versions of Qt and GTK itself — and it does not solve the inherent issue of different behaviour. The "consistency" argument has, effectively, "left the building" (if it ever entered it) years ago; it's also vastly overrated when you realize that all applications under Windows use slightly different tool kits — even when written by Microsoft. This also applies to Apple on their desktop. People continue to use both those platforms anyway. Yes, there will always be people that wish for all their software to be exactly the same and behave exactly the same; no, I don't think it's an attainable goal — especially if all we can do is involved freedesktop.org to write a theme spec. Relevant XKCD: https://xkcd.com/927/ Ciao, Emmanuele. > El abr. 13, 2016 3:59 PM, "Florian Pelz" <pelzflorian@xxxxxxxxxxxxxx> > escribió: >> >> On 04/08/2016 10:37 AM, Fabio Pesari wrote: >> > One of the accusations made against GNU/Linux is that there is no >> > established "native" look-and-feel on it - GTK programs look different >> > from Qt programs, JUCE programs look different from Qt programs, Tk >> > programs and FLTK programs look different from everything else and so >> > on. >> > >> > This claim isn't false, it's just that most of us simply don't care >> > about it and often (unjustly) accuse those people of being superficial. >> > >> > But as the recent thread about blind users on libreplanet-discuss showed >> > us, the widget toolkit used for a program can make a huge functional >> > difference to some people. >> > >> > wxGtk gave me an idea: what if (optional) GTK3 backends were written for >> > all other GUI toolkits (Tk, FLTK, JUCE, Qt, Fox, Swt, Swing)? >> > >> >> Actually there is a GTK+ 2 "backend" for Swing [1]. It draws all buttons >> and text fields and so on like GTK+ does, but it does not always work >> well. For example, some text input fields that work well with the >> default Java Swing look are very small with the GTK+ look. >> >> It also is no more accessible to blind users than the default look. How >> could it be? >> >> [1] >> >> https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/plaf.html#available >> >> >> >> _______________________________________________ >> gtk-list mailing list >> gtk-list@xxxxxxxxx >> https://mail.gnome.org/mailman/listinfo/gtk-list >> > > _______________________________________________ > gtk-list mailing list > gtk-list@xxxxxxxxx > https://mail.gnome.org/mailman/listinfo/gtk-list > -- https://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
