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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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...
|
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
|