Re: Thoughts on combo replacement
- From: Kristian Rietveld <kris gtk org>
- To: Owen Taylor <otaylor redhat com>
- Cc: GTK Development list <gtk-devel-list gnome org>, jody gnome org
- Subject: Re: Thoughts on combo replacement
- Date: 21 Mar 2002 15:30:58 +0100
On Thu, 2002-03-21 at 05:33, Owen Taylor wrote:
> * The same choice of menu or drop down list should also exist if you
> are implementing a history for an editable entry. That is, if you
> have option menus, the history on an entry should appear as something like:
> | | /\ |
> | | == |
> | | \/ |
> With the option-menu double arrow, and clicking on it should give you a
> drop down menu. I believe the Macintosh equivalent of a combobox
> works this way.
I think we always want the menu to be beneath the widget. The optionmenu
menu always appeared over the widget. We also need to decide whether we
want a double or single arrow. If the menu or list always appears
beneath the widget, then we need to go with a single arrow pointing
> * While the gal combobox code supports arbitrary widgets in the drop down
> portion, I don't think that is actually useful. The only use of it I've
> seen is in the color-combo, where you have a bunch of colors and a
> GnomeColorPicker for a custom color. But the GnomeColorPicker effectively
> acts like just another menu item, so I don't see any requirement to have
> a widget for it.
> Supporting arbitrary widgets causes problems:
> - It will compromise the ability to control the exact behavior of navigation
> (especially keynav) in the drop down portion.
> - It means you can't make switching between menus and "lists' a theme option.
Having a combobox with entry and history, with the history in a menu
looks weird IMHO. We definitely need a list there. But we definitely
need a menu for a color picker combo. I'm not really sure if making
menus/lists a theme option is a good idea.
> So, if we can avoid this (and I think we can) we should.
> To support the menu style of display with gridded items, we'll have to add
> gridding support to GtkMenu, which won't be particularly fun. (Nothing with
> GtkMenu* is.) But is potentially useful in general.
> - Completion against items in the list (but note that completion is really
> a separate and more complex issue... both Mozilla and IE make
> the completion dropdown different from the history dropdown; the completion
> dropdown displays only current completions, will complete match
> www.gtk.org against http://www.gtk.org in the history list and so forth.)
I think different programs want different completion algorithms. So we
may have to create some API to change the completion function, and
provide a default one.
> API thoughts
> * There is a temptation to use cell renderers to represent the contents of the
> list; advantages of this:
> - API reuse.
> - Some code reuse. (Though you'd have to duplicate most of GtkTreeViewColumn)
> - Quite flexible.
> To handle the menu part, you would create a menu item that used GtkCellRenderers
> to render its contents ... there is nothing in GtkCellRenderer
> that I know of that is particularly tied to renderering in text/base
> contexts rather than in a fg/bg context.
> And (as long as you didn't want to support row-spanning) you could just use
> a GtkTreeView to display the contents when in list mode.
> The API would presumably consist of something like:
> void gtk_combo_view_set_model (GtkComboView *combo_view,
> GtkTreeModel *model);
> void gtk_combo_view_pack_start (GtkComboView *combo_view,
> GtkCellRenderer *renderer,
> gboolean expand);
> void gtk_combo_view_set_attributes (GtkComboView *combo_view,
> GtkCellRenderer *renderer,
> void gtk_combo_view_set_n_cols (GtkComboView *combo_view,
> gint n_cols);
I don't understand what this function is supposed to do.
> This API is not really amenable to row/column spanning, though you
> could imagine making one of the columns of the model be the number
> of columns for the item to allow for the simplest cases.
For combo widgets using a menu we can write some code to fill a menu
with items from the GtkTreeModel. Though we need to add some API or an
algorithm to set the number of columns/rows for the grid and to do
> * The main alternative to using cell renderers would be a simple clist-like
> text, image, or image-and-combo design. A straw man API might be:
> GtkComboItem *gtk_combo_item_new (void);
> void gtk_combo_item_set_text (GtkComboItem *item, const char *text);
> void gtk_combo_item_set_markup (GtkComboItem *item, const char *markup);
> void gtk_combo_item_set_image (GtkComboItem *item, GdkPixbuf *image);
> void gtk_combo_box_append (GtkComboBox *combo_box,
> GtkComboItem *item);
> void gtk_combo_box_attach (GtkComboBox *combo_box,
> GtkComboItem *item,
> guint left_attach,
> guint right_attach,
> guint top_attach,
> guint bottom_attach,
> GtkAttachOptions xoptions,
> GtkAttachOptions yoptions);
> void gtk_combo_box_remove (GtkComboBox *combo_box,
> GtkComboItem *item);
If we use this, we use a GtkTable. Do we need gridding support in
GtkMenu at all then?
> Row/column spanning is more natural here, but would still pose problems
> for using a GtkTreeView to implement the list mode.
> * With either possibility there would be a ::item-selected signal when the
> user chose an item from the combo, it would presumably take a GtkTreePath
> for the tree-view API and a GtkComboItem * for the second API.
> * The base combo widget should support probably support all of the 1a), 1b), 2a), 2b)
> possibilities for the non-menu widget.
> If we want text-combo or color-combo widgets, it would make sense for them
> to be subclasses of the base widget, as in the gal API.
> * Is the idea that "every thing acts like a menu item" sufficient?
I think it is for most cases. Though IMHO using menus in 'browser-style'
combos is ugly.
> * Is row/column spanning for gridded items necessary?
I don't really see where this can be useful.
> * What are the relevant widgets in the competing toolkits (WinForms, Swing, Qt)?
> what do they support?
] [Thread Prev