Screenshots: Multiframed
Almost fullscreen
Different types of frames


01/06/2004 - TrsWM 0.5.2 released. Nasty bug in session module, crashing trswm on restart, is (hopefully) fixed. Also I've added FHINT_DONT_SAVE frame hint to disable saving certain frames (there's almost no point in saving FRAME_TRANSIENT frames, they are transient :-)

01/03/2004 - TrsWM 0.5.1 released. Almost no new features since 0.5.1a, only minor bugfixes.

I've made some progress towards 0.5.1, and decided to release 0.5.1a, for you to test netwm module and express your wishes or concerns. Right now I'm mostly satisfied with it, but some glitches remain, and I'm really hoping to sort them out for 0.5.1. New stuff: NETWM compliance module. It's very nice (and usability-enhancing) to have fully-featured taskbar, pager and all that. Also, some preliminary (slightly buggy, but...) KDE systray support was added. No, trswm won't dock systray icons into the dock frame (yet ?), but KDE systray protocol requires WM's interaction in systraying support, and this code was added to the netwm module. And, as usual, some bugfixes and minor enhancements.

TrsWM v.0.5.0 was released 11/11/2003. I've tried to make this release as stable as possible, as well as fix some installation and configuration problems. Also, first signs of documentation can be spotted (if you're lucky :-). What's new:

  • between 0.4.9 - almost nothing, mostly bugfixes. RenameObject and CreateWorkspace macros were added.
  • between 0.4 - lots of new features, most notably totally new resize engine, allowing linked and opaque resize and movement of frames. Also, lot of bug and "feature" fixes.
In short, 0.5.0 is a greatest and stablest trswm version ever, and if you're feeling brave (or bored), grab the source, compile it, and try it - there's a chance you'll like it ! :-)

I have set up trswm-devel mailing list at, so if you have any trswm-related questions, please visit this page, subscribe and ask them there. Or e-mail me directly.

So, what is TrsWM ?

This is a window manager (WM), built on ideas of another (excellent) WM, Ion. Fundamental principles of both Ion and TrsWM are reduction of manual window positioning and possibility to completely manage windows using only the keyboard. Ideally, mouse could be optional and supported, but neither main nor required method of manual window management. Below I will briefly lay out some thoughts and ideas which motivated me to start TrsWM development.

1 Easy extensibility and ability to build lightweight and useable environments for systems with limited resources, as well as more featureful (or just better looking) setups, if sufficient resources are available. TrsWM was designed from the ground up as a set of modules, and many architecture features are geared towards easy addition of new modules and their independence from each other. This goal is largely achieved - main executable contains only small set of service functions, totally unrelated to functionality and behavior of the system built using this set. All the "window management" code is in the modules.
Ion also supports dynamically loadable modules, but "pluggable object event handlers" technique, while very useful and extensively used in OOP, sometimes is less than optimal for WM, and some interesting features are difficult to implement within Ion's framework without modifying main WM's source code.

2 Window layout policy. Ion's basic idea "screen is split into non-overlapping frames, each frame contains >=0 windows, each window's size is <= size of the containing frame" is genuinely simple and beautiful, but often is not sufficiently versatile. TrsWM utilises somewhat different policy - "Every window is placed into the corresponding frame, frames could be of different types, frames with equal type do not overlap". This policy, IMO, is better targeted on maximising usability of modern complex software suites.

3 Handling of position and size requests coming from client windows. TrsWM generally sticks to Ion's policy "window will have no more space than available in the parent frame", but could be set up to satisfy such requests from selected classes of windows. Sometimes software developers know better why their programs need this space.
Well, two previous reasons are partially obsolete with introduction of "floating workspaces" in Ion, but (IMO, again) mixing two completely different policies would sometimes lead to user confusion.

4 (Reasonable) integration with a scripting language. TrsWM was started as a project when Ion was using its own, quite simple but sometimes not flexible enough configuration format. Choice of Lua as a scripting language extension proved itself right. Since that both WMs are using Lua as configuration (and more) backend. I want to say, however, that current Ion development path - "rewrite WM using Lua" do not seems entirely correct to me. Back in time, Sawfish was almost entirely written in some kind of Lisp, and, while absolutely tunable and easily modifieable, was not very well suited for usage on slow systems due to unacceptibly slow (for WM) execution sometimes.

Well, enough for now. I'm neither English-native nor technical writer :-), so excuse my grammar and overall style of this document. If you want to discuss this topic, add something, or, maybe argue - my email is below, and your opinion is always welcome. And now look on the right side of this page, read Release notes, grab a tarball, ./configure && make && make install and try TrsWM for yourself . Maybe, that's what you were searching for ?

TrsWM logo
Useful and

Current version of TrsWM:

Source tarball
Source RPM
Glibc 2.2/i686 binary package

Please, tell me what you think about TrsWM - yarick at relex dot ru
With all the best, yarick at relex dot ru