RE: OT - Terminal embedded in desktop
Umm, Jean-Claude, most likely I'm missing something, but shouldn't you be able to create one yourself rather easily by taking the code for a stock xterm (the simpler - the better), removing the call that creates the window, and using root drawing calls instead of window drawing calls? I know it won't be *that* simple, but as a general direction, does the above look feasible? Igor On Tue, 3 Jun 2003, Jean-Claude Gervais wrote: Hi Biju, Thanks for taking the time to try and understand. I know I am not totally clear. I'm not looking for something for Windows. It's something for X, Gnome, KDE, or whatever other X thingie I'd need to run it where the desktop is a normal Linux X desktop, with icons and things on it, but at the same time, it is a terminal window. The terminal window is transparent, yes. But not transparent like a lot of X terminals I've seen that only put the same bitmap that the X root window is using in their client area. With normal terminals, you see a fake transparence; it simulates transparence by using the desktop bitmap as a background in its (the terminal's) window. I'm talking about a desktop applet (maybe an applet, maybe something else, I'm not sure) that is a terminal window, covering the desktop, but really transparent. And if you click on an item on the desktop, you can activate it. Does that make any sense? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Biju G C Sent: Sunday, June 01, 2003 3:55 PM To: [EMAIL PROTECTED] Subject: Re: OT - Terminal embedded in desktop --- Jean-Claude Gervais [EMAIL PROTECTED] wrote: Hello, Also, the terminal window, since it is the desktop, would not have a border, would take up the entire desktop and could not be moved. It would not appear in the window list of the window manager. Is there such an animal? Is it an application, a window manager or a combination of the two? Thanks. R u looking some thing like the following They are not X Window manger, But May be use it along with XWin.exe (I have not tried) http://blueboxshell.org/ http://bb4win.org/news.php http://www.litestep.net/ http://indiestep.sourceforge.net/ http://www.lokai.org/ http://www.geoshellx.com/ http://geoshell.sourceforge.net/GeoWiki http://carbon.shellscape.org/ http://shells.lokai.net/ -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Schedule for upgrade to XFree 4.3?
Folks, Is there a schedule for upgrade to XFree 4.3? Ruth
Re: xwinclip shouldn't monitor the primary selection
Think what you want in five minutes, but I have worked on it for over a year and it isn't as simple as you think. Keep your suggestions to yourself if you don't have anything concrete to contribute. Harold [EMAIL PROTECTED] wrote: Sorry. I have searched the maillist and I've read several times that xwinclip must be rewritten, but I can't find why. In January, you said that you are planning to integrate xwinclip into the X server to be able to detect when an application asserts a selection ownership (at least, it's what I understant :-?). I think that this is a dead end, because an X application doesn't need to notify the X server when the selection content changes. For example, gvim asserts the primary selection ownership when you begins the drag operation and doesn't assert it again when you release the mouse button. Nonetheless, monitoring the primary selection is a bad idea. The primary selection is a secondary way of coping and pasting, an easter egg for expert users and is very volatile. The main way of cutting, coping and pasting must be the clipboard selection. Look at http://www.freedesktop.org/standards/clipboards.txt. So I think that xwinclip must ignore the primary selection. Good bye!
Re: CVS Import
Alexander, Thanks for taking care of this. I am pulling a tree down now. Harold Alexander Gottwald wrote: Hi, I've just imported the Xfree 4.3.0 sources and the server test 91 sources to the xoncygwin cvs at sourceforge. I've not yet done a test build. Some changes which were applied to the windows-1 branch may also be taken over to the HEAD branch (eg some files in config/cf) but I've not touched them yet. bye ago
Re: Schedule for upgrade to XFree 4.3?
Is this a broken record? I replied to this yesterday. Harold Ruth Ivimey-Cook wrote: Folks, Is there a schedule for upgrade to XFree 4.3? Ruth
Re: Problem with releases since -37
On Tue, Jun 03, 2003 at 10:38:52AM -0400, Andrew Braverman wrote: I updated the XWin package to -42 and changed nothing else. The new stackdump is attached. Thank you again for all the help. I was talking about the latest CYGWIN DLL, not the latest XWin package. [mailto:[EMAIL PROTECTED] Behalf Of Christopher Faylor Sent: Monday, June 02, 2003 7:44 PM To: [EMAIL PROTECTED] Subject: Re: Problem with releases since -37 On Mon, Jun 02, 2003 at 05:56:19PM -0400, Andrew Braverman wrote: Sorry. Missed that one. It is attached now. Doh. I was hoping that if I saw the cygwin version from the cygcheck output I would be able to figure out the stack dump but I've removed the debugging version of cygwin 1.3.22 that I'd need to do that. If you want to try the latest (i.e., the soon to be uploaded June 2 version) cygwin snapshot DLL and send the stackdump file again, I should be able to say where it is dying from the hex address.
Re: Schedule for upgrade to XFree 4.3?
On Mon, 2 Jun 2003, Harold L Hunt II wrote: Ruth, No schedule. We are working on it, sort of. Thanks for the reply, and sorry I didn't notice it earlier... don't know why :-( I was thinking mainly of the font system improvements, I guess. Regards, Ruth -- Ruth Ivimey-Cook Software engineer and technical writer.
Re: compile does not create me an xwin.exe
I looked through the build log and it appears that it fails to build something is wrong with: winmultiwindowclass ... rm -f winmsg.o gcc -c -O2 -fno-strength-reduce -Wall -Wpointer-arith -I. -I../../../../exports/include/X11 -I../../../../include/fonts -I../../../../programs/Xserver/fb -I../../../../programs/Xserver/mi -I../../../../programs/Xserver/miext/shadow -I../../../../programs/Xserver/miext/layer -I../../../../programs/Xserver/include -I../../../../programs/Xserver/os -I../../../../include/extensions -I../../../../exports/include/X11 -I../../../../programs/Xserver/render -I../../../../programs/Xserver/randr -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 -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DPIXPRIV -DRENDER -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXvExtension -DXFree86Server -DXvMCExtension-DXResExtension -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXvExtension -DXFree86Server -DXvMCExtension-DXResExtension -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DDDXTIME -DFD_SETSIZE=256 -DDDXOSINIT -DDDXOSVERRORF -DDDXOSFATALERROR -DHAS_MMAP -UXFree86LOADER -UXF86DRI -DPROJECTROOT=\/usr/X11R6\ winmsg.c make[5]: *** No rule to make target `winmultiwindowclass.o', needed by `libXwin.a'. Stop. make[5]: Leaving directory `/x-devel/build/std/programs/Xserver/hw/xwin' make[4]: *** [hw/xwin] Error 2 make[4]: Leaving directory `/x-devel/build/std/programs/Xserver' making all in programs/lbxproxy... make[4]: Entering directory `/x-devel/build/std/programs/lbxproxy' making all in programs/lbxproxy/di... make[5]: Entering directory `/x-devel/build/std/programs/lbxproxy/di' rm -f main.o ... Original Message Follows XWin.exe will be in build/std/programs/Xserver/XWin.exe, not in build/std/XWin.exe. Does that help? Harold Calvin Smith wrote: i'm trying to compile xwin following the 'Cygwin/XFree86 Contributor's Guide' but after i run make World it doesn't create an xwin.exe _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Rob,
Please update to XFree86-xserv-4.2.0-42.
I forget... did I already ask you to try this without using -clipboard
(you are using -clipboard, right)? If not, please try this without
using -clipboard and report your results.
Harold
Robert Pang wrote:
Hi John
This is what I see in /tmp/XWin.log from 2 consecutive tries.
GetWindowName - XA_STRING Mozilla {Build ID: 2003052723}
GetWindowName
GetWindowName - XA_STRING Getting Involved with mozilla.org - Mozilla {Build
ID: 2003052723}
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
GetWindowName
GetWindowName - XA_STRING Mozilla {Build ID: 2003051323}
GetWindowName
GetWindowName - XA_STRING Robert Pang's Web Top - Mozilla {Build ID:
2003051323}
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
GetWindowName
GetWindowName - XA_STRING Mozilla {Build ID: 2003051323}
GetWindowName
GetWindowName - XA_STRING Robert Pang's Web Top - Mozilla {Build ID:
2003051323}
GetWindowName
GetWindowName - XA_STRING mozilla-bin
Thanks.
Rob
- Original Message -
From: Harold L Hunt II huntharo at msu dot edu
To: cygwin-xfree at cygwin dot com
Date: Mon, 02 Jun 2003 21:40:56 -0400
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
References: [EMAIL PROTECTED]
Reply-to: cygwin-xfree at cygwin dot com
I haven't got any ideas. Check /tmp/XWin.log before and after mozilla
crashes. Report any new lines that show up during this period.
Harold
- Original Message -
From: Robert Pang [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 02, 2003 6:24 PM
Subject: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi developers,
I am running XFree 86 for Cygwin (4.2.0 - 37) on Windows 2000. I am having
problem with Mozilla 1.4 beta running on Sparc Solaris 2.6 and displayed
in
my XFree 86 running in multi-window mode. Mozilla starts fine. However,
whenever I click in the address bar to enter a new URL, Mozilla aborts
with
the following error when I click in the address bar.
mozilla ./mozilla
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 17 (X_GetAtomName)
Atom id in failed request: 0xc000
Serial number of failed request: 2467
Current serial number in output stream: 2467
Mozilla running from Linux/x86 doesn't show the same problem and works
perfectly. Any clue what's wrong with Mozilla on Sparc Solaris?
Thanks.
Rob
RE: [ANNOUNCEMENT] Server Test 91
Harold Hunt wrote: 5) winclass.c, winclass.h - Rename these files to winmultiwindowclass.c and winmultiwindowclass.h, respectively, since they are only used in MultiWindow mode. Prefix the functions in these files with MultiWindow. (Harold L Hunt II) The appended patch contains some function parameter checking to avoid segfaults in case of invalid parameter values. It is based on the xwin-Test91 release. Ralf param_check_xwin91.dif Description: Binary data
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi Harold
I update to XFree86-xserv-4.2.0-42 and mozilla still crashes when I click on
the address bar. But it doesn't crash if I do not use -clipboard. So, is
-clipboard the problem? How come I don't have a problem with -clipboard
if mozilla is run from Linux instead?
Thanks.
Rob
- Original Message -
From: Harold L Hunt II huntharo at msu dot edu
To: cygwin-xfree at cygwin dot com
Date: Tue, 03 Jun 2003 13:32:43 -0400
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
References: [EMAIL PROTECTED]
Reply-to: cygwin-xfree at cygwin dot com
Rob,
Please update to XFree86-xserv-4.2.0-42.
I forget... did I already ask you to try this without using -clipboard (you
are using -clipboard, right)? If not, please try this without
using -clipboard and report your results.
Harold
Robert Pang wrote:
- Original Message -
From: Robert Pang [EMAIL PROTECTED]
To: Robert Pang [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 10:09 AM
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi Harold
This is what I see in /tmp/XWin.log from 2 consecutive tries.
GetWindowName - XA_STRING Mozilla {Build ID: 2003052723}
GetWindowName
GetWindowName - XA_STRING Getting Involved with mozilla.org - Mozilla
{Build
ID: 2003052723}
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
GetWindowName
GetWindowName - XA_STRING Mozilla {Build ID: 2003051323}
GetWindowName
GetWindowName - XA_STRING Robert Pang's Web Top - Mozilla {Build ID:
2003051323}
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
GetWindowName
GetWindowName - XA_STRING Mozilla {Build ID: 2003051323}
GetWindowName
GetWindowName - XA_STRING Robert Pang's Web Top - Mozilla {Build ID:
2003051323}
GetWindowName
GetWindowName - XA_STRING mozilla-bin
Thanks.
Rob
- Original Message -
From: Harold L Hunt II huntharo at msu dot edu
To: cygwin-xfree at cygwin dot com
Date: Mon, 02 Jun 2003 21:40:56 -0400
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
References: [EMAIL PROTECTED]
Reply-to: cygwin-xfree at cygwin dot com
I haven't got any ideas. Check /tmp/XWin.log before and after mozilla
crashes. Report any new lines that show up during this period.
Harold
- Original Message -
From: Robert Pang [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 02, 2003 6:24 PM
Subject: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi developers,
I am running XFree 86 for Cygwin (4.2.0 - 37) on Windows 2000. I am
having
problem with Mozilla 1.4 beta running on Sparc Solaris 2.6 and displayed
in
my XFree 86 running in multi-window mode. Mozilla starts fine. However,
whenever I click in the address bar to enter a new URL, Mozilla aborts
with
the following error when I click in the address bar.
mozilla ./mozilla
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 17 (X_GetAtomName)
Atom id in failed request: 0xc000
Serial number of failed request: 2467
Current serial number in output stream: 2467
Mozilla running from Linux/x86 doesn't show the same problem and works
perfectly. Any clue what's wrong with Mozilla on Sparc Solaris?
Thanks.
Rob
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Harold
BTW, I don't have the crash when -clipboard is in use when I do not use
multiwindow mode.
Rob
- Original Message -
From: Robert Pang [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 1:14 PM
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi Harold
I update to XFree86-xserv-4.2.0-42 and mozilla still crashes when I click
on
the address bar. But it doesn't crash if I do not use -clipboard. So, is
-clipboard the problem? How come I don't have a problem with
-clipboard
if mozilla is run from Linux instead?
Thanks.
Rob
- Original Message -
From: Harold L Hunt II huntharo at msu dot edu
To: cygwin-xfree at cygwin dot com
Date: Tue, 03 Jun 2003 13:32:43 -0400
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
References: [EMAIL PROTECTED]
Reply-to: cygwin-xfree at cygwin dot com
Rob,
Please update to XFree86-xserv-4.2.0-42.
I forget... did I already ask you to try this without using -clipboard
(you
are using -clipboard, right)? If not, please try this without
using -clipboard and report your results.
Harold
Robert Pang wrote:
- Original Message -
From: Robert Pang [EMAIL PROTECTED]
To: Robert Pang [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 10:09 AM
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi Harold
This is what I see in /tmp/XWin.log from 2 consecutive tries.
GetWindowName - XA_STRING Mozilla {Build ID: 2003052723}
GetWindowName
GetWindowName - XA_STRING Getting Involved with mozilla.org - Mozilla
{Build
ID: 2003052723}
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
GetWindowName
GetWindowName - XA_STRING Mozilla {Build ID: 2003051323}
GetWindowName
GetWindowName - XA_STRING Robert Pang's Web Top - Mozilla {Build ID:
2003051323}
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
GetWindowName
GetWindowName - XA_STRING Mozilla {Build ID: 2003051323}
GetWindowName
GetWindowName - XA_STRING Robert Pang's Web Top - Mozilla {Build ID:
2003051323}
GetWindowName
GetWindowName - XA_STRING mozilla-bin
Thanks.
Rob
- Original Message -
From: Harold L Hunt II huntharo at msu dot edu
To: cygwin-xfree at cygwin dot com
Date: Mon, 02 Jun 2003 21:40:56 -0400
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
References: [EMAIL PROTECTED]
Reply-to: cygwin-xfree at cygwin dot com
I haven't got any ideas. Check /tmp/XWin.log before and after mozilla
crashes. Report any new lines that show up during this period.
Harold
- Original Message -
From: Robert Pang [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 02, 2003 6:24 PM
Subject: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi developers,
I am running XFree 86 for Cygwin (4.2.0 - 37) on Windows 2000. I am
having
problem with Mozilla 1.4 beta running on Sparc Solaris 2.6 and
displayed
in
my XFree 86 running in multi-window mode. Mozilla starts fine.
However,
whenever I click in the address bar to enter a new URL, Mozilla aborts
with
the following error when I click in the address bar.
mozilla ./mozilla
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 17 (X_GetAtomName)
Atom id in failed request: 0xc000
Serial number of failed request: 2467
Current serial number in output stream: 2467
Mozilla running from Linux/x86 doesn't show the same problem and works
perfectly. Any clue what's wrong with Mozilla on Sparc Solaris?
Thanks.
Rob
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Rob,
Welcome to the world of threads. The clipboard manager and window
manager run in their own threads within the X Server process... there is
likely to be a bug in one of those modules or in the supporting modules.
I have no idea which module actually contains the bug at this point.
How prepared are you to help with debugging? I mean, you are in the CS
department at Stanford, so I would expect that you can help us quite a
bit, no? :)
Harold
Robert Pang wrote:
Hi Harold
I update to XFree86-xserv-4.2.0-42 and mozilla still crashes when I click on
the address bar. But it doesn't crash if I do not use -clipboard. So, is
-clipboard the problem? How come I don't have a problem with -clipboard
if mozilla is run from Linux instead?
Thanks.
Rob
- Original Message -
From: Harold L Hunt II huntharo at msu dot edu
To: cygwin-xfree at cygwin dot com
Date: Tue, 03 Jun 2003 13:32:43 -0400
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
References: [EMAIL PROTECTED]
Reply-to: cygwin-xfree at cygwin dot com
Rob,
Please update to XFree86-xserv-4.2.0-42.
I forget... did I already ask you to try this without using -clipboard (you
are using -clipboard, right)? If not, please try this without
using -clipboard and report your results.
Harold
Robert Pang wrote:
- Original Message -
From: Robert Pang [EMAIL PROTECTED]
To: Robert Pang [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 10:09 AM
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi Harold
This is what I see in /tmp/XWin.log from 2 consecutive tries.
GetWindowName - XA_STRING Mozilla {Build ID: 2003052723}
GetWindowName
GetWindowName - XA_STRING Getting Involved with mozilla.org - Mozilla
{Build
ID: 2003052723}
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
GetWindowName
GetWindowName - XA_STRING Mozilla {Build ID: 2003051323}
GetWindowName
GetWindowName - XA_STRING Robert Pang's Web Top - Mozilla {Build ID:
2003051323}
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
GetWindowName
GetWindowName - XA_STRING Mozilla {Build ID: 2003051323}
GetWindowName
GetWindowName - XA_STRING Robert Pang's Web Top - Mozilla {Build ID:
2003051323}
GetWindowName
GetWindowName - XA_STRING mozilla-bin
Thanks.
Rob
- Original Message -
From: Harold L Hunt II huntharo at msu dot edu
To: cygwin-xfree at cygwin dot com
Date: Mon, 02 Jun 2003 21:40:56 -0400
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
References: [EMAIL PROTECTED]
Reply-to: cygwin-xfree at cygwin dot com
I haven't got any ideas. Check /tmp/XWin.log before and after mozilla
crashes. Report any new lines that show up during this period.
Harold
- Original Message -
From: Robert Pang [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 02, 2003 6:24 PM
Subject: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi developers,
I am running XFree 86 for Cygwin (4.2.0 - 37) on Windows 2000. I am
having
problem with Mozilla 1.4 beta running on Sparc Solaris 2.6 and displayed
in
my XFree 86 running in multi-window mode. Mozilla starts fine. However,
whenever I click in the address bar to enter a new URL, Mozilla aborts
with
the following error when I click in the address bar.
mozilla ./mozilla
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 17 (X_GetAtomName)
Atom id in failed request: 0xc000
Serial number of failed request: 2467
Current serial number in output stream: 2467
Mozilla running from Linux/x86 doesn't show the same problem and works
perfectly. Any clue what's wrong with Mozilla on Sparc Solaris?
Thanks.
Rob
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Rob, There is a temporary release of XWin.exe available that watches our for more NULL pointer dereferences. Please try it out and report your results: http://www.msu.edu/~huntharo/xwin/shadow/XWin-Test91-DEBUG.exe.bz2 There are instructions for installing such a binary at: http://xfree86.cygwin.com/devel/shadow/ Thanks for testing, Harold
Re: ooh, ooh! more nitpicking
Jack, Yeah, that is definitely a feature that people getting paid to program would implement. :) I think we have many more fundamental problems to solve before we worry about such issues. Harold Jack Tanner wrote: So I love the fact that my X-forwarded apps now show up in the Alt-Tab list with their proper icons. Except that now there's no way to distinguish at a glance between, say, a Mozilla running locally and a Mozilla running remotely -- they have the same icon. How about this for overloading a simple feature and opening a gazillion cans of worms: the icon shown for each X application in the Alt-Tab list (as well as in the taskbar, for completeness sake), gets it's default icon but with an faint X11-style letter X in the background. This letter X should be visible no matter what my system colors are. As a bonus point, the number of the X display should be embedded next to the X to disambiguate between the same application being shown on different X servers, but this bonus functionality should only be enabled if more than one X server is actually running. Flames to /dev/null; granted, this is a silly idea but it does point out a problem. Additional information could be sought by seeing how other application-forwarding software (e.g., VNC, NetMeeting, PC Anywhere, Citrix Metaframe or their ilk) disambiguate under such circumstances, or if they bother to do anything at all. For those still reading, here's an entertaining note: the citrix.com site currently carries an ad which reads Citrix embraces and extends Windows Server 2003. -JT
Re: ooh, ooh! more nitpicking
Hi-Jack, All the local MS applications should have a big yellow 'M' in their icon foregrounds. remote Macs should have a big red 'X' (OS X only!)), Suns a big 'S', HP's a big 'P' etc. I'm sure they will all oblige and change their icons, after all X came first (or did it?). Post it to their help desks (beware, some charge just to ask a question), they love to change things willy-nilly. Tell them it's in the good cause of 'disambiguation' of remote/local systems via a heterogeneous server. If I can get I copy of the source code I will hack it for them for free, please advise on CVS/pass. Colin
Re: ooh, ooh! more nitpicking
Okay, okay, no need to go overboard. Harold Colin Harrison wrote: Hi-Jack, All the local MS applications should have a big yellow 'M' in their icon foregrounds. remote Macs should have a big red 'X' (OS X only!)), Suns a big 'S', HP's a big 'P' etc. I'm sure they will all oblige and change their icons, after all X came first (or did it?). Post it to their help desks (beware, some charge just to ask a question), they love to change things willy-nilly. Tell them it's in the good cause of 'disambiguation' of remote/local systems via a heterogeneous server. If I can get I copy of the source code I will hack it for them for free, please advise on CVS/pass. Colin
Efforts to make xwinclip/-clipboard not steal the selection [Fwd:[Xoncygwin-cvs] CVS Update: xc (branch: trunk)]
Okay, since the selection stealing by xwinclip/-clipboard probably generates the largest amount of annoying questions on this mailing list, I decided to finally spend a little time trying to redo this properly. I had been meaning to look at Keith Packard's XFIXES extension that was added to the XFree86 CVS last November and was subsequently removed before 4.3.0 was released. Tonight I looked through the pieces that of that patch that added a new type of callback function for selection changes. Callbacks for this can be registered by calling AddCallback... Tonight I applied those few pieces of Keith's code for the selection callback to our SourceForge CVS tree. I also added a file to hw/xwin called winclipboardcallback.c and I added a call in winscrinit.c that registers a callback. Forgive the poor function names... but it is past bed time (you'll know what I mean if you look at the CVS). The code compiles and runs. When the selection changes, it prints a message to the log file via ErrorF. So, we are at least able to detect when the selection changes now. There are two steps that I will be taking next (or appreciating help from others on): 1) Make a few simple changes to the -clipboard functionality that registers a callback for the selection change events. Stop stealing the selection when something in X is copied. This would immediately improve -clipboard since it would no longer steal the selection and it would still support wonderful things like non-ANSI text conversion. 2) Change the clipboard functionality from an X Client to just another set of functions in the X Server. This is possible because we no longer have to wait for the X Client SelectionNotify events, etc., but it may prove difficult to find the X Server interface to the functions that convert selections into the desired format. On the other hand, this may be really easy. I would *really* like to do (1) first, even if (2) were to follow as soon as later the same day. I think that (1) is achievable within 8 hours. I may have something tomorrow. I would appreciate if others would look into (2) in the mean time. Good night, Harold Original Message Subject: [Xoncygwin-cvs] CVS Update: xc (branch: trunk) Date: Tue, 03 Jun 2003 22:06:38 -0700 From: Harold Hunt [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CVSROOT:/cvsroot/xoncygwin Module name:xc Repository: xc/programs/Xserver/include/ Changes by: [EMAIL PROTECTED] 03/06/03 22:06:38 Log message: Add parts of Keith Packard's XFIXES used to notify clients when the selection changes. Only built when __CYGWIN__ is defined. Modified files: xc/programs/Xserver/dix/: dispatch.c xc/programs/Xserver/hw/xwin/: Imakefile winscrinit.c xc/programs/Xserver/include/: dix.h Revision ChangesPath 1.2 +40 -20xc/programs/Xserver/dix/dispatch.c 1.3 +2 -0 xc/programs/Xserver/hw/xwin/Imakefile 1.2 +267 -53 xc/programs/Xserver/hw/xwin/winscrinit.c 1.2 +28 -4 xc/programs/Xserver/include/dix.h --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Xoncygwin-cvs mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xoncygwin-cvs
Possible X-Wndows problem
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. What happened: 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). System Statistics: Pentium-4 3.0Ghz cpu 512MB of memory Standard things like keyboard, optical mouse, scanner, etc Lots of hard drive space (11GB free) Notes: I was not using OpenGL but was rather using the standard X Windows/Motif drawing routines to handle the drawing of the dots. I am thinking that due to the enormous number of times Cygwin had to write a single dot, then update the window, that maybe I ran into some kind of a buffer overflow. I have run my test program and Cygwin does die each time. Usually after a couple of hours. So it takes quite a while to build up to whatever it is that is causing this. I am trying to reduce the overall program down to where I can post the example program but if anyone has run into this before, I would appreciate an e-mail or a post pointing me in the right direction. TIA to whomever answers. Mark
xwinclip patch
What I'm requesting is so simple as this:
--- xwinclip.c.orig 2003-01-13 02:27:22.0 +0100
+++ xwinclip.c 2003-06-04 10:09:18.0 +0200
@@ -362,15 +362,6 @@
exit (1);
}
- /* Assert ownership of PRIMARY */
- iReturn = XSetSelectionOwner (pDisplay, XA_PRIMARY,
- iWindow, CurrentTime);
- if (iReturn == BadAtom || iReturn == BadWindow)
-{
- printf (Could not set PRIMARY owner\n);
- exit (1);
-}
-
/* Local property to hold pasted data */
atomLocalProperty = XInternAtom (pDisplay, CYGX_CUT_BUFFER, False);
if (atomLocalProperty == None)
With this patch, xwinclip works as a Windows user would expect.
With a few lines, I've configured xterm and emacs to copy/paste to/from the clipboard:
~/.Xresources:
*VT100.Translations: #override \
Shift KeyPress Insert: insert-selection(CLIPBOARD) \n\
Ctrl KeyPress Insert: select-set(CLIPBOARD) \n\
~/.emacs:
(global-set-key [S-delete] 'clipboard-kill-region)
(global-set-key [S-insert] 'clipboard-yank)
(global-set-key [C-insert] 'clipboard-kill-ring-save)
Gnome 12, Gvim, and KDE 3 works correctly.
I acknow that there is lots of old applications (KDE12 mainly) that ignores
completely the clipboard, so I will try to rewrite xwinclip as a windows
taskbar app that will allow to copy (at user request) the primary selection to the
clipboard and vice versa.
Good bye!
