Merge lp:~gerboland/qtmir/qmirserver-hides-mirserver into lp:qtmir
| Status: | Merged |
|---|---|
| Approved by: | Daniel d'Andrada on 2015-05-29 |
| Approved revision: | 340 |
| Merged at revision: | 344 |
| Proposed branch: | lp:~gerboland/qtmir/qmirserver-hides-mirserver |
| Merge into: | lp:qtmir |
| Diff against target: |
750 lines (+279/-192) 14 files modified
demos/qml-demo-shell/qml-demo-shell.qml (+15/-0) src/platforms/mirserver/CMakeLists.txt (+1/-0) src/platforms/mirserver/display.cpp (+1/-6) src/platforms/mirserver/display.h (+7/-9) src/platforms/mirserver/miropenglcontext.cpp (+2/-3) src/platforms/mirserver/miropenglcontext.h (+0/-1) src/platforms/mirserver/mirserverintegration.cpp (+24/-35) src/platforms/mirserver/mirserverintegration.h (+3/-4) src/platforms/mirserver/nativeinterface.cpp (+13/-10) src/platforms/mirserver/nativeinterface.h (+3/-3) src/platforms/mirserver/qmirserver.cpp (+69/-72) src/platforms/mirserver/qmirserver.h (+21/-49) src/platforms/mirserver/qmirserver_p.cpp (+53/-0) src/platforms/mirserver/qmirserver_p.h (+67/-0) |
| To merge this branch: | bzr merge lp:~gerboland/qtmir/qmirserver-hides-mirserver |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Daniel d'Andrada (community) | 2015-05-01 | Approve on 2015-05-29 | |
| PS Jenkins bot | continuous-integration | Needs Fixing on 2015-05-27 | |
|
Review via email:
|
|||
Commit Message
[qpa] refactor QMirServer to clean up its API, and fix strange thread design.
This does the following:
- QMirServer has a much cleaner API - using d-pointer to encourage ABI stability
- move quit decision point to MirServerIntegr
- the Mir server is run from a class inheriting a QThread, simplifies thread control significantly
| Daniel d'Andrada (dandrader) wrote : | # |
If you're thinking about making QMirServer public API, could you please add some documentation to src/platforms/
| Daniel d'Andrada (dandrader) wrote : | # |
So MirServer::stop() is thread safe or is it a hack?
"""
void MirServerWorker
{
server->stop();
}
"""
| Daniel d'Andrada (dandrader) wrote : | # |
> So MirServer::stop() is thread safe or is it a hack?
>
>
> """
> void MirServerWorker
> {
> server->stop();
> }
> """
Please ignore me. Now I see that MirServerWorker
| Daniel d'Andrada (dandrader) wrote : | # |
In src/platforms/
"""
Q_SLOT void serverStopped();
"""
Are you sure you want this slot in the public API?
And, by the way, it's named like a signal. It should be onServerStopped() or, even better, quit().
| Daniel d'Andrada (dandrader) wrote : | # |
in src/platforms/
"""
connect(
"""
I think this line deserves a comment explaining why this has to be a direct connection, which will cause QMirServer:
trunk has a terse comment about it.
Which makes me think maybe you should say from which thread QMirServer:
| Daniel d'Andrada (dandrader) wrote : | # |
In src/platforms/
"""
bool run();
Q_SLOT bool stop();
"""
Again, thinking about having it as public API: you should probably document these methods, answering questions like: Is it a blocking call or does it return immediately?
What's the user expected to do with those return values? I don't see you using them for anything.
"""
connect(
"""
"""
if (!d->serverWork
{
qCritical() << "ERROR: QMirServer - Mir failed to start";
"""
Isn't QMirServer going out of its territory when it modifies QCoreApplication directly like that?
I would expect the user of QMirServer to do this instead, like:
"""
if (!qmirServer-
QCoreApplic
}
"""
| Daniel d'Andrada (dandrader) wrote : | # |
In src/platforms/
"""
-Display:
- : QObject(parent)
- , m_mirServer(server)
+Display:
{
- std::shared_
+ std::shared_
"""
I think you could go further and pass the display config already in the constructor instead of the whole server since that's the only thing Display is interested in after all.
-------
In src/platforms/
"""
MirOpenGLConte
- : m_mirServer(server)
#if GL_DEBUG
- , m_logger(new QOpenGLDebugLog
+ : m_logger(new QOpenGLDebugLog
#endif
{
- std::shared_
+ std::shared_
"""
Likewise here.
| Gerry Boland (gerboland) wrote : | # |
> If you're thinking about making QMirServer public API, could you please add
> some documentation to src/platforms/
> does, what's its main purpose.
It's far from ready yet, but that is the plan. I'll start writing documentation when we've the API in a good condition, which will be another while yet.
| Gerry Boland (gerboland) wrote : | # |
> in src/platforms/
>
> """
> connect(
> &QMirServer:
> """
>
> I think this line deserves a comment explaining why this has to be a direct
> connection, which will cause QMirServer:
> within MirServerWorker's thread.
>
> trunk has a terse comment about it.
Fair point. The line above it also creates a direct connection, and that line has a comment pointing to the explanation. But yeah, that connection is easily missed, will fix
| Gerry Boland (gerboland) wrote : | # |
> In src/platforms/
>
> """
> bool run();
> Q_SLOT bool stop();
> """
>
> Again, thinking about having it as public API: you should probably document
> these methods, answering questions like: Is it a blocking call or does it
> return immediately?
>
> What's the user expected to do with those return values? I don't see you using
> them for anything.
I was planning to document things later. But I can start now if you'd prefer.
> """
> connect(
> d->serverWorker, &MirServerWorke
> see FIXME in MirServerWorker
> """
>
> """
> if (!d->serverWork
> {
> qCritical() << "ERROR: QMirServer - Mir failed to start";
> QCoreApplicatio
> """
>
> Isn't QMirServer going out of its territory when it modifies QCoreApplication
> directly like that?
> I would expect the user of QMirServer to do this instead, like:
>
> """
> if (!qmirServer-
> QCoreApplicatio
> }
> """
You're totally right, this is also the direction I wanted to go. I was hesitant to do so, as I feared it along with all the other changes would make quite a large MR. So your suggestion is to be the next step: have the QMirServer user listen for mir or qt shutdown, and react accordingly. Should I just do that now?
| Gerry Boland (gerboland) wrote : | # |
> In src/platforms/
>
> """
> -Display:
> - : QObject(parent)
> - , m_mirServer(server)
> +Display:
> {
> - std::shared_
> m_mirServer-
> + std::shared_
> server-
> """
>
> I think you could go further and pass the display config already in the
> constructor instead of the whole server since that's the only thing Display is
> interested in after all.
>
> -------
>
> In src/platforms/
>
> """
> MirOpenGLContex
> const QSurfaceFormat &format)
> - : m_mirServer(server)
> #if GL_DEBUG
> - , m_logger(new QOpenGLDebugLog
> + : m_logger(new QOpenGLDebugLog
> #endif
> {
> - std::shared_
> m_mirServer-
> + std::shared_
> """
>
> Likewise here.
I had a reason for not doing that at the time, but I can't recall it now. Will do
| Daniel d'Andrada (dandrader) wrote : | # |
> > In src/platforms/
> >
> > """
> > bool run();
> > Q_SLOT bool stop();
> > """
> >
> > Again, thinking about having it as public API: you should probably document
> > these methods, answering questions like: Is it a blocking call or does it
> > return immediately?
> >
> > What's the user expected to do with those return values? I don't see you
> using
> > them for anything.
>
> I was planning to document things later. But I can start now if you'd prefer.
>
>
>
> > """
> > connect(
> > d->serverWorker, &MirServerWorke
> //
> > see FIXME in MirServerWorker
> > """
> >
> > """
> > if (!d->serverWork
> > {
> > qCritical() << "ERROR: QMirServer - Mir failed to start";
> > QCoreApplicatio
> > """
> >
> > Isn't QMirServer going out of its territory when it modifies
> QCoreApplication
> > directly like that?
> > I would expect the user of QMirServer to do this instead, like:
> >
> > """
> > if (!qmirServer-
> > QCoreApplicatio
> > }
> > """
>
>
> You're totally right, this is also the direction I wanted to go. I was
> hesitant to do so, as I feared it along with all the other changes would make
> quite a large MR. So your suggestion is to be the next step: have the
> QMirServer user listen for mir or qt shutdown, and react accordingly. Should I
> just do that now?
I can live with this being an intermediate step but it should leave the code in a consistent state. Eg: If you don't use the return values for anything then don't return them in the first place (have a void return type). Also it would be good to add TODOs for the next step, like over those QCoreApplication calls inside QMirServer.
| Daniel d'Andrada (dandrader) wrote : | # |
The commit message line is a bit too long. That first line should shorter, followed by a longer description below if needed
- 332. By Gerry Boland on 2015-05-18
-
Trying to fix shutdown, incomplete
- 333. By Gerry Boland on 2015-05-18
-
Fix shutdown issues by inheriting QThread directly - also get to avoid having qt event loop for mir
- 334. By Gerry Boland on 2015-05-18
-
Clean up shutdown codepath further. run/stop return void
- 335. By Gerry Boland on 2015-05-18
-
Unneeded return statements
- 336. By Gerry Boland on 2015-05-18
-
Remove old comment, it not the case any more
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:336
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
- 337. By Gerry Boland on 2015-05-18
-
Merge qtmir trunk
| Gerry Boland (gerboland) wrote : | # |
> > In src/platforms/
> >
> > """
> > -Display:
> > - : QObject(parent)
> > - , m_mirServer(server)
> > +Display:
> > {
> > - std::shared_
> > m_mirServer-
> > + std::shared_
> > server-
> > """
> >
> > I think you could go further and pass the display config already in the
> > constructor instead of the whole server since that's the only thing Display
> is
> > interested in after all.
> >
> > -------
> >
> > In src/platforms/
> >
> > """
> > MirOpenGLContex
> > const QSurfaceFormat &format)
> > - : m_mirServer(server)
> > #if GL_DEBUG
> > - , m_logger(new QOpenGLDebugLog
> > + : m_logger(new QOpenGLDebugLog
> > #endif
> > {
> > - std::shared_
> > m_mirServer-
> > + std::shared_
> server-
> > """
> >
> > Likewise here.
>
>
> I had a reason for not doing that at the time, but I can't recall it now. Will
> do
I thought of the reason. It would require me to include loads of Mir internal headers in MirServerIntegr
As the multimonitor work will refactor those classes quite a bit, I decided to just keep this approach knowing that I'll improve it later.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:337
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
Click here to trigger a rebuild:
http://
- 338. By Gerry Boland on 2015-05-19
-
Merge trunk
- 339. By Gerry Boland on 2015-05-19
-
Remove unneeded header
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:339
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
- 340. By Gerry Boland on 2015-05-27
-
Only pass mg::DisplayConf
iguration to qtmir::Display, as that is all it needs
| Gerry Boland (gerboland) wrote : | # |
Ready for a second review pass. Main change is in the thread design which simplifies event passing greatly. API improved too, QMirServer no longer quits the process, owner does instead
| Daniel d'Andrada (dandrader) wrote : | # |
"""
bool QMirServer::start()
{
[...]
Q_EMIT started();
[...]
}
"""
Is this signal being used for anything?
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:340
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Gerry Boland (gerboland) wrote : | # |
> """
> bool QMirServer::start()
> {
> [...]
> Q_EMIT started();
> [...]
> }
> """
>
> Is this signal being used for anything?
Nope, added to API for symmetry (the "stopped" signal is necessary)
| Daniel d'Andrada (dandrader) wrote : | # |
Code looks ok, but didn't test on the device to see if broke anything.
| Daniel d'Andrada (dandrader) wrote : | # |
* Did you perform an exploratory manual test run of the code change and any related functionality?
Yes.
* Did CI run pass? If not, please explain why.
No, because Jenkins runs on wily and wily doesn't have mir 0.13 yet.

PASSED: Continuous integration, rev:331 jenkins. qa.ubuntu. com/job/ qtmir-ci/ 258/ jenkins. qa.ubuntu. com/job/ qtmir-vivid- amd64-ci/ 109 jenkins. qa.ubuntu. com/job/ qtmir-vivid- armhf-ci/ 109 jenkins. qa.ubuntu. com/job/ qtmir-vivid- armhf-ci/ 109/artifact/ work/output/ *zip*/output. zip
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/qtmir- ci/258/ rebuild
http://