Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2014-03-09 10:12:04
|
Jérôme,
I've been looking at the Qt terminal code to address sizing retention.
Through some dialog for patch #661 Ethan and I began to question the
differences between Qt versions and how that would effect an initial
incorrect plot size that I and apparently Mojca are seeing.
I'm beginning to suspect that is the case, and what is different between
the Qt versions is probably the obscure size hint. Newer versions are
probably more accurate. However, I'm wondering if we can get away from
the size hint and get direct results with just a little clean up of
QtGnuplotWidget::processEvent()
The gist of it is that QtGnuplotWidget is made to be the central widget
of the QMainWindow, so I would guess just doing that alone is enough to
impart size adjustment on QtGnuplotWidget without having to process
GESetWedgetSize inised processEvent. But before addressing that, I'd
like to clear up the layout of the widgets in the main window.
Now, from what Ethan describes, the size specifications option for qt
terminal refers to the outer dimensions of the QMainWindow, not the
plotting area. I think the documentation could be clearer on this:
"The size of the plot area is given in pixels, it defaults to 640x480.
In addition to that, the actual size of the window also includes the space
reserved for the toolbar and the status bar."
The 640x480 is not the plot area, more accurately the "size of the
window". Is there consensus on this?
If there is, then here is another question. What do
term->xmax
term->ymax
represent to the core code? Outer window dimensions? Or the plot area?
I ask because if it is the latter, then
// Set plot size
if (qt_setSize)
{
term->xmax = qt_oversampling*qt_setWidth;
term->ymax = qt_oversampling*qt_setHeight;
qt_setSize = false;
}
seems questionable. If the latter, then really the size should be sent
to gnuplot_qt, which then computes the plotting area size and sends that
info back to the inboard driver, which eventually ends up in term->xmax,
term->ymax.
Let's clarify these things and then proceed to do a little bit of
cleanup of the code.
Dan
|
|
From: Jérôme L. <lod...@us...> - 2014-03-09 21:07:15
|
The bottom line is that setting a custom size for a widget with Qt is no less than a nightmare. Apparently, there is no way to tell Qt that the widget should have a given size to start with, and then be resizable. So I have spend countless hours trying to find tweaks to emulate this behaviour, as until now all my attempts have resulted in an incorrect behaviour for at least one Qt version on one platform. I would be very happy if you come up with code that works correctly, but this task is not easy because this code has to be tested on the 3 platforms (Unix, OSX, windows) which have different sizing policy for widgets, and with Qt 4 and Qt 5. > I'm beginning to suspect that is the case, and what is different between > the Qt versions is probably the obscure size hint. Newer versions are > probably more accurate. However, I'm wondering if we can get away from > the size hint and get direct results with just a little clean up of The size hint tweak is a very recent addition that is used to set the size of the window before it is displayed. Before this addition, the window was resized after it is display, and sometimes was stuck in a wrong size. > Now, from what Ethan describes, the size specifications option for qt > terminal refers to the outer dimensions of the QMainWindow, not the > plotting area. I think the documentation could be clearer on this: I was not aware of this interpretation of the specification, but it looks weird to me. Setting the size of the window would mean that the size of the plotting area would depend, for instance, on whether the toolbar is hidden or not, on the window decoration for the title bar... Also, don't forget that the QtGnuplotWidget can also be used without a QtGnuplotwindow around it. it can be embedded in any Qt application, in which case I don't know what size the widget should actually report to the gnuplot core if the size the widget usually reports is the total window size. > "The size of the plot area is given in pixels, it defaults to 640x480. > In addition to that, the actual size of the window also includes the space > reserved for the toolbar and the status bar." > > The 640x480 is not the plot area, more accurately the "size of the > window". Is there consensus on this? > The code of the qt terminal as it is written now, assumes the opposite: the size set by the "size" option of the "set term qt" command is the size of the plotting area (more precisely of the viewport widget of the QGraphicsView showing the plot), and the application that embeds the plot area, which can be (but not necessarily is) a QtGnuplotWindow, takes care of reserving more screen space to fit other widgets, such as a toolbar, a title bar... > If there is, then here is another question. What do > > term->xmax > term->ymax > > represent to the core code? Outer window dimensions? Or the plot area? They are set to qt_oversampling multiplied by the plot area dimensions. Jérôme |
|
From: Daniel J S. <dan...@ie...> - 2014-03-09 21:47:21
|
On 03/09/2014 04:07 PM, Jérôme Lodewyck wrote: > The bottom line is that setting a custom size for a widget with Qt is no less > than a nightmare. Apparently, there is no way to tell Qt that the widget > should have a given size to start with, and then be resizable. So I have spend > countless hours trying to find tweaks to emulate this behaviour, as until now > all my attempts have resulted in an incorrect behaviour for at least one Qt > version on one platform. I would be very happy if you come up with code that > works correctly, but this task is not easy because this code has to be tested > on the 3 platforms (Unix, OSX, windows) which have different sizing policy for > widgets, and with Qt 4 and Qt 5. I think there are ways to control this in Qt utilizing the QLayout family of objects. A QLayout is a container class and one adds widgets and then lets Qt do the work. http://qt-project.org/doc/qt-4.8/layout.html (You've used this so I'm sure you are aware of it.) I think the QLayout can be placed in different modes (e.g., how to handle stretch), use QSpace to put space between widgets if desired, etc. It's just a matter of finding the right combination of settings and groupings. But it looks to me that for the Qt gnuplot_qt window it is pretty much the QMainWindow with only one widget--the plot area (or view port), and that plot area is what is the mandatory central widget. The status bar and menus are all standard parts of the QMainWindow. Since QMainWindow has a layout which can be set, I have to think that QMainWindow will figure out the dimensions for that central widget. It's what is left over from all the other items on the QMainWindow. (Or perhaps there is some way of making the size of the central widget immutable so that Qt has to resize the QMainWindow in order to fit around the central widget. I'm not sure.) >> I'm beginning to suspect that is the case, and what is different between >> the Qt versions is probably the obscure size hint. Newer versions are >> probably more accurate. However, I'm wondering if we can get away from >> the size hint and get direct results with just a little clean up of > > The size hint tweak is a very recent addition that is used to set the size of > the window before it is displayed. Before this addition, the window was > resized after it is display, and sometimes was stuck in a wrong size. I think that can be fixed. >> Now, from what Ethan describes, the size specifications option for qt >> terminal refers to the outer dimensions of the QMainWindow, not the >> plotting area. I think the documentation could be clearer on this: > > I was not aware of this interpretation of the specification, but it looks weird > to me. Setting the size of the window would mean that the size of the plotting > area would depend, for instance, on whether the toolbar is hidden or not, on > the window decoration for the title bar... Let's confirm this with Ethan and others. But I think that is the behavior. If one tears a dockable item off of the QMainWindow it opens up space and the plot can be made bigger. The alternate would be to shrink the main window. It could be programmed either way. I'm in the middle of programming this right now, so it would be good to know how it should behave. > Also, don't forget that the QtGnuplotWidget can also be used without a > QtGnuplotwindow around it. it can be embedded in any Qt application, in which > case I don't know what size the widget should actually report to the gnuplot > core if the size the widget usually reports is the total window size. Yes, that is true. I see that is how qt_graphics() is programmed right now. In the case of an external widget, I suppose it is easy; just inquire what the window size is for the widget. Any size specifications don't apply when there is an external widget. The external Qt window is more analogous to the viewport but perhaps not necessarily the gnuplot_qt window. >> "The size of the plot area is given in pixels, it defaults to 640x480. >> In addition to that, the actual size of the window also includes the space >> reserved for the toolbar and the status bar." >> >> The 640x480 is not the plot area, more accurately the "size of the >> window". Is there consensus on this? >> > > The code of the qt terminal as it is written now, assumes the opposite: the > size set by the "size" option of the "set term qt" command is the size of the > plotting area (more precisely of the viewport widget of the QGraphicsView > showing the plot), and the application that embeds the plot area, which can be > (but not necessarily is) a QtGnuplotWindow, takes care of reserving more > screen space to fit other widgets, such as a toolbar, a title bar... OK, what you describe is what I originally understood from the Qt documentation. Again, I'm not sure that is what it is supposed to be. Dan |
|
From: Daniel J S. <dan...@ie...> - 2014-03-09 22:00:04
|
On 03/09/2014 04:47 PM, Daniel J Sebald wrote: > On 03/09/2014 04:07 PM, Jérôme Lodewyck wrote: >> The code of the qt terminal as it is written now, assumes the >> opposite: the >> size set by the "size" option of the "set term qt" command is the size >> of the >> plotting area (more precisely of the viewport widget of the QGraphicsView >> showing the plot), and the application that embeds the plot area, >> which can be >> (but not necessarily is) a QtGnuplotWindow, takes care of reserving more >> screen space to fit other widgets, such as a toolbar, a title bar... > > OK, what you describe is what I originally understood from the Qt > documentation. Again, I'm not sure that is what it is supposed to be. By the way, x11 window retains the plot dimensions when type 'm' to add/remove the status bar. That behavior isn't the same as Qt. Dan |
|
From: Daniel J S. <dan...@ie...> - 2014-03-10 06:36:19
|
On 03/09/2014 04:47 PM, Daniel J Sebald wrote: > I'm in the > middle of programming this right now, so it would be good to know how it > should behave. I've placed an initial version Qt window size retention on the patch tracker: http://sourceforge.net/p/gnuplot/patches/663/ I left the behavior of the window sizing as is for now, and there are still a couple bugs associated with the size retention. However, the important thing is the conceptual changes, and I'd like to know if you think it is an improvement. Dan PS: One comment for anyone interested in Qt programming. Try to avoid any use of dynamic_cast<>, i.e., a glorified form of casting for Qt. If you think you can't avoid using that syntax, then try harder. :-) The reason is that whenever that syntax is necessary, one is almost assured to be programming Qt in a way that doesn't fit its paradigm and will prove to be a problem down the road. One is better off approaching things in a different way. With Qt it usually takes a little trial and error to find the best setup, but once it's found things fall in place pretty nicely. |
|
From: Daniel J S. <dan...@ie...> - 2014-03-15 03:28:31
|
On 03/10/2014 01:36 AM, Daniel J Sebald wrote: > On 03/09/2014 04:47 PM, Daniel J Sebald wrote: > >> I'm in the >> middle of programming this right now, so it would be good to know how it >> should behave. > > I've placed an initial version Qt window size retention on the patch > tracker: > > http://sourceforge.net/p/gnuplot/patches/663/ Mojca, If you have some time this weekend, please try out the Qt window size retention patch. Dan |
|
From: Mojca M. <moj...@gm...> - 2014-03-17 20:21:13
Attachments:
scaling.png
|
On Sat, Mar 15, 2014 at 4:20 AM, Daniel J Sebald wrote: > On 03/10/2014 01:36 AM, Daniel J Sebald wrote: >> >> On 03/09/2014 04:47 PM, Daniel J Sebald wrote: >> >>> I'm in the >>> middle of programming this right now, so it would be good to know how it >>> should behave. >> >> >> I've placed an initial version Qt window size retention on the patch >> tracker: >> >> http://sourceforge.net/p/gnuplot/patches/663/ > > > Mojca, > > If you have some time this weekend, please try out the Qt window size > retention patch. I'm very grateful for the change that keeps me in terminal as opposed to jumping to the plotting area and having to alt-tab back to terminal after every command. I'm not sure how to reproduce the following (and maybe I should check with master), but as a rule of thumb it happened when I had all the cores 100% occupied with other tasks: Terminal type set to 'qt' gnuplot> plot sin(x) qt_graphics: "QLocalSocket: Socket operation timed out" qt_graphics: Not receiving requested widget size Error: short read from gnuplot_qt socket while expecting font metrics warning: Too many axis ticks requested (>1e+01) warning: Terminal canvas area too small to hold plot. Check plot boundary and font sizes. warning: Too many axis ticks requested (>1e+01) warning: Too many axis ticks requested (>4) Other than that it sometimes happens that I don't get any text labels at all (one of the things that Ethan fixed), but don't hold my word for it because I'm not sure if that was a side effect of forgetting "make install" or if that was a real issue. The second plot shrinks – it uses a different plotting area. (The first plot doesn't fully fit into the window – x axes labels are too low. The second plot now fixes that by using smaller plotting area.) I'm not sure about the pattern (how exactly to reproduce it), but very often sizes of the plots are completely off (either too small or too big). The ratio seems right, but scaling is not. See the attachment. Please note that I have "Replot on resize" switched off (because it's not bearable to have it turned on as it resizes every few pixels.) But usually the plot should adjust after calling "plot ...". Here it sometimes does and sometimes doesn't. >From time to time I also get gnuplot> qt_graphics: "QLocalSocket: Socket operation timed out" qt_graphics: Not receiving requested widget size qt_graphics: "QLocalSocket: Socket operation timed out" qt_graphics: Not receiving requested widget size (with "Replot on resize" turned on). I didn't try to understand the changes in the source code, I was only testing the functionality. (I'm not saying that everything reported above is specific to the patch. Some problems might be present in trunk already. I would need to check more carefully, but some "errors/problems" are somewhat random.) Mojca |
|
From: Daniel J S. <dan...@ie...> - 2014-03-23 14:49:56
|
On 03/17/2014 03:21 PM, Mojca Miklavec wrote: > On Sat, Mar 15, 2014 at 4:20 AM, Daniel J Sebald wrote: >> On 03/10/2014 01:36 AM, Daniel J Sebald wrote: >>> >>> On 03/09/2014 04:47 PM, Daniel J Sebald wrote: >>> >>>> I'm in the >>>> middle of programming this right now, so it would be good to know how it >>>> should behave. >>> >>> >>> I've placed an initial version Qt window size retention on the patch >>> tracker: >>> >>> http://sourceforge.net/p/gnuplot/patches/663/ >> >> >> Mojca, >> >> If you have some time this weekend, please try out the Qt window size >> retention patch. > > I'm very grateful for the change that keeps me in terminal as opposed > to jumping to the plotting area and having to alt-tab back to terminal > after every command. > > I'm not sure how to reproduce the following (and maybe I should check > with master), but as a rule of thumb it happened when I had all the > cores 100% occupied with other tasks: > > Terminal type set to 'qt' > gnuplot> plot sin(x) > qt_graphics: "QLocalSocket: Socket operation timed out" > qt_graphics: Not receiving requested widget size > Error: short read from gnuplot_qt socket while expecting font metrics > warning: Too many axis ticks requested (>1e+01) > warning: Terminal canvas area too small to hold plot. > Check plot boundary and font sizes. > warning: Too many axis ticks requested (>1e+01) > warning: Too many axis ticks requested (>4) > > Other than that it sometimes happens that I don't get any text labels > at all (one of the things that Ethan fixed), but don't hold my word > for it because I'm not sure if that was a side effect of forgetting > "make install" or if that was a real issue. > > The second plot shrinks – it uses a different plotting area. (The > first plot doesn't fully fit into the window – x axes labels are too > low. The second plot now fixes that by using smaller plotting area.) > > I'm not sure about the pattern (how exactly to reproduce it), but very > often sizes of the plots are completely off (either too small or too > big). The ratio seems right, but scaling is not. See the attachment. > Please note that I have "Replot on resize" switched off (because it's > not bearable to have it turned on as it resizes every few pixels.) But > usually the plot should adjust after calling "plot ...". Here it > sometimes does and sometimes doesn't. > >> From time to time I also get > > gnuplot> qt_graphics: "QLocalSocket: Socket operation timed out" > qt_graphics: Not receiving requested widget size > qt_graphics: "QLocalSocket: Socket operation timed out" > qt_graphics: Not receiving requested widget size > > (with "Replot on resize" turned on). > > I didn't try to understand the changes in the source code, I was only > testing the functionality. > > (I'm not saying that everything reported above is specific to the > patch. Some problems might be present in trunk already. I would need > to check more carefully, but some "errors/problems" are somewhat > random.) Thanks Mojca. So generally it is about right, but occasionally is dropping data sent from the outboard gnuplot_qt. That's what I'm seeing as well. Something doesn't seem reliable about the comm link. It could be something I did, but note that a lot of resizing with the mouse means a lot of traffic. There are probably ways to reduce the traffic, say by recording the reported size on the inboard side, and we can do that. But first I'd prefer to leave a lot of traffic and fix the dropped data issue. Reducing its occurrence only makes it a harder bug to fix down the road. Dan |
|
From: Ethan A M. <sf...@us...> - 2014-03-17 20:28:23
|
On Monday, 17 March, 2014 21:21:05 Mojca Miklavec wrote: > > I'm very grateful for the change that keeps me in terminal as opposed > to jumping to the plotting area and having to alt-tab back to terminal > after every command. Huh??? The only terminal I've ever seen do that is the Windows terminal. That doesn't sound like something that was ever requested by gnuplot core or qt terminal code. Could it be that you have changed the focus policy in your window manager? Ethan |
|
From: Mojca M. <moj...@gm...> - 2014-03-17 22:22:23
|
On Mon, Mar 17, 2014 at 9:27 PM, Ethan A Merritt wrote: > On Monday, 17 March, 2014 21:21:05 Mojca Miklavec wrote: >> >> I'm very grateful for the change that keeps me in terminal as opposed >> to jumping to the plotting area and having to alt-tab back to terminal >> after every command. > > Huh??? > The only terminal I've ever seen do that is the Windows terminal. > That doesn't sound like something that was ever requested by gnuplot > core or qt terminal code. But it behaves that way on Mac with qt terminal since the beginning, I believe. > Could it be that you have changed the focus policy in your window manager? I don't have any clue how to "change the focus policy" on Mac (I don't know that for Linux either, but it's not like Mac OS X is very configurable in that respect). But I didn't touch any settings anyway other than switching back and forth between Qt 4 and 5. But I checked again. I'm unable to compile Daniel's patch with Qt4 without modifications. The code from "trunk" still puts the plot to front with Qt 4. But it keeps the plot in background with Qt 5. So it probably wasn't Daniel's patch. It might be that Qt 5 is simply behaving different than Qt 4. (There are sooooo many different combinations of Qt and gnuplot versions that I mixed that up a bit. I don't remember seeing the window kept it background, but maybe I simply forgot.) Mojca |
