Controlling windows in X with wmctrl

2 minute read

Restarting a computer sucks. You have to typing in passwords, starting your windows manager, get all your default applications going and so on. It takes me several minutes to restart a system and get it into a workable state.

Particularly in the last days, I had to restart various times forcefully. A critical error in the intel grahicstack breaks the multi monitor setup. Not working suspend to ram. A half way down suspended system, in which the fan keeps being active while remaining part of the systems is without a responses. Each time a system reset was necessary.

However, i found some useful tool that allows me to ‘accelerate’ the startup by quite a bit. wmctrlis the tool, that was found by browsing through the man page of fluxbox. What’s it? It’s a protocol the X Server is speaking, allowing to ask the Windows Manager for some information and/or actions. It allows you to give the windows manager some commands. Neat. The installation on archlinux was easy:

pacaur -S wmctrl

Why do you need this? Simple: To allow to start up any application in fluxbux and place it on the right virtual desktop. Window Manager like KDE allows you to remember the state of windows before a logout, fluxbox don’t. So when you login again with KDE, all your old windows will be start on the right virtual desktop. But KDE consumes way to much resources…so a solution for fluxbox is necessary.

The man page has all the details one might need to use it. I wrote down an example:

urxvt -title urxvt -e tmux a &
sleep 1
wmctrl -F -r 'urxvt' -t 2

What does this example do?

It starts a urxvt terminal with a define title and within it will start the tmux a to re-attach to an open tmux session. Defining the title allow wmctrl to find the windows to move it to the right virtual desktop. The ID of a virtual desktop can be displayed with wmctrl -G -l command. One thing that did’t work out (yet), was setting the window to fullscreen. You can start urxvt will the paraemter -g with the right size. But this lead to some strange rendering bug and you can’t read anything from the terminal down. wmctrl can do this too. But I didn’t do it yet.

Anyways, this makes a reboot a bit easier. But in the end, reboot sucks.

Some notes about the Stack

2 minute read

Before I begin, we need to clarify what a stack is first. For once, it’s a structure that represent data.

The Stack of a computer can be understood in different matters. Mostly as a way to represent current working chunks of memory a program needs to store it’s local context.

That’s a very strange to write…. Let’s try it again: When a program is executing, it needs to store some of it’s memory somewhere. Memory is allocated in chunks. This chunks of memory will be ‘stacked’.

The importance of this ‘stacking’ is, that once it’s layered down on the stack, it will be buried by the next item. Unless the next item is processed, it remains buried. You need to process the top of the stack, before the next time can be access.

Once you executes a programs, you will get a ESP. However during debugging with gdb, i notice something odd: the BSP keyword. Some search later, I figured out that this was point to the top of the stack. Just like ESP. Now: What’s the different between BSP and ESP?

So when you look at the assembler you will see thing like this:

0x080483c4 <main+0>:	push   ebp
0x080483c5 <main+1>:	mov    ebp,esp
0x080483c7 <main+3>:	and    esp,0xfffffff0
0x080483ca <main+6>:	sub    esp,0x50
0x080483cd <main+9>:	lea    eax,[esp+0x10]
0x080483d1 <main+13>:	mov    DWORD PTR [esp],eax
0x080483d4 <main+16>:	call   0x80482e8 <gets@plt>
0x080483d9 <main+21>:	leave  
0x080483da <main+22>:	ret 

Andrew Honig did a blog post about this topic. I quote:

At ebp is a pointer to ebp for the previous frame (this is why push ebp; mov ebp, esp is such a common way to start a function). This effectively creates a linked list of base pointers. This linked list makes it very easy to trace backwards up the stack. For example if foo() calls bar() and bar() calls baz() and you’re debugging baz() you can easily find the parameters and local variables for foo() and bar().

best regards, akendo