Overview

fsp-h is a heavily modified fork of Peter Zelezny's F***ing Small Panel, version 0.7, biased towards use with the blackbox window manager, version 0.70.1 on Linux.

The name, fsp-h, stands for F***ing Small Panel - Hacked.

Features
Rationale
1. Why not add (or why remove)...
2. Why include (or not remove)...
Documentation and Screenshots
Support and bug reports
Changelog
Project History
Downloads
Known bugs
Copyright

Features

Small: ~11k executable, < 1 MB RAM usage.
Correctly handles multiple workspaces
Simple operation: only two things: left click moves focus to the window, raising it if it is not currently active, lowering it if it is, and right click closes the window without any fuss.
Displays a small 24 hour clock in the corner that is visible, but barely takes up any screen space.
Vertically small by default (16 px high, and adjustable in the code) to maximize your useful screen space.
Displays window titles and icons, as you'd expect.
No visual nonsense to waste space, so it can comfortably display over 15 windows at once without feeling cramped.
Sticks to the bottom of the screen to remain easy to use.
Shaded windows shade their text, but iconified windows disappear entirely, in the Blackbox tradition. (See below for a discussion on this)
Nothing else. It does one thing and does it well.

Rationale

Why not add (or why remove)...

Workspace switchers?

Three reasons: 1) Blackbox already has one, in its main toolbar, 2) mouse wheel over the desktop works in Blackbox and is often easier anyway, and 3) I never used it when I had it available on KDE, so I probably wouldn't use it here.

A notification area? (Often incorrectly called a 'system tray')

That is outside the scope of a simple task switcher. There are other specialized programs offering that functionality if you want it, that would do a better job than a quick thing I would hack up. (Secondly, I think they are overused, and I almost never use one myself anyway.) They also waste space that is better spent on holding more tasks.

A quick launch app bar?

No need on blackbox; the root menu does that job better than something I would quickly hack up anyway. Secondarily, they use space that is better spent on holding more tasks.

A start menu?

Same as quick launch. I rarely use them anyway; I usually find it easier to just type the command I want in a quick throwaway rxvt or something.

A right click context menu?

The option I found myself using in a right click menu on systems that offered one was almost always close, so rather than go through the effort to implement a menu on barebones Xlib, I just defaulted right click to go to close without fuss, so I can use it rapidly if wanted. For other tasks, it is easy enough to right click on the window's title bar or use hotkeys anyway.

Moving the panel?

In some systems, you can move the panel to other sides of the screen, but I didn't do this, nor make an effort to make it easy to do with code hacks. There are a few reasons:

I never used that functionality anyway; my muscle-memory is wired to jam the mouse toward the bottom of the screen to use a taskbar.
Most people don't: if they accidentally move the taskbar, they often just find it confusing or annoying.
Anywhere except the top or bottom edge of the screen is a usability nightmare anyway. In the middle makes it hard to click on it (Fitts' Law), and on the sides, the text doesn't have room to be displayed in a reasonable way.

However, if I am requested to make moving it to the top of the screen easier with a quick code change, I'll look into it. No addition of a run-time feature though; I see that as pointless.

Resizablity at runtime?

Like with the above, I never use it, and I don't think most people (willingly) do either, and just find it confusing or annoying when they accidentally do.

A second layer of tasks (double decking?)

Again, this is something I would never use, and the reason is two-fold: 1) it wastes precious screen space, and 2) it makes using the panel much harder, due to Fitts' law. Clicking on the row that is not hugging the screen edge requires more mouse precision than I care to use when switching tasks.
Anyway, if you have that many tasks open for it to become useful, perhaps you should consider opening up another workspace?

I'm unlikely to change my mind on any of those.

Why include (or not remove)...

The clock?: Doesn't blackbox already have one, and doesn't it waste screen space? Well, yes to both of those, but for this one, I felt it was worth it. The clock uses a very small amount of screen space and memory to implement, and my eyes like to look toward the bottom-right side of the screen to see a clock, so I kept it for familiarity and ease on my long-trained eyes.
The right click closes without fuss?: See above. A counter argument might be accidentally right clicking on something and closing it is bad, but once you get used to it, this rarely happens, and programs that don't think you should close them still ask for confirmation anyway (such as a save before closing dialog box), so the actual damage you can do is quite limited.
Window icon pixmaps?: While it is true they eat a few more pixels and bytes of RAM per task, they also provide a pretty good usability boost: it is easier for our human brains and eyes to quickly scan some pictures than it is to scan text or recall the exact position of something. The ease of location the pictures offer is well worth the tiny cost.
Iconified (minimized) windows disappear from the taskbar!: The reasoning from this comes from both personal preference and as a part of the Blackbox way (this is the main reason why I call my taskbar biased towards use with Blackbox). I tend to shade or lower rather than minimize windows I just want to get out of the way, so I rarely encounter this. When I do iconify something, it is because I really do want it to get completely out of my way without actually closing it. Since I want it completely out of my way, getting it off the taskbar is a logical extension to this as well. In blackbox, once something is minimize, you get it back by middle clicking to bring up the workspace menu on the edge of the screen or on the root window; it is easy to retrieve, but out of the way entirely until I want it.

Documentation and Screenshots

Coming later

Support and bug reports

Email me, including 'fsp-h' in the subject line. I'll try to answer your concerns as fast as I can.

Changelog

06 Oct 07: fsp-h 1.0 released to the public; this site written.

April 07: fsp-h 1.0 originally written, put into use by me personally.

Project History

I tried KDE for a while, but it really started to get on my nerves, so I decided to ditch it for a new solution. I used the blackbox window manager on all my other (older) computers, so I figured I might as well give it a go on my powerful main computer as well.

However, there was one thing KDE's normal environment had that I missed in blackbox: a taskbar. So, I set out to find an adequate program to give me the functionality of a taskbar that I used, and little more. I wanted my program to be lightweight, so if I started to like it, I could transfer it to my old computers too.

I came across the fspanel in a link from the Blackbox homepage, and I liked the idea it was doing, but didn't like how it did it, and worse yet, it didn't seem to work very well. I at first abandoned it, trying to find something better, but the search turned up only things that were even worse, so instead, I downloaded fspanel's source, about 1000 lines of C, opened up the netwm spec, and started hacking away.

I did three things with my hacking:

Make it work well on my newer version of Blackbox, hence implementing a chunk of the netwm standard.
Remove functionality I didn't care about.
Customize the appearance and behaviour to be more like what I prefer, and in the process of doing so, refactor the code a little to make it easier to change again later.

In doing so, I still kept the goal of maintaining a tiny, light on memory, and fast executable. I think I succeeded.

However, this does have one small tradeoff: it doesn't read files, so to customize it, you must change the source and recompile rather than change a config file. This is extremely minor, as I altered the source to be even easier to adjust than it was originally.

After a few days, I was done with my changes, and was very happy with it. I've used it as my main panel since then.

Downloads

Tarball. Includes full source code, makefile, and a binary. Type 'make' to recompile. To run the program, just use ./fspanel

Known bugs

Sometimes the clock falls a minute behind; just waiting another minute lets it catchup on its next redraw. Alternatively, switching workspaces also forces the whole panel to redraw, also updating the clock.
After a while, the default app icon seems to disappear. I'm not sure why it does this, but it isn't a big deal; I never miss it when it does.