
Perlwm – a window manager written entirely in Perl - lelf
http://perlwm.sourceforge.net/
======
markstos
... and last updated in 2004.

~~~
lelf
Stable software! Rare these days.

~~~
kalium_xyz
Liked, subscribed, followed on twitter, starred on github, and added on
myspace

------
DonHopkins
Excelsior and Huzzah! This is a match made in heaven! Perl and X-Windows ICCCM
are like two peas in a pod!

[https://en.wikipedia.org/wiki/Pod_People_(Invasion_of_the_Bo...](https://en.wikipedia.org/wiki/Pod_People_\(Invasion_of_the_Body_Snatchers\))

[https://medium.com/@donhopkins/the-x-windows-
disaster-128d39...](https://medium.com/@donhopkins/the-x-windows-
disaster-128d398ebd47)

>As a result, one of the most amazing pieces of literature to come out of the
X Consortium is the “Inter Client Communication Conventions Manual,” more
fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters,
L”). It describes protocols that X clients must use to communicate with each
other via the X server, including diverse topics like window management,
selections, keyboard and colormap focus, and session management. In short, it
tries to cover everything the X designers forgot and tries to fix everything
they got wrong. But it was too late — by the time ICCCM was published, people
were already writing window managers and toolkits, so each new version of the
ICCCM was forced to bend over backwards to be backward compatible with the
mistakes of the past.

>The ICCCM is unbelievably dense, it must be followed to the last letter, and
it still doesn’t work. ICCCM compliance is one of the most complex ordeals of
implementing X toolkits, window managers, and even simple applications. It’s
so difficult, that many of the benefits just aren’t worth the hassle of
compliance. And when one program doesn’t comply, it screws up other programs.
This is the reason cut-and-paste never works properly with X (unless you are
cutting and pasting straight ASCII text), drag-and-drop locks up the system,
colormaps flash wildly and are never installed at the right time, keyboard
focus lags behind the cursor, keys go to the wrong window, and deleting a
popup window can quit the whole application. If you want to write an
interoperable ICCCM compliant application, you have to crossbar test it with
every other application, and with all possible window managers, and then plead
with the vendors to fix their problems in the next release.

>In summary, ICCCM is a technological disaster: a toxic waste dump of broken
protocols, backward compatibility nightmares, complex nonsolutions to obsolete
nonproblems, a twisted mass of scabs and scar tissue intended to cover up the
moral and intellectual depravity of the industry’s standard naked emperor.

>Using these toolkits is like trying to make a bookshelf out of mashed
potatoes. - Jamie Zawinski

[...]

>The color situation is a total flying circus. The X approach to device
independence is to treat everything like a MicroVAX framebuffer on acid. A
truly portable X application is required to act like the persistent customer
in Monty Python’s “Cheese Shop” sketch, or a grail seeker in “Monty Python and
the Holy Grail.” Even the simplest applications must answer many difficult
questions:

>WHAT IS YOUR DISPLAY?

    
    
        display = XOpenDisplay("unix:0");
    

>WHAT IS YOUR ROOT?

    
    
        root = RootWindow(display, DefaultScreen(display));
    

>AND WHAT IS YOUR WINDOW?

    
    
        win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1,
                                  BlackPixel(
                                      display,
                                      DefaultScreen(display)),
                                  WhitePixel(
                                      display,
                                      DefaultScreen(display)));
    

>OH ALL RIGHT, YOU CAN GO ON.

>(the next client tries to connect to the server)

>WHAT IS YOUR DISPLAY?

    
    
        display = XOpenDisplay("unix:0");
    

>WHAT IS YOUR COLORMAP?

    
    
        cmap = DefaultColormap(display, DefaultScreen(display));
    

>AND WHAT IS YOUR FAVORITE COLOR?

    
    
        favorite_color = 0; /* Black. */
        /* Whoops! No, I mean: */
        favorite_color = BlackPixel(display, DefaultScreen(display));
        /* AAAYYYYEEEEE!! */
    

>(client dumps core & falls into the chasm)

>WHAT IS YOUR DISPLAY?

    
    
        display = XOpenDisplay("unix:0");
    

>WHAT IS YOUR VISUAL?

    
    
        struct XVisualInfo vinfo;
        if (XMatchVisualInfo(display, DefaultScreen(display),
                             8, PseudoColor, &vinfo) != 0)
            visual = vinfo.visual;
    

>AND WHAT IS THE NET SPEED VELOCITY OF AN XConfigureWindow REQUEST?

    
    
        /* Is that a SubstructureRedirectMask or a ResizeRedirectMask? */
    

>WHAT??! HOW AM I SUPPOSED TO KNOW THAT? AAAAUUUGGGHHH!!!!

>(server dumps core & falls into the chasm)

[...]

>X-Windows: Even your dog won't like it.

>X-Windows: Complex non-solutions to simple non-problems.

>X-Windows: The First Fully Modular Software Disaster

~~~
nrdvana
You forgot my favorite one! Xlib is written so badly that there is no graceful
way to deal with a connection error to the server - the library gives you one
callback to clean up and then it forcibly aborts the process. I looked into
why, and its basically because they have no provision for cleanup of failed
function calls. If a function can’t return the expected result it would either
leave behind a broken internal state of the library or segfault, so they call
abort() as a workaround.

If not for this glaring design disaster, it would be possible for a program to
attempt re-connecting to a new display server after the previous one crashed.
No X11 program has ever done this only because Xlib made it impossible.

~~~
joosters
Would it be possible to solve this by creating a proxy between the xlib
application and the X server? This proxy could re-issue failed requests, or
reroute them to a different server. Basically, it would be the error-handling
layer, so that all xlib calls always seem to work, from the application's
viewpoint.

As a proxy, it could improve error handling across all X applications without
any application code changes.

~~~
DonHopkins
It would be better for life on Earth as we know it if the proxy simply cut you
off from the X server, forcing you to find a better window system to use. It's
much better to prevent errors from happening in the first place, than to
handle them after they happen.

------
angvp
good old times

------
pearjuice
>sourceforge

I'm glad I haven't used this site in years and I don't plan to change that
today.

