A while ago when I upgraded my distribution, several keys went wonky on me and ceased functioning according to my wishes. It was a minor inconvenience to have things like the Caps Lock key become enabled again. So I pecked around at fixing it here and there, but never really put in much thought or effort until today.

I remap my keys with the /etc/X11/xinit/.Xmodmap (aka ~/.Xmodmap) file. The problem was my .Xmodmap was borking when X started, so no remappings were taking place. (If one part of .Xmodmap fails, they all fail.) In my /var/log/Xorg.0.log I found this:


(EE) Error compiling keymap (server-0)
(EE) XKB: Couldn't compile keymap
(WW) Couldn't load XKB keymap, falling back to pre-XKB keymap


And in the output from X – apparently from the keymap compiler (xkbcomp) – were repeated warnings/errors like this:


Warning:   Duplicate shape name ""
                 Using last definition
Error:        Section defined without a name
                 Definition ignored
Warning:   Multiple doodads named ""
                 Using first definition


With a little googling I came across this thread which gave some insight, but was of little help in fixing the problem. This Arch Linux forum thread has several people using various remapping methods reporting the same error. The thread is marked “Solved,” however, the fixes suggested had no effect on my situation. Daedalus’ suggestion of using the “keyboard” driver did manage to provide me with more helpful error messages that pointed out line numbers. This indicated my Caps_Lock remapping was the culprit.

I quit searching on the error messages and began learning more about xmodmap. I didn’t read anything of much use, but I did come across some examples of xmodmap commands I had never used before. I have always used the ‘clear’ and ‘keycode’ commands to disable Caps_Lock and assign different functions to keys, like this:


clear Lock
keycode 66 = Tab


What I found was the use of the ‘remove’ and ‘keysym’ commands to do the same thing:


remove Lock = Caps_Lock
keysym Caps_Lock = Tab


I tried those, and voila! Problem solved.

I wish I could explain why the old method ceased to work, but I can’t. Both methods are still described in the xmodmap man page, and examples of both still exist there as well. The first thread linked above suggests broken data in keyboard-config-1.3 on X Server 1.4.2. I have keyboard-config-1.4 on X 1.4.2, however, so questions remain. Yet despite no explanation, I hope the fix alone will be helpful to others with similar problems.

Finally, here is my new .Xmodmap, which I have enhanced a bit, for those of you curious about it. Explanations for my remappings are in the comments. As for why I prefer to use the xmodmap method for keyboard mapping, there are several reasons. First, it is a single file containing all changes. Those changes universally affect all programs since it is built into the X server. That means no third-party daemon is needed. Also, .Xmodmap is really very easy to configure once you get used to the xev utility. And last, it uses the xmodmap command which I have been familiar with since I adopted Linux – because once upon a time I had to remap the buttons on my mouse in order to get “advanced functions” (read: the scroll wheel) to work. =-)

Çok tuşlu fare ve klavyeleri seven bir yapıya sahip olduğum için Windows altında kullandığım multimedya özelliklerini Linux altında kullanmak istiyorum ben. Bilmiyorum haksız mıyım. Eğer sizin de 6-7 tuşlu fareniz var ve tuşları aktif değilse aşağıdaki yöntemi kullanabilirsiniz. (Anlatımın orjinali İtalyanca bir sitede. Girmek için buraya tıklayabilirsiniz. Türkçe’ye çeviren arkadaş için buraya tıklayabilirsiniz. Ben onun anlattığı yöntemi kendi uyguladığım şekliyle anlatacağım)

Öncelikle evdev adlı pakedi güncelliyoruz. Bunun için Uygulamalar -> Donatılar -> Uçbirim yolunu izleyerek terminal açıyoruz ve aşağıdaki kodları sırayla yapıştırıp entera basıyoruz:

sudo apt-get update
sudo apt-get install xserver-xorg-input-evdev

Ardından yine terminale aşağıdaki kodu yapıştırıp entera basıyoruz:

cat /proc/bus/input/devices

Bu komut ile sisteme takılı donanımların listesi terminalde görünecektir. Buradan farenizle ilgili kısmı bulun. Benimki şöyle:

Handlers yazan satırdaki event kısmına dikkat etmek gerekir. Ben kendiminki olan event4 olarak devam ettim işleme. Siz de kendinizkine göre devam edin.

Şimdi xorg.conf adlı dosyada birkaç değişiklik yapacağız.

Önce bir yedeğini alıyoruz:

sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.yedek

Herhangi bir sorunda kurtarma modunda aşağıdaki kod yazılarak geri dönüş yapılabilir:

sudo cp /etc/X11/xorg.conf.yedek /etc/X11/xorg.conf

Sonra düzenlemek için xorg.conf dosyasını açıyoruz. Benimkinin fare ile ilgili kısmı şöyleydi:

Burada birkaç değişiklik yapmamız gerekiyor. Öncelikle ilk satıra yani Identifier yazan satıra dokunmuyoruz. Altındaki satırdaki “mouse”u “evdev” yapıyoruz. Onun altındaki satırın başına # koyuyoruz. Böylece o satır etkinsizleştirilir. Dilerseniz o satırı silebilirsiniz de. Bir alt satırdaki “/dev/input/mice” kısmını “dev/input/event4″ yapıyoruz. Tabi event4′ü herkes yukarıda event numarası kaç ise ona göre değiştirmelidir. Benimki event4 olduğu için öyle yaptım. Bir alttaki satırı ellemiyoruz. Onun altındaki satıra yukarıda terminalde faremiz ilgili kısımdaki Name’in karşısındaki değeri yazdım. Yani “A4Tech PS/2+USB Mouse” yazdım. İtalyanca sitedeki şahıs,  “A4Tech X7″ yazmış. Sonuç olarak

Option          "Name"	"A4Tech X7"

diye bir satır eklenmelidir buraya.

Daha sonra bir alttaki satırın başına da # konur. Böylece o satırda etkinsizleştirilir. Benim xorg.conf’umun fare ile ilgili kısmının son hali şöyle:

Kaydedip kapatıyoruz. Sistemi yeniden başlatıyoruz.

Şöyle bir kod daha var ama ben bunu çalıştıramadım hata verdi. Olmasa da olur sanırım. Eski sürümler için olabilir.(benim sürüm 9.04):

xmodmap -e "pointer=1 2 3 4 5 8 9 6 7"

Terminale şu kodu yazıyoruz şimdi de:

xev | grep button

Şöyle bir pencere açılacak:

Bu pencerede farenin tuşlarını basarak terminalde kaç numaralı tuşa denk geldiğini görebilirsiniz.

xmodmap’in varsayılan sırası şu şekilde: 1 2 3 4 5 8 9 6 7

Buradaki 8 ve 9′a dokunmuyoruz. Onlar farenin kendi ayarları ile ilgiliymiş.

Sıra Xmodmap’i kendimize göre düzenlemeye geldi. Bunun için terminale aşağıdaki kodu yazıyoruz:

gedit .Xmodmap

pointer=1 2 3 4 5 8 9 6 7

Introduction

When I was first preparing to switch to Linux many years ago, I went into research mode and looked around the net a bit. At the time, part of the allure of Linux were the crazy cool desktops people had. After I switched I tried Gnome, then KDE, and was depressed at how uncool and *dozelike they were. Eventually, I discovered that all those amazing desktops were the result of Fluxbox (or the other *box forks). I switched immediately.

To my surprise, I found that not only was I able to get a really cool appearance, but Fluxbox made all the things I wanted out of a window manager, and some I didn’t know I wanted, simple. It turned out that I was not the only user to have noticed those operating system limitations and failings I’d been grumbling about for years, particularly with *doze. The Fluxbox crew apparently knew my pain and had gone about addressing all of those complaints.

For example, one particular thing I had tried way back in the dark years was a DOS script to launch a bunch of applications at bootup with attempts to get them to their proper window sizes and such. It worked in a very limited fashion. Controlling *dows startup folders and services by their methods is a joke. It’s just poorly implemented by Microsoft, and while certainly better in Linux, still not exactly perfect. Fluxbox handles this as elegantly as one could wish.

You see, as a guy with a programmer background, repetition of effort utterly disgusts me. So when I restart my computer or even just a program, I absolutely detest having to resize and relocate windows to the way I had them before the restart. Just having to restart apps after reboot is too much wasted effort and time. With Fluxbox I found a solution to this issue completely built in, along with many, many more time-saving ideas. In a word, it’s brilliant.

Many people’s first reaction to seeing a Fluxbox desktop is to be taken aback by its barren aspect. They notice the complete lack of pretty little icons and don’t quite understand the spartan nature of it. Well, it’s like this: If everything you use on a regular basis already starts for you, and the rest either has keyboard shortcuts or can be found in a moment in your customized menu… what the hell do you need pretty little icons covering up your badass desktop image for? That’s not to say you can’t have pretty little icons if you want, but Fluxbox defaults to a simplistic, stay-out-of-the-way style.

In the following article, I will describe my particular layout of the Fluxbox desktop: workspaces, monitors, and applications. While technically not part of Fluxbox itself, part of what makes those Fluxbox desktops so cool are the terminals, so I’ll give a fairly in-depth explanation of my aterm setup. Most Fluxbox descriptions, the Fluxbox website included, describe things entirely by files, so I think I’ll try to use a chronological approach wherever possible. To this end, I will next discuss the X/Fluxbox startup script sequence, and show you what happens as I start Fluxbox. After that, I will talk about the heart of Fluxbox: the configuration files. Finally, I’ll wrap up with some other features and things worthy of notice. I hope you enjoy and benefit from my experience.

My Fluxbox, Let Me Show You It

This is my Fluxbox. There are many like it, but this one is mine. My Fluxbox is my best friend. It is my life. I must master it as I must master my life. Without me, my Fluxbox is useless. Without my Fluxbox, I am useless. rAmen.

Fluxbox, like many other window managers these days, allows for having multiple desktops. In Fluxbox these are called “Workspaces.” I usually use five workspaces, each devoted to separate purposes, and thus, each have specific applications. Let me describe them for you, but first let me note that all my workspaces are two monitors wide despite some images being cropped to show only the primary left-hand monitor.

For now, let’s skip over the first workspace. The second I use for web browsing with Firefox or Seamonkey, as well as Open Office documents. Between multiple FF windows and several documents, this workspace can get pretty crowded at times.

On my third workspace I keep two Bluefish (a simple text editor) projects of eight or so text files each. One of these projects is for Linux notes, commands, simple howtos, etc. The other is for things like to-do lists, shopping lists, books/movies/tunes to get, etc. I’ve found I’m far more likely to take note of things if these files are already open for editing, so devoting a workspace to having these simple files permanently open works really well for me.

The fourth Fluxbox workspace I keep my file manager on; at the moment I’m using XFE. I also do my torrenting from here, and basically anything media related. And the fifth is my workspace for actual work. I usually have a couple terminals open, maybe some editors, I use the Gimp here, etc.

Now back to the first. On it I have seven terminals sized to fit together nicely and display various bits of useful information. I tail /var/log/messages, debug, syslog, secure, and my current X session’s log (I redirect the output of the startx command to this log file). I use one terminal for displaying disk usage info, and I have one that I use every once in a while for brief commands (frequently process kills).

I happen to have two monitors, the second of which is smaller and always displays XChat no matter which workspace I’m using. This is called the “Sticky State” in Fluxbox. I also run GKrellM in what’s called the “Slit” which is the Fluxbox method for keeping docked applets permanently visible and outside the normal Fluxbox window rules. In this way, GKrellM always shows across workspaces, and maximized apps do not cover it up – although like everything else with Fluxbox that behavior can be changed.

I keep my Fluxbox Toolbar at the top and only across the left-hand monitor, and I let it autohide itself. I usually have four apps in the System Tray: XChat, KMix, KTorrent, and Amarok, none of which show up on the Iconbar portion of the Toolbar; the Iconbar being the primary section that displays icons for each app open on that workspace; the Toolbar being the whole thing, clock and all (some definitions).

All of these programs start automatically when I start X/Fluxbox. They always start exactly where I want. They all start at the proper sizes. My two Bluefish projects start opened. XChat starts stickied on the right hand monitor. KMix, KTorrent, and Amarok all start minimized to the Sys Tray. I no longer suffer monkey-like duplication of effort. It is perfection.

You might also note that I leave a small corner of the desktop visible under GKrellM. This is so I can right click to access the Fluxbox Root Menu easily. I have a keyboard command that will pop it up, but as counterintuitive as it might sound, the mouse seems to be the easiest for me to do this. I also have set Fluxbox (via the Keys file) so when I mouse over the desktop and scroll the mousewheel up or down, I scroll between workspaces. Between accessing the menu and flipping workspaces, having a tiny portion of the desktop showing is very convenient and not at all a waste of real estate.

Next page: Aterms

Aterms

Firstly, all those cool transparent terminals you see are usually aterms (or eterms). These are extremely lightweight (non-UTF8), highly customizable terminals. Though not a part of the Fluxbox project, the question of how to get these cool-looking terminals often goes right along with the adoption of Fluxbox, so I’ve decided to cover them by describing my setup.

I have 11 predefined terminals of varying sizes and locations that start in specific directories with various commands issued. For example, aterm0 is a full screen terminal that opens with htop started, so if I think I’ve got a runaway process I just use the keyboard shortcut, and instantly there’s the culprit. The 7 terminals that open in my first workspace upon starting Fluxbox are each separately defined. I also have a fairly large aterm that I use for general purpose command line work.

I define all of these in my my .bashrc, and I do this by two methods: by bash shell aliases, and by creating single-line bash scripts that contain the aterm commands. The aliases let me start these aterms from the command line of existing terminals. The scripts let me start these aterms from other applications and the Fluxbox root menu. The execution of initial commands when these aterms are started is controlled through a case statement that checks the aterm’s terminal name definied in $TERM which is set in the aterm command by the -tn switch.

Let me describe what is happening in each part of my .bashrc. First, I set each aterm command parameter as a bash script variable, then use those in the commands themselves in order to make the commands more legible, as well as allow me to have notes for each parameter. This is where options like transparency/shading, background color, and font are set. Next, I create the full aterm commands using those parameter variables (and others), and save them into 11 individual variables ($ATX, $AT0… $AT9). It is those 11 variables that I then echo into scripts placed in /usr/local/bin. And those variables are also used as the aliases for this bash shell instance. Note that after I create the scripts the first time, I comment out the echo commands so as to not repeat unnecessary work each time a bash shell is opened: define/create them once and then leave them alone until something changes.

After the definition of the aterm commands, comes the check for whether or not I want to perform any additional commands. The .bashrc file is always run when a new shell is opened, but that does not necessarily mean that I wish to do anything more. For one, I could be within the Linux console (TTY1) without a window manager or X running at all, in this case I don’t want to do anything further, so that is the first test.

The next test is to see which aterm type it is dealing with. This is the reason that I used the -tn switch to name the global system $TERM veriable, and I gave each predefined aterm a different name based on which function it is fullfilling. So for example, the case statement checks to see if it is aterm0; if so it changes directories, and executes /usr/bin/htop. But here you should note that in all cases, I change the $TERM variable back to the default, “xterm”.

This is for the other major test taking place in the case statement: it is checking to see if the aterm is a new window, or if a new bash shell is being opened from within an already existing window (e.g., via su, bash, or even if merely .bashrc is being executed to load new settings). To walk you through it: the first time an aterm is opened the aterm command will set $TERM to “aterm0″ (for example), .bashrc will then be run, when it gets to the case, it will see that it is not the console, and then seeing that it has instructions for “aterm0″ it will execute the commands there, including changing the $TERM to “xterm”. Later, after I have closed htop, I continue to use the window and su into another user. A new bash shell is started within the existing window, but when .bashrc checks if it should change directories and run htop again, it doesn’t because it is no longer named “aterm0″.

That’s how I set up and use my aterms. If you want you can remove the aterm title bar, the scroll bar, and make it entirely transparent. Or you can put an aterm in the “Slit,” thus putting text on your desktop – which is pretty damn cool. Take a look at this Howto for some more details. I personally keep mine only somewhat transparent so that I can more easily read my terminals. It’s really a trade off between coolness and readability, and the readability is very dependent on your background image, font, and font colors. When I change backgrounds I frequently change my aterm settings as well.

I know that aterms are not part of Fluxbox, but to me the two go hand-in-hand. I’ve spent quite a bit of time figuring and perfecting a method to get aterms of various sizes at a whim as well as upon startup. If you decide to toy around with your own aterm setup, this will probably be the biggest time sink by far as you tweak and tweak and tweak, compared to setting up Fluxbox. Feel free to use my method and good luck.

Next page: Fluxbox Startup

Fluxbox Startup

I use Slackware for my OS and I always start X from the command line so your mileage may vary a bit here. Please bear with me as this gets a little confusing. My description will follow the chronological sequence.

When the startx command is issued the startx script executes xinit, a binary. Among other things, xinit will try to run your system’s xinitrc script(s). These can be in various locations (e.g. ~/.xinitrc or /etc/X11/xinit/xinitrc), but I believe the most common location is /etc/X11/xinit/xinitrc. That script then runs a default system startfluxbox script, which then typically runs the default user’s startup script, which in turn starts the Fluxbox binary. I have altered this sequence so that for me it goes like this:

1. The xinit binary starts X using files like /etc/X11/xorg.conf and ~/.Xdefaults,
2. The xinit binary then runs the xinitrc.fluxbox script,
3. xinitrc.fluxbox merges my /etc/X11/xinit/.Xmodmap into the system’s generic settings,
4. xinitrc.fluxbox then runs the /usr/bin/startfluxbox script,
5. Which in turn executes the /usr/bin/fluxbox binary using the ~/.fluxbox/init file settings.

I am not a fan of the somewhat recursive nature of Fluxbox’s “startup” scripts. Fluxbox has designed them to cover the contingencies of a first-time user, a user with no startup script, and users with their own startup scripts. I understand the reasons for this, but since I’m on a single-user system, I just don’t need all this. And quite frankly, it confuses me. So I’ve eliminated a user-specific startup script, and I’ve whittled down the scripts in my sequence to using as little code as possible. Then as a matter of trying for standardization, I separate my X settings from my Fluxbox settings.

You do not have to have an .Xdefaults, and mine is used strictly for color settings; the rest of my X settings I take care of in xinitrc.fluxbox. My .Xmodmap is strictly X level keyboard mappings (like changing the Capslock key to Tab). I keep my Fluxbox settings in startfluxbox (namely, I set the background image here). Some people put all their Fluxbox settings with their X settings in xinitrc.fluxbox (I used to). Some people prefer to use more of Fluxbox’s built-in methodology for much of this stuff. Others put all their X settings in .Xdefaults. None are wrong; it’s a matter of preference. I try to keep it simple to help me keep it all straight.

Let’s look at some of these files. Of interest in my .Xmodmap I map the right Alt, Ctrl, and Windows (Super) keys to their equivalent left side keys. This is important for getting the same behavior out of each. Later I’ll talk about the Fluxbox Keys file, which can get some unexpected results if you don’t do something like this.

Now check out my xinitrc.fluxbox script where I do most everything X related. The early stuff should be pretty self-explanatory. I do a bunch of xset commands (which can be done in an .Xdefaults or various other locations). After that I do something different from most people. Rather than use a ~/.fluxbox/startup script to start apps, I run the /usr/bin/startfluxbox in the background and grab its process ID number, execute all the apps I want, and then hang there waiting until Fluxbox finishes. This is an old method that has the advantage of allowing me to execute commands after Fluxbox starts but not from within it. In other words, these apps are started from X, not Fluxbox. X won’t allow you to start applications without a running window manager, so you can’t just execute them prior to starting Fluxbox. There are various advantages and reasons for doing this, but for me its mostly about to which files I log. It also lessens the number of files I deal with.

Next we have my system startfluxbox script called from xinitrc.fluxbox. I set my background here because I want to get the image up as quickly as possible so I don’t see any default color flash for a moment. Most people just use the method Trent mentioned with the rootCommand option in the Fluxbox Init file, and it works fine. I’m just trying to squeak a couple microseconds out of it. I’ve played extensively with this, and there are several other things you can do (like using X to set the background as commented out in my xinitrc.fluxbox – very dangerous), but ultimately I decided that this is the best method for me. It’s a little faster, and again it lessens the number of files I use for configuration.

Notice that I’ve cropped quite a bit out of this script and out of the whole normal Fluxbox startup sequence as this is the only startup script to be called. At this point the Fluxbox binary launches, which brings us to the Fluxbox config files….

Next page: Fluxbox Configuration Files

Fluxbox Configuration Files

There are really five major config files that you’ll be directly editing for Fluxbox, and one you won’t. They are:

• The Init file which with the exception of the rootCommand option, will probably never be edited by hand, and which holds all the settings for Fluxbox as a whole.
• The Apps file which defines the “States” and “Decorations” of each application (and in most cases, each application’s sub windows) such as dimension, location, its workspace (desktop), etc.
• The Startup file which, as mentioned above, is used to specify the apps you wish to launch at startup.
• The Menu file which sets up the Root Menu tree and all the apps contained therein.
• The Keys file which defines your keyboard shortcuts.

The defaults for these files are located in /usr/share/fluxbox, and personalized ones are located in ~/.fluxbox/. I personally make symlinks pointing from /usr/share/fluxbox/ to /etc/skel/ and from there to my home directory files. This prevents any accidental erasures, and keeps the default files I want to propagate (my home ones) to any potential new user accounts located in the standardized /etc/skel/ directory.

Init

First, let’s start with the file you won’t be editing by hand (or mostly won’t), the Init file. This is the file that contains all the settings for Fluxbox which you can set through the “Fluxbox Menu” part of the Root Menu. This is stuff like the Fluxbox Style you are using, the Toolbar settings (autohide, location, right or left justified), the number of workspaces, Slit behavior and placement, window behavior and placement, tab behavior, etc, etc, etc. The easy customization of all this is one of the greatest advantages of Fluxbox. There’s little to misunderstand here, and trial and error will help with what few things you may not guess by their names. When you make changes via that menu, the settings are saved into the Init file and so there is little need to edit by hand.

As touched upon above, you can execute a command with rootCommand within the Init file, and this is often used to set the background image for your desktop. At some point in your tweaking, you may try to execute more than one command within Fluxbox right when it begins, say like setting the background and opening an aterm, but rootCommand doesn’t like what you’re trying to do. The way to get around this is to write a small bash script with all the commands you want to issue, and then run that script from rootCommand. This might be obvious to some, not so much so to others. I tried a lot of things before figuring out the single command limitation, so I thought I’d mention it.

Apps

Left to its own devices, Fluxbox will edit the Apps file on its own, and you may never mess with it. The Apps file stores the settings you make for each app and each of its sub-windows (e.g., dialogue boxes). One can’t really talk about this file without talking about “States” (and “Decorations”). Window states are properties of how a window should act (and look) within Fluxbox. Maximized is a state, as is Iconified or minimized (i.e., reduced to an icon on the Iconbar part of the Toolbar). Sticky is a state meaning the application will cross from one workspace to another rather than just be limited to its assigned workspace (which is the opposite, and default, state) or whichever workspace it was started in. Transparency is available as a state for those who love their desktop image or are looking for that, “Wow!” reaction from their friends. If you right click on an application’s Titlebar or Icon, you’ll be given a list of states to change for that session. And to set a default behavior for a certain app, you simply check the states you want to apply in the “Remember” submenu. But note that there are other states that you can set that are not listed in the menu, which can be set in the Apps file.

A great example of states is my XChat app. If you recall, I have it on a second monitor to the right of my primary monitor, I have it there all the time as I basically devote that monitor to it. This means I have it set to “[Head] {2}” the second monitor, and “[Sticky] {yes}” so it will stay visible for all workspaces; and because its always visible, I don’t particularly need its Icon on the Iconbar along with other apps, so I have set it “[IconHidden] {yes}” which is not a standard option. For positioning Xchat I set “[Position] (UPPERRIGHT) {0 0}” meaning from the top right corner of my desktop, right justify XChat’s window from pixel x=0,y=0.

With XChat I have it stickied, but with Firefox I always keep those windows on workspace number two, or simply “[Workspace] {2}”. Of course, when I do want to move a Firefox window to another workspace, I simply make it sticky and switch workspaces (which can be done with no more than a click or keyboard shortcut). The Apps file is default behavior, not a hard rule.

Do you start to see the power and control you get over your system with Fluxbox? No more opening the same apps over and over again, and no more maximizing them and rearranging other windows. Once your Apps file is set up for all your programs, you’re golden. And it really doesn’t take any longer than the first time you open the app, set the window where you want it, right click on the Titlebar, and check off what states you want to remember in the menu. That’s it. There are a few like IconHidden that you have to set by editing the Apps file, but the vast majority of setup is GUI driven (if that’s what you want) and automated.

Startup

The Startup file is used to specify which apps should begin at startup. You can do other things in it, but this is the primary purpose for which it’s used. As mentioned above, I cut the user version of this file out of the startup sequence for simplicity’s sake since I’m on a single-user system. Most people will use it as intended.

Menu

I’m not going to talk much about the Menu file. It’s pretty self-explanatory and Trent already covered it well. You can add any app on your system to it, or remove any that were automatically added during the initial menu generation. And you can generate again by hand with the Fluxbox command “fluxbox-generate_menu”. There are several command line options you can give like -k makes a KDE menu, -is does a wider search for apps, -w sets homepage for console browsers, -m sets the Root Menu title (e.g., fluxbox-generate_menu -k -is -w http://www.google.com/webhp -m `hostname`). If you want to start with a more complete list of apps on your system and then slim it down, you might want to play around with this command. Use -h to see more options.

Keys

OMGILUVKEZNBBQ! Seriously, I cannot tell you how much I love this feature of Fluxbox. For those gamers or even occasional gamers amongst you, if you’ve ever played a first person shooter or flight simulator, you realize immediately that there are way too many commands to learn right off the bat, so you learn a few keys, go practice until you’ve got them memorized, then come back to learn more. Hell, practically any game these days will actually walk you through learning the basics, then you start playing, and the game itself will teach you additional commands as you go. That is precisely what you have to do with your Fluxbox keys file, and once you do, you’ll never go back to any other window manager.

I mean, the other parts of Fluxbox are wonderful. Fluxbox is so fast and light. The Apps file is an unbelievably huge time saver. But the real juice is in the Keys. Sure, you can get many of the same effects with X, and there are daemons you can run that do the same thing, but the X methods are complex and a real pain, and the daemons are just that: yet another program forever running on your system eating away at your resources. With Fluxbox, this is just part of its basic behavior, and like the simplicity of other Fluxbox settings, the Keys file is pretty damn easy.

But I’ve gotten ahead of myself, first the explanation: The Keys file is a config file that maps keys (and mouse/joystick/whatever events) to certain actions on your computer. For example, Ctrl+Alt+Delete, the good old “three finger salute” that everyone knows and loves is typically mapped to a system reboot; Alt+Tab is usually for window switching. On a more basic level, the Tab key is mapped to the Tab action, the Q is mapped to print q, the 1 to print 1, etc. But all these can be changed (remapped) if one were so inclined.

With the Keys file, you can map pretty much any keystroke or strokes to any action or actions. That’s not to say that you should go remapping the a to the f and so forth, but you would not believe how much time you can save when you don’t have to take your hand away from the keyboard. For example, using Alt+Tab to repeatedly switch back and forth between two apps as compared to grabbing the mouse, moving it to the Toolbar, selecting the other app, then selecting the point in the text where you want to paste, etc. This is clearly a simplistic example. Those reading this article have likely long since started avoiding the mouse, if not become devoted vi fanatics. But to drive home the point to those who still love the mouse, let me ask you this: Have you ever had to help your mom/uncle/friend with their computer, and having told them to switch to the other program, then had to watch and wait while they muddled through using the mouse to do something that you know is nothing more than a flick of the left wrist away? Yeah, it’s infuriating to behold the needlessly slow.

The guys who created Fluxbox understand this, and they’ve built in functionality that dramatically saves you time. This is my Keys file. It’s actually not all that huge compared to some I’ve seen. Note that the damned useless windows keys are no longer useless and are just another modifier key like Control and Alternate. You know those eleven aterms of mine? Well opening one of them is as simple as the windows (Super) plus a number, or Super+a for the eleventh one. Super+f opens a new Firefox window. Super+k kills the current window/process while Super+c just closes it normally. Alt+Tab switches between windows, and Super+Tab switches between desktops. Add the Shift key to either of those key combinations and they cycle in reverse order. I even have one for going into a screensaver lock (xlock), and another will shut off my monitors by sending a DPMS shutoff command.

One of the most often used are the various resizing and repositioning keyboard shortcuts. Almost daily, I’ll open a work aterm with a Super+a, and immediately do an Alt+Super+LeftArrow which moves it to the left edge of the screen, then Alt+Super+UpArrow which moves it to the top. In three strokes I’ve started a shell and moved it out of the way. A keypress further and I’ve opened another work terminal in the default position (center of the screen) for primary use; the other is for backup, often open to man pages or logs. Other key combinations move or resize by 20 or so pixels. Others maximize horizontally for me to read something easier, and then sends it back to the size it was before. Or maximize and then back.

The speed with which I can move things around, flip between workspaces, execute one app, close it, and then flip back to another is incredible. It was this sort of power that I always wanted out of a system, and Fluxbox makes phenomenally simple to set up and use. Add to that the excellent handling of default application positioning and other states, and you’ve got the recipe for working without having to waste time with simple appearance/usability issues. You focus on doing the things you want to be doing rather than being forced to repeat the same ridiculous actions over and over. It’s a beautifully streamlined interface.

Next page: Other Stuff and Conclusion

Other Stuff

Tabs

I don’t think it would be fair to any discussion on Fluxbox to fail to mention Tabs. Everybody loves tabs. Tabbed browsing has taken web browsers by storm. Tabbed file managers are becoming the next big thing. It should be no surprise that Fluxbox has had tabbed windowing for years.

Fluxbox allows you to merge several applications’ windows together into one… for lack of a better term: unit. The unit then has tabs for each application that you can flip between. You can move the unit around on the workspace, move it to other workspaces, etc., and thus, all the apps move around together. The unit then has a single icon in the Iconbar, and all the apps then share other states as well. Some people call this the best feature of Fluxbox.

Personally, I don’t use this feature much, but I can think of the advantages. For example, say I hated multiple workspaces, and thus, needed to have all my apps on one. My Iconbar would be packed full, and I wouldn’t be able to see any information in them. With tabs I could lump my three or four Firefox windows into one, and all my Open Office docs onto another, then my two Bluefish projects into one, all the Gimp windows into one. Suddenly I’d have reduced the number of icons down to four, a far more manageable number.

Extensions

There are many third party apps developed to work with Fluxbox to extend its functionality. For example, if you absolutely adore those pretty little icons on your desktop, you can use Fbdesk or Idesk to get them back. Try Google and the Fluxbox Wiki for more.

Styles

Fluxbox comes with a great number of “System Styles” or “Themes” which allow you to change the basic appearance of the Toolbar, Root Menu, window appearance, etc. Fluxbox also allows you to have other “User Styles” which are simply placed in the ~/.fluxbox/styles/ directory. There are hundreds of User Styles available for download off the net, but one can also go about creating one’s own. Personally, I tend to find a style close to what I want, then make changes to please my overly critical eye. This is remarkably easy as styles are defined in a single text file that is not too complicated. This guy has some more information. Styles, both System and User, are easily changed via the Root Menu.

I think I should note here that the Fluxbox style will likely not do everything you want. To get the complete look you’re after, you also have to change your GkrellM theme – if you use it – of which 191 themes are available in a single tarball here (untar into ~/.gkrellm2/themes/).

More importantly, many applications use what is called a GUI toolkit for designing their windows. There are several toolkits in use on *nix systems, predominantly GTK (most Gnome apps) and QT (most KDE apps). Some GTK themes are available here. It doesn’t matter where they are placed as long as in your home directory you link .gtkrc and .gtkrc-2.0 to the appropriate files in the theme’s directory (should be obvious). QT can be changed in several ways: if KDE is installed you can use the kcontrol app, and on some systems you can use qt3-qtconfig. There are also various third-party apps that allow you to use one theme for both GTK and QT toolkits.

Conclusion

Between your Fluxbox style and your GTK/QT style, with perhaps a little editing by hand, you should be able to get the look you’re after. Add in a similar GkrellM (or other applet) theme, a really cool background image, customize some aterms, and you’ve got that badass Linux system that makes your geek friends drool and your *doze friends start asking how hard it is to learn Linux.

But while you can really impress with the appearance of Fluxbox, that won’t be why you stay with it. Much of what you can visually do with it can be accomplished with other window managers, although the task might be a tad more difficult. Beyond the superficial lies the truly brilliant design that ties all the functionality for highly efficient day-to-day operation into a mere handful of easy-to-edit text files. And once you really start using that functionality, when you try to flip back to other window managers you’ll find yourself increasingly frustrated by their failings and limitations, and asking the bewildering question, “Why don’t they just implement something simple to fix this – like Fluxbox?”

I’ve been using setxkbmap in combination with xmodmap to get my system to use Swedish Dvorak with swapped Ctrl/Caps Lock for quite some time now. Little did I know that simply using setxkbmap alone does the trick:

setxkbmap se dvorak -option ctrl:swapcaps

The title for this post is extremely descriptive. Here, I will present my solution to the problem I’ve been having with getting my keyboard layout to work as follows:

• Use Swedish Dvorak
• Swap places for Ctrl and Caps Lock
• The “Windows key” should be a separate modifier

Here’s the solution

I like my EeePC 901, though the missing navigation keys hit me a bit, and getting a pipe symbol (|) with one hand is wrist-flipping (AltGr+Function+Y [on a German keyboard]). I knew I had to fix that, and now I’ve done it.

As a solution, I set up some alternative keys to trigger:

• lesser than
• greater than
• pipe
• Home
• End
• Prev Page/Page Up
• Next Page/Page Down

Note: This article is going to be a bit more long. Hence, if you want, you can just skip to the howto. Oh, and by the way, the solution provided is for the X server, not for Windows.

(CC) BY-NC-SA I'mNannie / Flickr; example EeePC keyboard (en)

For the navigation keys, initially I thought I could just reuse the given navigation keys Up/Down/Left/Right by hitting them while holding down AltGr. Though, that didn’t work, so I had to find some new keys to use. As I am a right-handed person and as I don’t want to occupy the other hand for navigational tasks too, the right side of the keyboard is the only choice.

In that area we’ve got the AltGr key available as a modifier. Also, there is a mouse menu key — pretty pointless as the big touchpad is right next to it. So, alternatively, I could use that mouse key as another modifier key. But it turned out that didn’t work, so I have AltGr as the only modifier available.
 

Since I couldn’t reuse the menu key in any other obvious beneficial way, I decided to make it become Page Down. Of the missing navigational keys, Page Down is the most important one since on web pages and other large documents you start at the top and want down, not upwards. In browsers, usually the spacebar works also, but in editors hitting the spacebar gives you a space, not a Page Down.

Next, Page Up, since Page Down is rather silly. So what key to use? — I picked ‘.’ (period) since its almost straight North of the menu key.

Since there’s no other use for the menu key, I made the menu key be Page Down without any modifier to be held down, though to stay able to use the period as usual, to make it be Page Up, it must be used together with the chosen modifier, AltGr.
 

On trying out AltGr as a navigational modifier, I learned that it’s cruical to be able to use the key-to-be-modified with the middle finger, and that conveniently. So, choice what to use for Home and End became quite restricted.

I selected L and the character second-right to it, ‘Ä’ on a German keyboard. — I left the one-key gap in between since the keys out there in the periphery are a bit more slim, and the L/Ö alternative felt not as convenient as using L and Ä.
 

On the issue about the lesser-than and greater-than symbols as well as the pipe one, I chose to keep them in the bottom left corner of the keyboard. In German layout, the bottom left key is Y.

Originally, to get a Pipe, you need to press AltGr-Function-Y. Doing this one-handedly requires quite a bit of training, but still you often will achieve AltGr-Y only, which gives you some angle-bracket like quotation mark.

Also, to get a greater-than character, you need to perform a similar bit of keyboard artistic — AltGr-Shift-Y.

That’s a bit inconvenient. Instead, I decided to untangle those four characters a bit: I want a two-keys combination at max. That is: AltGr+Y gives lesser-than, AltGr+X be greater-than. And for purpose of convenience I put the pipe North of X and Y: AltGr+S gives Pipe. Perfect.
 

Sidenote: The key next to the backspace, on a German keyboard layout is rather pointless: Originally, it features the single quotation mark and the backtick, though there’s another key nearby, featuring the very single quotation mark and the number sign — and AltGr gives you the backtick too. As AltGr+# or Shift+’ is the same number of keystrokes, alternatively, you could dump the key next to the backspace completely and put lesser-/greater-than and pipe there. — I did not so because I learned about AltGr+# only after I was done with configuring, and you might also want to keep the usual keys (like single quotation mark/backtick) untouched.
 

How To Do It

Here is how I applied the modifications:

First, XModMap is the tool of choice.

On the console, I retrieved the current, i.e. system-given, settings for my keyboard by xmodmap -pke. I immediately stored that output to ~/.xmodmaprc where it will be read from, each time I’ll re-login: $ xmodmap -pke > ~/.xmodmaprc

I opened ~/.xmodmaprc, skimmed through it to find the key occupations I was after: Y, X, S, L, Ä, period, menu key. As that’s not what you are interested in, here’s just what the respective entries look like in my modified ~/.xmodmaprc now:

• keycode 39 = s S bar section bar section
• keycode 46 = l L Home Left Home Left
• keycode 48 = adiaeresis Adiaeresis End asciicircum End asciicircum
• keycode 52 = y Y less guillemotleft less guillemotleft
• keycode 53 = x X greater guillemotright greater guillemotright
• keycode 60 = period colon Prior division Prior division
• keycode 117 = Next

If you, as I do, never log out of your current session (due to the convenience of hibernate mode), you can make the changes work immediately, without any need to restart the session first: On a console, for every of the above keycode lines, issue a

$ xmodmap -e "keycode line“

Notes: You don’t need to be root to gain the effect. And everything will be in effect just after you issued the modification command. To undo any modification, just restore the original look of the keycode line from the editor, then issue that by another xmodmap -e " ... ".

So, everybody having a good holiday?? As for me, I got unlucky with my super sleek and shiny laptop and its motherboard got fried. So, for quite some time I was relegated to using a laptop which

(i) had a Spanish keyboard, on top of which I was using German and English layouts (oh yes, even for programming ), and

(ii) had the period/colon key missing (it had been ripped off), so I was using another keyboard connected via a USB port to type my periods and colons whenever they came up. And no, I could not only use the USB keyboard because that one in turn had some keys not in the best working order (!!! wait, it gets better soon !!!)

After bearing with all this for quite some time, I thought there has to be some way I can map the period/colon key to one of the keys I am not using, for example Pause, F12 etc., and do away with the additional USB keyboard, and thus make things a little better. So I finally stumbled upon Xmodmap, which my Ubuntu was pre-equipped with, of course, and figured out a simple way to accomplish the task at hand.

Use the following at the command line:

xmodmap -e "keysym Pause = period"
xmodmap -e "keysym F12 = colon"

And you’re done! Now Pause prints the period and F12 prints the colon, no matter whether you are using the German, English or Spanish layout. I guess if you put “period colon” together then the later character will be printed with shift, but I didn’t experiment with that.

I tried putting these lines in my .xinitrc file and then in my .profile, but for some reason it doesn’t seem to be running automatically when the computer boots. For the time being I am having to do it manually every ime the computer starts afresh.

Here is a list of all the “keysym” codes you can use with Xmodmap!

There you are – happy Xmodmapping

Per gli utenti che come me possiedono una tastiera con tanto di tasti multimediali e non vogliono rinunciare al loro uso, voglio soddisfare in breve questo loro desiderio Allora innanzitutto se nella vostra Home non è presente il file .Xmodmap createlo quindi aprite un terminale e avviate xev quindi ora premete il tasto multimediali che volete settare quindi nel terminale vi appariranno una serie di comandi come questi:

KeyRelease event, serial 31, synthetic NO, window 0×2400001,
root 0×1a6, subw 0×0, time 7177017, (-1326,372), root:(112,394),
state 0×10, keycode 222 (keysym 0×0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

vedete che nella terza riga dell’output c’è keycode numero questo dovete selezionarlo e copiarlo nel file .Xmodmap, quindi vi fate seguire il nome con cui intendete identificare questo tasto esempio F30, questo dovrà essere il file di xmodmap risultante:

keycode 176 = F25
keycode 174 = F26
keycode 160 = F27

come vedete è molto semplice configurare questo file, sono necessari pochissimi passaggi, infine per settare la scorciatoia del vostro De o Wm che utilizzate, per i De non credo debba essere eseguita questa configurazione di xmodmap dal momento che dovrebbe avvenire tutto in automatico; mentre per window manager come openbox o pekwm, il mio caso, dovete aprire il file in genere chiamato keys creare una nuova scrociatoia, per Pekwm questo un esempio:

KeyPress = “#176″ {Actions = “Exec amixer -c 0 sset Master 1+ unmute cap &”}

molto semplice e intuitiva la configurazione, questo comando mi serve per alzare del 3% il volume di alsamixer utilizzando appunto il comando amixer attraverso il tasto multimediale della mia tastiera. Faccio notare che per Pekwm avevo avuto problemi nel fare funzionare queste scorciatoie in quanto con la nuova versione del window manager è necessario settare direttamente il keycode del tasto anzichè il nome identificativo del tasto, necessario al contrario in openbox, quindi basta aggiungere un # prima del keycode ed il gioco è fatto

Ah dimenticavo non scordatevi di aggiungere nel file startup il comando xmodmap /home/utente/.Xmodmap &

P.s. ho fatto una prova e ho visto che su Pekwm non è necessario incluedere il keycode in .Xmodmap, basta sapere il keycode del tasto e inserirlo direttamente nella scorciatoia desiderata Ottimo Pekwm sempre il migliore!

Motivation

I use the control key a lot. Between my Fluxbox keys file shortcuts, several Xterms with bash, and Emacs, the pinky on my left hand is getting worn out quickly. It may not seem productive at first, but every engineer should spend some time setting up the simple things in his or her lab, including getting a comfortable keyboard.

Using

• a standard US keyboard
• a UNIX-like system running an X windows server (if you are on a UNIX-like system and have a graphical display, you are probably running X windows)
• xmodmap

Setup

Here is my $HOME/.Xmodmap file:

! map Caps Lock key to Control
remove Lock = Caps_Lock
keysym Caps_Lock = Control_L
add Control = Control_L

! map right Windows/Super key to Caps Lock
remove Mod4 = Super_R
keysym Super_R = Caps_Lock
add Lock = Caps_Lock

To activate it, wait until you restart X or run from the command line:

$ xmodmap $HOME/.Xmodmap

Done. Now I just need to break the Control_L habit. Fortunately, I kept that key mapped as Control_L so it still works as expected. This feels like the old days in the UNIX workstation lab, except that my keyboard is much, much cleaner.

I have a second-generation MacBook (bought in spring of 2007), and due to a bunch of recent issues which have turned me off from OS X (e.g., the machine randomly will fail to wake up from sleep, compiling software is a huge pain, etc.), I have been aroused from my complacency and have decided to try my hand at getting gNewSense, an all-free software derivative of Ubuntu, running. I didn’t expect this to be an entirely painless or automatic process — I had tried Ubuntu on the same hardware a little over a year ago, and found it to be lacking — but I needed a distraction from studying for the GRE, and so I dove in last weekend and burned a LiveCD.

I am currently running gNewSense DeltaH, which is based on Ubuntu’s Hardy Heron release. I have found the out-of-the-box hardware support to be surprisingly good: I didn’t need to install any special packages to get the screen resolution right, to get the mouse working, or to get the keyboard working before boot (all of which were issues with Ubuntu when I tried it a year ago). The gNewSense installer worked perfectly fine, and gave me a happily-booting system without any additional configuration on my part.

The rest of this post will be dedicated to the things I had to do to get the system working to my satisfaction after the initial installation. Even though the hardware support is impressive, especially for a distribution which makes a point of removing any and all binary-only “blobs” from the kernel, there are a few things which I have found necessary to get a system which will eventually allow me to fully replace OS X. I’m documenting them here for my own benefit, and for the sake of anyone else who might be considering running gNewSense or Ubuntu on a MacBook.

1. Getting the wireless card working. Prior to doing any system updates or installing any packages I might want, I had to get a working Internet connection. We share a wireless connection here, so plugging in direct was not really an option for any length of time. I used the madwifi drivers, which are not available as a gNewSense package (though they are now available in Ubuntu’s linux-restricted-modules package, according to the madwifi wiki). I don’t understand the licensing issues involved, because the COPYRIGHT file in the madwifi distribution says its source code is dual-licensed under the BSD and GPL licenses, which is good enough for me.

There was one snag trying to get the wireless drivers to compile. gNewSense DeltaH installs both the linux-image-2.6.24 and linux-image-2.6.24-generic kernels, but only the generic version properly uses both CPU cores, so that is naturally the one I was using. However, the default installation does not install the kernel headers for the generic kernel build, so madwifi would not compile against it. Therefore, it was necessary for me to plug into the wired connection and run


$ sudo apt-get install linux-headers-2.6.24-generic


before I could compile madwifi. Once the Linux headers were installed, though, running


$ make
$ sudo make install


in the madwifi directory worked flawlessly, and the kernel loads the driver at boot.

Update: after installing the linux-libre kernel, version 2.6.29-1, from Uncle Gnufs’ World Famous Home Baked Free Kernel Shoppe, wireless works without the Madwifi drivers. The built-in ath9k driver is used instead, and I have experienced no problems with it so far.

2. Getting the mouse working. The MacBook touchpad mostly works after a default installation, but a couple of features are missing that I really need and enjoy:

• right-clicking
• two-finger scrolling

Right-clicking is a must-have in any modern desktop environment, and it was actually the more difficult problem to solve. I am still not sure if I like the solution, but for what it’s worth, this will work:

1. Install the xkbset package:
   
$ sudo apt-get install xkbset

2. Create a file ~/.Xmodmap, and add the line:
   
keycode 115 = Pointer_Button3

   Key code 115 is for the left Apple key. You can use a different key if you wish; use the “xev” program to determine what the key codes for different control keys are.
3. On the System menu, go to Preferences -> Keyboard. On the “Mouse Keys” tab, check “Allow to control the pointer using the keyboard.”
4. On the System menu, go to Preferences -> Sessions. On the “Startup Programs” tab, click “Add.” Enter what you like for the name and comments; the command should be:
   
xmodmap /home/username/.Xmodmap && xkbset m

   (replacing “username” with your actual username).

5. Restart X with Ctrl-Alt-Backspace.
6. The LEFT Apple (Command) key will now simulate a right-click wherever the mouse pointer is.

At the moment, this solution is only working for me some of the time, and it doesn’t have the “native” feel of OS X’s Control-click for rightclick. (Indeed, you don’t have to click the mouse button at all to get a right click.) This feels uncoordinated to me, because the key is not a modifier for a normal mouse click (the way it is normally a modifier for a keypress); instead, it is a mouse click. This means that whatever key you choose must be solely dedicated to right-clicking. If anyone comes up with a better way to make a key/mouse-click combination function as a right click while still preserving the normal function of that key elsewhere, I would love to hear about it.

Two finger scrolling is easier to set up, though I don’t have it working as smoothly as in OS X yet either. Simply add these lines to your /etc/X11/xorg.conf file in the section which has the “Synaptics Touchpad” identifier:


Option "VertTwoFingerScroll" "1"
Option "HorizTwoFingerScroll" "1"
Option "TapButton1" "0"


(If you don’t want horizontal two finger scrolling, set that to “0″ instead of “1″. The third line turns off tapping on the touchpad as a click; leave it out if you like being able to click with a tap.) There are a couple of issues with this so far. First of all, the touchpad seems too sensitive to me: two-finger scrolling goes very fast, and accidental brushes of my palm or thumbs on the touchpad can have drastic effects on whatever I’m doing in a way they never did in OS X. Second, the right side of the touchpad also appears set up to be a scroll zone, which is redundant and unhelpful for me; I fixed this via the GUI (System -> Preferences -> Mouse -> Touchpad -> uncheck “Enable vertical scrolling”) but I don’t know how to set this permanently in the Xorg configuration, which I would like to do. Again, suggestions are welcome.

3. Installing GNU IceCat. IceCat is the GNU Project’s version of the Firefox browser. I much prefer it to Epiphany (which was mysteriously eating my downloads), and it adds some nice security features that Firefox doesn’t have. Downloading the .deb from ftp://ftp.gnu.org/gnu/gnuzilla/3.0.1-g1/ and installing it with dpkg worked fine.

Update: I’m having some difficulties getting Gnash, the GNU Flash player, to work with IceCat. I tried installing mozilla-plugin-gnash via apt-get and creating a link to the installed flashplugin-alternative.so from the IceCat plugins directory…and IceCat promptly crashed when I tried to open a Flashy site. I am going to assume that this is due to some kind of version conflict between the mozilla-plugin-gnash package and IceCat, and try compiling from source next.

Update 2: I compiled Gnash from source, and it works at last! I still can’t play videos on Hulu or YouTube, because they use Flash 9, and Gnash doesn’t have support for them yet, but oh well. Here are the steps to compile Gnash and the plugin for IceWeasel:

1. Install dependencies:
   
$ sudo apt-get install libboost-dev libboost-thread-dev libagg-dev libsdl1.2-dev libgstreamer0.10-dev libatk1.0-dev libatk1.0-dev libglib2.0-dev libgtk2.0-dev libungif-dev libjpeg-dev libboost-dev libboost-thread-dev libagg-dev libsdl1.2-dev libgstreamer0.10-dev libatk1.0-dev libatk1.0-dev libglib2.0-dev libgtk2.0-dev libgif-dev libjpeg-dev libxml2-dev libcurl3-dev libboost-date-time-dev libboost-serialization-dev

2. Obtain the Gnash 0.8.4 source .tar.bz2 from ftp://ftp.gnu.org/pub/gnu/gnash/.
3. Unzip the sources:
   
$ tar xjvf gnash-0.8.4.tar.bz2
$ cd gnash-0.8.4

4. Configure the build for GTK (not KDE) and to install the IceCat plugin:
   
$ ./configure --with-plugindir=/usr/local/lib/icecat-3.0.1-g1/plugins --enable-gui=gtk

5. Make and install:
   
$ make
$ sudo make install
$ sudo make install-plugins


4. Fixing font rendering. This solution comes from Deep Thought. Add this XML to ~/.fonts.conf:


<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<match target="font">
<edit name="autohint" mode="assign">
<bool>true</bool>
</edit>
</match>
</fontconfig>


Other outstanding issues:

• Sound
• Sleeping/hibernating: the system does sleep (suspend to RAM) and resume, but after doing so, I can’t switch from GNOME to one of the text-based virtual terminals (e.g., via Ctrl+Alt+F2) — they’re all black.

That’s all for now. I will update this post as I discover solutions for other issues.

I’ve been using Gentoo on my notebook for the past year or so which is why my HOWTO wiki on Thinkwiki has started to fall into disrepair. Anyway, i got something working (which was really not a problem, but just something i hadn’t gotten around to.) The special keys are now (almost) fully functional.

I created the file ~/.Xmodmap

with the contents:

keycode 115 = F13
keycode 162 = XF86AudioPlay
keycode 164 = XF86AudioStop
keycode 144 = XF86AudioPrev
keycode 153 = XF86AudioNext
keycode 117 = XF86Calculator
keycode 234 = F20
keycode 233 = F19

and then ran:

xmodmap ~/.Xmodmap

for now i’m just concerned about keycodes 234 and 233 which are the forward page and backward page keys, just above their respective arrow key. Keycode 115 is the right-click properties menu, but it seems to be tripping something in KDE that is making it difficult for me to get the key to do anything. I used F13 and F14 because there’s no chance of a collision, and i know that they don’t already have a function assigned to them.

I then installed the extension Firefox extension Keyconfig and additional buttons for keyconfig extension.

After restarting, by setting the F19 and F20 to be the keys mapped to the function f4kc_PrevTab and f4kc_NextTab respectively i can now flip through all my open tabs in Firefox with these previously inert keys.

Success!!!

En ocasiones, puede que nos veamos ante la ausencia de determinada tecla que necesitemos (por ejemplo, yo perdí la barra espaciadora de este teclado ).

Por este u otros motivos, nos puede ser útil mapear una tecla, o sea, redireccionarla hacia otra.

Para hacer esto disponemos de 2 herramientas:

• loadkeys: trabaja con el mapa de teclado del kernel.
• xmodmap: trabaja con el mapa de teclado de X.Org.

loadkeys

En caso de que estemos en tty, tendremos que usar la primera. Su sintaxis básica es:

loadkeys [<fichero>]

<fichero> es un fichero opcional donde tienen que estar las expresiones a ejecutar. Si no lo especificamos, se lee la entrada estándar.

Para mapear la tecla <tecla> con la función <función>, podemos hacer lo siguiente:

# loadkeys <<FIN
keycode <tecla> = <función>
FIN

Por ejemplo, para asignar a la tecla Bloq Mayús (58) la función «space» (espacio), hacemos:

# loadkeys <<FIN
keycode 58 = space
FIN

xmodmap

Si estamos usando X.Org, en vez de loadkeys podemos usar xmodmap. Su sintaxis es parecida:

xmodmap [-e <expresión>] [<fichero>]

<fichero> es un fichero opcional donde tienen que estar las expresiones a ejecutar. En su lugar, podemos indicar expresiones con la opción -e, seguida de la expresión entre comillas.

Para mapear la tecla <tecla> con la función <función>, podemos hacer lo siguiente:

# xmodmap -e "keycode <tecla> = <función>"

Por ejemplo, para asignar a la tecla Menú contextual (117) la función «space» (espacio), hacemos:

# xmodmap -e "keycode 117 = space"

Hace tiempo que queria agregarle algo a mi Pc, y se me dio por cambiar mi pobre teclado Genius de 105 teclas por un teclado con algunas cosillas mas.

Creo que el Genius ErgoMedia 700 cumple con mis necesidades, aunque para configurar algunas teclas tuve que hacer unos pases mágicos (en los que me ayudo un amigo con consejos de que utilizar). En 45′ tenia funcionando la tecla de Home y Correo además de la www.

Además tiene el sonido integrado al teclado, y es usb trae una ruedita como la del mouse para hacer Scroll en la pantalla, y un Zoom que aun no configuré.

Tiene control de volumen y varias cosas para audio que Kde las tomo al toque una vez que seleccione un teclado parecido.

Con esa configuración le agrego 3 teclas que Kde no reconocia.
Saludos y estoy posteando fotos en estos días.

このエントリーでtabとAltのキー位置を交換したく、いろいろ調べていたら、xmodmapというのを知った。とりあえず、shellでxmodmapと打ち込むと、以下の文が出てくる。また、オプションで-pkeを付けると、keycode(キーコード)とkeysym(キーシンボル) の対応一覧表が出てくる(載せたいのだが、縦にすごく長いので、割愛する)。

xmodmap: up to 3 keys per modifier, (keycodes in parentheses):

shift Shift_L (0×32), Shift_R (0×3e)

lock Caps_Lock (0×25) control Control_L (0×42), Control_R (0×6d)

mod1 Alt_L (0×40), Alt_L (0×7d), Meta_L (0×9c)

mod2 Num_Lock (0×4d)

mod3
mod4 Super_L (0×7f), Hyper_L (0×80)
mod5 Mode_switch (0×5d), ISO_Level3_Shift (0×7c)

Caps LockやCtrlキーはmodifier(他のキーを修飾するもの）というらしい。 それで、いつぞやどこかでみたCaps LockとCtrlキーを入れ替える具合にtabとAlt_Lに関してやってみた。以下はその設定である。

!
! swap Alt_L and Tab
!
remove mod1 = Alt_L
keysym Alt_L = Tab
keysym Tab = Alt_L
add mod1 = Alt_L

これを~/.Xmodmapという設定ファイル名にし、保存した。これを起動時に読み込まれる設定ファイル(~/.xssesionや~/.xinitrc)に追加するのだが、session-errorが起きたので、何が間違っていたのかよくわからない。結果だけはわかっていたので、そのファイルを削除したのだが。試しに、なにもしないで、emacsを起動すると、tabとAltキーが交換されていて、Tabの位置がMeta-として、使えるようになっていた。まあ、Tabにもいろいろ機能があるみたいなので、Altの位置が気に入らなかったら、また考えるかもしれない。

これから、このTab(Meta-)と 奇妙な生活が始まる…

・参考

10 Specific Ways to Improve your Productivity With Emacs

追記：2008/04/14
xmodmap コマンド

This time I write about my new keyboard: the cherry evolution stream. I primarily decided to buy a new one because I wanted to switch to the US layout, which has it’s advantages when coding or just because I am used to write with the US layout at university. I bought it at keybo.de where it is possible to get almost every possible layout, they sent it very fast and payment was possible via bill so I can recommend that shop.

So far I have no problems with the keyboard, I quite like it. I plugged it into the keyboard PS/2 port (is there an advantage of using an USB port?) and it worked out of the box under linux. I use just the standard xorg kdb driver for X:
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
EndSection
although even auto-detection in never xorg versions should work. Only the multimedia buttons do not work without additional configuration but I did not expect that, where would be the fun? So it was a rather easy task to get all the keycodes using xev and combine them with the appropriate actions. Add
keycode 160 = XF86AudioMute
keycode 174 = XF86AudioLowerVolume
keycode 176 = XF86AudioRaiseVolume
keycode 144 = XF86AudioPrev
keycode 162 = XF86AudioPlay
keycode 153 = XF86AudioNext
to your .Xmodmap file (or wherever you thinks it’s best) and … run it through xmodmap:
xmodmap .Xmodmap .
To use the volume buttons you may want to install kmilo under kde.

My new mouse, the Logitech G5 refresh (edit: the one with 2 thumb buttons), works really nice under Linux. The only minor issue I had was that the direction of the horizontal scrolling was swapped. I solved this with the following code in my xorg.conf (xorg-server-1.3.0.0-r2, xf86-input-evdev-1.1.5-r2 as Gentoo packages, the appropriate evdev kernel modules have to be loaded):
Section "InputDevice"
Identifier "Mouse0"
Driver "evdev"
Option "CorePointer"
Option "Name" "Logitech USB Gaming Mouse"
Option "HWHEELRelativeAxisButtons" "7 6"
EndSection
No further setup is needed, all buttons and scroll wheel direction work out of the box; especially no xmodmap is needed. The dpi setting buttons work too. However, at the moment, one can only set the mouse to 400, 800 or 2000dpi. A customization will hopefully be possible when lomoco supports the G5.

Using the settings above let you scroll horizontally eg in konqueror or OpenOffice. Firefox sets it to “go back/forward one page” by default. To scroll, set mousewheel.horizscroll.withnokey.action and mousewheel.horizscroll.withnokey.numlines (edited, thanks to Deth for pointing out a mistake) to 1 in the about:config dialogue. The default behaviour is reached with ALT+wheel.

Although xev prints the thumb buttons’ pressing correctly, there isn’t any function yet AFAICS. Unfortunatly (for me) KDE cannot assign actions to mouse buttons. This is possible with xbindkeys, which is configured via .xbindkeysrc. Here is mine (edit: which sets actions for both thumb buttons):
"xvkbd -text "\[F13]""
b:8
"xvkbd -text "\[Control]\[Prior]""
b:9
"xvkbd -text "\[Control]\[Next]""
Control + b:9
xbindkeys, however, cannot assign simple key combinations but only shell commands so — you guessed it — another tool is needed: xvkbd. Now button 8 simulates a F13 which is not on my keyboard but can be assigned by KDE and button 9 gives a CTRL+PageUp, which cycles through the tabs in firefox; CTRL+Button9 does the obvious thing. I guess I’m happy now but, nonetheless, I hope KDE 4 makes the use of extra mouse buttons a bit easier.

Es un martes por la mañana, caminas hacia tu pc dispuesto a otro largo día de trabajo, quieres terminar la tésis o redactar el nuevo artículo para la editorial (del que ya te atrasaste un día), o quizá solo quieras seguir ligando a la chica del otro lado del mundo que conociste “por accidente” el otro día en su hi5. Te sientas frente al ordenador con tu taza de café de todos los días, excepto que hoy tienes una extraña sensación…

Es entonces es cuando lo ves y te acuerdas: está allí, sobre tu escritorio, estático, vano, inservible. Sientes esa extraño cosquilleo en la nuca, ese sentimiento mezcla de miedo, enojo y frustración, al recordar que ayer solo dejaste el ordenador porque el teclado que no te acuerdas desde cuando lo tienes ha dejado de responder.Ese al que nunca lo tomaste en serio porque era solo algo más, ahora ya no lo puedes usar. Ese con el que escribiste el mail que te salvo el empleo, o el que solo usas para la mensajería instantánea, ha dejado de ser útil, o al que ya no se le veían las teclas “w a s d” porque todo el día juegas al Alien Arena o al Tremolous… y sin embargo nunca lo tomaste en serio.

Ha llegado el día en que tu teclado ha dejado de funcionar bien, es hora de olvidarte de él, echarlo a la basura (no… mejor reciclarlo ) y comprar uno nuevo.

O simplemente y sencillamente te has comprado un nuevo pc, o conocen lo geek que eres y alguien te regala un teclado nuevo.

Ahora todo ha cambiado, ves tu nuevo y flamante teclado, todo lleno de botoncillos que quizá nunca llegues a usar (o que en verdad no sirven de nada :S ). El problema está en que ninguno funciona, por mas que los oprimes no sucede nada, o solo funcionan ciertas teclas y las demás bien gracias. Y lo peor de todo es que tus amigos/familiares/colegas te dicen que en el hasefrochito si funcionan bien todos, que debe ser que tu maravillosa Debian no puede con ese simple teclado, o es que GNU/Linux no es para estas cosas… Pero puedes demostrarles que tu puedes hacer con esas teclas lo que sea, desde abrir el amarok (o el listen), hasta activar el sistema de riego del jardín (eso queda para otra guía ) y configurar el teclado en menos de 10 minutos.

Bueno, ya estuvo bueno de parloteo, ahora vamos al grano.

Los teclados multimedia a menudo necesitan cds o diskettes de instalación que solo funcionan en hase, pero no quiere decir que el teclado en sí no envíe datos al pc si no ha instalado ese software, ya que lo único que éste hace es decirle al sistema como actuar cuando sean pulsados los botones extra.

En GNU/Linux es solo cuestión de hacerlo manualmente, identificando los botones y dictando las acciones que se realizarán.

Esta guía trata acerca de como configurar estas teclas dentro de una sesión gráfica, para que puedan ser configurados en cualquier escritorio, pensado para usar herramientas comúnes entre distintas distros y sin instalar ningún nuevo demonio (cosa que hacen ciertos programas automatizados)

Primero: Determinando los keycodes.

Los keycodes son la traducción que hace el sistema a los datos enviados por el teclado. Cada tecla genera keycodes distintos pero basados en estándares, (al menos en el caso de 104-105 teclas que posee comúnmente un teclado de escritura occidental) en el caso de los botones multimedia, y ya que no existe un estándar propiamente dicho, los fabricantes les colocan los que les venga en gana a los botones, total si incluyen un sofware que lo configure todo pues….

Para saber que keycode corresponde a cada uno de los botones usamos una aplicación llamada “xev” que se especializa en informar de los eventos que ocurran en X, debemos lanzarla desde un emulador de terminal (por ejemplo konsole, gnome-terminal, xterm, yakuake, etc.) estando en el servidor gráfico (no en las tty):

~$ xev

Luego de esto aparecerá una ventanita llamada “Event Tester” que es la que “siente” todo lo que haga sobre ella el mouse y el teclado, mientras que en en la terminal desde donde la hemos lanzado van apareciendo los eventos.

Teniendo seleccionado el Event Tester vamos presionando los botones multimedia uno a uno y viendo lo que sale en la terminal. En mi caso al presionar el boton “Play”:
KeyRelease event, serial 31, synthetic NO, window 0x2e00001,
root 0x63, subw 0x0, time 1412932703, (92,-5), root:(163,415),
state 0x10, keycode 162 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

Como ven aparece el keycode 162 y además NoSymbol, esto significa que no se ha definido ninguna acción o caractér para el botón. Ahora lo que falta hacer es que el sistema interprete de alguna forma estos códigos.

Segundo: Definiendo los símbolos para los keycodes usando xmodmap.

xmodmap es una sencilla aplicacion de consola que permite modificar ‘al vuelo’ el mapa de caracteres del teclado para las X (agregando, eliminando o intercambiando símbolos).

Primero creamos un fichero de texto sin formato que contenga los keycodes y sus respectivos símbolos, uno por línea, de la siguiente forma:

keycode N = símbolo

Donde N es el número de keycode que obtuvimos con xev, y símbolo es cualquier nombre con el que querramos identificar al botón en cuestión.

Ojo que debe ser un fichero de texto plano sin formato, no vale hacerlos con opeoffice, koffice y demás editores que insertan formatos raros a los documentos, debe ser texto puro y sin formatos especiales (pueden hacerse por ejemplo con kate, gedit, vi, etc.).

El fichero lo guardamos con el nombre .xmodmap o .xmodmaprc en nuestro directorio home, en realidad el nombre puede ser cualquiera que se os antoje, pero si lleva alguno de estos es posible que los entornos de escritorio y/o dependiendo de la distro que usemos, sea detectado y aplicado automáticamente al próximo inicio de sesión.

Noten que el nombre del fichero comienza con un punto, esto significa que estará oculto y no nos estorbará al ver los archivos guardados en nuestro home.

Como ejemplo les dejo mi .xmodmaprc:

keycode 144 = XF86AudioPrev
keycode 153 = XF86AudioNext
keycode 160 = XF86AudioMute
keycode 161 = XF86Calculator
keycode 162 = XF86AudioPlay
keycode 164 = XF86AudioStop
keycode 174 = XF86AudioLowerVolume
keycode 176 = XF86AudioRaiseVolume
keycode 178 = XF86HomePage
keycode 222 = XF86PowerDown
keycode 223 = XF86Sleep
keycode 227 = XF86WakeUp
keycode 229 = XF86Search
keycode 230 = XF86Favorites
keycode 231 = XF86Refresh
keycode 232 = XF86Stop
keycode 233 = XF86Forward
keycode 234 = XF86Back
keycode 235 = XF86MyComputer
keycode 236 = XF86Mail
keycode 237 = XF86AudioMedia


Si se preguntan de donde saqué esos nombres para los botones …¡que tan raros que se ven!, …. bueno pues están definidos en el fichero /usr/include/X11/XF86keysym.h y si utilizamos estos pues tenemos la ventaja de que muchas aplicaciones traen predefinidos los atajos de teclas con estos nombres, por lo que no tenderemos que configurarlas después de terminar con esta guía .

Aplicando las configuraciones

Para terminar y ver los resultados de todo lo que hemos hecho hasta ahora pues es tiempo de aplicar los cambios:
~$ xmodmap .xmodmaprc (sustituyan el .xmodmap por el nombre de su fichero en caso de haberle puesto otro)
Ahora solo falta probar las teclas de nuevo con el xev, despues de aplicar los cambios con xmodmap el resultado de presionar alguna tecla especial (en mi caso):

KeyRelease event, serial 31, synthetic NO, window 0x2e00001,
root 0x63, subw 0x0, time 1418716437, (102,-28), root:(106,413),
state 0x0, keycode 174 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

Como ven ahora aparece que el símbolo XF86AudioLowerVolume está asignado al keycode 174, muy bien, ¿no creen? .

Haciendo que se apliquen los cambios al iniciar sesión.

El problema ahora es que los cambios solo se mantienen mientras no salgan de la sesión, en algunos casos (como he escrito arriba) se autodetectará el fichero de configuración y se aplicará sin problemas, si esto no ocurre tenemos la opción de hacerlo a mano todas las veces (con una simple llamada a xmodmap y pasándole como argumento el fichero que hemos creado), o incluír el comando de llamada a xmodmap en el autoarranque del escritorio que utilicemos (KDE, GNOME, Xfce, Fluxbox, Blackbox, etc.) …en esta guía solo diere cómo hacerlo para KDE:

Creamos otro fichero de texto en el directorio ~/.kde/Autostart/ que contenga el comando hemos utilizado para aplicar los cambios.

Si al fichero de los keycodes le han puesto el nombre que sugería (.xmodmaprc) el contenido de este otro fichero sería:

#!/bin/bash
xmodmap .xmodmaprc
exit

Nota: Este fichero debe escribirse en texto plano y tener la extensión .sh (script para sh/bash), un ejemplo de nombre para este archivo podría ser Script_teclas.sh. Además este fichero ha de tener permisos de ejecución, para dar permisos de ejecución a cualquier fichero se puede usar el comando $ chmod +x Fichero.

Luego ya solo queda configurar las aplicaciones que querramos lanzar con con los botones, en kde se puede hacer desde Centro de Control –> Regionalidad y accesibilidad –> Accesos rápidos de teclado.
Para controlar aplicaciones como amarok, las configuraciones se hacen en el mismo programa, donde se le puedan indicar accesos rápidos globales de teclado.

Si se quiere controlar algún programa que no posea accesos globales se puede optar por realizar un script (cosa que va mas allá de los alcances de esta guía) y configurar un acceso rápido desde el Centro de control para lanzarlo.

Espero que esta guía le sirva a alguien (si es que alguien la lee ) y que comenten acerca de como les ha parecido y también si tienen alguna sugerencia para mejorarla.
Saludos.