bugGNU Octave - Bugs: bug #41665, 'qt' is default graphics toolkit...

 
 

bug #41665: 'qt' is default graphics toolkit even when it is not available

Submitted by:  Michael Godfrey <godfrey>
Submitted on:  Sat 22 Feb 2014 03:29:07 AM UTC  
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Michael Godfrey Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

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)

Fri 06 Feb 2015 05:48:34 AM UTC, comment #29: 

Checked in the changeset here (http://hg.savannah.gnu.org/hgweb/octave/rev/40e846a96908).  Closing report.

Rik <rik5>
Project Administrator
Thu 05 Feb 2015 02:59:22 AM UTC, comment #28: 

@Rik: your patch works perfectly for me. I can live with the current behavior too, but with this change it's even better. Thanks.

Mike Miller <mtmiller>
Project Administrator
Thu 05 Feb 2015 01:57:25 AM UTC, comment #27: 

@Mike: Can this bug be closed now?  The original reporter's issue, default graphics toolkit being an unavailable one, has been fixed.  In comment #24 you seemed to want to hold out for a solution that didn't print out a blank ("") toolkit at start-up.  I'm okay with the current behavior, but see the attached patch which I think does what you want.  If you like it I will commit it and close this report.

(file #32998)

Rik <rik5>
Project Administrator
Mon 02 Feb 2015 04:13:08 PM UTC, comment #26: 

I just found this bug report in the bug fix list for 4.0 release. I recently created a new bug for qt toolkit with --no-gui option: https://savannah.gnu.org/bugs/?44116

Stefan Mahr <dac922>
Wed 12 Mar 2014 11:23:25 PM UTC, comment #25: 

I don't disagree, but the problem is that the way the code is arranged, the default is set before any toolkits are registered. Either the code must be rearranged to delay the setting of defaultfigure__graphics_toolkit__, or it should be replaced with a call to gtk_manager.

Michael C. Grant <mcgrant>
Wed 12 Mar 2014 10:49:29 PM UTC, comment #24: 

The side-effect of graphics_toolkit returning an empty string at startup is kind of undesirable I would say. Any way to keep this fix and get that back? Should graphics_toolkit set the default underneath if it's called before the default has been decided yet?

Mike Miller <mtmiller>
Project Administrator
Wed 12 Mar 2014 08:12:39 PM UTC, comment #23: 

Looks great. I got an octave-gui segfault during "make check"; I will re-run the build in Homebrew verbose mode and try and track that down. But it still installed, and both octave-gui and octave-cli default to a working toolkit on the Mac. Thank you!

Michael C. Grant <mcgrant>
Wed 12 Mar 2014 07:46:25 PM UTC, comment #22: 

Looks great, actually. I will test it ASAP.

Michael C. Grant <mcgrant>
Wed 12 Mar 2014 07:42:52 PM UTC, comment #21: 

Since available_toolkits is a set and not a list, I think we need something more to ensure the toolkit priority is the way we want it to be if the default toolkit is unregistered.  I checked in the following changeset:

  http://hg.savannah.gnu.org/hgweb/octave/rev/ca1648b2e673

Does that look OK and does it work for you?

John W. Eaton <jwe>
Project Administrator
Wed 12 Mar 2014 03:49:58 PM UTC, comment #20: 

Oops, it looks like I left a line of debugging output in that patch. If you decide to apply it, and need me to generate a new one, let me know. (Or you can just delete the one line, most likely.)

Michael C. Grant <mcgrant>
Mon 10 Mar 2014 03:49:38 PM UTC, comment #19: 

I've created a patch that modifies the default toolkit setting as available toolkits are added. Priority is given to "qt", then "fltk", then "gnuplot".

One side effect of this approach is that if you call "graphics_toolkit" from the Octave command line before creating a figure, it will return the empty string. This is because the defaultfigure__graphics_toolkit__ value is initialized before the available toolkit list is initialized.

However, it looks like the code handles this properly, because if you attempt a plot, it seems to re-initialize this value. Subsequent calls to "graphics_toolkit" produce a non-empty result with the expected value ("fltk" for cli, "qt" for guy).

So it's a bit clumsy, but arguably no more clumsy then having a default value set before the available choices are loaded. And it has the added bonus that it works! I do think that the empty graphics_toolkit issue should be rectified somehow, but that requires more code rearrangement than I am willing to attempt without guidance. One option is to eliminate defaultfigure__graphics_toolkit__ as a static property and replace it with calls to gtk_manager.

(file #30844)

Michael C. Grant <mcgrant>
Mon 10 Mar 2014 01:16:01 PM UTC, comment #18: 

Sorry for posting a duplicate bug report (41821). But I do have an ulterior motive for seeing this problem addressed ASAP.

Recall that FLTK graphics in the GUI are broken on the Mac in the stable branch, due to Qt related problems unique to that OS. Whether this was intended or not, the new QT graphics toolkit addresses this problem.

Therefore, I've been building an option into the Homebrew octave recipe to build the gui-release branch. Unfortunately, that option breaks octave-cli due to this bug. Until the stable branch gets the Qt graphics option, or the FLTK issue is addressed in another way, I'd like to find a way to address this. (And no, it's not just to run my CVX toolkit; I have other patches that I'd like to integrate for that anyway :-))

Of course, the problem here is that the need to initialize 'dtk' before 'available_toolkits' has been properly initialized is the problem. It seems to me that a better approach would be to define some sort of priority rule in the registration process, so that as new toolkits are registered, the one with the highest priority is set to "dtk".

gtk_manager::gtk_manager (void)
  : dtk (), available_toolkits (), loaded_toolkits ()
{
#if defined (HAVE_QT)
  dtk = display_info::display_available () ? "qt" : "gnuplot";
#elif defined (HAVE_FLTK)
  dtk = display_info::display_available () ? "fltk" : "gnuplot";
#else
  dtk = "gnuplot";
#endif
}

Michael C. Grant <mcgrant>
Sun 23 Feb 2014 06:58:33 PM UTC, comment #17: 

The binaries available are always the same, octave-cli or octave-gui.  When working from a code tree, run-octave calls one or the other.  When installed, octave calls one or the other.

Rik <rik5>
Project Administrator
Sun 23 Feb 2014 05:33:51 PM UTC, comment #16: 

John: Thanks for the explanation. I do not think that
this needs more discussion here. But, it would be good
to have the current state and any expected changes
documented somewhere for developers and maintainers.
I think that the current user documentation is right
the way it is.

Finally, I infer from what you said that after a
make install, octave and make check end up
running different binaries. Is this necessary?

Michael Godfrey <godfrey>
Project Member
Sun 23 Feb 2014 05:13:36 PM UTC, comment #15: 

"octave --no-gui-libs"  causes the octave wrapper program to exec the "octave-cli" binary that is not linked to Qt libraries.  We could drop this option and just tell people that if they want to use a binary that is not linked with Qt, they should just run "octave-cli" directly.

The -cli option for ./run-octave bypasses the "octave" wrapper program and runs "octave-cli" directly.  It's useful for debugging, because we can start the debugger directly on the "octave-cli" program and do something useful.  Debugging the wrapper "octave" program as not very interesting.

If we want to discuss this further maybe we should do it on the mailing list or summarize all the details and requirements on a wiki page.  I think the whole situation is a big mess but I don't have a better solution than what we've already done.

John W. Eaton <jwe>
Project Administrator
Sun 23 Feb 2014 04:35:58 PM UTC, comment #14: 

Good. But, is it true that make check in the end
runs a different binary than is installed by
make install?

And, I assume that --no-gui-libs will go away when
John figures out the (difficult) cross platform issue.

So, back to fixing make check...

Sorry to nag you about this.

Michael Godfrey <godfrey>
Project Member
Sun 23 Feb 2014 04:28:29 PM UTC, comment #13: 

-cli is an option only to the run-octave script, not to octave, so I don't think it needs to be documented.  The only people who will ever need it, or can potentially use it, are developers working in a source tree.

The situation with --no-gui-libs is in flux.  I don't think jwe has hit upon the exact strategy for releasing Octave across Linux and Windows platforms.  I think it is fine to just wait and see what happens as this may disappear entirely.

Rik <rik5>
Project Administrator
Sun 23 Feb 2014 04:17:28 PM UTC, comment #12: 

OK. I think I get it. The following are documented user
options:

--force-gui
--no-gui

Undocumented and therefore should not be in the code that is
executed by calling octave:

-cli
--no-gui-libs

Should the fact that --no-gui-libs is accepted by octave be reported as a bug? It is not shown for octave -h, or any
call with bad options.

In any case octave calls octave-gui as the binary. Right?

Is it a good idea that the binary which is run in make check
is not the same as the binary which is installed by make install?
It would be better if make check used the same code that
the user will get after make install.

Michael Godfrey <godfrey>
Project Member
Sun 23 Feb 2014 03:41:00 PM UTC, comment #11: 

'run-octave' used in the development source tree has a -cli option.  The actual installed Octave binary does not.  The same effect can be had by calling octave with the '--no-gui-libs' option or directly invoking octave-cli.exe rather than octave-gui.exe.

The octave binary is now just a small wrapper which execs either octave-gui or or octave-cli.

Possible options
--no-gui-libs : Calls octave-cli which is a binary built without linking to the Qt libraries.  This is a CLI environment that can still do plotting with FLTK or gnuplot.

--no-gui : Calls octave-gui, a binary linked to Qt libraries, but doesn't launch the GUI and instead runs the CLI code in octave-gui.

--force-gui : Calls octave-gui and forces the launch of the GUI

NO OPTIONS : Calls octave-gui and launchs the GUI version.

Rik <rik5>
Project Administrator
Sun 23 Feb 2014 02:18:10 PM UTC, comment #10: 

According to the Manual there is no --cli option.
This is good and your impression that it is useful
in some way must be incorrect.

The bug reported here seems pretty trivial, but
it is useful to have make check working.

Michael Godfrey <godfrey>
Project Member
Sun 23 Feb 2014 01:56:05 PM UTC, comment #9: 

Out of habit and due to the experimental state of the GUI
I always use octave --no-gui.  I have seen no evidence that
this does not work correctly even if there is no graphics
display (no DISPLAY set in the environment, or equivalent).
Of course, if the is no DISPLAY, I cannot generate plots.

I believe that --cli would do the same for me. If this is
true the difference between --cli and --no-gui has something
that I do not understand about qt. Why can this not be dealt
with at runtime?  This would avoid the need for 2 command
line options which have to be explained to users.

I will take a look in the Manual for the current explanation
and see if I can understand it.

Michael Godfrey <godfrey>
Project Member
Sun 23 Feb 2014 11:43:18 AM UTC, comment #8: 

>> Part of the problem seems to me to be too many octaves.


I sing at a too high frequency? Promised, after this comment I shut up until I have something useful to say :-)

>> but is it really necessary?

I'd say yes:
 -cli -> necessary for platforms with no display or when octave was compiled without Qt libraries
 -no-gui -> when printing is no more an issue in 'qt' graphics_toolkit, this should be the preferred one for 'make check' (maybe for the documentation also) when octave was compiled with Qt.
 -GUI

Pantxo Diribarne <pantxo>
Project Member
Sun 23 Feb 2014 05:29:50 AM UTC, comment #7: 

Part of the problem seems to me to be too many octaves.
I remember the arguments for going this route, but is
it really necessary?

Michael Godfrey <godfrey>
Project Member
Sun 23 Feb 2014 02:00:24 AM UTC, comment #6: 

@ Michael: sorry, I didn't want to troll this bug report, I just wanted to note that the new title was a bit misleading. Anyway I agree that "make check" should not rely on qt graphics toolkit which has currently no print capabilities (necessary for some tests).

@ Rik: -cli (AFAIU equivalent to --no-gui-libs) is different from --no-gui. The latter includes a QtApplication which is designed to run qt graphics toolkit (even if the GUI is disabled), whereas the former is our good old one threaded octave, not Qt capable.

Pantxo Diribarne <pantxo>
Project Member
Sat 22 Feb 2014 09:50:27 PM UTC, comment #5: 

That's why I want to have the sanity checking on toolkits first, and the addition of 'qt' to the CLI as a separate issue.  'make check' has indeed caught an error that needs to be fixed.

Rik <rik5>
Project Administrator
Sat 22 Feb 2014 08:40:51 PM UTC, comment #4: 

For me the original point was that make check now fails
for wrong reasons.  The first priority should be to get
make check working again. Is it a good idea to cause
make check depend on qt?  I would say no.

Of course, it would be nice if qt were available in CLI
mode, and this would "fix" make check as a side effect.

Others should decide on the best way to fix the reported
problem.

Michael Godfrey <godfrey>
Project Member
Sat 22 Feb 2014 08:08:55 PM UTC, comment #3: 

I agree that 'qt' should be available in CLI mode.  I don't know how much work that will or won't take.  Could you file a different bug report about that?

I think it is still worthwhile to have some sanity checking on the default graphics toolkit which prevents this problem from happening now, or in the future if we add yet more toolkits.  I want to keep this bug report about that issue.

Rik <rik5>
Project Administrator
Sat 22 Feb 2014 05:48:57 PM UTC, comment #2: 

I think it should be noted that the 'qt' graphics toolkit should be available in --no-gui mode. AFAIR, this mode is meant to run qt toolkit(s). 

Pantxo Diribarne <pantxo>
Project Member
Sat 22 Feb 2014 04:36:41 PM UTC, comment #1: 

I re-titled to what I think is the real issue.

run-octave -f --no-gui
available_graphics_toolkits
ans =
{
  [1,1] = fltk
  [1,2] = gnuplot
}
default = graphics_toolkit
default = qt

At some point there was similar testing code to make sure that FLTK wasn't set if it didn't exist.

Rik <rik5>
Project Administrator
Sat 22 Feb 2014 03:29:07 AM UTC, original submission:  

This causes 23 FAILS when make check is run.
./run-octave --no-gui  runs the tests, like
test graphics.cc-tst with no failures.

Example error from fntests.log is:

66822: >>>>> processing /run/media/godfrey/GoFlex08/qss/d/src/octave/hg/octave/libinterp/corefcn/graphics.cc-tst
66823:   ***** test
66824:  hf = figure ("visible", "off");
66825:  h = plot (1:10, 10:-1:1);
66826:  set (h, "linewidth", 10, "marker", "x");
66827:  lw = get (h, "linewidth");
66828:  mk = get (h, "marker");
66829:  close (hf);
66830:  assert (lw, 10);
66831:  assert (mk, "x");
66832: !!!!! test failed
66833: default graphics toolkit 'qt' is not available!

Michael Godfrey <godfrey>
Project Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #32998:  bug_41665.cset added by rik5 (1KiB - application/octet-stream)
file #30844:  toolkit.diff added by mcgrant (3KiB - application/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by dac922 (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by mcgrant (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by godfrey (Submitted the item)
  •  

    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 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-02-06 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2015-02-05 rik5 Attached File- => Added bug_41665.cset, #32998
        StatusConfirmed => Ready For Test
    2014-03-10 mcgrant Attached File- => Added toolkit.diff, #30844
    2014-03-10 mtmiller Dependencies- => bugs #41821 is dependent
    2014-02-22 rik5 StatusNone => Confirmed
        Summarymake check thinks qt graphics toolkit not available => 'qt' is default graphics toolkit even when it is not available

    Back to the top


    Powered by Savane 3.5