Isn't this problem easily solvable by changing those slots defined in Q_PRIVATE_SLOT to actual private slots of KIO::Scheduler and forwarding the call to the existing code ? See attached patch.
On Wed, Jun 1, 2011 at 10:47 AM, Jeremy Whiting <[email protected]> wrote: > Until those that know the code get this issue sorted out, I've pasted a > small workaround that gets it to build here: > http://paste.kde.org/77059/ > > Jeremy > > On Wed, Jun 1, 2011 at 2:39 AM, Thiago Macieira <[email protected]> wrote: >> >> On Wednesday, 1 de June de 2011 01:42:13 argonel wrote: >> > This makes a promise that any class can use a private slot without >> > access checking. It doesn't say how that slot was declared, just that >> > the private slot can be invoked by any other class. The change to >> > Q_PRIVATE_SLOT introduces access checking of slots and breaks the >> > promise, and so it needs to be left unchanged until Qt 5. >> >> You're assuming you're allowed to use Q_PRIVATE_SLOT. That macro is not >> documented, so any use of it outside Qt is suspect by itself. Qt makes >> promise >> of source compatibility when using it. >> >> -- >> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >> Senior Product Manager - Nokia, Qt Development Frameworks >> PGP/GPG: 0x6EF45358; fingerprint: >> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > >
kio_scheduler.patch
Description: Binary data
