Lifted method access modes in KURLDrag and KMultipleDrag

[David Faure]

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 
> example:
> 
> 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).