Windows Layout Manager (WiLMA)

Over the past year I've received quite a few questions from people wondering how I manage all the windows that must be all over the place on all the various screens and systems. The standard answer is that "I've got my own little tool that I developed for managing window layouts" (on single as well as multiple systems simultaneously). However, that standard answer seems to result in even more questions as to how it works and what it does. Since I'm a firm proponent of code re-usability I'm also a firm believer in not wasting too much time answering the same questions over and over again so I've decided to answer the question in detail, once and for all.

What I'm using for my windows and layout management is the Window Layout Manager, or WiLMA for short (hey, as developers we're allowed to invent a dozen new acronyms each day and we like that little perk!). The following page provides a more detailed outline of what the Window Layout Manager does and how I use it. The Window Layout Manager is a small 500K application, written in C# and using The .NET framework 2.0 and higher, using a lot of imports from user32.dll and avoids any unsafe code. But I bet you could care less about THAT. :-)

The cool thing about WiLMA is that I can get the same thing done in different ways and the combinations of all the options and features allow me to construct just about any layout under any circumstance and with any combination of how I apply it.

The main application has a basic window that allows the management of various layouts. Adding new ones, editing existing ones, configuring the options, all the basic things you can expect from any normal application. When closed or minimized it sits in the tray and offers a tray icon with quick access to layouts that are enabled (it's possible to exclude layouts from populating the tray menu since some layouts are not meant to be applied directly).

A layout is a collection of window definitions that contain conditions and actions. Conditions that describe the window and how it should be detected and matched and actions that allow various actions to be taken such as minimizing, moving, relocating, moving it to a different screen, offsetting the position, maximizing it to a certain screen, etc. There are three types of layouts:

• Normal Layouts: these contain window definitions where the entire layout can be applied to a current desktop.
• Individual Window Layouts: these contain window definitions that can be applied individually through an active window context popup menu.
• Live Layouts: these are layouts where the system is monitored and when windows that match any or all definitions it will apply the actions to that window as it becomes available and gets noticed.

Sounds complicated? Not really, but the Window Layout Manager offers enough features and combinations that it does need a lot of fine tune control over how the application behaves, as can be seen from the main configuration options:

Some of the options offered here are:

• Restoring a layout after a specified time-out (if enabled) will pop up a small window after a layout or other actions are applied so they can be kept or undone.
• Ignoring certain process names for the Automatic Capture feature.
• Options that fine tune what is included in an Automatic Capture of all the available desktop windows.
• Detection options that control what types of windows are looked at and considered when a layout is applied.
• A check newer version on startup because I had to implement a common approach to that for a different product and I used WiLMA as the test application in which I tried out the best approach for it. Needless to say, I never have to check for newer versions because I'm quite aware when I modify it and compile a new build. :-)

And of course system wide hotkey support (with a thank you and shout out to Max Bolingbroke who had provided a very clean example as a result of working with Movable Phyton). The Popup Hotkey allows for a popup menu to appear over the active window that offers the matching layout options that are available within the layouts managed by the Window Layout Manager. A way to quickly position windows individually without using an individual window hotkey or entire layout. This is what the Individual Window Layout type of layout is for.

Above is a screen capture of the Layout Editor where layouts can be given a name, an optional description, a hotkey (to apply the entire layout quickly and efficiently), and a whole range of other options such as:

A collective layout offset. Imagine you've got a layout that has all its windows located on the left screen in a dual monitor setup. You could create another layout and edit all the window definitions individually to instruct it to take actions to relocate them to the right screen - either by screen relocation or XY offsets, but it's easier to copy an entire layout including all its window definitions and within a multi-monitor situation simply provide a collective offset for the entire layout and all its window definitions.

Why would you want to do that? Well, in my case, if you've seen my home office setup, I regularly have a certain set of windows on a specific monitor and want to keep the layout the same but move them around because I angle and rotate one of the screens towards a guest that I'm showing something. In that case I just hit the hotkey or apply the layout so that all those windows get positioned exactly as they are on one of the other screens. That then clears a monitor for other display purposes.

The layout editor allows for adding, editing, copying, removing, and capturing windows. And copying window definitions between layouts (to make life easy and avoid having to create duplicate definitions in different layouts or to grab a predefined definition in the repository for easy editing).

Capturing is the process whereby the entire layout is populated by all the windows that can be found on the desktop and running on the system based on the detection options (a.k.a. the Window Filter that can be overridden and specific for any layout). If I've moved a bunch of windows in the positions that I'm most comfortable with and wish to preserve as a layout I just hit capture and that is sufficient for all the basic tasks. I can then always edit each individual window when I see fit.

The window definition overview shows the basic conditions and criteria and actions. It may seem rather cryptic but this is part of an older version of WiLMA that was command line driven and used configuration files where conditions and actions were specified in a proprietary format (which WiLMA takes care of in a full user interface).

When a layout is set to "Enable Individual Popup Selection" it means that each window definition can be applied to an active window that matches the criteria. For example, I often need to move around my command shell windows (mostly PowerShell these days since I'm a total PowerShell fan!) and prefer it in very fixed positions. There's about seven different ones and in an "Individual" layout I can define all seven of those, give them a description and when I make a shell window active and hit the popup hotkey it offers me a popup context menu with all these seven choices. I hit the menu item for the actions I want applied and wham, I can continue work without having to waste time moving the window around manually.

A closer look at the window definition or Edit Window dialog. As you can see, individual windows can be given a hotkey just like entire layouts can. However, a hotkey for a layout needs to be unique while many different window definitions can use the same hotkey. What happens if you do that is that all windows that are detected on the desktop that match the criteria will have their actions applied. It is a little redundant since you can group the windows to a layout and manage it from a single layout but there have been situations where I prefer to have it both ways.

The criteria for a window definition consist of a few basics such as matching a definition to window based on the title (or partial title by wildcard or full Regex - that's regular expressions for those who don't know what that means). Same for the process name, process filename, and the window class name. Advanced matching includes whether a window is minimized, maximized, a main window, whether it is on a specific screen, or within a region.

The fun part about the editor (and certainly was fun implementing!) is that the parameters are enabled and disabled based on combinations that are either allowed or mutually exclusive. For example, the region criteria work in absolute coordinates over the entire desktop space unless the "on screen" is also selected, then the region parameters become relative to the selected screen. Coloration of the controls provide feedback when parameters are chosen that are considered to be out of bounds. It will allow this, but it will notify me just in case I'm making a mistake or trying to do something that would reposition a window where I can't get to it.

When all the chosen criteria are matched against a window one or more actions can be applied. These include minimizing, maximizing, restoring, moving windows to fixed positions, sizing windows, relocating to a screen, making a window on top or sending it to the background, or any combination of these. Again, all options are handled by exclusivity so if the action is "minimize" it won't allow you to also reposition and scale it because that would be pointless.

A Match function allows for a quick matching test against the windows on the desktop while the Test function allows for a quick test of the actions. A Find option is included to locate specific windows through the Window Locator (as seen below).

The Window Locator allows me to browse through all windows (including the invisible ones that shouldn't be messed with) and get a quick overview of their state, type, process, title, and various other details. Selecting one from the locator will automatically bring over the details to the editor so I can make minor changes and create the actual definition without having to spend too much time editing parameters.

If you are wondering why I've blurred a few things in there... those lines contained public IP addresses and a product name of something that I'm not at liberty to disclose. Sowwy! :-) And for those of you paying attention, the highlighted window there is called Ignytion Log Collector. Not nearly as interesting as the Window Layout Manager, mind you. Don't ask!

Something that is not part of the main UI but worth telling about is the peer to peer network feature. When enabled it allows all the WiLMA's on the network to find eachother and allows one machine to apply layouts of another system either locally or remotely. This was a quick hack I added in order to satisfy my own sense of "lazy but efficient" and while it works great it's really meant for a single-user scenario since it doesn't have any features for authentication and security. Imagine the terror you could cause in a network of multiple users running WiLMA. What fun that would be, eh!

The last thing that is worth a note is the Hotkey Explorer. Because it is easy to lose track of hotkeys and layouts and individual windows there's a quick overview for all the hotkeys used by the layouts and windows. It's mostly there for reference purposes because even I sometimes lose track of what I've been configuring.

So there you have it. This concludes the really quick nickle and dime tour of the Ignytion Window Layout Manager, WiLMA. While I've only covered the basics here I trust all the above contains sufficient detail so you can duplicate my efforts and write your own layout manager...

...or not.

I guess the next question I might be asked is... "Can I have it?!" or "Where can I get it?!". I'll have to think about that one. Since it's been written for proprietary use there's no "manual" of sorts and if there's something I really hate it's writing manuals for "end users". I like writing source documentation well enough but end-user manuals are just a pain in the you know what.