X11, Tcl and Tk for Windows
I am looking for Tcl/Tk v8.0 and a compatible version of Xlib, for a port of an application developed originally for a Unix platform. The application is a based transport simulator, and is written in C++ . The Tcl/Tk is there to provide the GUI, including a window within which X11 calls provide "real-time" graphics display of the behaviour of simulated objects (eg "real-time" movement of vehicles across a map). At first sight Cygwin appears to provide what I need: a. Include files for tcl and tk in usr/include and for X in X11R6/include/X11. b. The X11 library at usr\X11R6\lib\libX11.a ... And the Tcl/Tk libraries tcl80.lib and tk80.lib But when I link with the libraries mentioned in (b), the following sequence of code leads to failure in the X software. For brevity this code omits checks on call results, which are OK up to the last line. _pint = Tcl_CreateInterp(); Tcl_Init (_pint); _tk_mainwin = Tk_MainWindow (_pint); _pdisp= Tk_Display (_tk_mainwin); int idc = DefaultColormap (_pdisp, 0); // Failure here, or in subsequent call to XParseColor () I have also tried linking with libraries tcl84.lib , tk84.lib from the Tcl/Tk distribution at http://www.tcl.tk/software/ includes .. but in that case I get a failure in the call to Tcl_Init. I would appreciate advice on how to obtain a workable collection of the software libraries, or on some other way of overcoming these difficulties. Mark Horn
Re: AW: Enabling SHM support in default build of XWin.exe
Chuck, Charles Wilson wrote: Ralf Habacker wrote: ... if linked to the static ipc-library. Using the cygipc dll results in an additional runtime dependency, which will produce windows runtime linking errors if the cygipc package isn't installed, which will produce more support noise dealing with this issue. Using the static library avoids this problem. I think that you *should* use the DLL. And add cygipc to the setup.hint requires: of XFree86. Not because I think that everyone should or will 'turn on' the daemon, but because: Oh don't worry. I hadn't made my reply to this yet. I am going to use the DLL and add cygipc as a dependency. SHM will only be enabled if the daemon is setup properly, but it won't cause problems if it isn't setup. The other thing here is that I am just lazy. It would take more work for me to make a static link to cygipc than to link to the DLL. Thanks for your input, Harold
Re: static libs in bin?
Actually the 4.3.0-3 list is empty, 4.3.0-2 beeing ok. > Note that the Cygwin package listing website is broken for the > XFree86-bin packages. The only version of XFree86-bin that lists is > XFree86-bin-4.2.0-1 (at least for me). The most recent version, > found > at the URL below, has an empty list: > > http://www.cygwin.com/packages/XFree86-bin/XFree86-bin-4.3.0-2 = Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: AW: Enabling SHM support in default build of XWin.exe
Ralf Habacker wrote: ... if linked to the static ipc-library. Using the cygipc dll results in an additional runtime dependency, which will produce windows runtime linking errors if the cygipc package isn't installed, which will produce more support noise dealing with this issue. Using the static library avoids this problem. I think that you *should* use the DLL. And add cygipc to the setup.hint requires: of XFree86. Not because I think that everyone should or will 'turn on' the daemon, but because: you can't use libtool to make a DLL that has static dependencies (without heroic effort). Now, I know that XFree86 does not use libtool, but maybe I want to build gtk or something that (a) does, and (b) links to XFree86 libs. Since, in this scenario, the XFree86 libs will have a link time dependency on libcygipc.a -- I won't be able to build a DLL version of gtk (without heroic effort). What's the "support issue" you're worried about, Ralf? One more requires: library? When Harold is busy spinning out expat, fontconfig, and freetype -- what's one more? -- Chuck
ddxLoad patch?
Alexander, I want to get the following patch that you made to xoncygwin HEAD taken care of: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xoncygwin/xc/programs/Xserver/xkb/ddxLoad.c.diff?r1=1.1&r2=1.2 I want to commit your change to the XFree86 CVS tree, but I don't know if your change is compatible with all platforms. If it is compatible with all platforms, could you give me the justification that I should use when I file the bug report? If we don't know that this is compatible with all platforms, should we #ifdef __CYGWIN__ it? Thanks for contributing, Harold
Re: Latest CVS Compilation error
Alexander,
I have submitted your change to XFree86 as part of a large patch set.
See bug 701:
http://bugs.xfree86.org/show_bug.cgi?id=701
Harold
Alexander Gottwald wrote:
Harold L Hunt II wrote:
Please resubmit your earlier patch when you have this completed.
Stupid me. Has forgotten to attach the patch *g*.
bye
ago
NP: Welle:Erdball - Starfighter F-104G (2)
Index: winmsg.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xwin/winmsg.c,v
retrieving revision 1.1
diff -u -r1.1 winmsg.c
--- winmsg.c 17 Oct 2002 08:18:22 - 1.1
+++ winmsg.c 15 Sep 2003 19:27:26 -
@@ -45,26 +45,7 @@
winVMsg (int scrnIndex, MessageType type, int verb, const char *format,
va_list ap)
{
- const char *prefix = NULL;
-
- if (verb && verb > VERBOSE_LEVEL)
-return;
-
-#undef __msg
-#define __msg(name,string) case name: prefix = string; break;
-#undef _msg
-#define _msg(name,string) __msg(name,string)
- switch (type)
-{
- MESSAGE_STRINGS default:prefix = NULL;
- break;
-}
-#undef __msg
-#undef _msg
-
- if (prefix != NULL)
-ErrorF ("%s ", prefix);
- VErrorF (format, ap);
+ LogVMessageVerb(type, verb, format, ap);
}
@@ -73,7 +54,7 @@
{
va_list ap;
va_start (ap, format);
- winVMsg (scrnIndex, type, 0, format, ap);
+ LogVMessageVerb(type, 0, format, ap);
va_end (ap);
}
@@ -83,7 +64,7 @@
{
va_list ap;
va_start (ap, format);
- winVMsg (0, type, 0, format, ap);
+ LogVMessageVerb(type, 0, format, ap);
va_end (ap);
}
@@ -94,7 +75,7 @@
{
va_list ap;
va_start (ap, format);
- winVMsg (scrnIndex, type, verb, format, ap);
+ LogVMessageVerb(type, verb, format, ap);
va_end (ap);
}
@@ -104,7 +85,7 @@
{
va_list ap;
va_start (ap, format);
- winVMsg (0, type, verb, format, ap);
+ LogVMessageVerb(type, verb, format, ap);
va_end (ap);
}
@@ -114,6 +95,6 @@
{
va_list ap;
va_start (ap, format);
- winVMsg (0, X_NONE, verb, format, ap);
+ LogVMessageVerb(X_NONE, verb, format, ap);
va_end (ap);
}
Index: winmsg.h
===
RCS file: /cvs/xc/programs/Xserver/hw/xwin/winmsg.h,v
retrieving revision 1.1
diff -u -r1.1 winmsg.h
--- winmsg.h 17 Oct 2002 08:18:22 - 1.1
+++ winmsg.h 15 Sep 2003 19:27:26 -
@@ -32,31 +32,6 @@
#ifndef __WIN_MSG_H__
#define __WIN_MSG_H__
-
-#define __msg_name(name,string) name
-#define __msg(name,string) __msg_name(name,string)
-#define _msg(name,string) __msg(name,string),
-
-#define MESSAGE_STRINGS \
-_msg(X_PROBED,"(--)"/* Value was probed */)\
-_msg(X_CONFIG,"(**)"/* Value was given in the config file */)\
-_msg(X_DEFAULT,"(==)" /* Value is a default */)\
-_msg(X_CMDLINE,"(++)" /* Value was given on the command line */)\
-_msg(X_NOTICE,"(!!)"/* Notice */) \
-_msg(X_ERROR,"(EE)" /* Error message */) \
-_msg(X_WARNING,"(WW)" /* Warning message */) \
-_msg(X_INFO,"(II)" /* Informational message */) \
-_msg(X_UNKNOWN,"(?""?)" /* Unknown, trigraph fix */) \
-_msg(X_NONE,NULL/* No prefix */) \
-__msg(X_NOT_IMPLEMENTED,"(NI)" /* Not implemented */)
-
-typedef enum
-{
- MESSAGE_STRINGS
-}
-MessageType;
-
-
/*
* Function prototypes
*/
Index: InitOutput.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xwin/InitOutput.c,v
retrieving revision 1.33
diff -u -r1.33 InitOutput.c
--- InitOutput.c 29 Jul 2003 21:25:15 - 1.33
+++ InitOutput.c 15 Sep 2003 19:27:27 -
@@ -47,13 +47,15 @@
int g_iWindowPrivateIndex = -1;
unsigned long g_ulServerGeneration = 0;
Bool g_fInitializedDefaultScreens = FALSE;
-FILE *g_pfLog = NULL;
DWORD g_dwEnginesSupported = 0;
HINSTANCE g_hInstance = 0;
HWND g_hDlgDepthChange = NULL;
HWND g_hDlgExit = NULL;
Bool g_fCalledSetLocale = FALSE;
Bool g_fCalledXInitThreads = FALSE;
+int g_iLogVerbose = 4;
+char * g_pszLogFile = WIN_LOG_FNAME;
+Boolg_fLogInited = FALSE;
/*
@@ -190,15 +192,11 @@
g_fdMessageQueue = WIN_FD_INVALID;
}
- /* Close the log file handle */
- if (g_pfLog != NULL)
-{
- /* Close log file */
- fclose (g_pfLog);
-
- /* Set the file handle to invalid */
- g_pfLog = NULL;
-}
+ if (!g_fLogInited) {
+LogInit(g_pszLogFile, NULL);
+g_fLogInited = TRUE;
+ }
+ LogClose();
/*
* At this point we aren't creating any new screens, so
@@ -242,12 +240,15 @@
#ifdef DDXOSVERRORF
if (!OsVendorVErrorFProc)
OsVendorVErrorFProc = OsVendorVErrorF;
-
- /* Open log file if not yet open */
- if (g_pfLog == NULL)
-g_pfLog = fopen (WIN_LOG_FNAME, "w");
#endif
+ if (!g_fLogInited) {
+LogInit(g_pszLogFile, NULL);
+g_fLogInited = TRUE;
+ }
+ LogSetP
Re: rootless cygwin emacs howto?
Run -multiwindow without -rootless. The docs have not been updated for the multiwindow and rootless modes. Harold Terrence Brannon wrote: I just finished reading these docs: http://xfree86.cygwin.com/docs/ug/configure-cygwin-xfree-options.html but they dont mention rootless and multiwindow as options, but I assume they are the latest docs. I wasn't sure whether to run multiwindow with or without rootless.
Re: finding out if xfree86 is the latest
Terrence, From a Cygwin bash prompt, run: cygcheck -c XFree86-xserv The development change log is here: http://xfree86.cygwin.com/devel/shadow/changelog.html You can also look at the Cygwin/XFree86 Announcement archives: http://cygwin.com/ml/cygwin-xfree-announce/ Harold Terrence Brannon wrote: There is really nothing to it. Just get a recent version of X, I am sorry if this is a dumb question, but it certainly is not a FAQ. I have xfree86-base 4.3.0-1. I went the xfree86.cygwin.com in hopes of seeing if that was the latest version, but did not see a page listing the current version. I found out my version number by downloading setup.exe and looking in the X11 hierarchy.
Re: rootless cygwin emacs howto?
I just finished reading these docs: http://xfree86.cygwin.com/docs/ug/configure-cygwin-xfree-options.html but they dont mention rootless and multiwindow as options, but I assume they are the latest docs. I wasn't sure whether to run multiwindow with or without rootless.
finding out if xfree86 is the latest
> There is really nothing to it. Just get a recent version of X, I am sorry if this is a dumb question, but it certainly is not a FAQ. I have xfree86-base 4.3.0-1. I went the xfree86.cygwin.com in hopes of seeing if that was the latest version, but did not see a page listing the current version. I found out my version number by downloading setup.exe and looking in the X11 hierarchy.
Re: Compiing XWin...
Please ignore this message thread. My original post (copied below) somehow got lost in the "ether" of the 'net for about 12 hours. In the meantime, I sent another note on the same subject which went through nearly instantaneously. From: "Thomas Chadwick" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Compiing XWin... Date: Tue, 16 Sep 2003 16:51:37 -0400 Ages ago I did some messing around with compiling XWin. I followed the steps in the Contributor's Guide, checking out the xc package from CVS and running make World. After that I was able to play with XWin itself, recompiling just that target from the xc/programs/Xservers directory (or something similar - don't know if I'm remembering it quite correctly). At the time, it occurred to me that if I installed the XFree86-lib and XFree86-prog packages via Cygwin Setup, it should be possible to get just the Xservers branch of the XFree86 source tree, run xmkmf to generate the Makefile, then build just XWin without having to download and build all of XFree86. But I never got around to re-trying it that way. I've recently been motivated to do some tinkering with XWin and before I set about the task of getting the source, compiling, etc., is there an obvious (or not-so-obvious) fallacy with my modified approach to building XWin? FYI - A full build of XFree86 takes hours on my ThinkPad w/ Pentium III @ 700MHz, 512MB RAM, and Win2k. _ Need more e-mail storage? Get 10MB with Hotmail Extra Storage. http://join.msn.com/?PAGE=features/es _ Send and receive larger attachments with Hotmail Extra Storage. http://join.msn.com/?PAGE=features/es
Re: DDD working - but getting warnings
Those look like Motif problems to me. Please test again after lesstif has been recompiled and updated. I am working on it now, so it should be RSN. Thanks. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444
DDD working - but getting warnings
Hey all, Harold, thanks for updating those Xfree libs. DDD seems to be working fine now, except I am getting several warning that constantly come up. I just wanted to know if this is normal? Sample Error: * Warning: Name: ItemsList Class: XmList Parent refused resize request. Second XtMakeGeometryRequest() failed Parent is ItemsListSW(XmScrolledWindow) Original request w 34 h 134, Second reuest w 32 h 132 Parent size 57 155 * I know I can supress these errors by turning off X-warning, but just wanted to check how normal these are. Thanks, Yamin (If it is abnormal, just let me know, and I'll do a proper capture of the events) This mail sent through www.mywaterloo.ca
Re: Compiing XWin...
On Tue, 16 Sep 2003, Thomas Chadwick wrote: > the Xservers branch of the XFree86 source tree, run xmkmf to generate the > Makefile, then build just XWin without having to download and build all of > XFree86. But I never got around to re-trying it that way. See http://cygwin.com/ml/cygwin-xfree/2003-09/msg00325.html bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Compiing XWin...
Ages ago I did some messing around with compiling XWin. I followed the steps in the Contributor's Guide, checking out the xc package from CVS and running make World. After that I was able to play with XWin itself, recompiling just that target from the xc/programs/Xservers directory (or something similar - don't know if I'm remembering it quite correctly). At the time, it occurred to me that if I installed the XFree86-lib and XFree86-prog packages via Cygwin Setup, it should be possible to get just the Xservers branch of the XFree86 source tree, run xmkmf to generate the Makefile, then build just XWin without having to download and build all of XFree86. But I never got around to re-trying it that way. I've recently been motivated to do some tinkering with XWin and before I set about the task of getting the source, compiling, etc., is there an obvious (or not-so-obvious) fallacy with my modified approach to building XWin? FYI - A full build of XFree86 takes hours on my ThinkPad w/ Pentium III @ 700MHz, 512MB RAM, and Win2k. _ Need more e-mail storage? Get 10MB with Hotmail Extra Storage. http://join.msn.com/?PAGE=features/es
AW: Enabling SHM support in default build of XWin.exe
Hi Harold, > Ralf Habacker sent some patches on 2003/09/05 that I am working on > getting committed to the XFree86 CVS tree. Those two patches are here: > > http://cygwin.com/ml/cygwin-xfree/2003-09/msg00092.html > http://cygwin.com/ml/cygwin-xfree/2003-09/msg00090.html > > > I have opened Bug 698 in XFree86's Bugzilla to track the fixing of the > xf86bigfont extension initialization: > > http://bugs.xfree86.org/show_bug.cgi?id=698 > > > After Bug 698 is committed I will be adding a function (from Ralf's > patches) to XWin.exe to check whether or not the IPC daemon is running, > then I will be adding a call to that function in the initialization of > the SHM and xf86bigfont extensions (again, per Ralf's patch). Thank you for doing this. I was very busy in the last time with real work and I have used the spare time checking possible side effects relating to this issue. For the results see below. > This should result in a build of XWin.exe that supports SHM when the IPC > daemon is running, but is not hindered when the IPC daemon is not running. > ... if linked to the static ipc-library. Using the cygipc dll results in an additional runtime dependency, which will produce windows runtime linking errors if the cygipc package isn't installed, which will produce more support noise dealing with this issue. Using the static library avoids this problem. Using the static library may cause a recompile of the x libs with a newer cygipc release in case the communication protocol between the ipc client and server changes, but I doubt that this will be happen, because the cygipc library is stable and full working. (Im using the static cypipc library for at least two years with no problems) > This will be a nice addition, as it will allow Ralf to stop distributing > ancient copies of XWin.exe for KDE on Cygwin. :) > nice to hear. > > My one question is this: KDE on Cygwin (last I checked) is also > distributing a handful of X libraries (X11?) that need SHM support as > well, can SHM be dynamically enabled/disabled for these libraries, or > are they going to have to be built in two different flavors still? > Currently the Xext and the X11 libray are using shm related functions, for which I have done a little research with the results mentioned below. The result in short is, there is no need to build in two different flawors, using the static cygipc library. 1. lib/xext/Xshm.c All shm related functions are checking the MIT-SHM extension with the XExtCheckExtension macro. see http://www.atomised.org/docs/XFree86-4.2.1/XShm_8c-source.html 2. lib/X11/Font.c _XF86BigfontCodes checks the XF86BigFont server extension before using any shm code see http://www.atomised.org/docs/XFree86-4.2.1/lib_2X11_2Font_8c-source.html line 00352 ff The other libraries of the kde-x-1.3 package which you are refering are obsolate: libXft: - added qt3 referenced symbols XftGlyphLoad XftGlyphCheck XftFreeTypeGlyphExists XftFreeTypeOpen XftFreeTypeClose XftRenderString16 -> these symbols are exported by default since 2002/09/18 libXext: - added shared memory relating symbols (XShm..) to the list of exported symbols -> these symbols are exported by default in future libICE: - removed 5 seconds delay in libICE if file attributes don't match -> fixed in 2002/09/18 Hope that helps Ralf
Re: Building XWin.exe
On Tue, 16 Sep 2003, Thomas Chadwick wrote: > I've recently been motivated to tinker a bit with compiling XWin.exe on my > own. After reading through the "Obtaining the Source Code" and "Native > Compiling" sections of the Contributor's Guide, I'm left with the following > question ... > > Do I rally need to download and build all of XFree86? Can't I just download > the Xservers branch of the source tree, run "xmkmf -a" to generate the > Makefiles and dependencies, and then compile just the XWin target? The most recent source for XWin can be found in the xoncygwin CVS repository. http://www.sourceforge.net/projects/xoncygwin The code there consists only of a few libraries and XWin itself and should build much faster than the whole XFree86 CVS. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: kde tool bar
Lung.Allen wrote: I'm trying to get kde to display only the toolbar on my system! Here is what my start file look like. ___--- @echo off set DISPLAY=localhost:0.0 set REMOTE_HOST=remotehost set CYGWIN_ROOT=\cygwin set PATH=.;%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%PATH% if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\tmp\.X11-unix\X0 :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix start XWin -from %DISPLAY% -query %REMOTE_HOST% -nodecoration rem -fullscreen Allen D. Lung Hi You don't say whether you're reporting a problem or success, or what the problem is! Also, I think this question is better asked on the kde-cygwin mailing list, [EMAIL PROTECTED] See http://kde-cygwin.sourceforge.net/ml/ or http://mail.kde.org/mailman/listinfo/kde-cygwin to subscribe... David
Re: Enabling SHM support in default build of XWin.exe
Harold L Hunt II wrote: Ralf Habacker sent some patches on 2003/09/05 that I am working on getting committed to the XFree86 CVS tree. Those two patches are here: http://cygwin.com/ml/cygwin-xfree/2003-09/msg00092.html http://cygwin.com/ml/cygwin-xfree/2003-09/msg00090.html I have opened Bug 698 in XFree86's Bugzilla to track the fixing of the xf86bigfont extension initialization: http://bugs.xfree86.org/show_bug.cgi?id=698 After Bug 698 is committed I will be adding a function (from Ralf's patches) to XWin.exe to check whether or not the IPC daemon is running, then I will be adding a call to that function in the initialization of the SHM and xf86bigfont extensions (again, per Ralf's patch). This should result in a build of XWin.exe that supports SHM when the IPC daemon is running, but is not hindered when the IPC daemon is not running. This will be a nice addition, as it will allow Ralf to stop distributing ancient copies of XWin.exe for KDE on Cygwin. :) My one question is this: KDE on Cygwin (last I checked) is also distributing a handful of X libraries (X11?) that need SHM support as well, can SHM be dynamically enabled/disabled for these libraries, or are they going to have to be built in two different flavors still? Regardless of the answer, adding dynamic SHM support to XWin.exe will solve the majority of the problems of KDE on Cygwin distributing custom files. XWin.exe gets updated so frequently that it would be an unreasonable burden for them to try to keep their copy up to date. Harold This is great news, thanks for working on this David
