lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [PATCH] More XRC fixes, including wxDatePickerCtrl ones


From: Greg Chicares
Subject: Re: [lmi] [PATCH] More XRC fixes, including wxDatePickerCtrl ones
Date: Thu, 16 Apr 2015 23:54:29 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0

On 2015-04-10 18:26, Vadim Zeitlin wrote:
[...eight large but simple patches...]
>  As always, please let me know if you have any questions about these
> patches and thanks in advance for applying them!

I've applied them all in a throwaway VM, and examined the result thus:

/opt/lmi/bin[0]$./lmi_wx_shared --ash_nazg --data_path=/opt/lmi/data 
--pyx=show_mvc_dims

where the last argument displays the dimensions of the MVC tabbed dialog.
At 192 DPI, 'skin.xrc' has grown from 1088x819 to 1169x820, which I think
is due to the prerequisite patch here:
  http://lists.nongnu.org/archive/html/lmi/2015-04/msg00002.html
and in particular to the widening of date-picker controls on the "Inforce"
tab. I don't think the eight later patches had any real effect on the
dimensions, which is good.

I looked at the outcome with 'skin.xrc' at 96 DPI, and everything looks
fine to me. I'm not sure I can even perceive any difference due to these
patches. On the "Inforce" tab, the date-picker controls seem to be about
three pixels wider than the text controls with which they're vertically
aligned; I don't remember whether it was that way without these patches
(and it's been a long time since I tried using a blurry 96 DPI screen for
anything at all, much less lmi). No wx diagnostics appear on the console.
BTW, at 96 DPI, the 'skin.xrc' tabbed dialog is 640x483. That means it
no longer fits the 640x480 screen that ms eliminated with xp, but I
guess I won't worry too much about that.

I realize you're still working on high-DPI enhancements in wx, which is
outside the scope of these patches. But, since I'm looking at it now,
let me describe what I see at 192 DPI. First, these diagnostics appear
on the console:

wxSpinCtrl "SolveBeginYear": initial width 20 is too small, at least 34 pixels 
needed.
wxSpinCtrl "SolveBeginTime": initial width 20 is too small, at least 34 pixels 
needed.
wxSpinCtrl "SolveEndYear": initial width 20 is too small, at least 34 pixels 
needed.
wxSpinCtrl "SolveEndTime": initial width 20 is too small, at least 34 pixels 
needed.
wxSpinCtrl "SolveTargetYear": initial width 20 is too small, at least 34 pixels 
needed.
wxSpinCtrl "SolveTargetTime": initial width 20 is too small, at least 34 pixels 
needed.

Those are the only diagnostics on stderr, despite the anomalies below,
so I guess WXXRC's built-in diagnostics are not yet as complete as they
possibly could be.

Some radioboxes seem slightly too narrow, causing text truncation, e.g.:
  "Month by mont" missing final "h"
  "Survive to life expectanc" missing final "y"
But perhaps it's not just a problem with the dimensions of the surrounding
group box, because "( ) Net rate   ( ) Gross rat" is missing a final "e"
even though there's abundant empty space in the right end of the group box.

Some comboboxes are way too narrow: e.g., "Premium tax state" has only
four horizontal pixels for displaying text, which isn't enough for even
a single character.

On the "Inforce" tab, I was surprised to see that the date-picker controls
are about twice as wide as the text controls with which they're vertically
aligned. Surprised, because they were almost the same width at 96 DPI.
Looking at the source, which I believe has all patches applied (e.g., for
'skin.xrc', 118 sections differ from HEAD), I see:
                                    
<flag>wxGROW|wxALIGN_CENTER_VERTICAL|wxRIGHT</flag>
                                    <object class="wxTextCtrl" 
name="ContractNumber">
                                        <help>Contract number</help>
                                        <size>80,-1</size>
                                        <value>0</value>
                                    </object>
Didn't you intend to change every occurrence of "<size>80,-1</size>",
at least to remove the "-1"? Have I missed a patch?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]