I don't know much about X11 and much less about Xinerama, but I tried to get
the DPI code running on X yesterday, and all my virtual machines (3 Linux
variants) fell back to X11 (no Xinerama). After investigating a little more, I
found that there is no libXinerama.so, but there are
On 07.01.2011, at 02:33, fltk-dev@easysw.com wrote:
Author: matt
Date: 2011-01-06 17:33:29 -0800 (Thu, 06 Jan 2011)
New Revision: 8206
Log:
DPI fixed for Xinerama?
About Fl::screen_dpi() on Mac OS:
unfortunately, the system function userSpaceScaleFactor
always returns 1 (unless
Generally screen DPI seems to be handled Really Badly across the board -
most WinXX systems lie to you about DPI too, just returning 96 or 120 or
whatever they fancy regardless of what actual display is connected.
Recent Xorg X11 systems appear to be going the same way...
This came up recently
On 07.01.2011, at 11:13, Manolo Gouy wrote:
On 07.01.2011, at 02:33, fltk-dev@easysw.com wrote:
Author: matt
Date: 2011-01-06 17:33:29 -0800 (Thu, 06 Jan 2011)
New Revision: 8206
Log:
DPI fixed for Xinerama?
About Fl::screen_dpi() on Mac OS:
unfortunately, the system function
On 07.01.2011 10:38, Matthias Melcher wrote:
I don't know much about X11 and much less about Xinerama, but I tried to get
the DPI code running on X yesterday, and all my virtual machines (3 Linux
variants) fell back to X11 (no Xinerama). After investigating a little more,
I found that
On 07.01.2011, at 13:27, Albrecht Schlosser wrote:
On 07.01.2011 10:38, Matthias Melcher wrote:
I don't know much about X11 and much less about Xinerama, but I tried to get
the DPI code running on X yesterday, and all my virtual machines (3 Linux
variants) fell back to X11 (no Xinerama).
Now,
since pretty much all the OSs lie (which shouldn't come as a
surprise, because until HDMI the data exchange between
screens and graphics cards has been very minimalistic),
Well, in theory, the EDID data returned by DDC2 on most any recent
monitor gives pretty much the same info as
Gents,
A few new warnings being seen now on my win32 builds (Msys/mingw based
build...) that were not present a few days ago.
First is in the font handling, maybe something to do with the work
Manolo did to display Arabic (and other RTL) text a bit better?
Compiling fl_font.cxx...
In file
On 07.01.2011, at 13:51, MacArthur, Ian (SELEX GALILEO, UK) wrote:
Now,
since pretty much all the OSs lie (which shouldn't come as a
surprise, because until HDMI the data exchange between
screens and graphics cards has been very minimalistic),
Well, in theory, the EDID data returned
On 07.01.2011 14:23, MacArthur, Ian (SELEX GALILEO, UK) wrote:
A few new warnings being seen now on my win32 builds (Msys/mingw based
build...) that were not present a few days ago.
...
The next seems to be a side effect of the recent DPI stuff, I guess...
Compiling screen_xywh.cxx...
On 07.01.2011 13:34, Matthias Melcher wrote:
BTW.: I'm just fixing a bug WRT Xinerama and dpi for Cygwin/X11 or
maybe generally for X11: As it is on my system, configure finds
Xinerama, but it is not active with my X server configuration,
i.e. XineramaIsActive(fl_display) returns false...
You are probably missing one of the -devel packages, or it is a packaging bug
for the Linux distro...
On Jan 7, 2011, at 1:38 AM, Matthias Melcher wrote:
I don't know much about X11 and much less about Xinerama, but I tried to get
the DPI code running on X yesterday, and all my virtual
On Jan 7, 2011, at 2:13 AM, Manolo Gouy wrote:
...
About Fl::screen_dpi() on Mac OS:
unfortunately, the system function userSpaceScaleFactor
always returns 1 (unless special measures are taken, see below)
whatever the screen and screen resolution you use. I have here
a MacBook Pro and an
On Jan 7, 2011, at 4:34 AM, Matthias Melcher wrote:
On 07.01.2011, at 13:27, Albrecht Schlosser wrote:
On 07.01.2011 10:38, Matthias Melcher wrote:
I don't know much about X11 and much less about Xinerama, but I tried to
get the DPI code running on X yesterday, and all my virtual
I don't think that we currently have a clear documentation of
FLTK's usage of compiler, OS, and FLTK's own #define's.
Should I (we) try to write such docs, and where would be a useful
place? Maybe in the OS-specific documentation chapter ? Or in the
developer section?
Here are some first
The CMP page is the correct place for these things:
http://www.fltk.org/cmp.php
Just add another section near the end for preprocessor standards.
On Jan 7, 2011, at 11:02 AM, Albrecht Schlosser wrote:
I don't think that we currently have a clear documentation of
FLTK's usage of compiler,
On 07.01.2011, at 17:50, Michael Sweet wrote:
FWIW, I have the JPEG changes almost ready to go - just need to finish
updating the IDE project files with the changes to the JPEG sources. ZLIB and
PNG to follow this weekend...
Great! I will do an RC3 now and the RC4 will be just for the
17 matches
Mail list logo
