Dialogs

[dejlek]

I am trying to convert a GtkD application (DIDE) to gid:gtk3

I can't find how to do the following using gid:gtk3:

      auto msgdlg = new MessageDialog(this.projectWindow, DialogFlags.Modal, MessageType.Warning, ButtonsType.Ok,
                                      "File not saved.");

or

    FileChooserDialog fcdlg = new FileChooserDialog("DIDE: Open File...", projectWindow, ,
      buttonCaptions, rts);

I am not expecting to have these constructors as GIR files may not have them, but appropriate setters would do. Trouble is - I can't find them in the generated code. (Not sure they are in GIR either, will look at that later)

[elementgreen]

GtkD implements these as custom methods.

There are in fact some of these constructors described in the Gtk3 GIR file (search for "gtk_message_dialog_new"). However, they are marked as "introspectable"=0, because they have varargs. Currently gidgen ignores non-introspectable API.

If you think it is useful, you could add a custom implementation of these methods, similar to how GtkD does it. It can be done like so in the defs/gtk3.d file:

//!class MessageDialog

void this (Window parent, gtk.types.DialogFlags flags, gtk.types.MessageType type, gtk.types.ButtonsType buttons, string messageFormat, string message=null)
{
...

You can keep adding code and it will get inserted into the MessageDialog file.

[elementgreen]

He he.. We're both editing our answers.. It is has introspectable="0" as you say and is varargs which cannot be automatically inferred in a type safe way. GtkD implements these manually, because of this. See my comment below about some ideas of how some functionality could be added to gidgen to semi-automatically bind such methods.

I would think you would be able to do what you need to do with the methods of the parent Dialog class though.

[dejlek]

I noticed introspectable=0 too late. I already wrote the message... Sorry :)

[elementgreen]

No problem.. Do you use Discord? We could potentially chat via DM on there.

[dejlek]

https://www.kymorphia.com/gid/gtk.message_dialog.MessageDialog.html - ok this is GTK4 doc, but as you can see here too there are no methods to actually achive what that single constructor from GtkD does.

[dejlek]

I use IRC for 30 years. I prefer that but I can use discord too. :)

[elementgreen]

Thinking about this more.. I can think of a couple ways to have gidgen generate varargs functions/methods:

1. Add an extension to GIR which can be patched with a //!set command that allows for a type to be specified for the varargs.
2. If no type is found, it could use a template and pass the additional arguments to the varargs C function.

Having both of these options would allow for type-safe varargs methods to be generated. A tuple type could be used in instances where the C callable has a predictable sequence of types, though that may require a template as well. These methods could then be set to introspectable="1" using a //!set command to patch the XML.

[elementgreen]

After looking over the MessageDialog constructors again, they seem to be not very ideal for creating D bindings for them, at least in an automated way. The varargs are used as arguments to a printf style format string. Using C printf formatting from D is not of particularly great value and subverts some of the safety aspects of D, since there is no way to enforce the types being passed to such a function and there could be issues converting D types to C, leading to crashes or other issues.

The GtkD implementations of them are kind of nonsensical as well and have security issues, from what I can tell. They take a messageFormat string, but lack the ability to pass any arguments for it, except for an additional message string which is supposed to be null. The assumption here is that the string formatting is supposed to be handled in D. The problem is, if this rendered string content contains user defined input, % sequences could be inserted to cause undefined behavior (crashes or worse, if someone figures out how to exploit this in some way), because it is used as the format string!

If I was to write a binding for this, I would tend to do things similarly, in that there would just be a single string for the message, but it would not be used as the printf format string. Instead "%s" would be passed as the format string and then the message would be the argument to that.

So it seems like custom binding methods are the way to handle this for now. However, I can see potentially adding some features to gidgen to make it easier to write custom bindings. In particular a way to have gidgen insert the documentation provided by the GIR file when creating a custom binding for an existing callable.

[dejlek]

So it seems like custom binding methods are the way to handle this for now. However, I can see potentially adding some features to gidgen to make it easier to write custom bindings. In particular a way to have gidgen insert the documentation provided by the GIR file when creating a custom binding for an existing callable.

I think this would be great! It should generate the documented method/function, and the only body would be throw NotImplementedException("<fully qualified name> not implemented yet")

[elementgreen]

I'm not sure if I see the value in implementing all vararg methods, since the functionality can usually be accomplished in another way. Also, it may make more sense to have the arguments be different than the C method. I could see potentially adding a template though as a placeholder, since it could mimic the variable arguments of the C function and might be compatible with the final version once it is added. I guess if there was some way to detect whether the method is implemented or not, it would provide a way to detect it during runtime and decide whether to call it or use some other code. But it also might be nice to detect if it is implemented at compile time. Hmm. 🤔