Le Wednesday 01 June 2011, Dawit A a écrit : > 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.
there could also be a static private schedulerPrivate() function in KIO::Scheduler, and the Q_PRIVATE_SLOT uses that function. > > 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
