The cursor (foreground) color can be set with the
-cursorColor x11-color-spec
option to ldex or any front-end that passes the options through to ldex.
For example:
lde ... -cursorColor red
lde ... -cursorColor '#A020F0'
./run-medley -cursorColor RED -g 1200x700 -sc 1200x700 -noscroll
Alternatively, the color may be specified with the ldex*cursorColor resource
(in ~/.Xresources, or other such X11 resource databases that are loaded by
the X11 server)
The command line option will override the X11 resource option.
* Update SDL dependent code and makefile segments to prepare for SDL3
Many APIs have changed between SDL2 and SDL3. This update adds
preprocessor conditionals to adapt the Maiko SDL code to allow selection of
the SDL major version (2 or 3) from the -DSDL=n define.
The SDL3 implementation is currently available as a preview release, 3.1.0, at
https://github.com/libsdl-org/SDL/releases/tag/prerelease-3.1.0
* Add updates for makefile-haiku.x86_64-sdl to prepare for SDL3
* Allow makeright to accept sdl3 as display type to ease SDL3 experiments
* Update CMakeLists.txt for SDL3 library
* Replaces configuration option -DMAIKO_DISPLAY_SDL=ON/OFF with
-DMAIKO_DISPLAY_SDL=OFF/2/3
* Replaces PUBLIC definitions with PRIVATE definitions on targets since
we are not exporting definitions outside this local compilation
* Update messages to indicate which version of SDL is being configured
* Add fixup for SDL3.xcframework on macOS to compensate for missing
RPATH specification (CMake issue 25998)
On or before macOS Ventura's release, defaulting the @rpath to
include /Library/Frameworks stopped. Since we expect the SDL2
framework to be installed there we must add a -rpath option.
This should be backwards compatible with older macOS releases.
(verified on Catalina but nothing older)
* Rationalize the processing of command line args for the sysout. Remove most of the redundancy between what is done for sysout arg processing in xrdopt.c versus main.c. Move all of the decision making about what sysout_name to use until all args have been processed (both in xrdpopt and main). This is done in main, where the prioritization and checking is done in one place rather than spread in several places in xrdopt and main. // Order of priority:
628 // 1. Value of -sysout command line arg
629 // 2. Value of the first command line arg
630 // 3. Value of LDESRCESYSOUT env variable
631 // 4. Value of LDESOURCESYSOUT env variable
632 // 5. Value as determined by X resource manager, if any
633 // 6. Value of /home/frank/lisp.virtualmem (or lisp.vm for DOS)
* In main.c moved check for sysout as first arg to before the call to read_Xoption. This will ensure that we always check the 'true' first argument even when read_Xoption modifies argv.
* Haiku OS port
* haiku with X11 backend
* haiku has stpncpy
* Haiku is not Linux.
* X not stable enough on Haiku
* Haiku : settimeofday is a no-op
* Haiku : no need to define settimeofday at all (pointed by nbriggs)
---------
Signed-off-by: Anarchos <sylvain_kerjean@hotmail.com>
Calls to UNIX-GETPARM with argument "OSNAME" or "ARCH" now return
values derived from the compile-time settings in inc/maiko/platform.h
The current return values are
OSNAME:
"macOS"
"Cygwin"
"DragonFly BSD"
"FreeBSD"
"Linux"
"NetBSD"
"OpenBSD"
"AmigaOS 3"
"Solaris"
"Windows"
"Emscripten"
ARCH:
"WebAssembly"
"x86_64"
"arm"
"arm64"
"x86"
"PowerPC"
"RISC-V"
"SPARC"
"Motorola68K"
Rather than adding/or-ing the STK_OFFSET constant into a stack offset
to convert it to a pointer in general Lisp memory and then converting
from that to a native address... use the functions specifically
present to do those conversions with embedded checks on stack offset
validity.
Pointer difference calculations on an inappropriate stack pointer could
result in a negative offset, not just an offset that is too large to fit
in 16 bits. Complain if either case occurs.
While packing is not guaranteed, and most compilers will combine
adjacent bit fields regardless of the alignment requirements of the
datatype that is being divided, here we can be clearer that we
expect packing into 16-bit fields and we do not require (and must not
have) 32-bit alignment of the collections of bitfields.
