[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #53217] Can't cancel out the popped up window
Date: Sun, 25 Feb 2018 03:32:10 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

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):

  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()

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,
                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):


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:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]