Shallow Thoughts
Akkana's Musings on Open Source, Science, and Nature.
Wed, 16 Jul 2008
I had a silly problem: I needed to make some screenshots, but my
window borders were too pretty.
The problem isn't actually that they're pretty; it's that the theme
I wrote for openbox is very different from the much simpler theme I
used to use in fvwm, and I needed new screenshots that matched
the old fvwm look. Preferably without actually going back to
using fvwm -- I'm quite happy with openbox these days.
Anyway, the obvious solution is to run a second X.
I had done that in the past (when I needed to test something repeatedly,
like a wacom tablet, and didn't want to be restarting X all the
time) so I knew that was possible. But then someone told me about
Xnest. It's a way to run an X server embedded in a window of the
current X session. What a neat idea! I wanted to try it.
I made a simple .xinitrc.xnest file that starts
fvwm after loading .Xdefaults.
It took some fiddling to find a combination of arguments that worked.
In the end, this was it:
xinit ~/.xinitrc.xnest -- /usr/bin/Xnest -ac :1 -geometry 1024x768
And indeed, a 1024x768 window popped up with an fvwm running inside
it. Cool! Except it turned out to be not so cool -- because as soon
as I switched desktops, I found that the Xnest window wouldn't
repaint itself. Not even after being covered with another window
then uncovered -- it just didn't seem to get any expose events.
Bummer!
Next I tried Xephyr -- I heard that it was similar to Xnest, a
little more heavyweight but a little more reliable. It turned out
the arguments were just the same, so I ran it exactly like Xnest:
xinit ~/.xinitrc.xnest -- /usr/bin/Xephyr -ac :1 -geometry 1024x768
but Xephyr was even worse about window redrawing, plus it had some
problems with the mouse pointer, which kept jumping to random
places.
Too bad! They both sounded fun, and I'm sure they'll improve and
will eventually become usable. But for now, I'm back to the simpler
solution, running a second X server. Here's how that works:
first I have to log in on console 2 (ctl-alt-F2).
For some reason, I can't run a second X except from there.
Then I run:
startx ~/.xinitrc.xnest -- :1
and I get a new X session, on ctl-alt-F8 (with my regular session still
accessible on ctl-alt-F7).
Tags: X11, screenshots
[
20:01 Jul 16, 2008
More linux |
permalink to this entry
]
Sun, 25 May 2008
A user on the One Laptop Per Child (OLPC, also known as the XO)
platform wrote to ask me how to use crikey on that platform.
There are two stages to getting crikey running on a new platform:
- Build it, and
- Figure out how to make a key run a specific program.
The crikey page
contains instructions I've collected for binding keys in various
window managers, since that's usually the hard part.
On normal Linux machines the first step is normally no problem.
But apparently the OLPC comes with gcc but without make or the X
header files. (Not too surprising: it's not a machine aimed at
developers and I assume most people developing for the machine
cross-compile from a more capable Linux box.)
We're still working on that (if my correspondant gets it working,
I'll post the instructions), but while I was googling for
information about the OLPC's X environment I stumbled upon
a library I didn't know existed: python-xlib.
It turns out it's possible to do most or all of what crikey does
from Python. The OLPC is Python based; if I could write crikey
in Python, it might solve the problem.
So I whipped up a little key event generating script as a test.
Unfortunately, it didn't solve the OLPC problem (they don't include
python-xlib on the machine either) but it was a fun exercises, and
might be useful as an example of how to generate key events in
python-xlib. It supports both event generating methods: the X Test
extension and XSendEvent. Here's the script:
/pykey-0.1.
But while I was debugging the X Test code, I had to solve a bug that
I didn't remember ever solving in the C version of crikey. Sure
enough, it needed the same fix I'd had to do in the python version.
Two fixes, actually. First, when you send a fake key event through
XTest, there's no way to specify a shift mask. So if you need a
shifted character like A, you have to send KeyPress Shift, KeyPress a.
But if that's all you send, XTest on some systems does exactly what
the real key would do if held down and never released: it
autorepeats. (But only for a little while, not forever. Go figure.)
So the real answer is to send KeyPress Shift, KeyPress a, KeyRelease
a, KeyRelease Shift. Then everything works nicely. I've updated
crikey accordingly and released version 0.7 (though since XTest
isn't used by default, most users won't see any change from 0.6).
In the XSendEvent case, crikey still doesn't send the KeyRelease
event -- because some systems actually see it as another KeyPress.
(Hey, what fun would computers be if they were consistent and
always predictable, huh?)
Both C and Python versions are linked off the
crikey page.
Tags: programming, crikey, X11, python
[
14:50 May 25, 2008
More programming |
permalink to this entry
]
Thu, 10 Apr 2008
Dave has been experimenting with xorg configuration lately -- trying
to figure out why the latest Xorg no longer supports 1600x1200 on
his monitor. (I've looked for bug reports and found gazillions of
them, all blaming it on the video card but involving three different
makes of video card, so color me skeptical.)
Anyway, part of this has involved taking out parts of his
/etc/X11/xorg.conf file to see which parts might be causing the
problem, and he's found something interesting.
What do you suppose is the minimal useful xorg.conf file?
You might suppose, oh, screen and monitor sections, an input section
for the keyboard and another one for a generic mouse, and that might
be all you need ... right?
Okay, try it. Let's start with a really minimal file -- nothing --
and gradually add sections. To try it, make a backup of your current
xorg.conf, then zero out the file:
cd /etc/X11
mv xorg.conf xorg.conf.sav
cp /dev/null xorg.conf
Now exit X if you hadn't already, and start it up again (or
let gdm do it for you).
Be prepared to do repairs from the console in case X doesn't start up: e.g.
sudo cp /etc/X11/xorg.conf.bak /etc/X11/xorg.conf
What happened?
In my case, on the laptop running Hardy beta, X starts right up and
looks just the same as it did before.
xorg.conf -- who needs it?
A specious question, of course, which has a perfectly good answer:
anyone who needs a resolution other than whatever xorg picks as the default;
anyone with additional hardware, like a wacom tablet;
anyone who wants customizations like XkbOptions = ctrl:nocaps.
There are lots of reasons to have an xorg.conf. But it's fun to
know that at least on some machines, it's possible to run without one.
Update: turns out this is part of Ubuntu's new
BulletProof X
feature. It doesn't work on other distros or older versions.
Thanks to James D for the tip.
Tags: linux, X11
[
10:25 Apr 10, 2008
More linux |
permalink to this entry
]
Tue, 05 Feb 2008
A month or so back, I spent some time fiddling with the
options for the Synaptics touchpad driver. The Alps (not Synaptics)
trackpad on my laptop has always worked okay with just the standard
PS/2 mouse driver, but in recent kernels it's become overly sensitive
to taps, registering spurious clicks when I'm in the middle of typing
a word (so suddenly I'm typing in a completely different window
without knowing it).
I eventually got it working. I tried various options, but here's what I
settled on:
Section "InputDevice"
Identifier "Trackpad"
Driver "synaptics"
Option "SHMConfig" "true"
Option "SendCoreEvents" "true"
Option "Device" "/dev/psaux"
Option "Protocol" "auto-dev"
Option "MinSpeed" "0.5"
Option "MaxSpeed" "0.75"
# AccelFactor defaults to .0015 -- synclient -l to check
Option "TouchpadOff" "2"
Option "Emulate3Buttons" "true"
EndSection
Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"
Option "CorePointer"
Option "Device" "/dev/input/mice"
Option "Protocol" "ExplorerPS/2"
Option "ZAxisMapping" "4 5"
Option "Emulate3Buttons" "true"
EndSection
Life was groovy (I thought).
Fast forward to LCA, a few days before my talk,
when I decide to verify that I can run my USB mouse and the
slide-advancing presentation gizmo through a hub off the single USB
port. Quel surprise: the USB mouse doesn't work at all!
I didn't really need a mouse for that presentation (it was on GIMP
scripting, not GIMP image editing) so I put it on the back burner,
and came back to it when I got home. As I suspected, the USB mouse
was working fine if I commented out the Synaptics entry from
xorg.conf; it just couldn't run both at the same time.
A little googling led me to the answer, in a thread called Can't
use Synaptics TouchPad and USB Mouse -- it wasn't the first google
hit for synaptics "xorg.conf" usb mouse, so perhaps this entry
will help its google-fu. The important part I was missing was in the
"ServerLayout" section:
InputDevice "Trackpad" "AlwaysCore"
InputDevice "Configured Mouse" "CorePointer"
Adding "AlwaysCore" and "CorePointer" parts was what did the trick.
Thanks to "finferflu" who posted the right answer in the thread.
Tags: linux, X11
[
21:54 Feb 05, 2008
More linux |
permalink to this entry
]
Sat, 25 Aug 2007
On a seemingly harmless trip to Fry's,
my mother got a look at the 22-inch widescreen LCD monitors
and decided she had to have one. (Can't blame her ... I've been
feeling the urge myself lately.)
We got the lovely new monitor home, plugged it in, configured X
and discovered that the screen showed severe vertical banding.
It was beautiful at low resolutions, but whenever we went to
the monitor's maximum resolution of 1680x1050, the bands appeared.
After lots of testing, we tentatively pinned the problem
down to the motherboard.
It turns out ancient machines with 1x AGP motherboards
can't drive that many pixels properly,
even if the video card is up to the job. Who knew?
Off we trooped to check out new computers.
We'd been hinting for quite some time that it might be about
time for a new machine, and Mom was ready to take the plunge
(especially if it meant not having to return that beautiful monitor).
We were hoping to find something with a relatively efficient Intel Core 2
processor and Intel integrated graphics: I've been told the Intel
graphics chip works well with Linux using open source drivers.
(Mom, being a person of good taste, prefers Linux, and none of us
wanted to wrestle with the proprietary nvidia drivers).
We found a likely machine at PC Club. They were even willing to
knock $60 off the price since she didn't want Windows.
But that raised a new problem. During our fiddling with her old
machine, we'd tried burning a Xubuntu CD, to see if the banding
problem was due to the old XFree86 she was running. Installing it hadn't
worked: her CD burner claimed it burned correctly, but the resulting
CD had errors and didn't pass verification. So we needed a CD burned.
We asked PC Club when buying the computer whether we might burn the
ISO to CD, but apparently that counts as a "data transfer" and their
minimum data transfer charge is $80. A bit much.
No problem -- a friend was coming over for dinner that night,
and he was kind enough to bring his Mac laptop ...
and after a half hour of fiddling, we determined that his burner
didn't work either (it gave a checksum error before starting the
burn). He'd never tried burning a CD on that laptop.
What about Kinko's? They have lots of data services, right?
Maybe they can burn an ISO. So we stopped at Kinko's after dinner.
They, of course, had never heard of an ISO image and had no idea how
to burn one on their Windows box.
Fearing getting a disk with a filesystem containing one file named
"xubuntu-7.04-alternate-i386.iso", we asked if they had a mac,
since we knew how to burn an ISO there.
They did, though they said sometimes the CD burner was flaky.
We decided to take the risk.
Burning an ISO on a mac isn't straightforward -- you have to do
things in exactly the right order.
It took some fast talking to persuade them of the steps ("No, it
really won't work if you insert the blank CD first. Yes, we're quite
sure") and we had to wait a long time for Kinko's antivirus software
to decide that Xubuntu wasn't malware, but 45 minutes and $10 later,
we had a disc.
And it worked! We first set up the machine in the living room, away
from the network, so we had to kill aptitude update
when the install hung installing "xubuntu-desktop" at 85%
(thank goodness for alternate consoles on ctl-alt-F2) but otherwise
the install went just fine. We rebooted, and Xubuntu came up ...
at 1280x1024, totally wrong. Fiddling with the resolution in xorg.conf
didn't help; trying to autodetect the monitor with
dpkg-reconfigure xorg crashed the machine and we had to
power cycle.
Back to the web ... turns out that Ubuntu "Feisty" ships with a bad
Intel driver. Lots of people have hit the problem, and we found a
few elaborate workarounds involving installing X drivers from various
places, but nothing simple. Well, we hadn't come
this far to take all the hardware back now.
First we moved the machine into the computer room, hooked up
networking and reinstalled xubuntu with a full network, just in
case. The resolution was still wrong.
Then, with Dave in the living room calling out steps off a web page
he'd found, we began the long workaround process.
"First," Dave suggested, reading, "check the version of
xserver-xorg-video-intel.
Let's make sure we're starting with the same version this guy is."
dpkg -l xserver-xorg-video-intel ... "Uh, it isn't
installed," I reported. I tried installing it. "It wants to remove
xserver-xorg-video-i810." Hmm! We decided we'd better do it,
since the rest of the instructions depended on having the
intel, not i810, driver.
And that was all it needed! The intel driver autodetected the monitor
and worked fine at 1680x1050.
So forget the elaborate instructions for trying X drivers from various
sources.
The problem was that xubuntu installed the wrong driver:
the i810 driver instead of the more generic intel driver.
(Apparently that bug is fixed for the next Ubuntu release.)
With that fix, it was only a few more minutes before Mom was
happily using her new system, widescreen monitor and all.
Tags: linux, X11, ubuntu
[
13:23 Aug 25, 2007
More linux |
permalink to this entry
]
Sun, 17 Jun 2007
It was a bit over two years ago that I
switched from
icewm to fvwm as my window manager. Fvwm proved to be very fast,
very configurable, and "good enough" most of the time. But lately,
I've found myself irritated with it, particularly with its tendency to
position windows off screen (which got a lot worse in 2.5.18).
It looked like it was time to try another window manager, so when
I learned that the
Openbox
project is headed by a fellow
LinuxChixor, I had to try it.
Openbox impressed me right away. I'd tried it once before, a couple of years
ago, when I found it a little inconsistent and immature. It's grown up a
lot since then! It's still very fast and lightweight, but it has good
focus handling, excellent window positioning, a good configuration
window (obconf), and a wide variety of themes which are pretty but
still don't take up too much of my limited screen space.
But more important, what it has is a very active and friendly
community. I hit a couple of snags, mostly having to do with focus
handling while switching desktops (the problem that drove me off
icewm to fvwm), so I hopped onto the IRC channel and found myself
chatting with the active developers, who told me that most of my
problems had already been fixed in 3.4, and there were .deb files
on the website for both of the distros I'm currently using.
Indeed, that cured the problem; and when I later hit a more esoteric
focus bug, the developers (particularly Dana Jansens) were all over it
and fixed it that same day. Wow!
Since then I've been putting it through its paces. I have yet to see
a window positioned badly in normal usage, and it handles several
other problems I'd been seeing with fvwm, like focus handling when
popping up dialogs (all those secondary GIMP Save-as dialogs that
don't get focused when they appear). It's just as flexible as fvwm
was when it comes to keyboard and mouse configuration, maybe even
more so (plus it has lots of useful default bindings I might not
have thought of, like mousewheel bindings to change desktops or
"shade" a window).
I was going to stay out of theme configuration, because there were
several pretty good installed themes already. But then in response to
a half-joking question on my part of whether a particular theme came
in blue, someone on the IRC channel made me a custom theme file -- and
I couldn't resist tweaking it from there, and discovered that tweaking
openbox themes is just as easy as fiddling with its other defaults.
I don't use transparency (I find it distracting), but my husband is
addicted to transparent windows, so when I noticed on the web site
that openbox handles transparency I pointed him there. (He's been
using an old Afterstep, from back when it was still small and light,
but it's been a constant battle getting it to build under newer gccs.)
He reports that openbox handles transparency as well as afterstep did,
so he's switched too.
I haven't looked at the openbox code yet, but based on how fast the
developers add features and fix bugs, I bet it's clean, and I
hope I can contribute at some point.
Anyway, great focus handling, great window positioning, fast,
lightweight, super configurable, and best of all a friendly and
helpful developer and user community. What more could you ask for in a
window manager?
I'm an openbox convert. Thanks, Dana, Mikachu and all the rest.
Tags: linux, X11
[
13:13 Jun 17, 2007
More linux |
permalink to this entry
]
Sat, 09 Dec 2006
Another person popped into #gimp today trying to get a Wacom tablet
working (this happens every few weeks). But this time it was someone
using Ubuntu's new release, "Edgy Eft", and I just happened to have
a shiny new Edgy install on my laptop (as well as a Wacom Graphire 2
gathering dust in the closet because I can never get it working
under Linux), so I dug out the Graphire and did some experimenting.
And got it working! It sees pressure changes and everything.
It actually wasn't that hard, but it did require
some changes. Here's what I had to do:
- Install wacom-tools and xinput
- Edit /etc/X11/xorg.conf and comment out those ForceDevice lines
that say "Tablet PC ONLY".
- Reconcile the difference between udev creating /dev/input/wacom
and xorg.conf using /dev/wacom: you can either change xorg.conf,
change /etc/udev/rules.d/65-wacom.rules, or symlink /dev/input/wacom
to /dev/wacom (that's what I did for testing, but it won't survive a
reboot, so I'll have to pick a device name and make udev and X
consistent).
A useful tool for testing is /usr/X11R6/bin/xinput list
(part of the xinput package).
That's a lot faster than going through GIMP's input device
preference panel every time.
I added some comments to Ubuntu's bug
73160, where people had already described some of the errors but
nobody had posted the steps to work around the problems.
While I was fiddling with GIMP on the laptop, I decided to install
the packages I needed to build the latest CVS GIMP there.
It needed a few small tweaks from the list I used on Dapper.
I've updated the package list on my GIMP Building
page accordingly.
Tags: linux, X11, imaging, gimp, ubuntu
[
15:12 Dec 09, 2006
More linux |
permalink to this entry
]
Mon, 10 Jul 2006
An unexplained change in the screen blanking timeout sent me
down the primrose path of learning about dpms, vbetool and screen
blanking. I guess it had to happen eventually.
It started when my laptop, which normally can sit for about ten
minutes before the screen goes black, suddenly started blanking
the screen after only two minutes.
After a few days of sporadic research, I now know what pieces are
involved and how to fix the timeout. But it turns out not everything
works the way it's supposed to.
I've written up my findings:
A Primer on
Screen Blanking Under Xorg.
Tags: linux, X11
[
11:55 Jul 10, 2006
More linux |
permalink to this entry
]
Mon, 20 Mar 2006
Dave has been complaining for a long time about the proliferation of
files named
.serverauth.???? (where
???? is various
four-digit numbers) in his home directory under Ubuntu. I never saw
them under Hoary, but now under Breezy and Dapper I'm seeing the same
problem.
I spent some time investigating, with the help of some IRC friends.
In fact, Carla
Schroder, author of O'Reilly's Linux Cookbook, was
the one who pinned down the creation of the files to the script
/usr/bin/startx.
Here's the deal: if you use gdm, kdm, or xdm, you'll never see
this. But for some reason, Ubuntu's startx uses a program
called xauth which creates a file containing an "MIT-MAGIC-COOKIE".
(Don't ask.) Under most Linux distributions, the magic cookie goes
into a file called .Xauthority. The startx script checks an
environment variable called XENVIRONMENT for the filename; if it's not
set to something else, it defaults to $HOME/.Xenvironment.
Ubuntu's version is a little different. It still has the block of
code where it checks XENVIRONMENT and sets it to
$HOME/.Xenvironment if it isn't already set. But a few
lines later, it proceeds to create the file under another, hardwired,
name: you guessed it, $HOME/.serverauth.$$. The XENVIRONMENT
variable which was checked and set is never actually used.
Programmers take note! When adding a feature to a script, please take
a moment and think about what the script does, and check to see
whether it already does something like what you're adding. If so,
it's okay -- really -- to remove the old code, rather than leaving
redundant and obsolete code blocks in place.
Okay, so why is the current code a problem? Because startx
creates the file, calls xinit, then removes the file. In other words,
it relies on xinit (and the X server) exiting gracefully. If anything
else happens -- for example, if you shut your machine down from within X --
the startx script (which does not catch signals) can die
without ever getting to the code that removes the file. So if you
habitually shut down your machine from within X, you will have a
.serverauth.???? file from each X session you ever shut down that way.
Note that the old setup didn't remove the file either, but at least it
was always the same file. So you always have a single .Xauthority file
in your home directory whether or not it's currently in use. Not much
of a problem.
I wasn't seeing this under Hoary because under Hoary I ran gdm, while
with Dapper, gdm would no longer log me in automatically so I had to
find
another approach to auto-login.
For Ubuntu users who wish to go back to the old one-file XAUTHORITY
setup, there's a very simple fix: edit /usr/bin/startx (as
root, of course) and change the line:
xserverauthfile=$HOME/.serverauth.$$
to read instead
xserverauthfile=$XAUTHORITY
If you want to track this issue, it's bug bug
35758.
Tags: linux, X11, ubuntu
[
20:24 Mar 20, 2006
More linux |
permalink to this entry
]
Mon, 01 Aug 2005
Another in the series of "I keep forgetting how to do this and
have to figure it out again each time, so this time I'm going to
write it down!"
Enabling remote X in a distro that disables it by default:
Of course, you need xhost. For testing, xhost +
enables access from any machine; once everything is working, you
may want to be selective, xhost hostname for the hosts from
which you're likely to want to connect.
If you log in to the console and start X, check
/etc/X11/xinit/xserverrc and see if it starts X with the
-nolisten flag. This is usually the problem, at least on
Debian derivatives: remove the -nolisten tcp.
If you log in using gdm, gdmconfig has an option in the
Security tab: "Always disallow TCP connections to X server
(disables all remote connections)". Un-checking this solves the
problem, but logging out won't be enough to see the change.
You must restart X; Ctrl-Alt-Backspace will do that.
Update: If you use kdm, the configuration to change is in
/etc/kde3/kdm/kdmrc
Tags: linux, X11, net
[
12:52 Aug 01, 2005
More linux |
permalink to this entry
]
Mon, 13 Dec 2004
I've been alternating between icewm and openbox for my window manager,
but I'm not entirely happy with either one. They're both fast to
start up, which is important to me, but I've had frustrations
mostly relating to window focus -- which window becomes focused when
switching from one desktop to another (icewm's biggest problem) or
when a window resizes (openbox), and also with initial window positioning
and desktop location (e.g. making one window span all desktops without
having to select a menu item every time I run that app).
Someone was opining on IRC about fvwm and its wonderful configurability,
and that made me realize that I haven't really given fvwm a chance in
a long, long time. Time to see if I was missing anything!
The defaults are terrible. No wonder I didn't stick with fvwm after
newer windowmanagers came out! It's definitely not an install-and-go
sort of program. Nor is the documentation (a long and seemingly
thorough man page) clear on how to get started configuring it.
Eventually I figured out that it looks for ~/.fvwm/config, and
that some sample configs were in /usr/share/doc/fvwm/sample.fvwmrc
(which is a directory), and I went from there. After several hours
of hacking, googling, and asking questions on #fvwm, I had a setup
which rivals any window manager I've found: it's fast, lets me configure
the look of my windows, lets me bind just about anything to keys,
and seems pretty well behaved focus behavior. More important,
it also allows me to specify special behavior for certain windows,
for example, making xchat always occupy all desktops:
Style "xchat" Sticky
which is something I've wanted but haven't been able to do in
any other lightweight window manager. That alone may keep me
in fvwm for the forseeable future.
Tips for things that were non-obvious:
Rotating through three desktops
In other window managers, I define three desktops, and use ctrl-alt-right
and left to cycle through them, rotating, so going right from 3 goes to
desktop 1. fvwm has both "pages" (a virtual desktop can be bigger than
the screen, and mousing off the right side scrolls right one page) and
desktops. I didn't want pages, only desktops, so
DeskTopSize 1x1
turns off the pages, and it was clear from the man page that
PointerKey Left A CM GotoDesk -1
would go left one desk (the only unclear part about that is that A
in the modifier list means "Any", not "Alt", and "M" (presumably for
"meta" means alt, not the windows-key which some programs use for meta).
"PointerKey" is needed instead of "Key" because otherwise fvwm gets
confused when using the "sloppy focus" model (the man page warns
about that).
The question was, how to limit fvwm to three
desktops, and wrap around, rather than just going left to new desktops
forever? The answer (courtesy of someone on IRC) turned out to be:
PointerKey Left A CM GotoDesk -1 0 2
PointerKey Right A CM GotoDesk 1 0 2
PointerKey Left A CMS MoveToDesk -1 0 2
PointerKey Right A CMS MoveToDesk 1 0 2
The only problem at this point is that MoveToDesk doesn't then change
to the new desktop, the way other window managers do, but I'm confident
that will be easily solved.
Titlebar buttons
I had the hardest time getting buttons (e.g. maximize, close)
to appear on the titlebars of my windows. You'd think this would
happen by default, but it doesn't. It turned out that titlebar buttons
aren't drawn unless there's a key or mouse action bound to that button,
which they aren't by default. So to get buttons for window menu,
maximize, and close, I had to do:
Mouse 1 6 A Close
Mouse 1 8 A Maximize
Mouse 1 1 A Menu Window-Ops Nop
But then showing buttons 6 and 8 (the even buttons are numbered
from the top right) automatically turns on 2 and 4 (I chose 6 and
8 because their default shapes were vaguely mnemonic), so they have
to be turned off again:
Style * NoButton 2
Style * NoButton 4
Smaller titlebar and window frame
I also wanted to reduce the titlebar height and the width of the window
frame: I don't like wasting all that screen real estate. That, too,
took a long time to figure out. It turns out I had to define my own
theme in order to do that, then add a couple of undocumented items
to my theme. There's lots of documentation around on how to make
buttons and background images and menus and key bindings in themes,
but none of the documentation mentions simple stuff like titlebar height.
DestroyDecor MyDecor
AddToDecor MyDecor
+ TitleStyle Height 16
+ Style "*" BorderWidth 5, HandleWidth 5
+ ButtonStyle All -- UseTitleStyle
Style "*" UseDecor MyDecor
New windows should grab focus
Most window managers do this by default, but fvwm doesn't, and requires:
Style * FPGrabFocus
Full config file
For any other settings, see my
fvwm config file.
Tags: linux, X11
[
17:14 Dec 13, 2004
More linux |
permalink to this entry
]
Mon, 09 Aug 2004
Searching, as always, for the perfect window manager ...
Helix likes ion3, because it handles key accelerators very well,
so I thought I'd try it.
I don't really like the "tiled or fullscreen" model it uses by
default, but found the answer in the FAQ (after a rude RTFM comment
which made no sense, since I already had RTFM and it doesn't give
information on anything but runtime arguments): press F9 and get
it to prompt for the type of the new workspace (the correct answer
is the one with "Float" in the name).
All of the available themes use the "small grab handle around the
title, but the rest of the titlebar isn't there" look. I don't like
that (it's harder to find a place to grab to move windows around)
though I suppose I could get used to it. Not a big deal.
It does look like it has good key binding support, and ways to
specify different behavior for different apps, both of which would
be very nice. Focus behavior on resize seems to be the same as openbox
and icewm, though: if the window resizes out from under the cursor,
it loses focus. Also the root menus (right-click) are a pain: they
don't stay posted, and they're small, so it's hard to navigate them.
I'm sure ion3 has some coolnesses, but I decided that it didn't look
likely enough to solve my problems to be worth learning how to
configure it (and that unjustified RTFM left a bad taste in my
mouth about how easy that configuration was likely to be). So
I'm back on openbox for a little while, anyway.
Here's what I want out of a window manager:
- First, startup speed and basic operation comparable to icewm or openbox
(my two faves so far).
- Intelligent handling of keyboard focus even when in "focus follows mouse"
mode. That means:
- When switching workspaces, focus goes either to the window
under the mouse, or the window on that workspace which last
had the focus (either one would be fine). Openbox does this
pretty well; icewm's focus is pretty random.
- When resizing a window that has focus, it should keep the
focus even if it resizes out from under the mouse.
- Click in a window focuses (but doesn't necessarily raise) that window.
(Again, openbox does this well, icewm doesn't.)
- A new window or dialog gets focused.
- A way of setting up rules for different windows:
e.g. I want xchat to be on all workspaces, or I want moonroot to
come up with no window borders. I shouldn't have to do a
right-click-and-menu-selection operation every single time I
run xchat.
- Easy configuration to start apps with from a menu on the root
or via key bindings (or, ideally, both). No dependance on
having a panel (which was why I quit using xfce4).
Both icewm and openbox handle this well.
- A way of navigating among windows using only the keyboard.
Both openbox and icewm allow for easy movement between
workspaces and moving windows between workspaces, but in both
of them, alt-tab toggles between the current app and the last
app on that workspace, and there seems to be no way to get to
anything besides those two.
Tags: linux, X11
[
17:36 Aug 09, 2004
More linux |
permalink to this entry
]
Sat, 31 Jul 2004
For some reason X on the laptop hasn't been seeing the external
USB mouse. But last night I got it working again. Turns out that
/dev/input/mouse0 no longer works; I have to use /dev/input/mice
because the mouse number changes each time it's plugged in
(which I don't think was a problem with earlier kernels).
Thanks to Peter S. for helping me track the problem down.
I also learned (unrelated to the mouse issue) about a couple of
very useful Debian apps, deborphan and debfoster, for finding
orphaned and no longer needed libraries. I'd always wanted
something like that to help clean up my crufty debian systems.
Tags: linux, X11, debian
[
18:39 Jul 31, 2004
More linux |
permalink to this entry
]
Wed, 07 Jul 2004
Got an account on alioth, akkana-guest.
Discovered that the tuxracer problem I've been having isn't actually
Debian sid having broken DRI, but merely some problem with the
commercial tuxracer (probably not loading the gl libs properly
or something). Free tuxracer still works. Yay.
Tags: linux, debian, X11, games
[
19:00 Jul 07, 2004
More linux |
permalink to this entry
]