.
The issue is that I would like to raise windows from within a program
(Emacs to be precise), but it doesn't work with the native window
manager running in multiwindow mode.
Emacs has several nice commands for which I have not-so-nice work
arounds (opening and closing windows). These are:
(raise-frame
), but it doesn't work with the native window
manager running in multiwindow mode.
Emacs has several nice commands for which I have not-so-nice work
arounds (opening and closing windows). These are:
(raise-frame f)
(iconify-frame f)
(decionify-frame f)
(make-frame-visible f)
None of these work
windows from within a program
(Emacs to be precise), but it doesn't work with the native window
manager running in multiwindow mode.
Emacs has several nice commands for which I have not-so-nice work
arounds (opening and closing windows). These are:
(raise-frame f)
(iconify-frame f)
(decionify-frame f
On 6/11/2014 10:50 PM, Patrick Herbst wrote:
On 03 Sep 2011, Jon TURNEY wrote:
On 13/08/2011 19:39, Oliver Schmidt wrote:
as reported in
http://www.cygwin.com/ml/cygwin-xfree/2005-06/msg00072.html
windows are not raised from the Cygwin X Server in multiwindow
mode, if a program wants
I used my patch from 2011 every day for the last three years and it
worked always without any problems. I was also able to incorporate this
patch into the newest cygwin x server running under 64-bit cygwin
without any problems.
See also:
On 03 Sep 2011, Jon TURNEY wrote:
On 13/08/2011 19:39, Oliver Schmidt wrote:
as reported in
http://www.cygwin.com/ml/cygwin-xfree/2005-06/msg00072.html
windows are not raised from the Cygwin X Server in multiwindow
mode, if a program wants to programmatically activate a window
), but it doesn't work with the native window
manager running in multiwindow mode.
Emacs has several nice commands for which I have not-so-nice work
arounds (opening and closing windows). These are:
(raise-frame f)
(iconify-frame f)
(decionify-frame f)
(make-frame-visible f)
None of these work
On 18/12/2012 07:29, Heiko Bihr wrote:
On 17.12.2012 19:38, Jon TURNEY wrote:
On 10/12/2012 19:01, Heiko Bihr wrote:
I think, there is a problem with mouse polling in multiwindow mode
(XWin.exe :0 -multiwindow) in Cygwin/X 1.13.
If a window gets maximized and then minimized, it will receive
On 10/12/2012 19:01, Heiko Bihr wrote:
I think, there is a problem with mouse polling in multiwindow mode
(XWin.exe :0 -multiwindow) in Cygwin/X 1.13.
If a window gets maximized and then minimized, it will receive motion
notify events, whenever the user moves the mouse cursor over the screen
Hi,
I think, there is a problem with mouse polling in multiwindow mode
(XWin.exe :0 -multiwindow) in Cygwin/X 1.13.
If a window gets maximized and then minimized, it will receive motion
notify events, whenever the user moves the mouse cursor over the screen.
To reproduce the problem, please
7 should be relevant for
testing this bug as well. I do not recall testing without desktop
composition enabled for the remote desktop session, and I do not know
whether the issue is specific to Windows 7/Server 2008 R2.
Multiwindow mode works fine, but all other modes draw on the taskbar
R2.
Multiwindow mode works fine, but all other modes draw on the taskbar
instead of in the Cygwin/X window. I have tried various combinations
of settings for the X server, but the behavior is the same in all
cases.
Did you try adding '-engine 1' option to the X server command line?
All
Hi Michel,
On 10/19/2011 11:33 AM, Michel Hummel wrote:
I am a bit late but I will be happy to test this version of XWin.
Could you give me a patched binary version please ?
You can download my currently used version of XWin.exe from:
http://min.us/mgtjlVdju
This version includes
2011/10/21 Oliver Schmidt oschmidt-mailingli...@gmx.de:
Hi Michel,
On 10/19/2011 11:33 AM, Michel Hummel wrote:
I am a bit late but I will be happy to test this version of XWin.
Could you give me a patched binary version please ?
You can download my currently used version of XWin.exe from:
)
{
+/* was: handleNextWindowMessage, but
+this will block in WaitForSomething when
+moving resizing windows in multiwindow
+mode. */
+}
+
+void handleNextWindowMessage(void)
+{
MSG msg;
/* Process one message from our queue */
diff --git a/cygwin/hw
I am a bit late but I will be happy to test this version of XWin.
Could you give me a patched binary version please ?
Regards,
2011/9/4 Oliver Schmidt oschmidt-mailingli...@gmx.de
It's me again ;-)
On 9/3/2011 9:01 PM, Jon TURNEY wrote:
As discussed in the thread [2] various scenarios,
could introduce a similar patch there too ;-) However a patch for
scrollbar option in windowed mode is not as reasonable as in multiwindow
mode, because the static redrawing of the x server makes sense in
windowed mode.
I'm not sure I follow your reasoning here. If we have 'ico' running
there too ;-) However a patch for
scrollbar option in windowed mode is not as reasonable as in multiwindow
mode, because the static redrawing of the x server makes sense in
windowed mode. Only in multiwindow mode the redrawing is strange, e.g.
if you applied my patch minimize redraw events after
On 20/08/2011 23:41, Oliver Schmidt wrote:
the following patch is a quick dirty hack to enable redrawing of windows
while the user moves or resizes the window.
This patch should be seen as experimental proof that this can be done with
only small changes in the source code.
This is fine as a
some additions to my last mail:
On 04/09/11 10:52, Oliver Schmidt wrote:
code and is also necessary for the patch. I think that the recursice
behaviour occurs because changes on the top level windows with native
Windows-API-Calls are leading to native Windows messages that again are
fed into
It's me again ;-)
On 9/3/2011 9:01 PM, Jon TURNEY wrote:
As discussed in the thread [2] various scenarios, e.g. AOT windows,
native windows interleaved with X windows in the native Z order, Windows
with focus-follows-mouse enabled via TweakUI all need testing after
trying to fix this, to
Hi,
in multiwindow mode the modal moving/resizing of windows causes a lot of
redraw events send to the X clients after the userse releases the mouse
button. During the moving/resizing client windows are not redrawn as
long as the mouse button is pressed. But all redraw/resizing events
+moving resizing windows in multiwindow
+mode. */
+}
+
+void handleNextWindowMessage(void)
+{
MSG msg;
/* Process one message from our queue */
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com
Hi,
as reported in
http://www.cygwin.com/ml/cygwin-xfree/2005-06/msg00072.html
windows are not raised from the Cygwin X Server in multiwindow
mode, if a program wants to programmatically activate a window.
I played around and figured out that the problem can be solved by
invoking
Workaround a bug in iiimxcf (assuming the WM_STATE atom exists),
which can cause many Solaris clients to simply fail with a BadAtom
error
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
hw/xwin/winmultiwindowwm.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
Hello,
xwin server crashes in multiwindow mode when launching it with xwin
-multiwindow command (also launching with startx script). The server
is working correctly launched with xwin .
I had the screen log:
$ Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 6.8.99.901-4
Hi,
I am trying to write a program, that when running the X Server in
multi-window mode keeps track of the association between the HWND
value that MSWindows assigns to each window that is created, and the X
Client that owns that window.
Finding X Client that owns an X Window is quite simple,
My apologies,
I was checking the value of the HWND in the window privates too early.
I was checking it before the server calls the MapWindow() function,
which is the function which calls some other functions that in the end
call the actual CreateWindowEx() of MS Windows. The CreateWindow()
Hi,
I'm using Cygwin with the integrated Windows-based window manager as it
is started in startxwin.bat:
run XWin -multiwindow -clipboard -silent-dup-error
The problem is as follows:
- An application initially creates some windows. The newly created
windows occur in foreground one after the
Hi all,
Is there a way to enable the alt-space menu in the Cygwin/X multiwindow
manager? (The window in the upper left which has restore, move, size,
minimize, maximize, and close). Most windows applications enable the
use of alt-space to access that menu, but under multiwindow mode it does
Hello,
I'm running Cygwin/X in multiwindow mode and it works quite fine. However,
if I try to start a Java GUI that uses default lookfeel window decoration
on a remote box, I get the following error in the shell on the remote host
and the application won't start:
---
Xlib: unexpected async
I've recently installed cygwin-xfree 6.8.2.0-1 and
cannot figure out how to get titlebars on my windows.
How is this done?
Thank-you,
Gary
---
~ cat startwin.bat
@echo off
SET DISPLAY=127.0.0.1:0.0
SET CYGWIN_ROOT=\cygwin
SET
PATH=.;%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%PATH%
On Mon, 11 Apr 2005, Gary Taylor wrote:
I've recently installed cygwin-xfree 6.8.2.0-1 and
cannot figure out how to get titlebars on my windows.
How is this done?
Start a window manager. Twm is installed with xorg-x11-bin
but you may also install windowmaker or fvwm2.
REM Windows
, and then do a
'make test', all the tests run as expected, and to completion.
HOWEVER,
when I get rid of .xserverrc and .xinitrc, and then do startx
using native multiwindow mode,
'make test' does not quite work as expected. All color
mappings work, but I have noticed that --deiconify
On Wed, 2 Jun 2004, Stef Simoens wrote:
you can run XWin with -logverbose 3 parameter. This will print some
debugging information to the logfile which may help figuring out why
the cursor disappears.
If you encounter the problem another time, please send me your
/tmp/XWin.log
I
On June 2 Kris Thielemans wrote:
As I already mentioned, occassionally my mouse pointer does not display
anymore. This then happens for all open and new X-windows.
I believe that this problem has been fixed in the source code but has
not made its way into an official build. If possible grab
On Tue, 1 Jun 2004, Tom Sobczynski wrote:
Using the current Cygwin X Server in multiwindow mode (i.e. Windows
native window manager), I get the X pointer when the mouse is in the
menu, toolbar and scrollbar areas of Gnome applications. The problem
goes away when I switch to rootless mode
Using the current Cygwin X Server in multiwindow mode (i.e. Windows
native window manager), I get the X pointer when the mouse is in the
menu, toolbar and scrollbar areas of Gnome applications. The problem
goes away when I switch to rootless mode and run another window manager
On Wed, 2 Jun 2004, Kris Thielemans wrote:
Using the current Cygwin X Server in multiwindow mode (i.e. Windows
native window manager), I get the X pointer when the mouse is in the
menu, toolbar and scrollbar areas of Gnome applications. The problem
goes away when I switch to rootless
you can run XWin with -logverbose 3 parameter. This will print some
debugging information to the logfile which may help figuring out why
the cursor disappears.
If you encounter the problem another time, please send me your
/tmp/XWin.log
I also have the 'dissapearing mouse pointer'-phenomenon.
Using the current Cygwin X Server in multiwindow mode (i.e. Windows
native window manager), I get the X pointer when the mouse is in the
menu, toolbar and scrollbar areas of Gnome applications. The problem
goes away when I switch to rootless mode and run another window manager,
such as metacity
redisplays
only those pixels that have now appeared above where
the line was. The only was to get the entire xterm
back again is to move the entire window above the
height of the line.
Does multiwindow mode make some assumptions about
where the Windows Taskbar is placed? I tried -mwextwm
Hello,
OS: WinXP, Service Pack 1
Cygwin: 1.5.9-1
Cygwin-X11-base: 6.7.0.0-8
Cygwin-X11-bin: 6.7.0.0-4
readline: 4.3-5
I'm having a stange problem with xterm that only
manifests itself when XWin is running in multiwindow
mode. When I launch an either an xterm or rxvt, the
line of the terminal
Ah - got it. Its a problem caused by WindowBlinds.
Tony.
...
Hello,
OS: WinXP, Service Pack 1
Cygwin: 1.5.9-1
Cygwin-X11-base: 6.7.0.0-8
Cygwin-X11-bin: 6.7.0.0-4
readline: 4.3-5
I'm having a stange problem with xterm that only
manifests itself when XWin is running in multiwindow
error and GDI leaks.
MWExtWM's windows cursor and sizing/moving window improvement may
be able to apply to multiwindow mode.
Kensuke Matsuzaki
--
Kensuke Matsuzaki
mailto:[EMAIL PROTECTED]
http://peppermint.jp
I've just CVS commited a 1-line patch for the GDI leak I found
last night. It's actually the same patch Kensuke did a few hours
ago, but it wasn't applied to the MultiWindow files. [I'm not
complaining, I forgot to apply the off-by-one classname fix to
Kensuke's rootless code, too...]
It seems
little speed-up. So I finish
the series of my optimizations to -multiwindow mode.
Of course any enhancement is welcome.
Takuma Murakami
rootless mode I can see from stty that
the terminal speed is 38400, while opening the same terminal from
multiwindow mode I see that the speed is 0 (the same does not happens
for rxvt for which stty always reports 38400).
I've started bash the following ways:
cmd.exe : speed 38400
- xterm.exe
On Wed, 24 Mar 2004, Danilo Turina wrote:
Hey!! I didn't notice it immediately, but now the problem has
disappeared (maybe because the new xterm-185?): speed is now 38400 as it
should be.
But I didn't change anything in xterm. It would probably be something
changed in the environment which
Thomas Dickey wrote:
On Wed, 24 Mar 2004, Thomas Dickey wrote:
On Wed, 24 Mar 2004, Danilo Turina wrote:
Hey!! I didn't notice it immediately, but now the problem has
disappeared (maybe because the new xterm-185?): speed is now 38400 as it
should be.
But I didn't change anything in xterm. It
Hi Takuma,
At 07:56 PM 3/20/2004 +0900, Takuma Murakami wrote:
You give me a good insight to improve Z order handling.
I believe we can approach to better solutions. The attached
is my latest code which should fix all problems on restacking
and a-o-t windows without using fAlwaysOnTop
Harold,
At 07:56 PM 3/20/2004 +0900, Takuma Murakami wrote:
You give me a good insight to improve Z order handling.
I believe we can approach to better solutions. The attached
is my latest code which should fix all problems on restacking
and a-o-t windows without using fAlwaysOnTop
Earle,
You give me a good insight to improve Z order handling.
I believe we can approach to better solutions. The attached
is my latest code which should fix all problems on restacking
and a-o-t windows without using fAlwaysOnTop flag. Could you
try and review this?
Tamuka Murakami wrote...
Hello Takuma,
At 07:56 PM 3/20/2004 +0900, Takuma Murakami wrote:
You give me a good insight to improve Z order handling.
I believe we can approach to better solutions. The attached
is my latest code which should fix all problems on restacking
and a-o-t windows without using fAlwaysOnTop flag.
Earle,
Earle F. Philhower III wrote:
Hello Takuma,
At 07:56 PM 3/20/2004 +0900, Takuma Murakami wrote:
You give me a good insight to improve Z order handling.
I believe we can approach to better solutions. The attached
is my latest code which should fix all problems on restacking
and a-o-t
Earle,
Thank you for your comments and commits. That not only fixes
a-o-t problems but also gives hints for the ongoing restacking
problem. Let me confirm some points to make things clear.
Minimized
always-on-top windows never disappear from in front of other
X windows in all the tests I've
Takuma Murakami wrote:
Minimized
always-on-top windows never disappear from in front of other
X windows in all the tests I've tried.
I can't reproduce this behaviour with release-59. I made two
windows overlapped, set one of them as a-o-t, then minimized
the a-o-t window. The second window was
4.3.0-59 would not have this problem because it does not yet contain
your recent changes to multi-window mode. This problem would only show
up in the CVS builds.
I can't reproduce it with release-59. Maybe I am doing the
tests in a wrong way... Could you point it out?
Yup, try with
Hi Takuma, thanks for your responses!
This is in answer to your two earlier messages...
Tamuka Murakami wrote...
Popups on a-o-t windows are having problems and should be fixed.
Did you fix it without reviving fAlwaysOnTop? I'm interested in
the solution.
Yes, this does not require the
Hi all,
I've been hacking away fixing up the support for always-on-top
mode which seems to have been broken since the upgrades Takuma
did about 3 weeks ago (~v1.1.6.2? of multiwndproc, etc). Minimized
always-on-top windows never disappear from in front of other
X windows in all the tests I've
Earle,
Earle F. Philhower III wrote:
Hi all,
I've been hacking away fixing up the support for always-on-top
mode which seems to have been broken since the upgrades Takuma
did about 3 weeks ago (~v1.1.6.2? of multiwndproc, etc). Minimized
always-on-top windows never disappear from in front of
This just in: Takuma said go ahead and commit both fixes so he can
review them. He says he will be able to respond sometime after four
hours. (He is in #cygwinx on irc.freenode.net now.)
Harold
Howdy,
At 02:05 AM 3/19/2004 -0500, Harold wrote:
Yup, Takuma knew there were bugs, but the new code is so much more
efficient (the old code was performing lots of operations during our block
and wakeup handlers, which get called hundreds of times per second) that I
told him to leave it there
Hello everybody,
it's some time I'm using Cygwin and XFree and I feel very satisfied
with both them.
Until today, I always have used the rootless mode + wmaker (which I like
very much). Anyway this morning I tried to switch to the multiwindow mode.
Having customized the contextual menu
On Wed, 25 Feb 2004, Danilo Turina wrote:
In effect this modification solves the problem for rlogins launched
manually by an xterm, but I does not affect at all commands inserted
into .XWinrc (they look like xterm -e rlogin machine -l user).
I tried several ways to put the speed to 38400 for
Thomas Dickey wrote:
On Wed, 25 Feb 2004, Danilo Turina wrote:
In effect this modification solves the problem for rlogins launched
manually by an xterm, but I does not affect at all commands inserted
into .XWinrc (they look like xterm -e rlogin machine -l user).
I tried several ways to put the
On Wed, 25 Feb 2004, Danilo Turina wrote:
Thomas Dickey wrote:
On Wed, 25 Feb 2004, Danilo Turina wrote:
In effect this modification solves the problem for rlogins launched
manually by an xterm, but I does not affect at all commands inserted
into .XWinrc (they look like xterm -e rlogin
On Wed, 25 Feb 2004, Danilo Turina wrote:
In effect opening an xterm within rootless mode I can see from stty that
the terminal speed is 38400, while opening the same terminal from
multiwindow mode I see that the speed is 0 (the same does not happens
for rxvt for which stty always reports
Alexander Gottwald wrote:
On Wed, 25 Feb 2004, Danilo Turina wrote:
In effect opening an xterm within rootless mode I can see from stty that
the terminal speed is 38400, while opening the same terminal from
multiwindow mode I see that the speed is 0 (the same does not happens
for rxvt
On Wed, 25 Feb 2004, Alexander Gottwald wrote:
On Wed, 25 Feb 2004, Danilo Turina wrote:
In effect opening an xterm within rootless mode I can see from stty that
the terminal speed is 38400, while opening the same terminal from
multiwindow mode I see that the speed is 0 (the same does
This issue has to have something to do with the way that commands are
launched from the .XWinrc menu, since launching an xterm from another
xterm works just fine. Here is the code that launches commands
specified in the .XWinrc menus:
case CMD_EXEC:
if (fork()==0)
{
struct rlimit rl;
On Wed, 25 Feb 2004, Harold L Hunt II wrote:
This issue has to have something to do with the way that commands are
launched from the .XWinrc menu, since launching an xterm from another
xterm works just fine. Here is the code that launches commands
specified in the .XWinrc menus:
case
Thomas Dickey wrote:
On Wed, 25 Feb 2004, Harold L Hunt II wrote:
This issue has to have something to do with the way that commands are
launched from the .XWinrc menu, since launching an xterm from another
xterm works just fine. Here is the code that launches commands
specified in the .XWinrc
On Wed, 25 Feb 2004, Harold L Hunt II wrote:
If the stdin for the menu process isn't a tty, the inherited stdin for
xterm still won't be a tty. Some stty settings can be set for non-tty's,
and some cannot. Usually the differences between xterm and rxvt in this
area are related to
Hi list,
Is it possible to open an x-client without title bar, when using
Cygwin/XFree86 with -multiwindow mode?
When I use -rootless mode with twm, I have 'NoTitle { xclock }' in
my .twmrc and xclock works silently in its corner of screen.
But with -multiwindow mode, xclock gets its title bar
On Sunday 04 January 2004 01:10, Kensuke Matsuzaki wrote:
Hi,
A new window manager XWinWM handles Motif WM Hint and Blackbox hint,
and kicker has no border. XWinWM is based on Hackedbox, and Hackedbox
doesn't use _NET_WM_WINDOW_TYPE atom.
I have to supprot EWMH, but XWinWM has preblem on more
Hi,
i just saw the xfree development page and recognized a missing feature in the
multi window mode, which is is at least interesting for kde, but I assume
also for other x applications.
Currently the server does not handle modal dialogs like expected (currently
modal dialogs are independed
Ralf,
I believe Kensuke's new window manager for multi-window mode does this
(the one that works with miext/rootless). The code is not yet
completely checked in, but check the archives for messages he has posted
pointing to some test versions. You can check out the code for the
server from
Hi,
A new window manager XWinWM handles Motif WM Hint and Blackbox hint,
and kicker has no border. XWinWM is based on Hackedbox, and Hackedbox
doesn't use _NET_WM_WINDOW_TYPE atom.
I have to supprot EWMH, but XWinWM has preblem on more basically
window management (Move, resize, iconify etc). So
Emss == Eric Masson [EMAIL PROTECTED] writes:
Emss I've attached log for normal behaviour and will send a folloup
Emss asa the case reappears.
Done, the only difference is that the laptop is now connected to mains
plug.
Regards
Eric Masson
--
Le neuneu est à Usenet ce que le
Hello,
Setup :
Windows 2000 SP4
XFree86 4.3.0-13
I'm facing the following problem when displaying a remote app on my
laptop.
When I launch XEmacs, the window upper left icon is sometimes set to
XEmacs one but most of the times to the default X one.
When the icon is set to XEmacs, I can't
Eric,
Eric Masson wrote:
Hello,
Setup :
Windows 2000 SP4
XFree86 4.3.0-13
I'm facing the following problem when displaying a remote app on my
laptop.
When I launch XEmacs, the window upper left icon is sometimes set to
XEmacs one but most of the times to the default X one.
Sounds to me like
Harold == Harold L Hunt, Harold writes:
Hello Harold,
Harold Sounds to me like most of the time the MultiWindow window
Harold manager (-multiwindow) and the integrated clipboard manager
Harold (-clipboard) are failing to startup. This causes the icons to
Harold be left as the default icon,
I found your thread on the Multiwindow/xwinclip problem with Mozilla, etc.
(running on Solaris, displaying on Cygwin XFree86 on Win200).
Thanks for the tip. Removing the -clipboard option stopped my crashes (I
was crashing while running netscape -edit, or the Mozilla/Firebird
equivalent). I
The multiwindow manager does presently not respect the hints that apps like
xterm or emacs give as to valid window sizes. This can cause xterm to have
ugly leftover smudges on the right edge of the window and other minor
little annoyances.
The attached DIFF -U3 patch against test93 adds support
Earle,
This is great! Just yesterday, while investigating the crashing upon
copying a large amount of text, I was resizing xterm to make it really
large and noticed that the window quite often got a size that chopped
off the last line of text or left a gap after the last line of text. I
test series 91 of the xserver but LyX keeps crashing in
multiwindow mode on the lap-top. ( I have not installed the test series on the
desktop).
Thank for very good software (, which helps me produce my Ph.D thesis.)
jorgen
Harold L Hunt II wrote:
Is this in the latest XF86 tarballs available from their development
server? I haven't had time recently to do code hacking, but with any luck
that'll change soon.
I think the tarballs tend to be out of date.
There are two sorts of tarballs. The regular
good idea to try to reimplement rootless/multiwindow
mode using their toolkit, or at least to add a new mode that uses the
toolkit.
Probably the nicest feature of the toolkit is that it tells the fb layer
that each window has its own framebuffer (which they do) so that expose
events on windows
converted to use this toolkit. It
would be a very good idea to try to reimplement rootless/multiwindow mode
using their toolkit, or at least to add a new mode that uses the toolkit.
Probably the nicest feature of the toolkit is that it tells the fb layer
that each window has its own framebuffer
.
The Cocoa code for XDarwin was recently converted to use this
toolkit. It would be a very good idea to try to reimplement
rootless/multiwindow mode using their toolkit, or at least to add a
new mode that uses the toolkit.
Probably the nicest feature of the toolkit is that it tells the fb
layer
Hi Harold,
Harold L Hunt II [EMAIL PROTECTED] writes:
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:
That's the way I like it, JIT-fixes ;-)
I had started to get crashes with the new Emacs I
Benny,
Okay, I will release this debug version as soon as I get a chance.
Thanks for testing,
Harold
Benjamin Riefenstahl wrote:
Hi Harold,
Harold L Hunt II [EMAIL PROTECTED] writes:
There is a temporary release of XWin.exe available that watches our
for more NULL pointer dereferences.
Hi Harold,
Harold L Hunt II [EMAIL PROTECTED] writes:
Okay, I will release this debug version as soon as I get a chance.
Cool.
BTW, I forgot to mention that the icons are *much* better now, that
bit also works.
so long, benny
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
- 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
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
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
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:
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,
1 - 100 of 134 matches
Mail list logo
