 |  |
| |
If you edit your .fvwm2rc file, simply restart fvwm2 to have the changes implemented. In most environments, there will be a menu item that restarts the window manager. The vanilla setup we started with offers the item Exit Fvwm on the Root menu. If you select that item, you'll get a submenu titled Really Quit Fvwm? that contains several entries, including Restart Fvwm. When you select Restart Fvwm, your configuration changes should be implemented. A slower but just as effective way is to quit the X session and start it again (presuming your session startup file includes fvwm2).
In any desktop environment with multiple virtual screens/pages, you can work on only a single screenful at a time. But fvwm2 makes it easy to run applications on different pages, move applications between pages, and switch the view between pages. If you refer to a particular window all the time, you can even arrange for it to appear on every page of every desktop. (We'll come back to this concept of "sticky" windows.) And you're not limited to viewing a page proper or keeping a window entirely on a single page.
Figure 19-1 shows an example of a typical fvwm2 environment. Notice the long horizontal box in the bottom right corner of the figure. This box is the FvwmButtons module (also called the button bar). FvwmButtons is generally used to house a number of tools and applications to which the user needs frequent access. Often these are other fvwm2 modules.
In this sample configuration, FvwmButtons contains two other modules: the Icon Manager (FvwmIconMan) on the left, and the Pager (FvwmPager) in the middle. At the far right you can also see three small application windows: xbiff (a mailbox that indicates when you have new email messages), xclock, and xload (a graphic representation of your system's workload).
The Icon Manager and the Pager are tools that let you monitor what's happening in your environment and manipulate the windows running there. The Icon Manager shows an entry for every conventional window currently on your display. If that window is iconified, the Icon Manager entry is preceded by a square that has a three-dimensional appearance. You can iconify and deiconify any window on the current page by clicking the first pointer button on the corresponding entry in the Icon Manager. (The Icon Manager always shows the windows on the current page; for a similar tool that reflects what's running on every page on every desktop, check out the WinList, described later in this chapter.)
Think of the Pager as a tiny mirror of your entire desktop(s). In a typical default environment with a single desktop composed of two-by-two screen pages, the Pager shows a small grid of four partitions separated by dotted lines. These partitions correspond to the desktop's four virtual screen pages. (If you configure for multiple desktops, a solid line is used to show the border between desktops. Section 19.2.5 later in this chapter tells you how to set this up.)
Each application you run appears in miniature in the Pager window. Applications with small windows are fairly hard to spot in miniature, but a blip representing them is there if you look closely. The miniature version of a larger client, like xterm, should have a readable label.
Whatever operations you perform on windows on the desktop (move, iconify, resize, and so on) are mirrored in the Pager. But the Pager is more than a monitor of activity—it's also a tool. Thus, you can move the miniature versions by clicking the second pointer button and dragging, and the actual windows will be moved. The Pager can also help you move windows between pages and desktops and select the area to be displayed on your monitor (which does not have to correspond to a page proper). You can select an area by right-clicking on the pager.
In addition to the desktop tools, fvwm2 is commonly configured to provide a set of cascading menus beginning from the Root menu. Click the first pointer button on the root window to reveal the Root menu. The Root menu is usually a good way to start a new terminal emulator window. If you start with the default environment for your system, the Root menu is likely to have submenus like Fvwm Modules, Fvwm Window Ops (which offers items like moving, resizing, and closing windows), Fvwm Simple Config Ops (for changing focus policies, how paging works, etc.), and Exit Fvwm (for restarting or exiting the window manager, starting another one, etc.).
This chapter assumes you know how to perform basic window manager operations. We're not going to teach you how to use the Pager or all the menu items. But we will show you how to change the number of desktops the Pager shows, add menu items, configure keyboard shortcuts, and make other useful customizations.
Most versions of fvwm2 are configured to use the pointer focus model (FocusFollowsMouse or MouseFocus in the configuration file). This means you need to move the pointer into a window in order to type in it, post an application menu, and so forth. However, fvwm2 provides other options.
Two other focus policies are available: click-to-type focus (ClickToFocus), which requires you to click the pointer on the window in order to type in it, and the very handy SloppyFocus, which is like pointer focus with a twist—the focus does not leave the last window that had it until you move it into another window that takes over the focus. This can come in handy, particularly with terminal emulator windows like xterm and rxvt. You can actually move the pointer out of the way—accidentally or on purpose—and still continue to type in the window.
The best part of fvwm2's way of handling focus policy is that you can mix and match what windows use what type of focus. All the settings for focus policy are used as arguments to the Style variable. (Style takes several arguments that determine the appearance and behavior of a particular client or window manager component. See Style on the fvwm2 manpage for more information about this versatile option.)
In the following excerpt from a configuration file, the first line makes pointer focus the default for all applications (the asterisk is a wildcard). The subsequent lines specify the exceptions to this rule. The button bar works better with click-to-type focus, as do xman (the manpage viewer) and xmag (a magnification tool). The two terminal emulators benefit from sloppy focus.
Style "*" FocusFollowsMouse Style "FvwmButtons" Icon toolbox.xpm, ClickToFocus Style "xman" Icon xman.xpm, RandomPlacement, ClickToFocus Style "xmag" Icon mag_glass.xpm, RandomPlacement, ClickToFocus Style "XTerm" Icon xterm.xpm, SloppyFocus, IconBox -70 1 -1 -140 Style "rxvt" Icon term.xpm, SloppyFocus, IconBox -70 1 -1 -140
In our sample configuration, the Simple Config Ops submenu of the Root menu offers three items that let you change the focus policy on the fly for the current window manager session: Sloppy Focus, Click to Focus, and Focus Follows Mouse. Note, however, that these items supersede what's in your configuration file for all applications. If you want to recover the more specialized definitions in your configuration file, you'll have to restart the window manager.
If you're using pointer focus (FocusFollowsMouse), you might want to consider also using the FvwmAuto module to automatically raise the focus window to the top. If we add the following line to our .fvwm2rc file, the focus window is automatically raised after the pointer has been in it for 200 milliseconds (one-fifth of a second):
Module FvwmAuto 200
The delay is important and makes FvwmAuto much more practical. When pointer focus is in effect, an autoraise feature can make the display seem chaotic: when you move the pointer across the screen, the focus hits several windows and they are raised in a distracting shuffle. With an autoraise delay, you can avoid the shuffling by moving the pointer quickly to the window you want to focus on.
If you use ClickToFocus mode by default, the autoraise feature is built in and you don't have to make this modification.
Of course, those who adapt to using the FvwmWinList module to transfer focus will have their windows raised automatically, without having to edit their .fvwm2rc file or even move the pointer off the WinList.
One of your menus may also be configured to offer an item that turns on autoraise on the fly and another item that turns it off again. In some default setups, the Fvwm Modules menu features AutoRaise and Stop AutoRaise for these purposes.
Many default configuration files have a default desktop of two screen pages across by two screen pages down, which in the configuration file is defined using the line:
DeskTopSize 2x2
It's easy to change the size of your desktop by editing the dimensions of the grid. Thus, the following line creates a desktop of three pages across by two pages down:
DeskTopSize 3x2
You don't have to have multiple pages in both directions. You can have a desktop of one page above another above another:
DeskTopSize 1x3
You don't even have to have multiple pages at all:
DeskTopSize 1x1
But then why use fvwm2?
Of course, the number of pages you select will depend on your space needs and style of working and whether you will use more than one desktop (described in the next section). If you configure for multiple desktops, each one will have the same DeskTopSize. So if you want a desktop for work and one for play, you may not need each one to have many pages. Two desktops of three-by-three, for instance, would give you a total of 18 pages to get lost on. However, some people, such as graphical artists, may welcome a larger workspace.
In order to work with multiple desktops, you simply have to configure the Pager to display the number of desktops you want. Each desktop will have the same number of pages, the number you specified using DeskTopSize.
To specify more than one desktop, you'll need to edit a line that looks something like this one:
*FvwmButtons(2x2 Frame 2 Swallow(UseOld) "FvwmPager" "Module FvwmPager 0 0")
This line incorporates the Pager into the FvwmButtons module (the button bar). The two numbers at the end of the definition line (0 0) give the range of desktops visible. The first desktop is number 0, and in this case the last desktop is also number 0 (i.e., there is only one).
If you want two desktops, change the final number to a 1:
*FvwmButtons(1x2 Frame 2 Swallow(UseOld) "FvwmPager" "Module FvwmPager 0 1")
The following line creates a Pager with four desktops, numbered 0 through 3:
*FvwmButtons(1x2 Frame 2 Swallow(UseOld) "FvwmPager" "Module FvwmPager 0 3")
Few people require this much space. But even if you add only a single desktop, you may have to change the overall dimensions of the Pager, and thus of the button bar that contains it, in order to have a reasonably sized view of your various desktops. You may also have to reallocate the space you have so that the Pager gets a large enough area.
There are a few relevant sizes you can tinker with to make room for a Pager that shows multiple desktops:
The dimensions of the button bar (FvwmButtons module)
The number of columns the button bar is divided into
How many of those columns the Pager takes up
A typical FvwmButtons module might be 520 pixels wide and 100 pixels high, starting in the lower right corner of the screen:
*FvwmButtonsGeometry 520x100-1-1
And it might be configured as two rows and five columns (the sizes of which are entirely dependent on FvwmButton's geometry):
*FvwmButtons(Frame 2 Padding 2 2 Container(Rows 2 Columns 5 Frame 1 Padding 10 0))
In this particular setup, the Pager takes up a one-column by two-row section of the FvwmButtons module:
*FvwmButtons(1x2 Frame 2 Swallow(UseOld) "FvwmPager" "Module FvwmPager 0 1")
The Icon Manager takes up three columns:
*FvwmButtons(3x2 Frame 2 Swallow "FvwmIconMan" "Module FvwmIconMan")
And the remaining column is occupied by the desktop applications (e.g., xbiff, xclock, xload) that run within a container in the FvwmButtons module:
*FvwmButtons(1x2 Frame 0 Container(Rows 2 Columns 2 Frame 0)) *FvwmButtons(Frame 2 Swallow(UseOld,NoHints,Respawn) "xbiff" 'Exec exec xbiff -bg bisque3') *FvwmButtons(Frame 3 Swallow(UseOld,NoHints,Respawn) "xclock" 'Exec exec xclock -bg bisque3 -fg black -hd black -hl black -padding 0 update 1') *FvwmButtons(2x1 Frame 2 Swallow(UseOld,NoHints,Respawn) "xload" 'Exec exec xload -bg bisque3 -fg black -update 5 -nolabel')
Notice that the container is subdivided into two rows and two columns. The top row contains xbiff and xclock, and the bottom row contains xload, using both columns.
Back to the issue of multiple desktops. If you want two desktops, set that up by changing the number of the final desktop to a 1 at the end of this line, as we did earlier:
*FvwmButtons(1x2 Frame 2 Swallow(UseOld) "FvwmPager" "Module FvwmPager 0 1")
Then, to make the Pager big enough to display both desktops adequately, add some pixels to the width of the button bar. Here's an extra hundred added to the 520 we started with:
*FvwmButtonsGeometry 620x100-1-1
And let's also reallocate the available five columns so that the Icon Manager takes up only two (rather than the three it started with), and give the extra column to the Pager. The section with the applications remains a single column wide:
*FvwmButtons(2x2 Frame 2 Swallow "FvwmIconMan" "Module FvwmIconMan") *FvwmButtons(2x2 Frame 2 Swallow(UseOld) "FvwmPager" "Module FvwmPager 0 1") *FvwmButtons(1x2 Frame 0 Container(Rows 2 Columns 2 Frame 0))
Figure 19-2 shows our new double desktop reflected in the updated button box. This is just one sample customization. With your individual needs and display specifics, you can imagine how complicated this can get. But it's easy to test your changes by simply restarting the window manager.
A window that appears on every virtual screen page is called a sticky window because it "sticks" to the screen. Some windows are designated as sticky in the system.fvwm2rc file, among them xbiff, programs ending in lock (e.g., clock programs such as xclock and oclock), and all the fvwm2 modules (because you need the button bar, Pager, etc., on every page).
If you want a window to be sticky, you need to specify that in your .fvwm2rc file. The specification requires you to use the Style variable, followed by the client's name, and the parameter Sticky. The Style variable is used to set many different characteristics. Here are some lines you might see in a configuration file to establish that a window is sticky, among other things:
Style "xbiff" NoTitle, Sticky, WindowListSkip, ClickToFocus Style "*lock" NoTitle, NoHandles, Sticky, WindowListSkip, ClickToFocus Style "Fvwm*" NoTitle, Sticky, WindowListSkip
Notice that the Style variable can recognize a wildcard character (*) to widen the scope of the definition. The value Fvwm* encompasses all fvwm2 modules.
Now try adding the following line, which specifies that an application called xpostit will stick:
Style "xpostit" Sticky
Practically speaking, you probably also want to specify that xpostit uses click-to-type focus and doesn't appear on the WinList, so this definition is better:
Style "xpostit" Sticky, WindowListSkip, ClickToFocus
In most cases, you'll want only small windows that you run a single instance of (and that you use frequently) to be sticky. Having a terminal emulator like xterm appear on every page would take up too much space. However, if you do want a client like xterm to follow you around, be sure to give that instance of the program a distinctive name using the -name option.
For example, in your X session startup file you can run an xterm you name mailwindow:
xterm -name mailwindow &
Then, to make that window appear on every page, add the following line to your .fvwm2rc file:
Style "mailwindow" Sticky
If you want to make a particular window sticky temporarily, look for an Fvwm Window Ops menu under your Root menu. You will commonly find a toggle to (Un)Stick a Window. Or, you can set up such a menu item yourself; see Section 19.4 later in this chapter.
There's an obvious, low-tech way to start applications on different desktops and on different pages within a desktop: switch the view to the desktop and page you want (using the Pager, keyboard shortcuts, or whatever method you like), open a terminal emulator window (e.g., using the Root menu), then run whatever program you want. Voilà—the application window opens on the current desktop and page.
But there are two automated ways to accomplish the same thing. In the first method, you specify in your .fvwm2rc file that certain programs appear on certain desktops and/or pages automatically when you run them. You do this using fvwm2's Style variable, which takes two relevant options: StartsOnPage and StartsOnDesk.[12]
[12]There is also a StartsOnScreen option that specifies which screen to start a window on if you have Xinerama enabled.
StartsOnPage takes up to three numeric arguments. If there is only one argument, it corresponds to the number of the desktop on which to open the application. If there are three arguments, the second and third additionally identify the page using an X,Y coordinate scheme. We'll come back to this in a moment. Two arguments alone are interpreted as the X and Y coordinates of the page.
And what about the closely associated StartsOnDesk variable? StartsOnDesk takes only one argument: the desk number. But since you can set this with StartsOnPage, along with the more specific page address, in practice there is no need to use StartsOnDesk at all. Although it's still supported, StartsOnDesk is an older option that has been replaced by StartsOnPage.
Now back to desktop and page addressing. Let's consider the addressing scheme of a single two-by-two desktop. Just as the first desk is addressed as number 0, the first page on a desk is 0,0. The next page to the right is 1,0. The third page clockwise (the lower-right quadrant) is 1,1. And the fourth page clockwise (the lower-left quadrant) is 0,1.
Supposing there are at least two desktops of four pages each, the following definition says that when you run an xterm called "bigxterm" it is opened on the second desktop (number 1) in the lower-left quadrant (0,1):
Style "bigxterm" StartsOnPage 1 0 1
Once you make this update to your .fvwm2rc file and restart the window manager, running the command:
xterm -name bigxterm &
opens the window where you want it.
You can accomplish the same thing using X resource syntax on the command line. This strategy may even be a little more practical than putting the definitions in your .fvwm2rc file because you won't have to define many different instances of the various programs (bigxterm, littlexterm, mailwindow, or whatever). The -xrm option (recognized by many X clients) lets you specify an X resource variable on the command line:
xterm -xrm '*Page: 1 0 1' &
You can even put a series of such lines in your X session startup file in order to open applications wherever you want them on your desktop(s) when you log in.
While it looks as if these two methods of opening windows on different desktops/pages (the Style variable with StartsOnPage and the -xrm command-line option) produce identical results, there is actually a subtle difference in behavior. When you use Style with StartsOnPage and you specify only the desktop number, the window is opened on the first page (0,0) of that desk. If you give the same information on the command line (using -xrm), the destination page of the new window is related to the page you're on when you run the command. The new window appears on the analogous page of the desktop you specify.
You have one more alternative if you're interested in opening a window on a different page within the current desktop. Run a window with the -geometry option and supply large enough coordinates to place it on a particular page in the desktop. If you use a desktop three pages square, the following line places a window in the middle page of the nine-page grid:
xterm -geometry +1200+1200 &
Keep in mind, however, that display-specific characteristics play a big part in gauging these distances, and they are not easy to guess.
If you're navigating the desktop by moving the pointer and you find it either too easy or too difficult to go from one page to the next, there's a configuration file variable you can customize. The aptly named EdgeResistance variable lets you adjust how easy it is to move the pointer beyond the perimeter of the current page.
The variable takes two parameters. The first, which is more relevant to the problem at hand, is the number of milliseconds the pointer must remain at the screen edge before you move onto the next page. The second parameter, which has to do with the way a window is moved between pages, is the number of pixels over the edge of the screen a window's border must move before it moves partially off the screen. Typical default settings are:
EdgeResistance 250 10
Some people find that the EdgeResistance they're working with is too low, with the inconvenient result that they inadvertently knock the pointer off the current screen page. If this is your problem, you can increase the first parameter:
EdgeResistance 500 10
A first parameter between 500 and 1000 greatly enhances the resistance. The maximum resistance is 10000, which actually makes it impossible to page over.
If you have the opposite problem and have to bounce the mouse against what feels like a hard rubber wall in order to page over, try reducing the first number:
EdgeResistance 100 10
In a typical default configuration, fvwm2 is set up with menu options that let you change your paging options on the fly. A number of these options are located in the Root menu, in the Fvwm Simple Config Ops menu. Thus, you can toggle the ability to page on and off with Full Paging On and All Paging Off.
All Paging Off limits you to keeping the pointer on the current page. You might prefer this if you're going to be working on that page for a while and you don't want to worry about knocking the pointer onto another page. You can toggle paging back on with the Full Paging On menu item. There are other items to constrain paging in different ways (e.g., Horizontal Paging Only, Vertical Paging Only). The Partial Paging item lets you move the pointer so that the view straddles two adjacent pages; the area you see will be highlighted in the Pager window.
The item Full Paging & Edge Wrap actually expands the range of paging possibilities. Normally when you reach the edge of a desktop, you can't move the pointer beyond it. With this item selected, you can drag the pointer beyond the edge of the desktop and it wraps around to the page on the other side (either horizontally or vertically). Thus, if you have the pointer in the upper-right page of a two-by-two desktop, and you drag the pointer off the right edge, it wraps around to the upper-left page of that desktop.
Underlying all these menu items is the EdgeScroll variable. Here are the EdgeScroll parameters that map to the various menu items:
Full Paging ON EdgeScroll 100 100 All Paging OFF EdgeScroll 0 0 Horizontal Paging Only EdgeScroll 100 0 Vertical Paging Only EdgeScroll 0 100 Partial Paging EdgeScroll 50 50 Full Paging & Edge Wrap EdgeScroll 100000 100000
EdgeScroll's two parameters specify the percentage of a page to scroll when you reach the border of the page. The first parameter is for horizontal moves, the second for vertical. If the horizontal and vertical percentages are multiplied by 1000, scrolling will wrap around at the edge of the desktop. EdgeScroll 100000 100000 will wrap for both horizontal and vertical moves.
Rather than rely on menu items like these, you can make any of these options the default behavior by putting the EdgeScroll variable on its own line in your .fvwm2rc file. See the fvwm2 manpage and check out the system.fvwm2rc file for guidance.
Note that none of these variations lets you scroll from one desktop to another. The next section shows how to configure some keyboard shortcuts to do just that.
|  | |
| 19. An Alternative Window Manager: fvwm2 |  | 19.3. Adding Keyboard Shortcuts |
Copyright © 2003 O'Reilly & Associates. All rights reserved.