Merge lp:~diwic/unity-settings-daemon/what-did-you-plug-in into lp:unity-settings-daemon
| Status: | Merged |
|---|---|
| Approved by: | Sebastien Bacher on 2014-02-18 |
| Approved revision: | 4015 |
| Merged at revision: | 4014 |
| Proposed branch: | lp:~diwic/unity-settings-daemon/what-did-you-plug-in |
| Merge into: | lp:unity-settings-daemon |
| Diff against target: |
685 lines (+534/-1) 10 files modified
configure.ac (+1/-1) debian/control (+1/-0) plugins/media-keys/Makefile.am (+4/-0) plugins/media-keys/gsd-media-keys-manager.c (+80/-0) plugins/media-keys/gvc/gvc-mixer-control.c (+13/-0) plugins/media-keys/what-did-you-plug-in/dialog-window.c (+130/-0) plugins/media-keys/what-did-you-plug-in/dialog-window.h (+18/-0) plugins/media-keys/what-did-you-plug-in/pa-backend.c (+264/-0) plugins/media-keys/what-did-you-plug-in/pa-backend.h (+22/-0) po/POTFILES.in (+1/-0) |
| To merge this branch: | bzr merge lp:~diwic/unity-settings-daemon/what-did-you-plug-in |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| PS Jenkins bot | continuous-integration | 2014-02-18 | Approve on 2014-02-18 |
| Sebastien Bacher | 2014-02-18 | Approve on 2014-02-18 | |
| Matthew Paul Thomas | design | 2014-02-18 | Pending |
|
Review via email:
|
|||
This proposal supersedes a proposal from 2014-02-15.
Commit Message
Handle unknown audio jack devices
Description of the Change
Hi,
Here comes the implementation of the "what did you plug in"-dialog for 14.04. While I'd like some more real-world testing before the actual merge happens (I can see to that), in parallel it would be good with some code focused review so I don't spend time polishing things if there's something with the design that you think is bad.
| David Henningsson (diwic) wrote : | # |
| Sebastien Bacher (seb128) wrote : | # |
@David: can you resubmit it (top right corner of the launchpad page) and change the target vcs to lp:~ubuntu-desktop/gnome-settings-daemon/ubuntu?
| David Henningsson (diwic) wrote : | # |
Sure, done now. I notice that a new version of g-s-d was released in parallel, but hopefully that won't stop you from looking at the code - I can rebase it on top of the latest g-s-d when we feel ready quality wise.
| David Henningsson (diwic) wrote : | # |
Btw, I chose to implement it in the media-keys plugin instead of making a new plugin, mostly for efficiency reasons: no need to have two different connections to PulseAudio constantly up, and I save some code because I don't have to reimplement stuff like reconnecting on PA restart and such.
| Sebastien Bacher (seb128) wrote : | # |
Thanks for the work David, some questions/comments:
- is there any easy way to test that? I've tried plugging headphones/a microphone on my laptop but that doesn't trigger the dialog, not sure if you can easily emulate the unknown case? Having a way to display the UI at least would be nice
- we started the transition to unity-settings-
- could you explain a bit what the code does? I tried to look at bit at the logic but I don't really know pulseaudio and things like "snd_ctl_
- pa-backend.h has commented functions, do you plan to add those back/use them? if not could you delete the lines rather than commenting them?
- > if (system(
better to cal "unity-
- > d->settings_btn = gtk_button_
can you replace the "..." by a their utf8 variant "…"?
- the design has a checkbox to store the choice, do you plan to add that?
- you need to list the new sources in po/POTFILES.in so the translatable strings are included in the translation template
| Sebastien Bacher (seb128) wrote : | # |
I've tweaked the source to run the UI, some extra comments:
- the "What kind of device did you plug in?" label is centered in the design and left aligned on your version
- the spacing between the Cancel/Sound Settings buttons is non standard
| David Henningsson (diwic) wrote : | # |
Hi Seb, thanks for your review! Just a few question before I start fixing the things you said:
> - is there any easy way to test that? I've tried plugging headphones/a microphone on my laptop but that doesn't
> trigger the dialog, not sure if you can easily emulate the unknown case? Having a way to display the UI at least
> would be nice
Do you think adding a local "#define DIALOGTEST" (that would pop up the dialog on any plug in or so) would do? Or do you want something that can be runtime enabled through some switch?
> - we started the transition to unity-settings-
> patch there, it's full source)
Sure, is it https:/
> - the design has a checkbox to store the choice, do you plan to add that?
Because it requires significant additional coding (mostly in sound settings, where you need to be able to revert back to "please ask me"), I was thinking of deferring it to the next cycle, where things have to be rewritten for Qt anyway. Also, this checkbox was not present in the wireframe we got from the design team at one point, so I figured it would be a nice-to-have rather than an absolute requirement. Is that okay with you?
| Sebastien Bacher (seb128) wrote : | # |
> Do you think adding a local "#define DIALOGTEST" (that would pop up the dialog on any plug in or so) would do? Or do you want something that can be runtime enabled through some switch?
That would be useful, but feel free to skip over that. I basically hacked dialog-window.c to add a main() with gtk_init/
> Sure, is it https:/
It moved teams for acl reasons, it's now https:/
> Because it requires significant additional coding (mostly in sound settings, where you need to be able to revert back to "please ask me"), I was thinking of deferring it to the next cycle, where things have to be rewritten for Qt anyway. Also, this checkbox was not present in the wireframe we got from the design team at one point, so I figured it would be a nice-to-have rather than an absolute requirement. Is that okay with you?
That seems reasonable to me as well, yes.
| David Henningsson (diwic) wrote : | # |
Here comes the new merge proposal. Changes since previous version:
> - is there any easy way to test that? I've tried plugging headphones/a microphone on my laptop but that doesn't trigger the dialog, not sure if you can easily emulate the unknown case? Having a way to display the UI at least would be nice
See the TEST_WDYPI_DIALOG define in gsd-media-
> - we started the transition to unity-settings-
Fixed
> - could you explain a bit what the code does? I tried to look at bit at the logic but I don't really know pulseaudio and things like "snd_ctl_
I added two comments with some overview of the detection and port setting mechanism. Is this helpful? If you need additional comments, I'll be happy to add them.
> - pa-backend.h has commented functions, do you plan to add those back/use them? if not could you delete the lines rather than commenting them?
Fixed
> - > if (system(
> better to cal "unity-
Fixed
> - > d->settings_btn = gtk_button_
> can you replace the "..." by a their utf8 variant "…"?
Fixed
> - you need to list the new sources in po/POTFILES.in so the translatable strings are included in the translation template
Fixed, I think (unsure how to test it though)
> - the "What kind of device did you plug in?" label is centered in the design and left aligned on your version
Fixed (design team was inconsistent on this one though)
> - the spacing between the Cancel/Sound Settings buttons is non standard
I changed the spacing, but not sure if it is standard now, because I'm unsure what the standard is.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:4013
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Sebastien Bacher (seb128) wrote : | # |
Thanks for the update!
> See the TEST_WDYPI_DIALOG define in gsd-media-
You use the on_wdypi_popup() before it's defined which leads to a build error, once that resolved it seems to build/work fine though
> I added two comments with some overview of the detection and port setting mechanism. Is this helpful? If you need additional comments, I'll be happy to add them.
Those comments are quite useful indeed, thanks for that!
That seems a bit hackish
" Headphone Mic Jack - indicates headphone and mic-in mode share the same jack,
...
Headset Mic Phantom Jack - indicates headset jack where hardware can not
...
Headset Mic Jack - indicates headset jack where hardware can distinguish
..."
Those names seem like current descriptions from alsa, are we sure the strings are not going to change/be translated/... that seems not a very reliable comparaison? If we don't have a better API I guess it would do the job for a stable serie but we should put some tests in the build to make sure those names keep being current maybe, no?
> I changed the spacing, but not sure if it is standard now, because I'm unsure what the standard is.
The GNOME HIG use 6 pixels steps, I think it's a 6 pixel value button the button
I've done a screenshot and copied it on http://
Otherwise the code looks fine to me, do you want to do extra testing or do you consider it ready to land?
| Matthew Paul Thomas (mpt) wrote : | # |
> I changed the spacing, but not sure if it is standard now, because I'm unsure what the standard is.
a. 6 pixels between the large buttons (Headphones vs. Headset, Headset vs. Microphone)
b. 6 pixels between "Cancel" and "Sound Settings…"
c. 12 pixels between "Cancel"/"Sound Settings…" and the bottom of the window.
Remember too that the dialog should not be resizable, and therefore should not have a Maximize button.
| Sebastien Bacher (seb128) wrote : | # |
One other small issue, with the define set the dialog opens at u-s-d start ... is that supposed to happen? (or should it only react to even?) (said differently, does it mean it's going to prompt at login if you have a such device plugged as well?)
| David Henningsson (diwic) wrote : | # |
> You use the on_wdypi_popup() before it's defined which leads to a build error
Oops, fixed.
> Those names seem like current descriptions from alsa, are we sure the strings are not going to change/be translated/...
They are not translated. They are unlikely to change, and it's what PulseAudio depends on too. But yeah, the discussion comes up every year on the upstream audio miniconf, that there should be some new API with a more structured approach than mathing on names. And the conclusion is that nobody has time to do it, and that the current solution works well enough. Sort of. :-)
> Otherwise the code looks fine to me, do you want to do extra testing or do you consider it ready to land?
I think it's ready to land (will post new merge proposal shortly). Acelan did some testing on real hw a few iterations ago and little has changed since, i e in the detection part.
| David Henningsson (diwic) wrote : | # |
> a. 6 pixels between the large buttons (Headphones vs. Headset, Headset vs. Microphone)
> b. 6 pixels between "Cancel" and "Sound Settings…"
> c. 12 pixels between "Cancel"/"Sound Settings…" and the bottom of the window.
All these three should be fixed now. A little unsure if I at the same time managed to make the distance between the large buttons and the bottom buttons have a few pixels too many...
> Remember too that the dialog should not be resizable, and therefore should not have a Maximize button.
Ok, fixed.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:4015
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Sebastien Bacher (seb128) wrote : | # |
> the current solution works well enough. Sort of. :-)
Ok, that works for me then, thanks for the explanations!
Testing seems fine as well, let's get that in, thanks for the work!
| Sebastien Bacher (seb128) wrote : | # |
(btw no need to resubmit a mp every time you do changes, just push to the branch you have been using, bzr/launchpad handle that fine and pick the new commits/update the merge request page diff and revisions list)


Hrm, looking at the diff below I probably did something wrong, like submitting against the wrong branch or something. Anyway, it's the file debian/ patches/ what-did- you-plug- in.patch in the lp:~diwic/gnome-settings-daemon/what-did-you-plug-in branch that should be looked at.