On 02-Jan-2002 Alexander Volovics wrote: > Hello, > > I have been using bb-0.61 on my laptop now for some time. > I have tried it with and without the 'blackbox-taskbar-patches' > of Ignacio Thayer. > > Personally I much prefer being able to immediately see which apps/windows > I have iconized on the toolbar and to open them again from the toolbar > then to have to pop up the "workspaces menu" every time just to see > what I have iconized and to open them from there. >
this has been requested twice on the blackbox feature request page (sf.net/projects/blackboxwm). Read my comments there please. To summarize Blackbox is NOT about icons. It supports them as minimally as possible because it has to do so. Another options is for there to be an icon pager similar to bbpager. It is possible now and will be even easier when the bb lib and NET WM spec is supported. Yet another option is to leave the icon menu pinned. This gives you a small window listing the icons. Very unobtrusive. I know that not supporting icons further will upset some people. However, changing one of the basic premises of the window manager will also make many people unhappy. > It would also be very nice to have the option of setting a background > pixmap in the styles definitions next to 'solid', 'mod' and 'gradient'. > (and more elegant than using xv or display + some kind of script). > Especially for Eterm users like myself. > blackbox comes with a program called bsetroot. This command can set backgrounds on root using the same gradient code blackbox uses for its own windows. It won't load jpgs, but it gets the job done. Eterm (and others) should be able to display semi transparency as bsetroot supports setting the information those apps want. Anything else means linking blackbox to libjpg, libpng, and whatever else people want as background images. This will not happen. > It should be possible to include both of these extensions without > straining the minimal qualities of blackbox very much (and they > could be made optional at compile time). > > Including these extensions (optionally) is in any case slightly > easier than patching everytime (and possibly having to wait on > the patches catching up with new versions of blackbox (particularly > for non-programmers like myself who cannot adapt anything themselves)). > options at compile time are simply not options. Many of the users of blackbox use it via precompiled packages from various linux and bsd vendors. These vendors when faced with compile time options either turn all of them on or all of them off. Personally I maintain blackbox for Debian as well as being its current chief hacker. Putting compile options in are useless to me and others. Compile options are also only useful to those willing and able to play with a compiler. Yes this is common under UNIX, but it is not the way of the future. I am a fan of runtime options and will try to support this as much as possible. The small group of us hacking on blackbox are trying to come up with ways to make blackbox smaller, leaner and faster. My hope is that the gains here can be used to offset any new additions. I hope this helps. I am open to discussion on most anything. Discussion is ALWAYS a good thing as long as it is kept bounded by reason. Pros and cons are always good and always lead to better results.
