[Octave-bug-tracker] [bug #53217] Can't cancel out the popped up window

[Dan Sebald]

Follow-up Comment #7, bug #53217 (project octave):

I'm attaching a simple changeset that will allow the Qt window to be closed
even when the pager is active, suspending the core (e.g., gray()), *but* it
can't be applied.  I will try to explain.

I've checked that the following callback still occurs with the appropriate
figure number when the figure Qt window is closed by not ignoring the
conventional close method (i.e., the changeset):


  void
  Figure::close_figure_callback (void)
  {
    figure::properties& fp = properties<figure> ();
    octave_value fnum = fp.get___myhandle__ ().as_octave_value ();

    Ffeval (ovl ("close", fnum));
  }


Because the Qt window is closed, there is no way of queuing more than one
close event for the callback with the attached changeset.  However, that isn't
always desired.

Let me just point out the warning/error message with multiply queued close:


octave_link::post_event (this, &Figure::close_figure_callback);
octave_link::post_event (this, &Figure::close_figure_callback);
octave_link::post_event (this, &Figure::close_figure_callback);
octave_link::post_event (this, &Figure::close_figure_callback);


The "this" is used to resolve the block of memory that the figure-pointer
attributes come from (i.e., the figure number).  But after the first handled
close event, "this" is no longer valid (which results in the error messages
the original poster noted).  I think this sort of thing is why Qt developers
came up with the signal/slot idea.  Once something is deleted in Qt, all of
its connections evaporate and no more communication happens with that object.

Anyway, the problem with the changeset is that the close behavior of a figure
can be altered via the following property:


>> get(gcf,'closerequestfcn')
ans = closereq


Say I do the following:


graphics_toolkit qt
function [] = do_nothing()
end
set(gcf,'closerequestfcn',@do_nothing);


Well, then pressing the close button will have no effect.  One thing we could
do is


              case QEvent::Close:
                if (CLOSEREQUESTFCN_PROP != 'closereq')
                  xevent->ignore ();
                octave_link::post_event (this,
&Figure::close_figure_callback);
                return true;


where CLOSEREQUESTFCN_PROP is pseudo-code.  However, that seems a bit of a
kludge.  Someone could write a custom 'closerequestfcn' that adds a few lines
and then calls closereq(), which would still cause a problem.

Years ago I wrote a "background queue" in which the GUI could post commands
via a signal and then eventually get a signal back from the core containing
the octave_value result (with ID information about who requested the command
and octave_value):

https://savannah.gnu.org/patch/?8016

In that case, rather than the callback, the figure would issue "close #", and
if it does so multiple times while the core is busy the followup "close #"
will cause an error, but because it is in the background queue, the error
message is not printed anywhere.  I probably won't re-examine that patch.

In summary, this is a bug, but I doubt it will be addressed anytime soon.  It
requires a redesign.

(file #43395)
    _______________________________________________________

Additional Item Attachment:

File name: octave-figure_do_not_ignore_close-djs2018feb25.patch Size:0 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53217>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/