Comment 1 Ryan Abel 2009-10-14 20:15:32 UTC

I'm betting that this is, unfortunately, as-intended and thus an enhancement
request, but I'll let somebody from Nokia confirm that.

Comment 2 Andre Klapper 2009-10-14 21:38:33 UTC

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).

Comment 7 Ryan Abel 2009-11-07 16:41:01 UTC

(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?

Comment 9 Andre Klapper 2009-12-01 15:08:36 UTC

*** Bug 6473 has been marked as a duplicate of this bug. ***

Comment 10 Andre Klapper 2009-12-15 15:00:16 UTC

This is actually part of
http://maemo.org/community/brainstorm/view/add_universal_support_for_asr-automatic_screen_rotation-throughout_the_ui-002/

(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.

Comment 13 Andre Klapper 2009-12-28 14:05:08 UTC

(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.

Comment 16 Andre Klapper 2009-12-30 20:53:47 UTC

*** Bug 7503 has been marked as a duplicate of this bug. ***

*** Bug 9096 has been marked as a duplicate of this bug. ***

Comment 18 Andre Klapper 2010-03-02 21:45:02 UTC

Closing as FIXED for PR1.2 (the next public update).

Comment 19 Andre Klapper 2010-03-15 20:53:44 UTC

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.

Comment 21 Andre Klapper 2010-06-07 11:36:55 UTC

Reopening.

Comment 22 Andre Klapper 2010-06-07 11:45:43 UTC

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.

Comment 24 Eero Tamminen 2010-07-15 16:11:58 UTC

> 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?

Comment 25 Andre Klapper 2010-07-15 16:38:38 UTC

(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?

Comment 26 Andre Klapper 2012-03-24 11:39:59 UTC

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] )