I just want to clarify one more time what “bmpanel2 theme” means and why there are a lot of “no”s about it. People tend to understand bmpane2 themes as let’s say gtk2 themes, but these two are completely different concepts. Gtk2 themes are what I call “skins”, they define a big amount of rules of how you should draw elements and an end user feels free to compose these elements in any way he/she likes. On the other hand bmpanel2 theme is a kind of a snapshot of what you see when you start bmpanel2, and you can’t actually change a lot of look without changing a theme file. The problems come when you have to give people an ability to customize things. For example: user doesn’t want to see a paricular widget on his panel at all, what he/she can do about it? The correct answer here is to change a theme file the way he wants. But is that involve editing text files? Yes and no. Theoretically it is possible to create an utility which will make all you need just in two clicks. The only reason why it is not possible to make that kind of feature inside bmpane2rc is that you just can’t know what is inside a theme to control it flawlessly. There are cases when theme has multiple instances of a widget, how can you tell bmpanel2rc which ones should be removed?

The second conceptual problem is addressing customizable widgets. For example: user wants to have two launch bars, what he/she should specify inside the bmpanel2rc? Frankly, I have no idea. Well, maybe it should be possible to just use two and more launchbar entries and let them be configured sequentially. I mean first launchbar widget uses first launchbar entry in bmpanel2rc, second uses second entry and so on. The other good example here is a “start button”. Let’s say we have a widget that allows you to call just one application you like and we have a theme where this widgets looks exactly like “start” button with literally text label on it. How one should specifiy which app he/she needs to see running when clicking that button? Again, I have no idea.

So, until I will find some interesting concepts here, I will not do anything about these problems. Sorry.

Eventually I would like to see the bmpanel2 as a platform for making “looks” that can be customized in a way theme author wants/allows and not more. I really have a strong opinion that this is a way to go in GUIs. But of course I don’t want to end up with themes being fully featured scripts.

P.S. Sorry for not working on launch bar configurability for a while (gaps between items, background, etc.). I know I promised this, but I’m a bit in a not very good mood right now. 😀

Alternative widgets system and Pager widget were uploaded to the upstream git tree. There will be more updates however in a code and in the Bmpanel2 Theme Reference. Currently you can try it out using xsocam-dark theme and bmpanel2cfg utility (section “Alternatives”, select “pager”).

Currently I just want a desktop switcher like you’ve probably seen in other panels. I mean that one with mini-screens and window previews. As someone in comments on code.google.com had noticed – it will be more practical than the current one. First of all there are window previews, which is basically nice, but I will be able to draw small numbers (representing number of apps of course) on the corner of these mini-screens also using some kind of unintrusive policy – when there are no windows on the desktop just don’t draw any kind of numbers (e.g. zeros).

But let’s get back from the dreamland. I need a way to implement it somehow. There are two major ways to do this:

Implement alternative widgets system as I planned before.

Replace current desktop switcher with a new one.

And I really don’t like (1). Because there are a lot of problems with that. Current theme is just a description of how panel will look like when you’ll start it. Even though most of the users still think of themes as skins, they are not. Introducing alternative widgets on the other hand will break all this picture and make it even more unclear. Themes concept will basically stuck between “theme” and “skin” (in my mind – “theme” is a consistent/seemless look of something, while “skin” is a collection of elements which can be placed and composed in different ways). (2) on the other hand is extremely easy to implement. Due to multimonitor implementation I’m already tracking windows’ position/size. All I need to do is just make a theme description of new desktop switcher elements and simply put the drawing code in. But (2) also forces me to fix all themes according to new widget, which is a big task for me as a programmer (who is obviously isn’t an artist).

First of all, I’d like to start from bugs that were fixed (or at least I think they were). There was a bug with clock text and I thought it was fixed long time ago, but it wasn’t. In this patch set I did few more updates to that code and now, finally, I think it works fine. Please, if you see this glitch again after the update, let me know.

And now let’s talk about multihead support. Basically I decided to fully implement xinerama/xrandr dependent functionality and here how it works:

There are a lot of words: Xinerama, XRandR, TwinView, etc. but almost all of them about the same. Technically, all I need to know about your system is how many monitors you have and what their geometry/position are. I can use two X extensions to retrieve that kind of information: XRandR or Xinerama. I prefer Xinerama (CMake option: BMPANEL2_FEATURE_XINERAMA) currently, and XRandR is disabled by default (CMake option: BMPANEL2_FEATURE_XRANDR). Yes, I know that Xinerama is declared as deprecated, but currently I think it works well even when your system is configured with XRandR. However, bmpanel2 coded in a way that it can use both, just enable them both if you want. But still, preference is given to the Xinerama and if it is enabled on your system it will be used instead of XRandR (unless you have disabled Xinerama completely of course). So, if something went wrong, try ON/OFF these options (you can do it using cmake command line like that: cmake -DBMPANEL2_FEATURE_XRANDR=ON -DBMPANEL2_FEATURE_XINERAMA=OFF).

There is a problem with “strut” thing. If you’re interested in details read NETWM standard (just search for “strut” there). As user all you want to know that it is a bad choice to place the bmpanel2 between monitors (for example if you have one monitor on top of another). If you do, your windows will cover the panel in the maximized mode. It’s because standard currently doesn’t allow to deal with this situation properly. In other words – panel should stay on the edge of the combined virtual screen. If you still don’t know what I’m talking about, see this image showing hypothetic monitors array (green are good positions, red are bad positions, blue are monitors):

The next issue is Window Managers. I checked few, and here is the list of working ones: Openbox, Fluxbox, Xfwm4. These are not working properly: IceWM, PekWM. I guess my priority is standalone window managers like Openbox and PekWM, but in that case I can’t do anything about PekWM, ask its authors to implement full support of a _NET_WM_STRUT_PARTIAL and proper work with multiple monitors (e.g. maximizing windows accordingly). Also there are few minor differences in WMs behaviour, for example some of the WMs keep sending window position changes while you’re moving a window (IceWM, PekWM, Xfwm4), others send these notifications only when you have released a window (Openbox, Fluxbox) and it affects panel in a way that tasks move on another monitor only when the panel is being notified that windows had been moved. But that’s a minor issue I guess.

And finally, the User Guide or what you need to know as a bmpanel2 user. First let’s see a brief list of changes:

Bmpanel2 now doesn’t take into account the current workspace bounds. It means that you can’t stack panels one on top of another anymore. This feature was a hack and isn’t described anyhow in the NETWM standard. Maybe It will be back in the future.

Clock text bug fix (was mentioned in the beginning of the post).

Added new option to the bmpanel2 config and bmpanel2cfg utility: monitor. It allows you to specify on which monitor bmpanel2 should reside (starting from 0). Currently it isn’t possible to span bmpanel2 across monitors (well, unless you have disabled XRandR and Xinerama code completely).

Added new command line option to the bmpanel2: –config. Which allows you to override default config file. I recommend you to use full paths here always.

Now it is possible to specify the config file path in the bmpanel2cfg as a first command line argument when you’re running it (for example: bmpanel2cfg /path/to/non/default/configrc). It is used in pid (process id) searching algorithm. Basically it check if there is a running panel that was started with that config file as an argument and uses it as a target to send reload requests to. With this feature it is possible to use bmpanel2cfg with different instances of bmpanel2.

New cmake build options (these are booleans): BMPANEL2_FEATURE_XRANDR (off by default) and BMPANEL2_FEATURE_XINERAMA (on by default). They were described above.

Added new option to the bmpanel2 config and bmpanel2cfg utility: task_visible_monitors. You should read it as: Task is marked as visible if it is located on one of these monitors. This option basically a string of space separated numbers (for example: task_visible_monitors 0 1, means that windows from the first and the second monitor will be shown as tasks on the taskbar). There is one restriction however, current maximum number of monitors which this option can handle is 32. If anyone has X11 and bmpanel2 running on more that 32 monitors, please send me a photo of your *uhm* array of monitors and I will fix it for you immediately ;-).

New taskbar task visibility logic. By default taskbar shows only tasks from the current monitor (specified by monitor option). But you can customize this behaviour using task_visible_monitors option as described above.

Ok, now what you need to do to start these things up. I will show you on a two monitors example. Let’s suppose we have monitor 0 and 1 (in terms of bmpanel2):

1. We need to copy a usual bmpanel2 config file for a second monitor:

cp ~/.config/bmpanel2/bmpanel2rc ~/.config/bmpanel2/bmpanel2rc_mon1

2. Then open if with your preferred text editor (I use vim):

vim ~/.config/bmpanel2/bmpanel2rc_mon1

3. Add the monitor option here at the end of the file:

monitor 1

4. Now you’re ready to run:

bmpanel2 &

bmpanel2 --config ~/.config/bmpanel2/bmpanel2rc_mon1 &

Also of course you can modify a theme in this second config file. Or even copy a theme to your ~/.local/share/bmpanel2/themes dir and modify/rename it slightly. For example you might want to remove some widgets from it and/or change the position. If you want to configure your second panel instance with bmpanel2cfg, just use it’s config file as a first argument for bmpanel2cfg utility: bmpanel2cfg ~/.config/bmpanel2/bmpanel2rc_mon1. But don’t forget that it is the shell what changes the “~” to your HOME directory. If you want to add the bmpanel2cfg to let’s say a launch bar, you should use full path (e.g. bmpanel2cfg /home/nsf/.config/bmpanel2/bmpanel2rc_mon1).

And at the end I’d like to say that currently bmpanel2 isn’t actively developed. I’m making changes when there is something that I don’t like, so don’t be mad at me because I’m refusing to implement your feature. But I like to fix bugs, because they are quite challenging and interesting tasks by themselves. Some bugs are much harder to fix than another, so it may take time. Well, that is all I wanted to say. Happy bmpanel2 using.