AfterStep 1.3.1
It seems like only yesterday that I was asked to write an article about AfterStep for LJ's special issue on GUIs (graphical user interfaces), and now here it is. The main points I will focus on are the following:
History of window managers and in particular AfterStep
The future of AfterStep
Desktop philosophy of AfterStep 1.3.1
My conclusion is that the best GUI is the most productive one, but only if it remains user friendly. Users must be free to do anything easily using their window manager.
The first window manager was TWM from Evans and Sutherland, and it was the base upon which Robert Nation created FVWM. FVWM has been used to create most of the modern window managers: FVWM2, Enlightenment, amiWM and Bowman. FVWM2 was used as the basis for FVWM95, and Bowman evolved into AfterStep. In this “tree” hierarchy, some exceptions appear: WindowMaker, the NeXT emulation window manager; and KWM, the KDE project window manager. Both of these managers were written from scratch.
Is starting at the beginning better than modifying an already existing window manager? It may bring personal satisfaction, but it will also create duplication of effort. Since all of these programs (FVWM, Bowman, etc.) are freely redistributable, there's no need to write the same code twice. If a feature you want already exists in another window manager, just take the code and patch it into yours. This method will save you both time and effort. FVWM already had most of the features of the modern window managers. The concept has progressed only slightly, while the appearance has radically changed.
AfterStep, derived from both FVWM and Bowman, was first written by Dan Weeks, Frank Fejes and Alfredo Kojima to emulate the NeXT GUI. When they realized they couldn't put all the features they wanted into AfterStep, a new project was started—WindowMaker. WindowMaker is targeted at Gnustep (GNU approach to NeXT programming and interface) with very innovative concepts, e.g., dock, DnD and “sticky” menus.
Even if it limits you in some ways, the ability to build on a good base is very useful. You don't spend most of your time coding a good equivalent of FVWM with many bugs. AfterStep is now evolving toward new heights, including simpler and more powerful configuration. Rather than maintaining AfterStep and allowing other managers to pass it, we (the developers) want it to become the most innovative window manager. For example, we're planning to add a few new features. First, concepts that already exist in other window managers that we plan to incorporate into AfterStep:
A file manager in the root window (see Win95 and KDE) with an Irix-like desktop
WindowMaker Dock and “sticky” menus
Enlightenment-like window decorations with pixmaps
FVWM95 task bar
OS/2-like voice recognition (see the ear voice recognition project on Sunsite)
The code for these features from other window managers can be copied under the GPL (GNU Public License). I strongly believe in and encourage maximum source code re-usage. I like the FVWM95 task bar, Enlightenment decorations and WindowMaker dock DnD; they're very useful and easy to use. Mixing and matching concepts from several window managers will ultimately result in a “best-of-all-worlds” situation. That goal is why some people install and configure everything they find. Merging these features into a single program is a much more efficient solution. Therefore, the idea is to make AfterStep more friendly by including many features into a homogeneous work. I hope we'll be able to meet most individual tastes. And there's no need for coding in a new way (C++, Gnustep, Qt, etc.) to meet such goals since most of these cool features exist in FVWM parented window managers.
Figure 1. AfterStep Screenshot
I'd also like to see some new features that are not yet implemented in any window manager, with maybe a new way of coding. That's why AfterStep will first integrate the FVWM family features and then take a different path. New concepts that we wish to add are as follows:
NeXT desktop, in collaboration with the WindowMaker team
Module compatibility with FVWM2 and other window managers
Object-oriented management of AfterStep elements (title bar)
Animated icon and opaque window rotation
Total mouse configurability
Icons/help files/programs database (For example, a painting program without a nice default icon would “auto-magically” use a database icon containing a button for calling xman with the program's help file.)
Source code optimization to keep AfterStep from becoming slow
The sky is the limit. If you implement a good option in AfterStep, just send me your patch and if it's freely redistributable it'll be in the next version. If you think AfterStep is going to become 100MB, don't worry—all of these are compile time options. A patch is put in the executable program only if you request it (that's what we call meeting personal tastes). We're making AfterStep for ourselves, but one thing we also want is features we haven't already imagined. All this may seem quite ambitious, and we agree, we are. AfterStep's “pilgrim fathers” already did a lot, making such a good program, so it's not easy to make it even better.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
| Introduction to MapReduce with Hadoop on Linux | Jun 05, 2013 |
| Android's Limits | Jun 04, 2013 |
- Containers—Not Virtual Machines—Are the Future Cloud
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Introduction to MapReduce with Hadoop on Linux
- Senior Perl Developer
- Technical Support Rep
- Weechat, Irssi's Little Brother
- UX Designer
- One Tail Just Isn't Enough
- Android's Limits
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




42 min 49 sec ago
43 min 16 sec ago
3 hours 8 min ago
7 hours 18 min ago
7 hours 22 min ago
1 day 2 hours ago
1 day 3 hours ago
1 day 4 hours ago
1 day 7 hours ago
1 day 8 hours ago