| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #2147
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | Config Files |
|---|
| Summary: | configure script changes to allow building X11 version on cygwin |
|---|
| Version: | 1.3-feature |
|---|
| Created By: | a.rburgers.quicknet |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | 1.3.0 (SVN: v6657) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | a.rburgers.quicknet
03:20 Feb 09, 2009 |
| Currently when targeting cygwin the windows GDI is used.
The X11 interface does work as well, but is not supported
by the configure script. This patch does not contain any
source changes, but allows to configure for the X11 GUI
when targeting cygwin.
- add a --enable-X11 to the configure script.
- introduce a now variable uname_GUI in the configure script to
aid in selection of either X11 or GDI when targeting cygwin.
- In src/Makefile there are rules for cygfltknox-*.dll. Add
rules for cygfltk-*.dll (X11 dlls)
- add -DUSE_OPENGL32 to CFLAGS and CXXFLAGS when targeting GDI. This
allows to make the right choice at compile team between
/usr/include/gl/gl.h (for X11) and /usr/include/w32api/gl/gl.h
(for GDI/opengl)
- Throughout the configure script set THREADS="threads$EXEEXT"
to make sure we always set the right extension. | |
| |
| #2 | mike
09:17 Feb 09, 2009 |
| FWIW, we should keep all configure options lowercase, so "--enable-x11" instead of "--enable-X11".
Longer term, --enable-x11 should probably also apply to Mac OS X as well... | |
| |
| #3 | AlbrechtS
09:56 Feb 09, 2009 |
| I like this idea to have FLTK applications under Windows with X11 support, and I tried this recently, but it didn't work - and I didn't bother to find out, how it would...
Thanks for your efforts :-)
I did a first test, and I can confirm that it works for my current cygwin installation, but only in combination with:
--enable-cygwin (that was to be expected :-) )
--disable-xft (probably, because my installation doesn't support it)
It works with --enable-xdbe and with --disable-xdbe as well.
Currently I can't upgrade my working cygwin installation, because I don't want to install all the new X11R7 stuff, but I'll test this on another machine.
---
To Mike's note (regarding X support for Mac OS X): Yes, that's something I would really appreciate! Now that we know that it works for Windows... ;-) | |
| |
| #4 | AlbrechtS
10:12 Feb 09, 2009 |
| I forgot the error messages, when configured with xft:
Linking fluid.exe...
../lib/libfltk.a(fl_font.o):fl_font.cxx:(.text+0x72): undefined reference to `_FcPatternCreate'
../lib/libfltk.a(fl_font.o):fl_font.cxx:(.text+0xe8): undefined reference to `_FcPatternAddString'
../lib/libfltk.a(fl_font.o):fl_font.cxx:(.text+0x124): undefined reference to `_FcPatternAddString'
../lib/libfltk.a(fl_font.o):fl_font.cxx:(.text+0x135): undefined reference to `_FcPatternAddInteger'
../lib/libfltk.a(fl_font.o):fl_font.cxx:(.text+0x143): undefined reference to `_FcPatternAddInteger'
../lib/libfltk.a(fl_font.o):fl_font.cxx:(.text+0x15a): undefined reference to `_FcPatternAddDouble'
../lib/libfltk.a(fl_font.o):fl_font.cxx:(.text+0x16e): undefined reference to `_FcPatternAddString'
../lib/libfltk.a(fl_font.o):fl_font.cxx:(.text+0x184): undefined reference to `_FcPatternAddBool'
../lib/libfltk.a(fl_font.o):fl_font.cxx:(.text+0x191): undefined reference to `_FcPatternAddBool'
../lib/libfltk.a(fl_font.o):fl_font.cxx:(.text+0x1be): undefined reference to `_FcPatternDestroy'
../lib/libfltk.a(fl_font.o):fl_font.cxx:(.text+0x7bd): undefined reference to `_FcUtf8Len'
../lib/libfltk.a(fl_font.o):fl_font.cxx:(.text+0x818): undefined reference to `_FcUtf8ToUcs4'
collect2: ld returned 1 exit status
make[1]: *** [fluid.exe] Error 1
Just to have a complete report. | |
| |
| #5 | a.rburgers.quicknet
14:24 Feb 09, 2009 |
| Thanks for your responses,
and thanks for *your* efforts on fltk.
I've updated the patch
- change --enable-X11 in --enable-x11
- document --enabe-x11 in documentation/src/osissues.dox
--enable-xft compiles when I install the libXft-devel package.
However no fltk dll or binary depends /bin/cygXft-2.dll so I
am not sure whether this works as intended.
I use the new modular X11. The transition was smooth for me,
but you have to install the font-* packages and a package
for each individual X-application. See here
http://www.cygwin.com/ml/cygwin/2009-02/msg00133.html | |
| |
| #6 | AlbrechtS
06:08 Feb 10, 2009 |
| I tested the first patch version with another cygwin installation with the new modular X11, but the errors (WRT --enable-xft) are the same.
Please verify that configure really uses XFT on your system for compiling and linking. This should be
(a) indicated in the configure summary [1]
(b) visible in the dependencies (cygcheck)
(c) visible when enlarging text (pixelized or smooth?)
Maybe cygwin's XFT version doesn't support these functions? The names look like fontconfig functions, but I don't know ...
-----
[1] In my tested version, the summary always shows "Graphics: GDI", although it works with X (with --disable-xft). This should be fixed as well. | |
| |
| #7 | a.rburgers.quicknet
13:21 Feb 10, 2009 |
| something must have gone wrong with my first xft build.
I can reproduce your problem and indeed this is a fontconfig
issue: libXft depends on libfontconfig.
I've added a configure test for libfontconfig.
This version builds with --enable-x11 --enable-xft and for instance
the sudoku demo has a much better appearance with --enable-xft than
with --disable-xft | |
| |
| #8 | AlbrechtS
04:55 Feb 11, 2009 |
| Yes, I can confirm that your _v03 version builds with the old and the new cygwin/X11 version (with xft) as well.
However there are some resizing issues that I could not test enough yet. It looks like the new X11 version has problems with resizing e.g. the editor demo (the editor area stays small, if the window is enlarged, and the remaining space is filled with garbage). Maybe this is a cygwin/X problem and not a FLTK problem, but we should do more tests...
And the summary still says: "Graphics: GDI". | |
| |
| #9 | a.rburgers.quicknet
10:40 Feb 11, 2009 |
| - the configuration summary now reports the correct graphics type
- with xwin -multiwindow indeed there is a problem with the resizing
for the editor demo (independent of whether Xft is enabled).
- with xwin -rootless and windowmaker as window manager, the resize
works correctly. | |
| |
| #10 | a.rburgers.quicknet
12:40 Feb 11, 2009 |
| An fltk13 X11 build on a redhat linux system, displayed
on the cygwin X-server has the same resize issue.
It appears to be either a general issues in fltk's X-code
or in the cygwin X-server, but not an issue specific to X11
on cygwin. In that respect the --enable-x11 option on cygwin
looks good so far. | |
| |
| #11 | AlbrechtS
06:31 Feb 14, 2009 |
| Further tests seem to show that there might be two problems that come together:
(1) a problem in FLTK's client X11 code, when compiled with cygwin
(2) a problem in the NEW modular cygwin X server (X11R7)
There appears to be a known problem with the cygwin X server [1], but this discussed resizing issue can only be seen, if the client is Linux (the display refreshes after a while). Other non-FLTK apps seem to work this way as well.
With a FLTK client app. comiled with cygwin/X11 and displayed on an old (cygwin) X11R6 server, everything looks good, but on the new (cygwin) X11R7 server, the display does never refresh, AFAICS (outside the original dimensions of the window when it was first created).
I'll do further tests and open another STR for this cygwin/X11 related problem.
Otherwise the proposed patch looks good now, although I didn't test all possible combinations (including linking shared libs).
-----
[1] http://cygwin.com/ml/cygwin-xfree/2009-02/msg00118.html | |
| |
| #12 | AlbrechtS
06:49 Feb 14, 2009 |
| Fixed in Subversion repository.
The new configure option is now in svn.
I let this STR "pending" as a reminder for this X11-related problem, but there should really be another STR for this ... | |
| |
| #13 | a.rburgers.quicknet
06:55 Feb 14, 2009 |
| with --disable-xdbe, the editor demo is correctly
redrawn after a resize. During the resize, the X11 stipple
is shown. The redraw does not happen with xdbe enabled. | |
| |
| #14 | AlbrechtS
09:06 Feb 15, 2009 |
| I can confirm that resizing works okay with --disable-xdbe. However, now it turns out that there is also a misbehavior, if I turn xdbe on at the Linux client (app.) side (my previous tests with Linux as client and cygwin as X server happened to be compiled with xdbe disabled on the linux side).
An even better test program than test/editor is test/tabs, because the contents resize, but the (re)drawn area keeps as small as the initial window size. However, you can click the cancel and okay buttons, even if they are not visible. | |
| |
| #15 | AlbrechtS
09:22 Feb 15, 2009 |
| I'm closing this STR now, because the RFE is included in the subversion repository.
I opened STR #2152 for discussion of the related X11 resize / redraw problem.
Please see: http://www.fltk.org/str.php?L2152 | |
[ Return to Bugs & Features ]
|
| |
