notebook interface (was Re: [BUG] one cannot add widgets to notebooks)

On Monday, July 7, 2003, at 05:42  AM, Goran Thyni wrote:

On Sun, Jul 06, 2003 at 04:08:50PM -0400, muppet wrote:

On Sunday, July 6, 2003, at 01:30 PM, Thierry Vignaud wrote:

Gtk2::Notebook->append_page does not accept any other widgets that the
abstract base type Gtk2::Widget :

the second argument, tab_label, must be a widget (usually a GtkLabel,
but also a GtkHBox containing a label and a button), but you're passing
a string, which is not a widget.

I think this is a perfect example where we should try to be "perlish".
The old gtk2-perl wrapped this and automagically created the Label widget
if you passed in a string.

in diving a bit further into the problem...

there are six ways to add pages to a notebook:

  $notebook->append_page ($child, $tab_label);
  $notebook->append_page_menu ($child, $tab_label, $menu_label);
  $notebook->prepend_page ($child, $tab_label);
  $notebook->prepend_page_menu ($child, $tab_label, $menu_label);
  $notebook->insert_page ($child, $tab_label, $position);
$notebook->insert_page_menu ($child, $tab_label, $menu_label, $position);

the first five are just simplified front-ends for insert_page_menu, which is the actual swiss army knife.

in all cases, tab_label is to be either NULL, or a GtkWidget. if NULL, a GtkLabel with the text "page N" is used (with N being the page number, of course). however, tab_label can be any widget, and the most obvious use is a GtkBox containing a pixmap, a string label, and a button with an X in it to close the tab, a la Opera/Mozilla/Galeon/Safari tabs.

GtkNotebook has a setting (the "enable-popup" property) that allows a user to bring up a menu to select the desired notebook page, in addition to having tabs out. if you want to bring up that menu, the items that go into the menu *must* be GtkLabels, not anything fancy, so if you are going to put something fancy into the tab_label and allow enable-popup to be TRUE, you have to use the _menu variant and supply a GtkLabel widget for menu_label.

if you just pass NULL or a GtkLabel for the tab_label, then it's quite safe to pass NULL for the menu_label (but then it's pointless to use the _menu variant in that case).

so why am i babbling?

the current bindings just pass everything straight through to the C layer with no fiddling. in fact, we don't even allow undef for the tab_labels (which we should).

it would indeed be easy to automagically create GtkLabels for plain strings, passing any undefs or already-widgets through... but this begs the question, how do we now validate the input we've mangled? and also, since we have five extra functions which merely act as interfaces to the same function, we could consolidate these to save codespace, but we could also collect them by providing default parameters.


   # this is the normal case we have now
   $notebook->append_page ($child, Gtk2::Label->new ("foo"));

   # this one is fine, we automagically create a label
   $notebook->append_page ($child, "foo");

   # this one barfs, complaining that you didn't supply an alternate
   $notebook->append_page ($child, $non_label_widget);

   # this one works fine, as an alias for append_page_menu
$notebook->append_page ($child, $non_label_widget, Gtk2::Label->new ('foo'));
   # as does this:
   $notebook->append_page ($child, $non_label_widget, 'foo');

this would be highly helpful and perlish, but now we'd need to document it and make sure it does the right thing and doesn't get out of sync.

personally, i think it's sufficiently complicated on its own, without us tossing in string versus label confusion. however, we started down the slippery slope a long time ago so it's hard to argue against this on the "changing the interface" grounds.


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