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
Since ec091c9f2b building plugin libraries
such as webkit2_ext and sound_sdl was broken, as they didn't use the
correct CPPFLAGS any longer.
Fix this by explicitly inheriting from "common_settings" template which
adds the use of WX_CPPFLAGS etc now.
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.
Match the filenames used by configure (gcc, clang) and the visual studio
solutions. The biggest difference is that wxARCH_SUFFIX (e.g. _64) is not
included in the dll names, and the position of the version number in the
libraries.
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 results in much shorter compilation lines and hence much shorter
build logs, which makes examining them simpler.
There should be no real changes, as we should never use duplicated
options intentionally.
This variable doesn't exist any more, but now it's possible to use
CPPFLAGS directly and get rid of the hack which required it to be used
in the first place.
Rearrange wx_{lib,dll} templates definitions to put 3rd party include
paths in the beginning, before WX_CPPFLAGS inherited from wx_{lib,dll}_b
template, so that our own 3rd party libraries headers are found before
the system ones, if we're using built-in versions of the libraries.
Don't use include paths for jpeg, png and tiff libraries when building
non-GUI projects, such as base, net or xml, and don't make these
libraries depend on the GUI 3rd party libraries neither.
No real changes, just simplify things a bit.
CPPFLAGS, CFLAGS, CXXFLAGS and LDFLAGS are supposed to be under
user-control and putting configure-determined options in them broke
something as simple as running "make CXXFLAGS=-Wno-some-extra-warning"
because this overrode the CXXFLAGS set by configure and required for
build.
Improve this by using WX_*FLAGS in the generated makefile and leaving
the user-controlled FLAGS alone. This is still not ideal as running
"configure CFLAGS=-DFOO" and then "make CFLAGS=-DBAR" will define both
FOO and BAR, as configure copies CFLAGS to WX_CFLAGS, and so setting it
on make command line won't override it, as it should, but this should be
a much more rare and also much less severe problem, so we should be able
to live with it for now.
Normally this commit shouldn't result in any user-visible changes, i.e.
it shouldn't break any previously working scenarios and only make some
previously broken ones work.
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).
