Re: [dev] SGI Irix look (4Dwm)

From: Peter Hofmann <suckless-dev-list_AT_uninformativ.de>
Date: Wed, 22 Oct 2014 20:01:22 +0200

Hi OP,

yeah, I read your posting on the list. I was curious to see what others
suggested on this topic. Unfortunately, the discussion went off-topic
pretty soon. :-/

I'm still replying on the list, though, because I think that this
explanation might be interesting for others.


On Wed, Oct 22, 2014 at 03:08:14PM +0000, orangeprince_AT_hushmail.com wrote:
> I was wondering -- is there any chance you'd be willing to help me
> make an IRIX 3.3 theme for fvwm?

I assume you're talking about dwm. :-)

I'm pretty sure my code could be changed to make it look like you wish.
Currently, it looks like this:

http://www.uninformativ.de/gal/desktop/2014-07-16--dwm-titlebars.png

The problem is, my code is just "wrong". Yes, it works -- mostly. But
it's incredibly complicated and leads to complications with some
applications (Chromium for example).

To give you some more background information:

Vanilla dwm is a so called "non-reparenting window manager". This means
that dwm manages each window *directly*. Suppose you open some windows,
then the "window hierarchy" looks something like this:

    root window
    |-- firefox
    |-- galculator
    |-- xterm
    |-- xterm
    `-- xterm

As you can see, each window is a child of the root window. When you tell
dwm to move a window, it just moves that particular window. Pretty
straightforward, right? Now, there's a second class of window managers:
reparenting window managers. With those, the window hierarchy looks like
this:

    root window
    |-- frame
    | `-- firefox
    |-- frame
    | `-- xterm
    |-- frame
    | `-- xterm
    |-- frame
    | `-- xterm
    `-- frame
        `-- galculator

Now, each window has a parent window -- a frame. This frame contains the
actual window decorations. A frame window is created by the window
manager, not by the application itself. When you resize or move a
window, the WM has to move the actual window, plus its frame. When you
close a window, the WM has to close the frame as well. And so on.

You might ask: "If you need a frame in order to draw window decorations,
then how does dwm-vain draw decorations?" First of all, dwm-vain is
still NOT a reparenting WM! It's a non-reparenting just like vanilla
dwm. And that's the problem.

If you don't create a frame window, then there's only one place left for
you to draw decorations on: The window's "border". Every common X11
window has a border, although it can be set to a width of 0 pixels.
Problem with borders is that they extend equally in every direction. Let
me illustrate.

First, a window with a border of 0 pixels:

   +------------+
   | actual |
   | window |
   | contents |
   +------------+

Now with a border of some pixels:

   +------------------+
   | |
   | +------------+ |
   | | actual | |
   | | window | |
   | | contents | |
   | +------------+ |
   | |
   +------------------+

Still pretty straightforward, eh? :-)

Vanilla dwm uses this border in a very simple way: It fills it with a
color. Depending on whether the window is focused, it's a different
color. There's a patch that introduces a third color which is used when
the "urgency hint" is set on a window:

http://dwm.suckless.org/patches/urgentborder

Okay. Instead of filling the border with a color, you can also draw
arbitrary pixels on this border. This can be used to make dwm look
something like this:

http://www.uninformativ.de/gal/desktop/2014-06-12--dwm-more-elaborate-pixmaps.png

Up until this point, I'd say: "Okay, the code is a little hacky, but
it's kind of okay." Here comes the dealbreaker: You can NOT do the
following with plain X11 borders:

   +------------------+
   | |
   | some extra space |
   | for a title bar |
   | |
   | +------------+ |
   | | actual | |
   | | window | |
   | | contents | |
   | +------------+ |
   | |
   +------------------+

Because, remember, a border extends in each direction equally. You can
only specify a window border of "5 pixels" -- not "5 pixels to the left,
10 pixels on top."

How the hell is dwm-vain able to draw title bars on the border? Well, it
uses the SHAPE extension to cut off parts of the window. And that's what
makes it so utterly bad. Don't do this. A window manager should not
interfere with the shape of a window because the application itself
might also want to set the shape. Plus, the shape extension might not
even be available (it usually is because it's been around since 1989 but
you never know).

In reality, the actual border of dwm-vain looks something like this:

   +--------------------------+
   |### ###|
   |### ###|
   |### ###|
   |### +------------+ ###|
   |### | actual | ###|
   |### | window | ###|
   |### | contents | ###|
   |### +------------+ ###|
   |### ###|
   |##########################|
   |##########################|
   +--------------------------+

All the parts with "#" are CUT OFF by the shape extension.

I'm pretty sure that most people on the list will agree on this being
just plain crazy. :-) It's a hack, it's ugly and it's anything but
suckless.

I won't go into further detail. This causes many, many problems. The
only reason why dwm-vain still has these kind of borders is that I don't
find the time to either turn dwm into a reparenting WM or write a
reparenting WM from scratch.

To sum it up: If you want to draw (asymmetrical) window decorations,
write a reparenting window manager.

I hope you understand why I'm a bit reluctant to help you add these kind
of borders into your dwm. Sorry. :-|

Cheers!
Peter
Received on Wed Oct 22 2014 - 20:01:22 CEST

This archive was generated by hypermail 2.3.0 : Wed Oct 22 2014 - 20:12:08 CEST