Giters

jhass / crystal-gobject

gobject-introspection for Crystal

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Gtk::MessageDialog have just a subset of GTK API

hugopl opened this issue · comments

commented

The generated bindings only show a subset of the C API https://developer.gnome.org/gtk3/stable/GtkMessageDialog.html, and as expected the wrapper only wrap this subset.

struct MessageDialog # object
  parent_instance : LibGtk::Dialog*
  priv : LibGtk::MessageDialogPrivate*
  # Property buttons : LibGtk::ButtonsType
  # Property image : LibGtk::Widget*
  # Property message_area : LibGtk::Widget*
  # Property message_type : LibGtk::MessageType
  # Property secondary_text : UInt8*
  # Property secondary_use_markup : Bool
  # Property text : UInt8*
  # Property use_markup : Bool
end
fun message_dialog_get_image = gtk_message_dialog_get_image(this : MessageDialog*) : LibGtk::Widget*
fun message_dialog_get_message_area = gtk_message_dialog_get_message_area(this : MessageDialog*) : LibGtk::Widget*
fun message_dialog_set_image = gtk_message_dialog_set_image(this : MessageDialog*, image : LibGtk::Widget*) : Void
fun message_dialog_set_markup = gtk_message_dialog_set_markup(this : MessageDialog*, str : UInt8*) : Void

As the gtk_message_dialog_new isn't available, creating these objects (without gtk builder) are impossible.

commented

Well, what can I say. They're just not in the typelib. This is likely an upstream bug, you may want to raise it upstream. Not sure if against Gtk or Gir.

It seems like it's the case since forever, the Ruby gir_ffi-gtk gem added a manual definition six years ago, pretty much at its inception.

commented

OTOH, it looks like pygobject is skipping constructor methods altogether and generates generic constructors for gobjects using g_object_newv, accepting any properties marked . This might be something worth implementing.

Sadly pygobject seems to pass whatever propertiess the user passed as keyword arguments. So I'm unclear yet if we can generate a constructor accepting any of the properties or just ones with particular flags. For reference, the flags are in theory GObject::ParamFlags, so

  • ZERO_NONE
  • READABLE
  • WRITABLE
  • READWRITE
  • CONSTRUCT
  • CONSTRUCT_ONLY
  • LAX_VALIDATION
  • STATIC_NAME
  • PRIVATE
  • STATIC_NICK
  • STATIC_BLURB
  • EXPLICIT_NOTIFY
  • DEPRECATED

But I've only see READABLE, WRITABLE, READWRITE, CONSTRUCT and CONSTRUCT_ONLY in the wild for properties. For example here's MessageDialog ones

      + buttons (property)
        * flags = WRITABLE | CONSTRUCT_ONLY
        * type
          + <no name> (type)
      + image (property)
        * flags = READABLE | WRITABLE | READWRITE
        * type
          + <no name> (type)
      + message_area (property)
        * flags = READABLE
        * type
          + <no name> (type)
      + message_type (property)
        * flags = READABLE | WRITABLE | READWRITE | CONSTRUCT
        * type
          + <no name> (type)
      + secondary_text (property)
        * flags = READABLE | WRITABLE | READWRITE
        * type
          + <no name> (type)
      + secondary_use_markup (property)
        * flags = READABLE | WRITABLE | READWRITE
        * type
          + <no name> (type)
      + text (property)
        * flags = READABLE | WRITABLE | READWRITE
        * type
          + <no name> (type)
      + use_markup (property)
        * flags = READABLE | WRITABLE | READWRITE
        * type
          + <no name> (type)
commented

own, that was fast, I was writing a comment here when github updated the page with your commit.

commented

Well well... have a look at that shiny new GtkMessageDialog sample.

So this now generates generic keyword argument constructors based on an object's writable properties, in the spirit of pygobject.

I tried skipping generating other constructor methods, but unfortunately everything is inconsistent on what's exposed where, so for example GtkApplication does not expose the application id as a property, for whatever reason. Or maybe we're supposed to walk the ancestry chain and include everything from the parents into each constructor? Well something for the future, for now I just keep the explicit constructor methods, so you can pick to use either or.

commented

yep, I took a look in the patch you just sent

I think leaving all choices, i.e. C-like constructors + keyword-argument constructors can be less problematic and should cover these kind of corner cases. Good thing is that Crystal doesn't increase the compiled binary size with these unused methods.

commented

So I decided to go ahead with including the parent properties into the constructors. Some of them get quite massive from that, but judging from the samples I think it works quite nicely.