bugGNU Octave - Bugs: bug #44175, GUI differences between qt and fltk

 
 

bug #44175: GUI differences between qt and fltk

Submitted by:  Michael Godfrey <godfrey>
Submitted on:  Tue 03 Feb 2015 05:29:35 PM UTC  
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  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)

Tue 17 Feb 2015 11:27:07 PM UTC, comment #14: 

I fixed the problem with the default directory being one directory above the pwd in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/ca6fc882177d).  I also changed the default filename for saving figure in FLTK to untitle.pdf to match Qt.

Closing report.

Rik <rik5>
Project Administrator
Wed 04 Feb 2015 04:40:57 AM UTC, comment #13: 

Rik: Correct. But the fact that they both use OpenGL does
not guarantee that they both do everything correctly.
Once qt printing is working your test plan sounds good,
especially if there are enough plots.

But, keep in mind that all plotting that goes to OpenGL
has to deal with the 32-bit range limit. A data rescaling
needs to be implemented (independent of which toolkit is
in use) so that data overflow does not occur. Of course,
obviously not before 4.0.

Michael Godfrey <godfrey>
Project Member
Wed 04 Feb 2015 02:19:53 AM UTC, comment #12: 

Qt printing is certainly a blocker for 4.0, but jwe should take care of it soon.  FLTK and Qt are just windows on to a canvas that is drawn with OpenGL.  Both toolkits use the same backend so there shouldn't be visual differences between the two.  For printing, both use the same backend of gl2ps so there shouldn't be any differences there either.  We have a script that will dump all the demos from the plot directory so that you can compare gnuplot, matlab, fltk, and qt.  We should do that before the 4.0 release and eye up the plots.

Rik <rik5>
Project Administrator
Wed 04 Feb 2015 01:52:54 AM UTC, comment #11: 

Also, I do not think that qt plotting needs to be
exactly like fltk, but it does need to be able to
draw and print the same plots. And, scripts that produce
plots using fltk should produce the same results under qt.

Michael Godfrey <godfrey>
Project Member
Wed 04 Feb 2015 01:49:22 AM UTC, comment #10: 

Rik: right. I tried that patch on simple plots.
Do you feel that it becoming fully functional
should be a blocker for 4.0?

It will need quite a bit of testing since there
are lots of options, and lots of different plots, etc.

Michael Godfrey <godfrey>
Project Member
Wed 04 Feb 2015 01:45:48 AM UTC, comment #9: 

jwe demonstrated a patch on the Octave Maintainers list that allows printing with the qt toolkit.  He just needs to finalize and commit it and then that roadblock will be removed.

Rik <rik5>
Project Administrator
Wed 04 Feb 2015 01:36:15 AM UTC, comment #8: 

qt plotting seems to work, but since print("xxx.pdf")
does not, I think that it is a bit early to abandon fltk.
I and I think others have plots which gnuplot cannot
handle and these do need to be printed as PDFs.

Michael Godfrey <godfrey>
Project Member
Wed 04 Feb 2015 12:14:46 AM UTC, comment #7: 

I wouldn't remove FLTK immediately, but I agree that once Qt can be used from the command line we can begin letting this go.  Probably start just by announcing its deprecation and not spending time fixing anything for it.  It should still look pretty good because the actual rendering is done by OpenGL and gl-render.cc will continue to get bug fixes.

Rik <rik5>
Project Administrator
Tue 03 Feb 2015 11:25:15 PM UTC, comment #6: 

I'm currently working on improving mouse interaction along with the zoom, pan, and rotate3d functions so they are a bit more compatible with Matlab.

Once the Qt-based plot windows work well and https://savannah.gnu.org/bugs/?44116 is solved, is there any reason to keep the FLTK version around?  It seems like a waste of effort to me to try to keep them functionally equivalent.

John W. Eaton <jwe>
Project Administrator
Tue 03 Feb 2015 09:17:17 PM UTC, comment #5: 

Another difference is that FLTK does pan or rotate on the left mouse button and uses the right button for selecting an area of the plot to zoom in on.  This seems pretty reasonable.

Rik <rik5>
Project Administrator
Tue 03 Feb 2015 07:07:09 PM UTC, comment #4: 

@Michael: I added the two new bugs as dependencies of this bug.  This should help to keep things coordinated so that just one isn't fixed.

Rik <rik5>
Project Administrator
Tue 03 Feb 2015 06:52:40 PM UTC, comment #3: 

Rik,

Yes I will split the report in two.  But, it should
be that the two parts are coordinated so that the target
of consistent behavior gets done.

Michael Godfrey <godfrey>
Project Member
Tue 03 Feb 2015 06:08:42 PM UTC, comment #2: 

Can you break this into two bug reports with the changes for FLTK in one and the changes for Qt in another.

Another item to report, the Qt "New Figure" menu option doesn't seem to do anything.

Rik <rik5>
Project Administrator
Tue 03 Feb 2015 05:38:07 PM UTC, comment #1: 

Also, I should add that I could not find the way to
select the output type for the plot from the save or
save as windows.. PDF seems to be
the default. There may be a way. I just could not find it...

Michael Godfrey <godfrey>
Project Member
Tue 03 Feb 2015 05:29:35 PM UTC, original submission:  

I just tried some plotting using fltk and qt in GUI and CLI mode.
There are substantial differences between the choices. It would
be helpful to users, I think, if they both followed similar
conventions.

First, using fltk in either GUI or CLI:
if you click on the figure box
file -> save or save as (both behave the same way -- is this
intended??) you get a dialog box which shows under "look in"
the directory just ABOVE the current directory and in the box
for "filename" it shows the name of the current directory. If you
accept these defaults the plot is written to the directory above
the current one with the name "current_dir".pdf.  This does not seem to be a helpful default setting. And, I could not find a way
to cause the directory to be changed to the current directory.

And, in GUI using qt the plot appears, but it lacks the choices
available under fltk, such as grid lines, etc. And, the choices
under "file" to save or save as are grayed out. So, the only
way to save a plot is print(xxx.pdf") which writes the PDF in
the current directory as expected.

It is clear that:
1. The default directory for file choices should be the
   current directory for both qt and fltk.
2. The default name for the plot file should NOT be the
   current directory name. A better choice might be like the
   heading shown on the plot: "Figure_nn"
3. It would be helpful if the file-> save and save as
   choices were available in GUI/qt mode as they are for fltk.

It seems to me that this should be considered as blocking
for the release since having users figure this out and then
changing it to something that makes more sense would be
pretty disruptive.

Michael

Michael Godfrey <godfrey>
Project Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Carbon-Copy List
  • -email is unavailable- added by jwe (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-02-17 rik5 StatusNone => Fixed
        Open/ClosedOpen => Closed
    2015-02-03 rik5 Dependencies- => Depends on bugs #44177
    2015-02-03 rik5 Dependencies- => Depends on bugs #44178

    Back to the top


    Powered by Savane 3.5