• Updated changelog, release notes, home page, and version.
• Tagged as v0.2.0.

• Added some basic info about layouts to minx.core.wm doc string.
• Updated hooks-list.wiki with info about new hooks.
• Fixed a bug in layman.receptive_layout(): have to add layout returned by receptive_layout_hook to layouts list.
• In layman.find(), added ability to search for layouts based on their names. (Noticed we needed this ability when writing sample code to illustrate layouts usage.)
• Removed unnecessary warnings from minxlib::window, which were simply cluttering the log.
• Other minor edits elsewhere.

• Moved focus change event handlers from minx.core.xevents to minx.layout.base.
• Removed reparent notification handler from minx.core.xevents in favour of handling the event entirely from minx.layout.base.

This should pretty much all the code that's needed for the 0.2.0 release. Now to tackle the documentation... check-in: 4dc459e610 user: manuv tags: dev1.x

• Added support for end-user hook to create layouts before managing existing windows and entering event loop.

• Made the display and root_windows members of the minx.core.wm class public (i.e., removed leading underscore) so that they can be accessed by the init_hook.

• Removed unnecessary layout creation in wm.start() because the default layout logic in the layman.receptive_layout() method takes care of this already.

• Forgotten to register exception translators for protocol errors.
• Add exception handler for generic protocol errors in minx.core.wm event loop.

Got the idea for this from a cursory perusal of the code for xbindkeys. And now (at long last) key bindings work flawlessly! Getting close to the 0.2.0 release... check-in: 17ccc163e4 user: manuv tags: dev1.x

• Since we often need to meddle with a window's geometry, changed minxlib::window::geometry() so it returns a list rather than (an immutable) tuple.
• Fixed a bug in minx.layout.full.configure_request() that was offsetting window placement within the layout window.

However, target window still gets the key press event (e.g., a terminal window types 'd' when M4-D is pressed). Also, it doesn't work for all windows (e.g., xmessage doesn't respond). So there's still some work to be done here... check-in: bfb7417666 user: manuv tags: dev1.x

But at least now we have some basic infrastructure for a separate layouts directory/subpackage. check-in: 0a84c4d950 user: manuv tags: dev1.x

Next steps:

• Code clean-up and documentation.
• Bug fix: killing a window doesn't focus another.
• Bug fix: some key bindings are not recognized when a window has focus.
• Extract and abstract layout functionality currently in wm and xevents.
• Remove hard-coded border adjustments when resizing windows to fit layout.
• Add support for multiple screens and Xinerama.
• End-user hooks for creating custom layouts before launching window manager.
• Layout windows need to be transparent/invisible.
• Documentation for all of this (design notes, HOWTO's, etc.).

That's when we'll be ready to hit 0.2.0. check-in: ab72e115ad user: manuv tags: dev1.x

Eventually, should implement layouts so that killing them doesn't take down the window manager. check-in: 0d21ae6035 user: manuv tags: dev1.x

Also: various minor edits. check-in: fa47a47a48 user: manuv tags: dev1.x

Also some minor fixes to:

• minxlib/factory.hh: figured out Boost iterator adaptor weirdness in factory_map::iterator::dereference().
• minxlib/exception.cc: corrected a stale comment.

• Minx doesn't have to maintain internal mappings of which windows a layout is managing, their respective geometries, etc. Instead, we can simply query the X server for this info when we need it.

• It is much easier to implement layout nesting (again because the X server already provides the necessary infrastructure for creating and managing hierarchies of windows).

• Because layouts are simply top-level windows, entire arrangements of tiled windows can be easily layered and moved around. That is, instead of a single floating layer, we can have multiple layers.

• Moving windows between layouts is a simple matter of reparenting the window. X will generate appropriate events, which Minx can handle to update any internal state (which is already minimal).

• If Xinerama is available, moving windows and entire layouts across screens should be fairly straightforward to implement (useful, for example, for laptop un/docking).

Seriously, what's not to like?

Now, having touted the numerous benefits and basic soundness (genius, anyone?) of the layouts-as-windows idea, a few words about this check-in:

It begins the long and winding road leading to the grand vision described above. At this stage, of course, little of any real use is available. minxlib provides an API for creating new windows and the main window manager object uses it to create a black, top-level window the same size as the root window.

That's pretty much it; no window management, tiling, multiple screen support, etc., just yet. In fact, the layout window is just another window that Minx manages. Killing it, hilariously enough, nukes the window manager. check-in: df1a814742 user: manuv tags: dev1.x

• Added an Asymptote program to generate the Minx logo.
• Updated makefile in wiki/img to generate logo.
• Added the logo itself to version control.

TODO:

• Check for and use WM_DELETE_WINDOW protocol if supported.
• Add Doxygen comments for new code.

• Fixed minxlib::keymap so its Doxygen documentation will be generated.
• Added link to minxlib::keymap documentation on Doxygen main page.
• Added _minxlib to grp_* labels for minxlib::event and minxlib::exception. Fixed reference in minxlib::display to use new label.
• Added table showing mapping between minxlib and Xlib names for minxlib::protocol_error::failed_request_reason enum.

• Added a FAQ about key bindings.
• Added default key bindings to the hooks list.

For example, if Num Lock is configured as Mod2, all key events will reported with Mod2 set in case Num Lock is on. Thus, simple F1 presses will be reported and interpreted as Mod2 + F1. If there's no such key binding, Minx will ignore it; if there is such a key binding, Minx will end up executing the wrong function!

This commit solves the problem described above. check-in: 7a3edcd1c4 user: mvnathan tags: dev1.x

• Moved focus cycling code from xevents to wm.
• Removed hard-coded F1 for focus cycling.

TODO: Document minx.core.wm.focus_next() and focus_prev(). check-in: 4aac700f62 user: mvnathan tags: dev1.x

NOTE: Code is in sore need of documentation; many functions have none and, even worse, some of it is downright wrong! check-in: afb577d64d user: mvnathan tags: dev1.x

Otherwise, end-user code will fail if it doesn't check for the existence of these keys in the dictionary returned by the properties() method or fails to handle the resulting KeyError.

The problem became apparent when launching an XFCE Terminal, which creates hidden top-level windows without the above properties. The end-user manage_hook then bombs out when it examines the properties map for these hidden windows. check-in: bca46583e9 user: mvnathan tags: dev1.x