On Fri, Aug 29, 2014 at 8:26 PM, David Faure <fa...@kde.org> wrote: > On Tuesday 26 August 2014 16:29:23 Harald Sitter wrote: >> alohas, >> >> it would appear to me that a recent change in kio [1] was rather, >> very, entirely source incompatible (one could argue binary but let's >> not go there). >> >> Say I had the following in my application using kio 5.0/1: >> >> connect(copyjob, &CopyJob::aboutToCreate, this, &MyThing::onABoutToCreate); >> >> my application would no longer compile with 5.2 :'( > > Yes. But I wager that there is no such application, because CopyInfo is not > documented in the api docs, so the only way to read what's in there is to open > copyjob.h, and there it was marked as @internal > and with > /// FIXME: If this is internal, why is being used in a public signal below?
I think most IDE's will care very little about fixme comments or doxygen coverage when offering autocomplete options. >> Can we please revert and deprecate instead? > > That wouldn't allow to fix that FIXME, i.e. to make CopyInfo internal for > real. > > This signal was added for kde3's kdesktop, and has been useless ever since. > Its documentation shows why it's mostly useless - the urls in there aren't > even final, in case the user chooses "rename" in a conflict dialog. > > From a pragmatic point of view, I can't see what this could possibly break, > other than language bindings, which is how you found this, I assume? I found it by actually doing ABI checks. And I really think there is nothing pragmatic about breaking ABI when the library is supposed to be ABI stable. For example imagine someone using copyjob and being overly eager and simply connecting all signals to dummy slots, you know, in case they might need them in the future (like people subclass QObject without changes in case they might need to expand their own object derivates) . It most definitely would not be the weirdest thing I have seen library users do. That being said, IMHO it would be perfectly reasonable to deprecate the signal and *perhaps* even make it non fuctional (as in: it's never emitted). At the very least this would prevent SC/BC issues. HS _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
