[Kst] Copy/Paste behavior

[George Staikos]

On Wednesday 16 March 2005 12:36, Barth Netterfield wrote:
> On March 16, 2005 12:11 pm, George Staikos wrote:
> > > The back-buffer idea is a good one, and I don't see why it couldn't
> > > be made to work.
> >
> >    We don't need to implement anything new at all.  We already have the
> > necessary code for this in the graphics export code.  Hooking it into the
> > drag object won't result in any delay except at drop time.
>
> There are two reasons I like using the back buffer rather than the graphics
> export code:
> 	-It gives a clean rule about how large the plot should be - as big as it
> is. -The delay will always be short, independent of how many points are in
> the vector, etc.

  Here's how to do it without delay and get all the functionality we need:

KMultipleDrag allows combining of drag objects.  We have KstPlotDrag and 
KstPlotImageDrag (QStoredDrag probably).  KMultipleDrag gets both, and puts 
KstPlotDrag first (important).

KstPlotImageDrag provides several image formats that we predefine.  Perhaps 
PNG, JPG, GIF, EPS, assuming that KImageIO supports them.  The one we want to 
be the most common choice goes first now (important).  Instead of putting any 
data into the drag object, we leave it empty.  We inherit from 
virtual QByteArray encodedData(const char *mimeType) const

If the mimetype is one that we know ("image/png", etc), we decode for that, 
otherwise we return QStoredDrag::encodedData(mimeType);

encodedData() only gets called after a drop happens, so no rendering will 
occur unless it's triggered by the target.  We can provide a progress dialog 
in encodedData() too.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/