RE: [ANNOUNCEMENT] Cygwin/XFree86 setup.exe packages with dependencies
-Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 3:30 PM Dependencies work for installing. The behavior I noticed when uninstalling is that dependencies are ignored. I'm guessing that setup.exe was designed that way because there isn't really a good way to handle dependencies when uninstalling. Yeah. On uninstalling we need some user interaction, and the chooser isn't quite there to do that cleanly (yet). Rob
RE: [ANNOUNCEMENT] Cygwin/XFree86 setup.exe packages with dependencies
David, I needed to add /usr/X11R6/bin to PATH, and set DISPLAY. So you didn't use startxwin.bat? startxwin.bat is still included in the distribution and it is the preferred way to start. Harold -Original Message- From: Billinghurst, David (CRTS) [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 2:42 AM To: Harold Hunt Cc: cygx Subject: RE: [ANNOUNCEMENT] Cygwin/XFree86 setup.exe packages with dependencies i have just downloaded and installed. I needed to add /usr/X11R6/bin to PATH, and set DISPLAY. Client apps work fine using Exceed as server. I have real work going on so I can't fiddle too much. -Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Thursday, 18 April 2002 3:30 To: [EMAIL PROTECTED] Cc: cygx Subject: [ANNOUNCEMENT] Cygwin/XFree86 setup.exe packages with dependencies I just updated the packages at ftp://huntharo-4.user.msu.edu/pub/cygwin/ to have a working dependency between XFree86-base and the base XFree86 packages, such as XFree86-xserv, XFree86-fnts, etc.
RE: alt-tab: client window receives tab / pressing both shift-keys = caps-lock
Gerard, I've flagged these behaviors for a follow up later. Very interesting problems. I've not yet heard of pressing both shift-keys == caps-lock. I'll get back to you when I have a look at these. Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Pille Geert (bkarnd) Sent: Thursday, April 18, 2002 4:55 AM To: '[EMAIL PROTECTED]' Subject: alt-tab: client window receives tab / pressing both shift-keys = caps-lock Hello, when I use alt-tab to switch from XWin to a window outside of XWin, the currently active client window receives every tab I hit to get to the other window. Inside XWin, I'm using an old version of mwm (running on a HP/UX 11) to manage the windows, and I switch with CTRL-TAB. My installation of cygwin and XFree86 on it are hardly a week old, so I suppose I am fairly up to date. The client windows are cygwin/XFree86's xterm (the HP/UX xterm seems unable to handle dead keys inside XWin, although it had no problem with that using Kea!X, I'm using a belgian keyboard through xkb). Then I have another special feature: when I accidentally (or on purpose) press both shift keys, characters remain in uppercase, I have to switch that of by hitting the shift keys separately. It happens quite often by accident, when typing a short word in uppercase, say WHAT? Great products, both cygwin and the XFree86 port, I feel more at home at work now ;-) Gerard === This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. You are explicitly requested to notify the sender of this email that the intended recipient was not reached.
RE: kde 3.0 no icons
I'm submitting a bug report to KDE to gather more information. I can reproduce this bug when I put my graphics card into 32 bit color mode, but I need to know if any user out there with a graphics card capable of 24 bit color mode has this problem when they are in 24 bit color mode. Please respond ASAP if you can tell me whether or not 24 bit color produces the same problem of no icons in KDE 3. hi.. I've just discovered this bug when I upgraded to KDE 3 (and spent ages installing every single KDE package, thinking I was missing the icons :-( ) Switching to 24 bit truecolor (instead of my default 32 bit truecolor) has fixed the problem. Using XVision on the 32 bit display meant that the pictures displayed OK (there are other bugs in XVision though!). I suspect that the fact that XVision doesn't offer 32 bit pixmaps is what makes the difference. xdpyinfo output for cygwin XFree86 on a 24 bit display: name of display:cleveland:0.0 version number:11.0 vendor string:The XFree86 Project, Inc vendor release number:4020 XFree86 version: 4.2.0 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 24, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x1600017, revert to PointerRoot number of extensions:22 BIG-REQUESTS DEC-XTRAP DOUBLE-BUFFER Extended-Visual-Information FontCache GLX LBX MIT-SUNDRY-NONSTANDARD RANDR RECORD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP XC-APPGROUP XC-MISC XFree86-Bigfont XKEYBOARD XTEST XVideo default screen number:0 number of screens:1 screen #0: dimensions:1146x811 pixels (388x275 millimeters) resolution:75x75 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x36 depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store NO, save-unders NO largest cursor:1146x811 current input event mask:0xd84031 KeyPressMask EnterWindowMask LeaveWindowMask KeymapStateMask SubstructureNotifyMask SubstructureRedirectMask PropertyChangeMask ColormapChangeMask number of visuals:2 default visual id: 0x22 visual: visual id:0x22 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x23 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits xdpyinfo output for XVision on a 32 bit display: name of display:localhost:1.0 version number:11.0 vendor string:Santa Cruz Operation Inc. vendor release number:730 maximum request size: 4194300 bytes motion buffer size: 0 bitmap unit, bit order, padding:8, MSBFirst, 16 image byte order:MSBFirst number of supported pixmap formats:2 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 16 depth 24, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 140 focus: PointerRoot number of extensions:10 BIG-REQUESTS DOUBLE-BUFFER GLX LBX MIT-SUNDRY-NONSTANDARD SCO(C)1996-VisionResumeExtension SHAPE SYNC XC-MISC XIE default screen number:0 number of screens:1 screen #0: dimensions:1152x864 pixels (304x228 millimeters) resolution:96x96 dots per inch depths (2):1, 24 root window id:0x24 depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x22 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store YES, save-unders NO largest cursor:32x32 current input event mask:0x0 number of visuals:2 default visual id: 0x20 visual: visual id:0x20 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits
RE: kde 3.0 no icons
Adam, What I'd also like to see if the xdpyinfo output for Cygwin/XFree86 on a 32 bit display. Thanks, Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Adam Gundy Sent: Thursday, April 18, 2002 9:51 AM To: [EMAIL PROTECTED] Subject: RE: kde 3.0 no icons I'm submitting a bug report to KDE to gather more information. I can reproduce this bug when I put my graphics card into 32 bit color mode, but I need to know if any user out there with a graphics card capable of 24 bit color mode has this problem when they are in 24 bit color mode. Please respond ASAP if you can tell me whether or not 24 bit color produces the same problem of no icons in KDE 3. hi.. I've just discovered this bug when I upgraded to KDE 3 (and spent ages installing every single KDE package, thinking I was missing the icons :-( ) Switching to 24 bit truecolor (instead of my default 32 bit truecolor) has fixed the problem. Using XVision on the 32 bit display meant that the pictures displayed OK (there are other bugs in XVision though!). I suspect that the fact that XVision doesn't offer 32 bit pixmaps is what makes the difference. xdpyinfo output for cygwin XFree86 on a 24 bit display: name of display:cleveland:0.0 version number:11.0 vendor string:The XFree86 Project, Inc vendor release number:4020 XFree86 version: 4.2.0 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 24, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x1600017, revert to PointerRoot number of extensions:22 BIG-REQUESTS DEC-XTRAP DOUBLE-BUFFER Extended-Visual-Information FontCache GLX LBX MIT-SUNDRY-NONSTANDARD RANDR RECORD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP XC-APPGROUP XC-MISC XFree86-Bigfont XKEYBOARD XTEST XVideo default screen number:0 number of screens:1 screen #0: dimensions:1146x811 pixels (388x275 millimeters) resolution:75x75 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x36 depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store NO, save-unders NO largest cursor:1146x811 current input event mask:0xd84031 KeyPressMask EnterWindowMask LeaveWindowMask KeymapStateMask SubstructureNotifyMask SubstructureRedirectMask PropertyChangeMask ColormapChangeMask number of visuals:2 default visual id: 0x22 visual: visual id:0x22 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x23 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits xdpyinfo output for XVision on a 32 bit display: name of display:localhost:1.0 version number:11.0 vendor string:Santa Cruz Operation Inc. vendor release number:730 maximum request size: 4194300 bytes motion buffer size: 0 bitmap unit, bit order, padding:8, MSBFirst, 16 image byte order:MSBFirst number of supported pixmap formats:2 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 16 depth 24, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 140 focus: PointerRoot number of extensions:10 BIG-REQUESTS DOUBLE-BUFFER GLX LBX MIT-SUNDRY-NONSTANDARD SCO(C)1996-VisionResumeExtension SHAPE SYNC XC-MISC XIE default screen number:0 number of screens:1 screen #0: dimensions:1152x864 pixels (304x228 millimeters) resolution:96x96 dots per inch depths (2):1, 24 root window id:0x24 depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x22 default number of colormap cells:256 preallocated pixels:
RE: kde 3.0 no icons
At 10:07 18/04/02 -0400, Harold Hunt wrote: Adam, What I'd also like to see if the xdpyinfo output for Cygwin/XFree86 on a 32 bit display. sorry... I assumed you'd already have that. Here it is: name of display:localhost:0.0 version number:11.0 vendor string:The XFree86 Project, Inc vendor release number:4020 XFree86 version: 4.2.0 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 24, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: PointerRoot number of extensions:22 BIG-REQUESTS DEC-XTRAP DOUBLE-BUFFER Extended-Visual-Information FontCache GLX LBX MIT-SUNDRY-NONSTANDARD RANDR RECORD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP XC-APPGROUP XC-MISC XFree86-Bigfont XKEYBOARD XTEST XVideo default screen number:0 number of screens:1 screen #0: dimensions:1146x811 pixels (388x275 millimeters) resolution:75x75 dots per inch depths (7):32, 1, 4, 8, 15, 16, 24 root window id:0x36 depth of root window:32 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:2048 preallocated pixels:black 0, white 16777215 options:backing-store NO, save-unders NO largest cursor:1146x811 current input event mask:0x0 number of visuals:2 default visual id: 0x22 visual: visual id:0x22 class:TrueColor depth:32 planes available colormap entries:2048 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x23 class:TrueColor depth:32 planes available colormap entries:2048 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.
Subject: Re: Problem: extreme speed difference NT4 Win98SE runing Xfree
My display slowed down dramatically when I moved from a 1024x768 screen to a new display with 1280x1024 resolution (both with ME). Holger Vogt
Pixmap practical size limitation?
In modifying an existing application, which contained one (scrolled) DrawingArea and two (scrolled) Text widgets, I wanted to use multicolor text and decided to use two more DrawingArea widgets to accomplish this. However, only the 2000x2000 original Pixmap is reliably written for the refreshment of the original DrawingArea. In order to accommodate the potentially long and/or wide range of text in the emulated Text widgets, I created a Pixmap of size 5000x4000 and 1x2000, respectively. To be sure it wasn't something in the rendition of the text strings that was at fault in their unpredictable behavior, I drew a black 20x100 rectangle in the upper left corner of each Pixmap immediately after creation. Only the one for the 2000x2000 Pixmap appears in the associated DrawingArea window. Other than their sizes (and the variable names, of course), there is virtually no difference between these Pixmaps. In fact, if I temporarily change the dimensions of the other two to 2000x2000, I find that their behavior becomes reliable once again. None of the X documentation mentions any size limitations for the Pixmap, whose datatype is opaque. (Thanks a lot, MIT!) Even if there were one, it should generate a predictable error message, rather than an unpredictable behavior. Anyway, even if unsigned int referred to 16 bits on my computer (which it does not), these dimensions would still be within range - for that matter, they would even be accommodated by signed short! Is this a known bug? If so, can I get around it, albeit kludgily, by declaring 21 variables of type Pixmap and doing redundant XDrawString() calls to be sure that any that might fall withing the bounds of the write will be updated, or is there a limit on the _total_ amount of memory available for Pixmap data? I am running under Windows NT4, SP3, with the Hummingbird Window Manager, v.6.1. (The window manager supplied with cygwin is impractical for any sophisticated applications.)
RE: Pixmap practical size limitation?
Jerry, This is a Cygwin/XFree86-specific mailing list. Your question about whether 40 MB to 80 MB pixmaps are allowed is a general XFree86/X question that should be asked and answered by general XFree86/X mailing lists or documentation. Please check out these websites for more information and mailing list addresses: http://xfree86.org/ http://www.x.org/ You might also want to look in books, etc. for an answer. Sorry we can't help, Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jerry Miller Sent: Thursday, April 18, 2002 2:57 PM To: [EMAIL PROTECTED] Subject: Pixmap practical size limitation? In modifying an existing application, which contained one (scrolled) DrawingArea and two (scrolled) Text widgets, I wanted to use multicolor text and decided to use two more DrawingArea widgets to accomplish this. However, only the 2000x2000 original Pixmap is reliably written for the refreshment of the original DrawingArea. In order to accommodate the potentially long and/or wide range of text in the emulated Text widgets, I created a Pixmap of size 5000x4000 and 1x2000, respectively. To be sure it wasn't something in the rendition of the text strings that was at fault in their unpredictable behavior, I drew a black 20x100 rectangle in the upper left corner of each Pixmap immediately after creation. Only the one for the 2000x2000 Pixmap appears in the associated DrawingArea window. Other than their sizes (and the variable names, of course), there is virtually no difference between these Pixmaps. In fact, if I temporarily change the dimensions of the other two to 2000x2000, I find that their behavior becomes reliable once again. None of the X documentation mentions any size limitations for the Pixmap, whose datatype is opaque. (Thanks a lot, MIT!) Even if there were one, it should generate a predictable error message, rather than an unpredictable behavior. Anyway, even if unsigned int referred to 16 bits on my computer (which it does not), these dimensions would still be within range - for that matter, they would even be accommodated by signed short! Is this a known bug? If so, can I get around it, albeit kludgily, by declaring 21 variables of type Pixmap and doing redundant XDrawString() calls to be sure that any that might fall withing the bounds of the write will be updated, or is there a limit on the _total_ amount of memory available for Pixmap data? I am running under Windows NT4, SP3, with the Hummingbird Window Manager, v.6.1. (The window manager supplied with cygwin is impractical for any sophisticated applications.)
RE: Curious refresh rate behavior...
From: Harold Hunt [EMAIL PROTECTED] To: Thomas Chadwick [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Curious refresh rate behavior... Date: Wed, 17 Apr 2002 18:45:07 -0400 Thomas, Well, answer me this one question: What refresh rates does Windows 2000 allow when you set the Windows color depth to 8 bits? I switched Windows to 1024x768x8 and got 75Hz. I then ran XWin -fullscreen and got 1024x768x8 @ 75Hz. I then quit XWin and reset Windows to 1024x768x24 @ 75Hz. I then ran XWin -fullscreen -depth 8 and got 1024x768x8 @ 75Hz! Strange. I'll chaulk it up to some funny business with DirectDraw or the Video Driver. Thanks. _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
RE: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
Chris, Shall we add this to the cygwin distro or are we still waiting for some postinstall shell script work? These will forever be known as Harold's Famous Last Words: Sure Chris, why not? Go ahead and add the packages to the distro. Be aware, I just updated XFree86-xserv to 4.2.0-2, so you'll need to grab the latest packages off of ftp://huntharo-4.user.msu.edu/pub/cygwin/ That's all for now. I can't wait to see how many people use Cygwin/XFree86 now! Oh, we can wait for the postinstall shell script. That will really be just icing on the cake. Harold
