Re: THoughts on the ComboBox framework



> IMO, I believe that the Combobox should be a wrapper for the widgets already
> available (namely GtkTextView and GtkEntry).

I assume you mean GtkTreeView above, from the discussion below.

One accessibility problem with this is that the resulting API exposed to
assistive technologies such as screenreaders will be very complex (i.e.
all the complexity of a tree view) even for the 99% case.  I think this
would complicate life a great deal for at-spi clients and lead to
numerous problems.

I'd prefer if the exposed structure is simple for the 'simple' cases. 
Since we don't have per-instance interface inheritance, this means that
in order to handle both the simple and complex versions of combo-thingy
widgets, we'd have to subclass to get this behavior, i.e. we'd have a
'simple combo widget' that used a simple drop-down, and a 'complex combo
widget' that had the full tree drop-down.

That's probably anathema to GTK+ folks, but that's a limitation of the
interface inheritance mechanisms at our disposal.  It infers, basically,
a drawback to having compound widgets that are too generic.

Possibly if the combo-widget's ATK hierarchy were made straightforward
enough, for instance such that the drop-down widget were the one that
advertised the simple/complex interfaces, clients could cope by
interrogating the child of the combo (and the child would then have the
ATK relation POPUP_FOR).  However this relation isn't in the ATK API
yet, we'd need to add it for gnome-2-4.

-Bill

> Commonly, the combo box top (which is always shown with the drop down
> arrow), has two uses. 
> 
> - First is to have an entry which can not be modified and must be an item in
> the drop down list.  
> - The second is to have an entry which can be changed and which can also be
> selected from the combo drop down list. 
> 
> When the drop down button is clicked, the GtkTreeView should be shown.  For
> searching and add entries, etc, the GtkEntry should be used. As far as the
> columns and how the data is shown in the GtkTreeView is concerned, shouldnt
> this be left to the user to configure, perhaps with a API call to get the
> store/model and be able to modify the data in that way?
> 
> I may be way ofcourse on this, but I believe we already have the widgets to
> do the basics of what we want, your thoughts?

-- 
Bill Haneman <bill haneman sun com>




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