Generate wxJoystickEvent with the same fields under all platforms by
making the Linux and macOS versions follow MSW convention of using
"1 << N" for the changed button.
Add GetButtonOrdinal() accessor which can be used to retrieve just N.
Closes#18233.
While this is not done for all the ports yet, the new API allows
returning different PPI values for different monitors, unlike the old
(and still existing, but implemented in terms of the new one) global
function.
Allow getting the depth of any display, not just the primary one, even
though this is not implemented for Unix ports currently.
Mostly do this for consistency with the other display-related functions.
This makes src/unix/displayx11.cpp almost readable as it's not littered
by "#ifndef __WXGTK20__" checks everywhere any more -- instead this file
is just not compiled as part of wxGTK2 at all any longer (it is still
included in wxGTK1 as well as wxX11 itself and wxMotif).
wxGTK code also can just include the new wx/unix/private/displayx11.h
instead of having to declare all the X11 functions it uses manually.
There should be no changes in behaviour, this is just a clean up.
Simplify the code by not making this function pure virtual as all the
ports except MSW had to override it just to return an empty string.
Instead, just return empty string by default as it's not critical to
force the derived classes to override this function.
Instead of forwarding to these functions from wxDisplay implementation
in wxUSE_DISPLAY==0 case, make the functions themselves wrappers around
wxDisplay, which may, or not, depending on the platform, have a simpler
implementation in wxUSE_DISPLAY==0 case, but is always available in any
case.
As part of this change, only use src/osx/core/display.cpp in macOS
builds, not iOS ones and update the Xcode project accordingly too.
This cuts down on code duplication, especially in wxGTK, and facilitates
further additions to wxDisplay API.
Implement the new {Get,Set}{FractionalPointSize,NumericWeight} methods.
Also change wxLoadQueryFont() to use wxNativeFontInfo methods as a side
effect, to reduce code duplication and reuse the existing support for
numeric weights and fractional point sizes in wxNativeFontInfo.
This is similar to a recent commit which moved float to int point size
conversions to wxFontInfo and is done for the same reasons: wxFont and
wxNativeFontInfo can depend on wxFontInfo, but the converse is not true.
No real changes.
Use float as the fundamental type for the font size and implement
wxNativeFontInfo::{Set,Get}PointSize() as wrappers around the new
{Set,Get}FractionalPointSize().
Update wxNativeFontInfo for all platforms and replace the use of its
SetPointSize() method with SetFractionalPointSize() in wxFont for the
platforms already supporting fractional point sizes (don't change the
others just yet).
Note that wxNativeFontInfo::{Get,Set}PointSize() are preserved for
backwards compatibility but shouldn't be used in any code inside the
library itself any more (again, this is not the case yet, but will be
soon).
* Switch to pure Core Text Implementation, Start extended Font API
* mac fixes
* First msw implementation
* Fixing paste error
* fixing typo
* Rearranging lines to former fallthrough order
* Blind fixes for covering new abstract methods
* Blind gtk implementations
* Fixing according to travis ..
* Removing method defined in base
* formatting adaptions
* Extending the schema definition for new weights
* fixing typo, using wxRound, other fixes according to comments
* changes according to suggestions
* fixing init order, before the init of m_info was overridden by Init()
* redo
* redo
* redo
* Cleanup
Removing obsolete code snippets, proper traces for font names
* Moving common code
Only the Get/SetNumericWeight calls should now be implemented in the native part, the ‚old‘ Get/SetWeight are common code and use the numeric counterparts.
* Updating docs
* commit wa missing changes.txt
* Doc fixes
* Full stops added
NetBSD kqueue struct uses "intptr_t" as type of the user data pointer
and not "void*" as all the other platforms using kqueue, so account for
it in this code.
Closes https://github.com/wxWidgets/wxWidgets/pull/885Closes#18199.
The code setting thread priority doesn't work without changing the
scheduling policy as thread priorities are simply ignored when using the
default SCHED_OTHER (at least under Linux and NetBSD, but probably other
systems too).
See #18195.
Skip all the code dealing with the priority/scheduling parameters if the
priority is just wxPRIORITY_DEFAULT anyhow, as it's unnecessary to do
anything in this case and it can result in spurious errors.
Also extract this code into a separate SetThreadPriority() function to
make wxThreadInternal::Create() itself shorter and more clear.
Closes#18195.
Just use wxUnusedVar() instead of defining and using the ugly
WXUNUSED_STACKSIZE() macro.
Also change an out of date comment as the thread priority is not the
only attribute being changed here.
No real changes.
Changes of c0b0562533 to common code broke
wxGTK1 build, as wx/gtk/private/wrapgtk.h is for wxGTK 2+ only.
Fix this by handling wxGTK 1 separately and including gtk/gtk.h directly
for it.
Hopefully this code will be removed, together with the rest of wxGTK1
support, in some not so distant future.
Add wx/gtk/private/wrapgtk.h wrapping gtk/gtk.h in pragmas disabling
these warnings and include it everywhere instead of directly including
gtk/gtk.h.
Also include wx/gtk/private/gtk2-compat.h from this wrapper header as it
was included by 90% of the files including gtk/gtk.h itself and it seems
to be better and simpler to just always include it.
In certain cases (e.g., virtual machines), the XVideo extension may be
present, but there are no working adaptors. In this case, wxMediaCtrl
will select xvimagesink, but then when it tries to actually play some
media, it will fail. Fix this by attemping to set the video sink to
GST_STATE_READY in TryVideoSink(). Doing this causes gstreamer to run
some checks against the XVideo extension. If this fails, then we should
fall back to the next sink type (ximagesink).
While it seems to be harmless in this particular case, it still prevents
testing this code with UBSAN by triggering it here, so check that
multiplication doesn't overflow.
Don't divide by waveformat.uiBlockAlign which could be 0, but rather
multiply by it and verify that we get the expected result. This is more
robust, as it prevents crashes on malformed input and also slightly more
efficient even for correct input.
Check that we have enough data in the input instead of happily reading
out of bounds memory.
This fixes the most common problem of crashing on bad data which doesn't
look like WAV at all, but doesn't fix problems with parsing input which
does look like WAV, but is incorrect -- this will be done in subsequent
commits.
GTK+4 does not support the gdk_screen_get_monitor_scale_factor() API
(since gdk has become more backend independent.)
Use gtk_widget_get_scale_factor() API instead on the app top window.
TODO: This does not solve the multi-monitor problem, for that it would
be necessary to use the scale factor of the widget on which the action
is being peformed.
Use wx_is_at_least_gtk2(minor) instead of gtk_check_version(2, minor)
because it is more clear and also works as expected (i.e. returns true)
when using GTK+ 3 instead of creating difficult to notice bugs in the
code by failing the version check in this case.
See #18004.
Ever since the changes of 544c4a3bde
(almost 14 years ago), playing mono WAVs with wxSound completely failed
if setting the sound device to mono using SNDCTL_DSP_STEREO ioctl
failed. This doesn't look like a wise thing to do, so don't consider
this as a fatal failure, but just play mono as stereo (and even possibly
stereo as mono) instead.
This fixes the sound sample being broken out of the box on many (all?)
Linux systems.
The code was completely broken as it locked the mutex in only one thread
and then tried to unlock it in another one, which made no sense, didn't
protect against anything and resulted in errors and assert failures.
Fix this by locking and unlocking the mutex in both threads before
accessing shared data or playing sound.
Closes#17990.