Re: [g-a-devel] RELATION_CONTROLLED_BY and RELATION_CONTROLLER_FOR

[Bill Haneman <Bill Haneman Sun COM>]

Hi Aaron:

This is a good question (about the CONTROLLER relations).  It is used 
when interface components which are "separate" objects from the point of 
view of the user or, perhaps, the tookit paradigm, have a tightly 
coupled relationship in which one object determines some key aspect of 
another.  Typical examples now in use include scrollbars, which are 
controllers for the "viewport" objects which they move.  Resize widgets 
would also be controllers - for instance, if a window (or window 
manager!) chose to expose resize icons on a titlebar as separate 
AtkObjects, they would logically be controllers for the window.   
However we generally draw the line somewhere, we don't for instance 
expose the "close" button as a CONTROLLER, nor do we expose "OK" and 
"CANCEL" buttons as controllers for a dialog.  Generally CONTROLLER_FOR 
is reserved for the following types of situations:

1) one UI element controls the state of one or more other UI elements, 
but not an entire dialog.  We exclude familiar user models such as 
radio-buttons (in which each button can potentially 'control' the state 
of others, via exclusivity), but for instance if a particular checkbox 
enables or disables a subservient set of controls, strictly speaking 
that checkbox should be marked as a CONTROLLER for the other controls. 

2) one UI element serves as a 'manipulator' for the attributes of 
another, e.g. the object with which the user interacts via mouse, 
keyboard, or AtkAction is not the primary object whose onscreen 
attributes change as a result.  An example would be a colorwheel widget 
used to change the color of a "background color" box, or a slider which 
controls the size of a displayed sample font.

'CONTROLLERS' are most likely to implement AtkValue, i.e. they are 
usually valuators rather than binary toggles.

For your specific examples...

- Is a tree item 'controlled' by the collapse/expand button on the parent?

No - since the relationship is implied by the EXPANDABLE state on the 
parent container, and the parent-child relationship.  If there were a 
separate "expand my selection" button somewhere in the interface, it 
would arguably be a controller for the part of the view that was subject 
to being expanded.

- Is a window 'controlled by' the close button?

No, since the semantics are implicit in the close button's textual 
information and role.   However a "close current notebook tab" button 
might logically be a controller for a notebook.

- Is a document view 'controlled by' a zoom button on the toolbar?
This in an interesting case.  I would be tempted to say 'no' on the 
grounds that the effect of the button is implied in its role and label - 
however, if the zoom button affects the resulting viewport, then it 
would not be incorrect to expose it as a CONTROLLER for the scroll/view 
window, by analogy with scrollbars.

I suppose there's a sort of common-sense test that can be applied.  If 
the effect of a "controlling" UI element can be easily deduced from its 
labelling and role, then the CONTROLLER relation adds little value.  
However, if the controlling UI element is unlabelled (as is often the 
case with scrollbars), or the relationship between it and the portion of 
the UI which it controls is largely implicit in the visual layout, then 
exposing CONTROLLER adds significant value to the end-user.   I would 
conclude that it is a relationship that should be exposed for UI 
components which control a subset of the user's current "view"/dialog, 
when the result of end-user manipulation of the component is not 
otherwise clear.

regards,

Bill


Aaron Leventhal wrote:

> RELATION_CONTROLLED_BY  Indicates an object controlled by one or more 
> target objects.  RELATION_CONTROLLER_FOR   Indicates an object is an 
> controller for one or more target objects.
>
> Forgive the dense question ... what is meant by 'controlled' in this 
> instance? What are some typical examples? What is it used for today, 
> and what are known planned uses for it?
>
> - Is a tree item 'controlled' by the collapse/expand button on the 
> parent?
> - Is a window 'controlled by' the close button?
> - Is a document view 'controlled by' a zoom button on the toolbar?
>
> - Aaron
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel