Unary minus of wxPoint and multiplication with double are implemented
but undocumented. Many of operators that use integers types other
than int remain undocumented though.
The arithmetic operators for wxPoint and wxRealPoint are quite
repetitive and were made by copy-paste from the wxSize operators.
Because of that, some of the names are a bit misleading which this
commit changes. The changes are:
1. replace s/sz with p/pt for point variables (likely 's' comes from
copied code used for wxSize variables)
2. replace 'i' with 'f' for floating point types (likely 'i' comes
from copied code used for integer types)
3. replace 'factor' with 'divisor' for division operations (factors
are the multiplication operands, not division)
Do this for consistency with wxSize which already had this operator/()
overload and operator*() in these classes which was already overloaded
for double.
Closes#24185.
Closes#24187.
Use the correct types instead of wxSize which was erroneously used
there ever since a5664fd6ef (Increase interoperability between wxPoint
and wxRealPoint introducing constructors which convert between the two
classes., 2010-06-09).
Closes#23804.
Override required functions in wxHeaderCtrlSimple to avoid asserts if
its columns are reordered.
Also bring the code behaviour in agreement with the documentation by
calling UpdateColumn() after calling UpdateColumnVisibility().
Finally, only call UpdateColumnsOrder() if the corresponding event was
not processed as the application should use one xor the other mechanism
for reacting to columns reordering, but not both.
Closes#24108.
Closes#24172.
Use the same argument name as in the actual code in the class
constructor as well as the convenience function, instead of
wrongly copypasted "book".
See also 33de6dc (Fix confusing wxPersistentTLW ctor argument name,
2023-12-22).
Closes#24158.
Missing semicolon on latest method addition causes doxygen parsing
issues which in turn causes problems for dependent projects like wxRuby
and wxPython.
Closes#24155.
This code was already used for Ctrl-C handling, refactor it into a
separate function that can be called from the application now.
This commit is best viewed with --color-moved-ws=ignore-all-space Git
option.
Closes#24124.
This includes a static function to calculate Easter that can be used for
other authorities.
Document the wxDateTimeWorkDays and wxDateTimeHolidayAuthority classes.
Closes#24094.
This allows user codes to simply designate where their controls should
appear in the status bar without the need to handle wxEVT_SIZE
themselves.
They can still handle the event if the default positioning does not meet
their needs, but the new API is simpler and can be implemented for wxQt.
Closes#24092.
Without this change, using wxEL_ALLOW_NEW without wxEL_ALLOW_EDIT
resulted in an assertion failure, so fix it by turning wxEL_ALLOW_EDIT
too in this case: this makes sense because adding a new element is
"editing" too, and there doesn't seem to be any realistic scenario in
which new items can be added but the existing items can't be changed.
Closes#24099.
Closes#24100.
It was incorrectly called wxAppConsole::YieldFor() but the function was
moved from wxAppConsole to wxEventLoopBase back in dde19c2180 (second
part of #10320: move wxApp event handling functions to wxEventLoopBase
(in particular move Yield() functions); add backward compatible
redirections to wxApp; update docs; remove global lists wxPendingEvents
and wxPendingEventsLocker, 2009-02-15).
Closes#24095.
Replace user-specified empty constructors and destructors with the
compiler-generated versions, which has a number of advantages for code
generation, in addition to being more clear.
Closes#22965.
Closes#24058.
Refactor wxImageList and convert it to use physical pixels and
add support for high DPI state images wxTreeCtrl using the new
wxImageList.
See #24000, #24033.
Just check if the scale factor has changed when getting a "configure"
event for a TLW as we're guaranteed to get one when the scale factor
does change, according to GTK documentation (and it does seem to work).
Closes#19290.
Don't mention thoroughly outdated desktop environments such as Gnome 1
and don't make this X-specific as the situation is not at all better
with Wayland.
Do mention IsAvailable().
See #18081.
Closes#24028.
This seems to be the only way to fix using this class, which is
fundamentally incompatible with high DPI support, with bitmaps of
different logical but identical physical sizes.
By using physical size we ensure that the code chopping up the provided
bitmap in multiple images doesn't do it with the bitmap having the same
physical size but a different logical size from all the other bitmaps.
And, conceptually, logical size of the bitmaps in it really shouldn't
matter to the image list as it doesn't have a scaling factor and so
can't do anything useful with the logical size.
Moreover, we can't add wxImageList::SetScaleFactor() neither because
this class is, by design, supposed to be shareable between different
controls which may use different scale factors, so it doesn't make sense
to speak of the scale factor of the image list itself.
This undoes the changes made in the generic implementation back in
c374eefd34 (Fold wxOSX-specific wxImageList into generic version,
2018-10-30) and also eb52e86553 (Take into account scale factor of
images added to wxImageList, 2021-04-03).
Also update a couple of places where wxImageList is still used to use
physical sizes. Unfortunately some others can't be easily fixed, e.g.
global wxFileIconsTable would have to be completely rewritten.
Finally, add a unit test checking that things work as expected now:
previously the size of 24x24 bitmap in the image list containing
(scaled) 32x32 bitmaps would be 21x21 due to sub-bitmap extraction
kicking in.
Closes#23994.
Add these functions for consistency with SetStateImages() and to avoid
using GetStateImageList() in the treectrl sample, which can now use
GetStateImageCount() instead.
Unlike the existing SetStateImageList() function, the new one allows to
provide the high-resolution versions of the state images too.
Update the treectrl sample to use the new API.
Closes#23993.
