> >Comment By: Petr Mikulik (mikulik)
> Date: 2009-07-21 02:28
>
> Message:
> ./configure says:
>
> Requested 'QtCore >= 4.5' but version of Qtcore is 4.4.3
> Requested 'QtGui >= 4.5' but version of Qtgui is 4.4.3
> Requested 'QtNetwork >= 4.5' but version of Qtnetwork is 4.4.3
> Requested 'QtSvg >= 4.5' but version of Qtsvg is 4.4.3
>
> Does it really need version 4.5? On my latest OpenSUSE 11.1 the latest is
> libqt4-devel-4.4.3-4.8.2.
Not sure.
> If 4.5 is required, it will take ages before the terminal can be used.
> Could you support other 4.x?
I think 4.5 will be adopted very quickly, at least on the linux side,
if only because of the LGPL licensing.
I have it already on current Mandriva, and it looks like there is support in
Suse 11.1 also:
http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_11.1/i586/
libqt4-4.5.2-53.2.i586.rpm
libqt4-devel-4.5.2-53.2.i586.rpm
etc
Ethan
> ----------------------------------------------------------------------
>
> Comment By: Jérôme Lodewyck (lodewyck)
> Date: 2009-07-19 08:56
>
> Message:
> New patch
>
> - fixes various font problems
> - select background color UI
> - mouse wheel scroll and zoom
>
> ----------------------------------------------------------------------
>
> Comment By: Jérôme Lodewyck (lodewyck)
> Date: 2009-07-06 21:42
>
> Message:
> Here it is.
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-07-06 17:21
>
> Message:
> Build fails with the new patch, because it does not contain the file
> term/qt.trm
> Oversight when the patch file was created?
>
>
> ----------------------------------------------------------------------
>
> Comment By: Jérôme Lodewyck (lodewyck)
> Date: 2009-07-04 19:21
>
> Message:
> Here is a new patch. It includes the locale patch, and fixes the dist
> building error. It still needs the separate image tarball.
> About the font problem, I can set the terminal font with
> set term qt font "times,20"
> Is this not working for you ?
>
> I would be delighted to have this patch included in CVS. There are a few
> things to settle:
> - The images are taken from the KDE project, and are under the Creative
> Commons Attribution-NonCommercial-NoDerivs 2.5 License. Is it possible to
> include them as such in the gnuplot CVS ?
> - How to submit further development of the terminal ? With new patches, or
> by continuing on this one ?
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-06-17 05:06
>
> Message:
> I am inclined to move this patch implementing a Qt terminal into CVS so
> that it gets wider testing. Also because I like the terminal :-)
>
> Is that OK, or did you have more you wanted to work on while it was still
> a separate patchset?
>
> I have found two things that need attention, but neither would prevent
> testing and initial use:
>
> 1) I cannot figure out how to select a font. I can see in the code that
> there is a call to QFont(), but it does not see to do anything. If I
> replace "Sans" in the source code with a hard-coded alternative, then it
> works. But passing a font in through the user interface does not work.
>
> 2) The build targets "make check" "make distcheck" and "make dist",
> used for packaging the source tree for distribution, fail due to some
> problem with the qt targets. I don't understand what is going on here, but
> I am no expert at all when it comes to the autoconf tools.
>
>
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-06-08 06:25
>
> Message:
> Here is a patch to fix the encoding problem.
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-06-02 22:59
>
> Message:
> Locale handling changed between version 4.2 and the CVS version (which will
> become 4.4). What I say now applies to the CVS version.
>
> For the intended behaviour, see "help set decimal". If you find that
> something else is happening in practice - that is a bug.
>
> Here is an outline of how it is supposedly working. Please report any
> observed deviation.
>
> 1) The program sets the numeric locale to "C" on entry. You can confirm
> this by typing "show decimal". It should report that the decimal separator
> is a period, even if your global locale is such that it would be a comma.
>
> 2) You can change the treatment of decimals on input and output using
> "set decimal locale". Again see "help set decimal" for more information.
> However, the program _does not change_ the internal locale setting at this
> point. It simply remembers your preference.
>
> 3) When data is read from a file, or formatted for printing on the plot,
> the program temporarily sets the numeric locale to whatever you stored as a
> preference. When it is done reading or formatting, it sets the locale back
> to "C".
>
> 4) As a consequence of (3), the numeric locale should never be anything
> except "C" inside terminal driver code. Reading data from a file does not
> involve calling a terminal driver at all, and when strings are printed they
> are formatted first and then sent to the terminal driver afterward.
>
>
>
> However, it is believable that some call to a Qt library changes the
> locale setting. Or the locale setting may not be preserved across the
> fork/exec to start a separate Qt process. I remember that we had a similar
> problem with the wxt terminal. Here is the ChangeLog entry:
>
> 2008-03-17 Ethan A Merritt <merritt@...>
> * src/wxterminal/wxt_gui.cpp (wxt_init): Restore the locale
> settings
> for both LC_TIME and LC_NUMERIC, but only after the GTK+ thread
> has
> finished mangling them.
> Bug #1916190
>
> And here is the patch:
> http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/wxterminal/wxt_gui.cpp?r1=1.62&r2=1.63
>
> The initialization code for the Qt driver may need a similar patch.
>
> Or, of course, there may be a bug somewhere else :-)
>
>
> ----------------------------------------------------------------------
>
> Comment By: Jérôme Lodewyck (lodewyck)
> Date: 2009-06-02 21:43
>
> Message:
> Here is a new patch.
>
> A new strange bug has appeared. When running gnuplot with the Qt terminal
> in a french local environment, some bugs pop up here and there, such as
>
> ******************** file electron.dem ********************
>
> gnuplot> plot Ic(Vbe)
> ^
> "electron.dem", line 27: Can't plot with an empty x range!
>
>
> All these bugs disappear if I set the environment variable
> export LC_NUMERIC=.
>
> So apparently Qt is changing the decimal separator. What is the gnuplot
> policy about locale settings ? If I find a way to tell Qt to use the "."
> decimal separator in any locale, would that be OK ?
>
>
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-06-02 14:22
>
> Message:
> Oops. I don't know why the file didn't show up. I'm not used to this new
> SourceForge interface yet.
>
> ----------------------------------------------------------------------
>
> Comment By: Jérôme Lodewyck (lodewyck)
> Date: 2009-06-02 07:48
>
> Message:
> I cannot find your updated patch in the file list. Is it somewhere else ?
>
> I have been away from hacking lately, but I have a pending update for the
> patch on my hard drive. I will try to merge it with your patch and submit
> it shortly.
>
> There is no such Qt5. I just mentionned that Qt 4.5 is the first LGPL
> version of Qt, thus it should be required to distribute the Qt terminal
> along with gnuplot. But from a technical point of view, Qt 4.5 is just a
> minor update that do not require a rewrite at all.
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-06-02 06:37
>
> Message:
> I've attached an updated patch file that compiles with current CVS. All
> changes are trivial except for a fix for extra lines in polygons.
>
> Do you want to do any more work on this driver before it goes into CVS?
>
> At one point I think you mentioned that Qt5 would require a re-write. Is
> it worth waiting till then?
> It would be nice to have more complete documentation, if nothing else.
>
> By the way, my earlier problem with no mouse response in the embed demo
> program seems to have gone away with a slightly newer libqt.
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-06-01 05:00
>
> Message:
> In preparation for eventual release of gnuplot version 4.4, existing bugs
> and patchsets are being re-prioritized.
>
> I have chosen to use the following categories
>
> 9 - should be included in 4.4.rc1 if possible
> 7 - looks reasonable to me, but not high priority for 4.4.rc1
> 5 - default priority for newly submitted patches
> 2 - not under active consideration
>
>
> These are my personal ratings. If you want to argue for a different
> priority on one or more patches - go right ahead.
>
> Ethan Merritt (sfeam)
>
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-02-17 06:39
>
> Message:
> > What is the gnuplot policy for background painting ?
>
> I don't think there is one. Most terminals do not have such an option.
> x11 uses the XResource gnuplot*background or the command line option -bg.
> The libgd terminals (png, jpeg, gif) allow a list of colors at the end of
> "set term command". The windows terminal pops up a color selection widget
> if you select "Background" from a pull-down menu.
> A qt color-selection widget would be neat, but I'd be happy with an option
> "set term qt background <colorspec>" if that's the easiest. The routine
> parse_colorspec() can be used to read it.
>
> > Your issue with multiplot seems strange
> I can't explain multiplot slowness either. I'm just reporting what I see.
> It seems to be worse when the system is loaded, which again may be a hint.
>
> > The purpose of the embed example is to show how to use the terminal
> > to embed plots in Qt applications. Mousing is working, but only on
> > the last plot displayed
>
> The embed example does not display mouse coordinates when I run it here.
> I'd be happy to provide more information if this is a bug and you tell me
> what I should look for or try.
>
>
> The TERM_HELP entry needs to be filled in more completely at some point.
> What does the "widget" option do? Is that for embedding the plot?
>
>
>
> ----------------------------------------------------------------------
>
> Comment By: Jérôme Lodewyck (lodewyck)
> Date: 2009-02-16 22:23
>
> Message:
> Thank you for your in-depth testing.
>
> - "running_avg.dem" is indeed working fine with your patch
>
> - splot mousing works after sending GE_plotdone
>
> - The driver control flow is the following : when initialized, the process
> forks. The parents returns to the gnuplot core, while the child starts the
> GUI. Events are sent between processes using a crossplatform IPC exposed by
> the Qt API.
>
> - Your issue with multiplot seems strange to me. Here, it is working fine,
> and all plots are displayed almost instantaneously. The very first version
> of the terminal was much slower and multiplot were indeed amongst the
> slowest to be drawn. Is there some special procedure triggered by gnuplot
> between each plot drawing ?
>
> - When using the wxt terminal with the Qt theme for GTK widgets, Qt
> libraries version 3 are loaded and conflict with QT 4 libraries, hence the
> crash. In this configuration, compiling with Qt enabled forbids ever using
> the wxt terminal with the generated binary. With another theme, is is
> possible to select the wxt terminal or the qt terminal at runtime. However,
> successively plotting with both terminal in the same gnuplot session
> crashes because Qt internally uses the glib event loop. This issue should
> be resolved with the patch proposed by Timothée to run the wx terminal as
> an independant process.
>
> - The Control-C issue is probably a problem with both core and GUI process
> catching the signal. I wil have a closer look at it.
>
> - I don't think it is possible to specify the default background color
> independently from other default color settings. However, it is possible to
> programmatically have the background painted in white. What is the gnuplot
> policy for background painting ? Most terminal seem to choose white, but I
> tihink the X11 terminal background is rather grey-ish. Using the system
> color setting seems pretty sensible to me.
>
> - The purpose of the embed example is to show how to use the terminal to
> embed plots in Qt applications. Mousing is working, but only on the last
> plot displayed, as in standard gnuplot with multiple windows open.
>
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-02-16 05:54
>
> Message:
> > except 3D mousing for which I really don't know what I am doing wrong...
> >
>
> What's going wrong here is that the core code will not redraw the plot
> until it is notified that the previous draw event has finished. But this
> signal is never being sent. The qt driver needs to respond to term->text()
> by sending back an event GE_plotdone. I'm pretty sure that would fix the
> 3D mouse rotation.
>
> I think there is one more bit of cleverness that should be added to
> prevent hysteresis. Whenever a mouse motion event is received by the event
> loop, all other pending mouse motion events should be purged from the event
> queue. This makes a huge difference to the performance of the x11 driver,
> and I imagine it is similarly needed for qt.
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-02-16 04:10
>
> Message:
> > There is a curious error that causes the top border of the plot to be
> > drawn, even if it is disabled. See, for example, running_avg.dem.
> There
> > should be no right- or top- border on the plot. This plots also
> triggers
> > that "wrong polygon size" warning, so maybe it is a clue.
>
> I found some more cases of extra lines, and I think the fix is something
> like the following. It does fix the cases I found, but I'm working purely
> off intuition, so please sanity check the call:
>
> diff -urp QtGnuplotScene.cpp QtGnuplotScene.cpp.save
> --- QtGnuplotScene.cpp.save 2009-02-15 20:09:06.000000000 -0800
> +++ QtGnuplotScene.cpp 2009-02-15 20:09:02.000000000 -0800
> @@ -100,7 +100,6 @@ void QtGnuplotScene::flushCurrentPolygon
> if (m_currentPolygon.size() < 2)
> {
> fprintf(stderr, "Wrong polygon size %i\n",
> m_currentPolygon.size());
> + m_currentPolygon.clear();
> return;
> }
>
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-02-15 20:50
>
> Message:
> Nice!
>
> Could you please give a brief explanation of the control flow through this
> version of the driver? I see that it spawns off a second copy of gnuplot,
> and I am suspicious that some of the problems I will describe below are due
> to glitches in the inter-process communication.
>
> Comments from testing patch version of 15-Feb-2009:
> Built against libqt4-devel-4.4.3-1mdv2009.0
>
> - There is a curious error that causes the top border of the plot to be
> drawn, even if it is disabled. See, for example, running_avg.dem. There
> should be no right- or top- border on the plot. This plots also triggers
> that "wrong polygon size" warning, so maybe it is a clue.
>
> - Multiplots are ridiculously slow. Try for example "key.dem". Each
> sample in the demo takes 5-10 seconds to draw. In some multiplot demos the
> first plot in the figure comes up reasonably quickly, but then there is a
> very long delay before the rest of the plots appear.
>
> - The edges of the individual parallelograms that represent the pixels in
> "image" plots do not meet up perfectly, leading to a visible grid on the
> plot. We've seen this before in other terminal types, and had to work
> around quirks in the corresponding support libraries. The effect is
> particularly visible in pm3d.dem. Is this what you meant by saying that
> "polygon clipping is wrong"? The last time I fought with this, it turned
> out that in order for the graphics library to not leave a blank line of
> pixels along the boundary, it was necessary to both stroke and fill the
> same polygon. I have no idea if that analysis is relevant to the Qt
> drawing primitives.
>
> - In image2.dem, the plot showing decimation of binary data produces a
> garbled image. The plot command in question is
> plot 'blutux.rgb' binary array=(128,128) flipy format='%uchar' \
> every 1:1:43:15:83:65 with rgbimage
>
> - What I am now seeing if I attempt 3D mousing is that the first 1 or 2
> incremental moves are shown, but then the plot freezes. I.e. the view
> settings are updated internally but the plot is not redrawn. Manual replot
> does update to the current view setting.
>
> - If I try to switch between the wxt and qt terminals in the same gnuplot
> session, it either segfaults or locks up hard and has to be killed
> externally from the command line. Is this a known limitation, that the
> terminals are mutually exclusive? That's probably OK, since I would think
> users would choose only one of the two, but it means we need to forcibly
> exclude selecton of the combination. [at build time? at run time?]
>
> - Hitting control-C sometimes leaves the program in a peculiar state.
> Characters may or may not be echoed as you type them, and subsequent plot
> commands generate the error:
> QCoreApplication::exec: The event loop is already running
> After this the dead qt plot window consumes 100% of the CPU and must be
> killed externally.
>
>
> - The embedding example is neat, but I don't understand exactly how it
> should behave so I can't comment on whether it is living up to
> expectations. It doesn't seem to be mouseable; is this a bug?
>
> - Because I have KDE set so that applications inherit the desktop color
> scheme, the background of the gnuplot window is not white. What is the
> recommended way to force a background color for a specific Qt app? If
> there is not a standard way, then I think the gnuplot terminal itself needs
> a way to specify the background color.
>
> - Not sure what you mean by problems with Symbol->UTF8 conversion. Do you
> mean that iconv doesn't handle the Adobe-specific encoding used by the
> Adobe Symbol font? I wouldn't consider that a bug. Using UTF8 for symbols
> is working fine.
>
>
> ----------------------------------------------------------------------
>
> Comment By: Jérôme Lodewyck (lodewyck)
> Date: 2009-02-15 14:35
>
> Message:
> Here is a new patch. It fixed all reported bugs, except 3D mousing for
> which I really don't know what I am doing wrong...
>
> New:
> - Much faster
> - Antialiasing / Oversampling / Hinting
> - No more thread => should work with OS X
> - Persist behavior
> - Export to various formats (clipboard, printer, PDF, bitmaps)
> - Support for embedding plots in Qt applications. See embed_example.
>
> Known issues:
> - the size term option not working
> - polygon clipping is wrong (edges are positioned at +/- 1 pixel)
> - problems with Symbol -> utf8 conversion
> - some demo give a "Wrong polygon size" error, which should not happen
> - mousing in 3D does not work
> - export to EPS not working
> - image clipping not implemented
> - implement mousing for non active plots
>
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-02-15 05:01
>
> Message:
> Found a bug. If the program exits immediately after drawing a plot, then
> the process segfaults from somewhere in the Qt libraries:
>
> qt.bug:
> N = 0
> plot sin(x)
> pause N
> exit
>
> ./gnuplot qt.bug
>
> segfaults for N=0, exits cleanly for N > 0.
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-02-09 06:50
>
> Message:
> On, and one more minor observation. The vertical alignment in enhanced
> text mode seems set to the top of the character cell rather than the
> baseline. Have a look at "enhanced_utf8.dem" and note how the large B and
> the large integral sign extend down rather than up.
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-02-09 06:40
>
> Message:
> OK. It builds fine after an upgrade to Qt4.4.3
>
> Some comments:
>
> As Petr noted, mousing is broken in 3D. It appears to be tracking the
> mouse properly, and updating the view matrix, but it doesn't issue a
> replot/refresh command as it goes so you don't see anything unless/until
> you hit the refresh manually. Could this be a one-line fix somewhere?
>
> Mousing is only partially working in 2D. The tracking and zoom/unzoom is
> OK, but it doesn't seem to return mouse events on request. E.g. the
> "mousevariables.dem" demo fails, and neither "pause mouse" nor "pause mouse
> key" ever returns.
>
> One very noticeable thing that is that it doesn't offer the
> anti-aliasing/oversampling of the wxt terminal, so the lines and edges are
> not nearly as smooth. Is this something that could be added?
>
> But yes, it seems very promising.
>
> ----------------------------------------------------------------------
>
> Comment By: Nobody/Anonymous (nobody)
> Date: 2009-02-07 09:47
>
> Message:
> These are indeed Qt 4.4 functions.
>
> clear() should be replaced by
> foreach (QGraphicsItem* item, items())
> removeItem(item);
>
> and
> line.setP1(##) by line.setPoints(##, line.p2())
> line.setP2(##) by line.setPoints(line.p1(), ##)
>
> Anyway, the target Qt version will most likely be 4.5 since it will be the
> first LGPL version of Qt.
>
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2009-02-07 04:45
>
> Message:
> I'm having trouble getting this to build properly.
> I get several errors from undefined symbols:
> setP1
> setP2
> which I can get past by commenting out the corresponding source lines.
> But this error is a problem:
>
> qtterminal/QtGnuplotScene.cpp: In member function ‘void
> QtGnuplotScene::resetItems()’:
> qtterminal/QtGnuplotScene.cpp:196: error: ‘clear’ was not declared in
> this scope
>
> If I comment out that one, or cast it to void, then the terminal builds
> but indeed it never clears the canvas. So everything you try to plot
> writes on top of the existing contents. There are about a gazillion
> instances of 'clear' in the qt4 headers, so I have no idea which scope to
> force. Any suggestions?
>
> For what it's worth, I am trying to build against
> libqt4-devel-4.3.4-6mdv2008.1
>
>
>
> ----------------------------------------------------------------------
>
> Comment By: Petr Mikulik (mikulik)
> Date: 2009-02-02 23:46
>
> Message:
> Cool! It seems only mousing in "splot" does not work.
>
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=302055&aid=2558043&group_id=2055
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Gnuplot-developers mailing list
> Gnuplot-developers@...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-developers
>
|