On Mon, Jan 14, 2002 at 09:25:16AM -0500, Dan Espen wrote:
> "Dmitry Yu. Bolkhovityanov" <[EMAIL PROTECTED]> writes:
> > On Wed, 9 Jan 2002, Dominik Vogt wrote:
> >
> > > > > If I remember, one of the complaints about the server grab is
> > > > > that xmms stopped playing.
> > > >
> > > > That was the easiest-to-reproduce example I could think of.
> > > >
> > > > > You might consider filing a bug report with the xmms folks.
> > > >
> > > > Not a bad idea...
> > >
> > > This is *definitely* an xmms bug. It is perfectly legal for any
> > > application to grab the X server at any time, although it should
> > > be released as fast as possible. Running tasks that work in real
> > > time in the same process/thread as X11 calls is simply stupid. If
> > > we'd fix that in fvwm there are thousands of other programs that
> > > can potentially cause similar problems.
> >
> > Just for a record: RealPlayer for Linux also has this bug. I've
> > looked through the Preferences dialog, and it doesn't seem to have a
> > "play in separate thread" flag, while the program runs as several
> > processes. Probably just a bad coding. The version is 8.0.3.421,
> > linux-2.0-libc6-i386-gcc2.95. I don't think that filing a bug report to
> > Real would help anything.
>
> Hmm, I forget who the original poster here is.
>
> Anyway, "tcd" seems to keep playing while wire-frame resizes
> are being used, even through the xterm stops updating.
>
> I don't see why Real wouldn't want to fix their product.
Triggered by that discussion I tried how various systems react
when a new window is mapped while a window is being moved:
Kwm
- wire frame: window is mapped after move completes
- opaque: window is mapped immediately
A popular operating system by M$
- opaque: move operation is terminated immediately and the
new window is mapped
- wire frame: didn't try
Mac OS 9
- wire frame: freezes whole system until motion ends
- opaque: didn't try
Fvwm
- opaque: window is mapped after move completes
- wire frame: window is mapped after move completes
I think fvwm's behaviour is not optimal. Fvwm could handle a lot
of events even during opaque window motion. The only problem I
can see is that a newly mapped window might have to be placed
manually.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
