Yes, the gtk_signals.defs file seems to be correct:

(define-property dialog
  (of-object "GtkFileChooserButton")
  (prop-type "GParamObject")
  (docs "The file chooser dialog to use.")
  (readable #f)
  (writable #t)
  (construct-only #t)
)

but this function was generated:
  Glib::PropertyProxy_ReadOnly<FileChooserDialog*> property_dialog() const;
I think no property_* accessor should be generated for a non-readable construct-only property. This probably needs fixing in the .pm and/or .m4 gmmproc files of glibmm.

When we fix this, I think it's safe to remove this function because nobody could be using it.

OK. The actual bug was that _WRAP_PROPERTY() should not have been used for a property which is both construct-only and write-only. This is fixed now:

2007-12-13  Daniel Elstner  <danielk@openismus.com>

	* gtk/src/filechooserbutton.hg (property_dialog): Remove property
	wrapper since "dialog" is write-only and construct-only. (#436789)

As already stated, nobody could have been using it, so API and ABI change concerns do not apply. To catch mistakes of this kind more easily, gmmproc will now refuse to wrap such a property:

2007-12-14  Daniel Elstner  <danielk@openismus.com>

	* tools/pm/Output.pm (output_wrap_property): Refuse to generate
	a wrapper for a construct-only property which is also write-only,
	and display an error message accordingly. (#436789)

> To catch mistakes of this kind more easily, gmmproc will now refuse to wrap such a property.

I notice that it prints a warning and move ons:
/opt/gnome220/lib/glibmm-2.4/proc/gmmproc -I ../../tools/m4 --defs . filechooserbutton . ./../gtkmm
Output.pm: dialog : attempt to wrap write-only and construct-only property.

I guess that's OK. Thanks.

Yes, because I mirrored the behavior of gmmproc for other, similar errors conditions. However, I do think adding an option flag to gmmproc to make it bail out on errors would be a good idea. Shall I have a go at it?

No, I don't think it's worth the bother. And I have other tasks that you can do.