XWin-Test86: (New Window's title Code breaks when used with xmodmap)
FYI:: I have been struggling with delete/insert keys The following is from my xtartup.bat file I was using xmodmap as follows: REM REM Startup the programs REM REM Startup the X Server. rem start XWin start XWin-Test86 -multiwindow -clipboard REM Startup the twm window manager. rem run twm rem run wmaker REM Set a background color. run xsetroot -solid aquamarine4 run xhost usilca11 run xmodmap -e keycode 91 = Delete run xmodmap -e keycode 90 = Insert KP_0 run xterm -sl 5000 -sb -rightbar -ms red -fg blue -bg wheat -cr DarkSlateGrey -fn 10x20 -ls -g +100+100 ** Using xmodmap as shown above seems to cause the new windows title changing code to not work consistently/reliably
RE: Custom icons per window class/name patch
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. 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. Then when the window is deleted we will just UnregisterClass(GetClassName(hwnd)) and NOT have any GDI leaks. 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. The class, name, and role can still be used for the 2nd chance iconification of windows (the LoadImage() call referencing xwin.ini). I'll throw a patch together tonight for this unless someone beats me to it. -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
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
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'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?). 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?) Colin
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.
Apply Ralf's Role Patch?
I have merged Earle's changes to the icon handling, but I can't tell if there is a consensus to merge Ralf's role patch. Has it been decided that the role patch will need to be more robust? Should I just apply it anyway so that we all have the same code base to work from? Harold
key bounce problem
I've been experiencing a fairly annoying key bounce problem with almost any X client that takes keyboard input running against XWin on my XP box. The problem rears its ugly head the most when running xterm. I searched the archive for this list for xterm, debounce, keyboard, etc but couldn't find a message with a solution. The keyboard code for XWin appears to ignore xset's r option, likewise it appears to ignore XKEYBOARD args such as -ar1 as detailed on the Xserver man page. The keyboard code doesn't ignore XP's keyboard control settings however. I modified Control Panel-Keyboard-Repeat Delay to be one notch slower and the keyboard bounce problems magically went away. This fix obviously modifies the behavior of the keyboard for every Windows app, but since I spend 99% of the time inside XFree86 I'm quite happy with it. :-) I don't know if this fix applies to anything other than XP, but I thought I should subscribe to this list and get this message into the archive in case someone else runs into the same problem down the road. Stacey http://www.pigtailproductions.com/stacey/
RE: Custom icons per window class/name patch
Howdy, it's probably bad form to reply to your own posts but here goes: Attached is a patch from the clean test 86 release (xwin-20030518-1426.tar.bz2) The changes are as follows: * Colin's key un-sticker for when you unfocus an X window with a key depressed * Custom icons on a per-window basis - Each window created in its own class (to allow custom icon) - Class name = fn(res_name, res_class, res_role, incrementing counter) - Icon is created on-the-fly using the routines I sent before - On destroy of a window free the icon (if not x default) and class - Also still have XWIN.INI support, but seems silly to me at this point, I would just remove it completely and wait for a real ~/.xwinrc file parser and PNG files... * Set XIconSizes() to the Windows approved 16, 32, and 48. It doesn't seem to be looked at by anything, but it is in the XLib documents as something a WM should set. * Removed several misc compile warnings and turned off debug messages for GetWindowName (probably leftover from local debugging?) TBD: * KDE's proprietary icon format (it should be pretty easy to hack the present code to support it, all the real work is already done...) * Handle icon customization better, through ~/.xinitrc and PNG/JPG/etc. * Small icon bitmask problem? -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com from_86.diff.bz2 Description: Binary data
Re: key bounce problem
Stacey, Check the following email message for some history: http://sources.redhat.com/ml/cygwin-xfree/2003-04/msg00107.html Duncan Cragg seems to have reported success using 'xset r off', but you may want to read the rest of that thread for clarification. Hmm... from my own comments I think I mentioned that XF86MISC isn't compiled in, so it wouldn't seem that 'xset r off' could actually do anything... I had asked for some help from our guru, Alan Hourihane, but I don't remember if he had any insight to offer me. I didn't notice a reply to his message in the thread, but this was during the end of the semester for me so I may have been so busy that I didn't notice his response. Stacey --- If you weren't running (exactly) 'xset r off', could you try restoring your Windows keyboard setting and running that command? Let us know the results. I don't expect it to work, or I suspect that you have already tried (you did mention xset r), but give it a shot if you haven't tried it. Any else got some ideas here? Harold Stacey Campbell wrote: I've been experiencing a fairly annoying key bounce problem with almost any X client that takes keyboard input running against XWin on my XP box. The problem rears its ugly head the most when running xterm. I searched the archive for this list for xterm, debounce, keyboard, etc but couldn't find a message with a solution. The keyboard code for XWin appears to ignore xset's r option, likewise it appears to ignore XKEYBOARD args such as -ar1 as detailed on the Xserver man page. The keyboard code doesn't ignore XP's keyboard control settings however. I modified Control Panel-Keyboard-Repeat Delay to be one notch slower and the keyboard bounce problems magically went away. This fix obviously modifies the behavior of the keyboard for every Windows app, but since I spend 99% of the time inside XFree86 I'm quite happy with it. :-) I don't know if this fix applies to anything other than XP, but I thought I should subscribe to this list and get this message into the archive in case someone else runs into the same problem down the road. Stacey http://www.pigtailproductions.com/stacey/
Re: Custom icons per window class/name patch
Earle, Thanks. I will work on merging the remaining changes in this patch into my tree tomorrow. I hope to make a test release tomorrow so that we can all get back into synch. Thanks for your great contributions, Harold Earle F. Philhower III wrote: Howdy, it's probably bad form to reply to your own posts but here goes: Attached is a patch from the clean test 86 release (xwin-20030518-1426.tar.bz2) The changes are as follows: * Colin's key un-sticker for when you unfocus an X window with a key depressed * Custom icons on a per-window basis - Each window created in its own class (to allow custom icon) - Class name = fn(res_name, res_class, res_role, incrementing counter) - Icon is created on-the-fly using the routines I sent before - On destroy of a window free the icon (if not x default) and class - Also still have XWIN.INI support, but seems silly to me at this point, I would just remove it completely and wait for a real ~/.xwinrc file parser and PNG files... * Set XIconSizes() to the Windows approved 16, 32, and 48. It doesn't seem to be looked at by anything, but it is in the XLib documents as something a WM should set. * Removed several misc compile warnings and turned off debug messages for GetWindowName (probably leftover from local debugging?) TBD: * KDE's proprietary icon format (it should be pretty easy to hack the present code to support it, all the real work is already done...) * Handle icon customization better, through ~/.xinitrc and PNG/JPG/etc. * Small icon bitmask problem? -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
RE: Custom icons per window class/name patch
Howdy Colin, At 10:52 PM 5/27/2003 +0100, you wrote: 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?). 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. They're pretty standard and unoptimized, but since they are only called a very few times during a heavy-weight process, and for 32x32 images it's not a big deal. It just steps over the destination image, figures out which pixel in the source image that pixel maps to, and then does any color space conversions. A nicer way would be to promote all images to 32 bits and then do some 2d bilinear filtering. 8) It's sure nice to have a 1BOPS machine for under 1K$. 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?) Can you try again at 32bpp and see if things are munged? I didn't notice any problems with the quickie konqueror runs I did (over a 56k modem, you don't wanna do a long konqueror remote run, trust me) at 32bpp with the 16x16 icons. That would narrow down where to look by a lot. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
RE: Custom icons per window class/name patch
Howdy Ralf, I'm condensing a bunch of your messages into one longer one... At 11:30 PM 5/27/2003 +0200, you wrote: 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: ... 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. What's I think connection ID would be better than PID, they're not guaranteed unique across different machines. FWIW I just used the incrementing counter like you tried before, and seems hunkey dorey as long as you clean up after yourself in the destroy... 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 I think the only thing consistent is the inconsistency. :) And as far as I've seen in the commercial and non-KDE apps is that nobody but KDE sets that role, even to unnamed 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. Are you sure about this? Windoze will expand 16x16 icons and their masks, maybe the 16x16 icon is bad too but it's too small to see? A windows magnifier app might be handy here... The problem is kde and gnome specific. The kde3 window manager (kwin) taks switcher displays two kind of icons: 1. a list of 16x16 pixel icons like the windows task switcher does and 2. a higher resolution icon for the current selected application. The 16x16 pixel icon is provided through the regular WMHints property, the bigger one by the _NET_WM_ICON(CARDINAL) property, which is part of the Extended Window Manager Hints found in http://www.freedesktop.org/standards/wm-spec.html Ahhh, another window manager standard. So many to choose from! In detail from http://www.freedesktop.org/standards/wm-spec/1.3/html/x231.html _NET_WM_ICON _NET_WM_ICON CARDINAL[][2+n]/32 This is an array of possible icons for the client This is an array of 32bit packed CARDINAL ARGB [alpha,red,green,blue] with high byte being A, low byte being B. The first two cardinals are width, height. Data is in rows, left to right and top to bottom. ... I've appended an xprop dump for the KDE3 kate application. May be you can use this. Looks like about a 30 minute job to parse this guy into separate icon sizes and choose the largest one and feed that into the resize routine. It makes it easier that they're all 32-bit quantities, no format conversions necessary, and there is no reason not to write a nice 2d bilinear or quadratic scaler to give some really sharp icons! ... 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. Yup, seems to be neither rhyme nor reason about it. The apps I'm using have been ported using some Tk, some MainFrame(tm) Windoze porting layers, and maybe some über-hacks... 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. It's in the patch I sent a few mins ago, it seems to work OK and not leave things dangling if you clean up the HICONs and WNDCLASSes... 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
Local xload for cygwin
This isn't really XWin.exe related, but I've just posted a patch to the XFree86 devel group to allow you to run xload locally under cygwin. There's no rwhod so remote doesn't work, but you can still always xload from a remote machine. Even without remote sensing it's still pretty handy and more customizable than the Windows task manager. This means when you run window managers that swallow xload into their taskbars, they work 100% under cygwin... http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=305 -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: WMaker crashes when starting with startxwin.bat
Hello, I have just installed cygwin and everything is working fine except for one small problem. When I start up cygwin and load up Xwin via bash everything is fine, I have 2 xterms popup and a clock. My xterms are set to start in my home dir. My problem is loading Xwin via startxwin.bat. I found this email in the archives, and the settings here fixed my Signal 11 Xwin problem, and Xwin loads up fine via the startxwin.bat, but when my xterms popup they don't have the HOME var set. I fixed this problem with the bash --login option. I know this is because /etc/profile isn't read in the .bat. Is there any way to have the /etc/profile read, because I have other little in there I would like to use. I could live without them, but I was just curious. Thanks, Sergio Hi Klaus yes, you're probably right. But now the tricky question: How can I change the windows home to point to my $HOME in cygwin to solve that problem? take my startxwin.bat as an example. Cygwin is installed on d:\cygwin. The only customized lines are SET HOME, SET CYGWIN_ROOT, the rest is standard startxwin.bat with different WM-calls REMmed on and off. HTH hjb @echo off D: SET DISPLAY=127.0.0.1:0.0 SET HOME=/CYGDRIVE/D/cygwin/home/DV105 REM REM The path in the CYGWIN_ROOT environment variable assignment assume REM that Cygwin is installed in a directory called 'cygwin' in the root REM directory of the current drive. You will only need to modify REM CYGWIN_ROOT if you have installed Cygwin in another directory. For REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will need REM to change \cygwin to \foo\bar\baz\cygwin. REM REM This batch file will almost always be run from the same drive (and REM directory) as the drive that contains Cygwin/XFree86, therefore you will REM not need to add a drive letter to CYGWIN_ROOT. For example, you do REM not need to change \cygwin to c:\cygwin if you are running this REM batch file from the C drive. REM SET CYGWIN_ROOT=D:\cygwin SET PATH=.;%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%PATH% REM REM Cleanup after last run. REM if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\tmp\.X11-unix\X0 :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix REM REM Startup the X Server, the twm window manager, and an xterm. REM ... skipped if %OS% == Windows_NT goto OS_NT REM Windows 95/98/Me echo startxwin.bat - Starting on Windows 95/98/Me goto STARTUP :OS_NT REM Windows NT/2000/XP echo startxwin.bat - Starting on Windows NT/2000/XP :STARTUP REM REM Startup the programs REM REM Startup the X Server. REM start XWin %1 REM start XWin -fullscreen start XWin -rootless REM start XWin -broadcast REM Startup an xterm, using bash as the shell. REM run xterm -sl 1000 -sb -rightbar -ms red -fg yellow -bg black -e /usr/bin/bash REM setxkbmap de REM Startup the twm window manager. REM run twm REM run fvwm2 REM run openbox run wmaker xrdb -merge .Xresources REM Set a background color. REM run xsetroot -solid aquamarine4 exit
Re: key bounce problem
Harold, Duncan Cragg seems to have reported success using 'xset r off', but you may want to read the rest of that thread for clarification. Hmm... from my own comments I think I mentioned that XF86MISC isn't compiled in, so it wouldn't seem that 'xset r off' could actually do anything... No xset 'r' args appear to work. 'xset q' shows that the server is correctly registering 'xset r off' and it's definitely ignored. I think it's fine that XWin currently ignores this stuff since it's (without looking at the source) probably doing the right thing by talking directly to the Windows keyboard driver at the application level. Either way, I don't actually want 'xset r off', I really want something like: $ cat ~/.xserverrc : exec /usr/X11R6/bin/X -ar1 500 :0 ...which doesn't seem to work either. I had asked for some help from our guru, Alan Hourihane, but I don't remember if he had any insight to offer me. In a previous life I wrote X server support many ISA, VESA and PCI graphics adapters. I remember the keyboard-and-mouse-input guy in our group being a weary glass is half empty type person when struggling with these devices and everything that an X server is expected to do with them. Stacey http://www.pigtailproductions.com/stacey/