Re: [lmi] [PATCH] Don't hard code explicit wxDatePickerCtrl size

[Vadim Zeitlin]

On Mon, 26 Jan 2015 03:52:40 +0000 Greg Chicares <address@hidden> wrote:

GC> I'll send screenshots by personal mail showing why this change seems
GC> unfavorable to me. With this change, I see "2015-01-26" with enough
GC> blank space to the right for approximately three more characters.

 There are 2 issues here: first one is this blank space and the second, and
IMO worse, one is that the date picker is wider than the other (text) fields.

 The first issue only arises under Windows XP, i.e. it's not present under
Windows 7 (see lmi_win7.png), even when classic themes are used (see
lmi_win7_classic.png). Unfortunately XP doesn't provide a way to query the
control for its preferred best size, so we use our own approximation which
can't be absolutely precise because we just don't know how big the control
really is and so it errs on the side of being larger as it's a lesser evil
than truncating the control contents. However it arguably errs too much, so
I've reduced the extra space being added by half now in r78417 (see
https://github.com/wxWidgets/wxWidgets/commit/a3747ac9599b6d2b0121b7ef89c698d6d3dff7dc)
and this should be fixed now, please let me know if you still see the
problem with the latest wxWidgets.

 The second issue is, however, still present. The right thing to do to fix
it would be to use wxEXPAND sizer flag to let all the items in the column
take as much space as the widest of them. Unfortunately right now wxEXPAND
would also expand the text controls in the vertical direction, so to make
this work exactly like right now more changes would be needed, but they're
not that complex and, perhaps, wxEXPAND is going to change in wxWidgets
soon (see http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/161320).


GC> I understand that a case can be made for using whatever date format
GC> end users prefer,

 IMO it certainly can and should, but this is not about just this. Even
with the default date format hardcoding the control size is very wrong as
can be seen by what happens (again, with default format!) when using 150%
scaling factor (known as "Large Fonts" under Windows XP) in Windows, which
is rather common, and all but mandatory on higher resolution screens (where
the resolution can even be 200 DPI i.e. what Windows calls 200%), just look
at the attached lmi_large_fonts.png. This display is just broken, and not
only for the date picker control, notice how the text controls are only
wide enough for maybe 3 digits but no more.


GC> but if we do that, then there's no reasonable
GC> limit that we can rely on, so an automatically-sized date control
GC> can become arbitrarily wide. For example, if I set the msw short
GC> date format to "dddd, MMMM dd, yyyy", then I see only "Monday" and
GC> a comma in the control without this patch, to which I say: DDTT.

 Sure. But you can't say this to the users who don't have eagle perfect
eyesight to use the notebooks with native 3840*2160 pixels resolution
without scaling.


GC> The layout of lmi input skins has always assumed that the width of
GC> each field is under our control. Changing that may require extensive
GC> changes that I'd rather not contemplate--for example, on the "Inforce"
GC> tab of file 'skin.xrc', which mixes date and text controls in a three-
GC> column array, all controls in the same column having the same width.

 Yes, this definitely should be preserved. But it just means that all these
controls should have the same but appropriate width.


 Would you accept a patch adding wxEXPAND to all the controls in the same
column as wxDatePickerCtrl in all the skins? I really think that it's
pretty important to fix this, the display using higher DPI is IMNSHO
completely unacceptable and you will run into some users who use lmi in
such configurations sooner or later, even if you hadn't encountered them
yet.

 Thanks,
VZ