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

[Kipling Inscore]

> > 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?

> 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.

> > ICCCM was supposed to prevent that sort of thing but unfortunately it
> > is and only can be an etiquette guide. The window manager doesn't get
> > enough special privilege under X11 to really enforce any particular
> > window behavior.
>
> That's a bummer. One great big bug in X.

Yes, the window manager gets a small amount of privilege (if it
chooses to) only because it's the first to request such. First come
first window manager seems perfectly reasonable--just ensure whichever
you want as window manager is launched before any other crazy app that
wants to get window manager privilege (I don't think there's any
client out there audacious enough to crown itself window manager
unless it is intended to be a window manager in the first place).
The problem is that the window manager only gets a small advantage
over other programs. If it gets some special treatment, why not give
it full control?

> It should be the other way around. The server should be subservient to
> the window manager.
>
> A server, the X server, should _serve_.

The X server was initially written in simpler times. Bullying clients,
I suppose, were not expected.

> > Even if it did there would probably still be
> > control-fight loops where the program asks for something, the window
> > manager refuses, so the program asks again, possibly locking up its
> > interface.
>
> Who would put up with that? The developers would soon find themselves
> with apps that nobody used.

There are already programs that get into control fight loops with real
window managers. At least it's visible and thus obvious what's going
on, I guess.

> >  Really, I think the solution is responsible X11 client
> > programming,
>
> 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.
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.
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.
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. 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 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.

> > > Piss on that. This is my computer. It's like my home. When someone
> > > comes in my home they behave themselves or they leave. I set the
> > > standards for behavior, not some coder somewhere.
> >
> > File bugs with programs that don't follow ICCCM. File bugs with
> > programs that have lame behavior, even if it is "technically correct".
> > Modify programs and send patches.
>
> Or dump them and find something better.

That too. Which I've done for a few programs. Forget which ones. They
weren't worth remembering anyway, obviously.

> 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.