[Kst] Copy/Paste behavior
staikos at kde.org
Wed Mar 16 20:27:33 CET 2005
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.
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
More information about the Kst