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

[Greg Chicares]

On 01/26/2015 02:37 PM, Vadim Zeitlin wrote:
> 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).

Okay. We can take another look after these wx shortcomings are addressed.

I would also like to keep the tabbed dialogs small enough to fit on the
screen at 800x600 resolution. At least 'skin.xrc' fits, and that's the one
I customarily use, though I think at least one of the others doesn't. This
is important for myopic users, even if I'm the only one.

> 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.

I think the mailing list stripped your attachments; could you please resend
them directly to my personal account?

This is intriguing, and I'm trying to see it for myself with msw-xp. In
"Display Properties", I select the "Appearance" tab and change "Font Size"
from "Normal" to "Large". This affects only the title bar of lmi's tabbed
dialog, but not the controls.

If I go the the "Settings" tab and click the "Advanced" pushbutton, I have
the default "Normal size (96 DPI)" selected. I can change that to
"Large size (120 DPI)"; is that the setting you have in mind? Let's reboot
the VM and find out...okay, now I look at the "Inforce" tab with 'skin.xrc';
dates show only "2015-01" and numeric fields have room only for "12345678".

> 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.

Okay. I guess I'm not working with the latest technology.

This is very interesting to me because some years ago I tried larger
fonts and found them unworkable--IIRC, especially for web browsing, the
glyphs became larger, but their spacing wasn't adjusted. Clearly something
has changed. Perhaps browsers have improved, or maybe I had made an
infelicitous choice between msw-xp's two font-size options. I might find
this very useful, personally.

> 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.

I guess that's fine with me as long as the tabbed dialog fits on one screen.

>  Would you accept a patch adding wxEXPAND to all the controls in the same
> column as wxDatePickerCtrl in all the skins?

Someday, yes. I really can't give it any priority right now.

> 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.

It could be later rather than sooner: insurance offices tend to use
desktops, with low-priced monitors. But "later" doesn't mean "never".