Re: can't start KDE on FreeBSD from Windows XP
On Tuesday 07 September 2004 10:36, Alexander Gottwald wrote: On Mon, 6 Sep 2004, Bruce Rhodewalt wrote: I'm having trouble configuring KDE on my Windows XP machine (using Cygwin/X 2004/03/25). From my bash shell, I can ssh or telnet to my FreeBSD 5.2.1 RELEASE machine. However, if I try to connect and run KDE, I have problems. where do you run KDE? On the FreeBSD box or on cygwin? The log below say you're starting it on cygwin. If so then I'd pass you on to the kde-cygwin mailing list. iceauth: creating new authority file /home/Bruce/.ICEauthority KDEINIT_KIO_EXEC kdeinit: Launched KLauncher, pid = 3604 result = 0 C:\programfiles\cygwin\opt\kde3\bin\kdeinit.exe (3872): *** unable to remap C:\p rogramfiles\cygwin\bin\cygz.dll to same address as parent(0xD3) != 0xD4 1105 [main] kdein 3604 sync_with_child: child 3872(0x65C) died before initi alization with status code 0x1 1632 [main] kdein 3604 sync_with_child: *** child state child loading dlls I think this is the reason why you get no windows. But i have no clue what caused this error. This is a rebasing problem. See http://kde-cygwin.sourceforge.net/kde3/faq.php#rebase. BTW: Don't know the email address of bruce so send to the cygwin-xfree list too. Regards Ralf
Re: kde3+cygwin startup problem
On Friday 30 April 2004 17:15, Nicholas Gibson wrote: I'm at a loss, this is a fresh install of cygwin+kde3 on a machine that has just been built with XP. There are no spaces in my home path, any help would be much appreciated. My kde session never gets past this point, it just sits there at starting window manager. snip kdeinit: Launched KLauncher, pid = 2620 result = 0 C:\cygwin\opt\kde3\bin\kdeinit.exe (2940): *** unable to remap C:\cygwin\bin\cygz.dll to same address as parent(0xD3) != 0xD4 3 [main] kdein 2620 sync_with_child: child 2940(0x690) died before initi alization with status code 0x1 318 [main] kdein 2620 sync_with_child: *** child state child loading dlls see http://kde-cygwin.sf.net/kde3/faq.php#rebase Ralf
Re: kde fails to start after clean install
On Monday 26 April 2004 22:51, Nicholas Gibson wrote: I am attempting to start kde after a fresh installation of cygwin and kde from http://kde-cygwin.sourcefroge.net. This is on a fresh machine with 1GB of RAM and plenty of disk space... It hangs at loading the window manager. I love kde on cygwin, any help would be much appreciated... snip kdeinit: Launched KLauncher, pid = 3920 result = 0 C:\cygwin\opt\kde3\bin\kdeinit.exe (2664): *** unable to remap C: \cygwin\bin\cygz.dll to same address as parent(0xD3) != 0xD4 This is a rebasing problem, see http://kde-cygwin.sourceforge.net/kde3/faq.php#rebase how to fix it. Ralf
Re: proposal for using windows truetype fonts
On Thursday 01 April 2004 02:16, Igor Pechtchanski wrote: On Wed, 31 Mar 2004, Eric Hanchrow wrote: Ralf == Ralf Habacker [EMAIL PROTECTED] writes: Ralf # Create a symbolic link for the windows truetype fonts ln Ralf -sf $SYSTEMROOT/Fonts /usr/X11R6/lib/X11/fonts/truetype Is the environment variable SYSTEMROOT guaranteed to be defined? If not, you might be able to use WINDIR instead. Actually, it's better to use `cygpath -W` (or `cygpath -Ww` to get exactly the same value as $SYSTEMROOT). Igor SYSTEMROOT is only avaliable for winNT and above, not for win9x, so using $WINDIR or cygpath would be better. I've tried this and it works. The script should look like $ cat /etc/postinstall/freetype2.sh #!/bin/sh # Create a link to /usr/bin/freetype-config mkdir -p /usr/X11R6/bin ln -sf /usr/bin/freetype-config /usr/X11R6/bin/freetype-config # Create a symbolic link for the windows truetype fonts ln -sf $WINDIR/Fonts /usr/X11R6/lib/X11/fonts/truetype rsp. ln -sf `cygpath -Ww` /usr/X11R6/lib/X11/fonts/truetype Anywhay, relating to the the thread ttmkfdir no longer needed there may be an access problem in symlinking the original windows dir. My question now is: in which package this font handling stuff should go in the freetype package, an already xfree package like fonts or a new true type package ? Ralf
Re: ttmkfdir no longer needed
On Saturday 10 April 2004 03:09, Harold L Hunt II wrote: It looks like we no longer need ttmkfdir in order to expose the fonts installed with Windows to X11. The mkfontscale utility that is included with out distribution was inspired by ttmkfdir and essentially replaces it: http://freedesktop.org/~xorg/X11R6.7.0/doc/mkfontscale.1.html You can do something like the following right now (well, not with Cygwin 1.5.9 since mkfontscale will core dump, you have to use snapshot of cygwin1.dll for the moment): 1) mkfontscale /cygdrive/c/WINDOWS/Fonts 2) mkfontdir /cygdrive/c/WINDOWS/Fonts 3) Launch Cygwin/X 4) In a bash shell under Cygwin/X, run: xset fp+ /cygdrive/c/WINDOWS/Fonts 5) Run xfontsel and observe that picking 'microsoft' from the 'rgstry' category exposes 'microsoft sans serif', 'tahoma', and 'verdana' among others under the 'fmly' category. Note also that valid chartacters appear when you select these fonts. Due to this I am going to pull the link to ttmkfdir from our 'Ported Software' page. Perhaps someone would like to write a postinstall script that creates symlinks to the Fonts folder for Windows under /usr/X11R6/lib/X11/fonts/windows, then runs mkfontscale and mkfontdir in that folder (since we can not guarantee that we have permissions to create files in the actual Fonts folder for Windows). Then it would take a minor adjustment of our startup scripts to pass this additional font folder to Cygwin/X on startup. One note: In the thread proposal for using windows truetype fonts I suggested to use the /usr/X11R6/lib/X11/fonts/truetype dir for truetype fonts, because this is the default for qt and kde. Are there any objectivities using this instead of /usr/X11R6/lib/X11/fonts/windows ? Any takers? I'm not very a experted x user, so that I can check up if there is more work required, but as a start point this should work: #!/bin/sh ttfontdir=/usr/X11R6/lib/X11/fonts/windows # uncomment for enabling qt and kde like truetype font dir #ttfontdir=/usr/X11R6/lib/X11/fonts/truetype mkdir $ttfontdir lndir $WINDIR\\Fonts $ttfontdir mkfontscale $ttfontdir mkfontdir $ttfontdir btw. I've got one error while testing this $ mkfontscale /usr/X11R6/lib/X11/fonts/truetype Couldn't get family name for /usr/X11R6/lib/X11/fonts/truetype/MARLETT.TTF Does this give any problems ? I'll package it if somebody works the kinks out of it. for syn with the above mentioned thread - in which package this script will go - In the freetype, xfree font or a new package ? Ralf
proposal for using windows truetype fonts
Hi, currently I'm trying the xft stuff with windows true type fonts for cygwin/qt and kde applications and it works really good. I'm planning to release the next qt/kde releases with xft support enabled. One thing I have noticed, is that a symbolic link from the windows fonts dir is required into the X11 front root dir, so I added this link to the freetype2 postinstall script as seen below, because it looks to me as the best place to add. Any comments ? Ralf $ cat /etc/postinstall/freetype2.sh #!/bin/sh # Create a link to /usr/bin/freetype-config mkdir -p /usr/X11R6/bin ln -sf /usr/bin/freetype-config /usr/X11R6/bin/freetype-config # Create a symbolic link for the windows truetype fonts ln -sf $SYSTEMROOT/Fonts /usr/X11R6/lib/X11/fonts/truetype
Re: auto-import failure for new libXt
On Saturday 20 March 2004 23:32, Brian Ford wrote: I guess this is just a heads up since I don't have time to debug it right now, but with the latest XFree packages, I get a stream of error messages like the following when linking our apps: /home/ford/v9winsym/util/Failure_report/../../../vissym/util/Failure_report /failure_report.c:104: variable '_XtStrings' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details. failure_report.o(.text+0x203f): In function `main': This used to work, all be it with similar warnings. Is it time to make a pass through the X headers, adding the proper export tags? Ugh... No, only make sure, that you are using -fdata-sections when compiling source and -Wl,--enable-runtime-pseudo-reloc when linking. BTW: You can find detailed informations about this topic in the ld info page (see Machine Dependent/Win32 section) Ralf
Re: KDE3.1 fails to run from a clean install.
On Thursday 25 March 2004 16:39, Crescioli, Phil wrote: Ooops, I forgot to insert my KDE_Log File. Here it is. Last night I did a FULL and COMPLETE download of cygwin from http://kde-cygwin.sourcefroge.net This morning I installed ALL of cygwin and tried to bring up KDE3.1 using startx -multiwindow . KDE came up and allowed me to tweak the desktop environment, then failed to load a library, etc. The log file is below. When I run KDE, I have about 100MB free RAM of the 256 totall memory in my PC. When the first library fails to load, I have about 60MB free RAM. Is my prob not enough free memory, or do I need to tweak a file somewhere To get KDE up and running? FYI-I only set KDE desktop environment to load half the eye candy stuff during the initial setup so as not to have a memory issue. snip + touch /cygdrive/c/Documents and Settings/pcrescioli/.kde_mountchecked touch: creating `/cygdrive/c/Documents': Permission denied There are spaces in your home directory. kde 3.1.4 does not like this. try HOME=/opt/kde3/home startx -multiwindow
compiling error with recent xfree server sources
Hi, I've tried to compile recent xfree server sources from freedesktop cvs area branch CYGWIN (after switching over from the old cvs area by patching all CVS Repository rsp. Root files followed by a cvs update -C -r CYGWIN) and got the following compile error: wincreatewnd.c: In function `winAdjustForAutoHide': wincreatewnd.c:559: error: `ABS_AUTOHIDE' undeclared (first use in this function) wincreatewnd.c:559: error: (Each undeclared identifier is reported only once wincreatewnd.c:559: error: for each function it appears in.) Just an info. BTW: Thanks for the new clipboard stuff, It works very good for kde/cygwin. Great work. Ralf
only a note - microsoft was refering to xfree windows port
Hi all, while reading some stuff about the ms services for unix, I stumpled over a list of xservers in their documentation, where the xfree port is also listed. (probably in the time where it belongs to cygnus, but anyway, they have stated). http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/interop/unix/sfu/sysadmn.asp Running an X-Windows application on Microsoft Windows snip On Windows, you have a set of choices for X server. The prominent ones are: Hummingbird's exceed/W WRQ's ReflectionX Tarantella's XVision XFree86 from Cygnus The above X servers can be considered as X-Windows emulators on Windows. Ralf
KDE 3.1.4 cygwin/xfree release available
Hi all, Last week the first KDE 3.1.4 release of the KDE desktop environment for cygwin/xfree was released. Beside the basic packages it contains already some additional package like kde-i18n, kdevelop, kdeedu, quanta and kdenetwork (alpha version). See http://kde-cygwin.sf.net/kde3/ for further informations. Ralf KDE on cygwin http://kde-cygwin.sf.net
Re: Any WebBrowser for Cygwin?
On Wednesday 21 January 2004 08:38, Dr. Volker Zell wrote: Hi Michael == Michael Henke writes: Michael I want to do X-Forwarding with my Windowx-XP-Box and am using Cygwin SSHd. Michael SSH is working very fine so far. All i need is a browser (except textbrowser Michael like lynx!) for www. Michael Is there any Webbrowser like Mozilla, Netscape or Opera available for the Michael cygwin-X-Server? Where to download and how to compile/install? Try o http://www.dillo.org/ It builds OOTB but needs gtk. Konqueror is also available for cygwin/xfree. See http://kde-cygwin.sf.net/kde3 for more informations Ralf
Re: Cygwin/X Representation at LinuxWorld Expo in New York City - Jan 21 to Jan 23
On Wednesday 14 January 2004 05:20, Harold L Hunt II wrote: In an exciting, and very recent, turn of events, I will be attending LinuxWorld Expo in New York City from Wednesday January 21st 3:00 PM to Friday January 23rd 4:00 PM. This trip has been made possible by funding from X.org, for which I am extremely grateful. Nice to hear. Ralf
Re: QT 3.2.3 cygwin/XFree release available
On Monday 12 January 2004 11:08, Dr. Volker Zell wrote: Ralf == Ralf Habacker writes: Ralf today the cygwin/XFree port of the QT 3.2.3 X11 release based on the recent Ralf cygwin release is ready containing binary and source package. The following configure test for QT fails: conftest.cc: What is the right link command to link with qt-3.2.3 release ? BTW the release is missing the qmake.conf file for the cygwin platform That is the reason why the link line fails. Which release are you using qt-3.2.3-1 or qt-3.2.3-2 ? qt-3.2.3-1 misses an important file (.qmake.cache) and the -2 release does not have the /etc/profile.d script. I'm currently preparing an updated release. See http://kde-cygwin.sf.net/qt3/compiling.php for further informations. BTW: Compiling files requires -fdata-sections and link lines should require -Wl,--enable-runtime-pseudo-reloc Ralf
Re: window decoration for multiwindow mode
On Sunday 04 January 2004 01:10, Kensuke Matsuzaki wrote: Hi, A new window manager XWinWM handles Motif WM Hint and Blackbox hint, and kicker has no border. XWinWM is based on Hackedbox, and Hackedbox doesn't use _NET_WM_WINDOW_TYPE atom. I have to supprot EWMH, but XWinWM has preblem on more basically window management (Move, resize, iconify etc). So now EWMH compliance's priority is not high for me. Test version is here. http://peppermint.jp/products/x/xwinwm-0.0.1.tar.gz Thanks for this info. Can't say, when I can take a look at this, but I will see probably after the kde 3.1.4 release.
some questions relating kde-cygwin and XWin
Hi, 1. for the next kde-cygwin 3.1.4 release I'm going to build a start script, which starts all required applications like ipc-daemon2, XWin and KDE basic apps and kills this processes after a logout, if they are started by the script. I like to build this script without any inferences especially to other XWin instances running on other displays, so I'm required to get the pid of the started XWin instance. I've search in the sources of the Xserver but, have not found any useable feature, so my question is, is there any way known to retrieve the pid of a started XWin instance or is there a possibility to shutdown the server by a xclient app ? If there is no such feature, what about adding a command line option to store the server pid in a file ? 2. The Xserver could be shutdowned by the Tray X icon or by the X in the Xwin windows title. I've read that Xwin now supports specific menu entry (I remember only that this was implemented, not more) I'm looking for a way to run a script for an controlled kde shutdown after triggering a server shutdown but before the xserver shutdown is performed. Unfortunally I haven't found and doc about this in the xfree docs neither I found any usefull thread with an overview of this feature for evaluating a possible implementation, so my question is if anone can give me a pointer to some docs. 3. run.exe does not support space in path. I've search for any sources, but haven't found anyone only the binary seems to available in startup-scripts package. So my question is, if this could be fixed ? BTW: There is a font size problem on http://xfree86.cygwin.com/devel/server in the Topic Souce Code: Ralf
window decoration for multiwindow mode
Hi, i just saw the xfree development page and recognized a missing feature in the multi window mode, which is is at least interesting for kde, but I assume also for other x applications. Currently the server does not handle modal dialogs like expected (currently modal dialogs are independed windows) and does not support windows without regular windows title border. (This could be verifyed for example with kicker, the KDE panel, which is bordered with a regular window title, while it is shown without any additional border as expected using an X-window manager like kwin. The relating standards for this topic could be found at http://www.freedesktop.org/standards/wm-spec/1.3/ar01s05.html _NET_WM_WINDOW_TYPE, ATOM[]/32 This SHOULD be set by the Client before mapping to a list of atoms indicating the functional type of the window. This property SHOULD be used by the window manager in determining the decoration, stacking position and other behavior of the window. The Client SHOULD specify window types in order of preference (the first being most preferable) but MUST include at least one of the basic window type atoms from the list below. This is to allow for extension of the list of types whilst providing default behavior for Window Managers that do not recognize the extensions. Rationale: This hint is intended to replace the MOTIF hints. One of the objections to the MOTIF hints is that they are a purely visual description of the window decoration. By describing the function of the window, the Window Manager can apply consistent decoration and behavior to windows of the same type. Possible examples of behavior include keeping dock/panels on top or allowing pinnable menus / toolbars to only be hidden when another window has focus (NextStep style). _NET_WM_WINDOW_TYPE_DESKTOP, ATOM _NET_WM_WINDOW_TYPE_DOCK, ATOM _NET_WM_WINDOW_TYPE_TOOLBAR, ATOM _NET_WM_WINDOW_TYPE_MENU, ATOM _NET_WM_WINDOW_TYPE_UTILITY, ATOM _NET_WM_WINDOW_TYPE_SPLASH, ATOM _NET_WM_WINDOW_TYPE_DIALOG, ATOM _NET_WM_WINDOW_TYPE_NORMAL, ATOM _NET_WM_WINDOW_TYPE_DESKTOP indicates a desktop feature. This can include a single window containing desktop icons with the same dimensions as the screen, allowing the desktop environment to have full control of the desktop, without the need for proxying root window clicks. _NET_WM_WINDOW_TYPE_DOCK indicates a dock or panel feature. Typically a Window Manager would keep such windows on top of all other windows. _NET_WM_WINDOW_TYPE_TOOLBAR and _NET_WM_WINDOW_TYPE_MENU indicate toolbar and pinnable menu windows, respectively (i.e. toolbars and menus torn off from the main application). Windows of this type may set the WM_TRANSIENT_FOR hint indicating the main application window. _NET_WM_WINDOW_TYPE_UTILITY indicates a small persistent utility window, such as a palette or toolbox. It is distinct from type TOOLBAR because it does not correspond to a toolbar torn off from the main application. It's distinct from type DIALOG because it isn't a transient dialog, the user will probably keep it open while they're working. Windows of this type may set the WM_TRANSIENT_FOR hint indicating the main application window. _NET_WM_WINDOW_TYPE_SPLASH indicates that the window is a splash screen displayed as an application is starting up. _NET_WM_WINDOW_TYPE_DIALOG indicates that this is a dialog window. If _NET_WM_WINDOW_TYPE is not set, then windows with WM_TRANSIENT_FOR set MUST be taken as this type. _NET_WM_WINDOW_TYPE_NORMAL indicates that this is a normal, top-level window. Windows with neither _NET_WM_WINDOW_TYPE nor WM_TRANSIENT_FOR set MUST be taken as this type.
Re: New webpage: Cygwin/X Features
On Wednesday 24 December 2003 08:34, Harold L Hunt II wrote: I have added a Cygwin/X Features webpage due to request by users and to ease the job of getting Cygwin/X accepted by business users: http://xfree86.cygwin.com/features.html The list of features currently has about 17 items on it. We really have some neat features! :) I know that I have forgotton some mentionable features, but it is time for bed. Please send in suggestions for additional items to the mailing list; just mention the feature and I can write the description for the actual webpage. Harold Nice page - I've found a spelling error in: DirectDraw Acceleration - .. Mutli-Window ... Ralf
AW: Problems with shared lesstif and shared Xt on Cygwin/XFree86
Hi Harold L Hunt II wrote: I tried a build without $(SMLIB) and $(ICELIB) in SharedXtReqs, but it fails to link due to unresolved symbols (all symbols must be resolved at library link time in DLLs on Windows). I will have to consult with the rest of the Cygwin people to see what we should do now. I'm working on a similar problem with libXfont. The more I think about it, the more problems I see and I think this is a feature, which ld must provide. The cases where the symbol is undefined in the shared library might get resolved with dispatch functions and code in the program which changes the pointer which is used by the dispatch code. This might be possible, but how could ld find the propper library ? Let me explain a few notes to this topic, may be this helps to understand the relating things a little bit more. linux and other unix os uses a runtime search for such symbols through ld.so, ldconfig and friends. (see http://www.cs.princeton.edu/cgi-bin/man2html?ld.so.1:1 and http://www.cs.princeton.edu/cgi-bin/man2html?ld.so.1:1 for more informations) Beside the recommended linker patch, something like the above mentioned ld.so functionality has to be implemented too. There must be a runtime specific code located somewhere in the (mingw- and cygwin's) applications startup library (like the pseudo-runtime-reloc code see http://www.cygwin.com/ml/cygwin-patches/2002-q4/msg00205.html) or somewhere else. As far as I can see the runtime stuff could be implemented in two manners: 1. when the dll is loaded by the dll startup code. The loading stuff searches the PATH (or using an newly introduced LD_LIBRARY_PATH) environment var for dll's and their exported symbols to find a valid symbol and resolves this reference. 2. at the time an unresolved symbol is called (lazy binding, ms and other native win32 linkers are supporting such a mode). Unfortunally this work only with functions symbols and not with data symbols, because of the different accessing mode (call versus content loading/writing). Both cases increases the loading time of an application and may end up in seg faults in case more than one dll exports the requested symbol and the search path is searched in an unwanted order. The increased loading time could be reduced by a dependency cache like ldconfig does, but this decision could be reached in real test scenarios. For the dll ordering problem currently I have no idea how to fix, may be someone else can help with this. The linker patch should contain the following parts: 1. a command line options to enable/disable dynamic-runtime-linking support ( --[no-]allow-shlib-undefined seems to be usable) 2. it has to detect unresolved symbols and shuld build internal code stubs (like the regular function import stub) to solve symbol requests. For the runtime stuff is has to provide internal tables (the dynamic import table) allowing the runtime stuff to find and resolve this dependencies. These import tables are probably not be visible in the PE-dll supplied import, they are only internal defined. Another approach seems to be to link all such undefined symbols to one known symbol in an specific helper dll, augmented with the original symbol in an currently unspecified decoration, so that this dll is able to solve the undefined symbol. The advantage of this solution is that there is no specific runtime stuff in each dll or application necessary. All this stuff is located in one dll and could be upgraded and improved independently from the real application or dll's (for cygwin this dll will be probably cygwin1.dll, for mingw the mingwxx.dll). BTW: I've cc'ed this email to the binutils list, because there are more people with ld knowledge, who can give some more informations/solutions for this issue. Hope that help Ralf (It may be possible to us a dummy dll'
AW: AW: cygwin.rules - Enabling shared libXt finally?
No, there is no functional changes. I only want to make sure, that no c function in Intrinsic.c can use the symbol _y (in c 'y'), so this patch renames it to __$XtInherit, which isn't usable for c functions. BTW: I was very in rush while doing the last patch, which may fails to be applied. The symbol which has to be patched is _y and not _$$y like done in the previous patch. I've added an updated patch. Ralf --- Initialize-old.c 2003-10-21 20:21:18.0 +0200 +++ Initialize.c 2003-10-21 20:23:25.0 +0200 @@ -236,8 +236,8 @@ asm (.data\n\ .globl __XtInherit\n\ - __XtInherit: jmp *_y \n\ - _y: .long ___XtInherit \n\ + __XtInherit: jmp *__$XtInherit \n\ + __$XtInherit: .long ___XtInherit \n\ .text \n); #define _XtInherit __XtInherit Ralf Errm, this isn't going to change the public interface is it? That is, if Harold releases another libXt with this change, would that break the recently re-compiled and released lesstif, etc etc? -- Chuck Ralf Habacker wrote: Not sure I understand. What should be changed in the current version of the Xt code? only note 1, chaning the label. The second note is only for completeness. Attached are my curent xc/lib/Xt/[Initialize.c|IntrinsicP.h] files. Please send a diff against these if anything should be changed. Note that these are intentionally from the 4.3 branch. --- Initialize-old.c 2003-10-21 20:21:18.0 +0200 +++ Initialize.c 2003-10-21 20:23:25.0 +0200 @@ -236,8 +236,8 @@ asm (.data\n\ .globl __XtInherit\n\ - __XtInherit: jmp *_$$y \n\ - _$$y: .long ___XtInherit \n\ + __XtInherit: jmp *__$XtInherit \n\ + __$XtInherit: .long ___XtInherit \n\ .text \n); #define _XtInherit __XtInherit
Re: cygwin.rules - Enabling shared libXt finally?
Harold, It looks like you got it nailed to me. I am testing a build right now. I have too additional notes to this patch. 1. Because _Xtinherit is exported as a data symbol, immediate calls to this function in the manner ... _XtInherit(); ... will be relocated wrongly and should be avoided ( I have seen this, but does not know currently why this happens). A workaround in case this is absolutly required is to use the following stuff. void (*func)(void); func _blah_blah = XtInherit; ... (*_blah_blah); ... 2. In the patch there is a symbol named _y. This should be renamed to a name, which couldn't be used by regular functions for example _$Xtinherit_ref or so. The '$' isn't a valid c function name. Ralf
AW: cygwin.rules - Enabling shared libXt finally?
Harold Not sure I understand. What should be changed in the current version of the Xt code? only note 1, chaning the label. The second note is only for completeness. Attached are my curent xc/lib/Xt/[Initialize.c|IntrinsicP.h] files. Please send a diff against these if anything should be changed. Note that these are intentionally from the 4.3 branch. --- Initialize-old.c 2003-10-21 20:21:18.0 +0200 +++ Initialize.c 2003-10-21 20:23:25.0 +0200 @@ -236,8 +236,8 @@ asm (.data\n\ .globl __XtInherit\n\ - __XtInherit: jmp *_$$y \n\ - _$$y: .long ___XtInherit \n\ + __XtInherit: jmp *__$XtInherit \n\ + __$XtInherit: .long ___XtInherit \n\ .text \n); #define _XtInherit __XtInherit
Re: cygwin.rules - Enabling shared libXt finally?
Hi all,
What we would need is a startup function which replaces pointers to the
importlib _XtInherit to the pointer of _XtInherit from the dll.
func reloc_addr[] = { };
unsigned reloc_addr_size = ...;
__startup_relocate(void) {
unsigned i;
func real_func = dlsym(cygXt.dll, _XtInherit);
for (i = 0; i reloc_addr_size; i++)
*(reloc_addr[i]) = real_func;
}
This must be added to libXt.dll.a and the linker must fill the reloc_addr
array.
I've found some time to take a look at this problem and it seems as I've got
a solution, which is documented below.
Could you please give this a try ?
cheers
Ralf
/*
/*
* The Symbol _XtInherit is used in two different manners. First it could be
used as a
* generric function and second as an absolute address reference, which will
be used to
* check the initialisation process of several other libraries. Because of
this the symbol
* must be accessable by all client dll's and applications.
* In unix environments this is no problem, because the used shared
libraries format (elf)
* supports this immediatly.
* Under Windows this isn't true, because a functions address in a dll is
different from
* the same function in another dll or applications. The used Portable
Executable
* File adds a code stub to each client to provide the exported symbol name.
This stub
* uses an indirect pointer to get the original symbol address, to which is
then jumped to,
* like this example shows:
*
* --- client --- --- dll
* ...
* call foo
*
* foo: jmp (*_imp_foo) foo:
* nop
* nop
*
* _imp_foo: .long index of foo in dll export table, is set to the real
address
* by the runtime linker
*
* Now it is clear why the clients symbol foo isn't the same as in the dll
and we can think
* about how to deal which this two above mentioned requirements, to export
this symbol to
* all clients and to allow calling this symbol as a function.
* The solution I've used exports the symbol _XtInherit as data symbol,
because globale data
* symbols are exported to all clients. But how to deal with the second
requirement, that
* this symbol should be used as function ? The Trick is to build a little
code stub in the
* data section in the exact manner as above explained. This is done with
the assembler code
* below.
*
* References:
* msdn http://msdn.microsoft.com/msdnmag/issues/02/02/PE/PE.asp
* cygwin-xfree: http://www.cygwin.com/ml/cygwin-xfree/2003-10/msg0.html
*/
libtest-1.tar.gz2
Description: Binary data
lib_xt.patch
Description: Binary data
AW: AW: Enabling SHM support in default build of XWin.exe
Hi Charles, ... 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? I forgot that the standard cygwin libtool has this limitation (I`m living on the kde [=older libtool release] side of libtool which uses a pass_all lib filter and you're right that it is easier to maintain one package (cygipc) as to recompile every package which is linked to the static cygipc lib on every new cygipc release. Thanks for pointing this out. ;-) Ralf
AW: IPC/SHM is now supported by default in xoncygwin HEAD CVS tree
Hi Harold, I just checked in changes to the MIT-SHM (xc/programs/Xserver/Xext/shm.c) and XFree86Bigfont (xc/programs/Xserver/Xext/xf86bigfont.c) extensions that disable SHM support when the Cygwin IPC daemon is not running. This allows IPC/SHM support to be enabled by default in Cygwin/XFree86. I tried to define the functionality of an OS-specific SHM support check as best I could, which resulted in adding a new function called OsVendorShmCheck (). This new OsVendorShmCheck function is called from shm.c and xf86bigfont.c when DDXOSSHMCHECK is defined. This system was designed to work like DDXOSVERRORF and OsVendorVErrorF (), for example. this is obviously the right way, I have seen the related patches for ...BSD, but doesn't know who to deal with. Thanks for this efforts. There will be a new Server Test Series release sometime tomorrow that includes this new functionality. I assume that the current xlib releases are linked without shm support ? Then the new features of the Xwin Test server will only be usable if at least the X11 and Xext libs are compiled with shm support. Ralf
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: cygwin 1.5.3-1
Hi Harold,
What do you mean? Do you mean that even after adding a call to check if
shm is supported and running that the extension is still installed, even
if you return?
Or do you mean that looking at the existing code shows
that they were never checking for shm support in the first place?
this one.
Harold
--- old ---
void
XFree86BigfontExtensionInit()
{
if ((extEntry = AddExtension(XF86BIGFONTNAME, /* add extension */
.. /* check for shm support and return if isn't
avaliable */
--- new ---
.. /* check for shm support and return if isn't
avaliable */
if ((extEntry = AddExtension(XF86BIGFONTNAME,/* add extension */
Cheers
Ralf
RE: cygwin 1.5.3-1
Ralf --
What happens when you run your cygipc-based build of X11, but do not
have the ipc-daemon running? You can't run KDE, of course, but does the
Xserver itself still work properly? Can non-KDE X apps work?
Xfre has build in support for disabling XIT-SHM support in cases the kernel does
not support it.
See http://www.atomised.org/docs/XFree86-4.2.1/shm_8c-source.html
xc/programs/Xserver/xext/shm.c
snip
void
ShmExtensionInit()
{
ExtensionEntry *extEntry;
int i;
#if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
if (!CheckForShmSyscall())
{
ErrorF(MIT-SHM extension disabled due to lack of kernel support\n);
return;
}
snip
Because the cypipc produces a valid return code ENOSYS in cases the ipc-daemon isn't
available,
see http://www.cygwin.com/ml/cygwin/2002-11/msg00136.html, there is only a simple
checker functions needed to check the state of the ipc-daemon and enable/disable shm
functions.
The appended patch implemented this support for the xfree server.
See the result:
cd ~/src/xc/programs/Xserver
$ killall ipc-daemon
$ ./XWin.exe
$ xdpyinfo | grep MIT-SHM
$ killall XWin
$ ipc-daemon
$ ./XWin.exe
$ xdpyinfo | grep MIT-SHM
MIT-SHM
Hope that helps
cheers
Ralf
--
Chuck
Harold L Hunt II wrote:
Well, that makes it easy. SHM will not be supported by this new build.
Harold
Christopher Faylor wrote:
On Thu, Sep 04, 2003 at 04:45:34PM -0400, Harold L Hunt II wrote:
I am not sure. How automagically is the IPC daemon installed? If
it requires user intervention, then we cannot really have XShm in the
default install.
You could make it a setup.hint dependency, of course, but that's only
half the battle. The next step would be to get the cygipc daemon
started. I don't think you want to go through that pain unless there is
a clean fallback for when cygipc isn't working right.
xext_shm.patch
Description: Binary data
RE: cygwin 1.5.3-1
Hi all,
The appended patch implemented this support for the xfree server.
I've found that the XFree86-Bigfont extension is also shm related, which is
fixed by the appended patch.
As I have looked into this code I was wondering about the extension
initialisation code, which doesn't work as expected.
It add's the extension regardless of if shm is available or not.
--- old ---
void
XFree86BigfontExtensionInit()
{
if ((extEntry = AddExtension(XF86BIGFONTNAME, /* add extension */
.. /* check for shm support and return if isn't avaliable */
--- new ---
.. /* check for shm support and return if isn't avaliable */
if ((extEntry = AddExtension(XF86BIGFONTNAME,/* add extension */
Cheers
Ralf
xext_xf86bigfont.patch
Description: Binary data
RE: XWinrc configurable server (menus/icons)
Hi Harold, If my IP is w.x.y.z vs. my loopback of 127.0.0.1, how is one of these using unix domain sockets and the other using tcp/ip? you're right, the answer is off-topic for this issue. I had read a note about using DISPLAY=:0, which means using unix domain socket and for that my answer was target. I only choosed the wrong mail. Sorry for confusing. Ralf
RE: XWinrc configurable server (menus/icons)
Hi all, The most recent patch looks pretty good from your description. c) Replaces %display% with 127.0.0.1:display.0 in commands Huh, I was going to say that %display% should be replaced with 127.0.0.1:0.0, but then I remembered that we know the 0.0, but we don't know that the user connected via 127.0.0.1. However, should we just choose to replace display with 127.0.0.1:d.s where d is display and s is screen? I know that some users report better performance when using their actual ip instead of lookback for DISPLAY... ... because the performance of cygwin's tcp implementation is more than twice as much as the unix domain implementation. I assume that this is caused by the additional security and emulation stuff overhead, which is needed to implement unix domain sockets on top of tcp sockets. See http://sources.redhat.com/ml/cygwin/2002-01/msg01719.html for further details. Ralf
RE: [ANNOUNCEMENT] Server Test 95
Hi, there is a little problem with gcc 2.95.x. In some files I've got a compiling error like mentioned below: wingc.c: In function `winValidateGCNativeGDI': wingc.c:155: parse error before `fDebugProcMsg' wingc.c:156: `fDebugProcMsg' undeclared (first use in this function) wingc.c:156: (Each undeclared identifier is reported only once wingc.c:156: for each function it appears in.) make: *** [wingc.o] Error 1 The reason is, that gcc2 is not able to deal with variable definitions after code in a function. A workaround is to change the lines - DEBUG_FN_NAME(winSetSpans); - DEBUGVARS; - DEBUGPROC_MSG; into + DEBUGVARS; + DEBUG_FN_NAME(winSetSpans); + DEBUGPROC_MSG; Cheers Ralf Changelog 2003-08-04 Ralf Habacker [EMAIL PROTECTED] * winfillsp.c(winFillSpansNativeGDI), * wingc.c(winValidateGCNativeGDI), * winsetsp.c(winSetSpansNativeGDI): fix gcc2 compiling problems. diff -up xwin95_org/winfillsp.c xwin95/winfillsp.c --- xwin95_org/winfillsp.c 2003-07-31 00:34:53.0 +0200 +++ xwin95/winfillsp.c 2003-08-04 10:01:24.0 +0200 @@ -56,8 +56,8 @@ winFillSpansNativeGDI (DrawablePtrpDraw HDC hdcStipple = NULL; BYTE *pbbitsFilledStipple = NULL; int iX; - DEBUG_FN_NAME(winFillSpans); DEBUGVARS; + DEBUG_FN_NAME(winFillSpans); DEBUGPROC_MSG; /* Branch on the type of drawable we have */ diff -up xwin95_org/wingc.c xwin95/wingc.c --- xwin95_org/wingc.c 2003-07-31 00:34:54.0 +0200 +++ xwin95/wingc.c 2003-08-04 10:01:28.0 +0200 @@ -151,8 +151,8 @@ winValidateGCNativeGDI (GCPtr pGC, PixmapPtrpStipple = NULL; winPrivPixmapPtr pStipplePriv = NULL; int i; - DEBUG_FN_NAME(winValidateGC); DEBUGVARS; + DEBUG_FN_NAME(winValidateGC); DEBUGPROC_MSG; /* Branch on drawable type */ diff -up xwin95_org/winsetsp.c xwin95/winsetsp.c --- xwin95_org/winsetsp.c 2003-07-31 00:34:54.0 +0200 +++ xwin95/winsetsp.c 2003-08-04 10:01:50.0 +0200 @@ -52,8 +52,8 @@ winSetSpansNativeGDI (DrawablePtr pDrawa BITMAPINFOHEADER *pbmih; HBITMAP hBitmap = NULL; HBITMAP hbmpOrig = NULL; - DEBUG_FN_NAME(winSetSpans); DEBUGVARS; + DEBUG_FN_NAME(winSetSpans); DEBUGPROC_MSG; /* Branch on the drawable type */
RE: [XFree86-4.2.0] Now that we have an improved ld, please make libXt a shared library.
#ifdef SUNSHLIB
/*
* _XtInherit needs to be statically linked since it is compared against as
* well as called.
*/
void _XtInherit()
{
extern void __XtInherit();
__XtInherit();
}
#define _XtInherit __XtInherit
+ #elif defined(CYGWIN)
+ void (_XtInherit)(void) = __XtInherit;
+ #define _XtInherit __XtInherit
#endif
With this way we have a symbol which contains the address of the XtInherit
function in libXt and is directly exported. This requires the pseudo-reloc
feature of ld.
Why ? Does client code access _XtInherit+offset at any place ? Only in that
case the pseudo-reloc stuff is needed.
Ralf
RE: [XFree86-4.2.0] Now that we have an improved ld, please make libXt a shared library.
ago
BTW: there are some design problems with the shared library.
snip
This test is also done in other shared libraries. On linux (and most unices)
there is no problem with this. But on windows the symbol XtInherit in the
other library points to the import table and is different to the pointer
stored in the struct. The comparisation will not work.
Do you have really tried this ?
On the assembly level every reference of the above symbol uses the same
symbolname, which is the address of the stub coming from the libxxx.dll.a or any
other import library (or build internally by ld in case of using the
direct-to-dll-linking feature see info ld -machine depended-Win32).
I have build a real working example with a symbol of libX11, which seems to be
the same
#include stdio.h
void _Xwcsncmp(void);
typedef struct {
void (*func)(void);
} Str ;
Str x = { 0};
/*And on some places they test if x.func is set: */
main()
{
if (x.func != _Xwcsncmp)
printf(test failed\n);
else
printf(test passed\n);
x.func = _Xwcsncmp;
if (x.func != _Xwcsncmp)
printf(test failed\n);
else
printf(test passed\n);
}
$ gcc test.c -save-temps -lX11 -L/usr/X11R6/lib
$ ./a.exe
test failed
test passed
Cheers
Ralf
RE: [XFree86-4.2.0] Now that we have an improved ld, please make libXt a shared library.
Hi Alexander,
for libXt it uses the direct address. For every other library using
the libXt.dll it uses the address from the stub.
I see, this is another case. Please take a look into xc/lib/xt/Initialize.c and
xc/lib/xt/sharedlib.c which provides such a case for another os. I don't
understand the xfree build system very well, so I can't provide a working
solution for this, but in fact _XtInherit() should be located in the xt import
library, which references __XtInherit() which is located in the real xt dll.
Cheers
Ralf
snip
#ifdef SUNSHLIB
/*
* _XtInherit needs to be statically linked since it is compared against as
* well as called.
*/
void _XtInherit()
{
extern void __XtInherit();
__XtInherit();
}
#endif
In sharedlib.c there is similar code
snip
#ifdef SUNSHLIB
void _XtInherit()
{
extern void __XtInherit();
__XtInherit();
}
#define _XtInherit __XtInherit
#endif
void _XtInherit()
{
XtErrorMsg(invalidProcedure,inheritanceProc,XtCXtToolkitError,
Unresolved inheritance operation,
(String *)NULL, (Cardinal *)NULL);
}
RE: qt3 on cygwin
Hello i'm trying to compile qt3.1.0 on cygwin as said in http://kde-cygwin.sourceforge.net/qt3-win32/compiling.php but i get errors (impossible to find headers) has someone compiled qt3.1.0 on cygwin ? The qt3-win32 section covers the native port of qt on cygwin without using xfree (but still using cygwin), which is in an early state and may not compile out of the box. If you are trying to compile the xfree version of qt3/cygwin you should read http://kde-cygwin.sourceforge.net/qt3/compiling.php. Cheers Ralf
RE: I am back
Hi Harold, Have you checked if xoncygwin (SourceForge CVS) has both of your patches applied? I think that I applied them both, but it would be nice if you could verify that I did. The patches were not directly applied... I looked at them and did the modifications by hand, adjusting a few things here and there, so a diff will help you but it won't be identical to your diff. Today I had already taken a look on the xoncygwin cvs and recognized this. It seems that all patches are applied. Thanks Ralf
RE: Memory access error in XWin -multiwindow
Ralf Habacker wrote: After installing this package, relink the Xserver with the following line: $ make LDFLAGS=-Wl,--whole-archive -Wl,-lmemwatch -Wl,--no-whole-archive I just noticed two little issue with linking xwin: 1. The above link line is a link line using default Makefiles, but unfortunally Xwin uses not this standard. So you have to use the following. make EXTRA_LOAD_FLAGS=-Wl,--whole-archive -Wl,-lmemwatch -Wl,--no-whole-archive -Wl, -debug XWin.exe 2. I have overseeen, that Xwin does not support stderr output, so there are not results for xwin. I've uploaded an updated mem_watch (release 1.1) to http://sourceforge.net/project/showfiles.php?group_id=27249. MEMWATCH_OUTPUT=/c/temp/test.log ./test Ralf
RE: Memory access error in XWin -multiwindow
Hi Biju, I am facing an issue of Memory access error in XWin -multiwindow mode see http://www.cygwin.com/ml/cygwin-xfree/2003-06/msg00294.html So Ralf pointed me to http://cygwin.com/ml/cygwin-xfree/2003-06/msg00162.html After seeing that patch, I have just gone thru XWin Source and found, at lot of place we call memory alloc and not testing the return value. I am attaching the list extracts from programs I dont know all of those will make any issue. I did not checked whether it is properly free()-ed You can try the mem_watch library on http://sourceforge.net/project/showfiles.php?group_id=27249. It allows checking of memory related calls on cygwin with minimal effort. After installing this package, relink the Xserver with the following line: $ make LDFLAGS=-Wl,--whole-archive -Wl,-lmemwatch -Wl,--no-whole-archive Then start Xwin and you can see all memory related calls and there calling address. See an example output below (you can get more informations through the INSTALL file of the memwatch release). $ ./test MemWatch hooks installed (set MEMWATCH=1 env var to enable debugging) Memory Checker report = number of calls: malloc : 3 calloc : 1 realloc : 0 free : 1 used memory : 350 unfree'd memory areas address sizecalladdr 0a040488 30000401afc 0a040448 2000401ac7 0a040460 3000401ad9 == 350 compile this application with debugging symbols and try addr2line to get the source line of the relating call addr2line -e ./test.exe calladdr May be that helps. Cheers Ralf
RE: E Z ? - Tried installing KDE and lost original windowing system
On Thursday, June 19, 2003, at 09:10 AM, Larry Hall wrote: Robert Pollard wrote: Hello all, I tried to install KDE and it wouldn't run after installation. I did all the post installation changes. It comes up with an error window saying The application failed to initialize properly (0xc022). Click on OK to terminate the application. This has happened every since I installed the KDE packages. I reversed all of the changes to get the original windowing system back and it still comes up with this error. Any ideas? Thanks for your time, Robert Pollard This may be a problem of execute permissions of dll's. See http://www.cygwin.com/ml/cygwin/2002-10/msg00616.html for more informations. Additional you can verify if the kde dll's have execution permissions. $ find /opt/kde3 -type f -name '*.dll' -ls or update all execute permissions immediatly $ find /opt/kde3 -type f -name '*.dll' | xargs chmod a+x $ find /opt/gtk -type f -name '*.dll' | xargs chmod a+x $ find /usr/local/lib/qt3mt/bin -type f -name '*.dll' | xargs chmod a+x Cheers Ralf
Re: RE: Memory access error XWin -multiwindow
See http://cygwin.com/ml/cygwin-xfree/2003-06/msg00162.html Cheers Ralf --- original Nachricht Ende --- Ralf Habacker [EMAIL PROTECTED] wrote: --- Sylvain Petreolle [EMAIL PROTECTED] wrote: --- Biju G C [EMAIL PROTECTED] a écrit : I dont know whether this error is same as some faced by others. I am getting following memory access error message err_redhat3.png, err_redhat4.png dialogs on vc++ debugger for the same error Did you check about multiple cygwin1.dll in your system ? The err_redhat3.png is a common case fot that. a href='http://cygwin.com/faq/faq_4.html#SEC50' target='_blank'uhttp://cygwin.com/faq/faq_4.html#SEC50/u/a I checked and found no multiple cygwin1.dll on my system. There is a XWin91-DEBUG.exe test server release, which fixes some memory access problems. I don't remember the exact name, do a search. Thanks, but I cant find XWin91-DEBUG.exe !!! If I am the only person facing the problem its ok. Because I can work with -nodecoration mode. But I wonder anybody else tested with Linux and WinXP Pro Cheers Biju __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! a href='http://sbc.yahoo.com' target='_blank'uhttp://sbc.yahoo.com/u/a -- 60% Onlinekosten sparen! Jetzt Premium Mitglied bei freenet.de werden und mit dem Tarifnavigator guenstiger surfen. http://www.freenet.de/tipp/premium/tarif/index.html
Re: Re: RE: Memory access error XWin -multiwindow
Biju, the original patch which is applied to Xwin-Test91-Debug is located in http://cygwin.com/ml/cygwin-xfree/2003-06/msg00136.html. The message i have pointed to was an additional patch, which seems not to be applied yet. I don't know when this additional patch will be applied. Sorry. Ask Harold. BTW: The segfault you have seen is in the cygwin.dll. You should compile a debug version of Xwin with symbols (at least of the xwin directory) and start XWin with gdb to see what's going on. Ralf --- original Nachricht Ende Ralf, Still getting error see err_test91.png at a href='http://www.geocities.com/bijumaillist/xscreens' target='_blank'uhttp://www.geocities.com/bijumaillist/xscreens/u/a/ I checked 76 line of winmultiwindowclass.c in a href='http://www.msu.edu/~huntharo/xwin/shadow/xwin-20030602-1055.tar.bz2' target='_blank'uhttp://www.msu.edu/~huntharo/xwin/shadow/xwin-20030602-1055.tar.bz2/u/a But i dont see the patch in a href='http://cygwin.com/ml/cygwin-xfree/2003-06/msg00162.html' target='_blank'uhttp://cygwin.com/ml/cygwin-xfree/2003-06/msg00162.html/u/a applied to it. cheers biju --- [EMAIL PROTECTED] wrote: See a href='http://cygwin.com/ml/cygwin-xfree/2003-06/msg00162.html' target='_blank'uhttp://cygwin.com/ml/cygwin-xfree/2003-06/msg00162.html/u/a Cheers Ralf --- original Nachricht Ende --- Ralf Habacker [EMAIL PROTECTED] wrote: --- Sylvain Petreolle [EMAIL PROTECTED] wrote: --- Biju G C [EMAIL PROTECTED] a écrit : I dont know whether this error is same as some faced by others. I am getting following memory access error message err_redhat3.png, err_redhat4.png dialogs on vc++ debugger for the same error Did you check about multiple cygwin1.dll in your system ? The err_redhat3.png is a common case fot that. a href='a href='http://cygwin.com/faq/faq_4.html#SEC50' target='_blank'uhttp://cygwin.com/faq/faq_4.html#SEC50/u/a' target='_blank'ua href='http://cygwin.com/faq/faq_4.html#SEC50/u/a' target='_blank'uhttp://cygwin.com/faq/faq_4.html#SEC50/u/a/u/a I checked and found no multiple cygwin1.dll on my system. There is a XWin91-DEBUG.exe test server release, which fixes some memory access problems. I don't remember the exact name, do a search. Thanks, but I cant find XWin91-DEBUG.exe !!! If I am the only person facing the problem its ok. Because I can work with -nodecoration mode. But I wonder anybody else tested with Linux and WinXP Pro Cheers Biju __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! a href='a href='http://sbc.yahoo.com' target='_blank'uhttp://sbc.yahoo.com/u/a' target='_blank'ua href='http://sbc.yahoo.com/u/a' target='_blank'uhttp://sbc.yahoo.com/u/a/u/a -- 60% Onlinekosten sparen! Jetzt Premium Mitglied bei freenet.de werden und mit dem Tarifnavigator guenstiger surfen. a href='http://www.freenet.de/tipp/premium/tarif/index.html' target='_blank'uhttp://www.freenet.de/tipp/premium/tarif/index.html/u/a __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! a href='http://sbc.yahoo.com' target='_blank'uhttp://sbc.yahoo.com/u/a -- 60% Onlinekosten sparen! Jetzt Premium Mitglied bei freenet.de werden und mit dem Tarifnavigator guenstiger surfen. http://www.freenet.de/tipp/premium/tarif/index.html
RE: [ANNOUNCEMENT] Server Test 91
Harold,
after submitting this patch I recognized a rare case memory leak in
winMultiWindowGetClassHint() if the memory allocation for res_class fails.
This is fixed by the appended small patch, which is based on the previous one.
(Hope the indention is right)
Ralf
--
$ diff -up winmultiwindowclass.c.orig winmultiwindowclass.c
--- winmultiwindowclass.c.orig 2003-06-04 19:48:36.0 +0200
+++ winmultiwindowclass.c 2003-06-04 19:55:38.0 +0200
@@ -76,8 +76,11 @@ winMultiWindowGetClassHint (WindowPtr pW
(*res_class) = malloc (len_class + 1);
-if (!*res_class)
- return 0;
+if (!*res_class)
+ {
+free(*res_name);
+return 0;
+ }
strcpy ((*res_class), ((char *)prop-data) + 1 + len_name);
--
Ralf,
Thanks.
http://www.msu.edu/~huntharo/xwin/shadow/XWin-Test91-DEBUG.exe.bz2
Harold
Ralf Habacker wrote:
Harold Hunt wrote:
5) winclass.c, winclass.h - Rename these files to
winmultiwindowclass.c and winmultiwindowclass.h, respectively, since
they are only used in MultiWindow mode. Prefix the functions in these
files with MultiWindow. (Harold L Hunt II)
The appended patch contains some function parameter checking to
avoid segfaults
in case of invalid parameter values.
It is based on the xwin-Test91 release.
RE: [ANNOUNCEMENT] Server Test 91
Harold Hunt wrote: 5) winclass.c, winclass.h - Rename these files to winmultiwindowclass.c and winmultiwindowclass.h, respectively, since they are only used in MultiWindow mode. Prefix the functions in these files with MultiWindow. (Harold L Hunt II) The appended patch contains some function parameter checking to avoid segfaults in case of invalid parameter values. It is based on the xwin-Test91 release. Ralf param_check_xwin91.dif Description: Binary data
RE: Custom icons per window class/name patch
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Earle F. Philhower III Sent: Monday, May 26, 2003 7:28 PM To: [EMAIL PROTECTED] Subject: RE: Custom icons per window class/name patch Howdy Ralf, At 09:39 AM 5/26/2003 +0200, you wrote: while testing some KDE3 applications, I recognized that the application window class distinction by WM_CLASS isn't enough, because kde applications uses different icons for different windows of an application. This applications uses the WM_WINDOW_ROLE property to distingh for example message box windows from basic windows. Currently the icons of the main window are overwritten, because all the windows of an application share the same window class. The appended patch fix this. (Additional this patch fixes one segfault in GetClassHint, I have recognized causes by a null WindowPtr) I'm not a KDE user so I can't test this directly, but are you sure that the window role name is unique between applications? Would it make sense to use the Windows class name a function of both the res_role, res_name and res_class? Or is there only one KDE file open box that all apps would share? The first. 1. I've done some research relating to this stuff and found some specification of this in the Inter-Client Communication Conventions Manual (ICCCM) for example on http://tronche.com/gui/x/icccm/sec-5.html: It is necessary that other clients be able to uniquely identify a window (across sessions) among all windows related to the same client-ID. For example, a window manager can require this unique ID to restore geometry information from a previous session, or a workspace manager could use it to restore information about which windows are in which workspace. A client may optionally provide a WM_WINDOW_ROLE property to uniquely identify a window within the scope specified above. The combination of SM_CLIENT_ID and WM_WINDOW_ROLE can be used by other clients to uniquely identify a window across sessions. If the WM_WINDOW_ROLE property is not specified on a top level window, a client that needs to uniquely identify that window will try to use instead the values of WM_CLASS and WM_NAME. If a client has multiple windows with identical WM_CLASS and WM_NAME properties, then it should provide a WM_WINDOW_ROLE property. The client must set the WM_WINDOW_ROLE property to a string that uniquely identifies that window among all windows that have the same client leader window. The the spec. A practical hint one can find in http://mail.gnome.org/archives/wm-spec-list/2003-January/msg00010.html, where one of the kde core developer suggests the following: WM_CLASS+WM_WINDOW_ROLE are supposed to uniquely identify every window in an application (+PID if needed). PID might be necessary in multi monitor environments to distingh different sessions like starting the same xapp on two several servers, which might be have different window setting options based on the specific machine x or gui settings. 2. I have asked several kde apps for their implementation and recognized that this isn't implemented very straight. Some applications defines WM_WINDOW_ROLE application wide uniq and some does not so. Your suggestion WM_CLASS+WM_WINDOW_ROLE appended by [+PID] will be the best for all cases, i think. kate: WM_CLASS(STRING) = kate, kate WM_WINDOW_ROLE(STRING) = kate-mainwindow#1 khelpcenter: WM_CLASS(STRING) = khelpcenter, khelpcenter WM_WINDOW_ROLE(STRING) = MainWindow konsole: WM_CLASS(STRING) = konsole, konsole main window - WM_WINDOW_ROLE(STRING) = konsole-mainwindow#1 tip of the day - WM_WINDOW_ROLE(STRING) = unnamed about dialog- WM_WINDOW_ROLE(STRING) = aboutkde settings dialog - WM_WINDOW_ROLE(STRING) = unnamed keditbookmarks main window - WM_WINDOW_ROLE(STRING) = keditbookmarks-mainwindow#1 kicker WM_CLASS(STRING) = kicker, kicker WM_WINDOW_ROLE(STRING) = Panel ... 2. KDE uses 16x16x16 sized icons for modal dialogs (48x48x16 for regular icons), which seems to be not designed for displaying un the task bar or ALT-TAB process switching window. Currently this type of icons are displayed wrongly. CreateIcon() seems to stretch this icon so this result in displaying black horizontal stripes. This problem would be solved, when issue 1. would be implemented. Can you check the raw bits that are being passed to the CreateBitmap for this icon? I've run several 16x16 icon apps (ethereal and konqueror) and they all work fine. The icon_pixmap seems to be displayed fine in the window and taskbar, only in the task switcher the result is very bad. (Of course windows will pixel double the 16x16 icon to 32x32 for the task switcher...). CreateIcon does work for 16x16 bitmaps, but if there was a 32x32 icon registered for the window class before, maybe Windoze doesn't like swapping it for a 16x16 with the GCL_HICON... The problem is kde and gnome specific. The kde3 window manager (kwin) taks switcher displays two
RE: Custom icons per window class/name patch
Erle wrote: I just did some runs with the commercial apps I use at work, and can see that many do *not* create custom classes or window_roles for each type of window. KDE and gnome apps does. I think the best thing to do for the class naming is to just use an incrementing number and make each window its own class. This was my first attempt. Then when the window is deleted we will just UnregisterClass(GetClassName(hwnd)) and NOT have any GDI leaks. ... because of not freeing the Window Class after destroying a window ? There is no need for this. MSDN says, you can call UnregisterClass() after every window destroying. If the class could not be found or if a window still exists that was created with the class, the return value is zero. To get extended error information, call GetLastError. Before calling this function, an application must destroy all windows created with the specified class. All window classes that an application registers are unregistered when it terminates. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/Win dowsUserInterface/Windowing/WindowClasses/WindowClassReference/WindowClassFuncti ons/UnregisterClass.asp We have a GDI leak now because of this, so it will kill two birds with one stone. Under NT or later this leak shouldn't be a problem, but 95 based OSes share a common 16-bit pool amongst all apps, and may run out causing really bad things to happen if the server is running for a long time. We also have a GDI leak on the HICONs which need to be properly disposed of before they're lost completely. With a separate class per window this will be easier, since no window will share a HICON with another. ... but there are many more windows with the default x icon and not with the icon of the basic application window. Fixing this means adding some stuff to deal the stuff, the Window Class concept does. I have some questions about this: 1. Does UnregisterClass() frees the assigned ICON or has it to be free'd manually ? 2. The CreateIcon() and LoadImage() stuff does not frees the previous icon. Could this not be fixed ? Does this not fix mostly GDI leaks ? 3. Every time a WMhints message comes in a new icon will be created. What about checking if this icon was already created and avoid every time recreating ? The pixmap id could be stored in the private window area. The class, name, and role can still be used for the 2nd chance iconification of windows (the LoadImage() call referencing xwin.ini). You mean canceling the wm-hints pixmap features ? That means excluding all x apps, which does provide such informations. I'll throw a patch together tonight for this unless someone beats me to it. Any comments ? Cheers Ralf
RE: Custom icons per window class/name patch
Hi Ralf, Huh, where was the problem ? I've build it after applying all recent patches from Earle. When I applied Earle's and your patches in sequence, clean, from Harold's test86 sources I got some minor hiccups on the last .dif. I have seen, that you have got already this problems. Thanks. I've noticed that KDE icons have problems in their transparent backgrounds(e.g. konqueror). I suspect that the colour mask (xor) algorithm's from Earle may have a minor weakness with some pixmap sources (png's or KDE types?). probably caused by 16x16x16 pixmaps. I'm no expert in bit mangling graphics formats, and Earl's algorithms look tricky to me, so I'll put my hands up here. Mind you, the icon handling is pretty impressive as it stands! I'll try and capture hicons/CreateBitmap data that goes wrong (I'm displaying 16 bit 1280x1024 incase this is device dependent?) I don*t know, what*'s was going wrong, but anyway, streching the 16x16 bit images the 32x32 for the task switcher will not give good results. KDE apps uses the _NET_WM_ICON property to provide a higher sized image. See my other mail for more informations. Is there anyone there who has a linux machine with KDE 3 running, which could be accessed through the internet, so that Erle could connect to this machine and try by himself ? BTW: One could use the KDE 3.1.1 release from the kde-cygwin port, but I don't know I this would be to heavy ? I'm using this for testing this icon stuff. It need some more time for starting a kde application, but with a fast machine it would be possible.
RE: Thanks for donations
Hasn't Harold suggested that people could contribute links for their own donations? I don't think it makes sense for someone to be attempting to dole out money. What would the criteria be? Better to let the users decide. I understand your point, but who in the user community would know who to donate too if there are multiple paypal accounts. Unless you read CHANGELOG's the user community wouldn't know who to donate to. I think this too. Relating to this i've got a hint, that some people doesn't like paypal because of security problems and that some projects are using another donation system for example www.kagi.com. This should be only a note. Ralf
RE: Using XFree to replace explorer.exe as the window manager for Windows
I am wondering if anyone has attempted to use Cygwin/XFree86 to replace explorer.exe as the window manager. David Fraser has reported done so with kde-cygwin. See http://lists.kde.org/?l=kde-cygwinm=103072530327420w=2 for further infos. Regards Ralf
RE: Cygwin GNOME 1.4 binary packages
I am definitely interested in a cygwin GNOME binary, like the KDE binary which is available on sourceforge using the standard cygwin setup.exe (but I have not yet managed to get running properly on Win98) Where are the problems with win98 ? Ralf
RE: XFree leaking memory?
In other words, it might not be able to follow NEW or MALLOC, because the object format might be too different. Try the mem_watch tool in the kde-cygwin cvs area http://sourceforge.net/cvs/?group_id=27249, which hooks any memory relating call. $ less README Memory Watcher == This is a little library for tracing memory related api calls on win32 using gcc. Features: - detection of unfree'd memory regions - traces each malloc(), calloc(), realloc() and free() call - collects size and addresses of allocated area - runtime switchable logging support of hooked function See INSTALL for installation hints. The only thing you have to do is to adding a call after main() and perhaps one call for printing the results at the end of main(). Try $cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/kde-cygwin login empty password $cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/kde-cygwin co tools/mem_watch $ make $ make check $ test.exe
RE: XFree leaking memory?
There is also this tool - http://devel-home.kde.org/~sewardj/ Not sure if it can be used on Cygwin, but I think it might. It depends on the glibc and this isn't ported to cygwin yet. Ralf
RE: question on running kde under cygwin/xfree86
The X server fires up, but KDE never initializes. back at the cygwin prompt I get this: waiting for X server to begin accepting connections . .. .. .. after I manually close the X server I see: giving up. xinit: Permission denied (errno 13): unable to connect to X server xinit: No such process (errno 3): unexpected signal 2. Ideas anyone? try http://kde-cygwin.sourceforge.net/faq/kde2.php#D9 Regards Ralf
Re:[ANNOUNCEMENT] Server Test 68
Hi all, 1) Add support for non-rectangular windows created by the X Shape Extension while in Rootless mode (e.g., ``XWin -rootless''). (MATSUZAKI Kensuke) Thanks to all who are working to get ready this feature. I've tried to run kwin/kmail/korganizer/konqueror and other kde apps on cygwin/xfree in rootless mode and they works fine. :-) I intend to make XFree86-xserv-4.2.0-15 the stable release as soon as I receive some feedback that it does not introduce any substantial bugs. ... then on the kde-cygwin site there will be some screenshots with windowed kde applications. Great work. Ralf
RE: QT2 ready for ITP?
On Wed, Jul 31, 2002 at 07:51:08AM -0700, Nicholas Wourms wrote: --- Christopher Faylor [EMAIL PROTECTED] wrote: On Wed, Jul 31, 2002 at 11:14:50AM +0200, Ralf Habacker wrote: Any comments ? Are there any licensing issues with qt? Is the open source license compliant with cygwin's? http://cygwin.com/licensing.html Ghostscript's license [The aladdin license (APFL?)] is much more restrictive than the QPL. If we are not in compliance with Ghostscript then that is a problem. It is entirely separate from whether qt is compatible with the GPL + Cygwin. If you were aware of issues with ghostcript you should have raised them. Besides when you compile QT, you'll get a screen which shows how the QPL is mutually inclusive of the GPL. So, if I show you a screen which says it's exclusive of the GPL, you'll just give up? Since I don't accept the word of every person with a web site out there who thinks they are compliant with the GPL, I don't see why I should accept the words of a screen. Is there an independent corroboration of this anywhere? This may not be an independent corroboration for you, but what Nicholas means is the screen below, which is printed before configuring qt and it said that one can choose the license beetwen qpl or GPL. It tells its own tale. ~/src/cvs.kde-cygwin.sf.net/qt-2 $ cygwin/configure.cygwin This is the Qt Free Edition. You are licensed to use this software under the terms of either the Q Public License (QPL) or the GNU General Public License (GPL). Type 'Q' to view the Q Public License. Type 'G' to view the GNU General Public License. Type 'yes' to accept this license offer. Type 'no' to decline this license offer. Do you accept the terms of the license? Ralf
RE: QT2 ready for ITP?
Well, then, why all of the fuss in cygwin-patches where you were trying to modify windows headers? It doesn't seem like this is an entirely unix port: http://cygwin.com/ml/cygwin-patches/2002-q3/msg00175.html So, while this may have been discussed before, I'm not sure we had all of the details then. Well actually, it would be totally Win32 header free, if it weren't for the fact that Chris January added an original patch to better display current drives in konqueror. As for the dns stuff, that was already present in the Unix/X11 version, which is covered by the QPL/GPL. I think it is necessary to say detailed, what the changes on the qt port are. The qt-2 port of the qt/x11 is based on the official qt/x11-2.3.1 release from trolltech. Qt manages the platform specific parts in os specific files like filenane_x11.ext or filename_win32.ext. In the qt/x11 release the _win32. files are not contained, although some win32 code (dns code for example) is still contained with the lack of an os detection code, for which I have added code, based on an msdn example. Chris January has written some native stuff for file open/reading, I have added some native stuff for a faster Qdir implementation using Find(First|Next)File(). Does anyone see a problem with this ? Ralf
QT2 ready for ITP?
Ralf Habacker wrote: One thing that should be discussed will be how to divide the packages, which was stated (a little) in cygwin-xfree. Currently I'm preparing a (from my point of view usefull) schema and will send it to the list the next days, so that packaging could start. Packaging should be adapted by the users need, so the first question is what does the users expect. I assume the following: 1. Users want to download and start qt applications. They need (a) the package containing the qt dll and the (b) requested application package. 2. Users like to port their unix qt application to cygwin. They need at first (c) import libs and the headers, (d) perhaps the docs. For testing they need (e) the package containing the qt dll probably with debugging informations. 3. User want to learn qt programming. They need (c) the import libs, headers, (f) the examples, tutorials, (d) the docs and (e) the package containing the qt dll (with debug informations). (a) qt dll without debug informations (b) qt applications (c) import libs and header (d) qt docs (e) qt dll with debugging informations (f) examples and tutorials (a) should be released anyway (b) also for (c), (d), (e) and (f) there are several posibilities. Any comments ? Ralf ___ kde-cygwin mailing list [EMAIL PROTECTED] http://mail.kde.org/mailman/listinfo/kde-cygwin
QT2 ready for ITP?
Ralf Habacker wrote One thing that should be discussed will be how to divide the packages, which was stated (a little) in cygwin-xfree. Currently I'm preparing a (from my point of view usefull) schema and will send it to the list the next days, so that packaging could start. Packaging should be adapted by the users need, so the first question is what does the users expect. I assume the following: 1. Users want to download and start qt applications. They need (a) the package containing the qt dll and the (b) requested application package. 2. Users like to port their unix qt application to cygwin. They need at first (c) import libs and the headers, (d) perhaps the docs. For testing they need (e) the package containing the qt dll probably with debugging informations. 3. User want to learn qt programming. They need (c) the import libs, headers, (f) the examples, tutorials, (d) the docs and (e) the package containing the qt dll (with debug informations). (a) qt dll without debug informations (b) qt applications (c) import libs and header (d) qt docs (e) qt dll with debugging informations (f) examples and tutorials (a) should be released anyway (b) also for (c), (d), (e) and (f) there are several posibilities. Ralf, Here is how I would like to do it: package #1 - qt-2.3.1-n.tar.bz2: Contains (b) with basic docs (REDAME's, etc.). (b)'s applications will be transformed from foo.exe to foo_2.3.exe during make install. A post-install script will make symlinks to the standard names of the applications. package #2 - libqt-2.3.1-n.tar.bz2: Contains (a) only package #3 - libqt-devel-2.3.1-n.tar.bz2: Contains (c) + (d) w/post-install script to symlink to the default headers and libraries. Also the post-install script will generate suitable /etc/profile.d scripts to set the environmentals. package #4 - libqt-extras-2.3.1-n.tar.bz2: Contains (f) only package #5 - qt-2.3.1-src-n.tar.bz2 Contains full qt-2.3.1 sources for rebuilding plus a method #2 script to automate this task. As for (e), I see no need to release a debug version, as people will be able to recompile the package with debugging if they want it. If we want to have qt2 and qt3 coexisting, then we need to provide a suitable directory structure for the Cygwin mirrors. To prevent clobbering, and improper parsing by upset, we will put the packages in the following directory structure: qt/qt2.3/ - #1 #5 qt/qt2.3/libqt2.3/ - #2 qt/qt2.3/libqt2.3-devel/ - #3 qt/qt2.3/libqt2.3-extras/ - #4 This is how I've been packaging the berkeley db, and it works quite well. To explain my rationale, considier what would happen if the qt people released qt-3.1.X, which was slightly incompatible with some application source code built with qt-3.0.X. With my method, the last installed qt and/or libqt-devel package becomes the default, but DOES NOT clobber the other qt and/or libqt-devel packages. This is extremely handy when you are trying to target a particular version of the qt api. I'm still working on my scripts, but eventually I'll have menu-based selection of which version of the API should be default (maybe it will be a readline based c application). Cheers, Nicholas __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ___ kde-cygwin mailing list [EMAIL PROTECTED] http://mail.kde.org/mailman/listinfo/kde-cygwin
RE: QT2 ready for ITP?
Ralf, Here is how I would like to do it: I aggree mostly with your view, but I see the best in dividing the stuff into the following packages (a) qtlib - qt dll without debug information and basic docs (REDAME's, etc.). This is the minimum for using additional qt applications and it should contain the basic docs (b) qttools or qtdevtools - qt development tool like designer (linguist, assistant for qt3) (c) qtdevel- import libs and header and qt docs for compiling qt applications (d) qtsource - contains all the source of the qt package from the kde-cygwin cvs (e...z) qt... additional 3rd party qt applications like qtmemory or xdu ... (for example the freeware from http://www.trolltech.com/developer/freesoftware/index.html) or doxygen or whatever you can imagine. This packaging is based on the fact that qt is an application development framework and tutorial and examples are not really needed for running qt applications, they are more lessons, which the users should do it yourself, so the qtlib must be available. The devel and tool packages are only necessary for developing qt-applications and they may be one packages, so that at least only the devel package remains. (a) qtlib - qt dll without debug information and basic docs (REDAME's, etc.). This is the minimum for using additional qt applications and it should contain the basic docs (b) qtdevel- import libs, header, docs and tools for compiling qt applications (c) qtsource - contains all the source of the qt package from the kde-cygwin cvs (d...z) qt... additional 3rd party qt applications like qtmemory or xdu ... (for example the freeware from http://www.trolltech.com/developer/freesoftware/index.html) or doxygen or whatever The one question, which is left is, should the source packages added (1) as separate package or should it be added (2) in a setup.ini source line of the qtlib od qtdevel package. I prefer adding the source package to the qtlib package, because this is the basic package. Probably we could add the qtsource package to the qtdevel package too, but I don't know if it works. If we want to have qt2 and qt3 coexisting, then we need to provide a suitable directory structure for the Cygwin mirrors. To prevent clobbering, and improper parsing by upset, we will put the packages in the following directory structure: qt/qt2.3/ - #1 #5 qt/qt2.3/libqt2.3/ - #2 qt/qt2.3/libqt2.3-devel/ - #3 qt/qt2.3/libqt2.3-extras/ - #4 In the cygwin release directory there are some examples for using major bases directory layouts, which contains several updates in one dir. ./libpng/libpng2/libpng2-1.0.12-1-src.tar.bz2 ./libpng/libpng2/libpng2-1.0.12-1.tar.bz2 ./libpng/libpng10/libpng10-1.0.14-2-src.tar.bz2 ./libpng/libpng10/libpng10-1.0.13-3-src.tar.bz2 ./libpng/libpng10/libpng10-1.0.13-1.tar.bz2 ./libpng/libpng10/libpng10-1.0.13-3.tar.bz2 ./libpng/libpng10/libpng10-1.0.14-2.tar.bz2 ./libpng/libpng12-devel/libpng12-devel-1.2.4-2.tar.bz2 ./libpng/libpng12-devel/libpng12-devel-1.2.3-1.tar.bz2 ./libpng/libpng12/libpng12-1.2.3-1.tar.bz2 ./libpng/libpng12/libpng12-1.2.4-2.tar.bz2 qt2 will not have any major abi changes in the future,so it is enough to build like that: qt/qt2/qtlib2/ qt/qt2/qtdevel2/ qt/qt2/qt/ (for additional qt applications) qt/qt2/qtlib2/ qtlib-2.3.1-1.tar.bz2 qtlib-2.3.1-1-src.tar.bz2 setup.hint qt/qt2/qtdevel2/ qtdevel-2.3.1-1.tar.bz2 setup.hint qt/qt2/qt.../ qt...-x.y.z-n.tar.bz2 qt...-x.y.z-n-src.tar.bz2 setup.hint for qt3 we could do in the same manner except that we us qt/qt3/qtlib3/ qt/qt3/qtdevel3/ qt/qt3/qt/ (for additional qt applications) (b)'s applications will be transformed from foo.exe to foo_2.3.exe during make install. A post-install script will make symlinks to the standard names of the applications. I see no need for this. Because the qt2 abi will not be changed a simple etc/profile.d script would do the things needed for setting the propper environment: $cat /etc/profile.d/qt2.sh export QTDIR=/usr/lib/qt2 export PATH=$QTDIR/bin:$PATH export MANPATH=$MANPATH:$QTDIR/doc/man Of cource it means that all qt application shoud be installed into /usr/lib/qt2, which is true for the basic qt tools. What about 3rdparty qt packages. Where should they been installed ? Also in /usr/lib/qt2 or should Any comments ? Ralf Ralf
[ANNOUNCEMENT] kdenetwork-2.2.2 beta 1 released
Hi all, today the first beta release of the kdenetwork-2.2.2 packages is available. It contains kmail 1.3.1, which is mostly full usable as free kde based email client under windows. Other applications of this package will follow in later releases if there is interest on them. Try it and have fun Ralf Habacker
RE: Incorrect version in packages names
The naming was probably inherited from linux, where it is possible to have both kde (1) and kde (2) and kde (3) all installed on the same machine. Therefore, each needs different basename. Yes, this is it. If the kde-cygwin folks want to maintain that package-name distinction, then they should just use kdelibs_2 instead of kdelibs-2 as their basename. Then upset and setup will be happy -- and end users will be able to install both kdelibs_2 and kdelibs_3. Thanks for this hint. Ralf
RE: Incorrect version in packages names
The naming was probably inherited from linux, where it is possible to have both kde (1) and kde (2) and kde (3) all installed on the same machine. Therefore, each needs different basename. If the kde-cygwin folks want to maintain that package-name distinction, then they should just use kdelibs_2 instead of kdelibs-2 as their basename. Then upset and setup will be happy -- and end users will be able to install both kdelibs_2 and kdelibs_3. What about kde-x. Must it be named kde_x ? Ralf
RE: Incorrect version in packages names
What about kde-x. Must it be named kde_x ? Couln't those fixes be included in the base xfree package? Having a package that overwrites a file from another package gives problems if you deinstall the latter: you lose the file from the first... Unfortunally for some reasons no, because 1. this patches relates to cygipc based shm support, which isn't a cygwin packages and should not be used in a cygwin package (the xfree packages). There were some threads relating to this topic in the past on cygwin/cygwin apps. At the time the shm support will be a stable part of the cygwin dll, xfree could be recompiled with shm support. 2. some patches are currently not part of the official xfree release yet (for example xft patches and ice delay patch, see release notes below) Release 1.3 libXft: - added qt3 symbols to Xftlib libICE: - removed 5 seconds delay in libICE if file attributes don't match Release 1.2 - renamed package to kde-x Xwin.exe: - added MIT-SHM extension Ralf
RE: xterm fails to start with setuid failed: Permission denied
Hi, I'm getting the same for xterm. My Cygwin / XFree86 installation from about three months ago was running fine, but when I upgraded it yesterday I get the same problem, at least when running as a domain user. Xterm works when I run it as the local administrator though. I also have problems with xcalc (window is filled with the 0 button), and xedit (displays the message Error: Shell widget fileMenu has zero width and/or height and doesn't start). This is both as domain user and local administrator This happens with both XFree86 and StaNet X-Win32 as X servers. Is there a problem with the client utilities build? This is caused by a stricter uid/gid handling in cygwin 1.3.11. I've stumbled about it and Corinna Vinschen told me to make sure, that for all user, who could own files, which you like to access has to be a corresponding entry in /etc/passwd. See http://www.cygwin.com/ml/cygwin/2002-06/msg01198.html for more informations.
significant delay in xinit detected
Hi all, while working with kde/cygwin and xfree/cygwin I recognized a significant timeout of xinit, after starting the x server andbefore starting the x client relevant stuff. It seems that xinit goes into a timeout while waiting for the X process, because the delay does not depend on how long the xserver needs (I recognized this on a very fast machine, on which the xserver only needs 1/2 second to start). xinit waits then 5 seconds before starting the .xinitrc script. I remember on the first days on kde2 we have a similar problem with kdeinit, which was solved by Chris January. Because currently I have no idea, whats going on, is there anyone who can give a hints for this ? Regards Ralf Habacker
RE: significant delay in xinit detected
while working with kde/cygwin and xfree/cygwin I recognized a significant timeout of xinit, after starting the x server andbefore starting the x client relevant stuff. It seems that xinit goes into a timeout while waiting for the X process, because the delay does not depend on how long the xserver needs (I recognized this on a very fast machine, on which the xserver only needs 1/2 second to start). xinit waits then 5 seconds before starting the .xinitrc script. Looking a little deeper into the source shows that the timeout is about 15 sec, not only 5, and it seems that xinit does not recognizes the running x process. Ralf
RE: KDE 2.2.2 beta1 released
I think one of the major obstacles is to get the mainline cygwin
maintainers to approve the /opt directory tree. There has been some
discussion of this in the past, but it always ends in not wanting it
because they say so. One might say why not
/usr/X11R6/{qt2|qt3|kde2|kde3}? To that I say bah! The way it is
supposed to be is /opt is for large or excessively significant addons to
the system. This way one avoids cluttering up the X11R6 directory. Most
distros use /opt for kde and Ralph currently uses it. Is there really a
good reason why cygwin shouldn't use /opt for kde (possible gnome as
well)? Feel free to disagree...
The only point to add is that for qt the default installation path is
/usr/lib/{qt2|qt3}.
Currently I'm using /usr/local/lib/qt... because it isn't a cygwin distributed
package like cygipc.
I vote also for using a new directory structure like ...
/opt/kde[123] for kde
/usr/lib/qt[123] for qt
Ralf
RE: KDE 2.2.2 beta1 released
Nicholas Wourms schrieb: I hate to chime in with a me too, but I have been experiencing the same issue. I contacted Robert Collins about the issue and he said he would look into why setup is doing that. Haven't heard from him yet though... Setup is doing what? They mean the bug with the GNU long name extension, which results in failed kdebase installation, we have spoken about and for which I have submitted a patch. Do you have applied this patch into cvs ? Regards Ralf
RE: KDE 2.2.2 beta1 released
There is a new snapshot (v 2.249) available that has Ralf's patch in it. Thanks Robert Ralf
RE: KDE 2.2.2 beta1 released
This is great! I love to see the progress with KDE on Cygwin. Keep up the good work. Maybe in about a year we'll be able to distribute KDE on Cygwin via Cygwin setup.exe packages :) I assume, this point will be happens earlier. :-) Ralf
RE: Cygwin - More exports for libXft
Export some new symbols from Xft that are needed for qt 3.x. This has been build checked (i.e., XFree86 was built, but I have not tried to build qt 3.x against it yet). In the qt-3 dir of the kde-cygwin cvs area you can find a cygwin buildable qt-3 library. Ralf
missing symbols for qt3
Hi all, the 4.2.x release of the xftlib does not export some symbols required by qt 3.x. Are there any doubts fo adding this in further xfree/cygwin releases ? Index: lib/Xft/Xft-def.cpp === RCS file: /cvs/xc/lib/Xft/Xft-def.cpp,v retrieving revision 1.2 diff -u -3 -p -B -u -b -B -p -r1.2 Xft-def.cpp --- lib/Xft/Xft-def.cpp 2001/04/05 19:29:38 1.2 +++ lib/Xft/Xft-def.cpp 2002/05/16 07:53:29 -145,6 +145,12 XftInitFtLibrary XftConfigDirs XftDirScan XftDirSave - +/* the next are needed by qt 3.0 */ +XftGlyphLoad +XftGlyphCheck +XftFreeTypeGlyphExists +XftFreeTypeOpen +XftFreeTypeClose +XftRenderString16 Regards Ralf
RE: 5 seconds delay in libICE if file attributes doesn't match
I don't know but I wonder why it is called on all platforms *except* Cygwin. I'll look at the CVS history today. In libICE this is called on every platform, in libKDEICE, which is derived from libICE for using with DCOP, this is removed on every platform. Ralf
RE: MIT shared memory extension
This is off-topic for the xfree mailing list, it's really a developer or general topic. Anyway Should we move this to the cygwin list ? I'm not subscribed to the develop list. 1. Why do you use st_dev explicity. Isn't ftok() only for files ? From the ftok documentation: The ftok() function returns a key based on path and id that is usable in subsequent calls to msgget(), semget() and shmget(). The path argument must be the pathname of an existing file that the process is able to stat(). So st_dev seems to make no sense for me and could be removed. Possibly. If the file can be stat'd - and devices can - we should check it, no? Yes, this can be done after the stat() call. 2. Does st_ino creates uniq inodes rsp. hash values ? If so, why not (CASE1) adding an ascii representation of id to the path and calling hash_path_name() (the function which creates statbuf.st_ino) or (CASE2), using id as hash value for hash_path_name() like the following code. hashs collide. key_t's can not collide under any circumstance, and must be deterministic (i.e. not dependent on currently issued keys). But how do you ensure this in the current implementation ? st_ino contains a hash value. So this problem concerns the current implementation and the suggestion I've made. How do you suggest that you avoid hash collisions? With my suggestion I haven't adressed the problem of avoiding hash collisions. I only have addressed the newlib patch you suppose. Sorry :-( BTW: I have additional looked into the cygipc implementation. They uses only the lower word of st_ino and lowest byte of st_dev and lowest byte of id. And this seems to work, although the must have this hash collision problem even more, doesn't it ? May be this is another way to prevent the newlib patch. Regards Ralf
RE: MIT shared memory extension
Robert Collins wrote:
In short, I don't like the idea of making key_t 32 bits.
I have taken deeper into ftok and have some questions:
1. Why do you use st_dev explicity. Isn't ftok() only for files ?
From the ftok documentation:
The ftok() function returns a key based on path and id that is usable in
subsequent calls to msgget(), semget() and shmget(). The path argument must be
the pathname of an existing file that the process is able to stat().
So st_dev seems to make no sense for me and could be removed.
2. Does st_ino creates uniq inodes rsp. hash values ? If so, why not (CASE1)
adding an ascii representation of id to the path and calling hash_path_name()
(the function which creates statbuf.st_ino) or (CASE2), using id as hash value
for hash_path_name() like the following code.
key_t
ftok(const char *path, int id)
{
struct stat statbuf;
// call stat() only as file existing check
if (stat(buf, statbuf))
{
/* stat set the appropriate errno for us */
return (key_t) -1;
}
#ifdef CASE1
char buf[MAX_PATH];
sprintf(buf,%s%08x,path,id);
return hash_path_name(0,buf);
#else /* CASE2 */
return hash_path_name(id,buf);
#endif
}
This would allow using the current 32 bit key_t implementation.
Ralf
FW: MIT shared memory extension
Ups, there were some wrong usages of path/buf in the last code example. Sorry.
key_t
ftok(const char *path, int id)
{
struct stat statbuf;
// call stat() only as file existing check
if (stat(path, statbuf))
{
/* stat set the appropriate errno for us */
return (key_t) -1;
}
#ifdef CASE1
char buf[MAX_PATH];
sprintf(buf,%s%08x,path,id);
return hash_path_name(0,buf);
#else /* CASE2 */
return hash_path_name(id,path);
#endif
}
RE: MIT shared memory extension
The definition of key_t in newlib is a 32bit int, for cygdaemon it needs
to be 64 bit to store the inode and the index cleanly. Redefining that
will break every cygipc linked application when they are rebuilt, until
cygipc is rebuilt against the new source. However rebuilding cygipc will
break every already linked app. So until the cygdaemon shm code is
complete, Chuck and I figured that it was not worth putting everyone
through the agony of a backwards incompatible ABI change.
What about using a new type respective casts for cygdaemon. This would not break
key_t compatibility and allows to migrate single application to cygdaemon, while
others works with cygipc (at least for a limited time) ?
./include/sys/types.h:typedef long key_t;
What about interpreting key_t as pointer to shm_key_t or something else ?
Okay, this causes to support an internal list of shm_key_t elements :-(
But when I see right, you have to maintain already such a list
class shmnode {
public:
class shmid_ds * shmds;
int shm_id;
class shmnode *next;
+ shm_key_t key;
- key_t key;
HANDLE filemap;
HANDLE attachmap;
class _shmattach *attachhead;
};
The interfaces of the relates functions could be used as before, only the
interpretation is changed.
key_t ftok(const char *, int)
{
...
return node-key;
}
int shmget(key_t key, size_t, int);
...
shm_key_t *akey = (shm_key_t *)key;
...
What do you mean, could this be a workable solution ?
Ralf
RE: MIT shared memory extension
It works, we have done so for the kde-cygwin port Yeah, but it requires CygIPC, doesn't it? Yes, which is not distributed with cygwin because of license problems,.. the old story ... and I know, about what you like to talk - the new cygwin daemon, isn't it ? :-) BTW, has anybody tried to run kde-cygwin using the new cygwin-daemon to provide the IPC services? No, we haven't yet. I have already thought about using the cygwin daemon, but currently there are some reason why this isnt't happened. The first reason is, I don't know how stable and performant the cygwin ipc stuff works. I have thought about checking this, but found no time to do so. Perhaps I found some time after the kde 2.2.2 b1 release day next week. The second reason is, that it does not make sense to compile kde-cygwin with the cygwin daemon and use cygipc for xfree. The consequence of this seems to me to compile xfree with cygwin daemon too, but I does not have the knowledge and time to do this job. (I don't like to say that the xfree guys has to do so, only that I can't) subset of the three main IPC mechanisms (semaphores, messages. shared memory) -- but I don't remember if shm was part of that subset... If I remember right, it has. Anyway, even if the cygwin-daemon DOES provide the necessary IPC features, you'd probably need to recompile kde-cygwin against it instead of CygIPC. Yes, this is sure. --Chuck the cygwin-daemon code was recently merged into CVS; the snapshots have the functionality but the daemon itself is not turned on by default. Just like ipcdaemon.exe, you have to start up the cygwin-daemon yourself. For more info, see the cygwin-developers mailing list archives. Thanks for this info Ralf
RE: MIT shared memory extension
It is possible though to compile xfree86 for cygwin with that enabled, but it haven't been tested, check the mailinglist. It works, we have done so for the kde-cygwin port Regards Ralf
problems with kde 1.1.2 kcontrol solved
Hi, some month ago I've encountered a problem with kde 1.1.2 kcontol. The problem was, that a once called kcontrol page was hidden for further calls. Currently I have checked this with the xfree 4.2.0 release and recognizes that it this problem is gone away. Thanks for this good work. Ralf Habacker
qt 2.3.1 beta 1 release available
Hi all, the kde-cygwin team has released the qt 2.3.1 beta 1 release. This release is an update to the official qt 2.3.1 with all cygwin related patches from the 2.3.0 release applied. The most imported change is optimized qdir/qfile code, which speeds up qt file dialog displaying. You can found qt-cygwin under http://kde-cygwin.sf.net. Ralf
RE: cygpng2.dll missing
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Joshua Lokken Sent: Thursday, April 11, 2002 8:33 AM To: [EMAIL PROTECTED] Subject: cygpng2.dll missing Hello, all: Cygwin is great so far!! Question: After installing KDE and all of the required stuff, when I run kdeinit, I get an error message: The application was not started...cygpng2.dll was not found. Reinstalling the application could solve this problem. Which package installs this dll? I first noticed the error after installing kdelibs, and before installing kdebase. Install the libpng package from the cygwin setup Also, where does the kde startup script need to reside? The startup script startkde resides in /opt/kde2/bin. See http://kde-cygwin.sourceforge.net/faq.php#B12 for detailed instructions to start kde with startx Regards Ralf
RE: rootless mode
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Collins Sent: Monday, April 08, 2002 10:13 AM To: [EMAIL PROTECTED] Subject: rootless mode I've been thinking about rootless mode. Here's my current thoughts: 1) We create a real win32 window for each X window. 2) We use SetWindowLong to store the X window pointer in the WIN32 struct, so that when a message arrives to that windowclass's WindowProc, we can lookup the X window the message belongs to. 3) We use WindowPrivates to store the WIN32 related window HANDLE and other gunk. It may be that you already know this, but do you have seen the links about the ntxlib (and perhaps the libw11 project) on http://kde-cygwin.sourceforge.net/. The rxvt port is based on this stuff. There is a basic implementation of creating windows within a x client lib. Perhaps you can use it for your goal. Regards Ralf
RE: rootless mode
Thank you for pointing this out. :-) I doesn't know that in this detail Regards Ralf
RE: kde 3.0 no icons
snip I know you say that Cygwin/XFree86 is up-to-date, but are you running Cygwin/XFree86 4.2.0? You can check by running 'xdpyinfo' in a local Cygwin/XFree86 session or in a terminal when you are logged into another machine via XDMCP. qt3, which is used by kde3, does not work with the xfree 4.1.x server, so I can confirm, that an update to xfree 4.2.0 is absolutly nesessary. Ralf
RE: DDraw Blt vs BltFast
On Tue, Mar 12, 2002 at 09:30:05AM +0100, Ralf Habacker wrote: I have done some analysing work with this and with the cygwin daemon (cygserver transport classes) there may be a way in the future to implement unix domain sockets with named pipes which speed up unix domain sockets up to 250 MB/s, as I have measured with a quick an dirty sample Fine. But how do you implement them on 9x/Me? If 9x/Me does not support named pipes, why not using the currrent tcp/ip code for this ? Ralf
RE: KDE 2 running problems
Hello, I have a problem running KDE 2 under Cygwin 1.3.9 / XFree 4.2.0: it says The procedure entry point XShmAttach could not be located in the dynamic link library libXext.dll. Really, there's no such entry point in that DLL. I've tried to use DLL from XFree 4.1.0 but it doesn't have that entry point either. Can anyone help? Is there version of XFree allowing to run KDE 2? Is there version of KDE 2 which can run in XFree 4.2? There is a patched version of this lib (and the related server) in the kde-x-1.2 package on the http://kde-cygwin.sourceforge.net download area. -- Yours faithfully, Sergey mailto:[EMAIL PROTECTED] Homepage: http://sage.wallst.ru ICQ: 110345832 MSN: [EMAIL PROTECTED]
RE: KDE under cygwin?
And this is the wrong mailing list for discussing KDE. There is always at least one isn't there? I suppose this is not the place to ask questions related to cygwin? We tried to make this very clear here: http://cygwin.com/lists.html Hi Chris, isn't it possible to implement an automatic redirection (and generating an automatic answer to the sender) identified by specific keywords in the subject line ? Regards Ralf
RE: Cygwin XFree web page looks odd in Mozilla
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Harold Hunt Sent: Friday, January 18, 2002 5:27 AM To: [EMAIL PROTECTED] Cc: cygx Subject: RE: Cygwin XFree web page looks odd in Mozilla Rob - The errors you reported were trivial and are fixed now; they did not affect the rendering of the page. I'm kind of surprised that there were errors at all, as I usually run the validator after submitting. ^ Is this an open source tool ? Ralf Basically. The HTML document type definition is open source, it can be downloaded from http://w3c.org/. Checking a document against a given type definition is usually done with the open source tool NSGMLS: http://www.jclark.com/sp/nsgmls.htm. The HTML Validator provided by http://w3c.org/ is simply a web interface to a program that compares a document with the dtd. I'm not sure if the actual validator front-end is open source, but that doesn't really matter. The address of the W3C HTML Validator is: http://validator.w3.org/ Does that clear things up? Yes Thanks Harold
RE: Building Enlightenment
+ _IceLastMajorOpcode Why does this symbol need to be exported? I need some description to put in the patch submission if I'm going to send this on to XFree86. I've got some errors from people who were compiling the kdelibs 2.1.1 from the kde-cygwin cvs area and the dcopserver depends on this. For kde 2.2.x this isn't recommended, because the dcopserver uses a patched ICE lib, which was located in kdelibs/dcop/KDE-ICE and does not need the origin libICE. I have added this patched lib to the kde-xlib package to support those people. Only for kde I think this patch is not absolutly nessessary to submit to the xfree group, because kde 2.1.1 is obsolate and today I have send a request to the sourceforge stuff to remove the kde 2.1.1 source release from the cvs area. But it may be other apps who like to use this and this seems to me the only symbol which isn't exported yet. Does this have any specific reason ? Why should this symbol not be exported anyway ? This would reduce some question about why this was not exported in the future. What about if someone is going to use the kde 2.1.1 dcopserver for another project. He has to ask again about this missing symbol. Any comments ? Ralf
RE: Building Enlightenment
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Suhaib Siddiqi Sent: Monday, January 14, 2002 11:23 PM To: 'Cygwin-Xfree' Subject: RE: Building Enlightenment Sure, I will put add to URL This is the url to the downloadpage http://sourceforge.net/project/showfiles.php?group_id=27249 The package is currently named kde-xlib-1.1.tar.gz and contains libXext and libICE (missing ICEConnectionNumber symbol) and based on the xfree 4.1 release. The release number my be changed If the libICE in this package is a problem, let me know. Ralf Suhaib -Original Message- From: Ralf Habacker [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 5:19 PM To: Cygwin-Xfree Subject: Building Enlightenment Hi Suhaib, it is interesting for the xfree people to have a link to a patched libxext relating to this thread http://sources.redhat.com/ml/cygwin-xfree/2001-q2/msg01466.html? If so I would send a mail to the cygwin-xfree list with a link to the kde-cygwin project on sourcforge, where one can find such a lib. Ralf
RE: Building Enlightenment
Sure, I will put add to URL This is the url to the downloadpage http://sourceforge.net/project/showfiles.php?group_id=27249 The package is currently named kde-xlib-1.1.tar.gz and contains libXext and libICE (missing ICEConnectionNumber symbol) ^^ Ups. This is not right. It is IceLastMajorOpcode, that is missing. Index: ICE-def.cpp === RCS file: /cvs/xc/lib/ICE/ICE-def.cpp,v retrieving revision 1.5 diff -u -b -B -r1.5 ICE-def.cpp --- ICE-def.cpp 2001/04/18 16:13:18 1.5 +++ ICE-def.cpp 2002/01/14 23:00:34 @@ -69,6 +69,7 @@ _IceTransGetConnectionNumber _IceTransRead _IceTransWrite + _IceLastMajorOpcode /* $Xorg: ICE-def.cpp,v 1.3 2000/08/21 16:42:31 coskrey Exp $ */ /* $XFree86: xc/lib/ICE/ICE-def.cpp,v 1.5 2001/04/18 16:13:18 dawes Exp $ */ If the libICE in this package is a problem, let me know. Ralf Suhaib -Original Message- From: Ralf Habacker [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 5:19 PM To: Cygwin-Xfree Subject: Building Enlightenment Hi Suhaib, it is interesting for the xfree people to have a link to a patched libxext relating to this thread http://sources.redhat.com/ml/cygwin-xfree/2001-q2/msg01466.html? If so I would send a mail to the cygwin-xfree list with a link to the kde-cygwin project on sourcforge, where one can find such a lib. Ralf
RE: problem with using xsetroot without window manager
On Fri, 11 Jan 2002, Ralf Habacker wrote: Hi, I'm using the latest Xserver Test Release and have recognized a problem, when starting some apps without any window manager. For starting kde/kde2 I'm using setxroot to choose another background at the start of the launching process, which needs some time. At this time no window manager is running. With this configuration the color isn't set, but the xserver seems to be restarted. (The window seems to be closed for a little while and comes back) After startung twm, kwm or kwin color setting works. The same effect occurs, when I'm starting for example xdpyinfo without any window manager. When the end of the listing is reached the server restarts. This is the normal behavior. After the last client disconnected, the Xserver resets. Normally xinit is the first process that connects to the Xserver, exec the .xinitrc scripts and exits after the last program from xinitrc (normally the windowmanger) has ended. You can switch the Xserver to not resetting by adding the switch -noreset to the XWin commandline. This is not recommend if you use the Xserver for terminals, since all settings that are made in a session are not reset until the next session starts. Thats sounds good. ... It is a design feature of XFree86 (and most other X-Servers) to perform a reset when the number of client connections goes to zero. In your case (and as discussed before) the xsetroot program is the only client connected, so after it set's the root background, it disconnects and XWin resets. AFIK this behavior is not optional. You need to re-order the sequence of client starts, so that there is a persistent client (like an xterm or the window manager, or...) bye The reason is, I don't like the default background while kde2 starts and this need a while. Thanks for this hints. Ralf
problem with using xsetroot without window manager
Hi, I'm using the latest Xserver Test Release and have recognized a problem, when starting some apps without any window manager. For starting kde/kde2 I'm using setxroot to choose another background at the start of the launching process, which needs some time. At this time no window manager is running. With this configuration the color isn't set, but the xserver seems to be restarted. (The window seems to be closed for a little while and comes back) After startung twm, kwm or kwin color setting works. The same effect occurs, when I'm starting for example xdpyinfo without any window manager. When the end of the listing is reached the server restarts. Any ideas ? Regards Ralf
RE: Kde 2.2.1's setup.ini file
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Sylvain Petreolle Sent: Wednesday, January 09, 2002 6:41 PM To: [EMAIL PROTECTED] Subject: Kde 2.2.1's setup.ini file Hi, I would install Kde 2.2.1 and i didn't find the setup.ini file on http://sourceforge.net/projects/kde-cygwin. Where could I download it ? The alpha release of kde 2.2.1 does not support downloading with setup.exe/setup.ini. You have to download each archive and the related updates/patches. Read the relating README's for more information about installing and so on. I think the beta release would support this. Perhaps if no reaons speek against, it will be released with the cygwin mirroring network. Regards Ralf
