Re: RFC: UI design

[Tristan Van Berkom <tvb gnome org>]

Very interesting topic, I'm going to throw some responses out there
without thinking too hard, if the thread gets very interesting we can
build from there ;-)

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

It's hard to say even if desktop applications written with GTK+ actually
outnumber other kiosk or embedded use-cases (generally competent
companies developing on any embedded platforms tend to whine a lot
less so we just dont hear about them very much on the lists), so let's
please try not to setup any barriers to our beloved toolkit.

On Tue, Jan 10, 2012 at 12:29 AM, Benjamin Otte <otte gnome org> wrote:
> Hey,
>
> Here's another discussion point I want people to think about before
> the hackfest. This time it's not so much about API in a direct way but
> more about a guiding principles for the kinds of APIs we want to
> provide. The short question is this:
>
>  Who gets to decide how an application looks?

I think this is easy enough, the answer of course is both the
desktop theme writers and application developers.

Application developers obviously have a stronger say, they can:
  - write applications which leverage the theme, by using
    stock GTK+ widgets
  - augment the theme experience by adding their own css
    on top of whatever is running underneath
  - they should probably have the option to opt-out of desktop
    installed themes, if their CSS is complete enough for their
    use case and don't wish to pick up unexpected artifacts
    on systems with odd themes installed
  - application authors can also use completely customized
    widget kits (i.e., start with 3 or 4 derived GtkWidgets and
    build an application with that), which dont use CSS at all
    and perhaps load & cache images directly.

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.

Theme writers don't design applications in the first place, they
can decorate standard GTK+ widgets which are used in application
design, changing the look of an already designed application, for
applications which chose to leverage the theme (which is probably
default for any desktop application).

In this light, desktop themes should consist only of basic elements,
i.e. main application toolbar (may have a different look from other
toolbars used in the application), entries... GtkButtonBox and
GtkButton (for grouped buttons you may want to round the first
and last button edges, but never make this kind of assumption
for a GtkBox).

Desktop themes should refrain completely from setting up complex
CSS selectors, such as "if this button is somewhere inside a Grid
which is in the second scrolled window if it's parent GtkBox", I don't
know why it might happen but I can imagine a theme writer saying
to himself "Damn it, Evolution should look _exactly_ like this with
my theme installed", I think theme writers should not have that right,
they should instead be limiting themselves to providing a nice theming
environment for basic elements of the application.

> This question is aimed at theming and the question of graphic
> design[1] and not at intersection design[2]. The way I see it, there
> is two extremes to this:
> A) The application decides on the theme
> Examples: The Web, Windows, Games
> On the web, no page looks like any other page. If you for example
> compare http://maps.google.com and http://www.openstreetmap.org/ one
> of them looks greenish with a lot of rounded corners, the other
> blueish with sharp corners; font sizes are different and so on. Every
> application decides on its own how it wants to look and implements
> that look.
> B) The platform decides on the theme
> Examples: GNOME 2, OS X, office suites
> Here the platform decides how things look and it's discouraged to
> deviate from the norm with custom designs. ITunes could win a Finder
> look-alike contest, even though both are very different applications.
> Even portable applications try to blend in. You will notice that
> Firefox looks a lot more like a platform app on OS X and GNOME than it
> does on Windows.
> Of course, there are a lot of shades of gray inbetween. Phone
> platforms have UI guidelines but applications often break it and games
> don't look like Apple apps even on OS X. OTOH Microsoft applications
> blend in quite well with the Windows design and all the Google web
> pages look very similar, too.
>
> There is no obvious answer for which way is better. But a lot of
> things need to be done very differently depending on what way you
> decide to implement. Some examples:
> - switching themes
> Using a completely different theme is a thing people like. With
> platform themes, the N900 people were able to look quite different
> from the GNOME on your desktop and various distributions could make
> themselves stand out by using their own theme. All without changing
> the applications. This would not have been possible with application
> themes.
> On the other hand, with application themes you can add features you
> want quickly. If you want to merge a foreground and a background
> button in a browser, you just add the styling to do that.[3] Or if you
> want to make info messages blue, you just make them blue. However, if
> the platform changes the theming from under you in a way you didn't
> expect, that tuning might make your app look like crap. Say if the
> theme decides backgrounds are blue now, your info messages are now
> unreadable.
> - complexity of theme design
> Writing a CSS for an application is easy. If your application has no
> toolbar, you don't need to style toolbars. And if you add toolbars
> later, you just style them in the CSS then. On the other hand, you
> have to write a CSS for every application. Writing a theme for a
> platform is hard. The current Adwaita CSS for example is roughly 5000
> lines, so it's slowly getting as large as the code for GtkTreeview.
> But then, there's only one CSS file for all applications...
> - application UI design
> When developers design a UI for their application, the two ways
> require very different approaches. If the application decides on the
> theme, you can start with an image that's supposed to be a screenshot
> of the app when it's done. And then you can go and tweak the
> application's CSS until it matches. OTOH, if you're bound by the
> platform theme, the output should look closer to a Glade file, because
> you can't enforce pixel-exact alignment as you would expect in
> screenshots. This however usually requires the platform to provide (a)
> the editor to do these designs in and (b) a HIG so that application
> designers know why thinks work the way they do.

Application developers will always can (and will) derive widgets and
create their own look for their applications, I think the previous HIG
was definitely overblown.

My opinion on that is ideally we should have a standard set of composite
widgets (similar to the limited set of Cocoa widgets for iphones), one should
be able to play with a set of standard widgets and not have to worry too
much about HIG guidelines, in other words they should rely on the standard
set of composite widgets to comply with GTK+'s own opinion of interface
guidelines.

If our HIG philosophy changes, we adjust our composite widgets in GTK+
and push out a new version of GTK+, no applications change code for
that if they have used standard highlevel widgets from GTK+.

> - accessibility
> We have high-contrast, low-contrast, large-print and various other
> themes for people with visual disabilities. If applications theme
> things, GTK needs to make sure that these features are available even
> with custom themes. If there is platform themes, those people can just
> switch to a platform-provided theme for that feature.
> - form factors
> If you want to have different themes for desktops and mobile devices,
> this is easy on a platform theme. Just use a different one. But if
> it's done on the application side, the application needs to cater to
> those form factors explicitly. Whether this is a problem at all of
> course depends on how GTK aims to provide portability between
> different devices
>
> Now why is this interesting for GTK? Because the public API we want to
> expose and the cases we want to optimize the theming engine for differ
> quite a bit between the two approaches. Some examples:
> - gtk_settings_set (settings, "gtk-theme", "Adwaita")
> This does not make sense in an application-themed world. It should not
> be possible to change the theme.

This question is the bottom line I guess.

I would have to say, that applications which called
gtk_get_rid_of_the_damn_theme()
directly after gtk_init() and before creating their interfaces will
not be effected
by any theme set in the GtkSettings.

> - gtk_widget_set_style (button, "color: red; border: 0");
> This does not make sense in a platform-themed world. It should not be
> trivial to override the platform theme that easily.

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.

Well, that's all I have for now ;-)

Cheers,
                -Tristan

> It's also interesting because the GNOME 3 design efforts are currently
> very focused on implementing pixel-exact screenshots in their
> applications while the GTK API is still mostly unchanged from the
> GNOME 2 design. And as a GTK developer I'm always torn between those
> two sides. Currently I'm telling both sides "you can't have that"
> whenever they want something, so they're equally unhappy. But I'd like
> that to change in the future.
>
> Benjamin
>
>
> 1: http://en.wikipedia.org/wiki/Graphic_design
> 2: http://en.wikipedia.org/wiki/Interaction_design
> 3: Hi Xan!
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list