Merge lp:~gerboland/miral/qt-add-window-model-mir-side into lp:miral
| Status: | Merged |
|---|---|
| Approved by: | Alan Griffiths on 2016-07-27 |
| Approved revision: | 241 |
| Merged at revision: | 239 |
| Proposed branch: | lp:~gerboland/miral/qt-add-window-model-mir-side |
| Merge into: | lp:miral |
| Diff against target: |
394 lines (+294/-16) 7 files modified
miral-qt/src/common/mirqtconversion.h (+28/-0) miral-qt/src/common/windowmodelinterface.h (+78/-0) miral-qt/src/platforms/mirserver/CMakeLists.txt (+2/-0) miral-qt/src/platforms/mirserver/windowmanagementpolicy.cpp (+5/-3) miral-qt/src/platforms/mirserver/windowmanagementpolicy.h (+4/-13) miral-qt/src/platforms/mirserver/windowmodel.cpp (+125/-0) miral-qt/src/platforms/mirserver/windowmodel.h (+52/-0) |
| To merge this branch: | bzr merge lp:~gerboland/miral/qt-add-window-model-mir-side |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Alan Griffiths | 2016-07-25 | Approve on 2016-07-27 | |
|
Review via email:
|
|||
Commit Message
Qt: implement basic Mir-side window "model" which emits signals describing the model changes to a consumer (to come later)
Primary problem to be solved: have a model of windows that Qt can implement a view for.
Qt unfortunately requires that the model and the view have matching thread affinity - meaning I cannot manage the model on Mir's threads and use locking to keep consistent state for the view.
Instead I need to create and manage the model on Qt's GUI thread (where the view will live). I will do this by firing signals from this Mir-side WindowModel which will describe how the model changes, signals which a GUI thread model will listen for and use to synchronize its state with.
| Gerry Boland (gerboland) wrote : | # |
> Nits:
>
> +// miral::WindowInfo has a copy constructor, but implicitly shares a Self
> object between each
> +// copy. If a miral::WindowInfo copy is sent over signal/slot connection
> across thread boundaries,
> +// it could be changed in a Mir thread before the slot processes it.
> +//
> +// This is undesirable as we need to update the GUI thread model in a
> consistent way.
> +//
> +// Instead we duplicate the miral::WindowInfo data, in a way that can be sent
> over signal/slot
> +// connections safely.
>
> Obsolete/misleading comment?
Yep, sorry. Fixed.
> +// We assign each Window with a unique ID that both Mir-side and Qt-side
> WindowModels can share
> Can't we just use a weak_ptr<Surface> as an ID?
Yes that's a much better idea. I was worried about lifetimes, but the view (qtmir::MirSurface) holds a copy of the shared_
| Alan Griffiths (alan-griffiths) wrote : | # |
> > Can't we just use a weak_ptr<Surface> as an ID?
> Yes that's a much better idea. I was worried about lifetimes, but the view
> (qtmir::MirSurface) holds a copy of the shared_
> it is deleted - deletion which only happens after its corresponding entry is
> removed from the model.
You can use a weak_ptr<Surface> - which avoids accidentally affecting the lifetime. (I do this in BasicWindowMana
| Gerry Boland (gerboland) wrote : | # |
> > Nits:
> >
> > +// miral::WindowInfo has a copy constructor, but implicitly shares a Self
> > object between each
> > +// copy. If a miral::WindowInfo copy is sent over signal/slot connection
> > across thread boundaries,
> > +// it could be changed in a Mir thread before the slot processes it.
> > +//
> > +// This is undesirable as we need to update the GUI thread model in a
> > consistent way.
> > +//
> > +// Instead we duplicate the miral::WindowInfo data, in a way that can be
> sent
> > over signal/slot
> > +// connections safely.
> >
> > Obsolete/misleading comment?
>
> Yep, sorry. Fixed.
>
>
> > +// We assign each Window with a unique ID that both Mir-side and Qt-side
> > WindowModels can share
> > Can't we just use a weak_ptr<Surface> as an ID?
> Yes that's a much better idea. I was worried about lifetimes, but the view
> (qtmir::MirSurface) holds a copy of the shared_
> it is deleted - deletion which only happens after its corresponding entry is
> removed from the model.
Ah, not quite, there is more going on. I want the Mir-side window model (mirserver/
So the comment is not quite accurate, I've updated it to be more correct.
- 240. By Gerry Boland on 2016-07-27
-
Old comment not relevent, corrected
- 241. By Gerry Boland on 2016-07-27
-
Another badly written comment updated

Nits:
+// miral::WindowInfo has a copy constructor, but implicitly shares a Self object between each
+// copy. If a miral::WindowInfo copy is sent over signal/slot connection across thread boundaries,
+// it could be changed in a Mir thread before the slot processes it.
+//
+// This is undesirable as we need to update the GUI thread model in a consistent way.
+//
+// Instead we duplicate the miral::WindowInfo data, in a way that can be sent over signal/slot
+// connections safely.
Obsolete/misleading comment?
1. miral::WindowInfo doesn't share self, it copies it.
2. I don't see the duplicate.
~~~~
+// We assign each Window with a unique ID that both Mir-side and Qt-side WindowModels can share
Can't we just use a weak_ptr<Surface> as an ID?