Thanks for noticing this.

This is fixed in the new patch attached.

(file #33638)

The addition looks fine to me.  It's just a message.

The reason that program execution is blocked is that there is no existing mechanism to communicate results back to the Octave core.  The layout framework layout is as follows: Qt GUI is the main thread and the Octave core is in a secondary thread--a "worker thread" of sorts.  (Only the main thread can do graphics in Qt, with rare exception.)  That's a perfectly fine setup.  It would be straightforward to make the dialogs non-modal and let the worker thread continue on its way, but there is no way right now to communicate the result back to Octave core.  The way to do this in the asynchronous, cross-thread environment is with signals and slots.  The dialog box can send out a signal when it is done, but there needs to be a slot on the worker thread side of things to accept the signal.  That means whatever slot is on the work thread side needs to remember information about the dialog that was issued, probably with some identification in the case of multiple dialogs/figures, etc.  Worker thread also needs to accept signals "asynchronously", be that between script commands or whatever the case.

If by implement in Octave you mean that there are some primitives for drawing plot elements, that seems like too much work at the moment--to define and maintain.  Custom icons should be possible within the existing framework.  If one attempts the custom layout that this changeset hints at, it may well end up that it would work better with some more primitive OOP classes.  In that case things could be restructured, but the advantage of going with the more high level dialogs directly is the small amount of code it requires to implement given the large amount of Qt objects.