At least one WM (KDE's KWin) does not generate X11 configure events when dragging
a window using gtk_window_begin_move_drag(). We need the configure events so we
can generate wxMoveEvent, which AUI needs in order to re-attach a floating pane.
This is functionally a revert of b8789b9d6f for backends other than Wayland.
See #18372#18669
wxStaticBox using custom foreground color was drawing text in wrong
place when using DPI scaling due to scaling the various offsets in our
code, even though Windows itself doesn't do it.
Fix this by following what Windows does and not scaling anything.
Closes https://github.com/wxWidgets/wxWidgets/pull/1738
In the port using wxEventLoopManual, such as wxMSW, an idle event
handler calling wxIdleEvent::RequestMore() prevented any queued events
from being handled until the next "real" event (i.e. originating from
the underlying toolkit) was received. This was unexpected and
incompatible with the behaviour of wxGTK, where queued events were still
processed immediately even when RequestMore() was being constantly
called, so change wxEventLoopManual to also give higher priority to
these events by stopping calling ProcessIdle() if a queued event is
available.
Closes#18667.
If wxPG doesn't contain any visible items it's entire area should
be erased so we need to return -1 as a last drawn line index to ensure
that painted area will be clared from 0 y-coordinate.
Closes#18666.
This ensures that the parent frame doesn't close if any of the children
can't be closed and also that all children are closed before the parent
if they do agree to close.
Closes https://github.com/wxWidgets/wxWidgets/pull/1734Closes#15170.
This doesn't work anyhow, so it's better to prevent the code doing this
from compiling instead of getting run-time asserts or worse.
Also simplify construction of these events inside wxWidgets by passing
the window itself to the ctor instead of passing just its ID and calling
SetEventObject() separately later.
For consistency, do the same thing for wxNcPaintEvent too.
This allows to give at least some explanation about why the secrets
can't be stored to the user, e.g. they could search for a message such
as
The name org.freedesktop.secrets was not provided by any .service files
to find out that gnome-keyring package needs to be installed on their
system.
Note that this change means that under Unix an attempt to connect to the
secret service is now made when wxSecretStore is constructed and not
just when it's used for the first time, as before.
There doesn't seem to be any reason to use secret_service_xxx()
functions for Save() and Load(), but use simple API function
secret_password_clearv_sync() for Delete().
Use the equivalent function from the same API layer for it too instead.
Creating wxPaintDC for a window outside of any wxEVT_PAINT handler
already resulted in assert failures and crash due to using the empty
wxDidCreatePaintDC stack, but the assert message was not really clear,
so improve it by stating explicitly that wxPaintDC can only be created
from wxEVT_PAINT handlers.
Also check that wxPaintDC is being created for the correct window: this
wasn't detected at all before, but could still result in a lot of grief,
so check for this too.
Finally, create a new private header with the paint data stack variable
declaration instead of using "extern" to declare it manually in wxDC
code.
This doesn't seem to actually be doing anything useful, as it only
checks that wxPaintDCImpl is not created without creating wxPaintDC
which is impossible to do accidentally anyhow.
This will be replaced by a more useful check in the next commit.
There is a dedicated template class wxD2DResourceHolder<T> to support
managing backend D2D resources and wxD2DGradientStopsHelper should be
derived from wxD2DResourceHolder<ID2D1GradientStopCollection> for the
sake of consistency with other D2D resource holders.
Since wxPGChoiceAndButtonEditor derives from wxPGChoiceEditor so making
a call to the base class virtual function CreateControls() from the child
CreateControls() is legitimate and more clean than calling to this
function in the another instance of the base class wxPGChoiceEditor
(which may not exists).
Provide GetAttrPtr() and GetCellAttrPtr() convenience functions that can
be used instead of the original Ptr-less versions to avoid the need to
manually call DecRef() on the returned wxGridCellAttr pointers.
No real changes, just simplify the code and make it safer.
Doing it for cells using a different alignment doesn't work correctly
and it's not clear whether it really makes sense, so just don't do it at
all for now.
Closes https://github.com/wxWidgets/wxWidgets/pull/1726
The same wxRibbonBar can use multiple button bars with different icon
sizes, so 2 image lists are not enough. But OTOH there is no need to
distinguish between small and large images neither, so 2 may be also 1
too many.
Instead, use however many image lists we need, depending on the size.
For now, just store them in a vector and use linear search in it,
instead of using a map or, maybe, sorted vector, as we suppose there are
never going to be more than a couple of elements in this vector anyhow.
