FileChooserDialog in gtk4/gtkmm4 XML

I am in the process of converting some of my tools to gtk4. So far I have been able to manually update the XML passed to the builder. However, I have not been able to get the FileChooserDialog up and running like in previous versions of GTK. Currently, I can open a FileChooserDialog with the following XML:

False ... ...

The dialog is opened by a button click and produces a window similar to this image on the FileChooserDialog page

However, it does not have the Cancel and Open buttons. I have tried using the XML from the previous version of GTK. Unfortunately, adding a child without the internal-child=“action_area” argument clobbers the file display UI.

Can you advise on how to add these buttons from XML so that I can connect them to signal_clicked callbacks? Thanks much.

Gtk.FileChooserDialog is deprecated, use Gtk.FileDialog instead.

FileDialog does not appear to be available in gtk-4.0.0, which is the version available via apt in debian 12.

ls /usr/include/gtkmm-4.0/gtkmm/file*dialog*
/usr/include/gtkmm-4.0/gtkmm/filechooserdialog.h

I can try a source build. Are the gdk/gtk dependencies self-managed by the gtk source repo, or do those have to be lined-up manually?

Hi,

Try to play with the FileChooserDialog use-header-bar property, you may have to set it to “1” to force the headerbar with buttons.

While Gtk.FileChooserDialog is deprecated, it will stay available in gtk4 lifetime, but will be dropped in future gtk5. That said, Gtk.FileDialog offers many advantages, I recommend it once available in your distro.

Thanks for the idea @gwillems. I gave it a try, but have not seen any buttons.

I looked at some of the gtk4.0.0 source. I was able to find attributes such as “internal-child”. In gtk3, there was an internal-child named vbox, but this name is no longer valid. That contained an internal child action_area, which I have tried for my GtkButton child. It has built but it has not appeared (note: the GtkButton visible property is True). I was hoping to find a switch statement listing legal internal-child options, but I have not found that. However, it looks like the ui/*.ui files might define these names. ui/gtkdialog.ui contains the name “action_area” as an object id. ui/gtkfilechooserdialog.ui contains the name “action_area” as an internal-child.

Not all of the ids were legal for this GtkFileChooserDialog’s internal child, where by legal I mean the builder doesn’t throw an error. About half were legal, though none showed the buttons.

Can you please share the XML you’re using?

You cannot add children to GtkFileChooserDialog in the UI definition files. It wasn’t really a supported scenario in GTK3 either, but in GTK4 it’s definitely not possible.

Additionally, you really don’t want to go down that road because in any well-behaved GTK application you should be using either GtkFileChooserNative or, after GTK 4.10, GtkFileDialog, which use the platform’s native file selection dialog (for instance on Windows or macOS), or go through the file selection portal on Linux. Since those dialogs use native components, or exist out of process, you cannot add custom widgets or buttons to them.

The block that I’m currently working on looks like this:

<property name="can_focus">False</property>
<child internal-child="action_area">
  <object class="GtkButton" id="file_chooser_load_config_load">
    <property name="label" translatable="yes">Load</property>
    <property name="visible">True</property>
    <property name="can_focus">True</property>
    <property name="receives_default">True</property>
    <property name="hexpand">True</property>
    <property name="vexpand">True</property>
  </object>
</child>

The block that I started from, which was made by glade and had two buttons added to it looks like this:

<property name="can_focus">False</property>
<property name="type_hint">dialog</property>
<child internal-child="vbox">
  <object class="GtkBox">
    <property name="can_focus">False</property>
    <property name="orientation">vertical</property>
    <property name="spacing">2</property>
    <child internal-child="action_area">
      <object class="GtkButtonBox">
        <property name="can_focus">False</property>
        <property name="layout_style">end</property>
        <child>
          <object class="GtkButton" id="file_chooser_load_config_load">
            <property name="label" translatable="yes">Load</property>
            <property name="visible">True</property>
            <property name="can_focus">True</property>
            <property name="receives_default">True</property>
          </object>
          <packing>
            <property name="expand">True</property>
            <property name="fill">True</property>
            <property name="position">0</property>
          </packing>
        </child>
        <child>
          <object class="GtkButton" id="file_chooser_load_config_cancel">
            <property name="label" translatable="yes">Cancel</property>
            <property name="visible">True</property>
            <property name="can_focus">True</property>
            <property name="receives_default">True</property>
          </object>
          <packing>
            <property name="expand">True</property>
            <property name="fill">True</property>
            <property name="position">1</property>
          </packing>
        </child>
      </object>
      <packing>
        <property name="expand">False</property>
        <property name="fill">False</property>
        <property name="position">0</property>
      </packing>
    </child>
    <child>
      <placeholder/>
    </child>
  </object>
</child>

The glade GtkFileChooserDialog had two container areas where the buttons were added. The gtk4 block at the top of this post only has one button – starting small. Of course, I had to get rid of a few items for gtk4, like vbox and packing.

There may have been a miscommunication. I was trying to learn from the ui definition files in the source code. I did not know which values were legal for the internal-child attribute.

I will look into GtkFileChooserNative. Thanks for the suggestion.