Re: RFC: UI design

[Benjamin Otte <otte gnome org>]

On Mon, Jan 9, 2012 at 5:40 PM, Tristan Van Berkom <tvb gnome org> wrote:
> I think the first thing we have to keep in mind is that while well-known
> use cases of GTK+ are in the domain of "desktop applications" there
> is a great deal of use cases that are not tied in to desktop environments
> (be they, mobile desktops or laptops or other generalized personal
> computing devices).
>
Keep in mind that those kiosk or other embedded applications
themselves are the platform though. So for those cases, the
distinction does not matter. It doesn't even matter if you have
multiple applications if you still control the design of all of them
(you can do sth like
http://git.gnome.org/browse/gnome-themes-standard/tree/themes/Adwaita/gtk-3.0/gnome-applications.css
to the system theme).  It only gets interesting once you want to allow
external developers to integrate with your platform.

> Application developers obviously have a stronger say, they can:
>  - augment the theme experience by adding their own css
>    on top of whatever is running underneath
>
Keep in mind that if your application wants to "extend" the desktop
theme and the desktop theme can be changed by users, these extensions
must work with any theme, including future themes that do not exist
yet. So you must make your widget integrate well with any color,
padding, size and so on. And from my experience most custom CSS
already fails when using the dark theme, let alone the a11y ones.
I would actually go so far as to say every call to
gtk_widget_override_*() is broken if you don't control the theme.

> In the end I think that application developers will always find
> a way to circumvent an installed theme, so it makes no sense
> to make their life harder and force desktop installed css to
> be pushed into their app.
>
Well the problem is not that developers can't do things, the problem
is how we treat developers that do those things. When we change things
in themes (like we did with Clearlooks during GNOME 2.x), do we blame
the application authors for their attempts to override things or do we
expect the theme designers for their carelessness in not making sure
that their new theme works with every override in every application,
including the ones that are closed source?

> Possibly not, actually it should be much easier to set hard values for
> colors and borders and such without needlessly mucking about with
> CSS parsing, certainly if the intended result is only "set the background
> red and have a zero width border", then it should be much more
> efficiently doable by calling gtk_widget_set_background() and
> gtk_widget_set_border_width() directly.
>
The thing about providing convenience APIs is always this: If you
provide the API, people will use it. The ease of something is always a
good indicator about if it is expected of developers using this API to
do that kind of thing.
Setting the text on a label is something we expect people to do. A
lot. So there is gtk_label_set_text() to do this. We however do not
expect developers to set icon used for drawing the sort indicators on
tree view columns. Which is why there is no
gtk_tree_view_set_sort_indicator_icon() API.
While it is very clear-cut for these two APIs, this question is less
clear-cut for widget styling. Because if we provide a very visible
gtk_widget_set_background() function, we encourage developers to use
it. And for that function to work well, we need to make sure the
foreground and potential borders are still visible and the widget
doesn't look out of place. Because if that happens people will
rightfully tell us "GTK sucks". And I cannot guarantee that this
function works well (as pointed out above) if it has to work with a
light theme, a dark theme or any random theme downloaded from the
internet, because - for a start - I don't even know which foreground
color will be used.

Benjamin