Closed Bug 433001 Opened 11 years ago Closed 3 years ago

Base default Mail & Newsgroup window size on available screen size

Categories

(SeaMonkey :: MailNews: Message Display, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.46

People

(Reporter: kairo, Assigned: rsx11m.pub)

References

Details

Attachments

(1 file, 2 obsolete files)

For bug 432740, I'm making the SeaMonkey browser window set up its default size dynamically, based on the screen size.

A similar solution would probably be nice for SeaMonkey's main mailnews window.
Possibly, as mentioned in bug 432740 comment #14, we could autoswitch to vertical layout for wide screens as well in that code.
OS: Linux → All
QA Contact: message-display
Depends on: 1272888
Would be nice, but in contrast to the browser window (which is the first window a new user sees), the Mail & News window opens on top of it as a secondary window. Thus, it probably shouldn't cover the browser window entirely. As detailed in bug 1272888, with Lightning now enabled by default per bug 516026, a minimum width of about 900-1000px is required to accommodate the additional Lightning features.

Thus a possible algorithm might follow these rules:

 - Calculate a fraction (e.g., two thirds) of the window height and width as preferred dimensions;
 - if these value(s) are below the minimum established sizes, set the latter as height and/or width;
 - if after that the sizes exceed the physical screen dimension(s), set those as height and/or width.
Assignee: mail → rsx11m.pub
Status: NEW → ASSIGNED
Summary: make default mail window size dynamic → Base default Mail & Newsgroup window size on available screen size
Further thinking:

(In reply to Robert Kaiser from comment #0)
> Possibly, as mentioned in bug 432740 comment #14, we could autoswitch to
> vertical layout for wide screens as well in that code.

I'm not convinced that this is a good idea. Along the same lines, you could argue that users should be switched automatically into the "wide" mode for narrow screens, thus increasing the horizontal space available for the message preview pane at the cost of the folder pane. This may be confusing for users setting up multiple instances on machines with different screen geometries, where the layout may differ substantially between installations.

This opens up the question of course what to do with a high-resolution 21:9 monitor, where taking 2/3rds of the width on initial opening may seem substantial (the browser window takes up half only if the screen width is more than 1440px). I could restrict the window ratio to 16:9 to compensate for that, but the rules are getting a bit complicated. The minimum size (2nd item in the comment #1 list) should probably match a 1024x768 screen, which would result in a 1000x720 window given the padding used for bug 983689, ensuring that all items are visible (including the Lightning additions).
> I could restrict the window ratio to 16:9 to compensate for that,

Looks like I'm overthinking this a bit. Making the default Mail & News width 1/2 of the screen width while retaining the 2/3 default height (min. 720px) should solve it without introducing that special case. With the minimum width being 1000px, this would only become relevant on screens with >2048px width anyway, then leading to the window covering horizontally about the same as the default browser window (for which 1/2 width is triggered at that size as well). So, that should work.
Attached patch Proposed patch (obsolete) — Splinter Review
This should be the last installment regarding window sizes on my to-do list.

The patch follows what was outlined in comment #1 and comment #3:

 - For screens between 1024x768 and 2048x1152, the desired initial size of the
   Mail & News window is 1000x720 (outer width for Windows but inner width for
   Linux due to bug 581863/bug 581866); this fits main toolbar and Lightning.

 - For screens wider than 2048 pixels or higher than 1152 pixels, half of the
   size is used for the width and two-thirds of the height, respectively.

 - For screens smaller than 1024 pixels in width or 768 pixels in height, the
   available screen size is used less 24px in width and 48px in height for
   padding (and to account for window decoration on Linux).

I've left the starting corner of (10,10) unchanged as an offset to the browser window is desirable. Window sizes and padding have been established while working on bug 1272888 and bug 983689, respectively.

Note that bug 432740 for the main (browser) window added a special treatment for Linux by accounting explicitly for an average height of the decoration, and also introduced special cases on small screens to maximize the window. I didn't implement any of those as the aim here is not to allow for the maximal opening size but to find a "nice" of the Mail & News window to open for the first time when it's on top of the browser window. Thus, keeping it simple enough as possible seems to be a good approach.

Since this is replacing "em" units with "px" I've also tested 125% (and 150%) display modes on Windows, where the window opens 1250px (and 1500px) wide as desired, screen size permitting. Also, the desktop taskbar is excluded from the available height on both Windows and Linux, so that's considered as well.
Attachment #8759421 - Flags: ui-review?(philip.chee)
Attachment #8759421 - Flags: review?(iann_bugzilla)
> +    if (defaultHeight < minHeight)
> +       defaultHeight = minHeight > screenHeight ? screenHeight : minHeight;
> +    if (defaultWidth < minWidth)
> +       defaultWidth = minWidth > screenWidth ? screenWidth : minWidth;
You can probably use Math.min(minHeight, screenHeight)
Now do I test this?
How? On Windows 7, Control Panel > Display > Screen Resolution, then switch through the settings.

If you don't have a screen > 2048x1152, just modify minHeight and/or minWidth to see if the "large" settings are properly applied (or change the 1/2 and 2/3 ratios to something you can observe).

(In reply to Philip Chee from comment #5)
> You can probably use Math.min(minHeight, screenHeight)

Thanks, I'll give that a try (pending any other remarks you may have on the current patch).
(In reply to rsx11m from comment #7)
> switch through the settings.

using a new profile for every test, given that height and width persist (that part hasn't changed).
Attached patch Proposed patch (v2) (obsolete) — Splinter Review
(In reply to Philip Chee from comment #5)
> You can probably use Math.min(minHeight, screenHeight)

Ok, this works.
Attachment #8759421 - Attachment is obsolete: true
Attachment #8759421 - Flags: ui-review?(philip.chee)
Attachment #8759421 - Flags: review?(iann_bugzilla)
Attachment #8760030 - Flags: ui-review?(philip.chee)
Attachment #8760030 - Flags: review?(iann_bugzilla)
Comment on attachment 8760030 [details] [diff] [review]
Proposed patch (v2)

r=me a=me

> +    let defaultHeight = screenHeight * 2 / 3;
> +    let defaultWidth  = screenWidth / 2;
While on the subject you might want to use Math.floor() here.

xulstore.json:
"messengerWindow":{"screenX":"10","screenY":"10","width":"1000","height":"692","sizemode":"normal"}

screenHeight = window.screen.availHeight =  740
screenWidth  = window.screen.availWidth  = 1366

defaultHeight:  740 * 2 / 3 = 493.333333333333333333333333333333333333333
defaultWidth : 1366 / 2     = 683

const minHeight = 768;
const minWidth = 1024;

dh = 48
dw = 24

defaultHeight = Math.min( 740,  768) - dh =  740 - 48 =  692
defaultWidth  = Math.min(1366, 1024) - dw = 1024 - 24 = 1000
Attachment #8760030 - Flags: ui-review?(philip.chee)
Attachment #8760030 - Flags: ui-review+
Attachment #8760030 - Flags: review?(iann_bugzilla)
Attachment #8760030 - Flags: review+
Thanks, pushed as http://hg.mozilla.org/comm-central/rev/9c6b3837eb83 with Math.floor() applied.
Attachment #8760030 - Attachment is obsolete: true
Attachment #8760064 - Flags: ui-review+
Attachment #8760064 - Flags: review+
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.46
You need to log in before you can comment on or make changes to this bug.