Lifted method access modes in KURLDrag and KMultipleDrag
faure at kde.org
Tue Aug 16 19:55:40 BST 2005
On Thursday 11 August 2005 01:44, Rafał Rzepecki wrote:
> On Wednesday, 10 of August 2005 03:03, David Faure wrote:
> > On Saturday 06 August 2005 18:22, Rafał Rzepecki wrote:
> > > Currently I have worked around the problem by just casting the KURLDrag
> > > onto an ancestor and then calling the method (which is public there). But
> > > I feel this should be corrected. KMultipleDrag also has this problem.
> > Yep, I'm guilty for both ;)
> > (OTOH I can't think of a reason why someone would want to call
> > format or encodedData directly, those are being called by the receiver
> > side, which doesn't know which QDragObject subclass is being used...)
> Imagine implementing a custom QDragObject, which should provide URIs beside
> whatever other formats.
The best way to do that is to use KMultipleDrag.
(btw in Qt4 with QMimeData the problem disappears completely, so we're only talking
about Qt3 here)
> One way of doing this is subclassing KURLDrag, but
> this is sometimes not desirable. Another way would be to have a private
> KURLDrag object member, and delegate them calls whenever appropriate. For
> char *MyDrag::format( int i ) const
> if ( i == 0 ) return "application/x-foo";
> if ( iHaveAnotherFormat() && i == 1 ) return "application/x-bar";
> i -= 1 + ( iHaveAnotherFormat() ? 1 : 0 );
> return mUrlDrag->format( i );
> Because KURLDrag::format() was protected, you had to have mUrlDrag as a
> QDragObject*/QStoredDrag* or QUriDrag*.
I see. But I don't like this solution, since it's exactly the problem that
KMultipleDrag solves for you.
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kde-core-devel