Re: Ideas w/r/t HIG spacing and indentation guidelines



On Fri, 2002-09-27 at 14:21, Matthias Warkus wrote:
> Hi. Just some random thoughts...
> 
> The HIG requires most widgets to be labeled -- either with a
> colon-terminated Label at the side (with 12 pixels of spacing) or by
> putting the widget under a label, indented by 12 or some other
> multiple of 6 pixels (IIRC).

This reminds me of something that probably should be included in the HIG
but wasn't yet.  When associating labels with widgets, the guidelines
above are a good visual convention/indication, but such visual placement
is not too useful from an accessibility point of view, for instance for
blind users.  This is especially bad since labels themselves don't turn
up in the keyboard focus chain, so they can be hard for blind users to
find without additional hints.

ATK has API for logically associating labels with widgets (though it
does not affect their onscreen placement), via the "AtkRelation"
concept.  For a label and a button, button should have the relation to
the GtkLabel: "ATK_RELATION_LABELLED_BY", and the label in turn has the
relation "ATK_RELATION_LABEL_FOR" with respect to the GtkButton.

Thus the application should use something like this:

AtkObject *label_atko = gtk_widget_get_accessible (label);
AtkObject *button_atko = gtk_widget_get_accessible (button);
AtkRelationSet *relations = atk_object_ref_relation_set (label);

atk_relation_set_add (relations, 
                      atk_relation_new (&button_atko, 
                                        1, ATK_RELATION_LABEL_FOR));
g_object_unref (relations);
relations = atk_object_ref_relation_set (button);
atk_relation_set_add (relations, 
                      atk_relation_new (&label_atko, 
                                        1, ATK_RELATION_LABELLED_BY));


(This is a bit cumbersome, and reminds me that we need some convenience
API here, perhaps 
"atk_object_add_relation (object, target, relation_type)" ).

Another possibility, which would address Matthias' concerns as well,
would be to have API in gtk+ for creating GtkEntry fields, etc. which
had built-in labels.  The most straightforward way would be to make
GtkEntry into a container, with API for optionally specifying a label on
creation gtk_entry_new_with_label() or something like that.  Properties
could be used to determine alignment and placement of the label, and the
accessibility stuff could happen inside the common widget code, so that
the applications didn't need to do it.

-Bill




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]