This reverts commit 55c3c1b05c.
It turns out many Linux distributions are shipping zenity which doesn't support the new --icon option. We'll need a more robust fix for this.
On platforms where time_t is a signed 32-bit integer, most notably i386 Linux,
various functions stop working when dealing with a timestamp
beyond January 2038.
glibc has an opt-in mechanism that redefines time_t to be 64-bit,
and correspondingly increases the size of all system data
structures that contain a time_t, such as struct timeval and struct stat.
This is necessary to allow timestamps beyond January 2038 to be represented;
as well as things that obviously deal with timestamps, this affects functions
like stat(), which will fail with EOVERFLOW if asked to inspect a file whose
correct timestamp does not fit in time_t. This in turn can cause unexpected
problems for "filesystem APIs" of the form "if /run/foo exists, then ..."
when accessed by 32-bit code, if the check for existence is done with stat()
rather than access().
Using 64-bit timestamps in glibc is an opt-in and not the default, because
if done carelessly it can change libraries' ABIs. However, SDL mostly doesn't
use system headers or types in its own headers. I
Co-authored-by: Simon McVittie <smcv@collabora.com>
On 32-bit platforms such as i386, if SDL is compiled with -D_TIME_BITS=64
to opt-in to ABIs that will not stop working in 2038, the fields in
this struct change their naming and interpretation.
The Linux header <linux/input.h> defines macros input_event_sec and
input_event_usec which resolve to the right struct field to look at.
The actual field names and types are an implementation detail,
historically signed 32-bit time.tv_sec and time.tv_usec on 32-bit
platforms, but becoming unsigned __sec and __usec when using 64-bit
time (which makes them able to represent times up to 2106).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Add a DBus message handler to watch and respond to changes to the system cursor size and theme properties. Upon these settings being changed, a cursor refresh will be triggered so the new changes will take effect immediately, without the cursor having to leave and re-enter the window surface.
Applications that don't specify a rendering flag are likely handling Vulkan/GL themselves, so SDL loading OpenGL by default in this case is unnecessary overhead, and if a render backend requires it, the window will be recreated with the appropriate flags when the renderer is initialized.