[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] [PATCH] Don't hard code explicit wxDatePickerCtrl size
From: |
Greg Chicares |
Subject: |
Re: [lmi] [PATCH] Don't hard code explicit wxDatePickerCtrl size |
Date: |
Mon, 26 Jan 2015 03:52:40 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 |
On 01/24/2015 10:27 PM, Vadim Zeitlin wrote:
>
> I've somehow forgotten to submit this relatively big but very simple patch
> which removes the hardcoded sizes of wxDatePickerCtrl from the XRC files.
> The immediate reason for this is that this size is too small on my system/
> for my date-time format ("%d.%b.%y") and so the control is very
> user-unfriendly as it doesn't show the year, which is truncated, by
> default. More globally, using hardcoded sizes in pixels is not only bad
> (because of the problems such as this which are all but inevitable when
> using the program on more than one platform and difficult to avoid even on
> a single one), but also unnecessary, so there is really no valid reason to
> keep them.
I'll send screenshots by personal mail showing why this change seems
unfavorable to me. With this change, I see "2015-01-26" with enough
blank space to the right for approximately three more characters.
I understand that a case can be made for using whatever date format
end users prefer, but if we do that, then there's no reasonable
limit that we can rely on, so an automatically-sized date control
can become arbitrarily wide. For example, if I set the msw short
date format to "dddd, MMMM dd, yyyy", then I see only "Monday" and
a comma in the control without this patch, to which I say: DDTT.
The layout of lmi input skins has always assumed that the width of
each field is under our control. Changing that may require extensive
changes that I'd rather not contemplate--for example, on the "Inforce"
tab of file 'skin.xrc', which mixes date and text controls in a three-
column array, all controls in the same column having the same width.
I don't want to destroy the same-width property: that'd be ugly. We
could move the date controls out of those columns, but that would
destroy the internal logic of the layout.
Perhaps we should just force "yyyy-MM-dd" for consistency. Of course,
I'm an ideologue, and if it were up to me I'd impose the metric system
on everyone. Do note that lmi's GUI already disregards user formats
for currency and numbers. BTW, when I enter credit-card information
online, I'm forced to pick a two-digit month and a two-digit year--so
I think people are accustomed to having a format imposed upon them
for data entry. Sometimes I must give my telephone number as simply
8005551212; other input forms force me to enter (800) 555-1212; and
I recently had to fill in 800.555.1212 somewhere.
PDF output is different: there, I see "January 26, 2015", with numbers
formatted according to the convention of the only country where lmi
is used--and that's all as it should be.
- [lmi] [PATCH] Don't hard code explicit wxDatePickerCtrl size, Vadim Zeitlin, 2015/01/24
- Re: [lmi] [PATCH] Don't hard code explicit wxDatePickerCtrl size,
Greg Chicares <=
- Re: [lmi] [PATCH] Don't hard code explicit wxDatePickerCtrl size, Vadim Zeitlin, 2015/01/26
- Re: [lmi] [PATCH] Don't hard code explicit wxDatePickerCtrl size, Greg Chicares, 2015/01/26
- Re: [lmi] [PATCH] Don't hard code explicit wxDatePickerCtrl size, Vadim Zeitlin, 2015/01/26
- Re: [lmi] [PATCH] Don't hard code explicit wxDatePickerCtrl size, Greg Chicares, 2015/01/29
- Re: [lmi] [PATCH] Don't hard code explicit wxDatePickerCtrl size, Vadim Zeitlin, 2015/01/29
- Re: [lmi] [PATCH] Don't hard code explicit wxDatePickerCtrl size, Greg Chicares, 2015/01/31
- Re: [lmi] [PATCH] Don't hard code explicit wxDatePickerCtrl size, Vadim Zeitlin, 2015/01/31
- Re: [lmi] [PATCH] Don't hard code explicit wxDatePickerCtrl size, Greg Chicares, 2015/01/31