RE: Starting X on a second monitor - kludge that works
Howdy Mark, -- Original Message - Subject: RE: Starting X on a second monitor - kludge that works From: Mark Fisher [EMAIL PROTECTED] my only query now is how do I programaticaly find out the offset of my second monitor, as I have it slightly raised from the primary, as opposed to simply placed side by side. -- If you're asking just to set up your machine once, the simplest thing to do is open up the Display properties, and click-hold on the 2nd monitor, it should then display the (X,Y) position in it. Since it's raised you should have a negative Y position, which does work OK with the checked-in patch. Programmatically, I like AGO's @monitor idea... -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
RE: Starting X on a second monitor - kludge that works
Done as an extension to the -screen option. Just tack on an X and Y position after width and height (witn -geometry format or just space-delimited) and you're set. ex: make an 800x600 window and move it to the 2nd monitor XWin.exe -screen 0 800 600 1024 0 XWin.exe -screen 0 800x600+1024+0 You can still specify just a width and height, so no changes to current scripts needed: XWin.exe -screen 0 800 600 XWin.exe -screen 0 800x600 At 04:52 PM 12/4/2004 +0100, Alexander Gottwald wrote: We'll have to see how this fits with the old -screen n WxH option. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
RE: Starting X on a second monitor - kludge that works
Howdy! At 01:18 PM 12/3/2004 +, you wrote: I tried adding -position to a simple xinit session and X bombs out with the usage command, i.e. (~/.xinitrc) fvwm2 $ xinit -- -position 100 100 it doesn't look like these paramters exist Nope, it doesn't yet. But adding it to XWin.exe should be a snap. I think I still have CVS access, if I can get the src compiling this weekend I'll do a commit unless AGO objects...Xwin hit such a high quality level this year I've not needed to do anything with my install for ages! Personally, I'd like to see it as an XLib -geometry format (xwin -geometry 800x600+1024+0) just for consistency... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: window position with default window manager
AGO wrote... Subject: Re: window position with default window manager From: Alexander Gottwald [EMAIL PROTECTED] On Tue, 21 Sep 2004, Elvin Peterson wrote: It is possible to make all windows appear at the top left corner of the screen? I have looked at the command line options and found nothing appropriate. I am using the -multiwindow option. Afaik the internal windowmanager has no option to configure placing the windows. Most(all?) X apps have a -geometry command line option, the MWM does obey an initial position specified there IIRC... -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: How do I delete crashed cygwin/x directories on W2K?
For undeletable files first run chkdsk /f on the drive and make sure it's clean. Then try the steps listed in the MS KB article linked below, especially the subinacl command and the del \\?\ suggestions. You cannot delete a file or a folder on an NTFS file system volume http://support.microsoft.com/default.aspx?scid=kb;en-us;320081 At 03:49 PM 7/30/2004 -0700, you wrote: I have a couple of CYGWIN/X directories on my hard drive that I cannot remove even when I logon as Administrator. ...Note that I can only view, not change any security. It seems that S-1-5-21-1844 ... , which was most likely created by the installation procedure, is the owner of the 'Shortcuts' files in the directories. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: XWin and the ICON on xterm window
Howdy, At 02:36 PM 5/19/2004 +0200, Alexander Gottwald wrote: On Wed, 19 May 2004, Angelo Graziosi (D. Zanello) wrote: From version 6.7-5 I have noted that starting XWin with startxwin.bat (.sh) produces an xterm window for which the X-Icon near its title looks corrupted, as if there were a double reflection/refraction. Also others X-Windows application (like emacs) presents this effect. With XWin-6.7-5 there was a change in the way how Icons are loaded to fix a problem with freeing icons twice. @Earle: What about using LoadIcon again and duplicating the handle with CopyIcon? HICON tmp = LoadIcon (g_hInstance, MAKEINTRESOURCE(IDI_XWIN)); g_hiconX = CopyIcon(tmp); I'm not sure what's being to referred to in the original problem from Angelo, but FWIW the change back a while was getting rid of all LoadIcon() calls and instead using LoadImage()s instead (since we support DLL icons, .ico files, etc.). You need to use DestroyIcon() if the HANDLE is a from LoadIcon, and just plain DestroyObject() if the HANDLE is from LoadImage or you get a GDI leak. Lev Bishop was talking about doing some changes to do a LoadImage() for both large and small icon sizes, but I don't think anything became of it... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: XWin and the ICON on xterm window
Howdy AGO, Just a while back AGO wrote... On Wed, 19 May 2004, Earle F. Philhower III wrote: I'm not sure what's being to referred to in the original problem from Angelo, but FWIW the change back a while was getting rid of all LoadIcon() calls and instead using LoadImage()s instead (since we support DLL icons, .ico files, etc.). You need to use DestroyIcon() if the HANDLE is a from LoadIcon, and just plain DestroyObject() if the HANDLE is from LoadImage or you get a GDI leak. DeleteObject is never called on an icon handle in out code. Only DestroyIcon is. You're right, Alexander, I remembered that Kensuke fixed a bug w/this but I got the wrong direction. It's been a busy month and I've not looked at the XWin code recently. :) Using LoadImage results in broken images now. I'd like to revert to LoadIcon but in a safe way. I kind of agree about this, but would really like to fix the problem with LoadImage() instead of reverting to LoadIcon(). Not all systems (I know my W2K and WXP boxes are among these) have no problem at all with the icons, so there must be some difference between the pretty and non-pretty icon displays (custom themes with odd icon sizes, specific drivers, etc?)... Lev made some comments about doing dual LoadImages (both SM_ICON and SM_SMICON) to get rid of any bad scaling issues, IIRC. If you go to LoadIcon() then you'll have to kill all the icon customizations, no? -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: stacking/tweakui
At 10:30 AM 5/4/2004 -0700, Tapas Kanungo wrote: I am still facing the same problems that Brian reported earlier (when you click on one xterm to bring it to foreground, the window contents does not get refreshed unless you move the cursor out of the window and back etc.). For details: http://cygwin.com/ml/cygwin-xfree/2004-03/msg00849.html ... Earle's comments on the web on March 31)said that the fix had been checked in. I am not sure if the fix is in the above version, which was released on April 27. Just FYI, there was an email I sent just after that one noting that I had backed out that change because it wasn't thread safe, and could cause crashes depending on some race conditions. The current state of things AFAIK is that the Xmouse or click-and-move presently still don't update the X stacking order... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Color support added to HW accelerated cursor
Howdy! At 10:12 AM 4/27/2004 +0200, Alexander wrote: Have you got any idea what could be going on here? That's a perfectly fine workaround you've put in to catch when the OS call silently fails, but I can't imagine what the root cause would be... I'll check the MSDN Knowledge base. I bet it is documented there. Don't worry, I figured it out. You need a compatible bitmap on pre-XP systems, which isn't exactly what I was doing by hand in the code. The fixed code is much shorter now, and has none of the complicated cases for different bit depths (seems to work even on W95 w/8bpp mode now)... FWIW I didn't see any documents saying that it was necessary to use a compatible bitmap in the SDK docs, but all the samples were using one by default (they were making icons from portions of on-screen windows, so it's obviously compatible from that source!) -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Color support added to HW accelerated cursor
Howdy again, At 11:17 AM 4/27/2004 +0200, Alexander Gottwald wrote: hm. It seems I forgot to remove thw -swcursor flag again. It did not work :(. But I've fixed it by generating the cursor from the icon bitmaps. Arrgh! I swear it works under W95 and XP, all depths I can throw at it! Honest! :) But I didn't test W2K (running W95 under bochs is slow enough, thank you very much) and it seems like my work W2K machine has your exact problem, but now only intermittently. There was one minor change I just committed, you need to always free the GetIconInfo, not only when it comes back as an icon... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Color support added to HW accelerated cursor
Howdy, At 03:53 PM 4/26/2004 +0200, Alexander Gottwald wrote: The hotspots of the cursor are garbled. multiwindow xterm: moving the cursor from the titlebar into to window changes the cursor from arrow to text-input and the cursor jumps. The bottom line of the text-input cursor is now right below the title bar and everything else is in the titlebar but the hotspot is in the window itself Mozilla: cursor is arrow. You have to aim about 1 line (12px?) above what you want to hit. Can you be a bit more specific as to the mode/depths/OS/etc. you're running at? Is this on an ARGB cursor or a standard X cursor? I've tried under XP , 32 16bpp, MWM mode with all of the apps you've mentioned and not seen anything like that, so I need any pointers you can provide to track it down... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Color support added to HW accelerated cursor
Howdy Alexander, [From your CVS log] CreateIconIndirect sometimes creates an Icon instead of an Cursor. This breaks the hotspot and makes the cursor unusable. Discard the garbled cursor and revert to simple bw cursor. That's got to be one of the strangest things I've seen in a long time. I'll be damned if under W2K 16bpp modes on my Voodoo 3 cards the cursor comes back as ficon=*TRUE*, x/yhot=*16*, but under WinXP it always returns as a proper cursor, no matter what the bpp. Have you got any idea what could be going on here? That's a perfectly fine workaround you've put in to catch when the OS call silently fails, but I can't imagine what the root cause would be... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Icons in 6.7-6
Howdy, At 01:18 PM 4/25/2004 -0400, Lev S Bishop wrote: The recent changes from LoadIcon to LoadImage, while technically The Right Thing, have made the default X icon less pretty in the small size (ie in window titles, on the taskbar). I can explain in detail the cause of this if anyone cares. Last night I was toying in my head with a few ideas for extensions to the current icon handling system that would cover this and a few other nitpicky icon prettiness issues in a more general/complete way -- I'll probably have a go at coding those ideas up next weekend if I don't get a chance before. Sure, I'd like to hear the cause! Were you planning on sidestepping the issue by making a wrapper around the ICON/IMAGE to keep track of whether you LoadIcon()'d or LoadImaged()'d them, so you know how to get rid of them? I also stumbled upon the cygwin calls for converting from cygwin paths to Win32 paths, it may make sense to support both path types when specifying from where to load ICONs. PNG icon support would be neat and easy too, but it doesn't look like libpng is standard in the X tree and I wouldn't want to add dependencies... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Color support added to HW accelerated cursor
My CVS commit emails are in limbo, but just a heads up that I've checked in a change to the HW accelerated cursor routines to add support for non black-and-white cursors. Initially it only supports 2-colored cursors (try set-mouse-color in emacs...), not ARGB ones added with the XRENDER extension. Anyone who knows any apps that compile under cygwin that use the render cursors, I'd be interested in hearing about them so I can do some coding and testing... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Color support added to HW accelerated cursor
Howdy, At 07:28 PM 4/25/2004 -0400, Lev S Bishop wrote: Well, emacs compiles under cygwin, but the version distributed with cygwin doesn't use render. But I know for a fact that the version I'm using right now (on a remote machine) does use ARGB cursors so there must be compile-time options to tell emacs to use them. Thanks, I couldn't get things to compile cleanly for me w/emacs, but I did get a ssh into a linux machine w/apps like Mozilla and emacs that do support ARGB cursors. The change has been put into CVS, the only caveat is that I can't do any 24bpp testing (8-, 16-, and 32-bpp all checked and working, but only 32bpp has the true color/alpha support obviously)... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Small tweak to HW accelerated cursor committed
As usual my CVS commit emails are in limbo, but just a heads up that I've checked in a small change to the HW accelerated cursor routines. Before it would set the cursor no matter where the mouse was, even in the title bar. (Drag an xterm in multiwindow mode quickly and see the Windows cursor change to the X root cursor or the insertion bar depending on where you're dragging over on the X hidden root window...it's a race condition so sometimes it will show, sometimes not.) The new changes check to see if the current cursor position is outside of a window's client rect, and if so then it creates the cursor (for later WM_SETCURSOR events) but does not SetCursor() it. The WM_SETCURSOR handler will take care of it when the mouse moves back into the client region. It's also possible to create color Win32 cursors dynamically, not just black and white ones, through the use of CreateIcon (really!). I don't have any way of testing this at all so I haven't done any work on it. Are there any apps that compile under cygwin that set the X11 cursor color? -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: XWin -multiwindow menu problem (Was: XWinrc Bugs)
Hi Rodrigo, At 02:02 PM 4/17/2004 -0400, Rodrigo Medina wrote: The problems with XWinrc seem to be gone. Remains the problem with the 3 items menus, that I previously attributed to the XWinrc feature, but I now think it is a XWin -multiwindow problem. To remember the problem: All windows produce by XWin -multiwindow have a 3-items (Move, Size and Close) instead of the Windows standard 6-items menus. What the XWinrc feature has to do with this problem is that the XWinrc RELOAD command cures the windows previously produced by XWin -multiwindow. XFree86 versions of XWin did not have this problem. That's good troubleshooting, a patch that works around the W95 bug was committed to CVS. (Are you able to run the latest cygwin DLLs under W95 still? When I was running cygwin w/W95A+IE5.5sp2 under bochs I got nothing but bluescreens in cygwin1.dll...) -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Multiple monitors and repainting
David, Add -multiplemonitors to your XWin command line. -- Original Message - Subject: Multiple monitors and repainting Date: Thu, 15 Apr 2004 10:57:57 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] I have an NVidia DualView card (Quadro NVS) with two monitors attached to it. My monitors are laid out as 2-1 (#2 on the left). I recently upgraded to the new xorg x11 via setup. The version is xorg-x11 6.7.0.0-6. I start X with startxwin.bat. I'm using Windows 2000. The problem is this: If you move an xterm from one screen to the next (they appear on #2, and I move them to #1), the window stops repainting. If I move half, the half that was on #2 still repaints, while the #1 half does not. I'm wondering if you are aware of this issue, and if you have any solutions or workarounds. For now all my consoles live in monitor #2 :-) Thanks, -David Martinez -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: XWinrc Bugs - CVS updated
After going over winprefs.c with one eye on the Platform SDK I found several minor things that I corrected and committed to CVS: What's fixed: . We can't use LoadIcon() to get g_hiconX since it is DestroyIcon()ed. Use LoadImage() instead, like every other icon we use. . The name of the windows class ended up with a random character in it due to an incorrect strncpy(). . Added more input error checking to the winprefs() functions, gets rid of the pWin was null error that happened when you reloaded the .XWinrc. What's left: . There's a small GDI leak, either when a window is created or destroyed that has a X supplied icon (xload for example). I traced things as well as I could but came up empty tracking this down. I know it is either in the creation or deletion because there is NO leak if you repeatedly do .XWinrc reloads. When you start xload you go up by 8 GDI objects (don't know what kind, only have task manager to help), but when you quit xload you only go down by 4. I don't think any of these would cause Rodrigo's problem, but they're fixed nonetheless... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
GDI leak fixed in multiwindow mode, thanks to Kensuke's work
I've just CVS commited a 1-line patch for the GDI leak I found last night. It's actually the same patch Kensuke did a few hours ago, but it wasn't applied to the MultiWindow files. [I'm not complaining, I forgot to apply the off-by-one classname fix to Kensuke's rootless code, too...] It seems that we've got a lot of cut-n-pasted code in XWin. :( If someone has a few spare hours they should see if we can add a common multiwindow utility function file for things like generating class names or reloading the g_hiconX.
Re: XWinrc Bugs
Howdy Rodrigo, First, thanks for writing the man page updates. The version I saw was missing some of the new items that were added, now I have no excuse not to add them myself. ;) It's hard to do any Windows 95 testing, actually it's hard to get any Win95 API documentation anymore (MS seems to be updating their Platform SDK and removing any reference to W95 if a function is updated). For your problem with the system menus, I really believe this is due to something else completely, especially when you ended up without the 3 system menu items in all windows, after a reboot. Here's why: . There are no DeleteMenuor RemoveMenu calls anywhere in prefs.c All we ever do is a reset-to-default GetSystemMenu(hwnd,TRUE) call, everything else is just an InsertMenuItem() call. . Even if somehow you ended up messing with the golden system menu that could only last until a reboot. There's no UpdateResource call until you get to an NT based OS, a change to a GDI resource can't be written into a system .DLL file The removal of the 3 menu items would also make the max/min/close buttons disappear, since Windows reads each window's system menu to determine whether or not to enable those buttons. Maybe you've hit GDI heap exhaustion? IIRC the easiest way to see GDI and SYSTEM heap free is to (seriously!) run Solitaire, then do Help-About... Running out of heap makes bad, bad things happen under W95/98/ME. I think I *may* understand the ICONS stuff: I think until W98 only 16-color or black-and-white icons were allowed for applications. Can you please try pointing to a Black-and-White or 16-color .ICO file? You might be able to find some in your c:\Windows folder, but I can't remember any specific names. You could also try an app which has its own B-n-W icon like xcalc and see if that always works, and compare that to an app with a true-color icon like some KDE app... At 08:19 PM 4/11/2004 -0400, Rodrigo Medina wrote (lots o' snips): I have found a couple of bugs in the XWinrc feature. 1- The ICONS instruction does nothing, i.e. the applications 2- This one is really weird. The normal behavior of XWin -multiwindow is to assing to a generic window a menu with 6 items: Restore, Move, Size, Minimize, Maximize and Close (I am not sure of the actual english names). After I tried to include some items in a particular program (xeyes) with XWinrc the following happened: b) From that point, ALL windows produced by XWin -multiwindows lack of items Restore, Minimize and Maximize in their menus and have the Minimize and Maximize buttons inactivated. This happens even to other applications, even if the XWin program is shutdown and started again WITHOUT a XWinrc file, even if the machine is rebooted and even if XWin is reinstalled. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: XWinrc Bugs
Oh yeah, I am looking over winprefs.c to see if there is anything untowards going on elsewhere in it. Maybe a GDI call somewhere returns a valid error under W98+ for invalid data or out-of-mem, but under W95 it kills the GDI. I'll be sure to post any findings, but my time to look at this is quite limited now... At 07:59 PM 4/13/2004 -0700, I wrote: ...Maybe you've hit GDI heap exhaustion? IIRC the easiest way to see GDI and SYSTEM heap free is to (seriously!) run Solitaire, then do Help-About... Running out of heap makes bad, bad things happen under W95/98/ME. ... At 08:19 PM 4/11/2004 -0400, Rodrigo Medina wrote (lots o' snips): I have found a couple of bugs in the XWinrc feature. 1- The ICONS instruction does nothing, i.e. the applications 2- This one is really weird. The normal behavior of XWin -multiwindow is to assing to a generic window a menu with 6 items: Restore, Move, Size, Minimize, Maximize and Close (I am not sure of the actual english names). After I tried to include some items in a particular -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: window focus, raise, and stacking order
Hi Harold, Takuma, Brian, I have commited a 1-line fix (ok, 2 with comments) for this: when a WM_WM_ACTIVATE is received by the winmultiwindowwm.c local event processor call the X restacker. I tested it and it fixes this (under the X-mouse in XP's TweakUI, can't test under 98 or 2K ) and it also fixes the problem where windows aren't restacked when you bring up the window menu on a lower-level window. At 09:20 AM 3/31/2004 -0800, Brian Diggs wrote: I have discovered what I believe to be a bug in the window manager code part of the cygwin/X server. It is an interaction between the point-to-focus setting in Windows (a.k.a. Activation follows mouse in TweakUI) and raising windows. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: About box
Howdy Harold, Subject: Re: About box .. URLs: not possible in a dialog, as far as I can tell since this was how I wanted to do it too. Buttons were the only way I could do it. I have the feeling this is going to turn into the same kind of style argument as the ICON resource. ;) FWIW, there are multiple ways of implementing URLs in a dialog box. I've done both in my own W32 apps: Owner-drawn buttons: Your DialogProc() gets notifications to draw the button, so you can implement the underlined URL drawing there Override the WndProc for the buttons created by the dialog during InitDialog (Not very portable, needs COM working) Instantiate an ActiveX control I can submit some simple code that does the overridden windowproc (makes the pointer a little hand when you've over the icon, too!), but don't want to push the issue since it's more of a style than substance issue... -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: About box
Howdy Harold, At 01:49 PM 3/26/2004 -0500, Harold wrote: Earle F. Philhower, III wrote: ...I can submit some simple code that does the overridden windowproc (makes the pointer a little hand when you've over the icon, too!), but don't want to push the issue since it's more of a style than substance issue... By all means, please just commit code that does blue links in the dialog box. I was aiming to do that and didn't see a way to do it the first time through. Done, but for some reason the CVS commit list has put me back in the requires moderator approval class of user (the last change I did, the commit email came back just fine w/o moderator intervention AFAICT)... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: XWin 4.3.0-50 crashes with -multiwindow (ping Earle)
Howdy Fabrizio, At 09:34 AM 3/25/2004 +0100, you wrote: I tried version 4.3.0-60 and it worked without crashing in 24bpp mode. There is a minor glitch left: in 24bpp mode, the icon at the upper left corner has wrong colours, while the colours are right in 16bpp mode. I'm sending you PNG files to show what's happening. That's an easy fix, what's going on is we're still assuming packed format in the X icon crawling, but it's really got 1/4 of the bytes unused (32bits per pixel, not 24bpp = the whole cause of the crash in the first place!). We crawl over each line of the X icon with x=x+(effXbpp/8). We should be doing something like x=x+(BytesPerPixel(ximage)) or make effxbpp=32 when xbpp=24... I'll look at it tonite unless Harold has beaten me to it again! -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: XWin 4.3.0-50 crashes with -multiwindow (ping Earle)
Howdy Harold, At 12:00 AM 3/26/2004 -0500, Harold wrote: Nope, not going to beat you to it. This issue is what I was referring to when I said that Earle should probably look at the PixmapBytePad patch to make sure it was complete. :) There's a saying I've learned from my verification engineers: If you don't test it, it won't work! WinXP doesn't list 24bpp mode anymore, VICE doesn't compile under cygwin w/o work, and I'm not likely to shell out $$M to buy an Oracle DB. :) To top it off, freedesktop's CVS /tmp disk is out of space so CVS isn't working. Ouch! I did some unit-testing of the undocumented BitsPerPixel() macro, and it seems to be what's needed. Changing line 74 to effXBPP = BitsPerPixel(pixmap-drawable.depth); will set it to 32 when given a 24-bpp drawable, giving a pixel stride of 4 bytes as desired. It also doesn't break any of the 1-, 16-, or 32-bit icons that I was able to test (the return values of BPP() match expected there too), but I still have no 24-bpp icons to try. I'll try the commit again tomorrow morning, but if Fabrizio wants to beat up his local copy before then and report back it'd be appreciated! Also, I think you mentioned that 1 bit pixmaps were messed up. If that is still the case, it is because the GDI DIB 1 bit bitmap has a reversed byte order. So, you'll have to swap the byte order for 1 bit pixmaps when you convert them. Give that a try and let me know if it works... ping me as soon as you look into it cause I'm really wondering if that will fix it. This was way back when I was first writing it, IIRC. I don't think I've seen any 1-bit icon problems or heard of any (except for the complaint that xcalc's scaled icon was ugly) since. If someone has a specific problem I'll look into it, but 1-bit is working 100% AFAIK... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
RE: Hydravision problem?
Howdy,
At 10:05 PM 3/24/2004 -0500, Pete Inskeep wrote:
On the secondary display the xterm seems fine. No
immediate issures.
On the primary display the refresh does not seem to work
correctly.
The window seems to have some smaller portion on the left hand side
that works correctly. The size seems to vary from a sliver on the left
barely visable to about half the xterm. I can't seem to tell
whats determining the size.
The part that does not refresh is black or white. Even the pointer
(which is a }{ symbol) seems to stop where the refresh stops.
Note that it will go up and down and you can still see part of it
on the edge of the refresh area.
Does Hydravision expose two separate displays in the Display control
panel, Advanced tab (i.e. numbered 1 and 2 in the dialog)? If so,
what is the orientation of these displays? relative to the one
you have defined as the main screen (use this device as
primary monitor)? Can you click-and-drag both displays and report
the (x,y) coordinate of each one's upper-left corner (shows in
a balloon help window when you draw a monitor in the dialog)?
And are the X/Y pixel dimension of each monitor the same?
It looks like what's going on is the X/Y dimensions of the X root
window aren't matching the X/Y dimensions of the Win32 desktop for
some reason. The same thing happens if you use multiwindow
w/o the multiplemonitors option on a 2- or 3-head box...
-Earle F. Philhower, III
[EMAIL PROTECTED]
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Re: XWin 4.3.0-50 crashes with -multiwindow (ping Earle)
Howdy Fabrizio, Harold. Thanks for the good debug Fabrizio! The 24bpp icon handling was something I never could test: I couldn't find any apps that had 24bpp icons, all I found were 1- 15-, 16-, or 32-bit ones. I was assuming the X server always used a packed format, but PixmapBytePad() looks to be the proper way of handling this. (Can I ask how you knew? I did a Google on the macro and didn't come up with anything of interest, I only found stuff in the header files themselves...) Harold, the xStride calc looks great, but by removing the conversion of 15-bpp modes into effective 16-bpp modes will break 15bpp icon handling. 15-bpp modes are handled exactly the same as 16bpp modes, except they are not bit-packed (there's 1 extra unused bit every pixel) so you can't do (bpp/8). To fix it we can reinstate the if()... if (pixmap-drawable.bitsPerPixel == 15) effXBPP = 16; else effXBPP = pixmap-drawable.bitsPerPixel; if (pixmap-drawable.depth == 15) effXDepth = 16; else effXDepth = pixmap-drawable.depth; Or get rid of the effX* variables completely, but modify (~line 218) if (effxdepth==16) into into if (xdepth==16 || xdepth==15) and modify all of the X image ptr walking ptr += posX * (effXBPP / 8); into ptr += (xbpp==15)?(posX * (16/8):(posX * (xbpp/ 8)); If you'd like I can do it, just let me know which one would be more appealing! Personally I find the effX variables make the routine a bit more readable, but that's kind of expected since I put them there in the first place... At 07:49 PM 3/23/2004 -0500, you wrote: Fabrizio, It looks like your conclusions are correct. I have included your suggested change in XFree86-xserv-4.3.0-60. Please test this on a 24 bit depth system. It seems to work okay on 32 bit depth systems. I checked the change into CVS as well. I think that Earle should probably take a look at it to verify that it is likely correct since there are several calculations to correct the depth and bpp values, which may be made redundant by just using PixmapBytePad instead; but the function confuses me too much to understand it quickly. Harold wrote: Harold and all, I built XWin from source and debugged with gdb, and in that way I was able to track down the bug. It is due to my visual being 24bpp. It does not occur if it is changed to 16bpp. 32bpp is not available, but I am confident everything would work in that case. Here is what happens: - winScaleXBitmapToWindows is called. The pixmap passed has height 42, width 48 and bitsPerPixel 24 - effXBPP is 24, xStride is 144 (48*(24/8)) - iconData is allocated as an array of 144*42 bytes - then, miGetImage is called. Here the line linelength = PixmapBytePad(w, depth); is executed with w=48 and depth=24. As a result, linelength is 192 (48*4), not 144 (48*3). - in the following for cycle, pDst (initialized as iconData) is incremented by linelength(=192) each time. Soon the pointer overflows the allocated bounds, causing the crash. It seems that handling of 24-bit display is broken. Maybe winScaleXBitmapToWindows should use PixmapBytePad to calculate xStride, but I'm only guessing as I'm not an expert. Regards, Fabrizio -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: XWin 4.3.0-50 crashes with -multiwindow (ping Earle)
Howdy Harold... At 10:17 PM 3/23/2004 -0500, you wrote: Upon closer inspection I think you'll see that the logic of the statements is unchanged. I was working on adding an additional case for 24-bpp and reworked the if/else pairs to more a set default/override default it needed structure. Looked cleaner to me, so I left it :) Let me know if you still think it is changed or not after another inspection. D'oh, I did just a CVS diff and I latched on to the unconditional assignments. I just did a cvs update and it looks fine, no changes needed. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
Hi Takuma, At 07:56 PM 3/20/2004 +0900, Takuma Murakami wrote: You give me a good insight to improve Z order handling. I believe we can approach to better solutions. The attached is my latest code which should fix all problems on restacking and a-o-t windows without using fAlwaysOnTop flag. Could you try and review this? After 48 hours of continuous running in a mixed environment of both X and Windows apps I haven't noticed any problems at all, and I've seen from the logfile that the fRestacking flag has captured and killed some recursive restacks as expected from looking at your code. The only glitch I have seen, and this is NOT new, is that when the Win32 Z order changes because of a right-click system menu or a click-and-drag to move a window, the X window is only restacked at the end of the menu or move operation. I don't see any reason to not commit your changes to CVS as soon as possible! -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Emacs menus act strangely
Howdy, At 12:08 PM 3/20/2004 +0100, Alexander Gottwald wrote: Earle F. Philhower, III wrote: My change email has been spotty, I've only received notice of one ... The commit message I got yesterday showed the comma in the realname seems to be the problem. It uses Earle F. Philhower as first Address and [EMAIL PROTECTED] as second. ... Yes, I hope that is the only issue. I had the freedesktop admins change my realname to one without a comma yesterday, hopefully that'll clear things up in the future. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
Hello Takuma, At 07:56 PM 3/20/2004 +0900, Takuma Murakami wrote: You give me a good insight to improve Z order handling. I believe we can approach to better solutions. The attached is my latest code which should fix all problems on restacking and a-o-t windows without using fAlwaysOnTop flag. Could you try and review this? It works great from my testing today! On Monday I'll bring it to work for a harder test, I normally have 10 or so emacs and xterms running with an occasional EDA tool. (It seems that cygwin's emacs-x11 has some problems, not due to these changes, so I can't get too many started locally to test...) of the regular stack. It's a 1 line change in winmultiwindowwndproc.c. It must be the SetWindowPos() in the winTopLevelWindowProc's WM_SHOWWINDOW handler. I removed SWP_NOACTIVATE flag since popups can't get into the front with the flag. Yes, seems fine w/o that flag set. The HWND_TOPMOST still gets set fine, and menus stay in the top z-pane. I just put it in there because during some intermediate testings I left all created windows as OVERLAPPEDWINDOW and not set back to POPUP (for the cascading). In recent changes I made winRestackWindowMultiWindow empty I was wondering about the #if 0 on this section, but your new reorder routine seems to keep things working 100%. and removed winReorderWindowsMultiWindow(), which were my fault and forced you to reinvent PreserveWin32Stack(). I think winReorderWindowsMultiWindow() is Kensuke's version of PreserveWin32Stack(). He does the work in X server's internal function (ConfigureWindow) while you do through WM thread (XRaiseWindow). Yes, I'm more familiar with Xlib than internal DDX routines, so chose the one I understood. The restacking you've put back in the ReorderMW works just as well, or probably better. One thing I was worried about, and I see that you've taken care of, is the fact that since we iterate over the Win32 window stack and do a series of ConfigureWindow/etc., those ConfigureWindows() might cause yet another Restack call, resulting in up to ((n*(n-1))/2) calls. The fRestacking flag you put back in looks like the easiest way of handling this... Thanks, I'll let you know if anything pops up in my testing! -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
Hi Takuma, thanks for your responses! This is in answer to your two earlier messages... Tamuka Murakami wrote... Popups on a-o-t windows are having problems and should be fixed. Did you fix it without reviving fAlwaysOnTop? I'm interested in the solution. Yes, this does not require the flag. Basically, any overridden window is now moved to the absolute top of the Z order, not just the top of the regular stack. It's a 1 line change in winmultiwindowwndproc.c. 1) Is minimization of a-o-t windows broken on release-59? 2) Does the CVS build fix restacking problem? Now it's quite clear to me, the culprit is my restacking bug. If Earle's solution fixes #2, then it is what we've sought for. Even if it doesn't fix it, he gives a nice stepping stone to the final solution. I'll look at the code for a while. I'll have to read the archives some more to understand what you mean by the restacking bug, but FWIW there's a new function called PreserveWin32Stack in winmultiwindowwm.c which just walks the Win32 window stack after a map or a raise and forces the X stack to be in the same order. It's implemented now just as a series of XRaiseWindows (it may be possible to use the X combined restacking function)... -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: Emacs menus act strangely
Howdy all, Subject: Re: Emacs menus act strangely I just installed all new packages of X. Now when I start emacs from xterm's menu, and try to click a menu from newly started emacs, the menu pops up away from its usual place and doesn't work. Already been reported and a fix is on the way. It's in the CVS as of this morning, if you can compile yourself then just cvs update and make Xwin.exe, OTW we'll have to wait for a new test release... -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: X/Cygwin icon proposal
An icon doesn't deserve *this* much attention, but... Nahor wrote... Subject: Re: X/Cygwin icon proposal Alexander Gottwald wrote: It looks good in the tray and taskbar, but not in the titlebar. (see attached images) If you can build ico files with both alpha and non-alpha icons why not include your version with alpha channel and for non-alpha either the boxed (which I liked) or a plain two-color variant. .. cygwin is unix. unix is simple (shell and stuff) and this is the opposite of the bubble-gum os WinXP with alpha channel. Uh? I don't get your point. I personally don't buy a machine just to run unix. I use it to do other stuff (mostly compilation) that do make use of CPU power. So I have a recent machine, so I have XP. I assume that quit a dew (most?) geeks using Cygwin/XFree would be in the same case. But it's just a guess. Here's my two cents on the issue, as someone who has supported an application for 7 years that, at one time, supported everything from Win 3.1 w/Win32s through Windows XP: - Default to a safe setting for anything that's not critical. - You'll save TONS of user grief, and by extension, your own. Sure, at home I run WinXP. But at my office, and lots of other offices where XWin.exe is used people are still using Win NT or 2K. You can't just go to your IT department and say gimme WinXP, it's new and makes things faster and more fun! And from the recent list archives it seems like there are home users w/Win98 using cygwin. Default to a safe icon format but include the XP specific one in the exe. You can access it with a line TRAYICON ,101 in your .xwinrc file no matter what. Or, fix the code to detect the OS. If OS=Win5.0 use alpha icon, OTW use standard icon. That can be done at runtime w/a few lines of C. -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: Emacs menus act strangely
My change email has been spotty, I've only received notice of one CVS commit I did myself. Plus, it seems like freedesktop.org is having some troubles: their website is inaccessible right now at 12:45PM PST... -- Original Message - Subject: Re: Emacs menus act strangely Date: Thu, 18 Mar 2004 15:18:01 -0500 From: Harold L Hunt II [EMAIL PROTECTED] To: [EMAIL PROTECTED] ... Huh... I didn't see the email message, so it must have gotten held up. I'll do an update and release it if it comes down. -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: X/Cygwin icon proposal
Howdy Nahor, For someone who's entire contribution to XWin has been an alpha-blended X icon you've got some loud opinions... Subject: Re: X/Cygwin icon proposal From: Nahor [EMAIL PROTECTED] Earle F. Philhower, III wrote: Default to a safe icon format Beep, sorry, you're computer was taken over by the icon then crashed, please reboot :) But anyway, the alpha *is* safe for other OS (well maybe not for NT, but I haven't heard back from haro about icon_test9 which seems to work fine for Alexander). It may not be to your taste but it is recognizable as the X logo. Looking really nasty under OSs earlier than XP is a bug I'd say. Plus it's probably rechnically an invalid icon resource under those OSes so you may wnd up causing a boom (hey, under 95 or 98 it doesn't take much to crash the system!) Or, fix the code to detect the OS. If OS=Win5.0 use alpha icon, OTW use standard icon. That can be done at runtime w/a few lines of C. Which one? The monochrome one? Or the one with the white background? Maybe the old one with the white specks? And how do you do the runtime thingy when XWin isn't running and Windows displays the icon in Explorer? You've not very familiar with how a shortcut is made, are you? Make the 1st icon in the file the clean X-in-a-white-box that's been there for some time. Windoze shortcuts then will use it by default. Then, since you're so unhappy with the icon, submit a patch to the x-create-shortcut-icons package that checks the OS version and if it's XP or greater says create-shortcut w/icon 102, and voila... Maybe Halrold should only distribute the source code, and let people recompile xwin.exe by themselves that way they can choose their own prefered icon for the binary. It's already there in CVS and his test releases, have a ball! -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: X/Cygwin icon proposal
Howdy Harold, Subject: Re: X/Cygwin icon proposal Date: Thu, 18 Mar 2004 18:22:12 -0500 From: Harold L Hunt II [EMAIL PROTECTED] For someone who's entire contribution to XWin has been an alpha-blended X icon you've got some loud opinions... .. http://x.cygwin.com/devel/server/changelog-050.html He added the -nodecoration parameter, scrollbar support, build rules for Windows resource files, lots of stuff. Sorry, then, Nahor, didn't recognize the handle. (Just when I was getting a good flamefest started, too!) .. But Windows has rules for picking icons from executables (but they are hard to find documentation on) and I would hope it is possible to order the icons and provide the proper formats such that the default icon for the *executable* (not shortcut) would be the one that looks nicest on the system. Yes, the .EXE it's going to take IIRC the 1st icon it finds in the file (lowest resid, I think). What I'm really surprised about here is that the ICON format lets you store a bunch of different formats in just one ICON resource (you can specify a 1-, 16- , 256-, or 16M color, all in 16x16, 32x32, and 48x48 in one ICON). Does the one that everyone is so riled up about have the other, fallback formats included? If not, can they be added and tried out? You could make the non-alpha version of the ICON all the boxed-X and leave the 16M+alpha one as the floating X... As long as it doesn't crash, it can be a picture of an emu as far as I care, but that all centers on whether that emu is safe under earlier OSs or not...Crashing emus stink... -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Changes to multiwindow mode and always-on-top (ping Takuma)
Hi all, I've been hacking away fixing up the support for always-on-top mode which seems to have been broken since the upgrades Takuma did about 3 weeks ago (~v1.1.6.2? of multiwndproc, etc). Minimized always-on-top windows never disappear from in front of other X windows in all the tests I've tried. And when a non-aot window is created on top of an a-o-t one, it is popped to the top of the X window stack, even if there is an a-o-t window in Win32 space above it. It's as if a chunk of the window below the aot window is showing through, and a real pain. (It's caused by XRaiseWindow()ing a window that's not really at the top of the Win32 stack...) I've cleaned all this up in my local copy, and made Emacs/xterm menus work properly in a-o-t mode (they don't disappear!) without stepping on any of Takuma's changes. However, I can't get minimization to work without turning off the Win32 a-o-t setting on the window during the minimize... The old behavior was to copy the current a-o-t state to a private flag in pWinPriv on a minimize, remove the a-o-t bit from the window, and on a restore set the a-o-t flag back on the Win32 window if so cached. If I put this flag and behavior back I can get things working 100% AFAICT: a-o-t windows minimized from the taskbar, the system menu, or the button disappear. Takuma, if you're reading the list, can you give some insight as to why you took out the old private flag? (I agree it should be cached in the wndproc on the WM_SIZE message, not the SC_* menu handler where it was, that's where I've got it placed presently, and it now works for all different methods of minimizing a window I can think of...) -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
Howdy, At 02:05 AM 3/19/2004 -0500, Harold wrote: Yup, Takuma knew there were bugs, but the new code is so much more efficient (the old code was performing lots of operations during our block and wakeup handlers, which get called hundreds of times per second) that I told him to leave it there for a few weeks until we could figure out if we could fix it and keep the performance improvement. Yes, it's way faster than before with his changes, but sometimes it seems to have optimized too many screen updates. These only seem to be occasional glitches, and forcing a redraw of the window always clears things up (except for the stacking order stuff). I fixed things up the straightforward way: When a WM_RAISE or WM_MAP event filters to us, I start with the mapped window, xvert it to the HWND, and work a way through Win32 space up to the top of the Z order. Any window that's still above the HWND we just XRaise()ed, I XRaise the XWindow of that HWND. AFAICT this will only occur with AOT windows, and should result in 0 work at all if there aren't any AOTs... Hmm... if you have it mostly fixed, then check it in... Takuma is currently burning cycles trying to fix this also but I don't think he has gotten far. I think he will appreciate having a little help :) All I've really fixed, AFAIK, is the case where the X and W32 stack order aren't the same...I doubt this is what he's having trouble with, it's too simple. If I put this flag and behavior back I can get things working 100% AFAICT: a-o-t windows minimized from the taskbar, the system menu, or the button disappear. That sounds good. Takuma was talking about re-adding the fRestacking flag... is that the flag you are talking about? No, unfortunately this is just a bit for the HWND_TOPMOST state of the window when it's minimized. Without clearing the TOPMOST state in W32, the window technically stay on top of other windows since a SIZE_MINIMIZE is handled by an ignored MOVE (-32000,-32000) IIRC. Regular apps don't care since they always have a consistent view of a window's position, but in this case we have X which thinks the window is still at (x,y) and Windoze which has it as (-32k,-32k)... [5 minutes later...] This just in: Takuma said go ahead and commit both fixes so he can review them. He says he will be able to respond sometime after four hours. (He is in #cygwinx on irc.freenode.net now.) OK, it is checked in (sorry if no xorg-commit mail, I think my pdx.freedesktop.org CVS account has a real name that's not valid...) -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Updated: XFree86-[base,xserv]
Howdy Harold, Harold wrote ... While you are at it, would you mind looking at what happens in emacs when you have set the Always On Top flag for a window? The menus in that case briefly popup, then get stuck behind the main emacs window. If you hold the mouse button down and drags it around between a few menus you can eventually get them to stick on top... sounds like all child windows of an Always On Top window should also have that flag set. I don't know if that is easy or hard to solve though. According to the Windoze docs any subchildren of a window on the top of the Z order inherit the always-on-top setting automatically. Unfortunately it looks like when Emacs makes a menu, it creates a window whose parent isn't the editor window. It probably makes a transient over the root display, so as far as X and Win32 knows it's just another undecorated window. I'll throw in some local debugging and take a gander and see if this is really the case. It *may* make sense to place transients at the top of the Z stack always, but I'd rather not do that without a whole lot of thought... -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: Updated: XFree86-[base,xserv]
It's bad form to talk to yourself, but... At 06:19 PM 3/17/2004 +, Earle wrote: OK, I feel really stupid now. I did test this locally but not with xterm menus. I do most of my work in emacs, which seems OK, so didn't notice... There's a transient property on the window that should be examined before cascading it, I'll either back out the change or add the transient property check tonight. I've got the fix ready, but it seems freedesktop.org is down (www cvs both) tonight. I'll try again tomorrow morning, but it turned out to be that we have to check for 3 things @ line ~482 of winmultiwindowwindow.c: 1. Not predefined in hints (preplaced w/-geometry or by the app) 2. No WM_TRANSIENT_FOR ATOM attached (for things like splash screens) 3. No pWin-overrideRedirect (undecorated) Adding those 3 changes makes everything back to hunkey-dorey in emacs, xterm, xfig, xfontsel, and xemacs. The main app window is cascaded but menus aren't touched. Harold, I'll look at the always-on-top stuff once these are checked in... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Garbled task-bar icon
At 12:31 PM 3/15/2004 +0900, Haro wrote: I'm not sure I'm following your instructions correctly, but changing resolutions does not seem to change the situation. I've also placed both .ico file into same directory, browsed them using Widows exlore, and x_test6.ico gets garbled but x_test8.ico shows nothing. It's same even when browsed with small icon. FYI, I've attached the screen-shot. I've only been partially following this thread but as a point of reference I found that drawing of icons was something that device drivers accelerated under Win95/98/ME, but sometimes they didn't quite accelerate it properly and introduced artifacts when confronted with anything other than a 16-color 32x32 icon (IIRC ATI drivers were really bad about this!). FWIW I've never seen this kind of driver problem under Win NT/2K/XP... As just a silly test, if you're running Windows95/98/ME, can you turn off all HW acceleration (there's an option in the System/My Computer control panel, Advanced tab IIRC, or in the Display properties control Advanced tab/button for this) and restart the computer and try to start XWin again and see if the icon is still bad? If it works unaccelerated, then there's a driver issue. If it doesn't work unaccelerated, then it's something else completely...(Don't forget to turn back on acceleration after the test!) -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: X/Cygwin icon proposal
Hi Harold, Attached please find a patch against 4.3.0.54 that: . Adds TRAYICON iconidentifier to the .xwinrc file parser which lets you, surprisingly enough, change the tray icon . Adds file.dll,XX parsing to the icon loader to support grabbing icons from inside DLL or EXEs . Adds ,XX parsing to the icon loader to support loading icons that are stored in the XWin.exe RC file (today there's only one, but I think folks are thinking of having multiple at some point in the near future) . Adds handling of the TaskbarCreated Windows message which lets you re-add the taskbar icon when the main explorer starts. Otherwise if explorer dies and is restarted for some reason, you'd lose the X taskbar icon until you exited all your X apps and restarted XWin. . Fixes the icon loader to not append the ICONDIRECTORY to icons that are fully specified w/a drive letter (i.e. c:\blahblah) [These below I'm not sure if the CVS -r cygwin tree is known funky or what...] . WINMSG.H: Comments out the redeclaration of the MessageType enum. I couldn't find anything in the change logs about using a modifies OS.H (where MessageType is originally defined and included prior to this header). . WINMULTIWINDOWSHAPE.C, WINWINDOW.C: pScreen is used by REGION_INIT() and other region macros, but isn't a local variable in two functions in these files (in winwindow there was a #if 0 around the variable defintion, and in multiwindowshape it was not there at all?!...) -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com taskbar-and-icons.patch Description: Binary data
Re: X/Cygwin icon proposal
Hi folks, I'm really impressed with all the work you folks are doing! At 04:33 PM 3/11/2004 -0500, Harold wrote: Nahor wrote: Alexander Gottwald wrote: It was (is) in CVS and I really like it. Even much better than the new one. Maybe one can add yet-another-option on the commandline and have several icons in the exe (or on a special library or whatever). It won't solve the problem of the default exe icon but it will solve any the taskbar/systray/shortcuts issue. Well, I don't know about a command-line option (sounds like a reasonable idea), but I was at least going to preserve the white bordered icon as the second icon in the file. That way people could use it for shortcuts and such. Also, I think Earle's .XWinrc file may allow you to specify an alternate icon for the tray and the default icon for each window, so we may not need a command-line option. Anyone want to look into this to confirm or debunk it? It's not there today, but if people are really interested I can throw together a patch to the parser lexx/yacc to add a TrayIcon line and add the usual support for iconfile.dll,n where n=icon ID (ie. shell32.dll,5 gives the floppy drive icon). A default icon can be specified for X apps, but again it's only for .ico files and can't index into, say, XWin.exe... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: X/Cygwin icon proposal
At 01:14 AM 3/12/2004 -0500, Harold wrote: Yes, some neat things are happening. A little birdy told me that OpenGL acceleration is almost there... glDoom, here I come! As long as XWin keeps running runs w/o crashes for longer than the interval between Windows patches, I'm a happy camper... At 04:33 PM 3/11/2004 -0500, Earle wrote: ...a patch to the parser lexx/yacc to add a TrayIcon line and add the usual support for iconfile.dll,n where n=icon ID (ie. shell32.dll,5 gives the floppy drive icon)... Yes, that sounds good. Let me just double-check that the TrayIcon feature *would* allow you to select the second icon within XWin.exe, right? That is okay that the icon for other applications could not index into XWin.exe, as long as XWin.exe can specify icons within itself. Yup, that would be the plan: If no .XWinrc file or no TrayIcon, run with the present default settings (I guess whatever ICON 0 is compiled into XWin is what you'll get). Anywhere an icon is specified in the .xwinrc file, do the following: . If the iconame is just ,# then load the specified icon number from the XWin.exe resources . else if the iconame is filename.exe/.dll,nn then load icon ID nn from that file . else use present load .ico flow . If we're unsuccessful in loading the icon, use the default X icon from XWin.exe I also keep meaning to write a man page for the .xwinrc format, but since I don't follow main cygwin app development I'm not sure if manpages are the preferred format or if everyone is doing GNU Info files or something else. It's probably in one of TFM that I've not R yet. ;) -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: different resolutions on different monitors
At 10:11 PM 2/11/2004 -0800, I wrote: Actually, I think it's a feature. Chad's got a non-rectangular Windows desktop: (Bad ASCII alert!) x x=monitor 1 1024x768 x y=monitor 2 1280x1024 x Oops, make that y=1024x768, x=1280x1024)... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Patch for centering exit/mode change dialogs on multiscreen
It seems that the DS_CENTER property only centers a dialog onto the 1st detected monitor, and not the primary monitor (selected in Desktop props). At my office the two are the same, but on my home setup my center DVI monitor is detected as #3... I'm attaching a minor patchfile which programmatically centers the dialog during the WM_INITDIALOG stage using a pretty standard center() function for the exit and mode change dialogs. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com centermultiscreen.patch Description: Binary data
Re: Minimising window with Always on top attribute leaves contents in underlying window
Hi Mike... At 08:29 AM 1/25/2004 +, Mike wrote: I'm using 4.3.0-42 and have noticed that the following minor bug in multi-window operation when running on Win2K and WinXPPro: Two windows (terminal or otherwise) are overlapped and the topmost one has it's Always on top attribute set (by right-clicking on the windows title bar). The topmost window is then minimised, leaving a copy of its contents on the desktop, viewable by moving the remaining window over the portion of the desktop previously occupied by the other window. It's been a while since I submitted a patch, but since this problem is due to my code I'll be nice and fix it. Basically, whenever we get a WM_SYSCOMMAND:SC_MINIMIZE we need to disable the HWND_TOPMOST attribute and let the X system recognize it. On a WM_SYSCOMMAND:SC_RESTORE we just need to reset that attribute to what it was before. I'm attaching a patch *against the CVS -r CYGWIN tree* because I cannot get the XWin-4.3.0-42 source available on http://xfree86.cygwin.com/devel/server/changelog.html to compile properly, whereas the freedesktop CVS goes thru without a hitch. It adds a boolean fAlwaysOnTop to the window privates; caches the AOT value on a WM_SYSCOMMAND:SC_MINIMIZE and removes top-z attributes from the window; restores the AOT value on a WM_SYSCOMMAND:SC_RESTORE; and changes the WM_WINDOWPOSCHANGED event handler to always allow the Windoze DefWindowProc() to be called (necessary for the changes I did, and doesn't seem to have any negative effects). -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com fixaot.patch Description: Binary data
Re: Minimising window with Always on top attribute leaves contents in underlying window
Howdy Harold, I thought you were taking it easy for a while! At 11:37 PM 1/25/2004 -0500, you wrote: Any reason for the following in your patch: @@ -893,7 +909,7 @@ if (s_pScreenPriv != NULL) s_pScreenPriv-fWindowOrderChanged = TRUE; } - return 0; + break; The thing that strikes me as odd is that you have to return from the WM_WINDOWPOSCHANGED message without calling DefWindowProc (which will get called if you change that return to a break) in order to prevent Windows from breaking that message down into a WM_SIZE and WM_MOVE message and sending those in addition. My worry is that you may have essentially found a bug in the WM_WINDOWPOSCHANGED handling that was fixed by allowing the WM_SIZE and WM_MOVE messages to be generated and handled, when we should really fix such a bug instead of accidentally masking its existance. I'm not comfortable removing this change from your patch since it will then need to be tested again to verify that things work as expected. Since you have already been testing it, I figured it would be easier for you to do the testing :) I did extensive testing without that change, actually, because it took me a while to figure out why the minimize button and sysmenus worked but the taskbar left-click 2x didn't. ;) You can remove it, but minimizing the window by 2x-clicking on the Windows taskbar won't propagate the Z order change w/the same messages as if you were to use the system menu or the minimize button. Why? AFAICT the minimize button or menu item send a wm-move, even if you don't let DefWindowProc() do its thing. I suspect Explorer sends its own messages when you click on the taskbar, and they are not the same as the frame WndProc()'s. FWIW I can't really see any reason not to allow DefWindowProc to have a shot at the WM_WINDOWPOSCHANGED message, but I'll admit that I've not gone through all of Kensuke's code... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Crash in xserv 4.3.0-40
Howdy Harold, Christopher: At 06:06 PM 1/15/2004 -0500, you wrote: On Thu, Jan 15, 2004 at 06:02:24PM -0500, Harold L Hunt II wrote: With that being said, I'll address the issue of symbol information: 1) If I include symbol information and there are no crashes, then people will complain (don't argue with me, they *will* complain) about the size of the download being X KB larger than it had to be. Newer versions of binutils allow you to split symbol information into a separate file which gdb understands. I've been meaning to release a version of gdb and binutils which can do this for a while and will probably do this as soon as I'm out from under my current mountain of work. Another option is to generate a link map file when you do the final compile. It's just a text file of 4KB or so and you can manually reference the failing address from a stackdump into a routine name. For my commercial software I've found this is often enough to figure out what's wrong without worrying about distributing symbol files or the extra size associated with them. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Patch: -multiplemonitors is default, -nomultiplemnoitors added
Hi Harold, Ayvind...
At 12:45 PM 1/15/2004 -0500, you wrote:
Thanks, got it. Will look at it soon.
Harold
Øyvind Harboe wrote:
Ref. earlier post, here is the patch.
http://sources.redhat.com/ml/cygwin-xfree/2004-01/msg00160.html
I compiledtested; works on my rocket.
This is just my $0.02, but instead of changing the default behaviour
for non-multi window mode, why not just patch only the mode that
doesn't work properly in a multihead machine, multiwindow? Folks
running single window on a multihead setup are probably doing it
for a good reason (i.e. left monitor=X, right=Windows) and would need
to change their startup scripts...
Unfortunately I don't have a working compile setup for the new XWIN .40
or I'd give the patch, but basically use everything Ayvind did except the
MultiMonitor mode value change, move that setting into the
if (ISOPTION(multiwindow)) {} block.
-Earle F. Philhower, III
[EMAIL PROTECTED]
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Re: Failure to make grap 1.30 under cygwin 1.5.5
Howdy, At 03:48 PM 9/25/2003 -0400, CGF wrote: ...Just so it's clear: I don't care to get involved in fixing issues where the bug report is something is horribly wrong with it, either, so if you do actually want to work on fixing it, then I'll need more to go on than I have been given and I'll need some hint of cooperation rather than attitude. But, of course, that's a good lesson for life anyway. OK, I know this should be on the cygwin-apps but since it showed up here can I make a better problem report on the new flex version? Internal common parsing variables and functions that were available in 2.5.04 no longer are accessible (i.e. yytext_ptr or yyunput, yy_flex_realloc). As I'm not an expert in Lex I can't say if these are legit functions, but they have been there since time immemorial and are found in the X11R6 tree in several spots besides the xserver/hw/xwin branch. For debugging I tried to find the .31 version but couldn't find it on any official site so I couldn't find a changefile and see if maybe there's a new -switch or something to enable legacy mode beyond the standard -lex mode option. A compile of the version available @ gnu results in a version that still has these needed functions. The lex header files are very, very different between the 2.5.4 and .31 versions, but I didn't go into detail because they are quite convoluted. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Fun with flex
Howdy Harold... At 08:26 PM 9/15/2003 -0400, you wrote: I am working on building a release for Cygwin 1.5.3. I am getting some fun errors (listed below) related to changes to flex. I would appreciate any help in pointing out how these problems should be fixed. Please note that this is a build of the XFree86 4.3.0.1 CVS branch. I would suggest that the flex package that's installed by Cygwin 1.5.3 is NOT valid. I have just d/l'd and installed the version of flex straight from ftp.gnu.org, and it compiles everything exactly as before, pswrap and the old lex grammer file winprefslex.l. Some of the header or support files must have been munged. The version I used was: $ flex --version flex 2.5.31 flex -l -t lexer.l lexer.c gcc -O2 -fno-strength-reduce -Wall -Wpointer-arith -I../.. -I../../exports/include -D__i386__ -DWIN32_LEAN_AND_MEAN -DX_LOCALE -D_X86_ -D__CYGWIN__ -D_XOPEN_SOURCE -D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DNO_ALLOCA -DFUNCPROTO=15 -DNARROWPROTO -DXENVIRONMENT-c -o lexer.o lexer.c stdout: In function `yylex': stdout:1199: `yy_prev_more_offset' undeclared (first use in this function) stdout:1199: (Each undeclared identifier is reported only once stdout:1199: for each function it appears in.) /usr/include/stdio.h: At top level: stdout:2988: warning: `yy_flex_strlen' defined but not used make[4]: *** [lexer.o] Error 1 make[4]: Leaving directory `/home/harold/x-devel/4.3/build/std/config/pswrap' okay, continuing in lib/dps ../../config/pswrap/pswrap -a -o dpsclrops.c -h dpsclrops.h dpsclrops.psw ../../config/pswrap/pswrap: not found make[3]: *** [dpsclrops.c] Error 127 make[3]: Leaving directory `/home/harold/x-devel/4.3/build/std/lib/dps' including in lib/dpstk... make[3]: Entering directory `/home/harold/x-devel/4.3/build/std/lib/dpstk' + mkdir unshared ../../config/pswrap/pswrap -o XDPSpwraps.c -a -f XDPSpwraps.h -h XDPSpwraps.h XDPSpwraps.psw ../../config/pswrap/pswrap: not found make[3]: *** [XDPSpwraps.c] Error 127 make[3]: Leaving directory `/home/harold/x-devel/4.3/build/std/lib/dpstk' -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Fun with flex
Howdy... At 11:53 PM 9/15/2003 -0400, Christopher Faylor wrote: On Mon, Sep 15, 2003 at 07:52:11PM -0700, Earle F. Philhower III wrote: I have just d/l'd and installed the version of flex straight from ftp.gnu.org, and it compiles everything exactly as before, pswrap and the old lex grammer file winprefslex.l. Some of the header or support files must have been munged. The version I used was: $ flex --version flex 2.5.31 That's funny because that is the version that is released for cygwin. AFAICT, the latest version on ftp.gnu.org, in /pub/gnu/non-gnu/flex, is flex-2.5.4a.tar.gz. Yes, good catch. The shell I was running from did not get a rehash after I did make install in the flex directory. A double-check of the version after opening a new window does show 2.5.4 as expected. This new version was used by make since it got a new shell to execute the commands. $ flex --version flex version 2.5.4 I am not having any luck d/l'ing the source files for the .31 version from the cygwin setup app so can't really do more debug than that... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: XWinrc configurable server (menus/icons)
Howdy Harold... .. You may still be correct with your worries, I'm sure there's a file descriptor that the OS is dup2()'ing there you don't want. FWIW I'm execl()'ing /bin/sh -c command string Hmm... that is a good point. We have the Win32 message queue file handle open, a feature Cygwin provides, so that we get bumped each time a message hits the queue. After the fork shouldn't you be looping through all file descriptors and closing all but stdin, stdout, and stderr? .. That's the exact thing I was thinking about, but unfortunately I haven't got a clue how to get a list of all open file descriptors under cygwin. There's a Solaris function fdwalk(), but I don't think that's POSIX standard or even available on cygwin. I suppose after the fork() you could do: struct rlimit rl; int i; getrlimit(RLIMIT_NOFILE, rl); for (i = STDERR_FILENO+1; i rl.rlim_max; i++) (void) close(i); but that seems wasteful to iterate over rlim_max... .. Okay. Does this mean you are going to implement the search-n-replace or not? Just want to know whether or not to wait for it. I like the put_env() idea that folks are suggesting, but I think it'd probably still be worthwhile to also do the string substitution. It's not that big of a deal to add both. Tonight I'll give that a go, adding the put_env() call in the LoadPrefs as well as a %display% substitution in LoadPrefs()... -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: XWinrc configurable server (menus/icons)
Howdy Harold... At 10:40 PM 8/6/2003 -0400, you wrote: 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... Ugh... what should we do here? Leave it as you did it? I plead innocence! Actually, 127.0.0.1 is what the clipboard and WM connect to, so I just left it at that. As for screens, I chose 0 because while you can have multiple screens per server, what one do you choose when you do something from a menu? If I choose xterm from the taskbar, which screen does that mean? Seriously, I couldn't think of a good answer. I don't really have any love for one or the other method, whatever works is OK by me... I shudder to imagine how the loopback adapter is slower than an IP lookup, and double-shudder when you can actually notice the difference with XWin being so slow updating the screen anyway... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: XWinrc configurable server (menus/icons)
Howdy Harold, At 06:13 PM 8/10/2003 -0400, you wrote: Should we change the file prefixes to something along the lines of winprefs then? Done in the attached patch, you'll want to rm winmultiwindowprefs.[cho] winmultiwindowyacc.[ycho] winmultiwindowlex.[lco] to get rid of the old files. The usual drill: make Makefile; make clean; make depend Please send the diff against xwinrc.2.diff. I know that a patch can add new files, but will it know to remove the winmultiwindow files that are getting renamed? If not, I will try to manually remove the new files that are renamed. I'm attaching a diff -U3 -N against xwinrc.2. It's got all the stuff as before (custom icons, menus, etc.) with a new RELOAD command for a menu item to reload the config files, and the bugfix for overridden icons when closing windows through their title bars, and the setsid() call after the FDs are closed after the fork(). The system.XWinrc file has all the documentation I've written, but I've not been able to make myself sit down and write a man page... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com xwinrc.diffs.2.to.3.bz2 Description: Binary data
RE: DDD dies on me
Howdy, At 02:37 PM 8/11/2003 -0400, Andrew Braverman wrote: It is definitely XWin that is crashing. I seem to have had some mental block when I wrote the last message because I could swear I had said it died in 24 bit, but the text doesn't lie... I will try putting a bunch of ErrorF statements in and send the resulting log file ASAP. Thanks. Ugh, I don't own a video card that does 24bpp anymore, even my old PCI Voodoo 3000 only groks 8, 16, and 32 bit modes. Debugging this will take some work I fear! Please put the errorf's in before the for row=0...iconsize line do if there is an overwrite we'll get the data before it happens... A quick glance at the switch(effBPP)==24 doesn't show anything grossly bad, but the local vars will help pinpoint things immensely... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
RE: DDD dies on me (pt 2)
At 02:37 PM 8/11/2003 -0400, Andrew Braverman wrote: It is definitely XWin that is crashing. I seem to have had some mental block when I wrote the last message because I could swear I had said it died in 24 bit, but the text doesn't lie... I will try putting a bunch of ErrorF statements in and send the resulting log file ASAP. Thanks. ... Please put the errorf's in before the for row=0...iconsize line do if there is an overwrite we'll get the data before it happens... Actually, put those ErrorF()s before the call you saw was bombing, which was before that for() loop. Also, FWIW I compiled XWin (test95+xwinrc patches) with it forcing effBPP and bpp to 24 in the winXIconToHIcon which works fine except for Windoze not liking 24 bpp icons on a 32-bit screen (comes up black). The function you're looking at functions the same way as if the desktop was 24bpp, though, so it should exercise the same code path. However, after a dozen runs of ddd (3.3.7 from the sourceforge site) I've not had a single crash. I see the bug icon outline every time. Under the unhacked XWin the bug comes out in all its colored glory. Don't know what to tell you, but it's looking the same as before, only your installation is bombing. Maybe the ErrorF()s will shed some light on something being out of whack in the X structure or the desktop DC. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Xedit failure
Howdy Rodrigo... At 03:43 PM 8/13/2003 -0400, you wrote: I have to report a failure of xedit with XFree86-bin 4.3.0-1: $ xedit Segmentation fault (core dumped $ cat XEDIT.EXE.stackdump Exception: STATUS_ACCESS_VIOLATION at eip=0041D8F7 ... $cat /proc/version CYGWIN_95-4.0 1.3.22(0.78/3/2) 2003-03-18 09:20 Version of XWin is 4.3.0-3 A clean CVS download of xfree86 from their tree, make World, make install, finally running xedit has the same problem, it's not a problem specific to the XWin packages. May I suggest using an editor that's been updated in the last 9 years? :) /* $XConsortium: xedit.c,v 1.28 94/03/26 17:06:28 rws Exp $ */ -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
RE: DDD dies on me (pt 2)
Howdy Andrew...
At 09:22 AM 8/13/2003 -0400, you wrote:
Thanks for the help. I have managed to get XWin to crash in both places
again (which one happens is random, but these are the only 2). I have
attached the log file from the modified program as well as a stack trace
from gdb for each one. Given some proverbial free time, I will try to do
some more debugging. FYI, this is just the CVS code. I will go back to the
web and find the place where it tells me how to add the test code to the CVS
code and try that. Also, though I mentioned it in the original thread, I am
not sure I reminded you in this thread that I was running ddd from a Linux
box (though that should not make a difference).
Well, all the parameters look OK. I was fearing there were negative
heights in the pixmap, like for Windows bitmaps when they're in VGA
reversed order.
The only thing I can point you to is to get a dump of the locals of
that miGetImage function right before it does the for(i=0..h) {}.
Especially linelength, which should equal the xStride that's calculated
in the winXIcontoHICON function. Also the value of i and pDst when
the lower level functions barf would be interesting.
-Earle F. Philhower, III
[EMAIL PROTECTED]
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Re: XWinrc configurable server (menus/icons)
Howdy Harold, At 12:58 PM 8/10/2003 -0400, you wrote: I have committed your patch to my local tree. However, I wonder why all of the files are prefixed with winmultiwindow. Is the code purely intended only for multiwindow modes? If so, that is fine. It not, perhaps we should rebrand this before we start releasing it and committing it to CVS. Other than that, everything looks great. It builds fine and runs, but I haven't had a chance to play around with the prefs file yet (my paths are different than yours, etc.). You're correct, the taskbar menu configuration is done for single window mode, too. Whether that's a useful thing, I'm not really sure (it'll work fine, but normally you'd just use your window manager's root menu and not touch the X taskbar icon). Before a commit, I do have a bugfix or two to post. xwinrc.2.diff throws out a window custom icon if the window is closed thru the Windoze close box, and the setsid() CGF suggested isn't in there either. I also added an on-the-fly reload menu command so you don't need to restart X to update the icons/menus. Would you like a diff against xwinrc.2.diff or against test95? -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: XWinrc configurable server (menus/icons)
Howdy Christopher, Igor, and Harold... ... Two small notes here: 1) You can actually call setenv(DISPLAY, value) inside the XWin process, which will be inherited by XWin's children. ... On Wed, Aug 06, 2003 at 01:06:55PM -0400, Harold L Hunt II wrote: The for loop that you have is the way I have seen it done before. Me too. However, if you can find an API specification for something which does something similar in the Single Unix Specification, I'd be ... getrlimit(RLIMIT_NOFILE, rl); for (i = STDERR_FILENO+1; i rl.rlim_max; i++) (void) close(i); but that seems wasteful to iterate over rlim_max... (make that rlim_cur, closing 4 billion descriptors takes too long...) I'm attaching another diff (against test95 plain), be sure to so a make Makefiles and make depend before make XWin.exe. It does all the prior stuff and a) Closes all fds on the fork()'d process b) Sets environment variable DISPLAY=xxx:yy c) Replaces %display% with 127.0.0.1:display.0 in commands d) Better syntax error display, gives lineno and expected token in XWin.log e) Error messages in log when it can't load an icon/etc. f) Checks WM_NAME property for a match for icons, not just class name ^^ Pretty neat in use, I have my fast Linux machine xterms with titlebars like Linux:machinename:$cwd and Hobbes (CalvinHobbes) icon, and my slow Sun machine xterms with a CharlieBrown icon! -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com xwinrc.diffs.2.bz2 Description: Binary data
Re: XWinrc configurable server (menus/icons)
Howdy David At 07:09 AM 8/6/2003 +0200, you wrote: Wow! This is great! Just what we were discussing earlier... Just one comment: Is it not possible to automatically set the DISPLAY variable from X so that it automatically starts the xterms etc in the right X display, rather than having to pass a commandline parameter? (In fact, if they inherited the environment, this might happen anyway, but I don't know if X defines DISPLAY inside itself...) Spawned commands should inherit the ENV settings at the time XWin.exe was started, so if your startx script sets DISPLAY before starting XWin.exe then you don't need any cmdline options. A simple string replacement in the HandleCustomWM_COMMAND() function in winmultiwindowprefs.c would also work to allow things like xterm -display %display% to work, but it's not in the code in the patch. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
XWinrc configurable server (menus/icons)
Howdy Harold,
At 07:31 PM 8/5/2003 -0400, you wrote:
Can't remember if I replied to this yet. I am in the process of getting
my Inspiron 8500 returned after having it replaced (bought it 3 weeks
ago). Both the original and the replacement randomly freeze. Google for
[Inspiron 8500 freeze] and you'll see exactly what I mean. I have been
setting up computers for the past two weeks now.
I have finally ordered a Gateway 450X notebook. Hopefully that will work
better and allow me to spend a little more time looking at patches.
Good luck, on the bright side since it went south so fast you didn't
lose too much data on the drives.
In other words, I might look at your patch tomorrow, or I might look at it
next week. Can't say for sure.
In any case, thanks for the patch, I like the idea and am looking forward
to seeing what it does.
No rush. But just delete the tar file I sent yesterday, that was really just
a parser that read the config file. It took a few hours of futzing around
today,
but I got it nicely integrated into the server. Now on init it parses
~/.XWinrc
or /usr/X11R6/lib/X11/system.XWinrc and makes custom menus and submenus for
the taskbar icon and each window, and can replace icons with ones specified
in the rc file.
I'm attaching the diffs against test95 below, please use these for any testing
you do (there are several new files, so if patch asks: you do want to make new
files...). The file _usr_X11R6_lib_X11_system.XWinrc has all the documentation
on the RC format anyone'd need. If the file's not found, you get the exact
same behaviour as test95 as far as menus/icons/etc.
** There's also a off-by-one bugfix in winmultiwindowclass.c, so no matter
what that file's changes should go in... **
Oh yeah, a simple if (fork()==0) { execl(); exit(0); } seems to spawn X and
Windoze apps fine. I know there was some discussion about this earlier...
Below's the sample config that I'm running that replaces the X.ico with one
that's
floating in my Windows directory, and replaces Xterm's with another, and adds
custom menus to Xterm, all other windows, and the toolbar window...
---
// Below are just some silly menus to demonstrate writing your
// own configuration file.
// Make some menus...
menu importantapps {
xsolexecxsol -display 127.0.0.1:0.0
xv execxv -display 127.0.0.1:0.0
}
menu root {
// Comments fit here, too...
xterm execxterm -display 127.0.0.1:0.0
notepad execnotepad
xload execxload -display 127.0.0.1:0.0 # Comment
separator
Good Apps menuimportantapps
SEParATOR
}
menu aot {
Separator
Always on Top alwaysontop
}
menu xtermspecial {
Emacs execemacs # test
Always on Top alwaysontop
SepArAtor
}
RootMenu root
DefaultSysMenu aot atend
SysMenu {
xterm xtermspecial atstart
}
IconDirectory c:\winnt\
DefaultIcon reinstall.ico
Icons {
xterm uninstall.ico
}
DEBUG Done parsing the configuration file...
---
-Earle F. Philhower, III
[EMAIL PROTECTED]
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
xwinrc.diffs.bz2
Description: Binary data
Re: DDD dies on me
Howdy Andrew... -- Original Message - Subject: DDD dies on me From: Andrew Braverman [EMAIL PROTECTED] A while ago (beginning of June, I think), I posted a note to this group that .. to figure out that the program occurred in winScaleXBitmapToWindows in winmultiwindowicons.c. I ran three consecutive tests and two of those three caused a segfault in the free at the end of the procedure (actually in mktime??? called by free). The iconData mallocs at the beginning of the procedure seem to align correctly with the frees at the end. The last caused a segfault in fb24_32BltUp which is called from the miGetImage at the beginning of the procedure. Seeing that, I decided to try the program in 16 bit color and everything was fine. For the first time, I was able to see that this program does display its own icon on the title bar. Does anyone (Earle?) have any suggestions about where I should start digging? In any case, I will try to do a little more digging over the next week or so. - A silly question, it is XWin.exe that's SEGVíng and not DDD.exe, correct? And what was the screen depth (8/15/16/24/32) you were running that caused the bomb? Also, could you add some ErrorF()s to dump all local variables to the /tmp/XWin.log file, as well as the pixmap-drawable structure elements, too? [ErrorF() works just like printf() so just ErrorF(varX=%d\n,varX); is all that's needed...] Posting the info it spits out before a SEGV would go a long way towards debugging this... The most likely culprit is that one of the conversions is overwriting the Windows icon data that it's allocated, causing bad stuff to happen later on. You can see how I switch between the possible formats on effXBPP and effBPP(the Windoze BPP we're converting to), possibly not all cases have been tested, *especially* 8-bit modes. -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: XWinrc configurable server (menus/icons)
Howdy again Christopher...
At 11:00 PM 8/6/2003 -0400, you wrote:
I'm not really up on cygwin's process model, what would the setsid() call
do? I have read the man page and I'm still not sure what's a session ID or
why I'd want a new one...
It would disassociate a tty from any child process. It's often done
after file descriptors have been closed.
I don't know for sure that it will help anything but it may stop the
console windows from popping up -- at least in cygwin 1.5.x.
Thanks, I added the setsid() just after closing all but STDIN/OUT/ERR
and before the execl() and didn't notice any problems, so next time
I put up a patch it'll have this change included. [Of course, I'm
running Cygwin 1.3 and not the 1.5 you're working on...]
I also found a small bug where if you close a window with a shared
icon from the ICONS{} section it deletes the icon even though it
shouldn't. I'm just waiting for more input on the whole
What should DISPLAY be set to? question before I clutter up the
mailing list with another patch...
Except for that, the only thing I can think of adding is a 'reread
the prefs file' command to the MENU{} format. Has anyone else
tried the .xwinrc yet?
-Earle F. Philhower, III
[EMAIL PROTECTED]
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
Re: XWinrc configurable server (menus/icons)
Howdy Christopher... At 09:57 PM 8/6/2003 -0400, you wrote: a) Closes all fds on the fork()'d process It *may* be helpful to call setsid() at this point, after you've closed the file descriptors. I'm not really up on cygwin's process model, what would the setsid() call do? I have read the man page and I'm still not sure what's a session ID or why I'd want a new one... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: rfe: seamless windows integration
Howdy Harold,
At 10:36 PM 8/4/2003 -0400, you wrote:
Thanks. Let me tell you, we already have a laundry list of dream
features. We just need people to start working on them.
There sure are a lot of managers and architects around here recently. ;)
In any case, since it's been a couple years since I did any parser work,
I've hacked out a flex/bison parser for a generic extensible xwin.rc format,
and gotten all the info stuffed into a reasonably simple structure, now
all I need to do is crawl the structure and do CreateMenu()/AddMenuItem()
accordingly and LoadIcon(), and when creating windows compare the class
name to the ones in the prefs structure and possibly replace icon and/or
add to the system menu of that window.
I'm attaching a tar.bz2 below, give it a look-see whoever's interested
in the whole customizable menus thing, and if you want to integrate the
prefs structure parser let me know. The file format's simple and
explained in the input.rc, and has support for pretty much all that
XWin.exe can do now as far as customizations. [ Sure, you could add
an ALPHA {} block that would change the alpha-blend of windows under
Win2K and XP, but I'm not sure how really useful that would be. Maybe
a PaletteWindow style, though, for xload or xcalc... ]
For me the most interesting part was getting back up to speed on lex/yacc,
the implementing in the server is reasonably plug-n-chug as my physics
prof used to say.
Harold, if this is something you don't like for XWin just let me know...
-Earle F. Philhower, III
[EMAIL PROTECTED]
cdrlabel - ZipLabel - FlpLabel
http://www.cdrlabel.com
prefsparser.tar.bz2
Description: Binary data
Another patch: Stop random GPFs on exit
Howdy Harold, it looks like you're really busy with the 4.3 updates, but here's another small patch for XWin that gets rid of the GPFs that sometimes happen when exiting the server w/-clipboard or -mwm. Basically, the X server was closing connections to the threads who were then attempting to re-open them and restart their main loops. This is fine for a server reset, but for a server kill you don't want to re-open the connections because the info you've got (things like ScreenPtrs etc.) aren't valid anymore. This patch just adds a notify call to the two threads which sets a flag so that when they do a longjmp() back to their main loops on an IO error they pthread_exit() and not attempt to re-access their passed in parameters/etc. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com nogpfexit.diffs.bz2 Description: Binary data
PATCH: Constrained sizing support in -multiwindow mode
The multiwindow manager does presently not respect the hints that apps like xterm or emacs give as to valid window sizes. This can cause xterm to have ugly leftover smudges on the right edge of the window and other minor little annoyances. The attached DIFF -U3 patch against test93 adds support to automatically validate the sizes of windows while you're sizing them, just like you find in most X11 window managers. I've tested it locally and it seems to work just fine under W2K, but I'd like to confirm that it performs properly under XP where the window decorations (which it needs to take into account) are different... -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com constrainsize.diff.bz2 Description: BZip2 compressed data
Re: [ANNOUNCEMENT] Server Test 92
Hi Peter... -- Peter Colovas wrote - Subject: Re: [ANNOUNCEMENT] Server Test 92 It may be benign since I'm trying to kill the server anyway, but it also points to a memory leak or some other error which is causing the GPF. xwinclip also fails at other times, although I haven't been running 92 long enough to see if it happens. It would be interesting if someone with access to Purify or another memory profiling tool could compile XWin and see what happens. Purify's a bit out of my price range, but IMHO this is not a real memory leak/etc. issue. Since it only happens during shutdown of the server, and isn't repeatable at that, I believe this is more of a freeing() in the main app cause by the shutdown of the X server (it frees all ScreenPtrs, for example) without killing the extra worker threads (xwinclip, mwmgr) who have local copies of some of these pointers. Sometimes the thread gets activated before the process completely terminates - and the GPF happens, and sometimes it doesn't get activated and the shutdown happens normally. However, if someone did have Purify, you're 100% right that it would be an interesting run in any case! -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: [XWin test-92] no trayexit
Howdy Harold, here's that patch: --- xwin.test92/wintrayicon.c 2003-06-02 06:14:26.0 -0700 +++ xwin/wintrayicon.c 2003-07-30 13:09:06.0 -0700 @@ -176,7 +176,7 @@ /* Remove separator */ RemoveMenu (hmenuTray, - 1, + 0, MF_BYPOSITION); } -- Original Message - Subject: Re: [XWin test-92] no trayexit Date: Wed, 30 Jul 2003 14:47:03 -0400 From: Harold L Hunt II [EMAIL PROTECTED] To: [EMAIL PROTECTED] Huh. Interesting. There was a debate some time ago as to whether the Exit button should be on the bottom or top of that menu. My local tree got changed, but the change appears to have been incomplete because the code that hides and unhides buttons seems to be unchanged. That code operates on button positions, not button names, so it has to be updated whenever buttons are moved. This should be easy to fix, but I would, of course, appreciate it if someone got to it before I did and had a patch waiting for me when I get home tonight... Harold Thomas L Roche wrote: daniel.blueman Wed, 30 Jul 2003 13:04:19 +0200 (MEST) Unfortunately, the system tray icon menu (ie not when you double-click, but when you single right click) has no entries - so no 'exit' option like previously. I also observed this: the only content of the context menu was a separator (disabled, IIRC). -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: [XWin test-92] no trayexit
Howdy Harold, Test93 runs fine w/the menu, it's not as if there was a lot of changes involved! ;) At 07:48 PM 7/30/2003 -0400, you wrote: Earle, Thanks. Check out Test93... please make sure that the patch fixed the problem. Thanks for contributing, Harold Earle F. Philhower, III wrote: Howdy Harold, here's that patch: --- xwin.test92/wintrayicon.c 2003-06-02 06:14:26.0 -0700 +++ xwin/wintrayicon.c 2003-07-30 13:09:06.0 -0700 @@ -176,7 +176,7 @@ /* Remove separator */ RemoveMenu (hmenuTray, - 1, + 0, MF_BYPOSITION); } -- Original Message - Subject: Re: [XWin test-92] no trayexit Date: Wed, 30 Jul 2003 14:47:03 -0400 From: Harold L Hunt II [EMAIL PROTECTED] To: [EMAIL PROTECTED] Huh. Interesting. There was a debate some time ago as to whether the Exit button should be on the bottom or top of that menu. My local tree got changed, but the change appears to have been incomplete because the code that hides and unhides buttons seems to be unchanged. That code operates on button positions, not button names, so it has to be updated whenever buttons are moved. This should be easy to fix, but I would, of course, appreciate it if someone got to it before I did and had a patch waiting for me when I get home tonight... Harold Thomas L Roche wrote: daniel.blueman Wed, 30 Jul 2003 13:04:19 +0200 (MEST) Unfortunately, the system tray icon menu (ie not when you double-click, but when you single right click) has no entries - so no 'exit' option like previously. I also observed this: the only content of the context menu was a separator (disabled, IIRC). -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: [ANNOUNCEMENT] Server Test 92
Howdy... At 04:13 PM 7/29/2003 -0500, Peter Colovas wrote: I'm running Win2k SP4. I have a problem with winclip exceptions. If I close down the X session when I have multiple remote terminals open, I almost always get an exception in xwinclip. It is still happening with Test92. I run XWin -multiwindow -clipboard. I get the same xwinclip error at home on win98, but I haven'y upgraded to this server test version yet. Do you mean that you get this when you are trying to kill the server from the notification icon? I too see that occasionally, but haven't taken the time to run under GDB and see why the xwinclip thread is GPFing during server shutdown. In any case it's benign since you're killing the app anyway, right? -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Build failure on current CVS
/lib/X11' -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: Build failure on current CVS
Howdy Harold, At 06:58 PM 7/24/2003 -0400, you wrote: I am building the CVS tree from anoncvs.xfree86.org, not the branch that we have on sourceforge. The errors certainly look like they could be caused by some messing around to get IP V6 working... maybe we should just wait for it to settle down. Shouldn't they be #ifdef'ing all things like this? I'm sure cygwin is not the only xfree86 architecture that doesn't have IPV6 headers... Also, just to make sure, if I wanted to start doing some hacks on the XWin server I should still be using the xoncygwin cvs, right? -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: rdesktop.exe session on an X-terminal?
Howdy Michael, -- Original Message - Subject: Re: rdesktop.exe session on an X-terminal? 'rdesktop.exe' doesn't honor a command-line display argument and setting Windows and Cygwin environment variables 'display' and 'DISPLAY' has no effect. --- I can confirm that the rdesktop 1.2.0 that I downloaded and compiled under Solaris displays fine under XWin -multiwindow -multiplescreens, for connections to both terminal servers and my WinXP laptop. I just set the $DISPLAY properly in the xterm and rdesktop server... Under Windoze there's no need for rdesktop, you can use the free Remote Desktop Connection utility from MS (supported under Win 98, 2000, and built-in underXP). The MS version is also faster and supports 16-bit displays which is almost a necessity for XP remotes, with all their eye-candy. -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: rdesktop.exe session on an X-terminal?
Howdy Michael, -- Original Message - Subject: Re: rdesktop.exe session on an X-terminal? Thanks for your reply. Yes, rdesktop on Unix works well for us too but we need to build a standalone Win2k-serving-Xterminals-with- Windows-Desktop-sessions solution. Other than Citrix, rdesktop seems to be the only alternative?? I think you've misunderstood what rdesktop can do. If you want to share multiple Windows desktops from one machine, then you need something like Citrix. rdesktop is a client that just talks to a Citrix server, it's not a server per-se. If you just need 1 PC to 1 user, then you can get an XP Pro license and dedicated PC, the remote desktop server is built into it... Even if rdesktop has some server type mode, it wouldn't let you share Windoze desktops: XWin.exe only knows about X windows that it creates, and doesn't send events or examine non X windows... -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: Custom icons + MouseUp fix
Howdy Colin! At 08:14 PM 6/17/2003 +0100, you wrote: I been looking into replacing the mouse timers in multiwindow mode. One interesting quick-fix, to improve out-of xwindow mouse responsiveness to reduce 'transition pointer artefacts' on leaving xwindows, is to reduce the value of MOUSE_POLLING_INTERVAL from 500 to 10ms! Tried this with load of xterms and xeyes open and it works for me (XP on a 500MHz Pentium III). That's something I tweaked too, but it didn't really seem to do much for me, probably since most of my jobs were remote (WM_TIMER is only given if there's nothing else for Windoze to do IIRC). Are you looking at the hook DLL? I've been swamped with other things so haven't done more than look at the sample code Harold did for that Morse beeper. One other minor thing I think might be simple to do is replace the SW diX cursor with the standard Windoze cursor: All the Xbitmap-WinIcon code can be used almost directly, and this'll reduce CPU load when moving the mouse over an active window. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Mozilla vis-à-vis Cygwin
Howdy Michael, At 11:24 AM 6/17/2003 -0700, you wrote: Anyway.. I guess what I expected from my May 10th FYI was at least a private email or two from people who would be interested on working such a project. From now on I will try to be more clear. Like Ken Thompson said, that's just they way open source has always worked. If it's important to you, then why not start hacking away at it instead of waiting for others? Once you start posting patches and bug reports to the Mozilla team's website or here if it's cygwin xfree86 related, I'm sure you'll get more input and support. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Xterm doesn't work on second display in dual head system
Howdy Stefan, -- Original Message - Subject: Xterm doesn't work on second display in dual head system yet another problem: I use a dual head display based on a Matrox G400DH card in a Win2K system. When starting Xfree86/cygwin it opens an xterm window that works while it is on the main display. But when I drag it into the second display it doesn't accept keystrokes anymore. They get buffered, though: They appear when I drag the window back into the primary display. Is that a bug or have I misconfigured anything? -- Let me guess, the 2nd monitor is to the left of your primary display, right? The old version of the XWin.exe server didn't support multihead displays with negative origins, but the latest test releases have had this bug fixed for a month or two. Check the announcement for Test91, the last test release IIRC, to get a newer exe: http://www.cygwin.com/ml/cygwin-xfree/2003-06/msg00044.html -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: Generic rootless/multiwindow mode in XFree86 CVS [Fwd: Re: CVS Update: xc (branch: trunk)]
, you can save memory because you don't need to keep a copy of the framebuffer in memory. You can instead just draw directly into the backing store provided by the underlying window server. You can also do things like window moves much more quickly by just telling the underlying window server to move this frame rather then re-rendering everything to the framebuffer with the X window in the new position and copying it all back onto the screen. I hope my explanation makes some sense. As I said, I plan to write more docs later, so let me know if you have any questions so I'll address them. If MS Windows provides backing store for its on screen windows, you will probably find the generic rootless code allows you to provide a lot of slick features very easily. If you look at Xserver/hw/darwin/quartz/cr you can see how small a typical implementation can be. --Torrey -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: xwinclip patch
Howdy Harold, you took the words right out of my mouth (well, maybe they were a bit kinder than I'd have been!): Subject: Re: xwinclip patch ... Not all applications used the CLIPBOARD atom... a lot of them still only use XA_PRIMARY. Dropping support for XA_PRIMARY is a HUGE reduction in the feature set of xwinclip and it will not be accepted by users. XA_PRIMARY is what's used by the two largest apps used under X (according to the Unix Hater's Guide): emacs and xterm. I think you'd have a line of people knocking on your door to yell at you if you were even to think about removing the select = paste flow from these apps, or the even worse option of having to select then move the mouse to the taskbar and select some option from a popup menu to paste things. -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
RE: Problem with releases since -37
Howdy Andy.. At 02:37 PM 6/4/2003 -0400, you wrote: I did some more testing based on your suggestions. I first tried the XWin-Test91-DEBUG version of the server with the released version of the dll. That failed as before and gave me a new stackdump. I then put in cygwin1-20030602.dll as /bin/cygwin1.dll. I restarted windows to make sure that the correct dll was used. I ran with the XWin-Test91-DEBUG version of the server again and it gave me Microsoft's do you want to report this box again, but did not produce a stack dump. I tried the 042 version again, and got the same results (do you want to report this and no stackdump). Putting the last working version (037) back in with the new dll works fine. Anyone have any other ideas that I can try? Since nobody seems able to reproduce your failure, you might try debugging it, at least to the point of failure, yourself. You should be able to recompile the XWin.exe in debug mode and start it up in in gdb, and when the crash occurs you should get an annotated function trace with add'l debug info... I think the -DEBUG version is just one with Ralf's new parameter checks, not really a debug version, so you'll really have to recompile with the -g option... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Possible X-Wndows problem
Howdy... At 01:39 AM 6/4/2003 -0700, you wrote: I had Cygwin crash on me the other day and was wondering if this is my machine doing this (like it ran out of memory or some such) or if it was a known problem with Cygwin. I wrote a small program which opened a 400x400 pixel screen and then proceeded to write to each pixel varying colors. The program worked at first but after allowing the program to run several hours while it randomly wrote colors to the dots (in the proper range of course), Cygwin crashed and died leaving the system in an unstable state (ie: I had to reboot my Windows box). Are you running a W98 based OS, or were you able to kill W2K/NT/XP with this? That sounds more like a driver issue if it's the latter. Also, do you have a check as to the number of GDI handles, etc., and how they increase with time? I think there are some leaks still there but haven't run into any problems under W2k. W95 based OSes do have more limitations, though, and will crash where NT OSes will continue running. (To see GDI handles/etc bring up taskmgr, select View-Select Columns, and check GDI objects, Handle Count, USER objects, and memory usage...) If you do see one of those numbers increasing without stop then maybe just posting your source code would be useful. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
RE: [ANNOUNCEMENT] Server Test 91
Hi Ralf, let me just say thanks for doing all the boring work of parameter checking and NULL malloc fixes. Hacking code's fun, making it bulletproof is just work... At 08:02 PM 6/4/2003 +0200, you wrote: 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) -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: taskbar and system tray menus
Hi Colin and Harold. It seems like there is a storm of nit-picking this week, must be something in the air. Anyhoo... -- Original Message - Subject: Re: taskbar and system tray menus .. 'Exit' to bottom on tray and 'Always On Top' to top on sys menu (better I think than the transpose with 'Close') So 'Exit' and 'Close' are now at bottom of respective menus. -- My nit is this placing the custom items before the system items in the title menu is against all other Windoze UIs I've ever seen: nobody adds things to the top of the popup menu. Check for yourself, right-click on a CMD shell or cygwin shell, you see the Edit/Defaults/Props menu items after the Windoze standard ones. Right-click on an IE mini-icon in the title bar, you get Close followed by Make available offline. Or a regular explorer window, you get Close followed by all the other items... -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: [ANNOUNCEMENT] Server Test 91
Hi Harold, One more thing about your new server test release where you broke things up into smaller files and reworked the message loops: It looks like the mouse button fix (where you release the mouse outside of a window and X doesn't get notification so Xterm keeps scrolling or emacs keeps selecting) got lost. Was this on purpose, or just an oversight I should make a new patch for? -- Original Message - Subject: [ANNOUNCEMENT] Server Test 91 .. -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: taskbar and system tray menus
At 05:49 PM 6/2/2003 -0400, Christopher Faylor wrote: On Mon, Jun 02, 2003 at 09:38:55PM -, Earle F. Philhower, III wrote: It seems like there is a storm of nit-picking this week, must be something in the air. Anyhoo... That's usually a sign that a project is approaching stability and maturity and users are turning to other things. It seems like the flood of spelling corrections that historically hits the linux kernel list when the kernel is close to being released. If only that was the case! :) I think there is still mucho trabajo a hacer, especially in the Window Manager part of the multiwin setup. Everyone seems to want it to do something different, and IMHO you can either a) hack the code to make nobody happy (person X says 'oh, I want it to do A' and person Y says 'oh, if it does A then it's junk!'), or b) put in real configuration files just like FVWM where you have a ~/.xwinrc with lines like AlwaysOnTop = FALSE and ContextMenu=[xterm on XXX, xterm on YYY, ...] and xterm.*.icon=bigicon.png,littleicon.png Plus, there's the work Harold's doing on the windows message hooks which might be a really big change. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Multiwindow request
Hola all, At 04:12 PM 6/2/2003 -0400, you wrote: ...Perhaps a separate X client that runs in multiwindow mode and provides the root menu functionality might be a better idea... It could modify the standard Windows root menu by adding a submenu, which it would then have complete control over... Instead of this, why not just use the Windoze desktop that's already there? You can start a remote xterm by creating a new shortcut on your desktop and making the command rexec host /usr/X11R6/bin/xterm -display mymachine:0.0. You could do a shell extension, but I'm not sure how you'd go about compiling it w/o MinGW or MSVC, and even then it's probably not trivial to append to the standard desktop menu under different OSes (95 w/o the IE4 pack probably doesn't even support that, and it's most likely a different IF between 98 and NT in keeping with MS tradition...) -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: [ANNOUNCEMENT] Server Test 91
Howdy, At 09:32 PM 6/2/2003 -0400, you wrote: I didn't commit that because I was not convinced that it was entirely proper. I also forgot about it :) I would really like to implement hooks instead of adding more and more timers (it was a timer, correct?). It wasn't a new timer, it was just doing one more thing in the one that's already there (the present timer feeds fake mouse moves, the change just added in fake mouse ups in the same timer). -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: [ANNOUNCEMENT] Server Test 91
Hola, At 09:43 PM 6/2/2003 -0400, you wrote: I think the thing I didn't like about it was the fact that a few keys were also being released and that wasn't explained very well. What is up with that? ?? That's actually the WM_KILLFOCUS call that releases the keys. I think you've still got that in (and even if it's not 100% correct it seems to work wonders!)... There was a GeyVKey(LBUTTON), but that was just to read the mouse buttons from Windoze, if that's what you were thinking of. Harold Earle F. Philhower III wrote: Howdy, At 09:32 PM 6/2/2003 -0400, you wrote: I didn't commit that because I was not convinced that it was entirely proper. I also forgot about it :) I would really like to implement hooks instead of adding more and more timers (it was a timer, correct?). It wasn't a new timer, it was just doing one more thing in the one that's already there (the present timer feeds fake mouse moves, the change just added in fake mouse ups in the same timer). -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Multiwindow request
Howdy Igor... At 11:05 PM 6/2/2003 -0400, you wrote: Umm, Earle, you didn't quote the complete message. The shortcut is almost what I was suggesting in the first part of it (quoted below): At 04:12 PM 6/2/2003 -0400, I wrote: IMO, the ability to start clients is the function of the window manager. I know fvwm provides such, and so do KDE and CDE. In multiwindow mode, the window manager is native windows (Explorer?), which has its own start menu and its own desktop management, so those are the tools that should be used to start new clients. The only way in which the Explorer WM is different from the traditional WMs (like fvwm, etc) is that it's not aware of the DISPLAY value (which may or may not be a problem). ^ The reason I wrote the second part (which you did quote) was that the Explorer context menu would not know the value of DISPLAY to set for the X clients it would start... An X client would, of course, know it. BTW, that value is not necessarily mymachine:0.0... IIRC, Cygwin already requires some version of IE to be installed on 95 to function correctly (it may even be IE4, have to check the code). Sorry, I didn't mean to misquote you. But your local host and display # is always the same, no? Especially under Windoze where your desktop doesn't follow you like a SunRay or just a plain XDCMP session? My work machine is always xx.yy.zz:0.0, and my home is always bigearle:0.0. If you use -display in the xterm command line, it imports that environment variable into its shell so clients started from that xterm automatically pick the correct display. In fact, a shortcut like that's what I have in my work setup, and that's what commercial apps like eXceed do (of course, eXceed 8.0 also hangs more often than XWin but that's what you're paying the $$$ for 8P)... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: [ANNOUNCEMENT] Server Test 88
Howdy Lev, thanks for the info! At 09:42 AM 6/1/2003 -0400, you wrote: I think I can tell you what you need to do to allow small and large icons specified seperately. First, you need your window to be WNDCLASSEX not WNDCLASS. This gives you the hIcon element as before, which is to be of system large size, and in addition gives you an element hIconSm, which is of system small size. Now of course you need to know what system large, system small sizes are (the current code seems to assume system large is 32x32). You can get this using GetSystemMetrics with parameters SM_CXICON, SMCYICON for the system large and SM_CXSMICON, SMCYSMICON for system small. The system large size is determined by the video driver and cannot be changed any other way, the system small size is controlled by the caption buttons size setting in the display properties applet, appearance tab. Yup, that's listed (GCL_HICONSM) right next to the GWL_ value we presently use, I just never saw it! I did a quickie experiment and added bilinear filtering on the BW icon format only. Results: xcalc still looks like garbage even @32x32: instead of a black mismash, it's a gray one. There is just no good way of making some older icons look good, and newer apps use colored icons so there isn't quite so big a subsampling problem. IMHO, while you could add filtering and 16x16 icon creation to the present code, it wouldn't be worth the effort. Try it for yourself, use twm and take a snapshot of the big ol' xcalc icon, and then use your favorite image app to shrink it to 32x32 and I think you'll be disappointed no matter how you slice it. You also pointed out a possible problem, instead of using the system supplied X/Y of an icon we've got 32x32 hard coded. It seems that this assumption is correct on all Windoze versions so far, but it might be a bit more proper to replace the iconSize=32; to iconSize=GetSystemMetrics(SM_CXICON);. It could also be changed to have non-square icons, in fact it was originally written to support them but I ended up just overriding the Y scale with the X scale. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: [ANNOUNCEMENT] Server Test 88
Howdy Harold, It looks like the XWin.rc you were working on got put into this version causing the icon munging in the exit dialog. The code I sent works only the older version w/o the dlgframe style. --- xwin_88/XWin.rc 2003-05-28 20:51:51.0 -0700 +++ xwin/XWin.rc2003-05-31 09:46:09.0 -0700 @@ -53,8 +53,7 @@ /* Exit */ EXIT_DIALOG DIALOG DISCARDABLE 32, 32, 180, 70 -STYLE WS_POPUP | WS_CAPTION | WS_SYSMENU | WS_VISIBLE | WS_TABSTOP | DS_CENTER| WS_DLGFRAME -EXSTYLE WS_EX_DLGMODALFRAME +STYLE WS_POPUP | WS_CAPTION | WS_SYSMENU | WS_VISIBLE | WS_TABSTOP | DS_CENTER FONT 8, MS Sans Serif CAPTION Cygwin/XFree86 - Exit? BEGIN 3) windialogs.c/winDisplay[Exit|DepthChange]Dialog() - Add calls to drop the minimize and maximize buttons from the Exit Confirmation and Depth Change dialog boxes, while preserving the icon on the upper left hand corner of the dialog window. (Earle F. Philhower III) -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: [ANNOUNCEMENT] Server Test 88
on-the-fly one! -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Icons [in Server Test 87]
Howdy Lev, Colin, At 09:16 AM 5/30/2003 +0100, you wrote: This one crept passed quality control :). I can confirm your problem at 32 bit colour with xclock etc. OK at 24 bit and 16 bit (1280x1024) on my machine. Out with the magnifying glass again! Colin, you ran a 32bpp test and attached a screen capture, no? I cannot reproduce anything like what you two are seeing, I run at 32bpp all the time. It could be something to do with the device driver/HW involved as I only have access to my GF2GTS and my 4 screens of Voodoo 3000. What GFX cards are you folks running? You might have to do some debugging on your own HW to narrow this down... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
