maemo.org Bugzilla – Full Text Bug Listing
|Summary:||Status menu not available in portrait mode|
|Product:||[Maemo Official Platform] Desktop platform||Reporter:||Lucas Maneos <maemo>|
|Status:||RESOLVED WONTFIX||QA Contact:||home-bugs|
|Priority:||Low||CC:||andre_klapper, eero.tamminen, m, nelson.ferreira, nivw2008, pancake, urho.konttori, xavier.bestel|
SOFTWARE VERSION: 1.2009.41-10 STEPS TO REPRODUCE THE PROBLEM: 1. Start the phone application and go into portrait mode. 2. Tap the status area. EXPECTED OUTCOME: Status menu appears. ACTUAL OUTCOME: Nothing. REPRODUCIBILITY: Always. It works as expected in landscape mode. EXTRA SOFTWARE INSTALLED: OTHER COMMENTS: There should probably be a separate component for this, "Home" just seemed like the closest available.
I'm betting that this is, unfortunately, as-intended and thus an enhancement request, but I'll let somebody from Nokia confirm that.
Yes, this was never planned as the width of the opened statusbar is too wide. Basically the same with the taskswitcher. Might even be a WONTFIX, but feel free to vote. :-/
(In reply to comment #2) > Yes, this was never planned as the width of the opened statusbar is too wide. The obvious solution would be a single-column layout, similar to the application menu. I wonder what happens when the total height of all the applets exceeds the screen height (in either orientation)...
(In reply to comment #3) > I wonder what happens when the total height of all the applets exceeds the > screen height (in either orientation)... To answer my own question, after installing every status applet I could find in extras-devel, connecting USB and a bluetooth headset: It only displays five rows, but can be scrolled to see the rest. So no show-stoppers here so far.
*** Bug 5931 has been marked as a duplicate of this bug. ***
We are working on it. Might be released in first update release (if not, then the second).
(In reply to comment #6) > We are working on it. Might be released in first update release (if not, then > the second). > Care to elaborate on the plan?
What can I do to collaborate?
*** Bug 6473 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > This is actually part of > http://maemo.org/community/brainstorm/view/add_universal_support_for_asr-automatic_screen_rotation-throughout_the_ui-002/ Not quite - the status bar obviously already had a portrait mode, it's just not fully implemented yet. Based on comment 6 & TM this looks assigned internally, so I propose leaving it open here.
fixed and integrated to pr1.2. didnt make it to pr1.1 because of regression in connectivity dialog dpi font size. bug was in gtk. it was fixed but too late to be included in 1.1. so you all will justa have to wait a bit longer. sorry for the delay.
(In reply to comment #12) > because of regression in connectivity dialog dpi font size. For everybody's interest, that's bug 5609.
Well, it's similar, but not the same bug as the above. When we introduced the portrait status bar to the test builds, if you opened the connectivity dialog from the status bar, it was shown with fonts in wrong dpi. Needles to say, that never made it to the build until the font size issue was fixed -> took time, as we thought for a long time it was an X bug and the X guys were too busy on more important things. Anyway, enough internal gossip. This will be available in PR1.2.
(In reply to comment #14) > Anyway, enough internal gossip. Sorry for comment spamming (and not adding anything useful to it), but I just wanted to note that this internal gossip is really helpful for understanding the development and testing process and also understanding why it's being delayed, and will not be fixed in PR1.1. Thanks for providing detailed feedback on the development progress :) I hope this trend of providing more transparency continues throughout the bug tracker for other products/components as well.
*** Bug 7503 has been marked as a duplicate of this bug. ***
*** Bug 9096 has been marked as a duplicate of this bug. ***
Closing as FIXED for PR1.2 (the next public update).
Setting explicit PR1.2 milestone (so it's clearer in which public release the fix will be available to users). Sorry for the bugmail noise (you can filter on this message).
I just tested this on my PR 1.2 and it is NOT FIXED.
Ah, confusion... Title bar menu is FIXED for PR1.2. Statusbar (with the icons and clock) is not fixed and was not meant to be fixed.
(In reply to comment #22) > Title bar menu is FIXED for PR1.2. > Statusbar (with the icons and clock) is not fixed and was not meant to be > fixed. AFAIK there was nothing to be "fixed" for the title bar menu ("AppMenu"), as it worked in portrait mode even before PR1.2 (even in official apps like the Phone app, which has an AppMenu + portrait mode). I'm pretty sure this bug is about the status bar (Battery, Volume, Clock&Alarms, Profile, Internet connection, Bluetooth, Availability, ...) and not the title bar (see comment 14 above). Right now, it works like this: * "Official PR1.2" with hildon-desktop 1:2.2.138-1+0m5: Nothing happens when the status bar is touched * PR1.1, modified by installing hildon-desktop 1:2.2.135-2+0m5 from the PR1.2 SDK: The status menu outline appears shortly in portrait mode (no content), and the screen then switches to landscape mode and shows the status menu. (I'm happy to tell you the versions of other installed packages if hildon-desktop is not the only package involved in the behaviour of the status menu. Just tell me which packages you need the version of.) I'm assuming from this that there has been a fix for this somewhere between PR1.1 and PR1.2, but it hasn't made it into PR1.2. Not knowing the details about the implementation, from the looks of the status menu, it should be no problem to re-arrange the elements in one column instead of two, just like the portrait mode AppMenu is re-arranged, but even the rotation to landscape mode is fine with me. The current situation (nothing happens) is confusing to the user.
> but even the rotation to landscape mode is fine with me. > The current situation (nothing happens) is confusing to the user. Agree (personal opinion). Andre, is there an internal bug about this?
(In reply to comment #24) > Andre, is there an internal bug about this? Originally it was fixed for PR1.2: http://maemo.gitorious.org/fremantle-hildon-desktop/hildon-status-menu/commit/606b2ec41e1f047d6b6e7f74a0424692c1e05b5b I wonder if http://maemo.gitorious.org/fremantle-hildon-desktop/hildon-status-menu/commit/2269d2aa85e71ab23eb77134dce95a83d983a23c was the revert commit?
The Maemo 5 User Interface and Maemo 5 platform components (e.g. libraries) used for the N900 are considered stable by Nokia and it seems that there are no plans for official updates currently, hence nobody plans to work on this enhancement/wishlist request. (And in case you feel like discussing this situation: Nokia Customer Care or http://talk.maemo.org would be the place to do so as you will not reach Nokia officials in this community bugtracker - though all of this is really no news.) Reflecting this status by setting RESOLVED WONTFIX for this enhancement/wishlist request (see https://bugs.maemo.org/page.cgi?id=fields.html#status for status explanations). There is a small chance for issues in those Maemo components that are open source: Contributed patches could be included and made available in the Maemo 5 Community CSSU updates. The Maemo CSSU project is run by a small team of volunteers; see http://wiki.maemo.org/CSSU for more information. So in case that you can provide a patch that fixes the reported problem, please feel encouraged to file a request under https://bugs.maemo.org/enter_bug.cgi?product=Maemo%205%20Community%20SSU . Please note: The Maemo CSSU project is not related in any way to Nokia. ( Tag for mass-deleting bugmail: [cleanup20120324] )