> 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 :)
>
> Albert Astals Cid wrote:
> > 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.
Well, I am arguing for what KAboutData::applicationData is about IMHO and
expected by most code I have seen, which is:
a representation of the metadata of the Q*Application instance (which I
consider a result of quick&dirty porting to Qt5 under the premise of API
compatibility for all the existing codebase, not something which is well
designed given the Qt5 API, in case you doubt). Do not agree with your code
abstraction, but well, it's not straight object-oriented code in any case.
So what is the intend of any code which uses the setter/getter for that global
KAboutData instance named "applicationData"? To keep a separate data copy which
is living in its own world, discoupled from what other KAboutData-ignorant code
does when it comes to app metadata, really? I have not seen any
KAboutData::applicationData code which would. All the code would only fail
because they assume the applicationdata to be stable at some point for the rest
of the runtime, and that would be independent of any orders and numbers of
whatever methods calls to change the applicationdata before. Funnily most of
the Q*Application metadata are registered as properties with notify, but no
publically documented signal... oh well.
Well, seems you do not like that mapping to a shared property at all, okay.
Let's see what would be an alternative then? How can we know if some property
has already been set? Should an empty string be always interpreted as not set?
Might work for most properties, but not all. Abd the Q*Application API does not
enforce setting all properties in one go. Too tired to think of something else.
So now updating the patch to only extend the incomplete init from the
Q*Application metadata. Let's fix the other issues with more thoughts before.
BTW, seems there is no maintainer of this framework, so your opinion is equal
to everyone's.
> On April 29, 2016, 3:15 a.m., Michael Pyne wrote:
> > src/lib/kaboutdata.cpp, line 920
> > <https://git.reviewboard.kde.org/r/127655/diff/1/?file=456160#file456160line920>
> >
> > I think an else block should be added here that verifies whether the
> > QCoreApplication properties are consistent with KAboutData's and if not,
> > displays a big huge warning for each conflicting property.
> >
> > I'd rather not initialize KAboutData from QCoreApplication if doing so
> > would overwrite a non-empty KAboutData property, at least at this point.
> > Seems to risk a very spooky 'action-at-a-distance' in code whose behavior
> > would then depend on when you ran KAboutData::setApplicationData in
> > relation to creating a QCoreApplication.
As discussed I will leave the synchronizing of the returned KAboutData out for
now.
Adding a check and a warning here might make sense, should not be called to
often, added to patch.
- Friedrich W. H.
-----------------------------------------------------------
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
>
>
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
