Merge lp:~dandrader/unity8/homeKey into lp:unity8
| Status: | Superseded |
|---|---|
| Proposed branch: | lp:~dandrader/unity8/homeKey |
| Merge into: | lp:unity8 |
| Diff against target: |
804 lines (+699/-4) 10 files modified
plugins/Utils/CMakeLists.txt (+2/-0) plugins/Utils/ElapsedTimer.h (+51/-0) plugins/Utils/HomeKeyWatcher.cpp (+105/-0) plugins/Utils/HomeKeyWatcher.h (+73/-0) plugins/Utils/Timer.cpp (+59/-0) plugins/Utils/Timer.h (+79/-0) plugins/Utils/plugin.cpp (+3/-4) qml/Shell.qml (+4/-0) tests/plugins/Utils/CMakeLists.txt (+1/-0) tests/plugins/Utils/homekeywatchertest.cpp (+322/-0) |
| To merge this branch: | bzr merge lp:~dandrader/unity8/homeKey |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Michał Sawicz | 2015-04-17 | Needs Fixing on 2015-04-22 | |
| PS Jenkins bot | continuous-integration | 2015-04-17 | Needs Fixing on 2015-04-22 |
| Josh Arenson | 2015-04-17 | Needs Information on 2015-04-20 | |
|
Review via email:
|
|||
This proposal has been superseded by a proposal from 2015-04-23.
Commit Message
Tapping home key shows unity8-dash home
Description of the Change
* Are there any related MPs required for this MP to build/function as expected? Please list.
No.
* Did you perform an exploratory manual test run of your code change and any related functionality?
Yes.
* Did you make sure that your branch does not contain spurious tags?
Yes.
* If you changed the packaging (debian), did you subscribe the ubuntu-unity team to this MP?
N/A
* If you changed the UI, has there been a design review?
N/A
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:1732
http://
Executed test runs:
FAILURE: http://
UNSTABLE: http://
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Josh Arenson (josharenson) wrote : | # |
We had discussed on IRC that pressing the home key should hide the launcher. Since this MP does _not_ do that, I was wondering if that was still the case.
| Michał Sawicz (saviq) wrote : | # |
The whole timer situation feels too complicated, could you at least split out the fake timer into tests/utils?
Any reason you're not consistent with file name case (homekeywatcher.* vs. ElapsedTimer.*)?
See inline (Ctrl+F + saviq) ;)
| Daniel d'Andrada (dandrader) wrote : | # |
On 21/04/15 11:01, Michał Sawicz wrote:
> Review: Needs Information
>
> The whole timer situation feels too complicated, could you at least split out the fake timer into tests/utils?
Done.
That's the price you pay for testability. But at least this stuff can be
used by other classes in the future. This is actually a
copy&paste&rename from Ubuntu.Gestures plugin.
>
> Any reason you're not consistent with file name case (homekeywatcher.* vs. ElapsedTimer.*)?
Yes. The all-lowercase version was made be consistent with the naming of
other files in this plugin. But then I revolted against this bad
convention (can you name a single benefit of it?) and started doing
CamelCase instead. Made them all CamelCase now.
> +
> +class AbstractElapsed
> +public:
> + virtual ~AbstractElapse
> + virtual void start() = 0;
> + virtual qint64 msecsSinceRefer
> + virtual qint64 elapsed() const = 0;
> +};
> +
> +/*
> Please use /** where applicable so that docs are generated.
Done.
> +HomeKeyWatcher
> + UnityUtil:
> + QQuickItem *parent)
> + : QQuickItem(parent)
> + , m_windowBeingTo
> + , m_windowLastTou
> Doesn't this timer need to be started on construction (ideally if there are no touches)? Candidate for a unit test?
In theory yes, in practice it doesn't really matter. Added a start()
call there anyway.
>
>> + , m_emitActivated
>> +{
>> + connect(this, &QQuickItem:
> Can we rely on this signal on startup?
Yes.
> +void HomeKeyWatcher:
> +{
> + if (event->type() == QEvent::KeyPress) {
> + QKeyEvent *keyEvent = static_
> +
> + if (keyEvent->key() == Qt::Key_Home && !keyEvent-
> Make Qt::Key_Home a define maybe? Oh and change it to Super_L already, it's going to be that on arale in the next image.
Not worth making it a define or static const or property as this is the
*only* place that uses it.
Done s/Key_Home/
>
>> + && !m_windowBeingT
>> + && m_windowLastTou
>> + m_emitActivated
>> + }
>> +
>> + } else if (event->type() == QEvent::TouchBegin) {
>> +
>> + m_emitActivated
>> + m_windowBeingTo
>> +
>> + } else if (event->type() == QEvent::TouchEnd) {
> Does this work with multiple touch points?
Yes. TouchBegin is emitted when the first touch point starts and
TouchEnd when the last remaining touch point ends.
> +private:
> + QPointer<
> + bool m_windowBeingTo
> + UnityUtil:
> + UnityUtil:
> Got a better name for this member? :)
No, do you? :)
It states precisely what it does. Anything shorter could end up being
ambiguous or misleading.
| Michał Sawicz (saviq) wrote : | # |
W dniu 22.04.2015 o 12:51, Daniel d'Andrada pisze:
> On 21/04/15 11:01, Michał Sawicz wrote:
>> Any reason you're not consistent with file name case (homekeywatcher.* vs. ElapsedTimer.*)?
> Yes. The all-lowercase version was made be consistent with the naming of
> other files in this plugin. But then I revolted against this bad
> convention (can you name a single benefit of it?) and started doing
> CamelCase instead. Made them all CamelCase now.
Yeah, needs fixin' in trunk.
>> +private:
>> + QPointer<
>> + bool m_windowBeingTo
>> + UnityUtil:
>> + UnityUtil:
>> Got a better name for this member? :)
>
> No, do you? :)
> It states precisely what it does. Anything shorter could end up being
> ambiguous or misleading.
I was thinking m_activationTimer, it's not like the member name has to
explain everything it's used for. m_noTouchTimer maybe?
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:1733
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Daniel d'Andrada (dandrader) wrote : | # |
On 20/04/15 19:41, Josh Arenson wrote:
> Review: Needs Information
>
> We had discussed on IRC that pressing the home key should hide the launcher. Since this MP does _not_ do that, I was wondering if that was still the case.
Done.
| Daniel d'Andrada (dandrader) wrote : | # |
On 22/04/15 08:36, Michał Sawicz wrote:
>>> +private:
>>> >> + QPointer<
>>> >> + bool m_windowBeingTo
>>> >> + UnityUtil:
>>> >> + UnityUtil:
>>> >> Got a better name for this member? :)
>> >
>> > No, do you? :)
>> > It states precisely what it does. Anything shorter could end up being
>> > ambiguous or misleading.
> I was thinking m_activationTimer, it's not like the member name has to
> explain everything it's used for. m_noTouchTimer maybe?
Done.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:1736
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:1737
http://
Executed test runs:
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Michał Sawicz (saviq) wrote : | # |
* Did you perform an exploratory manual test run of the code change and any related functionality?
Y
* Did CI run pass? If not, please explain why.
Bug #1446846
* Did you make sure that the branch does not contain spurious tags?
Y
| Michał Sawicz (saviq) wrote : | # |
During QA testing it occurred to us that a lazy bottom-swipe in apps is likely to bring dash in, disrupting your workflow. We need to refine that.
| Michał Sawicz (saviq) wrote : | # |
I think basically this additional testcase needs fixing:
=== modified file 'tests/
--- tests/plugins/
+++ tests/plugins/
@@ -118,6 +118,7 @@
QTest:
QTest:
QTest:
+ QTest::
}
void HomeKeyWatcherT
| Daniel d'Andrada (dandrader) wrote : | # |
> During QA testing it occurred to us that a lazy bottom-swipe in apps is likely to bring dash in, disrupting your workflow. We need to refine that.
Hmm... you sure this is a problem? I'm afraid the only way to make a lazy swipe starting from the home button to *not* activate the button would be adding even more delay to the button activation.

FAILED: Continuous integration, rev:1731 jenkins. qa.ubuntu. com/job/ unity8- ci/5568/ jenkins. qa.ubuntu. com/job/ generic- deb-autopilot- vivid-touch/ 2313/console jenkins. qa.ubuntu. com/job/ unity-phablet- qmluitests- vivid/731/ console jenkins. qa.ubuntu. com/job/ unity8- vivid-amd64- ci/733/ console jenkins. qa.ubuntu. com/job/ unity8- vivid-i386- ci/733/ console jenkins. qa.ubuntu. com/job/ generic- mediumtests- builder- vivid-armhf/ 2311/console
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/unity8- ci/5568/ rebuild
http://