465319 - Show Short Version of Navigation Pane String for small resolutions

Status: RESOLVED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Christian Jansen]

The strings of the Navigation Pane need be displayed shortened, if screen does not allow to display the long version.

Comment 1

[Stefan Sitter [:ssitter]]

Attachment: screenshot of size issues

This screenshot shows the size issues in Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1b2pre) Gecko/20081118 Calendar/1.0pre.

For correct display a screen width of at least 1400 pixel is now required for correct view, at 1200 pixel the navigation header is hidden and the view gets truncated.

Some space could be gained by shortening the translation or using abbreviations. This might work for some but not for all localizations.

But there are almost 350 pixel wasted by empty space on the tabs itself. This useless space should be reduced to the absolute minimum. Instead of e.g.
[     Day View     ][     Week View     ] it should be [Day View][Week View].

Another possibility for gaining space should be an option (userChrome.css, advanced config) to display only the corresponding icon on the tab instead of text.

Comment 2

[Pete Riley]

(In reply to comment #1)
> Instead of e.g.
> [     Day View     ][     Week View     ] it should be [Day View][Week View].

Or even [Day] [Week].


> Another possibility for gaining space should be an option (userChrome.css,
> advanced config) to display only the corresponding icon on the tab instead of
> text.

And please let us completely remove the buttons that we'll never use (Day and Week in my case).  I could remove the buttons when they were in the main toolbar, now I can't (as far as I know).

Comment 4

[Stefan Sitter [:ssitter]]

Attachment: minimize empty space in tabs

Instead of using the tabs title character count for calculating the min-width this patch does the following: It applies the selected style (bold font) to the tab and uses the resulting width as min-width. See screenshot for improvements.

Comment 5

[Stefan Sitter [:ssitter]]

Attachment: screenshot with applied patch

Comment 6

[Berend Cornelius]

Comment on attachment 357221 [details] [diff] [review]
minimize empty space in tabs

I am really sorry to deny this review, but the problem with it is that -at least under Linux - it simply does not have any effect at all: By the time the nagivation bar is loaded no layout information is available - If you print the value of node.boxObject.width to the errorconsole than you can see that the width is "0". I can say that this problem caused me a lot of headache; that's why we came up with the solution of deriving the width from the number of characters of the label. I should probably also add that one of Christian's "no-compromise" demand was that the tabs are not supposed to 'jump' when being activated.

Comment 7

[Berend Cornelius]

@Pete: With the fix of  Bug 468420 -  Consolidation of the navigation bar it is now quite easy to hide the tab buttons that are not needed within your personal userChrome.css file. I tested this. The ids of the tab-buttons are:

-calendar-day-view-button
-calendar-week-view-button
-calendar-multiweek-view-button
-calendar-month-view-button

Comment 8

[Stefan Sitter [:ssitter]]

(In reply to comment #6)
I think I reproduced your issue. It works fine in Sunbird but fails in Lightning. Could be related to the visibility of the views. In Sunbird they are visible after startup, in Thunderbird they are hidden.

Would you accept a patch that does the same as the patch above but uses the string length fallback if width is zero? This would fix Sunbird at least.

Or maybe the setting of the min-width could be moved to a different time or location that ensures it is run after layout?

Comment 9

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

A very bright idea bz just gave me!!! We use a similar technique elsewhere:

Create a stack/deck and put two <label> elements in it. One is the view label in normal font weight, the other is the view label but in font-weight bold.

All non-selected views apply the style "visibility: hidden" to the bold label, the selected view does the same for the non-bold label.

This way we have the smallest width possible. I tried this in xuledit with a stack and it seems to work great!

Comment 10

[Berend Cornelius]

in reply to comment #8:
Maybe we could set the min-width on the onResize event and remove the listener as soon as the min-width is determined.
But of course your proposed solution is better than none.
in reply to comment #9:
The idea with the deck also came to my mind but the problem is how do you integrate the deck in the tab button? As far as I remember there is no easy way to achieve this - the tab button does not provide a <children> tag for this.

Comment 11

[Berend Cornelius]

>Maybe we could set the min-width on the onResize event and remove the listener
>as soon as the min-width is determined.
I think there was a problem with this solution, too: When the layout is determined (as during "onResize" the "min-width" attribute is ignored.

Comment 12

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

(In reply to comment #10)
> The idea with the deck also came to my mind but the problem is how do you
> integrate the deck in the tab button? As far as I remember there is no easy way
> to achieve this - the tab button does not provide a <children> tag for this.
I think bz's idea is the best thing we can do. I'd even suggest creating a binding that extends a xul:tab, I think thats still more elegant than any js code that executes in handlers and such.

Comment 13

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Use stack - v1

This patch uses a stack. I'm not sure I removed all traces of the js code to set the widths, but I'll leave this to the reviewer.

Comment 14

[Berend Cornelius]

Comment on attachment 358596 [details] [diff] [review]
Use stack - v1

Good patch! By keeping the type of the tab controls as they are you made sure the code won't break within their containers where the type - and its localName - is hardwired to "tab" at several places. XBL is really powerful once you know how to use it.
r=berend

Comment 15

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/5c3bf02af6b3>

-> FIXED

Comment 16

[Pete Riley]

(In reply to comment #7)
> @Pete: With the fix of Bug 468420 [...]
> it's now quite easy to hide the tab buttons that are not needed
> within your userChrome.css file.
> 
> -calendar-day-view-button
> -calendar-week-view-button
> -calendar-multiweek-view-button
> -calendar-month-view-button

Berend, it works great.  Thank you.

(I just started using 1.0pre instead of 0.9.)