ratpoison-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RP] Re: Ratpoison-devel digest, Vol 1 #248 - 12 msgs


From: Shawn Betts
Subject: Re: [RP] Re: Ratpoison-devel digest, Vol 1 #248 - 12 msgs
Date: Sun Feb 17 12:54:01 2002
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Eduard Werner <address@hidden> writes:

> > > Looks like the best solution so far. After switching to VMware with C-t -
> > > it doesn't get sluggish. (Isn't it funny how one single piece of 
> > > commercial
> > > software can really thoroughly spoil working with computers ...)
> > > 
> > > It still would be interesting to know what's so subtlely different in
> > > rp 1.0.0 and 1.0.1
> > 
> > The difference is when RP gets a ConfigureRequest it doesn't grant the
> > request, instead it insists that the window stay maximized. The
> > problem with this was that some apps with resize increment hints would
> > get caught in an infinite resize loop. So I changed it so RP grants
> > the configure request and then immediately after it maximizes the
> > window again. This seems to work flawlessly with every app I can
> > install on my machine...but VMWare for whatever reason doesn't like
> > it. The best thing would be to look at their source and...oh,
> > right...nevermind :(
> 
> I have some suggestions (mind me, I don't have much programming experience, so
> I might easily say sth silly here):
> 
> 1. I think UNMANAGED_WINDOW_LIST should go away from conf.h but it should be 
> available
>    at runtime like "ratpoison -c exec-unmanaged vmware -vmware-options". That 
> would be
>    more flexible since different users are experiencing different problems 
> with programs
>    they unfortunately can't recompile.
>
> 2. Maybe it would help to have a third thing between managed and unmanaged: 
> managed but
>    unconfigured by ratpoison? These windows would get granted their configure 
> request without
>    maximizing them afterwards again so they could work the way they want. For 
> VMware, RP's
>    old behaviour seems to have been the right thing.
>
> So that seems to make four possibilities which don't even look too 
> complicated to me (feel free
> to correct me):
> 
> 1. managed by ratpoison, configure requests granted, then maximized (the 
> default)
> 2. configure requests not granted, stay maximized
> 3. configure requests granted, not maximized
> 4. unmanaged
> 
> Options 2-4 should be available as exec-variations from the command line as 
> well as
> in .ratpoisonrc, e.g.
> 
> unmanaged "xbiff","xscribble"
> no_configure_requests "VMware Workstation", "squeak"
> no_maximize "xv" # not maximizing might keep xv from distorting the view

All these ideas seem to stem from the problem that VMWare doesn't work
correctly with Ratpoison. Let's remember that VMWare, IIRC, is not
free software. For this reason, I am not interested in introducing
sick hacks into ratpoison just so junk software "works". I am only
interested in VMWare because it may be exposing a bug in ratpoison. 

For this reason I am very sceptical of the above ideas.

I strongly suggest you stop using VMWare. Its nothing but bad news. It
is non-free gateway software: A non-free piece of software designed to
allow you to run more non-free software.

That said, the UNMANAGED_WINDOW_LIST in conf.h should be made more
accessible. But it's just not a very high priority. I'll accept
patches to fix it tho :)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]