Presenting Window Maker

Courting the Daemon, part 3

amanda

Compared to some of the x-window clients out there, Window Maker is a lightweight. Some have even called it antiquated. But just because something has been around for a while doesn’t mean it’s no longer useful. Granted, in the world of computers, software doesn’t age well. But there are exceptions to this rule, and Window Maker is one of them.

Unlike one of the desktop environment clients, like KDE or GNOME, Window Maker doesn’t create a virtual “desk” for the user. Window Maker is basically just a GUI for the Unix environment. A better comparison may be with Microsoft Windows 3.11. That old version of Windows was a GUI for the DOS (or DOS-based) system underneath, and it wasn’t trying to be anything else. Windows 95 and later, by comparison, created and managed a virtual desk, in much the same way the Macintosh GUI does. (The success of Microsoft Windows in this area is a topic of constant debate.)

You may ask why I chose to go with such an “old school” GUI client when there are more powerful ones available. Truth be told, I like Window Maker’s simple interface and design, and that simplicity is one of its greatest strengths. Unix, FreeBSD and Linux have all changed considerably over the last two decades. Window Maker has changed very little, and it still runs beautifully. The core design is versatile enough that with only minor updates it can still run with the best of them. The same can’t be said for many other x-window clients.

As for power, I didn’t give up a single kilobyte, because Window Maker gets along very well with KDE and it’s brethren. If you are using one of the environment clients, and still want or need the features it provides, then I have good news: you probably won’t have to give up anything! There is a good chance that Window Maker can manage them. For example, KDE’s file manager, Dolphin, is the backbone of KDE’s desktop environment. Most of KDE’s core file management functions are integrated within Dolphin, and I have found that this is where most of KDE’s power lies. I frequently run Dolphin as a client application from Window Maker, and it runs perfectly. So even when the KDE window manager isn’t running, most of KDE’s best features are easily available as options within the Dolphin file manager. I haven’t done extensive testing, but I have found that GNOME Files, the file manager for GNOME, and Thunar from XFCE, all run well as client programs within Window Maker.

Onward.

Most official sources for Window Maker include either a Linux instillation package (*rpm or *deb), or a tarball. I first used Window Maker back in my Linux days, and remembered the instillation being fairly straightforward. Users of the BSD series have the option of shaking the port tree, which is what I did:

/usr/ports/x11-wm/windowmaker/
/usr/ports/x11-wm/wmakerconf/

The first port is the only one you really need. Wmakerconf is a newer tool that adds and refines some configuration options. It isn’t essential, but it has some good uses, and it can’t hurt to have it available. Use the regular “make install clean” routine to install both programs.

One could also use the package instillation route:

pkg install x11-wm/windowmaker
pkg install x11-wm/wmakerconf

Personally, I would recommend going with the port tree “make install clean” method. Package installations usually provide a pre-compiled binary executable. For many application this is fine, but window managers tend to draw on a wide variety of system resources, and a packaged binary may not be the best for your system. By using the port method, you are more likely to get an executable that is tailored to your particular system. It takes a little longer than using a package, but it’s worth the extra effort.

When I first launched Window Maker, it looked something like this:

wm1

Note how Spartan the work space is when compared to one of the environment clients. This may be a bit intimidating at first, especially for someone who is used to seeing task bars and icons all over the place. But don’t worry. The configuration tool, called the preferences utility, can make things look better in a hurry.

I’ll talk about this utility in more detail further down, but the ability to change icon sizes is one of the many options it provides. The first thing I did was expand the size of the dock icons (the guys along the bottom and right margins) so that I could actually see them without squinting. Size can be set to something very small, like 8 pixels across, to something ridiculously large like 256 pixels. I just tried different sizes until I found one that my eyes agreed with.

In the upper left corner is the pager. As with most window managers, Window Maker can support multiple work spaces. The means of cycling through your work spaces, often called the pager app, is the paper clip icon. Clicking on this icon will allow you to add, remove, and name work spaces however you want. I usually keep my system between four and eight work spaces, but I understand that one can go as high as 64.

Now that I had the window manager working largely the way I wanted, I could start adding functionality to my custom system. The first thing I wanted was a good terminal program. FreeBSD is, at the end of the day, a variant Unix system, and that means it’s largely driven by a command line. I’m not going to get into the religious wars of command lines versus graphical interfaces. I’m just stating the facts as I see them: the best features of FreeBSD frequently require a command line interface. Fortunately, there are a number of choices in this area. KDE comes with one called Konsole, and Xterm is the “old reliable” of the X-Windows world. Both of these are fine, but I wanted one with some special options for customization. For this I chose RXVT. I had used this terminal program before, and there is even a variation for the Microsoft Windows world which I have in my Windows partition.

wm2

This is what a default RXVT terminal looks like. Like any terminal client, it provides a command prompt and very little else. Unix technology has it’s roots in the computer systems of the late 1950’s, where everything was done using a basic text screen. This echo is still apparent in most x-terminals. But again, the best features of Unix are usually tied to the command line. There are many users, especially Unix power users, who control their entire system through x-terminals, and rarely use the features of the GUI. Get to know the command line. It will become your trusted friend.

Getting back to RXVT, it offers a variety of options for screen geometry, colors, fonts, backgrounds images, and so on. It also has several variations, each with different features. The one I chose included unicode support, and is called “urxvt.” I wanted unicode support because sometimes I need to access my work computer from home, where I often deal with materials in non-Western languages in conjunction with on-line translation utilities. Unicode is a must for such work.

rxvt

URXVT in action, showing some of the options for colors, background images, and fonts. I’ve only scratched the surface of the various options this program has.

RXVT on the ports tree:

/usr/ports/x11/rxvt/

The version I use is:

/usr/ports/x11/rxvt-unicode/

Now that I had a good means of using the command line, I started to add some more features to my Window Maker install. One of the more useful features of Window Maker is what is called the “dock.” A lot of window managers feature a “dock,” which first appeared on the NextStep window manager (I think). It has been incorporated in many GUI systems since then. Even the Macintosh and Windows 10 GUI systems use a form of dock. Almost any application can be attached to the dock, but I prefer to restrict mine to system monitoring tools.

I shook the ports tree and installed these dock applications:

Window Maker network monitor

/usr/ports/net/wmnd/

Window Maker weather

/usr/ports/misc/wmweather+/

wmtime

/usr/ports/x11-clocks/wmtime/

wmmoonclock

/usr/ports/astro/wmmoonclock/

Some of my dock apps, like the clock and the network monitor, have obvious practical use. Others, like the weather reporter and the moon clock, are just for fun.

For other dock applications, visit the dock apps web site for ideas. Or, search “dock apps” in your favorite search engine. There are literally hundreds of dock-able apps out there, so if you know what you’re looking for, you’ll probably find something that will work.

One word of caution for FreeBSD users: before downloading a tarball or instillation package for a dock app, find out if it has been included in the ports tree. Over the years, many of them have been included. If the one you’re looking for is on the tree, then save yourself some trouble and install it from there. It eliminates a lot of guess work, especially when program library files and supporting utilities enter the mix.

Once I had my dock apps in place, I went back to the preferences utility. This utility provides a wide variety of options. It is usually built into the application menu by default (right click on the work space to see the menu), or it has an icon in the dock. This icon usually looks like the Window Maker logo with a wrench or screwdriver over it:

But in case it isn’t in either of these locations, it can usually be found at:

/usr/local/GNUstep/Applications/WPrefs.app/WPrefs

Failing that, the command line tool grep should find it in short order.

Explore the options within the preferences utility, and experiment. Just about every physical characteristic of the GUI can be customized in one way or another, so have fun with it. After such a session of experimentation, I managed to make my work space look exactly the way I wanted it. The result was something like this:

wm3

So now I had my own, personalized FreeBSD workstation. Now it was time to actually get to work. For that, I needed to start bringing in applications!


Some Window Maker links:

Opening the X-Window

Courting the Daemon, part 2.

X-Windows logo

Oy.

There are almost two dozen different X-Window clients available for users of FreeBSD, Linux, and Unix, all with their own strengths and weaknesses. Advocates of the various window managers have engaged in religious wars with other advocates, all trying to determine whose window manager has the biggest pointer.

I’m not going to get into that, at least not in any depth. Personally, I don’t see the point (no pun intended). Not all users work the same way. Even Microsoft and Apple know this, so they allow for customization of their GUI clients. Granted, they generally don’t provide as many options as X-Windows, but they provide enough for most users to work with.

So to the various advocates of the various window managers, I must say this: use the one you like, and be happy. One of the best things about the world of open source software is that users can customize things as they see fit, up to and including the character of their GUI.

That being said, there is something I want to quickly look at, which has surfaced in recent years within the FreeBSD community. That is, should FreeBSD have its own, dedicated X-window client?

When I entered the world of FreeBSD, I had some experience with X-Windows during my Linux experiments, so I knew something about their various characteristics. My first FreeBSD instillation was PC-BSD version 1.5 (“Edison”), and it came with KDE-3.1 as the standard X-Window client.

KDE-3.1 looked and felt like a Windows or Macintosh interface. This is to say it was very similar to what I was accustomed at the time, so I was able to get to work fairly quickly. I didn’t want to spend a lot of time learning a new interface and/or figuring out how to do the most basic of tasks. I was, after all, using an operating system that I wasn’t familiar with, and I knew from my Linux experience that Unix-derived systems are not easy to grasp. However, I was able to start using my system, and largely it was because of KDE. I found I could use KDE to accomplish most tasks, while learning the Unix-based underpinnings on my own time and at my own pace. KDE turned out to be a good teaching mechanism.

Granted, KDE isn’t the only desktop environment available, and I’m not sure it’s even the best. But for someone coming from a Windows or Macintosh environment, it’s familiar and easy to learn. When PC-BSD got started, it was probably the best choice available for training new users in the FreeBSD operating system. At the time, one of the developers said that one of the big motivations behind PC-BSD was to make FreeBSD more accessible to new users. That was the case for me, and it was largely because the GUI was easy to work with. Over time I became more comfortable with the FreeBSD system that lurks below the PC-BSD dressing, and eventually I was able to do some of the more complex Unix tricks that the old pros do all the time. Newbies don’t remain newbies forever, after all. Eventually I settled on the WindowMaker window manager, which when compared to KDE is minimalist.

But even so, KDE is still available should the need arise. And there are other desktop environment clients, like XFCE, Gnome and LXDE, which provide a Windows or Macintosh style environment. For a newbie, this is a good thing, and I highly recommend one of those for such users. For example, my Windows 8.1 instillation recently flaked out (surprise surprise…) and it may be some time before I can repair it. This caused problems for my nine-year old daughter, as she sometimes uses my computer when I’m at work. I set up an account for her on my FreeBSD instillation, and it defaults to KDE 4.1. As far as I know, she’s had no trouble figuring out how to find what she needs to find. I suspect she doesn’t care about KDE 4.1’s shortcomings, just so long as she can find Firefox and play Animal Jam or access PBS Kids. As for my wife, she just wants a selection of web browsers, and access to a word processor (she’s a freelance writer and web developer). KDE 4.1 to set to deliver those as well. Additional Unix experience is helpful, but not necessary.

So to bring this back to point, should FreeBSD (in it’s various forms) have its own, dedicated X-window client, as opposed to one of the carry overs from Solaris or Linux? Personally, I don’t think so. New users are going to want a GUI client that can get them up and running easily, and help familiarize them with the new environment. KDE, XFCE and Gnome can all do that. New users should be allowed to get the basics down on their own time, and at their own pace. The training wheels can come off when the time comes.

Does FreeBSD need a GUI client that targets advances users? Absolutely not. Advanced users are going to make their own choices and customize their system to their liking no matter what the initial GUI looks like. Some even develop their own X-windows client! So I don’t think there is much point to having a standard GUI for FreeBSD, because users aren’t likely to retain it! In fact, standardizing such things runs counter to the whole philosophy of open source computing, and most hackers aren’t likely to suffer such a restriction.

So now that I’ve gotten my editorial out of the way, let’s look at my window manager of choice…


Addendum:

PC-BSD is endorsing, and contributing to a new desktop environment X-client called Lumina. It’s still under development, but it looks like it would also be a good teaching and transition tool for new users. At a quick glance, Lumina seems to have a more Macintosh-like feel to it. New users from the Apple orchard should feel right at home.


Related links:

  • Xorg home page
  • Window managers for X
  • FreeBSD project
  • Beesdie Boy

    Courting the Daemon, Part 1

    Beesdie

    tardis_by_homemadezombieit’s flashback time! This article is strongly based on one I posted on DeviantArt.Com, on April 14, 2008.

    Allow me to introduce you all to a good friend of mine, Beesdie.

    For those of you who don’t recognize it, this is the mascot for the open source operating system FreeBSD. Just as Linux has Tux the penguin, FreeBSD has Beesdie (or Beastie) the Daemon.

    Some years back I went through a phase of constantly tinkering with computers. I used just about every major operating system in the world of x86 computing, to varying degrees of success. Those of you who know me personally know that this has simultaneously been a source of joy and frustration. I also liked tinkering with different pieces of hardware, and I’ve had some pretty interesting setups as a result. I used to get a major charge out taking a computer and getting it to do new and wonderful things. But somewhere along the line, probably shortly after my daughter was born, that changed. One night, after wrestling with my system and getting an elaborate program to work, I came away thinking “OK, fine and good, but that was more trouble than it was worth.”

    I became less interested in tinkering and more interested in function. I also decided that I would rather spend more time with my wife and family than fighting with a computer. When I use my computer, I want it to run applications on it, and get things done, rather than constantly have to reconfigure the damn thing just so things would work. Some tinkering and configuration is necessary, but I no longer wanted it to be the main event.

    It was during the early years of Windows XP that I realized that I was sick and tired of Windows. With it’s bug-ridden registry, bloated applications, flaky interface, and constant need for troubleshooting, I had seen my fill of dirty windows. For a time, I seriously considered switching to a Macintosh. The Macintosh has a clean interface and a good performance record, despite the often snooty attitude of its user base. However, Macintosh computers tend to more expensive that their x86-based counterparts. At one time the price difference was formidable. In recent years they have become more competitive, but they still tend to have a higher sticker price. At the time, the magic apple was simply beyond the reach of my checkbook. So, I had to stick with traditional x86, PC based architecture.

    The Windows series was, and an many areas still is, the dominant operating system for the world of PCs, but there were alternatives. I tried a few of the commercial underdogs (BeOS and OS/2), as well as several shell enhancements. These helped, but Windows remained flaky, even when pumped up.

    I suspect many of you are wondering why I didn’t switch to Linux. After all, Linux should have been the answer for someone like me who needed to stick with PC-based architecture, wanted a strong operating system, but didn’t want to fork out a lot of the money. Actually, I did try Linux. Over a three year period I tried several variations of it. Many of them had great features and they performed like a champ.

    Until I actually tried to get productive.

    Here’s the thing. As tired as I had grown of Windows, I was equally – if not more – tired of Linux. With it’s fussy configuration files, arcane module dependencies, lack of consistent support, and compatibility issues, there were many times I wanted to eat rotisserie-style penguin for dinner. All that constant re-configuring I mentioned? That was largely in Linux, not Windows. In getting away from Window’s buggy program registry, I encountered Linux’s Byzantine file dependency system. It wasn’t worth it. One night my wife, in a fit of exasperation, said that I should stick with Windows simply because it works. “It may not work well,” she said, “but it does work. Linux doesn’t!”

    In a moment of despair, I realized that she was right. For me, Linux was not and never would be an option. I know I’m going to tick off every Linux user in the universe for saying this, but for me, Linux is just too cranky. I’m not saying that Linux doesn’t work, only that it didn’t work for me. Still, I wanted an operating system that was reliable, had at least some level of decent support, and could work on modern hardware. That ruled out most of the minor players. I was still using Windows XP, but I had had too many breaks to ever totally trust it. And I wasn’t going to go back to Linux.

    There was still one option that I hadn’t tried. Throughout all of my tinkering, there was one operating system that I, for no apparent reason, had never tried: FreeBSD. Tux’s lesser-known half-brother. The little red daemon from Berkeley.

    So, one evening in early 2008, I prepared an instillation disc for PC-BSD 1.4.1. I’ll talk about PC-BSD in detail another time, but it’s essentially FreeBSD with a user-friendly front end. I prepared my computer for a mutli-boot option, and took the plunge. I had some problems getting PC-BSD to launch and install, but many of those were the result of my computers BIOS rather than anything related to FreeBSD or even Windows XP. My earlier experience with Linux had taught me how to correct or work around problems of this type, but any newbie would have been thrown out of the game. I say that to point out that despite what advocates say, FreeBSD is still best left to users with some experience and/or a lot of guile. This isn’t a process for the timid.

    Anyway, after some manipulation of my boot manager, PC-BSD started running. I wasn’t expecting much. Actually I was expecting another confusing mess like Linux. It took a little while to get the GUI looking and working the way I wanted it to, but the experience was comparable to customizing Windows XP. In this case, that was a good thing, because configuring a Linux instillation, especially the GUI, was often a nightmare. But FreeBSD let me get down to business in a relatively short time.

    I was even able to get a few programs up and running fairly quickly. I found the process comparable to Windows XP’s installation scripts. By contrast, I found the Linux *rpm or *deb instillation packages a constant guessing game. Half the time I would get dependency errors, with very little information about how to resolve them. By contrast, BSD let me know exactly what I needed, what needed to be updated, and offered to get all the components for me. If only I could get such service in the local restaurants.

    freshports

    Which brings me to the port tree. FreeBSD users often wax poetic about the ports tree. It is is essentially a database of instillation scripts for around 23,000 programs, packages, and drivers. I’ll go into it in more detail another time, but the first time I approached it I didn’t know what to expect. PC-BSD offers the ports tree as an optional component during install. Knowing that other FreeBSD users spoke highly of the ports system, I opted to try it. Back in my Linux days there was a particular graphical file manager that I really liked, so I was pleased to see that it had been included in the port tree. Using an administrator terminal, I told my system to install the beast, half expecting it not to work. For roughly 20 minutes that terminal window was full of rapidly scrolling gibberish, which told me that at least it was trying. (I found out later that this was the text output from the compilation process, and very much the norm.) When the scrolling finally ended, I held my breath, and tried to call up the program. I was presented with two quick questions confirming some configuration options, and then the program launched perfectly. I was amazed! In Linux, I had to tweak and fiddle for almost an hour just to get the thing to compile! But here it was, running clean and strong after minimal effort. I was rapidly approaching Nirvana.

    Another interesting happened to me while using the ports. Just for fun, I tried to install a very high-end graphical system navigator, the X-Cruiser. If you’ve seen the original Jurassic Park, the computer savvy tween used a variation of X-Cruiser to traverse the park’s mainframe. Anyway, my system went through the ports scripts as usual, but I received several warnings. When I tried to launch it, it crashed in a most spectacular fashion. A terminal window was displaying several messages of what the system was trying to do, and with the help of some on-line documentation I was able to decipher them, and one in particular: “incompatible firmware.” The core issue was my video card: it just didn’t have the necessary firmware, and the program wasn’t going to work. Ever. FreeBSD had essentially said “sorry boss, I can’t handle this one.”

    Strange as this may sound, I found that oddly refreshing. The system told me, flat out, that this program wasn’t going to work no matter what I tried to do. Linux would have crashed the program with a set of cryptic error messages that I would have been compelled to decipher, and would have left me guessing. FreeBSD spared me that frustration. I shrugged, removed the dead weight program, and went on my way.

    To sum up, my first experience with FreeBSD was a very positive one, and I have used it to some degree ever since. It’s fast, feature rich, and very reliable. In terms of usability, it is comparable to Windows or Macintosh (once you get past the first few hurdles), and leaves Linux completely in the dust. In just a few sessions, I got my PC-BSD instillation to work exactly the way I wanted it to, and I could change things with minimal effort should the need arise. I never achieved that level of satisfaction with Linux, even after months of using it.

    Since then I have considered Beesdie to be a trusted companion. I am root. Hear me roar!

    To be continued…

    SSM module: Isadora

    isadora

    I have made a few modules for Space Station Manager, though it would be more accurate to call them hacks than modules. I wanted to experiment with different configurations of station, so I made up modules that handle resources differently than the standard ones.

    One such module is the Isadora artisan studio. This module is based on an actual proposal by Brazilian artist and engineer, Ricky Seabra.

    The basic idea is that Isadora is an art studio in outer space. It provides space for artisans in much the same way science modules provide space for scientists. Seabra is reported to have once asked “Why should scientists have all the fun?”

    Why indeed?

    Within the confines of this simulator, Isadora generates income from the production of high quality astronomy photographs and holograms, motion pictures, recordings of micro-gravity dance and gymnastics, and the production of micro-gravity sculpture. When artisans aren’t using the studio, it can also serve as a lounge for crew members, or as a destination for space tourists. It doesn’t generate as much income as a science module. But by the same token it doesn’t require as many resources to operate and maintain as a science module.

    Within the simulation, Isadora looks like a standard module with sky-blue portals.

    Requires: 2 energy, 1 cooling, 1 life support
    Provides: 1 lab space, 4 credits


    Isadora (Class: Commercial)

    48 KB, ZIP Gaming Isadora module for Space Station Manager.