To prevent the changelog file from growing too big, start a new one for
the next release.
Also restore the instructions about updating it from Git notes just
before the release.
Unsurprisingly, this doesn't work at all with CHM, so allow disabling
using the custom theme when doing it by adding more custom variables.
Using (multiple) variables for this is rather ugly, but we already use
them for other options, so it seems better to keep adding them rather
than using some other mechanism.
Adding a different custom header file is even uglier, but it seems to be
the only way to avoid including the theme JS files into CHM.
Import the theme files into a subdirectory without any changes, even not
removing the trailing whitespace, to facilitate updating them in the
future. Do not add the theme as a submodule as it's surprisingly big
(~12MB) and we don't want to spend extra time on cloning it in each of
our CI builds.
Using this theme gives a nicer appearance and supports the often
requested dark mode.
Remove all colour-related options from the existing custom CSS file as
they don't work well in dark mode.
Also switch to using SVGs with transparent background, rather than PNGs,
for the class diagrams, to avoid background colour mismatch in dark
mode.
This fixes the problem with empty descriptions in the annotated class
list and is a prerequisite for using custom CSS theme in the upcoming
commits.
Closes#22288.
Turn off syntax highlighting entirely because using ".xml" here results
in total garbage in output for some reason (while not using any specific
language uses C++ highlighting which is confusing).
We need to pass the physical size, not scaled by DPI, as the "size"
parameter of GetBitmapBundle(), so that a user-defined art provider
could use it to select one of the available bitmap sizes (which will
then be scaled, if necessary, by wxBitmapBundle itself).
This change is not 100% backwards-compatible because, in theory, bitmap
sizes could be specified using dialog units previously, but this is not
supported any more. However in practice this never happened because it
simply doesn't make sense to use dialog units for the bitmap sizes and
it doesn't seem worth complicating the code by adding another XRC type
of "DPI-independent pixels that can be expressed in dialog units",
especially considering that DUs are DPI-dependent by definition.
See #22584.
We probably could change inc_release to do this too, but considering the
frequency of our minor (let alone major) releases, it doesn't seem to be
worth it.
Allow selecting between the "default" and "simple" providers for now, we
might want to extend this to allow user-defined providers in the future.
Closes#22515.
wxOSX doesn't build in 32 bits since quite some time and it doesn't seem
worth fixing this, so just ensure that we give a clear build error in
this case instead of multiple and less clear errors further down the
build process.
Also remove the now unnecessary checks for __LP64__ from wxOSX code.
The old code in wxToolBarBase::AdjustToolBitmapSize() forced the use of
the exact value of the requested bitmap size multiplied by the current
scale factor, which resulted in ugly bitmaps whenever fractional scaling
factor was used. It also used not immediately clear IncTo() call.
Simplify and improve it by handling the cases when we have a requested
bitmap size and we don't have it differently: if we do have it, just use
it directly, but only with an integer scale factor. And if we don't,
then simply use the bitmap size suitable for the current scale factor.
This seems to result in the most expected behaviour and, notably,
doesn't break the toolbar sample where the bitmap size can still be
toggled between small and big bitmaps on both normal and high DPI
monitors.
Also update the documentation: still recommend not to use
SetToolBitmapSize() at all, but don't claim that it forces fractional
scaling, as this is not the case any longer.
3-state checkboxes can have their initial value set to checked
or undetermined -- this adds support for the undetermined
state to the handler (only allowed if the style includes wxCHK_3STATE).
Closes#22468.
The alphabetical order for this handler was wrong, affecting not
only it's placement in the main HTML page, but also the list of
handlers on the right side.
This commit is best viewed with git --color-moved option.
Closes#22478.
This commit fixes a formatting problem with these two files
when built with Doxygen version 1.9.3.
The correct encoding is to escape the quotes and the backslash.
While the older style encoding used to work, it is no longer
supported due to a fix with how a single quote gets handled
by Doxygen. The escaped version works with Doxygen 1.8.17
so this will work fine with the current build version as well as
in more recent versions (tested with 1.9.3).
Closes#22461.
This is just to make all the version information consistent within this
file. This is primarily for properties that were added in a specific
wxWidgets version.
Closes#22456.
Add support for the missing wxBU_NOTEXT style, bitmaps for the other
than default states (pressed, focus, disabled and current) and margins
to wxBitmapXmlHandler.
Note that the images for the other states were previously already
supported by wxBitmapButton XRC handler, but not by the wxBitmap one,
even though both bitmap classes support them.
Closes#22451.
Vadim Zeitlin
Randalphwa
PB
Artur Wieczorek