Use print() and byte strings to make the code compatible with Python 3,
while also keeping it compatible with Python 2 (>= 2.6, at least).
Closes https://github.com/wxWidgets/wxWidgets/pull/1348
Under wxGTK, wxGauge was returning fixed values for height and width.
This meant that the gauge would not center correctly in a sizer,
particularly under GTK+ 3 where the default gauge height is just a few
pixels.
Following this change, wxGauge renders correctly on GTK+ 3 and matches
the reference widget display in the gtk3-widget-factory app.
Note, this change will also result in a slimmer widget on GTK+ 2, but
the gauge height can be forced using wxGauge::SetMinSize() on the older
toolkit.
The gauge presentation is totally theme dependent under GTK+ 3. For
example, the user can have thicker gauges by setting the following in
their ~/.config/gtk-3.0/gtk.css file:
progress, trough {
min-height: 20px;
}
Closes https://github.com/wxWidgets/wxWidgets/pull/1353
A number of object files in wxCore can end up being empty due to the
corresponding wxUSE_XXX options being set to 0. This is normal and
getting tons of warnings from MSVC during the build about it wasn't
helpful.
It turns out that these warnings can be suppressed by using the
undocumented, but described at
http://www.geoffchappell.com/studies/msvc/link/link/options/ignore.htm
"/ignore" option, so do this to finally get a clean build.
Ellipsization code was completely broken when used with the usual
control label strings containing mnemonics: it simply stripped the
mnemonics completely, losing them even if the label wasn't actually
ellipsized, and turned "&&" into a mnemonic. I.e. "&Plug && play"
appeared without underlined "P" but with underlined space before "play"
before.
Fix this by pretending that all ampersands in the string to be
ellipsized have zero width. This is not precise, as the result of
GetPartialTextExtents() for a string with the ampersands is not exactly
the same as the sum of its result for the string without the ampersands
and the width of the ampersands themselves, but it should be pretty
close and unlikely to result in any problems in practice for the
controls labels.
At the very least this fixes the completely wrong behaviour of the
controls on the "Static" page of the widgets sample, where ellipsization
is enabled by default and setting the label text with mnemonics didn't
work at all.
When processing mnemonics, the resulting string should still contain
them and they need to be stripped before measuring its width, but the
code didn't do it.
This didn't prevent the tests from passing, but only due to another bug
in ellipsization code itself, which lost the mnemonics completely. As
this bug is about to be fixed, the test needs to take mnemonics into
account properly now.
The code was confusing as it used Bind() for some handlers, event table
for some others and, for the 3 buttons in the middle column, it actually
managed to use both.
Get rid of the event table completely to make this more clear.
This resulted in wrong letter being underlined in wxGenericStaticText
when the mnemonic occurred after "&&" (i.e. an actual ampersand) in the
label.
Add unit test which passes now, but would fail before on the last check.
Clicking on the "Generic wxStaticText" box resulted in several
assertions because the markup string contained both a single "&" and
a "&" used for the mnemonic. Double the former to avoid misinterpreting
it as a mnemonic character too.
Also remove the macros used in the test to perform the same tests for
wxStaticText and wxCheckBox and use a helper function instead, making
the code more clear and extensible.
No real changes.
The names of these methods were confusing because they implied that they
were the actual implementations of the public [SG]etLabel(), while this
wasn't at all the case.
Give them then ames describing what they really do and also update the
comments to hopefully be more clear.
No real changes.
Fix bug introduced by the (relatively) recent wxJoystick rewrite: using
"!m_buttons" is wrong as it always returns 0 for any button(s) but the
first one, we need bit-wise "~m_buttons" here instead.
See https://github.com/wxWidgets/wxWidgets/pull/942
See #1142.
Combination of multiple borders looks bad, so skip drawing the left/top
borders in wxGrid{Row,Col,Corner}LabelWindow if wxGrid already has a
border around it.
Grid contents was drawn in grey colour instead of the usual active one
when it was disabled, but the row and column labels kept their default
appearance, which looked out of place.
Fix this by greying them out too. This should have been arguably done in
73145b0ed1 ~17 years ago, but better late
than never.
Don't assume that m_findIter is always valid initially, i.e. after
FindFirst() is called, as this is not the case if the memory FS is
empty, i.e. which no files had been added to it yet.
This also allows to simplify the iteration logic, as we don't need to
check m_findArgument (which, in turn, obviates the need to clear it when
we reach the end of the iteration) and can just use m_findIter directly.
Closes#18416.
