I have this problem in gnome-bluetooth's wizard, where I want more freedom as to which button(s) will be shown for a particular page. Currently I have to have a copy of the struct internally:

/* HACK, to access the GtkAssistant buttons */
struct RealGtkAssistant
{
        GtkWindow  parent;

        GtkWidget *cancel;
        GtkWidget *forward;
        GtkWidget *back;
        GtkWidget *apply;
        GtkWidget *close;
        GtkWidget *last;

        /*< private >*/
        GtkAssistantPrivate *priv;
};
typedef struct RealGtkAssistant RealGtkAssistant;

GtkAssistant is not really about the freedom to show arbitrary buttons; the idea here was that you specify the page sequence and some properties of each page, and let GTK+ take care of all the rest. 

Can you explain in some more detail what changes to the buttons you want to make ?

I don't want to show any buttons other than "Cancel" on some pages, as I do not want the user to be able to go back from a particular page.

This is what I do manually in prepare_idle_cb():
http://git.gnome.org/browse/gnome-bluetooth/tree/wizard/main.c#n430

For example, for the "Connecting" page (where we start poking at a device), we only want the "Cancel" button. The previous page is not available, neither should the forward page.

In some other cases, we do not want the ability to cancel, but only to exit early (the finishing page). Or the ability to not show any cancel or close button (for Simple Pairing, where we show a PIN on both Bluetooth devices and ask the user whether they match).

Take a look to bug #596428 for a possible solution in the evolution case.

@Bastian: Is the new api gtk_assistant_commit() enough for you needs?:

http://git.gnome.org/browse/gtk+/commit/?id=bb5c585777cede12bd1a7cf9fd1c5082e2debc22

Note that gtk_assistant_commit() permanently hides the Cancel button (the thought being once you commit it's too late to cancel), but you can always add a Cancel button for some cancellable I/O operation through gtk_assistant_add_action_button().

Bug #596428 also adds support for ending on a GTK_ASSISTANT_PAGE_PROGRESS -- the "support" being it's smart enough to hide the Forward button now.

I added this stuff for Evolution's import assistant.

If this is not sufficiently addressed yet, I would propose that we add a 'custom' page type, where buttons are entirely freeform. May need to add some forward/back functions then, to trigger the standard actions.

Bastien, Cody: Could you reopen this issue if you feel that it's not been addressed properly? Thanks in advance.

Turns out this isn't quite good enough for me to use in the bluetooth wizard.

Created attachment 173562 [details] [review]
GtkAssistant: Add more details about buttons shown

Add more documentation about which buttons will be shown for which
type of GtkAssistant page.

Created attachment 173563 [details] [review]
GtkAssistant: Add custom page type

The custom page type will not show any buttons by default, and
it is left to the application to add its own buttons instead.

The _next_page() and _previous_page() functions can be used
for the back and forward buttons used by the application.

Review of attachment 173563 [details] [review]:

Looks good to me. Add docs to the new functions, and its good to go.

Review of attachment 173562 [details] [review]:

Looks ok. I think we need to brush up the long desc with some information about the GtkAssistant design, ie that it decides about what buttons to show based on the provided page flow and page type information, together with some extra state information like 'completed' and 'committed' for each page.

Attachment 173562 [details] pushed as b5abd10 - GtkAssistant: Add more details about buttons shown
Attachment 173563 [details] pushed as cbbfd7b - GtkAssistant: Add custom page type