Lifted method access modes in KURLDrag and KMultipleDrag

[David Faure]

On Saturday 06 August 2005 18:22, Rafał Rzepecki wrote:
> Is there any good reason why KURLDrag::format() and KURLDrag::encodedData() 
> are protected? These methods are public in the ancestors.

Hmm I can't think of a reason for that, probably just an oversight on my part.

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

> Another thing about KURLDrag is that it lacks setURL() method. QTextDrag, 
> QUriDrag and QImageDrag all have set*() methods. But one can't use QUriDrag's 
> method to set the uris, as it bypasses KURLDrag's internals and breaks 
> things. There should be a method to set the URLs, and the QUriDrag's method 
> should be overrided not to bypass KURLDrag's internals, or at least set 
> private to prevent abuse.

Indeed. (well we can hide it by simply naming it KURLDrag::setUris( const KURL::List& uris ),
this will automatically hide the one from QUriDrag ("overloaded virtual" C++ feature).
Ah, there's setFileNames and setUnicodeUris too, though. Isn't it a bit dirty
to make those private in a subclass even though they're not virtual? Well
it's the best we can do I guess.... Anyhow with KDE 4 this problem might go away
(if I finish making KURL use QUrl).

> I can correct these problems, but I don't have SVN kdelibs installed and have 
> a slow machine, so it would take ages to compile here, so I'd rather have 
> someone else fix it or at least help me test the patches I provide, so that 
> I need not compile the whole kdelibs.

Ah, hmm, OK. I did the method access change, I'll be happy to commit your
setURLs or setUris patch once it exists ;)

> I'm not sure whether these fixed would break the ABI, so as to fix it in 
> 3.5 or rather the trunk.

Changing protected to public is binary compatible (except on windows with MSVC).

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).