I’m running fvwm2 on FreeBSD. I have a very simple desktop that has nothing on it apart from a wallpaper and a clock. The wallpaper is rendered by feh.
I prefer an analogue clock and have been using tclock for a while: this works well generally as it has a transparent background and by specifying its style thus:
it does pretty much what I want, except that the graphics aren’t that great: the fingers are quite thick and go into zigzag lines as they move around the clockface. I’ve looked around at other options and for a stand-alone clock that doesn’t need a panel or a dock or whatever, cairo-clock looks the best. However, it won’t run, it complains that I don’t have a compositing window manager.
I have sort of solved this by adding xcompmgr to my init function.
However, whereas under the old setup (tclock, no compositing) the clock blended nicely into the desktop, this no longer works.
cairo clock runs but is surrounded by a border (though not a title) and within the border the background is shaded heavily so it almost looks grey. If I try running tclock it does not have a border but still has a darkened square background around it.
This is clearly something to do with xcompmgr. I have already solved some issues by switching from qiv to feh for the wallpaper as qiv failed to repaint areas after windows got closed.
As far as I know, cairo-clock uses a 32-bit ARGB window visual to achieve transparency, while older X applications typically use X Shape extension to define a non-rectangular shape for the window, then all area outside the shape is rendered as transparent. (I’m not completely sure about tclock since I couldn’t find the program… I only see xclock.) The benefit of using ARGB visual is you could have more fancy effects, e.g. semi-transparent areas, and is much easier to handle (with X Shape extension, you define a non-rectangular shape with a lot of rectangles, and the union of all those rectangles is the “shape” you define for the window, which is quite tricky to use). Unfortunately, beauty comes usually at a cost: a compositor is generally required for rendering windows with ARGB visual . Without a compositor, X just disregards all alpha channel, so all the transparent areas will be rendered opaque – generally, fully black. (Many applications combine a shape defined with X Shape extension and ARGB visual to achieve an acceptable effect even without a compositor. Yet, the author of cairo-clock isn’t doing this.) That’s why cairo-clock doesn’t work without a compositor.
ARGB visual has yet another issue that, as far as I can tell, there’s probably no way to tell its shape – okay, without inspecting all pixels one by one with huge loss in performance. I’m not personally aware of any compositor that could detect the shape of an ARGB window, at least. They usually draw a rectangular shadow for all ARGB windows. So, maybe you can’t blame xcompmgr for this.
Therefore, I don’t think it’s possible to draw a round shadow for the window (unless cairo-clock do it itself), and the sole solution I could see is to disable shadow for the window:
[list]
[*]If you have some reasons to stick with the buggy xcompmgr, well, there’s a workaround that make use of a bug in xcompmgr-1.1.6. All ARGB windows created before xcompmgr-1.1.6 is launched will be displayed with no shadow. So you could launch xcompmgr, wait for a second, launch cairo-clock, wait for a second, kill xcompmgr and restart it.
Another possibility is to hack cairo-clock’s source code, so it uses _NET_WM_WINDOW_TYPE_DOCK as its window type, then use -C option of xcompmgr to disable shadow on it.
If you are not particularly loyal to xcompmgr, there are other some standalone compositors around: cairo-compmgr and compton both support painting shadow.
cairo-compmgr: I don’t know if it’s possible to disable shadow on a particular window with cairo-compmgr. Somehow, cairo-compmgr segfaults forever here (Gentoo). I don’t know if builds on FreeBSD.
compton: compton is a fork of xcompmgr with various additions and bug fixes, including a matching system that could be used to disable shadow on arbitrary windows based on user-defined rules. (Well, but please make sure you are using a sufficiently new version of it. Directly building from the git repo is recommended.) To paint shadow on all other windows but cairo-clock, you could use:
A little bit of extra information: if I launch cairo-clock from the command line rather than from my config script it still puts a square border around the clock but within the square, the background is not greyed out - it’s the underlying wallpaper as it should be.
I could live with launching it this way if I could get rid of the border.
In answer to you comments, I have no loyalty whatsoever to xcompmgr, I’d never even heard of it before yesterday. I’d be happy to try compiz, I didn’t know it would work with fvwm. Is there a howto anywhere? I get the feeling from looking at these forums that many fvwm users don’t really “approve” of compositing managers. There’s probably a linux wiki somewhere.
Finally, a bit of background information: I teach computer science undergraduates and I try to get them to experiment a bit more: it can be hard enough to get them to move from Windows to Linux, and to then try to get them to be a bit more adventurous than something like Ubuntu or Mint is seriously tough. I encourage them to try fvwm partly because I think learning to edit config files is good for them, and partly because I think it’s good for them to see that you can have a totally customized setup. But, they think my desktop is boring, so I’m trying to make it look a bit more exciting. I’ve started with the clock and I’d like to make background windows transparent. I want to do all this while keeping my basic config, so I don’t just want to use somebody else’s theme or move to fvwm-crystal, say. Hence what probably seems like a lot of trouble to tell the time when I could look at my watch, plus the overhead of running a compositor only for a different clock face.
I think the border is the business of fvwm. xcompmgr can’t paint borders. I found either of those two lines effective to remove the border:
# Explicitly remove the border from cairo-clock window
Style "cairo-clock" BorderWidth 0, HandleWidth 0, !Title
# Or let fvwm respect _MOTIF_WM_HINTS, which cairo-clock sets, to stop decorating it
Style * MWMFunctions, MWMDecor, HintOverride, OLDecor
The “grey out” thing is the shadow xcompmgr paints. xcompmgr-1.1.6 internally doesn’t paint shadow for ARGB windows, yet there’s a bug that causes it to paint shadows on ARGB windows sometimes.
Actually xcompmgr is one of the most broken compositors you will ever see. A lot of glitches and known memory leaks, because it’s written as a sample compositor for X by the X developers.
Huh, “I’d be happy to try compiz”? Is it “Compiz”, or “compton”, that you are trying to indicate? “Compiz” does not work with fvwm, because it is a standalone window manager, equivalent of fvwm. “Compton” is a standalone X compositor that is designed to cooperate with another window manager, like fvwm.
If you are asking a howto of Compiz, the standalone window manager that cannot work with fvwm, you could install Compiz directly in FreeBSD, then use .xinitrc or your display manager to launch it, just like how you launch fvwm.
If you prefer installing from the git repo, please firstly make sure you have the dependencies. A list of those packages on FreeBSD:
# The standard X libraries, which you already have
x11/libX11
x11/libXcomposite
x11/libXfixes
x11/libXrandr
x11/libXdamage
x11/libXext
# The libraries you probably already installed
graphics/libdrm
devel/dbus
devel/pcre
graphics/libGL
devel/gmake
# The packages that need special attention
textproc/asciidoc
textproc/docbook-xml-450
devel/libconfig
Then, just clone from the repo and build it normally:
# Clone the repo
$ git clone git://github.com/chjj/compton.git
$ cd compton
# (Optional) You may wish to switch to `richardgv-dev` branch, which contains the experimental OpenGL backend
$ git checkout richardgv-dev
# Build it! Note FreeBSD's gcc-4.2 does not work without this patch: https://github.com/DachiChang/arkports-9.1/blob/master/compton/files/patch-c2.h
# So either you need to apply the patch, or use clang (which is pre-installed in FreeBSD 9) to build it:
$ CC=clang gmake -B
# Now you could actually run it.
$ ./compton --config compton.sample.conf -c --shadow-exclude 'g:e:Cairo-clock'
# (Optional) compton.sample.conf in the tree is a sample configuration file, you may copy it as the default configuration file
$ cp compton.sample.conf ~/.config/compton.conf
# (Optional) Build man pages, etc.
$ make docs
# (Optional) install it to /usr/local
$ make PREFIX=/usr/local install
You may look into the man page for problems related to configuration.
Using a compositor is just a personal habit. A few years ago I was a fan of Compiz. Then I wanted to try something harder, so I went to Openbox and eventually fvwm, without a compositor. Half a year ago I accidentally met compton and got addicted. Many experts probably don’t like compositors, but I found composition improving my productivity, by letting me look and operate through semi-transparent windows (I use the -i option in compton) so I don’t have to raise and lower all those windows frequently with my small screen.
Actually the most exciting desktop usually comes from Compiz. The numerous fancy effects Compiz provides look way more attractive than compton. I hope compton could at least make your desktop more attractive than no compositor at all, though.
Since I still don’t know whether you are talking about “Compiz” or “compton”… Well, just in case you don’t know those: generally one configures Compiz via ccsm, the graphic configuration tool, and Compiz means you can’t use fvwm, so I’m afraid Compiz will not be helpful if you wish to make your students more Unixish. compton is configured mostly with commandline arguments and a somewhat-.ini style configuration file.
In terms of overhead, if you have an average computer and an average graphic card (anything better than VIA IGPs), and you don’t do complicated OpenGL/OpenCL tasks or play games, the overhead of neither compositor shouldn’t be a big concern. On low-end systems or if you have an extreme attitude about this, compton might be a superior choice. We have users using compton on Raspberry Pi.
Regarding “make background windows transparent”, you could achieve this with compton’s -i option, like compton -i 0.7. With Compiz, well, I don’t need to explain.
I have successfully installed compton on my laptop and I’m enjoying experimenting with it. I have not used git before so probably not doing something correctly, but I could not see any way of using Danchi Chang’s script so installed by following your instructions. Trying the richardgv-dev branch caused compilation to fail, but if I missed this out everything worked fine.
Because it went so well I decided to try it on my desktop machine too, but ran into problems here. Following exactly the same procedure, and having first made sure all the necessary packages are installed, the compilation goes ok but fails at the linker stage with the following error message:
compton.o: In function `get_cfg':
src/compton.c:(.text+0x9968): undefined reference to `config_set_include_dir'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
gmake: *** [compton] Error 1
The system I have on the desktop is pretty much identical to the one on the laptop (FreeBSD 9.0 amd64) so I have no idea why it should succeed on one but fail on the other.
Well, code from richardgv-dev branch builds fine on my FreeBSD 9.1 amd64. If you encountered a build failure, please show me the output messages (all the output messages, not only the error) so we can look into this.
This generally means you are using a very outdated version of libconfig that does not include config_set_include_dir(), i.e., <libconfig-1.4. Compton does detect libconfig version in Makefile with pkg-config and automatically enable legacy libconfig support when needed, but somehow this didn’t work for you. The current version in FreeBSD ports is 1.4.9, and libconfig 1.4 has already being included in ports tree since August 2010. So, this is strange. Please make sure you have devel/libconfig-1.4.x installed, and you don’t have remainings of an old libconfig installation somehow in your system, with, for example:
find / -name 'libconfig*.so*'
If for some reasons, you couldn’t get this working, or you have to stick with an old version of libconfig, you could forcefully enable legacy libconfig version support in compton:
(Note older versions of libconfig are not completely compatible with 1.4.x – a pointer is changed from ‘long *’ to ‘int *’ – so you shouldn’t use this unless you are 100% sure you have <libconfig-1.4. Also, older versions of libconfig have no @include support.)
Or you could choose to drop libconfig support entirely, which means, compton will not be able to read configuration files:
Thanks for your continuing help. I have had a bit of trouble getting on with this, as I decided to upgrade my FreeBSD box from 9.0 to 9.1 in the hope that this would solve the problem of the library incompatibility. Owing to a hardware fault that all got rather messy and I have ended up sticking with 9.0 for now. That has libconfig-1.4.5 anyway, so not so very old. However, I was unable to compile the code at all, getting these errors:
src/opengl.c:477:9: error: use of undeclared identifier 'GL_TEXTURE_RECTANGLE'
GL_TEXTURE_RECTANGLE);
^
src/opengl.c:667:20: error: use of undeclared identifier 'GL_TEXTURE_RECTANGLE'
GLenum tex_tgt = GL_TEXTURE_RECTANGLE;
In the end, I decided to simply compile again on my laptop where compilation had succeeded, but use the libconfig legacy mode you suggested, and then copy the binary over to my desktop machine. I repeated the whole process beginning with the git download, but the compilation failed with exactly the same errors as on my desktop box. However, I still had the original source from a few days ago so I tried with that, and it worked without any problem. I have copied the binary over and it is running very nicely.
My only real problem now is that I can’t reproduce this unless I hang onto my original download. I like Compton a lot and the fact that it will work with fvwm is great.
Have you changed something in the last few days or am I just doing something stupid?
Oh well, that sucks. Probably your issues are somehow associated with the outdated base system. I use FreeBSD 9.1 to test myself, and it works correctly.
I merged the OpenGL backend code to master branch, together with some misc changes.
Update: I’ve added a workaround of this issue to richardgv-dev branch of the git repo.
GL_TEXTURE_RECTANGLE is a macro used for compatibility with some very old cards in OpenGL backend. I suppose this macro is defined in recent OpenGL headers (which usually comes from mesa), and this is the first time I see somebody having this macro undefined. It may indicate you don’t have an up-to-date mesa or graphic driver installed, or you didn’t properly update your system or those packages somehow. Anyway, GL_TEXTURE_RECTANGLE is 0x84F5, so as a quick-and-dirty workaround:
In theory this should never work, because the soname of libconfig.so changes when the API changes, and ABI compatibility may break as well. So when you copy a binary from a system with libconfig 1.4 to one with 1.3 (or vice versa), it shouldn’t run at all. It feels like you do have libconfig 1.4 installed, ld couldn’t find it, but ld.so could, and this is a pretty bad sign, let’s say. Hmm, perhaps you have both libconfig.so.10 and libconfig.so.9 under /usr/local/lib, and the symlink /usr/local/lib/libconfig.so points to libconfig.so.9 somehow (possibly you somehow didn’t correctly uninstall the old version before you forcefully install a new one), or maybe your ld and ld.so have inconsistent search paths (may happen if you choose to use /usr/local/bin/ld instead of /usr/bin/ld as linker?).
Many experts probably don’t like compositors, but I found composition improving my productivity, by letting me look and operate through semi-transparent windows