[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] [PATCH] Don't hard code explicit wxDatePickerCtrl size
From: |
Vadim Zeitlin |
Subject: |
Re: [lmi] [PATCH] Don't hard code explicit wxDatePickerCtrl size |
Date: |
Sun, 1 Feb 2015 12:07:48 +0100 |
On Sat, 31 Jan 2015 19:52:25 +0000 Greg Chicares <address@hidden> wrote:
GC> > GC> Now I apply this patch:
GC> > GC> http://lists.nongnu.org/archive/html/lmi/2015-01/msg00028.html
GC> > GC> 0001-Remove-explicit-sizes-from-wxDatePickerCtrl-in-the-r.patch
GC> > GC> and the date controls are wide enough. Actually, as I believe you
noted earlier,
GC> > GC> they're wider than necessary--there's room for an extra '1' on the
end:
GC> > GC> 01/31/20151
GC> >
GC> > Hmm, we should be able to get this exactly right in wxGTK as it uses the
GC> > generic version, so everything is under our control. OTOH, being slightly
GC> > too wide is not that catastrophic, especially as opposed to not being wide
GC> > enough.
GC>
GC> True, but why not make it perfect?
Sure, >> TODO.
GC> That's encouraging, but I still get the same error with lmi:
GC>
GC> /opt/lmi/build[0]$LC_TIME="en_DK"
LD_LIBRARY_PATH=/usr/local/lib:/opt/lmi/local/lib ./lmi_wx --ash_nazg
GC> locale::facet::_S_create_c_locale name not valid
GC>
GC> That would appear to be a libstdc++ issue.
I think it's a Boost.Filesystem one, see
https://svn.boost.org/trac/boost/ticket/4688
If I understand this bug correctly, it should be possible to work around
this by using en_DK.UTF-8 explicitly here instead of just en_DK. But I
haven't had time to actually test this yet, will do a.s.a.p.
GC> > GC> Anyway, there are many other issues:
GC> > GC> - Numeric textcontrols on "Inforce" tab (e.g.) are not wide enough.
GC> >
GC> > This is almost certainly due to hardcoding their width to 80 pixels.
GC>
GC> Yes, of course. That's under my control. I just won't have the time to
GC> address all of this soon: doing it carefully takes a lot of work.
Should I try to propose a patch fixing this?
GC> Are you saying that keyboard handling:
GC> (1) is less polished in wxGTK than in wxMSW, which is remediable; or
GC> (2) is less polished in GTK+ than in MSW, which is not?
A mix of both I'm afraid. I really need to test how things work in GTK+ 3
though, there have been a lot of changes there and things might be better
there.
GC> > GC> - I like the narrow pull-down-arrow button on the date control better
GC> > GC> than the enormous one on comboboxes; is that customizable? As it
GC> > GC> stands, comboboxes for state and country aren't wide enough to show
GC> > GC> any text.
GC> >
GC> > Hmm, this is probably theme-dependent, I don't have any especially
GC> > enormous buttons in the comboboxes. Maybe they are twice larger than
GC> > necessary because of the scaling? Then it would be something to fix in
GC> > wxGTK... Could you please send me a screenshot privately so that I
GC> > understand better what's going on here?
GC>
GC> Sent.
Thanks, this is definitely wrong. It is not encouraging that the native
GTK+ combobox drop down buttons look wrong while the generic wxComboPopup
button looks much better :-(
GC> > GC> - Help | About text is as narrow as a newspaper column.
GC> > GC> - Nothing on the "Window" menu works.
GC> >
GC> > I have no immediate ideas about either of those :-( I could debug them if
GC> > you'd like to, of course.
GC>
GC> Yes, I think that's a good idea--if it can happen with debian, then
GC> we can't be sure it won't happen with something like msw-10, or any
GC> version of msw with 192 DPI on a high-resolution screen.
>> TODO.
GC> /opt/lmi/wx-scratch[1]$rm -rf *
GC> zsh: sure you want to delete all the files in /opt/lmi/wx-scratch [yn]? y
Please notice that this is not the right way to clean things because it
leaves .deps and .pch subdirectories. It doesn't matter in this particular
case because configure caches its results in the non-hidden config.cache
file, but generally speaking you really need to "rm -rf" the directory
itself. Or "make -s clean", which does take care of the stuff in .deps and
.pch too (but doesn't affect config.cache).
GC> /opt/lmi/wx-scratch[0]$ls
GC> /opt/lmi/wx-scratch[0]$/opt/lmi/wxWidgets/configure --with-gtk3
--enable-std_string --disable-threads --disable-apple_ieee --without-libjpeg
--without-libtiff --disable-gif --enable-stl --disable-joystick
--prefix=/opt/lmi/local >log 2>&1
Sorry, I totally failed to notice it the last time, but the option is
wrong: it should be "--with-gtk=3". As unknown --with and --enable options
are ignored by configure by design, this went unnoticed but GTK+ 2 was
still the default.
Unfortunately there doesn't seem to be much we can do about it, according
to http://www.hep.by/gnu/autoconf/Option-Checking.html it is mostly under
user control, e.g. you could do this:
% $wx/configure --enable-option-checking=fatal --with-gtk3
configure: error: unrecognized options: --with-gtk3
GC> /opt/lmi/wx-scratch[0]$grep -i gtk log
GC> checking for toolkit... gtk
GC> checking for --without-gtkprint... no
GC> checking for GTK+ version...
GC> checking for GTK+ - version >= 2.6.0... yes (version 2.24.10)
FWIW the output I get here (Debian Wheezy) is:
checking for GTK+ version...
checking for pkg-config... /usr/bin/pkg-config
checking for GTK+ - version >= 3.0.0... yes (version 3.4.2)
Sorry again for previously missing this mistake and wasting your time,
VZ
- Re: [lmi] [PATCH] Don't hard code explicit wxDatePickerCtrl size,
Vadim Zeitlin <=