No real changes, just write a single check for "dc == nullptr" instead
of doing it twice in combination with preprocessor checks.
This commit is best viewed with Git --color-moved option.
There is no longer a QtGetContainer() function name. wxQtEventForwarder was renamed
to wxQtEventSignalHandler. And QtGetScrollBarContainer() was just removed in previous
commits.
Because It is simpler to initialize (the inherited) m_qtContainer member
directly in derived classes during construction process, and make the API
a little bit cleaner.
Neither QListWidget nor QTextEdit derive from QScrollArea and the cast to it is
just UB. Instead, using the common base class QAbstractScrollArea is safer and
eliminates the need to these dangerous and insidious crosscast'ings.
There's really no need to make the wxFrame itself scrollable as it unnecessarily
complicates the implementation and introduces annoying bugs like content shifted
by 1px. Moreover, the scrolling logic is already encapsulated in other widgets
like wxScrolledWindow which can be used as a hosting container in the frame to
handle scrolling.
This makes behaviour more consistent across all platforms, as this flag
is always used in wxGTK and wxOSX, and might avoid some problems in
wxMSW, see #23982.
For the toolbars locked in one direction there is no need to compute the
hint size in the other one, so don't bother calling RealizeHelper() for
the non-current orientation in this case.
This is just a small optimization.
No real changes, just remove a duplicate call to wxSizer::SetDimension()
too and call it only once.
Also add some comments to explain what's going on here.
This is unnecessary and resulted in sometimes visible flicker, when the
wrong shape of the toolbar could be temporarily seen on screen before it
was replaced with the correct one.
Only set the actual window size in Realize(), and do it only for the
current orientation, instead of doing it in RealizeHelper() which is
called for both the current orientation and the transversal one.
Closes#24023.
Using "argc" and "argv" for parameter names triggers C4458 with MSVS
2022, warning about hiding class members with the same names.
As we can't rename the latter, rename the parameters to avoid this.
This makes the code more readable and also simpler as RealizeHelper()
only used its boolean parameter to convert it to wxOrientation anyhow
after the changes of the parent commit.
No real changes.
There is no need to test for the orientation explicitly, as we can just
call AddSpacer() and pass it the spacer size in the direction of the
sizer (which is what we always need).
No real changes, just make the code simpler and nicer to read.
This function used to return bool, but it didn't just always return
true, but it's not even clear how could it possibly fail in theory, so
this was quite useless.
But Realize() itself used GetSize() after each call to RealizeHelper(),
so just make RealizeHelper() itself return this size, which allows to
shorten the code and get rid of a couple of levels of indentation.
No real changes.
This doesn't really change anything because the only existing caller of
SetOrientation() already called Realize() immediately afterwards anyhow
but it seems more logical to do it from SetOrientation() itself, as it
always needs to be done when the orientation changes.
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.
This test doesn't use the native header but somehow still fails on
AppVeyor and locally a very failure can be reproduced if the mouse is
moved while the test runs, so check for this here too.
No real changes, just replace GetEventHandler()->ProcessEvent() with the
calls to this function, which does exactly the same thing, but is
shorter and more clear.
This was only used under Mac but defined under all platforms.
Don't bother with defining it elsewhere and just use a trivial empty
lambda as wxEVT_ACTIVATE handler under Mac.
Note that it's not really clear if this is still needed neither, but it
doesn't cost much to keep this workaround just in case it is.
This does work, contrary to the comment saying that it doesn't: it must
have been when cf6fec73d7 (wxaui flags reworked a bit; allows any
hinting type to be explicity invoked; turning off hinting completely is
not possible; sample updated accordingly, 2006-10-26) was done, but not
any longer.
No real changes, just simplify the code.
Instead of checking for all the other platforms, just check for non-Mac
as the code in this branch should work (and definitely should compile)
in any port and it's just wxOSX which requires special handling here.
This fixes the build under the other platforms (e.g. wxX11) broken by
the changes of e8a6f3b732 (Use wxSYS_COLOUR_HOTLIGHT for hint background
under Mac too, 2023-12-24).
Using 5ms delay for the fade in timer and 4 point increment for the
value running from 0 to 50 meant that the entire fade in took 60ms which
wasn't really noticeable, i.e. couldn't be distinguished from not using
fade in at all.
Increase the delay to 15ms (which corresponds to ~60 FPS) and make the
animation last longer by increasing the transparency more progressively
to make the fade in actually visible.
In the future we probably ought to make all the values involved
(animation duration, initial and end values and the step) configurable
by adding some SetHintFadeInOptions() to wxAuiManager.
