[PlasmaCore.IconItem] Refactor source handling for different types
ClosedPublic

Authored by kmaterka on Mar 31 2020, 8:39 PM.

Details

Summary

There are 3 possible strategies: QIcon, QImage and SVG. This change moves logic of each of these strategies into separate class.

Test Plan

Should behave exactly the same

Diff Detail

Repository
R242 Plasma Framework (Library)
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 25784
Build 25802: arc lint + arc unit
kmaterka created this revision.Mar 31 2020, 8:39 PM
Restricted Application added a project: Frameworks. · View Herald TranscriptMar 31 2020, 8:39 PM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
kmaterka requested review of this revision.Mar 31 2020, 8:39 PM

Do you think it is a good direction?

cblack added a subscriber: cblack.Apr 3 2020, 12:53 AM

Splitting into multiple classes seems like a good idea, but "strategy"? Seems like an odd choice of name to me.

src/declarativeimports/core/iconitem.cpp
58

Is this class necessary? I feel like this class's behaviour should be what its parent does without a child implementation.

58

Also, "Stategy" instead of "Strategy"

80

Seems unused.

kmaterka updated this revision to Diff 79279.Apr 4 2020, 11:37 AM

fix some silly errors

kmaterka marked 2 inline comments as done.Apr 4 2020, 11:49 AM
kmaterka added inline comments.
src/declarativeimports/core/iconitem.cpp
58

I wanted IconItemStrategy to be just an abstract base class, so that to have no strategy selected one needs to select null strategy explicitly.

80

removed unused variable from NullStrategy

kmaterka updated this revision to Diff 79281.Apr 4 2020, 11:50 AM
kmaterka marked an inline comment as done.

be consistent with old implementation

kmaterka retitled this revision from WIP: IconItem: Refactor source handling for different types to [PlasmaCore.IconItem] Refactor source handling for different types.Apr 4 2020, 11:51 AM
kmaterka edited the test plan for this revision. (Show Details)

Splitting into multiple classes seems like a good idea, but "strategy"? Seems like an odd choice of name to me.

I had assumed it's because of https://en.m.wikipedia.org/wiki/Strategy_pattern

Splitting into multiple classes seems like a good idea, but "strategy"? Seems like an odd choice of name to me.

I had assumed it's because of https://en.m.wikipedia.org/wiki/Strategy_pattern

Yeah, I totally agree, it is really confusing now. I'm bad at creating class names :)
I wanted to extract source handling (logic, internal state) to separate classes. "Handler" is overused, maybe something like this:
IconItemSource (or AbstractIconItemSource, or AbstractSource), then:
QImageSource (or QImageIconItemSource)
QIconSource (or QIconIconItemSource)
SvgSource (or SvgIconItemSource)
What do you think?

kmaterka updated this revision to Diff 79283.Apr 4 2020, 12:18 PM

Change class name: *Strategy -> *Source

Is it OK now? Any other review comments?

ping, review needed :)

mart added a subscriber: mart.Apr 14 2020, 7:46 AM
mart added inline comments.
src/declarativeimports/core/iconitem.cpp
40

does it have to be a QObject? it doesn't have properties, signals or invokables.. qobject is an expensive class so if you don't have to use oits features is better to avoid

Note there's a unit test for IconItem worth running if you haven't already.
The refactor in general makes sense - it's a lot cleaner.

Though I'm not sure what our super long term KF6 plan for IconItem is, it'll definitely be changing quite a bit.

kmaterka marked an inline comment as done.Apr 14 2020, 6:39 PM

Note there's a unit test for IconItem worth running if you haven't already.

I've checked that already, these test were really useful!

The refactor in general makes sense - it's a lot cleaner.
Though I'm not sure what our super long term KF6 plan for IconItem is, it'll definitely be changing quite a bit.

If there is no harm now, then it should be easier to change it in the future :)

src/declarativeimports/core/iconitem.cpp
40

There is one use of connect in SvgSource but I can change the implementation.

kmaterka updated this revision to Diff 80148.Apr 14 2020, 6:40 PM
kmaterka marked an inline comment as done.

Do not inherit from QObject

Any other comment? Is it OK and can be approved?

kmaterka updated this revision to Diff 81031.Apr 23 2020, 6:24 PM

Rebase to master (includes D29102)

davidedmundson accepted this revision.Apr 23 2020, 9:27 PM
This revision is now accepted and ready to land.Apr 23 2020, 9:27 PM
This revision was automatically updated to reflect the committed changes.

git bisect says this caused https://bugs.kde.org/show_bug.cgi?id=420801.

I will check that, sorry...

No worries, it happens to the best of us. :)

Regression fixed in D29314.