We were passing the enum as the first argument, which was being
converted to 0 and would set lastModified to 0. This would in turn
result in the cache being bypassed because now `findInCache with a
lastModified timestamp of 0 is deprecated` taking the slow path on most
occasions.
This, I suspect, is the true source of bug 426674. FrameSvg would
request items from the cache without specifying any modification time
stamp, so we end up always retrieving the cached version. Since
lastModified is now a required parameter, we need to ensure this does
not happen anymore.
BUG: 426674
Not tracking modification time of icon/themed stuff means we do not know
when we need to reject the cached versions of these. So ensure we try to
keep track of the svg that this is coming from, even if we do stuff to
it in the meantime.
Longer term this should be changed so the cache knows which files it is
caching and can reject things that changed in the meantime.
lastModified is used to track whether a file is outdated. Having a 0
here means we (in the old code) use the cached version. This causes
problems when the on-disk file has changed, as we have no way of
informing callers that they should regenerate the cache entry. To avoid
this, using a lastModified of 0 now warns and will always return false
(to indicate it is not cached). Unfortunately we can't simply drop the
default parameter of 0 since there is no source-compatible way of doing
that.
CCBUG: 426674
This came up in yesterday's VDG meeting.
When we introduced the idea of an edit mode. We kind of danced areound
what it is, and didn't call it a mode, even though it is. We named the
menu item "Customize layout". However in all of our communications with
the user outside of the UI, we call it the global edit mode. Users
themselves call it "mdit mode". The code calls it "edit mode". We call
it edit mode when we talk about it internally. I think it's pretty clear
what it is in people's minds. So let's make the UI text reflect that.
Having the macro's definition of the operator| in the namespace of the
flags argument improves/unbreaks things for the argument-dependent
lookup of unqualified function names, e.g. when flags are combined in
calls of other methods, but there is some other operator| defined in the
namespace of the current code.
Given Q_DECLARE_OPERATORS_FOR_FLAGS creates inlined functions, this
should be a source and binary compatible change.
Qt did similar for Qt 5.12 in
https://codereview.qt-project.org/c/qt/qtbase/+/225348
if KDeclarative::runtimePlatform() is set, then filter applets
that have formfactors set and don't match, in order to not
show on the phone applets that are desktop only
in desktop case, list all applets, for maximum retrocompatibility,
to be reconsidered for kf6
Compare API dox of Q_DECLARE_METATYPE:
"
Some types are registered automatically and do not need this macro:
* Pointers to classes derived from QObject
* QPointer<T>, QSharedPointer<T>, QWeakPointer<T>,
where T is a class that derives from QObject
"
This is a ABI-compatible change, as this just replaces explicitly
defined template code (by the Q_DECLARE_METATYPE macro use) with the
generic predefined one picking up pointers to QObject subclasses.
So instead of the custom explicitly template overload
template <>
struct QMetaTypeId< TYPE >
{ /**/ static int qt_metatype_id() {/**/} };
the predefined template overload one is picked up via
template <typename T>
struct QMetaTypeId : public QMetaTypeIdQObject<T>
{ /**/ };
template <typename T, int =
QtPrivate::IsPointerToTypeDerivedFromQObject<T>::Value ?
QMetaType::PointerToQObject :
/**/ 0>
struct QMetaTypeIdQObject
{ /**/ };
template <typename T>
struct QMetaTypeIdQObject<T*, QMetaType::PointerToQObject>
{ /**/ static int qt_metatype_id() {/**/} };
And thus the constexpr code using QMetaTypeId<T>::qt_metatype_id(),
for which all this is done, evaluates as before.
GIT_SILENT
relay->checkQueueing emits a signal to all observers. As it's a signal
anything can happen at that point. It's seemingly common for a receiver
to connect/disconnect a new visualisation which in turn alters
d->relays.
This broke when a foreach (with implicit shallow copy) was ported to a
for statement.
This report contains a good analysis and test case
BUG: 422973
Probably also:
BUG: 421392
BUG: 423713
BUG: 423776
BUG: 422230
BUG: 423081
Summary:
Before icons loaded internally with QIcon::fromTheme were being colored with the
colors from the current global color scheme instead of the ones from the current
Plasma Theme. Leading to visual bugs when the two differ. This happened because
KIconLoader uses the global color scheme by default.
A prominent case is the notification send by the network plasmoid when one
successfully connected to a wireless network. It sets the icon
"network-wireless-on" which is not included in Breeze icons (but is included in
Breeze Plasma Theme). If the current icon theme is indeed Breeze, IconItem
resorts to using QIcon::fromTheme and we end up with a wrong colored
"network-wireless" icon.
BUG: 417780
Test Plan:
{F8125752}
{F8125753}
Reviewers: #plasma, cblack, ngraham, mart
Reviewed By: #plasma, cblack, ngraham, mart
Subscribers: mart, wbauer, cblack, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D27589
The deprecated constructor taking a KPluginInfo unconditionally calls toMetaData() and then asserts.
BUG: 417548
Differential Revision: https://phabricator.kde.org/D27366
