Re: I have a problem

[Federico Mena Quintero <federico ximian com>]

On Sat, 2011-05-28 at 23:01 +0200, Benjamin Otte wrote:

> And I'm somewhat lost what to do then. Should I say yes
> because it's a good widget to use in general? Should I say no, because
> it shouldn't be used? What are the features and behaviors I have to
> look out for in those widgets so they end up in a consistent toolkit?

We sadly have not formalized this.  This is definitely one of the things
that we should try to do in the new HIG.

Emmanuele mentioned the "visual grammar", and I think this is the key
here.  There is already an architectural term for this; what Emmanuele
thinks of as a "visual grammar" is the "form language" of an
architecture.

I'm going to mix architectural terms and computer science terms, so bear
with me.  Think of building materials as an alphabet, and their possible
interactions as the grammar in your language.  The possible
constructions, or the strings in the language, are those that can be
built with those materials by following their particular rules.

Different architectures across the world have different form languages
because they use different materials in different conditions.  Brick and
mortar buildings, with clay roof tiles on timber frames (Italy?) have a
different look, and different shapes, than Japanese houses built of
timber and movable paper walls.  Each of those architectures has its own
form language - and yet both let you build habitable buildings.

In a similar fashion, GUIs have different form languages depending
mostly on the toolkit.  Qt apps look different than GTK+ apps even if
you change the theme, because the forms and their interactions are
different (and both let you build perfectly usable and attractive
interfaces).

The problem you are attacking is about trying to expand the form
language we have.

Maybe one question we need to ask is, "does this look like it could come
out naturally from GTK+, or are you cutting and pasting from an iPhone
screenshot?"

(Would you put a brick arch to frame a door in your Japanese
wood-and-paper house?  No, you wouldn't; it would look terribly out of
place.)

> I usually try to understand why the current widgets don't achieve the
> goal the design is trying to achieve and if we should modify the
> widgets to include the needed features. Or do the existing widgets not
> work for what we want to achieve and we should deprecate them?

It depends.  When we added icons and placeholder texts to GtkEntry, it
was because those were useful forms that were very hard to build with
what we had.  Sometimes we need completely new stuff, like the
button-that-when-clicked-brings-up-a-menu thing that everyone tries to
implement in various ways, and with various degrees of success.

> * The text says "Highlight and symbolic icon on hover indicates that
> the item is actionable"
> So far we've not had icons anywhere in GTK that only show up on hover.
> Is displaying symbolic icons on hover a new UI paradigm that we want
> to promote? Should space for those icons generally be reserved in
> advance or should we reflow when they become visible? Or should they
> be drawn on top of existing content? Do we expect to use this paradigm
> in other places (menuitems or buttons come to mind) or is this just
> for contacts?

This came from highly interactive web pages, and it's a good form.  It
lets you present affordances for functionality without cluttering
everything (as if you had the icons visible all the time).

I don't think we need a special widget for this; maybe just a GtkImage
that the app turns on and off by hand when another widget is hovered -
that's easy enough to do.  We could have a
gtk_image_set_active_only_when_hovered(image, other_widget), perhaps, if
the implementation turns out to have more tricks than obvious.

Space for the icons should definitely be reserved in advance; otherwise
you don't have a guarantee that they'll fit to be visible.

> * The text says "only the content gets scrolled"

That's where the designer probably got lazy^H^H^H^Htired as he was
finishing the mockup.  The heading area for "Angelinus Jolie" could very
well be slightly wider horizontally, and the scrollbar shorter, so that
the scrollbar really only adjoins the scrollable area.

Look at the second picture in the first column of the mockup, where it
shows the contents slightly scrolled.  This looks bad: the top of the
scrollable area has no frame and so the widgets get clipped (the
fade-to-white is a bad, cheap effect).  It would look even worse in the
bottom when the gray button for "Add detail" gets clipped in the bottom
of the scrollable area.  That scrollable area just needs a border around
it.

> * There's button(s) that say  ( Notes | Edit )
> How are these buttons different from notebooks? Is it just visually
> different or is it a completely different interaction? Because from
> the interaction described it looks like a notebook to me, just with a
> different UI. But I can't really pinpoint what's missing from
> GtkNotebook for this. Also, should we try to get rid of notebooks and
> replace it with buttons like these in other places?

Tough call.  To me notebooks meant, "we have too much information or
controls to show, but we can group it into a few logical sets and each
of those sets becomes a notebook page".  However, here it means, "here
are two aspects of the same thing".  Mental exercise - what if there
were no "Notes/Edit" separation, but rather a GtkTextView for notes at
the bottom of the scrollable area (like a text area at the bottom of a
web page)?  Would that have all the problems of a scrollable web page
with a text area, or would it simply let us get rid of extra widgetry?

> * The [ More v ] button
> So there's this button that pops up a menu, so it's somewhere between
> a menubar, a combobox and a button. Now, how should this behave? How
> should it look?

Many apps *do* have a button-that-turns-into-a-menu thing.  They are
tricky to implement.  Maybe we should start by adding a function to
GtkButton so that you can pop up a menu from it, with the right
position, grabs in place, timestamps, etc.

Megamenus are going to have related problems.  Think of Novell's failed
gnome-main-menu as a megamenu - we had to have a way to do this:

	1. Press the mouse on the Computer button
	2. The menu-of-apps appears
	3. Move the mouse with the button held down
	4. Release the mouse on an app's icon; the app gets launched

So we had to use grabs, some funny event handlers, and the like.  GTK+
should let you implement that easily if megamenus are to become
commonplace.

> * Overlays/Popups
> It seems a lot of designs overlay things on top of existing widgets.
> It seems a bit like the modern version of dialogs. GEditOverlay is an
> example for this, the contacts example[4] has it for its [ More v ]
> menu and when showing the "Embedded" image. The menus design page[5]
> is an obvious example. What is the interaction for those overlays and
> popups?

One thing about *that* particular popup is that to implement it
correctly, you need to be able to know the exact position of the text in
the "To:" entry line.  I'm not sure that GtkEntry lets you obtain that
information easily; I do know that for GtkFileChooserEntry, I had to do
some magic to figure out where to put up the completion messages (and
I'm sure there's a FIXME there for some corner cases).

About modality - if you have a modal popup, you as the user can't flip
desktops or check another window easily to check something that you may
need to enter into the popup.  Maybe popups need an unobtrusive "close"
button.

  Federico