qwt-interest — Qwt Q&A

(no subject)

[Ernst K. <ern...@iw...>]

Hi,

I have a question with regard to Qwt: I have subclassed myPlot from
QwtPlot and I want to add some additional objects like text or logos.
How can I do this? I tried to put it into the QPaintEvent, but this
routine is called _before_ the Qwt DrawCanvas etc. Where can I add some
code to do additional drawing AFTER Qwt has finished its painting?

Ernst

Re: QPainter Warning with graphs

[Uwe R. <Uwe...@ep...>]

On Wednesday 08 October 2003 18:05, Lynelle B. Nundoo wrote:

> I'm currently using QWT with QT 3.2.1 on a unix system.
> Everytime I create  a graph (at the point of instantiation), I get a
> warning ::
> QPainter::killPStack : non-empty save/restore stack when end() was
> called.
> Since I'm not overwriting any of the actual paintEvents etc, I'm not
> sure where to start looking.
>
> Any suggestions would be most welcome!

Try to set a breakpoint in qWarning and look at the stack. With gdb this wo=
uld=20
be: =B4b main=B4 + =B4run=B4 + =B4b qWarning=B4 + =B4cont=B4 +=B4where=B4.

Now you should see which QPainter::end is responsible for this warning. Ple=
ase=20
report it together with the info what Qwt release you use.

Uwe

QPainter Warning with graphs

[Lynelle B. N. <lyn...@ca...>]

Hi,
 
I'm currently using QWT with QT 3.2.1 on a unix system.
Everytime I create  a graph (at the point of instantiation), I get a
warning ::
QPainter::killPStack : non-empty save/restore stack when end() was
called.
Since I'm not overwriting any of the actual paintEvents etc, I'm not
sure where to start looking.
 
Any suggestions would be most welcome!
 
Thanks,
Lynelle
 
Lynelle B. Nundoo
Development Engineer
Intervid Technologies
 

Area under a qwtcurve

[DAVID <u10...@co...>]

Hi,

  I draw a qwtcurve and I need to calculate the area above this curve....
I could calculate the function on the curve and do that in a manual form...
there's an alternative solution??

How can do that??

Can anyone help me??

Thanks!!!

(no subject)

[DAVID <u10...@co...>]

Hi,

  I draw a qwtcurve and I need to calculate the area above this curve....
I could calculate the function on the curve and do that in a manual form...
there's an alternative solution??

How can do that??

Can anyone help me??

Thanks!!!

Re: QwtPlot - take mouse event in plotting area

[Gerard V. <gve...@gr...>]

On Thu, 2 Oct 2003 19:41:38 +0200 (CEST)
"DAVID" <u10...@co...> wrote:

> Hi,
>   Im' new in QWT anb I have problems with QwtPlot.
> 
> I need to take an event when the user clicks the mouse in the plotting area.
> I've used the void plotMousePressed (const QMouseEvent &e)
> , but it seems that this event doesn't
> take the event of the plotting area, but the external part of qwtplot object.
> 
> Can anyone help me??
> 
> Thanks!!!
> 
Are you really sure that you did not make another error?

Please try the Bode example? It should respond to mouse events
in the plot canvas (left click should work but to zoom, you must
click the zoom button, first).

If the Bode example has the same behaviour as your program, please,
tell us:
- Qwt - version
- Qt - version
- operating system

Gerard 

QwtPlot - take mouse event in plotting area

[DAVID <u10...@co...>]

Hi,
  Im' new in QWT anb I have problems with QwtPlot.

I need to take an event when the user clicks the mouse in the plotting area.
I've used the void plotMousePressed (const QMouseEvent &e)
, but it seems that this event doesn't
take the event of the plotting area, but the external part of qwtplot object.

Can anyone help me??

Thanks!!!

Re: Curves Superposition

[Gerard V. <gve...@gr...>]

On Mon, 29 Sep 2003 10:19:59 +0200 (CEST)
Franck DELCROIX <fde...@ya...> wrote:

> Hello,
> 
> I am using qwt-0.4.0 on SGI.
> 
> I would like to plot several thick curves of different 
> colors in a single plotting window, and be able to manage 
> which one appears on top of which one.
> 
> For now, I only get a mix of the curves... 
> 
> Does anybody know ?
> 
> Thanks in advance for your help,
> 
There is no possibility to arrange the z-order of the curves
directly, but later versions of Qwt plot the curves in the order
in which they are created (I use this feature).
I do not remember, if this is supported by Qwt-0.4.1 already.
Unstable releases do, I guess (if qwt_plot_dict.h defines a class
QwtSeqDict sequential plotting is supported). 

Gerard

Curves Superposition

[<fde...@ya...>]

Hello,

I am using qwt-0.4.0 on SGI.

I would like to plot several thick curves of different 
colors in a single plotting window, and be able to manage 
which one appears on top of which one.

For now, I only get a mix of the curves... 

Does anybody know ?

Thanks in advance for your help,

Franck



=====
---------------
Franck DELCROIX  (fde...@ya...) / Private MailBox /
---------------

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

Re: A widget not in qwt?

[Christian C. <cj...@cs...>]

Hi Patrick,

Thanks for the suggestion.

I actually did ask this question to one of the Kivio maintainers.  He 
warned that that part of their source was so convoluted currently that 
he couldn't recommend using it.

Regarding Dia, that's a Gnome app, right?  If so, I think that Gnome 
apps use Gtk, not Qt, as their toolkit.  (Sorry - I forgot to mention 
that I'd like to do this in Qt if possible.)

Regarding ksimus:  Thanks, I'll check that out.  I'd never heard of it 
before.

Best wishes,
Christian

Patrick Kursawe wrote:
> On Fri, Sep 26, 2003 at 10:47:30AM -0400, Christian Convey wrote:
>  
> 
>>I need to let users draw a data flow network:  The plunk boxes down on a
>>canvas, and they can draw arrows from certain nubs on one box to certain
>>nubs on another box.  Visually, it's a lot like a very watered down
>>version of Kivio.  I also need to provide context menus for those boxes
>>and arcs.
> 
> 
> Well, have a look at the Kivio source... or at ksimus. Or dia.
> 
> Just a suggestion,
> 
> Patrick	
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> qwt-interest mailing list
> qwt...@li...
> https://lists.sourceforge.net/lists/listinfo/qwt-interest
> 

-- 
Christian Convey
Sr. Software Engineer,
Computer Science Dept.
Brown University

Re: A widget not in qwt?

[Patrick K. <Pat...@ru...>]

On Fri, Sep 26, 2003 at 10:47:30AM -0400, Christian Convey wrote:
 
> I need to let users draw a data flow network:  The plunk boxes down on a
> canvas, and they can draw arrows from certain nubs on one box to certain
> nubs on another box.  Visually, it's a lot like a very watered down
> version of Kivio.  I also need to provide context menus for those boxes
> and arcs.

Well, have a look at the Kivio source... or at ksimus. Or dia.

Just a suggestion,

Patrick	

A widget not in qwt?

[Christian C. <cj...@cs...>]

Hi guys,

I hope this isn't too off topic.  I'm looking for a widget that kindof 
does/doesn't belong in qwt, and was wondering if you guys new of any 
implementations out there for it.

I need to let users draw a data flow network:  The plunk boxes down on a
canvas, and they can draw arrows from certain nubs on one box to certain
nubs on another box.  Visually, it's a lot like a very watered down
version of Kivio.  I also need to provide context menus for those boxes
and arcs.


Any suggestions?

Thanks in advance,
Christian

-- 
Christian Convey
Sr. Software Engineer,
Computer Science Dept.
Brown University

Re: A simple locking scheme

[Uwe R. <Uwe...@ep...>]

On Thursday 25 September 2003 21:16, Sigmund Gudvangen wrote:

> > Hope the example demonstrates why we need a solution how all type of da=
ta
> > can be embedded into Qwt, but we won=B4t l find one design for an unive=
rsal
> > data class, without introducing copying.
>
> Copying, however, is bad news for those that want to display several dence
> curves. Especially if the data is frequently updated, such as a few times
> per sec.

Ah yes, a misleading statement. In fact I meant Qwt should offer two option=
s:

1) The application uses one of the readymade Qwt data containers, accepting=
 a=20
waste of memory (if there is one) and maybe performance (depends).

2) The application embedds its data into a self written container that adds=
=20
the interface that is needed for Qwt.

Uwe

Re: A simple locking scheme

[Sigmund G. <si...@gu...>]

Le Jeudi 25 Septembre 2003 20:17, Uwe Rathmann =E9crivit :

> The current QwtCurve design requires 3 x- +3 y-arrays, while 2 y-arrays
> would be enough.=20

If a single x-array, common to all curves, was used that would constitute a=
n=20
improvement worth having. Retaining the (single) x-array can be useful, if=
=20
one for some reaason wants to wary the resolution along the x-axis. One=20
example that springs to mind is plotting of simulation results with sharp=20
resonance peaks.=20
>
> Hope the example demonstrates why we need a solution how all type of data
> can be embedded into Qwt, but we won=B4t l find one design for an univers=
al
> data class, without introducing copying.

Yes, flexibility is probably more important than a lean interface?
Providing several options, as is currently done with setCurveData() and=20
setCurveRawData() is, in my opinion, quite a good option.=20
Copying, however, is bad news for those that want to display several dence=
=20
curves. Especially if the data is frequently updated, such as a few times p=
er=20
sec.=20

QwtPlot is already a very useful tool, though.=20

Regards
Sigmund.

=20

Re: A simple locking scheme

[Sigmund G. <si...@gu...>]

Le Jeudi 25 Septembre 2003 18:16, Uwe Rathmann =E9crivit :
> On Thursday 25 September 2003 16:35, Sigmund Gudvangen wrote:
> > > Also we need to distinguish between read and write locks.
> >
> > Do you mean that you want to allow data to be read while the array is
> > beeing written?
>
> No, but more than one reader.
>
> A reader has to be blocked if there is a writer, but a writer has to be
> blocked if there is a reader or a writer. So it is important to have
> different locks indicating, if it is locked by a writer or by how many
> readers.

D'accord.

Sigmund.

Re: A simple locking scheme

[Uwe R. <Uwe...@ep...>]

On Thursday 25 September 2003 16:35, Sigmund Gudvangen wrote:

> > Also we need to distinguish between read and write locks.
>
> Do you mean that you want to allow data to be read while the array is
> beeing written?

No, but more than one reader. 

A reader has to be blocked if there is a writer, but a writer has to be 
blocked if there is a reader or a writer. So it is important to have 
different locks indicating, if it is locked by a writer or by how many 
readers.

Uwe

Re: A simple locking scheme

[Sigmund G. <si...@gu...>]

Le Jeudi 25 Septembre 2003 16:08, Uwe Rathmann =E9crivit :
>
> Also we need to distinguish between read and write locks.=20

Do you mean that you want to allow data to be read while the array is beein=
g=20
written?=20

Sigmund.=20

Re: A simple locking scheme

[Uwe R. <Uwe...@ep...>]

On Thursday 25 September 2003 13:47, Sigmund Gudvangen wrote:

> Having had time to ponder for a while, I agree with Micha that Loki
> probably isn't an appropriate tool for implementing locking in the prsent
> context.=20

The main intention of introducing a QwtPlotData class is to make QwtCurve=20
independent from the way data is organized. This prevents the application=20
from useless copies. Don=B4t know, but maybe a classname like QwtCurveDataI=
f=20
would be a better name.

I bet most of the designs for data classes are driven by the reality of=20
existing API=B4s, whatever nice design patterns in books might tell. IMHO=20
together with QMutex, QShared and friends a wrapper class for any type of=20
data, providing the QwtPlotData API requirements, could be written in a=20
couple of lines.

Of course Qwt will have to offer one or more default data classes too, wher=
e=20
something based on double * arrays is the most important one, just because=
=20
this is the most compatible API.

> If one accept that the application programmer should bear some of
> the responsibility for managing locking, then the following scheme can be
> employed: [...]

IMO QwtCurve and below is a better place to control locks. Otherwise QwtPlo=
t=20
has to know of all critical operations what is not true for derived curve=20
classes and for the Qwt 0.5 design plans at all.

Also we need to distinguish between read and write locks. Also a flag for=20
activating whether to use locking or not would be useful.

Uwe

Re: A simple locking scheme

[Gerard V. <gve...@gr...>]

Hi,

Another (current) idea is to have a virtual class that represents data
with two virtual functions, lock() and unlock() that by default are
no-ops.

If a programmer wants to use multi-threading, he could derive
a new class and redefine lock() and unlock() using a QMutex.

To make Qwt support multithreading it is probably sufficient to call
data.lock() on entrance of QwtCurve::draw() and data.unlock() on exit.

If the design of the virtual data class is flexible enough it should be possible
for the programmer to add a method that does data acquisition in a member
function of his derived class.

Regards -- Gerard

On Thu, 25 Sep 2003 13:47:49 +0200
Sigmund Gudvangen <si...@gu...> wrote:

> 
> Hi again,
> 
> Having had time to ponder for a while, I agree with Micha that Loki probably 
> isn't an appropriate tool for implementing locking in the prsent context. If 
> one accept that the application programmer should bear some of the 
> responsibility for managing locking, then the following scheme can be 
> employed:
> 
> Define two virtual functions in QwtPlot
> 
> protected:
>     virtual void lock( long curveKey ) {}
>     virtual void unlock( long curveKey ) {}
> 
> which are then called in QwtPlot::drawCanvas(), thus:
> 
>     //  draw curves
>     //
>     QIntDictIterator<QwtPlotCurve> itc(*d_curves);
>     for (QwtPlotCurve *curve = itc.toFirst(); curve != 0; curve = ++itc )
>     {
>         if ( curve->enabled() &&
>            axisEnabled( curve->xAxis() ) &&
>            axisEnabled( curve->yAxis() ) )
>         {
>             lock( itc.currentKey() );      // <-----------------------------
> 
> 	    curve->draw(p, map[curve->xAxis()], map[curve->yAxis()]);
> 
> 	    unlock( itc.currentKey() );    // <-----------------------------
>         }
>     }
> 
> In order to keep the application as responsive as possible, the arrays are 
> locked one by one, only while they are beeing redrawn.
> 
> In the derived calss
> 
> class MyQwtPlot : QwtPlot
> 
> reimplement the two functions:
> 
> void lock( long curveKey );
> void unlock( long curveKey );
> 
> something like this:
> 
> //================================== 
> void MyQwtPlot::lock( long curveKey )
> {
>     for ( int i=1; i<= m_pCurves->count(); i++ )
>     {
>         if ( i == curveKey )
>         {
>             m_pCurves->lock( curveKey );
>             break;
>         }
>     }
> }
> 
> //=================================== 
> void MyQwtPlot::unlock( long curveKey )
> {
>     for ( int i=1; i<= m_pCurves->count(); i++ )
>     {
>         if ( i == curveKey )
>         {
>             m_pCurves->unlock( curveKey );
>             break;
>         }
>     }
> }
> 
> It is now up to the application designer to call whatever locking mechanishm 
> he wants to use, as hinted by
> 
> m_pCurves->lock( curveKey );
> m_pCurves->unlock( curveKey );
> 
> Another way would be to emit signals from QwtPlot::drawCanvas(), with the 
> curveKey embedded. Or perhaps booth? That way the application writer would 
> have a choice.
> 
> While the scheme outlined above is somewhat low level, it is flexible enough 
> to allow it to be used with almost any locking mechanism. It might perhaps do 
> in the interime, until a more sophisticated scheme is deviced. Anyway, let me 
> have your oppinions.
> 
> Regards
> Sigmund.
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> qwt-interest mailing list
> qwt...@li...
> https://lists.sourceforge.net/lists/listinfo/qwt-interest
> 

A simple locking scheme

[Sigmund G. <si...@gu...>]

Hi again,

Having had time to ponder for a while, I agree with Micha that Loki probably 
isn't an appropriate tool for implementing locking in the prsent context. If 
one accept that the application programmer should bear some of the 
responsibility for managing locking, then the following scheme can be 
employed:

Define two virtual functions in QwtPlot

protected:
    virtual void lock( long curveKey ) {}
    virtual void unlock( long curveKey ) {}

which are then called in QwtPlot::drawCanvas(), thus:

    //  draw curves
    //
    QIntDictIterator<QwtPlotCurve> itc(*d_curves);
    for (QwtPlotCurve *curve = itc.toFirst(); curve != 0; curve = ++itc )
    {
        if ( curve->enabled() &&
           axisEnabled( curve->xAxis() ) &&
           axisEnabled( curve->yAxis() ) )
        {
            lock( itc.currentKey() );      // <-----------------------------

	    curve->draw(p, map[curve->xAxis()], map[curve->yAxis()]);

	    unlock( itc.currentKey() );    // <-----------------------------
        }
    }

In order to keep the application as responsive as possible, the arrays are 
locked one by one, only while they are beeing redrawn.

In the derived calss

class MyQwtPlot : QwtPlot

reimplement the two functions:

void lock( long curveKey );
void unlock( long curveKey );

something like this:

//================================== 
void MyQwtPlot::lock( long curveKey )
{
    for ( int i=1; i<= m_pCurves->count(); i++ )
    {
        if ( i == curveKey )
        {
            m_pCurves->lock( curveKey );
            break;
        }
    }
}

//=================================== 
void MyQwtPlot::unlock( long curveKey )
{
    for ( int i=1; i<= m_pCurves->count(); i++ )
    {
        if ( i == curveKey )
        {
            m_pCurves->unlock( curveKey );
            break;
        }
    }
}

It is now up to the application designer to call whatever locking mechanishm 
he wants to use, as hinted by

m_pCurves->lock( curveKey );
m_pCurves->unlock( curveKey );

Another way would be to emit signals from QwtPlot::drawCanvas(), with the 
curveKey embedded. Or perhaps booth? That way the application writer would 
have a choice.

While the scheme outlined above is somewhat low level, it is flexible enough 
to allow it to be used with almost any locking mechanism. It might perhaps do 
in the interime, until a more sophisticated scheme is deviced. Anyway, let me 
have your oppinions.

Regards
Sigmund.

New release: QwtPlot3D 0.2.0 beta

[Micha B. <kri...@us...>]

A new version of QwtPlot3D is out:

New features:

    * Vector output (PS, EPS, PDF, TeX)
    * Shading
    * Color legends

Look at http://qwtplot3d.sourceforge.net/  for details.


Micha
--

Re: loki

[<gve...@gr...>]

> Hallo group,
> 
> I like template programming and Andrej's book is an inexhaustible and
> enlightening source of inspiration.
> The other side:
> Loki is a bleading edge library. Also the most current versions
> compile not very well with all compilers. I would be very careful to
> include merely parts of Loki in qwt. This will perhaps shift the
> design paradigms of qwt sooner or later too (not to bad per se).
> 
> For Gerard and all the people perhaps interested in an article from Andrej,
> showing that it is sometimes very difficult to express also the
> first things with templates.
> 
> http://www.cuj.com/documents/s=7996/cujcexp1904alexandr/alexandr.htm
> 
> This only to illustrate my general caution in using these kind of code
> - you can do much more errors in implementing e.g. smart pointers than
> with min and max. Only to catch with heavy testing and hard to track.
> I give some points here to the STL and a few boost libraries, but not
> yet loki.
> Just my experience with this stuff (Still to repeat: I like this
> programming style and his powerfulness - but in other places)
> 
Don't worry Micha, I had also come to the conclusion that Loki is
too ambitious for quite a few compilers supported by Qt. Secondly, (IMO)
templates do not fit well in the current Qwt design and/or code base
(I am not a very experienced C++ programmer, though -- my hard disk
contains bleeding edge template programs that are too much for my lousy
gcc-2.96 and me).

On the other hand QwtPlotData must be flexible enough that it
will be easy to derive a QwtPlotLokiSmartPointerData class if
somebody feels like putting his head under the guillotine.

Finally, Uwe and I agree that Qwt should allow data locking for
multi-threaded programs, if a client wishes to implement it.

Thanks -- Gerard



-------------------------------------------------------------
This message was sent using HTTPS service from CNRS Grenoble.
         --->   https://grenoble.cnrs.fr   <---         

loki

[Micha B. <kri...@us...>]

Hallo group,

I like template programming and Andrej's book is an inexhaustible and
enlightening source of inspiration.
The other side:
Loki is a bleading edge library. Also the most current versions
compile not very well with all compilers. I would be very careful to
include merely parts of Loki in qwt. This will perhaps shift the
design paradigms of qwt sooner or later too (not to bad per se).

For Gerard and all the people perhaps interested in an article from Andrej,
showing that it is sometimes very difficult to express also the
first things with templates.

http://www.cuj.com/documents/s=7996/cujcexp1904alexandr/alexandr.htm

This only to illustrate my general caution in using these kind of code
- you can do much more errors in implementing e.g. smart pointers than
with min and max. Only to catch with heavy testing and hard to track.
I give some points here to the STL and a few boost libraries, but not
yet loki.
Just my experience with this stuff (Still to repeat: I like this
programming style and his powerfulness - but in other places)


Micha
--

Re: Locking access

[Sigmund G. <si...@gu...>]

Le Dimanche 21 Septembre 2003 14:50, Gerard Vermeulen =E9crivit :
> On Sun, 21 Sep 2003 13:10:32 +0200

> Yes, there seems to be nothing in the archives.
>
> -- quoting from a mail from Uwe --
> Another idea (guess a very good one) is to have an abstract base class for
> data instead. With such a class, applications are free to decide how to
> store the data without having to deal with curves.
>
> Maybe:
>
> class QwtPlotData:
> {
>  	virtual uint count() const =3D 0;
> 	virtual double x(i) const =3D 0;
> 	virtual double y(i) const =3D 0;
>
> 	...
> };
>
> I guess the class above is too simple and there are performance issues to
> consider.
> -- end quote --

Yes, something along those lines, but with smart pointers substituted for t=
he=20
bare pointers. Alexandrescu's SmartPtr from the Loki template lib. might be=
 a=20
good candidate. It would also take care of reference counting.=20
>
> It took me some time to convince myself that Uwe's idea is best.
>
> For efficiency reasons, I am toying with the idea that functionality
> involving addressing all elements of QwtPlotDataWhatEver object (finding
> minimum and maximum values -- filling the x or y values of the QPointArray
> used by QwtCurve to draw the data -- ...) could be delegated to
> QwtPlotData(WhatEver) for efficiency reasons.

Something like providing a size() method perhaps? If the source data struct=
ure=20
stores the number of elements anyway, almost no overhead would incur. But I=
=20
think it ought to be possible to tell QwtPlot to only plot part of an array=
,=20
for efficiency reasons.=20
>
> I speculate that decisions of what action to take if the data is locked
> could be handled by this functionality (returning old cached data?).
>
I think that caching data will usually be too expensive, as it will involve=
=20
copying of (sometimes) big arrays. It is true that some form of buffering=20
will often be called anyway, e.g. when the data is being acquired slowly fr=
om=20
e.g. a serial port. But I think that the responsibility of providing the=20
necessary buffering should lie with the data source, as it will often need =
to=20
buffer the incoming stream anyway. Moreover, if two buffers are used (while=
=20
one is being processed/plotted, the other is being filled up), no copying i=
s=20
required; it suffices to swap the pointers to them.=20

The above scenario will usually involve at least two threads, so some form =
of=20
locking is mandatory. The locking is best handled by the smart pointers and=
=20
is already incorporated into e.g. Loki's SmartPtr.=20

If the date is locked, it is presumably locked for a good reason, so the=20
appropriate action to take is to wait. If the user e.g. zooms out, so that=
=20
QwtPlot needs to fetch more data and the data source is locked that does of=
=20
cause freeze the update. However, I think that if that situation arises it=
=20
does so because the application designer made a mess of his thread=20
management. If the necessary elasticity is provided, in the form of bufferi=
ng=20
as discussed above, the data source should only need to lock the data array=
s=20
very briefly while swapping pointers. Likewise, QwtPlot should only lock th=
e=20
data arrays, one by one, as and when it needs to read data. Which will=20
usually be when the user zooms, resizes the window, etc. Delegating the=20
locking to smart pointers will automatically take care of locking the data=
=20
structure only when it is strictly required.

Smart pointers will also take care of reference counting, which should=20
therefore help prevent the rather awkward situation that the data source, f=
or=20
some reason or another, is deleted while QwtPlot still has a pointer to it.=
=20


Regards
Sigmund.

Re: Locking access

[Gerard V. <gve...@gr...>]

On Sun, 21 Sep 2003 13:10:32 +0200
Sigmund Gudvangen <si...@gu...> wrote:

> Le Dimanche 21 Septembre 2003 11:14, Gerard Vermeulen =E9crivit :
> > On Sun, 21 Sep 2003 10:42:35 +0200
> >
> > Sigmund Gudvangen <si...@gu...> wrote:
> > > Hi,
> > >
> > > In would be useful, notably in a multi-treading application, to be ab=
le
> > > to lock the array given to QwtPlot::setCurveRawData(...). Automatic
> > > locking could be implemented with e.g. smart pointers/locking proxy.
> > > Perhaps it would it be a good idea to provide such access, in additio=
n to
> > > the QwtCurve::setRawData() and QwtCurve::setCurveData()?
> > >
> > > Regards
> > > Sigmund.
> >
> > Hi,
> >
> > Uwe has proposed me to design a virtual QwtPlotData class with the idea
> > that QwtPlot can plot any type of array/vector-like class (and raw C
> > pointers and pointers to Numerical Python data structures).
> >
> > Your smart pointer/locking proxy could fit in such a scheme.
> >
> > I have to admit that I am more of a Python programmer than a C++
> > programmer: can you outline how you would implement such a proxy? or gi=
ve a
> > pointer to code accessible on line?
> >
> > Regards -- Gerard
>=20
> I am not sure what the best approach might be, as it would have to be a r=
ather=20
> generic scheme. That's why I first wanted to air the idea here. Is Uwe's=
=20
> proposal available in the qwt-interest archive? I tried to search for=20
> QwtPlotData, but didn't get any hits.
>=20
> Here are some links to smart ptr sites:
> http://www.cuj.com/documents/s=3D7980/cujcexp2008sutter/
> http://www.cuj.com/documents/s=3D8890/cujexp0310alexandr/
> http://www.boost.org/libs/smart_ptr/smart_ptr.htm
> http://ootips.org/yonat/4dev/smart-pointers.html
>=20
> One of the most lucid descriptions of smart pointers I am aware of can be=
=20
> found in Capter 7 of Modern C++ design, by Andrei Alexandrescu:
> http://www.amazon.com/exec/obidos/ASIN/0201704315/ref%3Dpd_bxgy_text_1/10=
4-8535017-7905561
> http://www.awl.com/cseng/titles/0-201-70431-5
> The latter site also has a link to the accompanying source code, the Loki=
=20
> libray.=20
>=20
Thanks for the pointers. The book looks like a 'must-have'.

Yes, there seems to be nothing in the archives.

-- quoting from a mail from Uwe --
Another idea (guess a very good one) is to have an abstract base class for=
=20
data instead. With such a class, applications are free to decide how to sto=
re=20
the data without having to deal with curves.

Maybe:

class QwtPlotData:
{
 	virtual uint count() const =3D 0;
	virtual double x(i) const =3D 0;
	virtual double y(i) const =3D 0;
=20
	...
};

I guess the class above is too simple and there are performance issues to=20
consider.=20
-- end quote --

It took me some time to convince myself that Uwe's idea is best.

For efficiency reasons, I am toying with the idea that functionality involv=
ing
addressing all elements of QwtPlotDataWhatEver object (finding minimum and
maximum values -- filling the x or y values of the QPointArray used by QwtC=
urve
to draw the data -- ...) could be delegated to QwtPlotData(WhatEver) for
efficiency reasons.

I speculate that decisions of what action to take if the data is locked cou=
ld
be handled by this functionality (returning old cached data?).

Regards -- Gerard