Re: Changes to multiwindow mode and always-on-top (ping Takuma)
Earle, 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? 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. 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. 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)... In recent changes I made winRestackWindowMultiWindow empty 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). Due to the changes propagation of Z order changes between X and Windows were not correctly performed; that's the restacking bug I've mentioned. Takuma Murakami noaot.patch Description: Binary data
Re: Emacs menus act strangely
Earle F. Philhower, III wrote: 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... 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. The messages are not in the archive but I found an older which was sent without realname (just [EMAIL PROTECTED]). This seemed to be ok. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
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
US keyboard not working with recent XFree86-xserv
Greetings, I was interested in picking up the multi-window fix in XFree86-xserv-4.3.0-59 so I recently reinstalled cygwin on my Windows XP machine. However, after the reinstall I'm unable to type into an xterm. I start Xwin.exe using the startxwin.bat script. The Xwin.exe process starts and launches an xterm. I'm unable to type into this xterm session. The xterm session recognizes mouse actions, but not keyboard actions. Does anybody have any ideas what might be causing this. I've included a copy of the Xwin.log file. Thanks. Troy Runkel [EMAIL PROTECTED] - Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.59 Contact: [EMAIL PROTECTED] XWin was started with the following command line: XWin -multiwindow -clipboard ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1280 h 1024 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 winScreenInit - dwWidth: 1280 dwHeight: 1024 winSetEngine - Multi Window = ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 16 bits per pixel winCreateBoundingWindowWindowed - User w: 1280 h: 1024 winCreateBoundingWindowWindowed - Current w: 1280 h: 1024 winAdjustForAutoHide - Original WorkArea: 0 0 994 1280 winAdjustForAutoHide - Adjusted WorkArea: 0 0 994 1280 winCreateBoundingWindowWindowed - WindowClient w 1280 h 994 r 1280 l 0 b 994 t 0 winCreateBoundingWindowWindowed - Returning winAllocateFBShadowGDI - Creating DIB with width: 1280 height: 994 depth: 16 winAllocateFBShadowGDI - Dibsection width: 1280 height: 994 depth: 16 size image: 2544640 winAllocateFBShadowGDI - Created shadow stride: 1280 winFinishScreenInitFB - Masks: f800 07e0 001f winInitVisualsShadowGDI - Masks f800 07e0 001f BPRGB 6 d 16 bpp 16 winCreateDefColormap - Deferring to fbCreateDefColormap () null screen fn ReparentWindow null screen fn RestackWindow winFinishScreenInitFB - Calling winInitWM. InitQueue - Calling pthread_mutex_init InitQueue - pthread_mutex_init returned InitQueue - Calling pthread_cond_init InitQueue - pthread_cond_init returned winInitMultiWindowWM - Hello winInitMultiWindowWM - Calling pthread_mutex_lock () winInitWM - Returning. winFinishScreenInitFB - returning winMultiWindowXMsgProc - Hello winScreenInit - returning winMultiWindowXMsgProc - Calling pthread_mutex_lock () InitOutput - Returning. MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: 0409 (0409) (EE) Keyboardlayout US (0409) is unknown Rules = xfree86 Model = pc101 Layout = us Variant = (null) Options = (null) Could not init font path element /usr/X11R6/lib/X11/fonts/Speedo/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/Type1/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/100dpi/, removing from list! winPointerWarpCursor - Discarding first warp: 640 497 winBlockHandler - Releasing pmServerStarted winBlockHandler - pthread_mutex_unlock () returned winInitMultiWindowWM - pthread_mutex_lock () returned. winProcEstablishConnection - Hello winInitClipboard () winProcEstablishConnection - winInitClipboard returned. winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winInitMultiWindowWM - pthread_mutex_unlock () returned. winMultiWindowXMsgProc - pthread_mutex_lock () returned. winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0 winClipboardProc - DISPLAY=127.0.0.1:0.0 winMultiWindowXMsgProc - pthread_mutex_unlock () returned. winMultiWindowXMsgProc - DISPLAY=127.0.0.1:0.0 winClipboardProc - XOpenDisplay () returned and successfully opened the display. winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning. winDeinitMultiWindowWM - Noting shutdown in progress ddxBeforeReset - Hello winClipboardProc - winClipboardFlushWindowsMessageQueue trapped WM_QUIT message, exiting main loop. ddxBeforeReset - Clipboard thread has exited. winDeinitMultiWindowWM - Noting shutdown in progress
Re: US keyboard not working with recent XFree86-xserv
You need this: http://cygwin.com/ml/cygwin-xfree-announce/2004-03/msg00032.html Harold Troy Runkel wrote: Greetings, I was interested in picking up the multi-window fix in XFree86-xserv-4.3.0-59 so I recently reinstalled cygwin on my Windows XP machine. However, after the reinstall I'm unable to type into an xterm. I start Xwin.exe using the startxwin.bat script. The Xwin.exe process starts and launches an xterm. I'm unable to type into this xterm session. The xterm session recognizes mouse actions, but not keyboard actions. Does anybody have any ideas what might be causing this. I've included a copy of the Xwin.log file. Thanks.
Hydravision problem?
Hi, Thanks for your response. I should have been more explicit. Here is what I have used: REM Startup the X Server with the integrated Windows-based window manager. start XWin -multiwindow -multiplemonitors -clipboard REM Startup an xterm, using bash as the shell. run xterm -sl 1000 -sb -rightbar -ms red -fg yellow -bg black -e /usr/bin/bash I have also tried it with the -screen 0 -screen 1 options, and with just the screen options. -multiplemonitors seems to work best but I still have problems. The xterm window is partially blanked out with white. When I drag the window it flashes on both screens completely whiting out the xterm window. When I drop it, the xterm is just where it should be but the xterm window is still at least partially blanked out with white. Any ideas? Thanks for your help. Pete Peter, I am trying to run cywin X on an IBM T41p laptop with an extra display connected. IBM uses ATI and Hydravision for their laptops. The dual display seems to work fine in windows mode. The external display is an WXGA (1280x768) although the ati card will only support 1024x768. The main lcd display of the note book is 1400x1050. So I am trying to run X in multiwindow mode. I have tried it with and without -screen 0 -screen1 options. In all cases the xterm seems to want to be in both displays kinda flashing around on both. Any ideas, or known problems? Please try to use -multimonitors option. Takuma Murakami
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)
Earle, Earle F. Philhower III wrote: 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...) I haven't gotten a chance to test Takuma's new patch yet, so I was wondering if you have checked what happens when you open two xterms, place a Cygwin bash shell inbetween them in the Z order partially overlapping with both of them, then minimize one xterm and then the Cygwin bash shell... you'll have to play with the ordering a little bit, but see if you can get it to have one xterm showing the contents of the other xterm where they were previously overlapping. That was a bug that we have had before and Takuma's changes from last week re-introduced that bug. I'm not sure if his new patch was an attempt to fix that or not... but this is something that somebody will need to fix and I'd appreciate it if you had some insight if this is not already fixed. 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! Glad to know that you guys are looking at this in depth. :) Harold
auto-import failure for new libXt
I guess this is just a heads up since I don't have time to debug it right now, but with the latest XFree packages, I get a stream of error messages like the following when linking our apps: /home/ford/v9winsym/util/Failure_report/../../../vissym/util/Failure_report/failure_report.c:104: variable '_XtStrings' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details. failure_report.o(.text+0x203f): In function `main': This used to work, all be it with similar warnings. Is it time to make a pass through the X headers, adding the proper export tags? Ugh... -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444
how to use dll created by cygwin in MS Visual C++?
I follow cygwin's user guide,create a dll as following:
//
// this the dll file :@test_dll.c
//created by songyewen 2004/03/21
//
#include stdio.h
int show_hello()
{
printf(this is the testing string from cygwin apps's dll file\n);
return 0;
}
//--
gcc -c test_dll.c
gcc -shared -o test_dll.dll test_dll.o
so I get the test_dll.dll
//--
//
//this file is a demo for testing dll in cygwin apps
[EMAIL PROTECTED]
//created by songyewen 2004/03/21
//
#include stdio.h
int main()
{
show_hello();
}
//-
gcc -o test_main.c test_main.exe -L./ -ltest_dll
so I get test_main.exe and can run test_main.exe successfully!
But I failed to use the test_dll.dll in MS Visual C++?
Who can help me?
thanks in advance!!
windowed mode seemingly unavailable
I am currently unable to determine how to open a single x-server window (with multiple x-terms inside), as opposed to the multiple window mode. I would like to operate inside the single window for performance reasons, and have done so in the past on a similar Win XP install with Cygwin/X. My understanding is that the window behavior that I am describing is the default: http://xfree86.cygwin.com/docs/ug/configure-cygwin-xfree-options.html The command I use to launch multiple-window mode is xwin -multiwindow. The command I have used successfully on a separate installation to launch single window mode is simply startx. However, on this computer, it appears to simply bring up an xterm (black window with x icon in upper left corner and yellow scrollbar) rather than the server window (white background with x icon in upper left corner and green scrollbars, not sure on exact terminology). With both systems, the only customization steps that I have performed (to my best recollection) are adding the xfree86-base and openssh packages. This is so that I can open remote apps. If anyone can point me in the right path, it would be very gratefully appreciated. I have spent several hours searching myself with google and in the list archives with very little useful information turned up. _ Get tax tips, tools and access to IRS forms all in one place at MSN Money! http://moneycentral.msn.com/tax/home.asp
