Re: Strange redraw problem with multiwindow

2004-10-01 Thread Alexander Gottwald
On Fri, 1 Oct 2004, Roman Belenov wrote:

 I have the following problem - if a window is resized so that part of it get's
 closer than 40 pixels to left screen border (I've got 1200x1600 resolution, so
 effect takes places when absolute x coordinate of some pixels in a window is
 larger then 1160), that part becomes white and is not redrawn later. If I just
 move the window to the right edge of the screen, it is redrawn correctly. The
 effect also takes place on window maximization - again, I have 40-pixels wide
 white vertical stripe near the right edge of the window. Without multiwindow,
 everything works fine - I have fullscreen root window and applications
 maximized inside it don't have this white stripe. Any ideas ?

please send /tmp/XWin.log

bye
ago
-- 
 [EMAIL PROTECTED] 
 http://www.gotti.org   ICQ: 126018723


Strange window redraw problem (Still)

2004-10-01 Thread Cserveny Tamas


Cserveny Tamas

Der Kopf und der Hals gehen zusammen in den Garten und spielen Ball im Wasser.



Re: Strange redraw problem with multiwindow

2004-10-01 Thread Roman Belenov
Alexander Gottwald [EMAIL PROTECTED] writes:

 please send /tmp/XWin.log

Here it is



rootless.log
Description: X server log

-- 
With regards, Roman.


Strange window redraw problem (Still)

2004-10-01 Thread Cserveny Tamas
Hi list,

Dave Carrigan wrote a letter previously about this issue.
([EMAIL PROTECTED]) 

My problem is pretty much the same, but i'm not using xwinwm. XWinWM would be
workaround for the problem (maybe it makes an additional refrEsh), but it
won't solve the issue. This problem exist in -multiwindow mode. 

I have made some screen shots under http://koli.rulez.org/~smil/xfree

- the level of blankness is not the same for all widgetsets. Eg.
   Motif seems to be more affected and KDE seems to loose rarely one or to 
   lines. (It seems that only fonts get lost, once konsole's tabs but that is
   very rare)

- Moving the mouse on the missing parts would reveal the content. (bug3.jpg)
- There are no window tweaking tool installed on this computer. (XP SP1)
- Tested with local xclients and sun59 clients. (standard tools like xfontset   
   also affeced)

I hope I was able to provide as enough information. If someone has a debug
binary I would be happy to make tests with it. 

(cygcheck's output is uploaded to the above address was well as the xwin.log)

-- 
Cserveny Tamas

ps. Sorry for the empty message



Re: Strange redraw problem with multiwindow

2004-10-01 Thread Roman Belenov
Alexander Gottwald [EMAIL PROTECTED] writes:

 Somehow the workarea got stripped.

Actually, it seems that I found the cause. I'm using Next-like application
launcher (BrLaunch) that uses left side of the screen to display button bar
(have been using it for years and so forgot to mention it in the first
message as something unusual). It resizes the desktop, so that when a window
is maximized, it doesn't cover the buttons. Seems that X server in multiwindow
mode gets confused.

Just tried X -multiwindow without BrLaunch launched, and it works fine. But it
would be nice if it operates correctly with resized desktop.

 Can you please run with more debug messages and send me the logfile again?

No problem.



rootless.log
Description: Binary data

-- 
With regards, Roman.


Re: Strange redraw problem with multiwindow

2004-10-01 Thread Roman Belenov
BTW moving standard Windows taskbar to the left of the screen causes the same
problem.

-- 
With regards, Roman.



Re: Strange redraw problem with multiwindow

2004-10-01 Thread Alexander Gottwald
On Fri, 1 Oct 2004, Roman Belenov wrote:

 Alexander Gottwald [EMAIL PROTECTED] writes:
 
  Somehow the workarea got stripped.
 
 Actually, it seems that I found the cause. I'm using Next-like application
 launcher (BrLaunch) that uses left side of the screen to display button bar
 (have been using it for years and so forgot to mention it in the first
 message as something unusual). It resizes the desktop, so that when a window
 is maximized, it doesn't cover the buttons. Seems that X server in multiwindow
 mode gets confused.
 
 Just tried X -multiwindow without BrLaunch launched, and it works fine. But it
 would be nice if it operates correctly with resized desktop.

I think I'll skip the size adjustment in the native windowmanager modes. 
The windows are not bound to the workarea and restricting the buffer to 
that size seems only to cause problems.

bye
ago
-- 
 [EMAIL PROTECTED] 
 http://www.gotti.org   ICQ: 126018723


Re: xemacs: segmentation fault after ctrl-xctrl-c

2004-10-01 Thread Siegmar Gross

 And XEmacs is really crashing for you even if you don't use this 9
 packages ? Is there any hint in the *Message-Log* Buffer which lisp file
 is getting loaded before you press c-x c-c ?

No, it doesn't crash when I move the mentioned directories to a subdirectory
but it crashes when any (just one is enough) of these packages is stored in
the lisp directory. I started xemacs without a file so every time the cus-face
package had been loaded. I don't know where it comes from because I couldn't
find a package with that name. Do you have an idea what could be wrong?
When I look e.g. at the files in crisp they are from 2003 and earlier so
they haven't been touched in the last update but nevertheless they let xemacs
crash.

Siegmar



RE: cygwin/x symantec antivirus conflict

2004-10-01 Thread Armbrust, Daniel C.
I have a corporate version of 8.1.1.323, and see no slowdowns.

I didn't have to do anything special to make it work.

(Helpful post huh?)

Dan

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jack Tanner
Sent: Thursday, September 30, 2004 5:05 PM
To: [EMAIL PROTECTED]
Subject: Re: cygwin/x symantec antivirus conflict

Alexander Gottwald wrote:
 I'll add this to the FAQ. Does Symantec Antivirus has an option to disable
 scanning for certain programs?
 
 Try adding XWin.exe to that list.

Good idea, but no dice. I added the entire c:\cygwin\ tree to the 
Symantec exclusion list, but the slowdown is still there. There's also 
no difference if you disable network drive scanning, or something called 
Threat Tracer (the purpose of TT is Identify the source of network 
share-based virus infections on computers that are running Windows 
NT/2000/XP operating systems.)

This really sucks. I don't want to run without antivirus protection, but 
the delay is really irritating.

Is anybody using Symantec Antivirus and NOT seeing a delay? If so, what 
version of SA are you using? I have full version 9.0.0.1400, scan 
engine 1.2.0.13.


different mouse behavior between rootless and multiwindow

2004-10-01 Thread Remfrey, Eric
Hi,

I am working on getting a native Solaris app to run on Windows using Cygwin.  
Currently, we use Exceed to do this, so if I can get this working properly, I'm sure I 
could convince our department head to send a donation your way.  I have had success 
with running it rootless, but am having some trouble getting the mouse to behave 
properly using the multiwindow switch.

In this CAD application, the screen is divided in to two parts; the main part is where 
the drawing is displayed, and the second part is a toolbar off to the right. 

How it should work:
 When you click and hold the right mouse button in, a new mouse cursor appears on the 
toolbar.  The original cursor stays where it was before you right-click.  You cannot 
move the new cursor outside of the toolbar region.  The purpose of this is so that an 
engineer can change tools without moving the original mouse pointer.  Once you let go 
of the right mouse button, you regain control of the original cursor exactly where you 
left it.

What is happening:
I right click I get the new cursor, but it appears directly over the original cursor 
rather than over the toolbar, and I can move it freely anywhere inside the window.  
When I let go of the right mouse button, the old pointer moves to where my mouse is 
before I regain control of it.  

Again, using the rootless switch everything works perfectly, but we would really 
prefer to run it with the Windows window manager.  Turning the numlock key on or off 
does not appear to have an impact on this behavior.

I know this is a long shot, but any help or suggestions would be very much appreciated.

Thanks,

Eric


FW: different mouse behavior between rootless and multiwindow

2004-10-01 Thread Remfrey, Eric
Sorry about the original post.  So much for trying not to look like an idiot... 

  -Original Message-
 From: Remfrey, Eric  
 Sent: Friday, October 01, 2004 10:09 AM
 To:   '[EMAIL PROTECTED]'
 Subject:  different mouse behavior between rootless and multiwindow
 
 Hi,
 
 I am working on getting a native Solaris app to run on Windows using Cygwin.  
 Currently,
 we use Exceed to do this, so if I can get this working properly, I'm sure I could 
 convince
 our department head to send a donation your way.  I have had success with running it
 rootless, but am having some trouble getting the mouse to behave properly using the
 multiwindow switch.
 
 In this CAD application, the screen is divided in to two parts; the main part is 
 where the
 drawing is displayed, and the second part is a toolbar off to the right. 
 
 How it should work:
  When you click and hold the right mouse button in, a new mouse cursor appears on the
 toolbar.  The original cursor stays where it was before you right-click.  You cannot 
 move
 the new cursor outside of the toolbar region.  The purpose of this is so that an 
 engineer
 can change tools without moving the original mouse pointer.  Once you let go of the 
 right
 mouse button, you regain control of the original cursor exactly where you left it.
 
 What is happening:
 I right click I get the new cursor, but it appears directly over the original cursor 
 rather than
 over the toolbar, and I can move it freely anywhere inside the window.  When I let 
 go of the
 right mouse button, the old pointer moves to where my mouse is before I regain 
 control of
 it.  
 
 Again, using the rootless switch everything works perfectly, but we would really 
 prefer to
 run it with the Windows window manager.  Turning the numlock key on or off does not
 appear to have an impact on this behavior.
 
 I know this is a long shot, but any help or suggestions would be very much 
 appreciated.
 
 Thanks,
 
 Eric


multi head X

2004-10-01 Thread Anthony Gabrielson
Hello,
I did a quick search and didn't turn up anything so here goes.  
I'm running XP with cygwin and cygwin X which is great.  I'm just having a 
problem if I drag a window over to the number 1 display, I can no longer 
interact with it.  Do I need to reconfig for two displays?

I think your version is better than exceed by alot other than 
that.

Thanks -
Anthony


Re: multi head X

2004-10-01 Thread Alexander Gottwald
On Fri, 1 Oct 2004, Anthony Gabrielson wrote:

 Hello,
   I did a quick search and didn't turn up anything so here goes.  
 I'm running XP with cygwin and cygwin X which is great.  I'm just having a 
 problem if I drag a window over to the number 1 display, I can no longer 
 interact with it.  Do I need to reconfig for two displays?
 
   I think your version is better than exceed by alot other than 
 that.

Please try adding the -multiplemonitors switch to XWin.exe start

bye
ago
-- 
 [EMAIL PROTECTED] 
 http://www.gotti.org   ICQ: 126018723


Bug|RFE: Manually set mouse button count

2004-10-01 Thread Xuân Baldauf
Hello,
At least if XWin is run on notebook, there might be the problem that 
cygwin incorrectly detects the number of available mouse buttons. This 
may be the case especially if a 3-button-wheel mouse is attached to a 
PS/2-port of that notebook, because the internal PS/2-port emulator 
intermixes external mouse events with touchpad events. In this case, 
cygwin detects only 2 buttons (I assume the two touchpad buttons), while 
it should detect 3 buttons.

This is usually not a real problem, because cygwin seems to add (by 
default) 2 buttons (for wheel-up and wheel-down), resultin in a total of 
4 buttons. But if the user wants to use the wheel of the attached wheel 
mouse, the wheel-up-events are properly scheduled to the X clients, but 
the wheel-down-events are not.

If one could manually specifiy the number of available mouse buttons 
(e.g. by command-line), this problem could be solved. Additionally, a 
related problem could be solved, too: Even if XWin correctly detects at 
startup time that there are only 2 mouse buttons, users might plug in a 
mouse with more buttons later on.

Cheers,
Xuân.