Re: Define a foreign language keyboard in HP-Ux CDE?
Hans, The latest XWin includes the keyboard auto-detection. Without any XF86Config files or xmodmap mappings it loads a default es layout for you. It may be good to disable CDE (and any other) keyboard setting and let XWin do the work entirely. Takuma Murakami ([EMAIL PROTECTED])
Re: No extern "C" for XFree86 OpenGL headers
This is out of the blue. Could you give a little more context to what
you are trying to do?
Harold
Tron Thomas wrote:
The XFree86 versions of the OpenGL headers files do not use extern "C"
when compiling C++ modules. This can result in linking errors as OpenGL
function receive decorated signatures that won't exist in the libraries.
A work around is for a developer to do something like the following in a
C++ code module:
#ifdef __cplusplus
extern "C" {
#include
}
#endif
which shouldn't normally be necessary as other implementations of OpenGL
do not require this.
No extern "C" for XFree86 OpenGL headers
The XFree86 versions of the OpenGL headers files do not use extern "C"
when compiling C++ modules. This can result in linking errors as OpenGL
function receive decorated signatures that won't exist in the libraries.
A work around is for a developer to do something like the following in a
C++ code module:
#ifdef __cplusplus
extern "C" {
#include
}
#endif
which shouldn't normally be necessary as other implementations of OpenGL
do not require this.
Re: Patch for keyboard handling
Takuma, Takuma Murakami wrote: I agree with you. If the mi event queue has pending events when winRestoreModeKeyStates is called, it may fail to synchronize mode key states between XWin and Windows. However, the new code can re-sync them at the next time winRestoreModeKeyStates is called while it is hard to do for the old code. Okay. Thank you for your suggestion. mieqProcessInputEvents seems to do the work. I inserted a code to call it and it looks working well for now, though I don't sure if it is legal to call it from the place other than ProcessInputEvents. The attached is a revised patch to call the function. I deeply appreciate your feedback. Looks good, but I think you are right about some danger in calling mieqProcessInputEvents. Hmm... the problem with calling ProcessInputEvents or mieqProcessInputEvents from our keyboard processing is that it causes input events to be processed one at a time, instead of in a queue. It completely negates the purpose of having an input queue in the X layer. I think I understand your original patch better now and I think that you were probably doing it correctly, but I can't verify that right now. If this is what you were trying to do, then it probably is correct: 1) Assume that no keyboard input is in the mi queue when winWindowProc is called. 2) If we are getting the keyboard focus, grab the Windows mode key state and X mode key state, compare them, and send fake key presses to X to get the two states in synch. 3) Do not synch the key states anywhere else. That would probably work because it would enqueue key messages that will synch the mode key states before placing normal key messages in the queue. Thus, when we ask X for the mode key states we should get a consistent result since the input queue in X is empty. Does that sound like what you were trying to do initially? I got confused because I couldn't keep track of where all the calls to winRestoreModeKeyStates would up. Let me know, Harold
Re: Default Mouse Pointer is Wrong
Cary Jamison wrote: "Ricky Boone" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... On Wed, 2003-11-05 at 09:37, Yadin Y. Goldschmidt wrote: Colin Harrison suggested long time ago to add the following line to the end of your startxwin.bat file: xsetroot -cursor_name left_ptr -fg white -bg black This will change the default mouse from an x to a white arrow. Ah ha, that did the trick. My apologies, I didn't even notice the suggestion when I searched for it. -.-;; Thanks for the help. :) I've noticed this too, but haven't complained about it. I didn't realize the problem was specific to the -multiwindow window manager. This isn't a problem. It is "the way it works". If this is true, than -multiwindow is not behaving as expected nor as other window managers behave wrt default cursors. The xsetroot is a work-around, but it seems to me this should be regarded as a bug in the window manager. The 'X' should be the default cursor when over the root window but an arrow when over an application window. Since -multiwindow doesn't really have a visible root window, it seems like permanently changing the default cursor to a pointer would be a good/quick solution. Fine. Run 'twm' as your window manager. Doesn't it do the same exact thing? That is the way that I have been reading the emails... if that is not the case, then could somebody please describe this better.? The solution you propose is not trivial. That is why this is "the way it works" and not a bug. I'm sure that upon further inspection you would figure out that trying to change this policy would result in the creation of a mouse-cursor over-riding policy that is a lot more complicated than what you think it would be. I'm pretty sure that it would be complicated enough that it isn't worth looking into. Of course, feel free to code me into submission. Harold
Re: Default Mouse Pointer is Wrong
"Ricky Boone" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > On Wed, 2003-11-05 at 09:37, Yadin Y. Goldschmidt wrote: > > Colin Harrison suggested long time ago to add the following line to the end > > of your startxwin.bat file: > > xsetroot -cursor_name left_ptr -fg white -bg black > > This will change the default mouse from an x to a white arrow. > > Ah ha, that did the trick. My apologies, I didn't even notice the > suggestion when I searched for it. -.-;; > > Thanks for the help. :) I've noticed this too, but haven't complained about it. I didn't realize the problem was specific to the -multiwindow window manager. If this is true, than -multiwindow is not behaving as expected nor as other window managers behave wrt default cursors. The xsetroot is a work-around, but it seems to me this should be regarded as a bug in the window manager. The 'X' should be the default cursor when over the root window but an arrow when over an application window. Since -multiwindow doesn't really have a visible root window, it seems like permanently changing the default cursor to a pointer would be a good/quick solution. My $.02 Cary
XFree4.3.0 multiwindow mode intermittently fails on ME
Hello, After a clean install of 4.3.0 I have a problem
where XWin multiwindow mode fails to allow connections
to the Xserver. (There is no problem running with the
"startx" method). I can ping localhost. Intermittently
"startxwin.sh" will start its xterm.
The server allways starts and the "X" icon appears on
the ME task bar, however if I try to start x clients I
get "Can't open display". Moving the mouse over the "X"
on the task bar removes the icon. However, XWin is still
listed as running in the process table.
XWin.log from a FAILED session:-
ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1024 h 768
winInitializeDefaultScreens - Returning
OsVendorInit - Creating bogus screen 0
(EE) Unable to locate/open config file
InitOutput - Error reading config file
winDetectSupportedEngines - Windows 95/98/Me
winDetectSupportedEngines - DirectDraw installed
winDetectSupportedEngines - DirectDraw4 installed
winDetectSupportedEngines - Returning, supported engines 0017
InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
winSetEngine - Multi Window => ShadowGDI
winAdjustVideoModeShadowGDI - Using Windows display depth of 16 bits per pixel
winCreateBoundingWindowWindowed - User w: 1024 h: 768
winCreateBoundingWindowWindowed - Current w: 1024 h: 768
winAdjustForAutoHide - Original WorkArea: 0 0 768 1022
winAdjustForAutoHide - Taskbar is auto hide
winAdjustForAutoHide - Found BOTTOM auto-hide taskbar
winAdjustForAutoHide - Found RIGHT auto-hide taskbar
winAdjustForAutoHide - Adjusted WorkArea: 0 0 767 1021
winCreateBoundingWindowWindowed - WindowClient w 1021 h 767 r 1021 l 0 b 767 t 0
winCreateBoundingWindowWindowed - Returning
winAllocateFBShadowGDI - Creating DIB with width: 1021 height: 767 depth: 16
winAllocateFBShadowGDI - Dibsection width: 1021 height: -767 depth: 16 size imag
e: 1567748
winAllocateFBShadowGDI - WEIRDNESS - biHeight still negative: -767
winAllocateFBShadowGDI - WEIRDNESS - Flipping biHeight sign
winAllocateFBShadowGDI - Created shadow stride: 1022
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
winInitWM - Returning.
winFinishScreenInitFB - returning
winScreenInit - returning
InitOutput - Returning.
winMultiWindowXMsgProc - Hello
winMultiWindowXMsgProc - Calling pthread_mutex_lock ()
MIT-SHM extension disabled due to lack of kernel support
winInitMultiWindowWM - Hello
winInitMultiWindowWM - Calling pthread_mutex_lock ()
XFree86-Bigfont extension local-client optimization disabled due to lack of shar
ed memory support in the kernel
(==) winConfigKeyboard - Layout: "0409" (0409)
(EE) No primary keyboard configured
(==) Using compiletime defaults for keyboard
Rules = "xfree86" Model = "pc101" Layout = "us" Variant = "(null)" Options = "(n
ull)"
Next output from cygcheck:-
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Wed Nov 05 13:11:30 2003
Windows ME Ver 4.90 Build 3000
Path: C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
C:\cygwin\aspn\bin
c:\WINDOWS
c:\WINDOWS\COMMAND
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 811(default) GID: 544(all)
544(all)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 811(default) GID: 544(all)
544(all)
SysDir: C:\WINDOWS\SYSTEM
WinDir: C:\WINDOWS
HOME = `C:\cygwin\home\default'
MAKE_MODE = `unix'
PWD = `/tmp'
USER = `default'
BLASTER = `A220 I5 D1 T4 P330'
CMDLINE = `bash --login -i'
COMSPEC = `C:\WINDOWS\COMMAND.COM'
CVS_RSH = `/bin/ssh'
HOMEDRIVE = `C:'
HOMEPATH = `\cygwin\home\default'
INFOPATH =
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
MANPATH =
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/X11R6/man:/usr/ssl/man'
OLDPWD = `/usr/X11R6/bin'
PKG_CONFIG_PATH = `:/usr/X11R6/lib/pkgconfig'
PROMPT = `$p$g'
PS1 = `$ '
SHLVL = `1'
TEMP = `c:\WINDOWS\TEMP'
TERM = `cygwin'
TEXMF = `{/usr/share/lilypond/2.0.1,/usr/share/texmf}'
TMP = `c:\WINDOWS\TEMP'
WINBOOTDIR = `C:\WINDOWS'
WINDIR = `C:\WINDOWS'
_ = `/usr/bin/cygcheck'
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
(default) = `/cygdrive'
cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
(default) = `C:\cyg
Re: [XFree86] screen redraw problem
Maybe your app is expecting backing store. You can start XFree86 with backing store "startx -- +bs". Mark. On Wed, 5 Nov 2003, J S wrote: > Is there anymore information I need to add to this post? I would really like > to get some help with it. The logs don't seem to be showing anything. I've > tried setting different color depths, and screen resolutions but to no > avail. > > Hi, > > I have an application which has some boxes in the window. The window itself > is scrollable. When I scroll down - no problem, but when I scroll up the > boxes turn into long vertical bars. This problem doesn't happen with Exceed, > but on XFree86 (both Linux XFree86 and Cygwin-XFree) it does. > > Can anyone advise me whether this is a bug, or is there some setting I need > to add? Let me know if you need anymore information. > > Thanks for any help. > > JS. > > _ > Stay in touch with absent friends - get MSN Messenger > http://www.msn.co.uk/messenger > > ___ > XFree86 mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xfree86 >
Re: screen redraw problem
JS, Looks like you have found a generic problem with X or one of the libraries you are using. It is going to take a lot of debugging... you are going to have to be that guy. Harold J S wrote: Is there anymore information I need to add to this post? I would really like to get some help with it. The logs don't seem to be showing anything. I've tried setting different color depths, and screen resolutions but to no avail. Hi, I have an application which has some boxes in the window. The window itself is scrollable. When I scroll down - no problem, but when I scroll up the boxes turn into long vertical bars. This problem doesn't happen with Exceed, but on XFree86 (both Linux XFree86 and Cygwin-XFree) it does. Can anyone advise me whether this is a bug, or is there some setting I need to add? Let me know if you need anymore information. Thanks for any help. JS. _ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger
Cygwin X server crashes when a remote Xemacs is run
Here what I'm trying to do: I establish a rsh connection with a UNIX/Linux machine and open an xterm. The I run Xemacs on this remote machine and XWin.exe crashes. I tried it connecting with both a Linux machine and a Alpha machine. Here the Xemacs versions installed on those machines: Linux - Xemacs 21.1 (patch 14) i386-redhat-linux Alpha - Xemacs 20.4 alpha-dec-osf3.2 Here the Windows error message: Exception: access violation (0xc005), Address: 0x61093b2c I'm running Cygwin 1.5.5-1 on Windows NT 4.0 Workstation. XWin.exe version is 4.3.0-20 Giampaolo Orrigo <> cygcheck.out Description: Binary data
Re: Twin screens
In message <[EMAIL PROTECTED]>, Harold L Hunt II <[EMAIL PROTECTED]> writes Try the -multimonitor command-line parameter (add it to your current parameters). I believe that is the name of it... might be -multiplemonitor. In fact, either may work. In any case, it will fail to startup if the name is incorrect, in which case you should try the other one. It's -multiplemonitors, it works perfectly and it's fully documented. I have slapped myself hard on both wrists and apologise to you and everyone else for wasting their time. Regards, Cliff.
screen redraw problem
Is there anymore information I need to add to this post? I would really like to get some help with it. The logs don't seem to be showing anything. I've tried setting different color depths, and screen resolutions but to no avail. Hi, I have an application which has some boxes in the window. The window itself is scrollable. When I scroll down - no problem, but when I scroll up the boxes turn into long vertical bars. This problem doesn't happen with Exceed, but on XFree86 (both Linux XFree86 and Cygwin-XFree) it does. Can anyone advise me whether this is a bug, or is there some setting I need to add? Let me know if you need anymore information. Thanks for any help. JS. _ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger
Re: WindowMaker-0.80.2-1 bad TIFFs?
$ mount C:\cygwin\usr\X11R6\lib\X11\fonts on /usr/X11R6/lib/X11/fonts type system (binmode) C:\cygwin\bin on /usr/bin type system (binmode) C:\cygwin\lib on /usr/lib type system (binmode) C:\cygwin on / type system (binmode) c: on /cygdrive/c type user (binmode,noumount) k: on /cygdrive/k type user (binmode,noumount) l: on /cygdrive/l type user (binmode,noumount) m: on /cygdrive/m type user (binmode,noumount) n: on /cygdrive/n type user (binmode,noumount) p: on /cygdrive/p type user (binmode,noumount) v: on /cygdrive/v type user (binmode,noumount) Harold L Hunt II wrote: What mount type are you guys using for that directory? I would suspect that a text mount might cause problems. You should be using a binary mount. Harold Danilo Turina wrote: As I already told in message http://www.cygwin.com/ml/cygwin-xfree/2003-11/msg00023.html this is happening also to me. Not only the terminal icon is messed up, but also the icons of the Preferences panel of WindowMaker. Notice also that opening those tiffs with a viewer (e.g. IrfanView) they seems to be ok. Andrew Grimm wrote: My recently-updated Cygwin WindowMaker is whining to me: TIFFReadDirectory: Warning, /usr/X11R6/share/WINGs/Images.tiff: unknown field with tag 317 (0x13d) encountered. TIFFReadDirectory: Warning, /usr/X11R6/share/WindowMaker/Icons/Terminal.tiff: unknown field with tag 317 (0x13d) encountered. I believe it as the icon for the terminal looks messed up. This doesn't impact my ability to continue living, but it would be nice if it were corrected. I have all of the latest Cygwin packages (on Win 2k) so I don't think I'm missing a decode/display component or anything. Thanks, Andy
Antwort: Re: WindowMaker-0.80.2-1 bad TIFFs?
If wmaker is started manually, it gives the following output: "[EMAIL PROTECTED] /CYGDRIVE/D/cygwin/home $ wmaker TIFFReadDirectory: Warning, /usr/X11R6/share/WINGs/Images.tiff: unknown field wi th tag 317 (0x13d) encountered. TIFFReadDirectory: Warning, /usr/X11R6/share/WindowMaker/Icons/TerminalGNUstep.t iff: unknown field with tag 317 (0x13d) encountered. TIFFReadDirectory: Warning, /usr/X11R6/share/WindowMaker/Icons/TerminalLinux.tif f: unknown field with tag 317 (0x13d) encountered." I did an update from ftp.gwdg.de (?) today. Before the update the tiffs were okay. Yours hjb
Re: Default Mouse Pointer is Wrong
On Wed, 2003-11-05 at 09:37, Yadin Y. Goldschmidt wrote: > Colin Harrison suggested long time ago to add the following line to the end > of your startxwin.bat file: > xsetroot -cursor_name left_ptr -fg white -bg black > This will change the default mouse from an x to a white arrow. Ah ha, that did the trick. My apologies, I didn't even notice the suggestion when I searched for it. -.-;; Thanks for the help. :) -- Ricky Boone <[EMAIL PROTECTED]> Planetfurry.com
Re: obstacle running "cygwin" (communicating with Solaris 8, Sparc) ...
Hello Brain, much thanks for your response. But unfortunately my problem doesn't stay in relation with the fonts. I've tried it yet. Do you have another solution in mind? Bye Querra > On Tue, 4 Nov 2003, Andreas (privat) wrote: > > > it's my intention to start a remote login-process at the solaris-pc via > > cygwin. Unfortunately the > > login-session is always interrupted. Cygwin is only able to depict a > black > > screen (including the mouse cursor). Nothing else occurs > > > http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-solaris-fonts > > -- > Brian Ford > Senior Realtime Software Engineer > VITAL - Visual Simulation Systems > FlightSafety International > Phone: 314-551-8460 > Fax: 314-551-8444 > -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++
Re: WindowMaker-0.80.2-1 bad TIFFs?
I'll add my confirmation of the problem. TIFFs in WindowMaker worked fine before the last update. My mount settings represent a default Cygwin install: userid:/etc$ mount C:\cygwin\usr\X11R6\lib\X11\fonts on /usr/X11R6/lib/X11/fonts type system (binmode) C:\cygwin\bin on /usr/bin type system (binmode) C:\cygwin\lib on /usr/lib type system (binmode) C:\cygwin on / type system (binmode) Dan Harold L Hunt II wrote: What mount type are you guys using for that directory? I would suspect that a text mount might cause problems. You should be using a binary mount. Harold Danilo Turina wrote: As I already told in message http://www.cygwin.com/ml/cygwin-xfree/2003-11/msg00023.html this is happening also to me. Not only the terminal icon is messed up, but also the icons of the Preferences panel of WindowMaker. Notice also that opening those tiffs with a viewer (e.g. IrfanView) they seems to be ok. Andrew Grimm wrote: My recently-updated Cygwin WindowMaker is whining to me: TIFFReadDirectory: Warning, /usr/X11R6/share/WINGs/Images.tiff: unknown field with tag 317 (0x13d) encountered. TIFFReadDirectory: Warning, /usr/X11R6/share/WindowMaker/Icons/Terminal.tiff: unknown field with tag 317 (0x13d) encountered. I believe it as the icon for the terminal looks messed up. This doesn't impact my ability to continue living, but it would be nice if it were corrected. I have all of the latest Cygwin packages (on Win 2k) so I don't think I'm missing a decode/display component or anything. Thanks, Andy
Re: Default Mouse Pointer is Wrong
Hi, Colin Harrison suggested long time ago to add the following line to the end of your startxwin.bat file: xsetroot -cursor_name left_ptr -fg white -bg black This will change the default mouse from an x to a white arrow. An unrelated question to harold Hunt: Why if one uses mwm as the window manager and one invokes xclock it does not have a frame and can't be moved? xterm, rxvt, xeyes, etc all have frames and can be moved. "Ricky Boone" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > This may just be an idiotic question, but I couldn't seem to find an > answer in the archives. > > I am trying to connect to remote applications in X (in -multiwindow > mode) through ssh on cygwin. When I open the remote application, the > default mouse pointer (cursor, whatever) is an 'X'. Some special areas > in the application, such as text fields, change the cursor successfully > to a text selection pointer, but the 'X' pointer remains the default > nearly everywhere else. > > Previously I had been using the default window manager with Cygwin by > running startx, then remoting inside of it. That was a little > roundabout, but it worked. All cursors and pointers looked okay. > > I've just done a complete reinstall of Cygwin on my WinXP box, since I > thought perhaps either something was screwed up with the previous > installation, or something new had fixed the problem. The remote system > I'm connecting to is Fedora Core Test 3 running the latest packages, > though I'm willing to bet if I find another machine to test this on it > will do the same; it's got to be something on my end, whether it's a > misconfiguration or something I'm forgetting to do. > > Here's a quick example of exactly what I'm doing: > > * Open Cygwin shell (cygwin.bat) > * startxwin.sh > * Inside the xterm window: ssh -XC [EMAIL PROTECTED] > * Once logged into remote box: evolution & > * Everything loads okay, but mouse pointer is an 'X' instead of the > usual Windows arrow, or the default pointer on the remote box. > > Any ideas? :) > > -- > Ricky Boone <[EMAIL PROTECTED]> > Planetfurry.com > >
Re: Default Mouse Pointer is Wrong
On Wed, 2003-11-05 at 09:08, Harold L Hunt II wrote: > The default mouse pointer in X is an X. You are describing the correct > scenario. Okay, my mistake there. When I am referring to default, I mean the normal cursor, usually being an arrow. > The mouse pointer should not be a Windows arrow. I didn't think so since it wasn't like that while using the default cygwin window manager; it was using an arrow. > The mouse pointer will not be the default pointer that you have under > Gnome or KDE on the remote system because you are not running Gnome or > KDE on the remote system... you are running only a single application > with a local (not remote) window manager (a.k.a. MultiWindow mode, > a.k.a. -multiwindow command-line parameter). Thus, the mouse pointer > will be either a) the default mouse pointer (an X), or b) whatever an > application sets it to (e.g. a text insertion cursor). > > Does that make sense? Everything seems to be functioning normally. It does, but what is preventing the cursor from being displayed as an arrow like it could without -multiwindow enabled? Fuctionality-wise it works just fine, but aesthetically it's not ideal for the user to see an 'X' when they normally see an arrow. -- Ricky Boone <[EMAIL PROTECTED]> Planetfurry.com
Re: Twin screens
Try the -multimonitor command-line parameter (add it to your current parameters). I believe that is the name of it... might be -multiplemonitor. In fact, either may work. In any case, it will fail to startup if the name is incorrect, in which case you should try the other one. Harold Cliff Stanford wrote: I am running X using the following start-up command: start XWin -multiwindow -nounixkill -clipboard -nowinkill I have recently installed a second monitor onto my system (XP PRO) where the second monitor is to the LEFT of the main screen. The architecture correctly (in my opinion) treats the 0,0 point as being on the new, left-hand screen and everything works fine on that screen. If, however, I drag a window across from the left screen to the main screen, it freezes. Doesn't do anything at all, no input, no refresh. Dragging it back makes it happy again. I assume that it believes it is now off-screen. Cliff.
Twin screens
I am running X using the following start-up command: start XWin -multiwindow -nounixkill -clipboard -nowinkill I have recently installed a second monitor onto my system (XP PRO) where the second monitor is to the LEFT of the main screen. The architecture correctly (in my opinion) treats the 0,0 point as being on the new, left-hand screen and everything works fine on that screen. If, however, I drag a window across from the left screen to the main screen, it freezes. Doesn't do anything at all, no input, no refresh. Dragging it back makes it happy again. I assume that it believes it is now off-screen. Cliff. -- Cliff Stanford Might Limited +44 870 199 4137 (Office) Suite 67, Dorset House +44 7973 616 666 (Mobile) Duke Street, Chelmsford, CM1 1TB
Re: Default Mouse Pointer is Wrong
Ricky, Ricky Boone wrote: This may just be an idiotic question, but I couldn't seem to find an answer in the archives. I am trying to connect to remote applications in X (in -multiwindow mode) through ssh on cygwin. When I open the remote application, the default mouse pointer (cursor, whatever) is an 'X'. Some special areas in the application, such as text fields, change the cursor successfully to a text selection pointer, but the 'X' pointer remains the default nearly everywhere else. The default mouse pointer in X is an X. You are describing the correct scenario. Previously I had been using the default window manager with Cygwin by running startx, then remoting inside of it. That was a little roundabout, but it worked. All cursors and pointers looked okay. I've just done a complete reinstall of Cygwin on my WinXP box, since I thought perhaps either something was screwed up with the previous installation, or something new had fixed the problem. The remote system I'm connecting to is Fedora Core Test 3 running the latest packages, though I'm willing to bet if I find another machine to test this on it will do the same; it's got to be something on my end, whether it's a misconfiguration or something I'm forgetting to do. Here's a quick example of exactly what I'm doing: * Open Cygwin shell (cygwin.bat) * startxwin.sh * Inside the xterm window: ssh -XC [EMAIL PROTECTED] * Once logged into remote box: evolution & * Everything loads okay, but mouse pointer is an 'X' instead of the usual Windows arrow, or the default pointer on the remote box. The mouse pointer should not be a Windows arrow. The mouse pointer will not be the default pointer that you have under Gnome or KDE on the remote system because you are not running Gnome or KDE on the remote system... you are running only a single application with a local (not remote) window manager (a.k.a. MultiWindow mode, a.k.a. -multiwindow command-line parameter). Thus, the mouse pointer will be either a) the default mouse pointer (an X), or b) whatever an application sets it to (e.g. a text insertion cursor). Does that make sense? Everything seems to be functioning normally. Harold
Default Mouse Pointer is Wrong
This may just be an idiotic question, but I couldn't seem to find an answer in the archives. I am trying to connect to remote applications in X (in -multiwindow mode) through ssh on cygwin. When I open the remote application, the default mouse pointer (cursor, whatever) is an 'X'. Some special areas in the application, such as text fields, change the cursor successfully to a text selection pointer, but the 'X' pointer remains the default nearly everywhere else. Previously I had been using the default window manager with Cygwin by running startx, then remoting inside of it. That was a little roundabout, but it worked. All cursors and pointers looked okay. I've just done a complete reinstall of Cygwin on my WinXP box, since I thought perhaps either something was screwed up with the previous installation, or something new had fixed the problem. The remote system I'm connecting to is Fedora Core Test 3 running the latest packages, though I'm willing to bet if I find another machine to test this on it will do the same; it's got to be something on my end, whether it's a misconfiguration or something I'm forgetting to do. Here's a quick example of exactly what I'm doing: * Open Cygwin shell (cygwin.bat) * startxwin.sh * Inside the xterm window: ssh -XC [EMAIL PROTECTED] * Once logged into remote box: evolution & * Everything loads okay, but mouse pointer is an 'X' instead of the usual Windows arrow, or the default pointer on the remote box. Any ideas? :) -- Ricky Boone <[EMAIL PROTECTED]> Planetfurry.com
Re: Define a foreign language keyboard in HP-Ux CDE?
Hi Harold and others, I installed the new version of the Xserver and I got some closer but not as close as I´d like. Using Xserv 4.3.0-21 and defining the keyboard as Spanish in XF86Config gave me the following: - Shift key combinations work as supposed on a Spanish keyboard. - AltGr key combinations don't work. - In the xmodmap -pk output I can see that there is no definition for key combinations with AltGr, and that the AltGr key is defined as: 1130xfe03(ISO_Level3_Shift) 0xff20 (Multi_key) - I am still working with HP-UX CDE. - The definitions in /etc/X11/XF86Config are: Option "XkbModel""pc105" Option "XkbLayout" "es" #Option "XkbVariant" "nodeadkeys" #Option "LeftAlt" "Meta" Option "RightAlt""ModeShift" - XWin.log says it's installing the keyboard OK. Any suggestions to resolve this will be more than welcome. Regards, Hans. Harold L Hunt II escribió: Hans, Hans Dekker wrote: Hi all, Having downloaded the latest version of XFree86, I encounter a problem using altGR on a Spanish keyboard. I searched and I searched and saw many articles of people with the same question from Denmark, Norway, Germany, UK and other countries, and fixes with Xmodmaps, xkeycaps, XF86Config, etc leaving still unclear to me which one is right: I didn't get it working yet. Can anyone tell me what´s the final solution? Doing a xmodmap on one of the CDE windows shows a keyboard with a US layout. A normal Xfree86 xterm (without CDE) is working fine with the same keyboard. I am using Xserv V 4.2.0-42 on WindowsXP with a CDE environment on Wow! 4.2.0-42 was released 2003/06/02. Since then we have moved from XFree86 4.2.0 to 4.3.0 and had about 25 updates to the Cygwin X Server (XWin.exe, XFree86-xserv). A lot of those updates are for keyboard-detection code written by Alexander Gottwald. I suggest updating your installation and buying Alexander a pizza if it works for you: http://www-user.tu-chemnitz.de/~goal/xfree/donations.html :) Here is the release announcement for XFree86-xserv-4.2.0-42, in case anyone is interested: http://cygwin.com/ml/cygwin-xfree-announce/2003-06/msg5.html Hope that helps, Harold .
Re: WindowMaker-0.80.2-1 bad TIFFs?
What mount type are you guys using for that directory? I would suspect that a text mount might cause problems. You should be using a binary mount. Harold Danilo Turina wrote: As I already told in message http://www.cygwin.com/ml/cygwin-xfree/2003-11/msg00023.html this is happening also to me. Not only the terminal icon is messed up, but also the icons of the Preferences panel of WindowMaker. Notice also that opening those tiffs with a viewer (e.g. IrfanView) they seems to be ok. Andrew Grimm wrote: My recently-updated Cygwin WindowMaker is whining to me: TIFFReadDirectory: Warning, /usr/X11R6/share/WINGs/Images.tiff: unknown field with tag 317 (0x13d) encountered. TIFFReadDirectory: Warning, /usr/X11R6/share/WindowMaker/Icons/Terminal.tiff: unknown field with tag 317 (0x13d) encountered. I believe it as the icon for the terminal looks messed up. This doesn't impact my ability to continue living, but it would be nice if it were corrected. I have all of the latest Cygwin packages (on Win 2k) so I don't think I'm missing a decode/display component or anything. Thanks, Andy
Re: Font and .bat files missing when installing XFree86 only?
Hi Harold, I guess I got confused by the different versions and different download sites there are. Sometimes parts are not downloaded of which the setup program sees (or thinks) they already exist on the system, which left me with an incomplete version of Xfree. Yesterday I deleted all there was and started a new download which seems to incorporate everything. Thanks however, Hans. Harold L Hunt II escribió: Hans Dekker wrote: Hi all, Having downloaded a version of XFree86, I see a difference between a previous version and this one: - When installing de XFree86 option only, no fonts are installed. I had to install (= copy) font files from a previous version and that worked. Am I missing something? You need the XFree86-fnts package at a minimum. I am surprised that this was not automatically selected. Are you sure that you selected XFree86-base? That package lists XFree86-fnts as a dependency, so it should have been automatically selected. - Also, some useful .bat files of which startxwin.bat is one, are missing from the current installation. Even when installing the complete package wouldn't help. Why was that? You have to pick the XFree86-startup-scripts package. Hope that helps. Harold .
Re: WindowMaker-0.80.2-1 bad TIFFs?
As I already told in message http://www.cygwin.com/ml/cygwin-xfree/2003-11/msg00023.html this is happening also to me. Not only the terminal icon is messed up, but also the icons of the Preferences panel of WindowMaker. Notice also that opening those tiffs with a viewer (e.g. IrfanView) they seems to be ok. Andrew Grimm wrote: My recently-updated Cygwin WindowMaker is whining to me: TIFFReadDirectory: Warning, /usr/X11R6/share/WINGs/Images.tiff: unknown field with tag 317 (0x13d) encountered. TIFFReadDirectory: Warning, /usr/X11R6/share/WindowMaker/Icons/Terminal.tiff: unknown field with tag 317 (0x13d) encountered. I believe it as the icon for the terminal looks messed up. This doesn't impact my ability to continue living, but it would be nice if it were corrected. I have all of the latest Cygwin packages (on Win 2k) so I don't think I'm missing a decode/display component or anything. Thanks, Andy
