Re: [RP] ... --solved (with my workspace scripts) -Phuk!

[TBlittlefoot]

On Sun, Dec 23, 2007 at 08:00:22PM -0800, Kipling Inscore wrote:
> > > I've been thinking about creating a LibPurple client that will run in
> > > multiple terminals (or in a single split terminal using screen) but
> > > who knows if/when I'll get around to that.
> >
> > Go for it. I'll help test it. Make conference calls possible. And
> > eliminate the need for a server. That way it would be a lot more
> > private. (I guess you'd need a lot of the server code in the client
> > for that, but that code is available under GPL, etc.)
> 
> I'd just make it a libPurple client, so its IM capabilities are a
> function of the loaded protocol plugins. Someone could and perhaps
> already has written peer-to-peer IM for libPurple.
> By conference calls do you mean group text chat or group VOIP?

Yeh. The opposite of IRC: The starting point would be one-on-one with
the option to add others, with the originating party having to
sanction any new participants.

> > But fair warning: If it pops up in my face when someone 'calls' me,
> 
> It most certainly won't. I'd hate that too.
> 
> > it's history. A tiny window in the corner would be okay, but it better
> > vanish when I hit Esc. And no blinking! :-)
> >
> > A console app to run in an xterm would be better than an X app. Less
> > resources and they are never rude.
> 
> I think I would write it to operate on Unix sockets or FIFOs,
> primarily proxied by curses
 or other console apps, leaving
> notifications essentially left for the user to script. I'd probably
> include a script to use ratpoison's echo function.

Excellent.

> > Sorry, but I disagree. The X server should be subservient to the
> > window manager and no application should be able to do anything
> > that the user controlling the window manager doesn't want to happen.
> 
> I think clients should probably be able to draw to their own windows
> (if mapped) and to off-screen pixel buffers without asking the window
> manager. Drawing is a request that has to go to the X server.
> Window managers like ratpoison would have a much easier task if they
> were able to really screen, filter and forward any requests from other
> clients.

Are you sure there's no way to do that? Perhaps a seperate app controlled
by the window manager that intercepted calls to the X server?

(This probably falls under the category of window management theory
[reference to third paragraph below] and is too complicated to go
into here.)

> There would still be lame clients that keep nagging when a request is
> refused, or lamely misunderstand the results of a request to the X
> server or window manager. Programmers are lazy sometimes. Toolkits
> should be written so that programmers have to go out of their way to
> write rude programs.

Yes!

> Sometimes it's better to let a client do what it wants and then revert
> when it's not paying attention. Just from a pragmatic standpoint.
> Hopefully X12 will address some issues of window manager control,
> though. It certainly could be improved.
> 
> Sorry I'm not going to reply to much of the rest of what you wrote,
> window management theory is a rather complicated issue that requires
> more careful thought than I can accomplish in a reasonable time.

Understood.

> Instead I'll try to sidestep the issue with this: we should be glad
> that X11 allows user-created window management at all, unlike Windows
> and OS X.

Indeed. 

> As weird as it may seem, my biggest complaint about those
> systems for practical work purposes is that their interfaces are
> absolute garbage and I can't do a thing about it. Cygwin and Fink just
> don't cut the fat.

I despise Windows. Wouldn't allow it on any computer I control. 

What a piece of shit operating system. Don't know OS X or Cygwin or Fink
at all, but you've given me enough information to allow me to forego
wasting any time with them.

> > > I wouldn't want to introduce unnecessary features into ratpoison but
> > > perhaps it should allow some sort of delegation/scripting for windows
> > > that have requested to be mapped but aren't yet mapped (ie a hook on
> > > maprequest and commands that allow putting an arbitrary window into an
> > > arbitrary group or frame) so that we don't have to script with
> > > xtoolwait and saving/interrupting the user's current setup.
> >
> > Don't know xtoolwait. It doesn't come with Slackware. Can it be used
> > with bash or are you talking about one of the X scripting languages?
> 
> It's been discussed previously on this list. xtoolwait is a simple
> windowless X client which simply executes its arguments and exits when
> the child program creates an X window or exits, whichever comes first.
> To be reasonably confident that certain ratpoison script behavior will
> occur on a particular window, you can write a script like the
> following (this example will launch xemacs and then hide it in a new
> group called "xemacsgroup", theoretically returning you to your
> pre-xemacs state after only flashing the xemacs window):
> 
> xtoolwait xemacs
> ratpoison -c "gnewbg xemacsgroup"
> ratpoison -c "gmove xemacsgroup"
> 
> Better still, however, would be if you never had to see xemacs until
> you were ready to use it. You could dedicate the current frame or
> lower rudeness, but then you wouldn't be able to automatically assign
> the xemacs window to an inactive group.

That looks like a useful tool. I'll find it and play with it.

As for emacs, well, I'm a vi guy. On my box, [x]emacs is aliased to:

echo "Emergency! System Overload! Contact the Authorities Immediately! Code 
Red!" | /usr/bin/wall

:-|

(sorry, couldn't resist)

> > If people quit using rude programs the developers would change their
> > ways in a hurry.
> 
> I think open source developers are more likely to notice bug reports
> and comments in mailing lists than user count, though If a large
> percentage of users switch, that might be noticed.
> 
> > Thanks for the insight into what's going on behind the scenes, Kipling.
> 
> Glad to help. I do what I can. I know what I do about X mostly because
> I wrote a misguided window manager before I realized that strict
> tiling is pretty much the way to go.

It sure is. If you want a rational working environment instead of a 
colorful display to impress the ignorant while you waste time playing
with a plastic rodent trying to find the window that you really want
to use at the moment.

Tom