Accidentally exported private classes

[David Faure]

On Monday 10 August 2015 13:23:05 Volker Krause wrote:
> Yep, and there are more reasons for not using nested classes for this and 
> following the Qt scheme instead, such as the Q_D/Q_Q macros for example.

Right.
 
> For existing code it is however a quite substantial (although not particularly 
> hard) change, I'm not sure if this is worth the effort, compared to the 
> Q_DECL_HIDDEN approach.

Could be scripted, it's all just search-replace, basically.

> > > I've started doing this in PIM code that
> > > isn't covered by BC guarantees yet. Do we also want this to be done in
> > > already released frameworks, although it is technically BIC?
> > 
> > Classes called "*Private" are not part of our BIC promises.
> 
> Ok, then I'll fix this in KF5 as well. Do you want individual review requests 
> for these changes or can I just push those directly?

Trivial pre-approved changes don't need review requests.

But I volunteer to do it right, instead. Such scripts are quick to write....
... here you go (also committed to kde-dev-scripts).

Sample diff attached, it compiles.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rename-private.pl
Type: application/x-perl
Size: 1240 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150810/0636a8b3/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kconfigbackend.diff
Type: text/x-patch
Size: 1595 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150810/0636a8b3/attachment-0001.bin>