Bloehdian has asked for the
wisdom of the Perl Monks concerning the following question:

Hello folks,

I am not quite sure whether the solution to the problem described below which I intend to implement is, firstly, feasible and, secondly, could be done in a less cumbersome way, potentially using "built-in" features of Gtk.

The problem:

I created a GUI which, when the user wants to save his work, presents the user a summary in a notebook page which has to be accepted or rejected ("Ok" and "Cancel" button at the bottom of the page) by the user prior to the actual saving . Most of the GUI is deactivated at this point, but a few buttons and the notebook page with the results to be saved stay active, i.e., a part of the GUI stays responsive while waiting for the user to press one of the two buttons (it could be necessary for the user to switch to the other notebook page prior to proceed with saving; if any other button is pressed apart from the both mentioned the user will be asked to only press "Ok" or "Cancel" since this is the only way to proceed with the application).

On the code level this means that the application should wait within the _save_work() subroutine for a 'button-press' event and, when it was passed to either the "Ok"-button or the "Cancel"-button, the program should execute the necessary actions and leave the loop. If any other event will occur the application should stay in that loop to force the user to press one of the buttons.

The code fragments I have in mind look as follows (for the sake of simplicity I present it only for the "Ok"-button, "Cancel"-button should be analogous):

On the code level this means that the application should wait within the _save_work() subroutine for a 'button-press' event and, when it was passed to either the "Ok"-button or the "Cancel"-button, the program should execute the necessary actions and leave the loop. If any other event will occur the application should stay in that loop to force the user to press one of the buttons.

Somehow "looping and waiting" makes me uneasy, because you are already in an event loop that is responsible for looping and waiting.

So another approach would be to have the code register a callback for the "Ok" and one for the "Cancel" button, disable most of the widgets, and then return.

Then the event handlers for the "Ok" and "Cancel" buttons are responsible for calling the callbacks that the code we first talked about registered.

I was aware of the main loop issue, but I thought that this would be "healed" with the call to the Gtk->events_pending function. Isn't it like that?

Not using the "waiting for event" approach would, at least, have the consequence not having a "closed" _save_work method any more, which does all the stuff, but several independent functions which would conceal the application's logic, i.e., this would make it harder to understand the code.

Not using the "waiting for event" approach would, at least, have the consequence not having a "closed" _save_work method any more, which does all the stuff, but several independent functions which would conceal the application's logic, i.e., this would make it harder to understand the code.

There's a reason one usually doesn't have one function which does "all the work". Afaict _save_work should just, well, save the work, not do UI teardown and other stuff. Doing one thing per function usually increases readability, not decreases it.