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

 
 

bug #44175: GUI differences between qt and fltk

Submitter:  Michael Godfrey <godfrey>
Submitted:  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
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group 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.13-f8d8.
    Corresponding source code