Under gnome, Tweaks -> Fonts ->Scaling factor allows to change
the size of all fonts handled by gnome.
With that change, FLTK apps obey to changes to Xft.dpi.
Previously, the display scaling factor value under gnome was sought in the gnome
database using the gnome_scale_factor() function. But that information is no
longer present.
File $HOME/.config/monitors.xml was also used to get that information.
Using the Xft.dpi X resource is simpler and more general because it's
effective both for gnome and KDE.
The procedure to set screen scaling factors becomes:
1) each screen scaling factor is set to 1
2) the OS is queried according to each platform to get screen scaling factor
values
3) The value of FLTK_SCALING_FACTOR, if present, is used to multiply
scaling factors
Gnome now seems to store the value of the display scale factor in file
$HOME/.config/monitor.xml. Previously, that value was readable with
the gsettings command.
The present commit uses the information found in that file
and reverts back to the gsettings command if that information is not found.
All branches named like:
- master
- branch-1.3
- feature-*
- fix-*
- issue-*
- str-*
will be built with Travis-CI in the FLTK standard repo and in the
user's and/or developer's forks if they enabled Travis-CI builds.
Explicit email addresses don't play well with forks, i.e. the given
mail receivers are *always* notified instead of the author and the
committer. This led to build notifications sent to me instead of Matt
when he committed something in his own fork.
The default rules are much better in this case. The drawback is that
*only* the committer and author get notified and there is obviously
no way to add anybody that gets notified *additionally* to author
and committer.
https://docs.travis-ci.com/user/notifications/#how-is-the-build-email-receiver-determined
The Cairo demo program (test/cairo_test.cxx) can and should be built
even if Cairo is not configured with CMake as it is done with
autotools (configure/make).
The message window shown when Cairo support is not available has been
improved (is more explicit and has a window title).
This file is currently identical with the one in branch-1.3 which was
used to release 1.3.5rc1. It includes generating the MD5 checksums
in a format suitable to be added to the online checksum file.
The new name follows FLTK naming rules and has the benefit of avoiding potential
collision with future macOS method names that follow a different naming rule.