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

[muppet <scott asofyet org>]

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.

e.g.,

   # 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.

thoughts?