add a version of containmentForScreen which it has the activity.
which is correct as the activity id of containments in in libplasma side.
this ensure the correctness of shellCorona createContainmentForActivity
as now it works also for activities different from the current one.
to make multimonitor a tad safer with it, when creating containments for an activity, initialize their lastScreen to the asked screen.
Details
- Reviewers
davidedmundson - Group Reviewers
Plasma - Commits
- R242:bfa19dbc8fc7: add a version containmentForScreen with activity
tried with an old plasmashell and is perfectly retrocompatible
Diff Detail
- Repository
- R242 Plasma Framework (Library)
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Either Corona tracks which containment are on which containment or ShellCorona does.
Having
QHash<QString /*activity*/, QSet<Plasma::Containment *> > m_desktopContainments;
in ShellCorona
and containmentForScreen(int id, const QString &activity) in Corona
The subclass is storing the data the superclass is allegedly providing.
We're storing the same thing in two places (either a map in shellcorona, or stored in the containment). This is asking for trouble.
I'd be happy for activity management to be moved here, it would save ShellCorona trying to retrospectively add a layer in a tree at completely the wrong place and clean up a tonne of code.
But if we're doing that it should be done completely.
- Merge branch 'master' into arcpatch-D11361
- add containmentsForActivity and containmentsForScreen
so, i tried to remove m_desktopContainments in D11801, using the new query functions i added here.
all seems to keep working, hopefully makes things a bit more robust
tried with an old plasmashell and is perfectly retrocompatible
Please make sure that includes comprehensively trying adding and removing screens and activities.