Currently, wxGLCanvas on wxGTK is only supported on X11 displays. If a
user attempts to use wxGLCanvas on Wayland, for example, the application
will core dump. This change adds an error message and a suggested
workaround until wxGLCanvas is supported on Wayland.
See #17702.
Closes https://github.com/wxWidgets/wxWidgets/pull/871
Base class SetTitle() implementation didnd't work for this class as it
used the (invalid) HWND of not yet existing dialog, so add a hook
procedure for the common font dialog, similar to the existing one for
wxColourDialog, which allows us to set the dialog title when the dialog
is really created.
Closes https://github.com/wxWidgets/wxWidgets/pull/865Closes#18177.
Calling MoveToPoint() shouldn't automatically open a new D2D figure (which
acts as a subpath) because in case of consecutive calls to MoveToPoint()
every next call would close the figure opened by the previous call and
we would get spurious figure(s) (consisting one point).
Opening a D2D figure (subpath) should be delgated to the functions doing
actual drawing.
Graphics path is actually a line with null width so its bounding box
should be obtained with cairo_path_extents() function which assumes
that line width is 0.
It was impossible to stop sorting the control if it had been sorted
before, so implement UnsetAsSortKey() to allow doing it by destroying
the current sort descriptor.
Closes#18176.
At least with 10.12 SDK, NSTabViewItem initWithIdentifier: parameter
isn't annotated as being nullable, so passing "nil" to it triggers a
compiler warning.
This warning is apparently harmless and the header was fixed in 10.13
SDK, so just suppress it.
It could happen that the window remained as the global "pending focus"
even after it lost its focus, resulting in FindFocus() still returning
it as the currently focused window, even though it didn't have focus any
more.
This notably broke focus logic of wxCompositeWindow and could result in
missing wxEVT_KILL_FOCUS for windows using it, such as wxDatePickerCtrl,
and quite likely was responsible for other focus problems in wxGTK as
well.
No real changes, just add a helper wxDumpWindow() function to make focus
logging less verbose and slightly more readable (as the label is not
shown any more if it's empty).
This amends a0298f3149 by only avoiding
dispatching of the native events in nested event loops, but still
dispatching any pending wx-level events before exiting it.
The latest code still solves the original problem, as it was due to
having an endless stream of native events, without possibly introducing
new problems and even crashes if, for example, some dialog event handler
queued an event referencing the dialog itself for later procession, as
this event must be dispatched before the loop exits and the dialog is
destroyed, which wasn't the case any more after the changes of
a0298f3149 but is done again now.
See #11273.
Revert 1de107c037 and remove the focus
event handler which duplicated and interfered with the handler inherited
from this class to make sure that we get wxEVT_{SET,KILL}_FOCUS for the
objects of this class.
Unfortunately these events now come in pairs, due to an extra artificial
event generated by wxComboBoxExtraInputHandler::OnFocus(), which is
still wrong -- but arguably less wrong and more useful than not sending
them at all.
Add wxPNGImageData and use it to store variables that used to be local
in wxPNGHandler::LoadFile() and could be clobbered by the use of
longjmp() and pass these variables to DoLoadPNGFile(), which still uses
longjmp(), whereas LoadFile() doesn't any longer.
In addition to fixing the warning, this allows to use C++ dtors for
freeing memory and makes the code shorter and, arguably, more clear than
the original version (although written in an unusual way) and definitely
more clear than the version with the warning fix.
This reverts commit 99ea06203a ("Fix
clobbering warning") and replaces it with a different solution to the
same problem.
Previously this was only done when wxBU_AUTODRAW was specified, making
this the only place in wxWidgets where this style was actually used.
This was not ideal, as the same code, not using wxBU_AUTODRAW, worked
just fine under MSW and GTK, but created ugly-looking buttons under Mac,
so do the right thing by default and let people call SetMargins(0, 0) if
they really don't want to have any margins.
Closes#18170.
Due to https://bugzilla.gnome.org/show_bug.cgi?id=710888 GtkInfoBar
wasn't shown if it had been hidden before -- which is exactly what
wxInfoBar did.
Fix this using the workaround proposed in the bug report, which makes
the info bar appear immediately, without any transition, which might be
not ideal, but markedly better than failing to show it at all.
Changing item cell in ShowAsRadio() was wrong as the item cell doesn't
exist when it is called and changing the column cell didn't seem to work
well, so just recreate the entire cell in it instead.
See https://github.com/wxWidgets/wxWidgets/pull/853
This allows showing radio buttons in wxDataViewCtrl easily and natively.
Notice that this approach, adding an extra function to the existing
renderer class instead of creating some new wxDataViewRadioRenderer (see
https://github.com/wxWidgets/wxWidgets/pull/809), was finally chosen
because it is simpler to implement and, more importantly, because it
will be more natural to generalize if/when we also add a 3-state
check/radio renderer.
Closes https://github.com/wxWidgets/wxWidgets/pull/853
