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, orangepri...@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
