Merge lp:~andreas-pokorny/mir/input-configuration-api into lp:mir
| Status: | Merged |
|---|---|
| Approved by: | Andreas Pokorny on 2015-11-18 |
| Approved revision: | 2998 |
| Merged at revision: | 3106 |
| Proposed branch: | lp:~andreas-pokorny/mir/input-configuration-api |
| Merge into: | lp:mir |
| Prerequisite: | lp:~andreas-pokorny/mir/libinput-platform-touch-pad-settings |
| Diff against target: |
806 lines (+476/-44) 11 files modified
include/server/mir/input/device.h (+9/-2) include/server/mir/input/pointer_configuration.h (+71/-0) include/server/mir/input/touchpad_configuration.h (+82/-0) src/server/input/CMakeLists.txt (+10/-12) src/server/input/default_device.cpp (+82/-3) src/server/input/default_device.h (+22/-4) src/server/input/default_input_device_hub.cpp (+5/-3) src/server/input/default_input_device_hub.h (+2/-0) tests/unit-tests/input/CMakeLists.txt (+1/-0) tests/unit-tests/input/test_default_device.cpp (+135/-0) tests/unit-tests/input/test_default_input_device_hub.cpp (+57/-20) |
| To merge this branch: | bzr merge lp:~andreas-pokorny/mir/input-configuration-api |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| PS Jenkins bot | continuous-integration | Approve on 2015-11-19 | |
| Alberto Aguirre | Approve on 2015-11-12 | ||
| Chris Halse Rogers | Approve on 2015-11-06 | ||
| Alan Griffiths | Abstain on 2015-11-02 | ||
| Alexandros Frantzis (community) | 2015-10-09 | Abstain on 2015-10-30 | |
|
Review via email:
|
|||
Commit Message
Add TouchPad- and PointerConfigur
These structures allow configuring input device specific settings. Applicability of these configurations can be tested through optional_
Description of the Change
This isnt the MP I was looking forward to...
Due to a change in behavior in libinput and a missing feature/bug in umockdev I cannot run the input configuration tests that I started to prepare.
Some details are here:
https:/
I am happy to keep this waiting until the above is resolved.
Apart from the lacking acceptance tests there are already some API decisions to review...
Beware there is some duplication in this MP until the other MP for
lp:~andreas-pokorny/mir/load-all-supported-input-platforms lands.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2985
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
FAILURE: http://
SUCCESS: http://
deb: http://
FAILURE: http://
SUCCESS: http://
deb: http://
FAILURE: http://
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2987
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Alexandros Frantzis (afrantzis) wrote : | # |
+ virtual void apply_configura
+ virtual void apply_configura
I find it easier to read code when the functions are not overloaded in this way, but have unique names instead, e.g.:
apply_pointer_
apply_touchpad_
I think if functions are performing different operations they should be named differently. We should only use overloading for functions that perform the same operation but need different arguments.
For an extreme case of this see the super confusing (IMO) mev::make_event() family of builder functions.
+ void tap_to_click(bool enabled);
+ bool tap_to_click() const;
As above, although I feel less strongly about this particular pattern, so not blocking.
+ void scroll_
+ MirTouchPadScro
+ void scroll_mode(int scroll_button);
... but this is just confusing. The first overload scroll_mode() sets the scroll mode but the second overload adds to it (and changes the button scroll mode), so these are different operations and the functions should be named differently.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2989
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2990
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Alan Griffiths (alan-griffiths) wrote : | # |
+<<<<<<< TREE
class PointerSettings;
class TouchpadSettings;
+=======
+class PointerConfigur
+class TouchpadConfigu
+>>>>>>> MERGE-SOURCE
Looks like the "criss-cross" merge with the pre-req has confused LP.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2991
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Andreas Pokorny (andreas-pokorny) wrote : | # |
> + virtual void apply_configura
> + virtual void apply_configura
>
> I find it easier to read code when the functions are not overloaded in this
> way, but have unique names instead, e.g.:
>
> apply_pointer_
> apply_touchpad_
>
> I think if functions are performing different operations they should be named
> differently. We should only use overloading for functions that perform the
> same operation but need different arguments.
But in both cases I only apply that configuration. I mean this is the same operation just different arguments.
> [...]
> + void scroll_
> + MirTouchPadScro
> + void scroll_mode(int scroll_button);
>
> ... but this is just confusing. The first overload scroll_mode() sets the
> scroll mode but the second overload adds to it (and changes the button scroll
> mode), so these are different operations and the functions should be named
> differently.
Ok I aggree this is confusing..
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2992
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
FAILURE: http://
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Alexandros Frantzis (afrantzis) wrote : | # |
+ virtual void apply_configura
+ virtual void apply_configura
I still think that these are different operations and deserve different names for clarity, but it's not a blocker.
Looks good otherwise.
| Alan Griffiths (alan-griffiths) wrote : | # |
+ virtual mir::optional_
+ virtual void apply_configura
+
+ virtual mir::optional_
+ virtual void apply_configura
There's unnecessary asymmetry between XXX_configuration() and apply_configura
If we're calling something "XXX_configuration" then it should be "apply_
Looks good otherwise.
| Andreas Pokorny (andreas-pokorny) wrote : | # |
ok followed your suggestions
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2993
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
FAILURE: http://
SUCCESS: http://
deb: http://
None: http://
SUCCESS: http://
deb: http://
FAILURE: http://
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Chris Halse Rogers (raof) wrote : | # |
Nit:
88 + * - [-1, 0): reduced acceleration
89 + * - (0, 1]: increased acceleration
Is how that would be usually written.
=========
Strangeness:
struct TouchpadConfigu
struct PointerConfigur
Why do these have all the getter/setter infrastructure? We don't do any input validation, so they're just extra boilerplate?
If they *had* input validation then I'd probably make them class TouchpadConfigu
==========
774 + .WillByDefault(
This looks wrong? Did you mean to OR mi::DeviceCapab
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2993
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Alberto Aguirre (albaguirre) wrote : | # |
"Why do these have all the getter/setter infrastructure? We don't do any input validation, so they're just extra boilerplate?"
+1. having getters/setters here doesn't buy you much. If ABI is a concern, you would have to go full PIMPL.
Further comments inlined.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2997
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
FAILURE: http://
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Andreas Pokorny (andreas-pokorny) wrote : | # |
@AlbertA: ack inline comments should be addressed.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2998
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Chris Halse Rogers (raof) wrote : | # |
My concerns are addressed. You might want to add a test that attempting to set invalid values throws, but I won't block for that.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Autolanding.
More details in the following jenkins job:
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
FAILURE: http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Autolanding.
More details in the following jenkins job:
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
FAILURE: http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Autolanding.
More details in the following jenkins job:
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
FAILURE: http://

FAILED: Continuous integration, rev:2984 jenkins. qa.ubuntu. com/job/ mir-ci/ 5221/ jenkins. qa.ubuntu. com/job/ mir-android- vivid-i386- build/4383 jenkins. qa.ubuntu. com/job/ mir-clang- vivid-amd64- build/3290 jenkins. qa.ubuntu. com/job/ mir-mediumtests -vivid- touch/4325/ console jenkins. qa.ubuntu. com/job/ mir-mediumtests -wily-touch/ 283/console jenkins. qa.ubuntu. com/job/ mir-wily- amd64-ci/ 1375 jenkins. qa.ubuntu. com/job/ mir-wily- amd64-ci/ 1375/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ mir-wily- i386-ci/ 283/console jenkins. qa.ubuntu. com/job/ mir-mediumtests -builder- vivid-armhf/ 4326 jenkins. qa.ubuntu. com/job/ mir-mediumtests -builder- vivid-armhf/ 4326/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ mir-mediumtests -runner- touch/6977/ console s-jenkins. ubuntu- ci:8080/ job/touch- flash-device/ 24110 jenkins. qa.ubuntu. com/job/ mir-mediumtests -builder- wily-armhf/ 284/console
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
FAILURE: http://
SUCCESS: http://
deb: http://
FAILURE: http://
SUCCESS: http://
deb: http://
FAILURE: http://
SUCCESS: http://
FAILURE: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/mir- ci/5221/ rebuild
http://