Re: RFC: UI design

[Tristan Van Berkom <tvb gnome org>]

On Tue, Jan 10, 2012 at 2:25 AM, Benjamin Otte <otte gnome org> wrote:
> 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.

(sorry for late reply ;-))

Yes that is a good point, when you write a GTK+ application for a
dedicated device, of course you control the platform so essentially
this distinction is moot.

>> 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.

Ok here is a good example of a problem we need to solve and
I think I have a decent idea of the direction we need to take to
solve it.

Essentially: we need a way to make things absolutely clear
when it comes to communicating the application's needs to
the theme.

One problem IIRC was that GTK+ theme had been
overriding explicitly set toolbar style, I think that the current
solution is that if the user sets a toolbar style, GTK+ theme
will not override it, giving application developers the opportunity
to use GtkToolbar widget in different portions of their application
than up at the top as what we commonly refer to now as
"the main application toolbar".

Now it's kind of assumed that application developers should
not override the toolbar style for the main application toolbar
because this configuration should follow the desktop settings etc.

For the case of the toolbar, this is working fine enough IMO.

Now a problem we currently have in Glade/gedit, is that we
absolutely need to override the padding of a GtkButton which
we place into the notebook tabs with a stock rendered 'X'
icon.

This is a more difficult issue because GtkButton can be used
in many different contexts, it's easy to say that a GtkButton
which is placed into a GtkButtonBox should have a certain
appearance... and then application developers have the
choice to pack the button into something different than a
GtkButtonBox if they need to escape the implied theming
consequences, but it's completely inappropriate to say
that theme writers should start to theme the GtkButton
differently if it's somewhere in a notebook tab, or elsewhere.

There are possibly a few approaches to address this
problem:

   a.) Introduce some sort of "role" attribute on widgets which
        allow theme writers to base their theming on a specific
        "role" for which the widget was indented by the application
        developer.

        This is a bit undesirable because roles could quicky become
        too many in number and hard to control, every apps needs
        can be different after all.

   b.) We could consider white-listing specific widgets for theming,
        perhaps even if it only goes as far as padding and alignment
        white listing

        For instance, a GtkButton would receive the regular theme attributes
        but only a GtkThemedButton would be effected by spacial attributes
        from the theme (i.e. this would become the "law" for theme writers).

Option b.) makes a lot of sense when it comes to composite widgets such
as GtkInfoBar, GtkButtonBox children etc, then we get grey area around
widgets like GtkProgressBar (again, I need to put those in notebook tabs,
I dont want theme writers to muck about with the padding/alignment of
progress bars in my notebook tabs, but perhaps the padding and alignment
should be assigned for the progress bar which is specifically inside a
GtkProgressDialog
or GtkProgressWidget or GtkThemedProgressBar or such).

If application developers dont want to be theme effected at all for
some widgets,
then they should obviously write their own derived widgets and simply implement
GtkWidgetClass->draw() in their own beautiful/custom ways, this option
will always
be there and so it's not really a part of the problem we need to solve IMO.

In the most simple terms I can come up with, application developers
need to count
on their basic widgetry to show up as expected, and not get some extra wacky
space around the toolbar just because theme writers thought that "toolbars are
only for use at the top of the window below the menubar".

Currently I'm thinking that the best way to do this is to
  o restrict coordinate/padding and all spacial theme attributes to use
     withing GTK+ provided composite widgets
  o possibly provide some extra composite widgets for standard use
     cases, just for the purpose of having a select list of class selectors
     which should be assigned in 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?
>

Same as above problem described, if application developers have a
clearly advertised subset of highlevel widgets that may change their
size and shape, and theme writers are forced to limit spacial theming
to these classes, then we start to clarify what is "expected behavior",

The current problem now is that the expected behavior is rather random,
leaving both parties in a tight situation.

Cheers,
           -Tristan

>> 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