Unless you have any quick idea of what's going on, I can try to git-bisect the issue back to where it began.
Or, could try setting the FLTK environment variable FLTK_BACKEND (though TBH I can't remember the valid values...) or perhaps even just try setting WAYLAND_DISPLAY to something invalid... (like "none") for your existing build.Actually, that's a thought - what does your system report WAYLAND_DISPLAY as?
Getting closer. My testcase (and the original codebase) now report:GCC Version: 11.3.0
FLTK Version: 1.4.0Known monitors: 3
Monitor 0: 2560x1440 (2560,0) [Primary Screen]Monitor 1: 2560x1440 (5120,0)
Monitor 2: 2560x1440 (0,0)Workspace: 7680x1440
So it is picking up the three monitors correctly, and it's identifying the primary screen correctly (the one in the 'middle' of three monitors).However, the resolution is still off. The monitors are 4K 3840x2160 monitors, but the current fltk (commit 1b0754ce4db888b01b291d64330751fe0a77eafc) has them as 2560x1440.
BTW, the xinerama setting in config.h is set:/*
* HAVE_XINERAMA
*
* Do we have the Xinerama library to support multi-head displays?
*/
#define HAVE_XINERAMA 1
At the moment I'm using configure+make to build in the FLTK tree. My main project uses autotools.I'm under the impression CMake is the 'future' for FLTK. Would the developers recommend that I migrate the build of FLTK to CMake? As I'm on Gentoo access to build systems is not a problem :-)
… and test apps in <FLTK source tree>/bin/test/
Le mercredi 30 novembre 2022 à 01:50:12 UTC+1, Tigercat a écrit :I'm under the impression CMake is the 'future' for FLTK. Would the developers recommend that I migrate the build of FLTK to CMake? As I'm on Gentoo access to build systems is not a problem :-)
Yes, CMake is expected to progressively supplant configure as building tool.But configure remains supported by FLTK.
This is a somewhat off-topic response to one of the comments below, not the main topic of the post!
On Wednesday, 30 November 2022 at 03:17:43 UTC Manolo wrote:
Le mercredi 30 novembre 2022 à 01:50:12 UTC+1, Tigercat a écrit :
I'm under the impression CMake is the 'future' for FLTK. Would the developers recommend that I migrate the build of FLTK to CMake? As I'm on Gentoo access to build systems is not a problem :-)
Yes, CMake is expected to progressively supplant configure as building tool.But configure remains supported by FLTK.
Though note that (perhaps as here?) they two build systems may not match exactly at all times as development proceeds, and that *in general* the cmake system is a little more likely to be fully "up to date" at any given point as things evolve.
Also, the cmake system seems to be better at detecting and handling dependencies as files change - the dependency generation in our autoconf setup is not 100% reliable and sometimes misses dependencies that cmake does detect.
On the other hand, the fltk-config that the cmake system generates is sometimes a bit wayward; I've found that it is inclined to miss compiler flags (such as optimizer settings) and sometimes image libs, that the autoconf generated version does seem to handle correctly.YMMV.
On 11/30/22 11:52 Ian MacArthur wrote:
This is a somewhat off-topic response to one of the comments below, not the main topic of the post!
Also, the cmake system seems to be better at detecting and handling dependencies as files change - the dependency generation in our autoconf setup is not 100% reliable and sometimes misses dependencies that cmake does detect.
To be precise: the autoconf (configure/make) build system is unreliable in almost 100% because we don't (and we can't!) maintain dependencies for all potential configurations.
There is only one working workaround: if users have the `makedepend` tool installed on their system they can execute `make depend` (note the space) in the FLTK root directory *after* configure/make and later whenever they use `git update` or change FLTK sources or the configuration. This is error prone and I recommend strongly to switch to CMake whenever possible - at least for building the FLTK libs.
On 11/30/22 09:21, Tigercat wrote:
Works for me. As an old-time Unix guy I use autotools most of the time because I'm usually just targeting Linux/Gnu, but for those times I do cross-platform Windows/Mac/Linux work I also find CMake is usually the best of the (all-problematic) options. I'll switch over and watch for issues.
The biggest thing cmake gave us was Windows support for
Visual Studio.
We had to manually maintain separate IDE files for different
VS versions
which was a giant pain in the but, and made for unnecessarily
large tar files
for all those separate project files and junk. With cmake, it
generates those
'on the fly' so we don't have to include them in the tar
files.
I'm sure Albrecht, who's our cmake wizard, would also chime in
about many
other benfits, not the least of which localizes each build in
a separate directory,
making it easier to build the same source code (on a file
server) built across
platforms without crosstalk in the source directories.
I get the impression cmake is a bit of a large undertaking to
learn fully,
but honestly so is automake/configure. I never really
understood the
underbelly of either one, so I tend to hand craft Makefiles
myself
and avoid IDEs so my apps and FLTK can be build via scripts.
At least
cmake allows that to be possible without the handcrafting,
which is fine with me..!
I get the impression cmake is a bit of a large undertaking to learn fully,
but honestly so is automake/configure. I never really understood the
underbelly of either one, so I tend to hand craft Makefiles myself
and avoid IDEs so my apps and FLTK can be build via scripts. At least
cmake allows that to be possible without the handcrafting, which is fine with me..!