kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

There may be an abuse of sizers that's making it _actually exceed_ the
display size, but I'm pretty confident that there's no way a sizer could
programmatically pick the "best" size for something like that. At best
it could make it not overflow the screen...but the sizer doesn't know
how much information is ideal to display at once. It's hard enough for a
human to pick, I was bouncing between several different systems with
different display configurations and all three OSes trying to choose
some of those...

On Sun, Jan 07, 2018 at 09:07:14PM +0000, Wayne Stambaugh wrote:
> Got it.  Thanks for the explanation.  Even on my systems on the edit
> LIB_ID dialog was always the entire height of the display.  It seems
> strange that wxWidgets wouldn't clamp the height to something less than
> the maximum display height.  I'm wondering if we aren't using some
> setting in the sizers that is causing this.
> 
> On 01/07/2018 04:02 PM, Chris Pavlina wrote:
> > Consider a dialog whose only contents are a list box. How would the
> > sizers pick a size for that? It depends on how much data you want the
> > list to show at once. By default, they'll pick a size that fits ALL the
> > data, as you can see in [1] -- I had to fix that because it literally
> > exceeds the entire size of my display. For dialogs where the contents is
> > highly variable, like lists, we need to provide a hint as to what the
> > size should be. This is why several of the dialogs use a fixed pixel
> > size in seeming violation of the UI policy, and why I've been changing
> > those to use dialog units.
> > 
> > [1] https://git.launchpad.net/kicad/commit/?id=e971b0e698b20b9d43ce28a2b2eb9905bf5c7694
> > 
> > On Sun, Jan 07, 2018 at 08:22:10PM +0000, Wayne Stambaugh wrote:
> >> Hey Chris,
> >>
> >> Since I don't have a HiDPI system to test with, I just want to be sure I
> >> understand this.  Are you saying that even when the dialog size is -1,
> >> -1 which forces the sizers to do their thing that they dialogs do not
> >> get sized properly on HiDPI displays even after controls are filled with
> >> valid data?  One of the issues that I ran into on standard display
> >> resolutions is that quite a few of our dialogs were created with fixed
> >> sizes which can break the normal dialog sizing so I fixed all of the
> >> offending dialogs so they should resize correctly.  I'm a bit concerned
> >> about any code that sets the dialog size rather than allowing the sizers
> >> to determine the dialog size from the contents of the dialog which is
> >> the normal way.  Is this a problem with wxWidget sizers?  If so, has it
> >> be already been resolve?
> >>
> >> Cheers
> >>
> >> Wayne
> >>
> >> On 01/07/2018 02:19 AM, Chris Pavlina wrote:
> >>> Hi,
> >>>
> >>> There is a slight deficiency in our UI policy, as it is written without
> >>> regard to systems having different font sizes or DPI. The sentence
> >>> beginning with "Note that the font used by end users" is a nod to this
> >>> possibility, but it requires the user to set their font size in a
> >>> certain way to have decent dialog sizes, which worked in the past
> >>> because nobody was going around running their systems with 18 point
> >>> fonts. With the increasing popularity of displays having physical
> >>> resolutions much higher than the old standard of 96 DPI, this is
> >>> becoming an unreasonable assumption.
> >>>
> >>> I've attached a patch with a paragraph addressing the use of "dialog
> >>> units" (wx's device-independent units) for setting the default size of
> >>> dialogs for which the sizers alone do not suffice. I believe this is
> >>> ready for inclusion, though there should probably be some discussion
> >>> here and it's not complete. In paricular, the next paragraph (about the
> >>> maximum size of 1024x768) is very "96 DPI-centric" and should probably
> >>> be totally rewritten, but I'm not entirely sure how.
> >>>
> >>> For simplicity, here's the paragraph the patch adds:
> >>>
> >>>     Note that for dialogs with flexible contents (lists, text, etc), the
> >>>     sizers may not be able to produce a reasonable initial size, because
> >>>     they don't know how much data should be shown by default. For this,
> >>>     there is `DIALOG_SHIM::SetSizeInDU()`, which uses device-independent
> >>>     "dialog units" based on the system font size (a wxWidgets feature
> >>>     borrowed from Windows).  Do not set the size directly in pixels, as
> >>>     it is unlikely to be suitable for systems with different font sizes
> >>>     or DPI.
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp