The most recent form designer, current with the XRC changes added up
through wxWidgets 3.2.0, and also the only tool that creates XRC file(s)
directly instead of requiring cut/paste.
Closes#22709.
This allows to avoid having an untracked file in the repository, so it
doesn't need to be ignored any longer, as it shouldn't exist after a
successful run.
Also output a warning if the log file is not empty, even though the full
dump is only shown in the GitHub workflow file, as when running the
script locally it may be more convenient to examine the log file in some
other way.
It has been a long-time coming, see b95a7c3144 (Allow wxThread::Wait()
and Delete() to block, even under wxMSW., 2011-03-14), but do still
document that it has finally changed.
New version of Doxygen interprets __foo__ as Markdown markup and
consumes the underscores, which mangles the identifier.
Prevent this from happening by escaping the leading underscore for all
occurrences of "__" outside of the code blocks, this seems to be the
least intrusive fix.
See #22671.
It's a bit wasteful to also mention these changes in the Git notes, so
don't do it and just leave a reminder to copy the existing change log
entries from 3.2 branch instead when it's time to release 3.3.0.
When closing the document using wxDocManager::CloseDocument(), which is
what happens when using the standard wxID_CLOSE menu command handler,
OnCloseDocument() was called twice: first when wxDocument::Close() was
called directly from CloseDocument() itself and once again later when it
was implicitly called from DeleteAllViews().
This was unexpected and also resulted in calling DeleteContents() twice,
which is even more so for a function supposed to perform cleanup.
Fix this by not calling Close() itself but instead a new CanClose()
function from CloseDocument() to check whether we can close and then
relying on DeleteAllViews() to actually close the document.
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.
Provide a link to the latest and working version of this file.
See #22590.
Closes#22594.
Co-Authored-By: Maarten Bent <MaartenBent@users.noreply.github.com>
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.
