Re: Qwt2

[Pieter v. B. <va...@ko...>]

On Friday 04 May 2001 15:22, Uwe Rathmann wrote:
> On Thursday 03 May 2001 13:37, Pieter van Beek wrote:
> > I just made a start, by programming a new QwtDataSource class, an
> > abstract interface class for all data that needs to be plotted. I think a
> > few functionalities need to be there from the start: incremental
> > plotting, multi-threading support etc. are some of them.
>
> Hi Pieter,
>
> maybe you can drop some words about the general direction of your design ?

Hi all,

That's hard, just dropping a few words about the general direction. Let's try 
anyway.

I just checked how many people have currently been subscribed to the 
Qwt-interest mailing list. As it turned out, we are with 36 now. A small 
group, especially when considering the fact that, AFAIK, Qwt is the only 
freely available (and actually useful) 2D plotting widget for Qt.

No doubt, many Qt users have written their own 2D plotting widgets: I know Qt 
is used in academic environments, also in the disciplines of mathematics and 
physics where visualization of relations and (acquired) data is a common 
task. I wish I had all those private little solutions together, here on my 
computer. I bet some nice solutions and interesting approaches and ideas can 
be found there. 

Personally, I think a high quality Qwt-like plotting widget should be 
available for Qt. And I also think that Qwt, in its current form, is _almost_ 
but unfortunately just not the thing we want; Qwt has become a patch ball, 
suffering from severe feature bloat. Also, as the original author/maintainer 
of Qwt, Josef Wilgen, once said: Qwt as a whole, and especially QwtPlot and 
friends, are not _really_ object oriented. Qwt _seems_ to be object oriented 
on a superficial level (it consists of classes, doesn't it?) but it doesn't 
feature any object oriented goodies such as encapsulation, implementation 
hiding, document/viewer model, transactions, etc.

Qwt does use a few nice and common design patterns, but this has never been 
made explicit: the docs don't explicitly mention any design pattern in Qwt. 
In fact, Qwt has no overall design pattern or object oriented philosophy.

> As far as I can see one central idea will be to separate the data from its
> graphical representation. But how will both work together ?
>
> I can see 2 different solutions:
>
> 1) The plot contains a counterpart to each data object ( f.e a QwtCurve )
> that can be connected via signals/slots. The application will manipulate
> the data object only, while the curves will be updated automagically. Going
> this way the data object must provide a lot more information through its
> signals than changed(bool incremental). Consider incremental plotting: in
> this case you have to know which points have to be painted and which have
> been painted before.

Indeed, this is the way to go. But I have planned another layer between the 
actual data, and the plot widget that the user sees: the QwtDataPlotter. This 
class encapsulates all state that does not belong to the plot class on the 
one hand (because it differs for each data source, such as color, or line 
style) and that doesn't belong to the data source class as well (again, such 
as color or line style). So there are three layers:

   QwtPlot      // A paint device, such as a widget or printer
      ^
QwtDataPlotter  // A class that knows how to plot data
      ^
QwtDataSource   // The data itself

This allows a lot of flexibility: one data source can be plugged into many 
different QwtDataPlotters, so it can be plotted on different plots with 
different markers, colors etc etc.

Also, one QwtDataPlotter can be plugged into many different QwtPlots, 
allowing data to be plotted in different viewer windows, with different 
scales. And data can be plotted on screen and on a printer with the same line 
style/color and marker type.

Communication between these classes can be done with signal/slots, or with 
C++-style callback design patterns (model/viewer).

>
> 2) The data-object will be passed to the plot and remains there as a child
> object, or even better the plot offers a virtual method that creates a
> data-object that will be called from QwtPlot::openCurve(). openCurve will
> also create the QwtCurve counterpart. Additional points will be passed to
> the data-object and painted through a plot method.
>
> While solution 1) sounds nice and a lot like Model/View, I guess solution 2
> is easier to implement and also easier to use for the applications. But I
> need to know more about the design to vote substantially.
>
> But anyhow, intelligent data objects that can be manipulated by the
> applications are an excellent idea.

Thank you.

Bye,
Pieter.

-- 
KOBAYASHI SOFTWARE                                  Gouden Leeuw 836
Phone: +31 20 4165015    http://www.kobasoft.nl    1103 KT Amsterdam
Fax:   +31 20 4166731    in...@ko...            The Netherlands
PGP ID: 0xEDD2D7DF  CF 20 EB 70 C4 B0 96 D3  E1 EE E5 34 2D FE 25 03