After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 589745 - Apply message in GtkAssistant
Apply message in GtkAssistant
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.16.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2009-07-26 09:04 UTC by Pierre Wieser
Modified: 2009-08-07 03:54 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
A patch against 2.16.6 (445 bytes, patch)
2009-07-26 09:06 UTC, Pierre Wieser
committed Details | Review

Description Pierre Wieser 2009-07-26 09:04:36 UTC
Hi,

I open this bug after having asking for the problem in the Gtk+ mailing list [1].

Given a GtkAssistant with a confirm page (with its Apply button), and a summary page (with its Close button).

When the Apply button is clicked in the confirm page, it appears that the next page is computed, and so the 'prepare' message is sent, _before_ the 'apply' message is itself emitted.

To be able to display the results of the operation in the summary page, one has so to do the work at the very beginning of the prepare handler.

And then handling the apply message becomes useless.

IMHO, the usual programmer does want 'apply' its operations before
'preparing' the display of the summary page.

I suggest to invert the order in which the apply message is emitted and the next page is computed.

Regards 
Pierre

[1] http://mail.gnome.org/archives/gtk-app-devel-list/2009-July/msg00069.html
Comment 1 Pierre Wieser 2009-07-26 09:06:52 UTC
Created attachment 139224 [details] [review]
A patch against 2.16.6

Joined is a simple patch against 2.16.6 which should do the trick:
just emit the Apply signal _before_ computing the next step.
Comment 2 Matthias Clasen 2009-07-27 00:24:30 UTC
Makes sense.