Re: I have a problem

[Benjamin Otte <otte gnome org>]

On Sun, May 29, 2011 at 1:06 AM, Paul Davis <paul linuxaudiosystems com> wrote:
> On Sat, May 28, 2011 at 5:01 PM, Benjamin Otte <otte gnome org> wrote:
>
> this is a cart vs. horse problem.
>
> i think you're absolutely correct that functionally, this is identical
> to a notebook. but there's function, and there's design.
>
> this design calls for an alignment of UI elements that isn't possible
> to accomplish with the current widget set (how would you get that More
> combo/menubar/button into the tab list?). is the design wrong to
> attempt that? if its wrong, why? if its right, how to accomodate the
> design if the current widgets don't.
>
Just as a FYI: In this particular case, GtkNotebook supports action
widgets, which would solve this particular problem. See
http://blogs.gnome.org/johannes/2009/11/09/gtknotebook-action-widgets/
for an intro from when they were added.

> in most of what you've written here, you seem to put the widget set
> first, and you seem to be suggesting that UI design should work with
> the constraints that flow from the widget set, because that will
> result in good UIs. the other position is that good UI design should
> come first, and then the widget set and specific widgets need to be
> modified to accomodate the design(s).
>
First of all, I would expect that I am biased towards the widget set,
that comes from being one of the developers. ;)

That said, let me get into how I think this whole interaction between
designers and developers should work inside GTK. I envision the design
process for new widgets or interactions to go something like this:
1) GNOME designers come up with an idea
2) GTK developers implement the idea
3) application developers and designers (both inside GNOME and ISVs)
use it in their applications
There's maybe a "1.5) GNOME ships a prototype application to test
things" in between.
(Of course, this is not a top-down approach. Ideally the application
developers provide feedback about how they think GTK should work to
the GTK developers and the GTK developers

When doing this thing though, we have to keep in mind the target
audience for GTK. And we have to keep in mind UI design principles.
Because the API of GTK is a user interface. And just like end users
for GNOME, the "end users" of GTK - the developers writing
applications - will look at what we give them and think about how to
best use it to achieve their goals. Of course, they will not read the
documentation, but infer something and then do what works.

An example for this is the notification area. It was introduced in
2002/2003[1][2] and led a happy life until in 2005, when GTK
introduced GtkStatusIcon. Suddenly, popping up an icon in the
notification area became a trivial thing to do. Everybody saw it and
thought "Hey, my application could make use of that, too." and off
they went. And now notification areas look like system trays on
windows and are definitely not the thing we envisioned them to be. In
fact, it goes so far that doing notifications in the shell is
basically impossible. And I think a large part of the reason for the
misuse is that we made it too freaking easy to use. Had it been a
separate library, people would have used it a lot less. Just imagine
if notification bubbles were as easy as a simple call to
gtk_notification_show()...

And of course, every time we support a new way to do things, there's a
nontrivial cost involved in it. Apart from having to support it for at
least this stable series, people will make use of it, find issues with
it and demand new features.That means someone needs to take care of
bugfixing, enhancements and so on. And when one day we decide to get
rid of it, people will complain that their application is designed
around this UI element we provided to them and expect us to have an
easy upgrade path for them.

Another thing that is quite important for me is to get people to do
the right thing by default[4]. So when some non-GNOME developer
decides to write an application with GTK, I want him to accidentally
do the right thing. For example, if we decide applications should use
Chrome-like overlays for status information it's probably a bad idea
that we have a GtkStatusBar[5] aptly named for it, but doing the wrong
thing. Same thing for toggles: Can we make it possible that developers
decide between switch, checkboxes, radio buttons and toggle buttons
correctly? Without reading any docs?

Fwiw, getting this right not only helps make developers happy, it also
helps designers - both because the apps are beautiful by default and
because you have to file less UI bugs. ;)

Benjamin


1: http://library.gnome.org/misc/release-notes/2.2/index.html
2: http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.1.html
3: http://developer.gnome.org/gtk/stable/GtkStatusIcon.html
4: http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html
5: http://developer.gnome.org/gtk/stable/GtkStatusbar.html