gnuplot-beta

Re: Qt terminal

[Jérôme L. <jer...@al...>]

Philipp K. Janert a écrit :
> What would make this really, really cool is if it
> could truly leverage Qt's cross-platform capabilities,
> such that it would become easier to build and install
> gnuplot on Win and the Mac. 

I think it should be rather straightforward to port the terminal on any 
platform supported by Qt.

> By the same token, if it does NOT offer this
> cross-platform capability, then I need to understand
> better what this patch does that wxt is not doing
> already. Could you speak to that?

I seems to me that wxt is also aiming at cross-platform capability...

Here are a few arguments in favor of developing this terminal:
- The more terminals, the better. A new terminal adds opportunities but 
doesn't harm, so in any case, it is worth considering.
- As it is using Qt, it looks more at home in Qt based environments, 
such as KDE. It also introduces no memory overhead if Qt libraries are 
already in use.
- I chose a modular design for this terminal, the aim being to be able 
to embed a plotting widget in any Qt application, as the x11 terminal is 
able to embed the plotting area in existing x11 windows.
- The plot rendering is done using the Qt GraphicsScene framework that 
registers each graph element as independent items, which means that 
advanced user interaction (e.g. modifying a label directly on he plot, 
moving a line...) can be envisioned.

Jérôme

Re: Qt terminal

[nabed <ss...@ol...>]

Hi,

I would like to be able to put three Qt Terms (Gnu Plot) widgets on a single
dialog in my Qt application. I would then like to be able to send gnuplot
commands & data steams these QtGnuPlot widgets and also be able to obtain
information on the where the user has panned to or zoomed to. 

Ideally I would want the QT Term to emit signals on pan & zoom events as I'm
wanting to correlate the pan and zooming across the three QtGnuPlot
widgets/terms. Would this be possible with your QtGnuplot widget?  

When/Where would I be able to obtain your widget. 

Serle


Jérôme Lodewyck-5 wrote:
> 
> Le lundi 2 février 2009, Ethan A Merritt a écrit :
>> On Sunday 01 February 2009, Jérôme Lodewyck wrote:
>> > Hi,
>> >
>> > 	I have written a Qt terminal for Gnuplot. My main motivation for doing
>> > this is that Qt is going to be released under the LGPL, and I far as I
>> > understood, this license is compatible with Gnuplot.
>> > 	The terminal is mostly inspired from the wxWidgets terminal (thanks
>> > Timothée for your hard work !). It is not yet optimized and there are
>> > still some glitches here and there, but it is mostly feature complete.
>> > 	If it is of interest for someone, I will be happy to propose a patch.
>>
>> Sure, go ahead and post a patch.
>> It is hard to tell much about how it works by looking only at
>> screenshots.
> 
> Ok, the patch is submitted
> 
>> Please describe more precisely what libraries or environment thie new
>> terminal would require.
>> Does it use the KDE libraries, or just Qt?
>> If one built gnuplot with only the driver, would it be run on, say,
>> the OpenMoko mobile phone platform?
>> What about non-linux Qt platforms?
> 
> It uses Qt 4 libraries. It was developed on Linux with Qt 4.4.3, but in my 
> experience, Qt applications usually work out of the box on any platform 
> supported by Qt (X11, windows, MacOS X, framebuffer linux, windows CE).
> Only 
> one pat of the terminal makes use of non-Qt functions: the Qt main loop is 
> implemented inside a pthread, which is a problem because
> 1/ It doesn't work on non-UNIX platforms, but from what I understood from
> the 
> wx terminal, Windows support would only imply putting #ifdef's around the 
> pthread functions
> 2/ Qt does not officially support running the main event loop inside a
> thread; 
> however, I did not experience any problem with this (except that Qt
> functions 
> should be used with care in the gnuplot thread)
> 
> Jérôme
> 
>> 	Ethan
>>
>> > Screenshots:
>> >
>> > http://lodewyck.free.fr/gp1.png
>> > http://lodewyck.free.fr/gp2.png
>> > http://lodewyck.free.fr/gp3.png
>> >
>> > Regards,
>> >
>> > Jérôme
>> >
>> >
>> -------------------------------------------------------------------------
>> >----- This SF.net email is sponsored by:
>> > SourcForge Community
>> > SourceForge wants to tell your story.
>> > http://p.sf.net/sfu/sf-spreadtheword
>> > _______________________________________________
>> > gnuplot-beta mailing list
>> > gnu...@li...
>> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

-- 
View this message in context: http://www.nabble.com/Qt-terminal-tp21784702p22493878.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: [Gnuplot-developers] [ gnuplot-Patches-2558043 ] Qt terminal

[Ethan M. <merritt@u.washington.edu>]

> >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@u.washington.edu>
>         * 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
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-developers
>