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: xemacs: segmentation fault after

2004-10-01 Thread Siegmar Gross

> Just try and move /usr/share/xemacs to /usr/share/xemacs.broken and see
> what happens when you start xemacs. If it's not crashing, just include
> one package after the other and start xemacs again.

I had to remove the following nine packages:

eiger xemacs 165 pwd
/usr/share/xemacs
eiger xemacs 166 ls -l */lisp/
mule-packages/lisp/:
total 0
drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:28 edict
drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:28 egg-its
drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:28 skk

xemacs-packages/lisp/:
total 0
drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:29 c-support
drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:29 calc
drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:29 calendar
drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:29 cc-mode
drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:29 cookie
drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:29 crisp
eiger xemacs 167 
eiger xemacs 168 xemacs
Warning: XtRemoveGrab asked to remove a widget not on the list
Warning: XtRemoveGrab asked to remove a widget not on the list
eiger xemacs 169 


When I add one of them to the parent lisp directory xemacs crashes with
segmentation fault when I type . The warnings still appear
after typing .


I would like to have c-support and cc-mode. Any ideas what's wrong with
the above packages?


Siegmar




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.


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:
> 
> > please send /tmp/XWin.log
> 
> Here it is

> 
> ddxProcessArgument - Initializing default screens
> winInitializeDefaultScreens - w 1200 h 1600
> winInitializeDefaultScreens - Returning
> (II) XF86Config is not supported
> (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
> winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel
> winAllocateFBShadowGDI - Creating DIB with width: 1159 height: 1566 depth: 32

Somehow the workarea got stripped. Can you please run with more debug messages
and send me the logfile again?

XWin :1 +kb -clipboard -multiwindow -fp 
/usr/X11R6/lib/X11/fonts/cyrillic,/usr/X11R6/lib/X11/fonts/75dpi,/usr/X11R6/lib/X11/fonts/misc,/usr/X11R6/lib/X11/fonts/intlfonts
 
-logfile /tmp/rootless.log -logverbose 5

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


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

2004-10-01 Thread Dr. Volker Zell
> Siegmar Gross writes:

>> Just try and move /usr/share/xemacs to /usr/share/xemacs.broken and see
>> what happens when you start xemacs. If it's not crashing, just include
>> one package after the other and start xemacs again.

> I had to remove the following nine packages:

> eiger xemacs 165 pwd
> /usr/share/xemacs
> eiger xemacs 166 ls -l */lisp/
> mule-packages/lisp/:
> total 0
> drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:28 edict
> drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:28 egg-its
> drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:28 skk

> xemacs-packages/lisp/:
> total 0
> drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:29 c-support
> drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:29 calc
> drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:29 calendar
> drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:29 cc-mode
> drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:29 cookie
> drwxr-xr-x+   2 AdminBenutzer0 Sep 17 09:29 crisp
> eiger xemacs 167 
> eiger xemacs 168 xemacs
> Warning: XtRemoveGrab asked to remove a widget not on the list
> Warning: XtRemoveGrab asked to remove a widget not on the list
> eiger xemacs 169 


> When I add one of them to the parent lisp directory xemacs crashes with
> segmentation fault when I type . The warnings still appear
> after typing .


> I would like to have c-support and cc-mode. Any ideas what's wrong with
> the above packages?

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 ?

> Siegmar

Ciao
  Volker



Re: xemacs: segmentation fault after

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.


RE: cygwin/x symantec antivirus conflict

2004-10-01 Thread Orrigo, Giampaolo .
I run version 10.0.1.13 and I have no problems.

GP


> From: 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: Jack Tanner
> Sent: Thursday, September 30, 2004 5:05 PM
> 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.


Re: Windows person trying to use Cygwin

2004-10-01 Thread Igor Pechtchanski
On Fri, 1 Oct 2004, Marcos Rebelo wrote:

> I'm finding two annoying problems in Cygwin
>
> 1º) I can't have the Num Lock activated otherwise the arrow keys don't work.
> 2º) with nedit I can select text with the mouse, but not with the keyboard.
>
> I don't know if the problems are related.

1) You didn't have to post twice.
2) Your problems seem like X problems, which should be discussed on the
Cygwin/X list.  I've redirected this reply there, and set the Reply-To:
accordingly.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

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.