The default window width of the initial Gramps startup need to be a bit wider. (And being a bit taller would eliminate scrolling in Navigator bar. 823x670 would be large enough)
It crops off the right edge of the Welcome! gramplet in column 2. Probably would have had enough room if it the Navigator sidebar did not have titles.
Our UI style guide states that Gramps should be usable, but not look its best, on a 800x600 resolution.
We should probably keep the initial application window size to 800x600 or slightly less.
I’d agree with that if some of the new Preferences tabs hadn’t violated the spirit of the guideline.
I can quess a reason Gramps adopted that guideline… discovered that many VMs create 800x600 virtual screens. So sticking with 800x600 simplifies testing using VMs.
However, on the flipside, if the windows size saved in .ini files exceeds the screensize then Gramps automatically drops down to fit. So we could abandon that guideline if VMs are the gating factor.
But that would beg the question, do the Gramps screensize detection routines see the VM size? … or the physical device size?
Which tabs are you talking about?
The actual size of a dialog will depend on the font size used and the language. It seems to me that most of our windows are no bigger than 800x600.
Do not forget that the default window size is also done using the default font.
Segue UI with the default size 9.
No wonder that Gramps makes my eyes hurt. Modern GUI design for websites calls for 16px defaults. That’s 12pt. 9pt is only 75% of normal size. (It is very aggravating that Notes use a hardcoded base font size. Changing font sizes in Themes has no affect in them.)
| Points | Pixels | Ems | Percent |
|---|---|---|---|
| 6pt | 8px | 0.5em | 50% |
| 7pt | 9px | 0.55em | 55% |
| 7.5pt | 10px | 0.625em | 62.5% |
| 8pt | 11px | 0.7em | 70% |
| 9pt | 12px | 0.75em | 75% |
| 10pt | 13px | 0.8em | 80% |
| 10.5pt | 14px | 0.875em | 87.5% |
| 11pt | 15px | 0.95em | 95% |
| 12pt | 16px | 1em | 100% |
| 13pt | 17px | 1.05em | 105% |
| 13.5pt | 18px | 1.125em | 112.5% |
| 14pt | 19px | 1.2em | 120% |
| 14.5pt | 20px | 1.25em | 125% |
| 15pt | 21px | 1.3em | 130% |
| 16pt | 22px | 1.4em | 140% |
| 17pt | 23px | 1.45em | 145% |
| 18pt | 24px | 1.5em | 150% |
Had to finish re-flushing the laptop computer and re-installing yesterday’s AIO zip.
First, the whole Preferences dialog is significantly larger than the 800x600 compliant application window. And the 1st tab “Data” has the whole “Input options” and “*Requires Restart” off the bottom of the dialog with a narrow (almost unnoticeable) vertical scrollbar. (scrollbar added PR#1525)
The “Colors” tab scrolls too… but who cares about the colors tab? It is ignored by almost every feature that could leverage it. And swatches are a horrible interface for tweaking more than 1 color too. If the Tags used that color palette (instead all Black) or the pin Config colors for the “All Known Places” geography view (instead of all Green), then deficiencies in its use might matter to someone.
Using scrollbars is OK. That clearly falls within the definition of being usable, but not looking its best.
I’m getting a size of 670x700. I’ll see if I can reduce the height a little.
On a fresh install of Windows (complete reformat and re-install, nothing added but AIO64-5.2.0-r1-d4de8fb), the default size of preferences was 918x772
I’ve added some more scrollbars and can now get 760x540 with an 11 point font.
oooh… this is an interesting Windows idiosyncrasy. This Thinkpad T740 has a default screen resolution of 1920x1080. Under Windows 10 Pro, the settings default to scaling apps by 150%.
So I set that to 100% and the defaults changed. Evidently, it interacts with hardware setting in the OS to choose defaults? And the Dashboard fit better. (Even though needing a magnifying glass to use.)
The Main went to 777x532 and the Preferences to 702x667
Can you make the scrollbars wider? They are wide enough to notice during rollover but the way they go narrow then disappear entirely (if the mouse is outside the dialog, or, after the pointer stops moving for 2 seconds) makes the awareness that there are additional Preference options too hidden.
Or maybe that is a themes change?
The size, color, etc of a scrollbar are controlled by your theme.
Then I am looking forward to things slowing down enough to begin exploring the CSS overlay that Nick mentioned a few weeks ago.
is there a PR that can be references to close this thread?
It was fixed in commit 69a0593 - Add more scrollbars to the Preferences dialog.
