Review Request 127655: Fix KAboutData::applicationData() to sync to current Q*Application metadata

[Albert Astals Cid]

> On April 29, 2016, 3:15 a.m., Michael Pyne wrote:
> > I think I disagree with the idea of overwriting KAboutData properties if they are already set by the user. Alex, any thoughts?
> > 
> > In the event the KAboutData doesn't already exist I think automatically setting it up makes sense, and QCoreApplication is a good source. But I would rather flag property conflicts than to break ties when developer selects two different values for same property, as that's change in behavior might break other parts of code that rely on KAboutData not changing values.
> > 
> > Would this partial solution be OK for the problem you're running into?
> 
> Albert Astals Cid wrote:
>     > I think I disagree with the idea of overwriting KAboutData properties if they are already set by the user. Alex, any thoughts?
>     
>     I agree with Michael, it seems strage it overwriting what you may have set in setAboutData.
> 
> Friedrich W. H. Kossebau wrote:
>     Hm. Would it not be more strange if one cannot be sure that KAboutData::applicationData().displayName() matches app->applicationDisplayName()? And similar for the other shared/mapped application metadata properties? Why would I rather expect the original property of the KAboutData value to be kept, than it being updated to its counterpart in the Q*Application metadata, if changed by the Qt-API afterwards?
>     Surprised to see you expecting things to be different :)
>     
>     Not that I expect it to happen a lot in real world code that the metadata of applications is set/reset by independent code snippets (and thus a mixture of KAboutData-using and Q*Application::setX-using), where random orders of writing and reading the data can happen. But if it happens, should not both Q*Application::setX and KAboutData::setApplicationData be equi-mighty, and both be acting on the same effective properties when it comes to metadata about the application instance, where it makes sense and is defined as such?
>     
>     Or, why should KAboutData::setApplicationData be allowed to overrule any already set QApplication metadata (which makes sense to everyone), but not the other way around? :) Why should KAboutData::setApplicationData be write-through, but KAboutData::applicationData not be read-through?
>     
>     Like it is now, if I would want to use metadata of the application, I cannot rely on KAboutData::applicationData alone, I also have to separately read things by Q*Application::x, to be sure to really have the values also used by other Qt-only parts of the code. Which renders the duplicates of those Q*Application properties in KAboutData useless, no?
>     I would expect more code to be broken if it relies only on KAboutData::applicationData() than code which expects any properties to keep their values, even if getting out-of-sync with the Qt application metadata.
>     
>     For the bug which motivated me to write this patch, agreeing on initialising at least the global KAboutData instance to current Q*Application data should be fine, so will change the patch to that now. But well, I think this initial patch should be the way to go and yield less surprising behaviour :)

> Would it not be more strange if one cannot be sure that KAboutData::applicationData().displayName() matches app->applicationDisplayName()?

To me, no.

> Why would I rather expect the original property of the KAboutData value to be kept, than it being updated to its counterpart in the Q*Application metadata, if changed by the Qt-API afterwards?

Why should they match? You're basically arguing for
a->setX("BOO")
b->setY("LALA")
a->x() => should return "LALA"

That's the most strange API ever.

> Or, why should KAboutData::setApplicationData be allowed to overrule any already set QApplication metadata (which makes sense to everyone), but not the other way around?

I don't think it makes sense either. If we're to fix this assymetry, I would much rather prefer a patch that doesn't overwrite QCoreApplication version, name and organization domain if they have already been set.

I am not the maintainer of this framework though, so wait for a more qualified opinion.


- Albert


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127655/#review95002
-----------------------------------------------------------


On April 28, 2016, 1:04 a.m., Friedrich W. H. Kossebau wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127655/
> -----------------------------------------------------------
> 
> (Updated April 28, 2016, 1:04 a.m.)
> 
> 
> Review request for KDE Frameworks, Alex Richardson and Michael Pyne.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> -------
> 
> KAboutData is passed as values on getting and setting the "applicationData",
> and it only makes sense to have its properties be a transparent access
> to the actual mirrored Q*Application metadata.
>     
> Even more as there is code in KF5 (e.g. KXMLGUI) which relies on KAboutData::applicationData(),
> without requiring the user to use KAboutData::setApplicationData().
> 
> 
> Diffs
> -----
> 
>   autotests/kaboutdatatest.cpp f31e7f3 
>   src/lib/kaboutdata.h 97c0f2b 
>   src/lib/kaboutdata.cpp ceb0c06 
> 
> Diff: https://git.reviewboard.kde.org/r/127655/diff/
> 
> 
> Testing
> -------
> 
> Added autotests pass.
> 
> 
> Thanks,
> 
> Friedrich W. H. Kossebau
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160502/d0197627/attachment.html>