bugGNU Octave - Bugs: bug #53217, Can't close window popping up...

 
 

bug #53217: Can't close window popping up after "gray" command while pager is active

Submitted by:  Dildar Sk <hodor123456>
Submitted on:  Sat 24 Feb 2018 07:04:45 PM UTC  
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error
Status:  Fixed Assigned to:  None
Originator Name:  Dildar Sk Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Tue 27 Feb 2018 10:08:27 PM UTC, comment #27: 

OK, then Octave is consistent with that description, e.g.,

>> close all
>> fig1 = figure(1);
>> set(fig1, 'colormap', hot(256))
>> size(get(fig1,'colormap'))
ans =

   256     3

>> fig2 = figure(2);
>> size(get(fig2,'colormap'))
ans =

   64    3

>> set(fig2, 'colormap', gray())
>> set(fig1, 'colormap', gray())
>> size(get(fig1,'colormap'))
ans =

   64    3

Whether that is what Matlab actually does is another question.  From a programmer's standpoint, I guess the best is to always specify the size of the colormap.

Dan Sebald <sebald>
Tue 27 Feb 2018 09:45:31 PM UTC, comment #26: 

We could extract the common input parsing code to a new function placed in the private/ directory of images.  This might be a clearer coding strategy, although performance would suffer.  Generally every time you have to go outside the current function there is reasonable amount of overhead on the part of the interpreter.  I don't think it's terribly important to change.

As to the difference between figure and axes colormaps, the latter did not exist until recently in Matlab.  Consequently, none of the colormap routines are set up to work with the axes colormap.  See the documentation of hsv as an example: http://www.mathworks.com/help/matlab/ref/hsv.html.

It may not be the best, but there is a historical way of doing things and it is documented.  If we want to have the colormaps look first to the axes, and then to the figures for colormaps, we lose compatibility with Matlab.

Rik <rik5>
Project Administrator
Tue 27 Feb 2018 09:20:37 PM UTC, comment #25: 

I like the individual color map flavors change.  It's too bad that initial test of 'n' and whether there is an existing figure via the root has to be repeated for every map.  Is there some way of doing code reuse by placing that construct in just one of the color maps and calling that with a special option?  Or somewhere else?

Yet, I still have questions about looking to the figure for the size of the existing color map and using that to determine the size of, say, hsv().  The reason is that Octave now has a figure color map and an axes color map.  How can hsv() anticipate which one is of interest to the user?  Or across existing and new figures, for that matter?

Could there be a difference in behavior of hsv() between these two?

colormap(hax1, hsv())

and

hsv()

Notice in colormap.m that the axes looks to be the color map source:

  [hax, varargin, nargin] = __plt_get_axis_arg__ ("colormap", varargin{:});

not the figure.

I do understand the "look-to-the-destination" approach, e.g., that if someone sets their axes color map (as opposed to, say, "figure" or "global" color map) to 256 levels.  That if s/he then just wants to change from one colormap (GRAY) to another (HSV) but maintain the number of levels, it would be merely

colormap(hax1, hsv())

but somehow--knowing the way Octave syntax flows--I wonder if this gets too confusing quickly based upon how many figures are open and what the current figure/axes is.  Maybe it would be better to just tie the default N to groot somehow.  No opinion, it's just a bit hazy to me as I currently perceive it.

Dan Sebald <sebald>
Tue 27 Feb 2018 09:13:47 PM UTC, comment #24: 

Closing report.  I'll let Dan open a new one specifically about the issue with callbacks.

Rik <rik5>
Project Administrator
Tue 27 Feb 2018 07:53:54 PM UTC, comment #23: 

> Is that not how Matlab behaves? Does this create a new figure? 'close all; cmap = hsv()'


No, it does not. I understand now what you changed, it was me who didn't understood what you meant properly.

Carnë Draug <carandraug>
Project Member
Tue 27 Feb 2018 07:22:10 PM UTC, comment #22: 

@Dan: All functions can also operate as commands.  If you don't use parentheses then the arguments are passed as strings.  For example,

plus 1 2
ans =  99
>> double ("1")
ans =  49
>> double ("2")
ans =  50

The issue is that pause, and many other functions, expect numeric inputs and for that you have to use parentheses.

For the other issue with callbacks, that should be a separate bug report; it has hardly anything to do notionally with the summary of this one "Can't close window popping up after "gray" command while pager is active".

Rik <rik5>
Project Administrator
Tue 27 Feb 2018 07:14:00 PM UTC, comment #21: 

@Carnë: I changed the various colormap functions, like hsv.m or winter.m, not to create a new figure.  The function colormap.m itself, when called without arguments, creates a new figure just as Matlab does.

Is that not how Matlab behaves?  Does this create a new figure?

close all
cmap = hsv ();

Rik <rik5>
Project Administrator
Tue 27 Feb 2018 06:59:09 PM UTC, comment #20: 

Well, "fixed" hardly seems right.  One of the original issues was the appearance of error messages.  Try the following, pause for five seconds and while paused click the close button of the plot a few times:

>> graphics_toolkit qt
>> plot(1:50)
>> pause(5)
>> warning: base_graphics_object::get_properties: invalid graphics object
error: unexpected exception while parsing input
>> warning: base_graphics_object::get_properties: invalid graphics object
error: unexpected exception while parsing input

The pause is meant to simulate the user running a long process where the core is busy.  Somehow suppressing the error messages would be an OK solution.  The bigger issue is the callback design.

https://savannah.gnu.org/bugs/index.php#comment7

BTW, most commands have a way-back compatibility of allowing input variables without the parentheses.  What is at issue with the following:

>> pause 5
error: invalid conversion from string to real scalar

Dan Sebald <sebald>
Tue 27 Feb 2018 06:43:42 PM UTC, comment #19: 

> I changed the various colormap functions so that they do not create a new figure, when none exists, and rather use a default of 64 in this case.


So is this going to be Matlab incompatible on purpose? Or maybe I didn't explain Matlab behaviour correctly?  Calling colormap in Matlab creates a new figure when none exists. And setting the default also works:

>> set (groot, 'DefaultFigureColorMap', jet(8))
>> cmap = colormap () % this opens a new figure window

cmap =

         0         0    1.0000
         0    0.5000    1.0000
         0    1.0000    1.0000
    0.5000    1.0000    0.5000
    1.0000    1.0000         0
    1.0000    0.5000         0
    1.0000         0         0
    0.5000         0         0

>> isequal (cmap, jet(8))

ans =

  logical

   1

Carnë Draug <carandraug>
Project Member
Tue 27 Feb 2018 06:40:40 PM UTC, comment #18: 

I changed the default state of the pager to "off" in this cset http://hg.savannah.gnu.org/hgweb/octave/rev/daf61c7dfcae.

Marking bug as fixed and closing report.

Rik <rik5>
Project Administrator
Tue 27 Feb 2018 05:12:46 PM UTC, comment #17: 

The use of a pager is generally tied with using a CLI.  In the past, when a CLI was the only interface available, it made sense for the pager to be on by default.  It was awkward if you had a lot of data to watch it fly by on the terminal with no means of slowing and reviewing it.  With a GUI, the interactive design principles recommend against using a pager.  The data that comes out is always available for review by using the scrollbars in the Command Window.  I have written a note to the Octave Maintainer's about possibly changing the default in Octave.

Rik <rik5>
Project Administrator
Tue 27 Feb 2018 04:58:33 PM UTC, comment #16: 

I changed the various colormap functions so that they do not create a new figure, when none exists, and rather use a default of 64 in this case.  See http://hg.savannah.gnu.org/hgweb/octave/rev/2dc04b6e1740.

Rik <rik5>
Project Administrator
Tue 27 Feb 2018 01:05:56 PM UTC, comment #15: 

> First, does Matlab create a new figure when the colormap function is invoked? Could someone try this code in a recent version of Matlab?


It does create a new figure on R2017b. As soon as you call colormap, an empty figure window is created and displayed.  Even after setting the default colormap.

Carnë Draug <carandraug>
Project Member
Mon 26 Feb 2018 06:03:13 PM UTC, comment #14: 

Can we break this in to to chunks?

First, does Matlab create a new figure when the colormap function is invoked?  Could someone try this code in a recent version of Matlab?

set (groot, 'DefaultFigureColorMap', jet(8))
cmap = colormap ()
isequal (cmap, jet(8))

I expect it doesn't create a figure, and that when there is no figure it uses the default colormap.

Rik <rik5>
Project Administrator
Sun 25 Feb 2018 10:50:08 PM UTC, comment #13: 

I also vote for default more off. This is simpler for newer
users and more experienced users can turn more on if they
want to, either cli or not.

Michael Godfrey <godfrey>
Project Member
Sun 25 Feb 2018 10:07:25 PM UTC, comment #12: 

Lets me inspect long series of data. To do this, there will now be the much more convenient variable editor.

True, but the variable editor is presently fairly slow in case of big arrays.
I find scrolling back in the GUI (with buffer set to e.g., 3000 lines) using slider bars a lot easier & faster. Be it that that doesn't work anymore on Windows 10 (see bug #52496).

Philip Nienhuis <philipnienhuis>
Project Member
Sun 25 Feb 2018 08:25:43 PM UTC, comment #11: 

>>  There are plenty other cases where the pager present leads new-users to wonder what is happening (leading to bug reports to revisit).


Seconded, I'd be in favor of having the pager off by default. My bet is that most people won't miss it, the others are cli people that can add a "more on" in their .octaverc. I see two advantages with paged output:

  • Interrupts endless outputs I generate by mistake (e.g. forgetting a semicolon). This can also be done with CTRL+C, just not as elegant.
  • Lets me inspect long series of data. To do this, there will now be the much more convenient variable editor.
Pantxo Diribarne <pantxo>
Project Member
Sun 25 Feb 2018 05:46:27 PM UTC, comment #10: 

Yes, on all accounts.

gray() isn't the issue, but changing it so that it doesn't create a figure when none exists is fine.  There are plenty other cases where the pager present leads new-users to wonder what is happening (leading to bug reports to revisit).

Certainly the pager could be changed too--another thing I'd suggest, but also is so entrenched there is little chance someone will look into it.  Octave could dump results to the pager and then come back to a state that allows it to continue processing commands immediately.  But the pager still needs to be displaying, so that isn't so easy.  Maybe it would require another thread for the pager to operate, but it couldn't be a QThread because such a thread would have to work with octave-cli as well which doesn't use Qt.

Dan Sebald <sebald>
Sun 25 Feb 2018 09:04:49 AM UTC, comment #9: 

Hey Dan,

(seems our posts crossed.)

Your reasoning is clear enough.

Part of the issue at hand can be simply that "gray" shouldn't open a graphics window by itself in the first place.
But the issue is equally valid if "gray" works on an existing figure.

I tend to think that the OP's problem is primarily that Octave has a pager that is on by default, which complicates the situation for unwary users.
Yet the bug you (Dan) describe looks real and is merely uncovered by the obvious reaction of users unwary of the pager's interference.

I suspect this may apply to several other commands that work on graphics windows and send so much output that the pager kicks in.

<adapting title>

Philip Nienhuis <philipnienhuis>
Project Member
Sun 25 Feb 2018 08:37:00 AM UTC, comment #8: 

"Matlab doesn't open a new figure and only returns a colormap. It uses the default colormap dimensions if no figure exists.
So there may be a compatibility issue in Octave opening a new figure."

Yes, I wondered about that.  It doesn't seem that colormap should necessarily open a figure.  It could just give the colormap that would be assigned if a figure is opened.

Dan Sebald <sebald>
Sun 25 Feb 2018 08:32:10 AM UTC, comment #7: 

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)

Dan Sebald <sebald>
Sun 25 Feb 2018 08:32:08 AM UTC, comment #6: 

the warning/error message arises from pressing the figure window's close button multiple times

Exactly.

The logic I mentioned is that "behind the pager" a script may be running that changes a figure; if that figure is manually closed but the script runs on, you can easily see that you can get errors as the script will try to adapt a non-existing figure. And indeed that's the exact error message:

warning: base_graphics_object::get_properties: invalid graphics object
error: unexpected exception while parsing input

Matlab doesn't open a new figure and only returns a colormap. It uses the default colormap dimensions if no figure exists.
So there may be a compatibility issue in Octave opening a new figure.
Any insights on that from the graphics experts?

I'll change status to "need info"

Philip Nienhuis <philipnienhuis>
Project Member
Sun 25 Feb 2018 05:11:14 AM UTC, comment #5: 

What does "hg tip" report for a changeset number?

>>24792:3390adaee21d.


I think the error was occuring due to

>>more on


After doing

>>more off

it's working as expected.
Thanks Dan Sebald.

Dildar Sk <hodor123456>
Sat 24 Feb 2018 09:39:13 PM UTC, comment #4: 

Sorry, I can reproduce this.  I forgot to change from gnuplot graphics toolkit to Qt graphics toolkit.  The issue is as I described, but note that the warning/error message arises from pressing the figure window's close button multiple times.  If one presses the close window just once and then types 'q' to exit pager mode no error appears.  So, the GUI probably keeps queuing a bunch of "close" commands for which the figure no longer exists.  I'll take a look at this later this weekend.

Dan Sebald <sebald>
Sat 24 Feb 2018 09:24:29 PM UTC, comment #3: 

"Yet I'll leave this open as I think it is a bit counter-intuitive that graphics windows don't respond if the pager is actively holding up output in the terminal; OTOH I can very well see the logic of that. Maybe a core dev can shed more light on this."

It's simply that the pager is like a part of the command and the command doesn't complete until the pager is closed.  The GUI is waiting for the worker process (the command line) to complete.  It shouldn't have to do that, but the pager setup was designed prior to the notion of Octave having a GUI and there needs to be a redesign of this and some communication protocol between the core and the GUI.

Dan Sebald <sebald>
Sat 24 Feb 2018 09:13:53 PM UTC, comment #2: 

I can't reproduce this.

There are a couple different issues here.  First a "non-bug" is the fact that you are unable to close the window that appears.  This is simply current behavior, albeit a limitation, which is that whenever Octave goes into pager mode (pager mode is the command-line "less"-like environment) it freezes all else, including graphics.  This has been noted elsewhere throughout the bug reports.

Now, the window that appears is a blank figure.  It may not seem like "colormap()" without an input should require the presence of a figure, but it could be that every figure's color map is different (and in fact, individual axes within figures might now have separate colormaps) so that we need to know the active figure before we can answer what the colormap is.  In any case, colormap() all alone might have to open a figure window.

That brings us to the actual bug, which is the

warning: base_graphics_object::get_properties: invalid graphics object
error: unexpected exception while parsing input

Could you be more specific about the version?  What does "hg tip" report for a changeset number?

Also, perhaps you could try a few things that might better characterize the issue.  Try first opening the figure and then colormap.  (Perhaps colormap() is acting before the figure is fully created.)  E.g.,

>> sombrero
>> colormap(gray)
>> figure
>> colormap(jet)
>> sombrero

Maybe turn off the pager and see what happens.

[from a fresh launch]
>> more off
>> colormap()

Things like that.

Dan Sebald <sebald>
Sat 24 Feb 2018 08:45:19 PM UTC, comment #1: 

(You do now that "gray"is a function, don't you? if not, enter the command: help gray)

What happens if you first type "q" (w/o quotes) in the terminal?

I see the same as you (but I'm on Windows), but after typing "q' the pager quits, control returns to the terminal and I can close the graphics window  w/o issue.
If I just do:

more off
gray

I can also close the graphics window w/o issue.
So for the time being I set status to "works for me".

Yet I'll leave this open as I think it is a bit counter-intuitive that graphics windows don't respond if the pager is actively holding up output in the terminal; OTOH I can very well see the logic of that. Maybe a core dev can shed more light on this.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 24 Feb 2018 07:04:45 PM UTC, original submission:  

When I type 'gray' on command line of octave dev,a window pops up.
On trying to cancel out the window by 'X' the window is not cancelling.It's not responding on trying to cancel it out.But after minimizing the window if you type 'q'(quit) it disappears.
Several errors come after that.

Dildar Sk <hodor123456>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #43394:  errors.png added by hodor123456 (296KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by hodor123456 (Submitted the item)
  • -email is unavailable- added by hodor123456
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 16 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-02-27 rik5 StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2018-02-27 carandraug StatusFixed => In Progress
        Open/ClosedClosed => Open
    2018-02-27 rik5 StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2018-02-27 rik5 StatusNeed Info => In Progress
    2018-02-27 rik5 Summary> Can't close window popping up after "gray" command while pager is active => Can't close window popping up after "gray" command while pager is active
    2018-02-27 carandraug SummaryCan't close window popping up after "gray" command while pager is active => > Can't close window popping up after "gray" command while pager is active
    2018-02-25 philipnienhuis SummaryCan't cancel out the popped up window => Can't close window popping up after "gray" command while pager is active
    2018-02-25 sebald Attached File- => Added octave-figure_do_not_ignore_close-djs2018feb25.patch, #43395
    2018-02-25 philipnienhuis StatusWorks For Me => Need Info
    2018-02-24 philipnienhuis StatusNone => Works For Me
        Operating SystemGNU/Linux => Any
    2018-02-24 hodor123456 Attached File- => Added errors.png, #43394
        Carbon-Copy- => Added dildarsk101010@gmail.com

    Back to the top


    Powered by Savane 3.5