maemo.org Bugzilla – Full Text Bug Listing
|Summary:||Volume buttons should be swapped when using the phone in portrait mode.|
|Product:||[Maemo Official Applications] Chat & Call & SMS||Reporter:||Edgardo Calabrese <eddo>|
|Status:||CLOSED FIXED||QA Contact:||communication-bugs|
|Priority:||High||CC:||andre_klapper, AntiSpammoni, maemo, markuspublic, mikhail.zabaluev, spenna, tigro.mails|
SOFTWARE VERSION: (Settings > General > About product) 5.0/ 1.2009.42-11 EXACT STEPS LEADING TO PROBLEM: Just use the phone in portrait mode. EXPECTED OUTCOME: As usual, the volume + button should be the one in the higher position, and the V- should be the one in the lower position, as happen in almost any phone ACTUAL OUTCOME: The volume + have the same function in any orientation, this lead in the expected behavior in landscape but not in portrait REPRODUCIBILITY: (always) EXTRA SOFTWARE INSTALLED: OTHER COMMENTS: Not a biggie but if we want a production level device we have to fix even this type of inconsistence. User-Agent: Opera/9.80 (Windows NT 6.1; U; it) Presto/2.2.15 Version/10.10
(In reply to comment #0) > EXPECTED OUTCOME: > > As usual, the volume + button should be the one in the higher position Thanks for the report, but I can't reproduce the problem. The above is exactly what happens here with the same version, and in fact there was bug 5897 requesting the opposite which was closed WONTFIX. When you are testing this, does the phone application really switch to portrait mode?
> Thanks for the report, but I can't reproduce the problem. The above is exactly > what happens here with the same version, and in fact there was bug 5897 > requesting the opposite which was closed WONTFIX. > > When you are testing this, does the phone application really switch to portrait > mode? > I did some further tests, and I noticed that the problem is not always present. I'm still trying to figure what triggers the bug. (noticed by me and by a friend of mine on two different phones). I suspect that this only happens answering to a call, and not when the call is originated from the n900, but I'm really not shure. All I can say is that I saw the bar going up (with the expected key) and suddenly starting to going down. (with the phone still vertical, and with the rest of UI stable in portrait mode.) Thanks for Your reply and sorry for the not completely correct description in the first message.
*** This bug has been confirmed by popular vote. ***
The behavior is improved in a software update, let's see if it solves this case.
Reflecting the internal severity and prioritization.
This has been fixed in package maemo-statusmenu-volume 0.43+0m5 which is part of the internal build version 2.2009.46-2 (Note: 2009 is the year, and the number after is the week.) A future public update released with the year/week later than this internal build version will include the fix. (This is not always already the next public update.) Please verify that this new version fixes the bug by marking this bug report as VERIFIED after the public update has been released and if you have some time. To answer popular followup questions: * Nokia does not announce release dates of public updates in advance. * There is currently no access to these internal, non-public build versions. A Brainstorm proposal to change this exists at http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
The problem reported here should be fixed in the update released today for public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes). Please leave a comment if the problem is not fixed for you in this update version.
(In reply to comment #7) > The problem reported here should be fixed in the update released today for > public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes). > Please leave a comment if the problem is not fixed for you in this update > version. > It seems that it is ok now. In landscape: volume UP with right volume key In portrait: volume UP with left (upper) volume key Thanks!
*** Bug 8500 has been marked as a duplicate of this bug. ***
Verifying and closing.