Re: where did the _construct functions go?

[Owen Taylor <otaylor redhat com>]

Oskar Liljeblad <osk hem passagen se> writes:

> Some gtk_XYZ_construct functions in gtk 1.2.x have been removed
> from gtk 1.3.x. These functions allow classes to be instantiated
> by g_type_create_instance and then "constructed" with additional
> parameters with gtk_XYZ_construct. (See gtk_plug_construct.)
> 
> E.g. if you have subclassed GtkButton, and want to use a stock
> image by default, you can't use gtk_button_new_from_stock because
> that would create a GtkButton instance. It would be necessary to
> do g_type_create_instance(MY_BUTTON_TYPE) then
> gtk_button_construct_from_stock. The latter function does not
> yet exist.
> 
> Would a patch against gtk 1.3/cvs that
> 
>   1. Added new functions gtk_XYZ_construct[_..] to all
>      classes with _new functions that do more than just
>      calling gtk_type_new/g_type_create_instance?
>   2. Updated those _new functions to use _construct instead.
> 
> be accepteped?

In general, _construct() functions covered up for a broken
interface. gtk_clist_construct() covers up for the fact
that the number of columns in a clist can't be changed
on the fly. gtk_plug_construct() covered up for the
fact that a Plug couldn't be added to a socket after
creation time. 

While we do have a replacement method of handling 
"construct" properties, they are best avoided by
simply allowing the relevant properties to be set
at any time.

The reason why the stock functionality is only available
at construction time is that it is considered 
convenience functionality -- like gtk_button_new_with_label(),
and a function gtk_button_add_label() wouldn't add any
value.

It turns out that gtk_button_new_from_stock() is
somewhat less trivial:

GtkWidget*
gtk_button_new_from_stock (const gchar   *stock_id)
{
  GtkWidget *button;
  GtkStockItem item;

  if (gtk_stock_lookup (stock_id, &item))
    {
      GtkWidget *label;
      GtkWidget *image;
      GtkWidget *hbox;
      
      button = gtk_button_new ();

      label = gtk_label_new_with_mnemonic (item.label);

      gtk_label_set_mnemonic_widget (GTK_LABEL (label), button);

      image = gtk_image_new_from_stock (stock_id, GTK_ICON_SIZE_BUTTON);
      hbox = gtk_hbox_new (FALSE, 1);

      gtk_box_pack_start (GTK_BOX (hbox), image, FALSE, FALSE, 0);
      gtk_box_pack_end (GTK_BOX (hbox), label, TRUE, TRUE, 0);
      
      gtk_container_add (GTK_CONTAINER (button), hbox);
      gtk_widget_show_all (hbox);
    }
  else
    {
      button = gtk_button_new_with_mnemonic (stock_id);
    }
  
  return button;
}

And in fact contains some packing options and the magic constant
'1' that you'd have to know to duplicate this in your
own code. So, we probably do need some extra API here.

Simply from the C API point of view, the obvious API
is:

 GtkWidget* gtk_button_add_stock (const gchar *stock_id);

However, approaching it from the other direction - from
the set of properties the button has, I think a better
interface would be to add to the existing ::label
property, two more properties:

 - use_stock_id
 - use_underline

[ The reason for use_underline, not use_mnemonic is 
  correspondance with GtkLabel ]

And that would imply a C api of:

 gtk_button_get/set_label ();
 gtk_button_get/set_use_underline ();
 gtk_button_get/set_use_stock_id ();

Which sort of spoils the "GtkButton is just a container"
simplicity of the API, and will probably increase the
number of people who can't figure out how to put an
image into a GtkButton... still, probably increases
overall ease-of-use for programmers.

Could you file a bug in bugzilla about this? I don't
think we can get to it for 2.0 at this point, but we
shouldn't forget this.

Regards,
                                        Owen