These files use TABs for indentation, so the standard check doesn't work
for them (and it doesn't seem worth having a special check just for
them neither, so simply don't check them at all).
Remove this bundle key from the generic Info.plist files as it's not
really useful there because none of our samples except "internat" is
localized.
So just add a special Info.plist for this sample and add values
corresponding to all the languages for which we have translations to its
CFBundleLocalizations.
The documented name of the bundle version variable has BUNDLE twice, see
https://cmake.org/cmake/help/latest/prop_tgt/MACOSX_BUNDLE_INFO_PLIST.html
and samples/Info.plist.in uses this variable, but we set
MACOSX_BUNDLE_VERSION instead, which seems wrong, so use the apparently
correct variable name instead.
Also update inc_year script to update them automatically the next time,
to prevent them from becoming 3 (for one, or 13 for the other one) years
out of date again.
Don't use CFBundleSignature, it was only needed for Classic Mac OS
compatibility. Similarly, LSRequiresCarbon was used to distinguish the
"new" Carbon applications from the Classic ones and is not needed any
longer.
CSResourcesFileMapped might still be used, but it's just an optimization
and we don't need it and it's just a s gratuitous difference with the
template used by Xcode, so remove it too.
Just put the keys in the same order as the one used in Xcode template
and samples/minimal/Info_cocoa.plist based on it (which is almost
alphabetical order, except for LSMinimumSystemVersion which comes after
NSPrincipalClass at the very end for whatever reason).
No real changes.
This was removed in 415f080c80 (Split wxGrid RANGE_SELECT event into
SELECTING and SELECTED, 2020-07-27) without preserving it for
compatibility. Do define it now, just as it was done for the non-CMD
equivalent of this macro EVT_GRID_RANGE_SELECT.
Also update the documentation to fix a typo from e2f316b19d (Mention
that wxEVT_GRID_RANGE_SELECT{ED,ING} are new in 3.1.5, 2020-08-18).
Use -1, not 0, for the not-yet-computed value. Prevents CPU-intensive
recomputation when the calculated size _is_ zero - e.g. because the
column is hidden.
No real changes: In wxImage::Rotate() don't needlessly wxRound numbers
that are already whole after having called ceil/floor.
Occurred since inception in 7a632f1056 (Added rotation to wxImage,
2000-02-06).
See https://github.com/wxWidgets/wxWidgets/pull/2460
Under at least some versions of Windows 10 with wxDVC themed text can be
clipped horizontally because of discrepancies between the text extent
as drawn by DrawThemeTextEx() and calculated with GetTextExtent()
earlier.
Work around the issue by always trying to use GetThemeTextExtent() in
DrawItemText(), not just for alignment of multi-line strings, and adjust
for any width differences similar to the existing adjustment for height.
See #18487.
Change wxGCDCImpl::DoGetTextExtent() from rounding to the nearest
integer to rounding up: if e.g. height is 15.3 then 16 pixels should be
used for height, and not 15. Rounding was previously improved from
casting (which appears to be the initial code) in 0417955ddb (adding
correct filling area to arc, correct rounding and clipping, 2007-10-21).
Issues with nearest rounding became more visible after off-by-one fixes
for wxDC::DrawLabel() with wxALIGN_RIGHT and wxALIGN_BOTTOM positioning.
When using e.g. wxALIGN_RIGHT with a width of 72.4 the text could now be
drawn beyond the extent on the right because the text is not offset by
one to the left any longer.
Revert e2e7d3d391 (Fix wxELLIPSIZE_END with wxALIGN_RIGHT in wxMSW
wxDataViewCtrl, 2016-03-18). This fix is no longer needed after
the previous commit reverted b642747fd2.
Reverting also allows for text to be drawn vertically aligned again
instead of always using top-left alignment. While the difference in
appearance by not having alignment can be minor with default row
heights, it becomes more noticeable with taller rows:
a wxDataViewCheckIconText column with a tall icon will have its text
stuck to the top of a row while other columns have their text vertically
centered. This already occurs by default when not explicitly specifying
an alignment (wxDVR_DEFAULT_ALIGNMENT) which results in
wxALIGN_CENTRE_VERTICAL being used for row alignment when rendering.
Revert b642747fd2 (Fix right aligned text position in wxDVC on MSW with
system theme, 2015-09-30) which in wxRendererXP::DrawItemText() mimicks
the off-by-one with right alignment of wxDC::DrawLabel() that got fixed
by the previous commit.
There's not a similar change copying wxDC::DrawLabel()'s former
off-by-one behaviour with wxALIGN_BOTTOM that would need reverting.
Both alignments now result in the same text positioning with both
drawing functions.
wxDC::DrawLabel() positions the text one to the left with wxALIGN_RIGHT
alignment and one up with wxALIGN_BOTTOM alignment. The same occurs in
wxControlRenderer::DrawBitmap() for bitmaps. Both off-by-ones exist
since inception in respectively 4d3c4c2f94 and bc60c3d699.
This fix vertically aligns wxALIGN_BOTTOM drawing of wxDC::DrawLabel()
with themed text drawing through wxRendererXP::DrawItemText().
When using non-TOP vertical alignment with wxRendererXP::DrawItemText()
either DT_VCENTER or DT_BOTTOM gets passed to DrawThemeTextEx() but
without the DT_SINGLELINE flag which is required for those alignment
flags to take effect, resulting in text always being top aligned.
Fix by passing DT_SINGLELINE when using either alignment, but only for
single lines as multi-lines are rendered as a single line with invisible
newline character. Draw multi-line text using top alignment and deal
with vertical alignment ourselves, using GetThemeTextExtent() to get
an accurate extent of the text.
Comment in wxRendererXP::DrawItemText() could be interpreted as
DrawThemeTextEx() being available for some XP editions but it is Vista+
only, so correct it.
This is intended for wxMSW to show differences between themed text
drawing (with wxRendererXP::DrawItemText() under Vista+) and
wxRendererGeneric::DrawItemText(). Use existing option to switch between
generic and native renderer (Ctrl-G) in the render sample to observe
the differences.
Some generic render functions aren't implemented and result in obtrusive
assert failures when switching to use the generic renderer in the render
sample. Instead show text saying the drawing function is not implemented
in the location where the sample would ordinarily draw the control.
To more easily expose problems add options to the dataview sample
related to rendering of items (applying mostly to the MyListModel page
only):
* Use left/centre/right alignment (Ctrl+1/2/3)
* Use top/centre/bottom alignment (Ctrl+4/5/6)
* Toggle tall row usage (Ctrl+7)
* Toggle keep on using small wx logo, regardless of row size (Ctrl+8)
* Toggle multi-line text usage (Ctrl+9)
For debugging convenience define DEBUG_RENDER_EXTENTS to draw a red
rectangle around a custom rendered cell's full rectangle, and a green
rect for the extent of the item appearing inside it. Custom renderers
ordinarily should not draw outside of the green rect. A notable
exception is drawn text, particularly multi-line ones.
