Slashdot Mirror
Window Maker 0.80 Released
An anonymous submitter points out that Window Maker, the window manager behind GNUStep, is now up to version 0.80. There is NEWS which describes some of the recent changes, as well as a Changelog.
← Back to Stories (view on slashdot.org)
I think they're 2 of the best Window Managers under Linux: small, flexible, fast and quite usables :-)
CU!
Window Maker is a window manager - it draws pretty borders around windows and lets you move them. KDE and GNOME are "desktop environments" -- an interapplication communication protocols and a collection of applications. Entirely different beasts.
What's this major obsession over 1.0 releases?
I would hardly call WindowMaker "feature-depleted". You know, before I used WM, I used fvwm2. Yes, FVWM 2.x. And much to my surprise, this 0.5x (which it was at the time) was much cooler and better window manager than FVWM2. (No uebercustomizable outlook, but it was simple, just as fast, and at least the configuration was about million times easier, plus theme support was *much* more mature...)
I don't care about the program's version number, as long as it works. =)
wmflame, the system load monitor.
In a way, I wish I had never discovered Windowmaker. I've been spoiled by it too much. I'm too used to 0% cpu and 0% mem usage (as measured by a whole slew of cpu and mem meters) from my window manager. Every time I try out a new build of KDE or Gnome, I get to impatient and irritated and go right back to Windowmaker and DFM.
;)
Damn you, Alfredo Kojima! Damn you to hell!
I've just upgraded to Linux From Scratch 3.1 (which I can highly recommend by the way) and I was not looking forward to compiling and installing all of Gnome and/or KDE from scratch. I even got halfway through compiling Gnome 1.4 before I tripped over the fact that a key system library needs the new Gtk+ which doesn't want to run with many other Gtk+ apps I have. Anyway, out of curiosity I grabbed WindowMaker because it was a) small and b) needed very few dependencies - the basic image libraries I think was all and since I had those I needed nothing more.
I'm not going elsewhere anytime soon. WM is fast, easily configurable and almost as pretty as E without chewing half the CPU. And to echo the sentiments of Bronster, it doesn't get in your way.
--- Hot Shot City is particularly good.
Well, I just run KDE 2 with its Windomaker/Step-style theme, and turn off a lot of the crap. ;-)
(That's something that some people fail to grasp about KDE - it just defaults to looking vaguely ms-windows-like)
Regarding the fonts, my fonts look lovely with KDE once I switched to using the antialiased ones - Qt and KDE can use the new XRENDER/Xft font subsystem of XFree86 these days.
Another problem a lot of people have is that they are running their X Server at 75dpi, when in fact many modern displays are closer to 100-120dpi (mine's 120dpi...) - I've yet to see a distro configure this properly (for a quick fix, start X with the command line -dpi option set to something approximating your display, or configure it in your XF86Config file). Since correct font rendering depends on knowing the physical size of your display, most people end up with really tiny looking fonts, since their X server thinks the display has a lower DPI than it really has.
Regarding the load time of KDE - one major problem has been traced to the inefficient way the standard dynamic linker loads C++ shared library files - a new release of the linker will fix that, and produces a huge improvement in C++-on-linux application startup times in general (this is not just a KDE problem). Coupled with the slowly-stabilising-to-de-facto-standard C++ ABI given to use by gcc 3.x, this should make linux C++ development easier and much less painful than it has been historically.
Personally, I'm not all that fond of C++, but lots of people are, and lots of commercial/niche applications on Win32 and commercial proprietary unix are in C++, so making C++ on linux work better is definitely worthwhile.
Choice of masters is not freedom.
There are already debian packages in .. sweeet.
unstable
There are only 10 types of people in the world: Those who understand binary and those who don't.
I still have not figured out how to get rid of these silly app icons that pop up for every program you open. The only way I figured out how is to right click the apps title bar, click attributes, click the menu for Application Specific and put a check in No Application Icon.
This has bugged me for years.
ROX is a fantastically great, small, and fast filemanager, http://rox.sourceforge.net/
Very cool, has most of the features I liked of Nautilus/Konqueror, but makes my AMDK6-2 400 work *so* much faster..... Give it a try, really great project.
XML is like violence. If it doesn't solve the problem, use more.
It is not appropriate to compare WindowMaker to GNOME (or KDE) since WindowMaker is a window manager, and GNOME is a desktop environment. It would be more appropriate to compare WindowMaker and Sawfish(the windowmanager that GNOME defaults to). Further, there is no reason that you can't use both, like having the gnome panels and desktop tools running, but using WindowMaker instead of Sawfish (which I have done in the past).
Now, GNOME2 can be pretty sluggish. However, Sawfish itself seems to be reasonably fast (and low CPU usage) on my P2-200. I doubt that I would feel the same way about sawfish on a 486 (which I typically use WindowMaker or blackbox on for speed). The whole construction of sawfish fasinates me (it is basically written in lisp), and I keep wanting to find a way to integrate it with emacs and my other lisp programs). However, I haven't yet had the time to investigate making sawfish behave in a more WindowMaker like maner. It should be possible though.
I'm a loser baby, so why don't you kill me.
There's a nice surprise in WindowMaker, but you can only see it on the Christmas eve. Take your system date back to December 24, then run wmaker, right click on the desktop then pick "Info Panel" from the "Info" menu to see the egg.
I only tested this with version 0.70 but I think it works with 0.80 too.
Petru
Try:
http://www.plig.org/xwinman/index.html
There are them all.
I haven't used AfterStep in a while, but if it's still more or less similar to the 1.0-era AfterStep, then it's not really all that similar to NextStep.
AfterStep began as a hack to FVWM 1.0 (originally, the dotfile format was almost identical) and thus is much more similar in terms of the way it behaves for the user to any other of the "old-school" window managers, with a dotfile to control behavior and little in the way of dynamic configuration or application management once you're in.
STOP . AMERICA . NOW
But that's a deeply silly way of having large fonts in this day and age.
Basically, you're _much_ better off running at the highest pixel resolution that's available, and correctly setting your DPI so that you can use points (or even millimeters) to specify font sizes. - that way, if you want larger fonts, you set the font size to "16 points", and if you want smaller fonts, you set it to "6 points". On a 1600x1200 120 DPI display with antialiasing, a 6 point font is perfectly legible, and a 16 point font is absolutely beautiful. The "point" is a measure of the font's physical, real-world size, so correctly setting the DPI to a higher value on high DPI screens simply means that the font is the correct height on screen, but more legible.
Basically, increasing the pixel resolution and correctly setting the DPI should increase the level-of-detail on-screen, while allowing a "10 point" font to be the same height, as measured with a ruler held up to your screen. In 640x480, you won't see the serifs clearly on "Times", but at 1600x1200, it'll be almost like reading a newspaper.
People seem to screw this up a lot, but it is incredibly important for desktop publishing. I can hold a printed A4 sheet up to the screen on my system, and set the zoom factor in the word processor or in ghostscript to "natural size"/100%, and the sheet will be exactly the same size as it's on-screen representation.
Windows used to screw this up, X Window System was designed not to screw it up, but then application coders got at it, Mac OS X (via display pdf/quartz) and NextSTEP (via display postscript) got it right.
Emelfm. I love this filemanager. Search for it on freshmeat.