Shallow Thoughts : tags : window managers

Akkana's Musings on Open Source Computing and Technology, Science, and Nature.

Sun, 24 Nov 2019

Adjusting PulseAudio Volume from the Command-Line (or a Window Manager)

I have a new laptop, a birthday present to myself last month. For once, rather than buying a cut-rate netbook, I decided to treat myself to a fancy Lenovo Carbon X1 with an up-to-date processor and lots of RAM.

Since I have way more resources than I'm used to, I decided I'd try installing a full Ubuntu and not trying to pare it down to a super lightweight system. I'm still running the lightweight, fast, highly configurable Openbox window manager instead of a full Gnome desktop: Openbox does just what I tell it and no more, and doesn't surprise me with random redesigns. But I did let Ubuntu install some system utilities I've always avoided in the past, like NetworkManager and PulseAudio. I decided I'd give them a chance, see if they've gotten better since I last checked.

They have, though they're still a bit of a hassle to deal with. NetworkManager can be controlled through nmcli, which is poorly documented but works okay if you google long enough to find the proper incancations. PulseAudio gave me a bit more trouble.

The standard GUI for controlling PulseAudio is pavucontrol. It showed two audio devices: "USB PnP Audio Device Analog Stereo" and "Built-in Audio Analog Stereo". Turns out the USB PnP option is a sound card built into the USB hub, a Totu tt-hb003a 11-in-1 USB-C hub that lets me connect to a charger, external monitor, SD and micro-SD slots, and extra USB ports without juggling a lot of extra cables.

Pulse assumes -- probably reasonably, though it's wrong in this case -- that if I have a USB audio device connected, I probably want to use it in preference to the laptop's built-in audio. That would make sense if I had external speakers plugged in, but I left all my computer speakers behind when I moved. I should probably order some speakers. But meanwhile, I needed to persuade PulseAudio to ignore the hub and use the laptop's built-in sound system.

Mute/Unmute via the Keyboard

The Lenovo, like most laptops, has a dedicated key for muting, Fn-F1. It even has a little light on it to show whether it's muted. In Openbox, pressing Fn-F1 actually muted the sound, and even turned on the light. This is probably because I'd previously set key="XF86AudioMute" to run amixer set Master toggle in .config/openbox/rc.xml, which worked on my Pulse-free pared-down Debian netbook. The problem is that pressing iFn-F1 again didn't bring the sound back. Instead, it was unmuting the USB hub's audio. Clicking "Set as fallback" on the built-in audio in pavucontrol made no difference.

It turns out that it is virtually impossible to persuade PulseAudio to use "Built-in Audio" when a "USB PnP Audio Device" is available. I finally found the secret: in pavucontrol's Configuration tab, set Profile for the PnP USB device to Off. Now only the built-in device shows up in the other tabs.

But that amixer command still wasn't unmuting properly, so the next step was to find a command that would actually unmute. Someone on #linux suggested pactl set-sink-mute @DEFAULT_SINK@ toggle and that worked great from the command line. But when I tried to bind it in Openbox to the XF86AudioMute key, it did nothing. I still don't understand why not; I wasted a lot of time comparing my shell environment to openbox's environment and never found the difference.

Back to web searching, I found an askbuntu thread suggesting some Openbox stanzas. In particular, it apparently works better to use alsamixer rather than pactl. This finally worked for toggling mute:

    <keybind key="XF86AudioMute">
        <action name="Execute">
            <command>amixer -q -D pulse sset Master toggle</command>
        </action>
    </keybind>

Volume Controls via Function Keys

Partial success! Unfortunately, the volume control commands in that same askbuntu post, amixer -q -D pulse sset Master 3%+ unmute, did nothing. I had already noticed that in pavucontrol, the volume controls didn't work either. In fact, if I started some music playing and then called up alsamixer, channels like Master and Speaker didn't do anything; the only channel that affected volume was ALSA PCM. After some fiddling, I discovered that I had to change Master to PCM and remove the -D pulse:

    <keybind key="XF86AudioRaiseVolume">
      <action name="Execute">
            <command>amixer sset PCM 4%+ unmute</command>
        </action>
    </keybind>
    <keybind key="XF86AudioLowerVolume">
        <action name="Execute">
            <command>amixer sset PCM 4%- unmute</command>
        </action>
    </keybind>

I'm sure I'll eventually need to fiddle some more. For one thing, if I ever want to use audio during a talk (as I did briefly at my Stonehenge talk earlier this year) I'll need to figure out how to enable a temporary HDMI sound sink quickly without needing to fiddle with pavucontrol. But for now, I'm happy to have the basic laptop volume and mute keys working.

Tags: , , ,
[ 15:43 Nov 24, 2019    More linux | permalink to this entry | comments ]

Mon, 20 Oct 2008

Requesting no window decorations (and moonroot 0.4)

Someone on #openbox this morning wanted help in bringing up a window without decorations -- no titlebar or window borders.

Afterward, Mikael commented that the app should really be coded not to have borders in the first place.

Me: You can do that?

Turns out it's not a standard ICCCM request, but one that mwm introduced, MWM_HINTS_DECORATIONS. Mikael pointed me to the urxvt source as an example of an app that uses it.

My own need was more modest: my little moonroot Xlib program that draws the moon at approximately its current phase. Since the code is a lot simpler than urxvt, perhaps the new version, moonroot 0.4, will be useful as an example for someone (it's also an example of how to use the X Shape extension for making non-rectangular windows).

Tags: , , ,
[ 12:06 Oct 20, 2008    More programming | permalink to this entry | comments ]

Sun, 17 Jun 2007

Openbox 3.4

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: , ,
[ 14:13 Jun 17, 2007    More linux | permalink to this entry | comments ]

Mon, 13 Dec 2004

Back to the Future -- fvwm

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: , ,
[ 18:14 Dec 13, 2004    More linux | permalink to this entry | comments ]

Mon, 09 Aug 2004

Trying ion3, the window manager

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:

Tags: , ,
[ 18:36 Aug 09, 2004    More linux | permalink to this entry | comments ]