Re: Uniform look-and-feel on GNU/Linux
- Date: Thu, 14 Apr 2016 07:48:35 -0500
- From: Daniel Espinosa <esodan@xxxxxxxxx>
- Subject: Re: Uniform look-and-feel on GNU/Linux
I know about Freedesktop limitations, but an specification could help, followed or not. I sed it, because it's a place where common specifications are hosted, as a neutral place.
Is not about to write a CSS for anyone to use, but a description for basic behavior and images guidelines. Each toolkits should implement by their selfs.
This is easy to say, but hard to convince all about to put away their own distinguished branding. As you see, when you see a program using a different look and feel it is different from others and that's they want from the beginning, but at the same time, they want to see the same on all platforms.
Lets Talk about Desktop. Is it convenient to have a basic behavior for all applications? like simple ones, using a GUI backend just as a convenient tool, but their branding. They should be the same in all Desktops, no matter the toolkit?
You are vastly overestimating what Freedesktop.org does.
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?
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
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
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
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/
> El abr. 13, 2016 3:59 PM, "Florian Pelz" <pelzflorian@xxxxxxxxxxxxxx>
>> 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 . 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?
>> gtk-list mailing list
> gtk-list mailing list
[@] ebassi [@gmail.com]
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list