Proposed compatibility-breaking transition period for LS architecture changes, starting in May

I started to write an article the other day, about my LiteStep module
Screenbar and what it means for themers and for other modules. After a few
sections, it fell into a pattern: explain how something doesn't work properly
in LiteStep (no matter what themers do to cover up the problem), and how my
module will solve it, but will require things to work differently. To solve
the problem of fragile layouts based on manually writing formulas to compute
coordinates, themers can use Screenbar's widget hierarchy, which is more
robust. To solve the autohide, multimonitor and Z-order problems, themers
should make all the little widget modules children of Screenbar, which handles
all these things. Unfortunately, child modules don't work all that well;
modules have to change how they handle the parent paremeter to initModuleEx,
and to have multiple instances (ie, to have a copy appear on each monitor),
some new entry points are required. In other words, everything would work
better, but work in a completely different and non-backwards-compatible way.
There are similar problems with the desktop maximize area and with the start
menu. Screenbar comes with its own, wholly new concept of how virtual desktops
ought to work, which is completely incompatible with RabidVWM and the four-pane
interface that people are used to. On top of all that, the way Screenbar uses
RC files makes you really want to change the syntax. For a module, it's a tough
sell.

LiteStep's problems, however, are much bigger than one module. Some
problems are common bugs that must be fixed in every module of a particular
type. Fixing these problems requires getting rid of all the unmaintained and
abandoned modules. Some are missing functionality which has been added at the
wrong level - modules implementing features that belong in the core, and themes
implementing features that belong in modules. Fixing these problems requires
changing the interface, reimplementing the feature properly, and getting rid of
the broken implementation.

I propose that LiteStep undergo a 6-month transitionary period, starting
on 23 May 2009, in which to try out radical ideas and architectural changes
without worrying about backwards compatibility. At the beginning of this
period, we declare the last backwards-compatible version LiteStep 1.0, then
start a LiteStep 2.0 fork. We select a bare minimum set of modules and fork
them as well and update them as we go to reflect changes to the API. At the
end of the period, we release LiteStep 2.0 together with a set of core
modules, a new OTS version, an official installer, and a few demo themes.

There are many ideas that would break compatibility, queued up. A 6 month
period should be long enough to implement most of them, and this way, we
only break compatibility once from an end user's perspective, no matter how
many times we need to break it from a development perspective. I chose the
date to correspond with about when LiteStep ought to be deemed v1.0 anyways,
and to start as schools are closing, as that's when developers tend to have the
most time.

Here are the issues that need to be addressed, as I see it. There is a lengthy
discussion to be had on each of these, but now is not the time for it. Please
reply to this thread only with comments on the transitionary period idea, and
wait until the transitionary period starts, or start a new thread, to discuss
specific changes.

1. RC File Format
    There have been a number of discussions about this already, the most recent
of which was a rather clever incremental change that would preserve backwards
compatibility. However, a more radical change is justified. Currently, the RC
file is half-way between a key-value store and a scripting language. It has
expression evaluation, but no way for modules to add functions to the
expression language's namespace. It has conditionals, but no loops or
functions. It has quoting, but no escape sequences. And the module API provides
functions to iterate, not over the variables defined in the configuration, but
over lines in the configuration itself - like interacting with a program by
iterating over the lines of its source code! Fixing this will require changing
not only syntax but also the APIs that modules use to interact with config
files. Incremental change is not sufficient.

2. Child Modules
    Presently, all modules with user interfaces create independent top-level
windows. The interface which modules provide to the core does not support
arranging them into hierarchies; while initModuleEx takes a parent window
option, this does not allow for the likely possibility of needing the same
module to create multiple windows with different parents, such as when a
taskbar is cloned on two monitors, and does not provide the container module
with any information about the child's size preferences.

3. Transparency
    Every module implements its own transparency, and while there are many ways
of implementing it, most of them break or become extremely slow if pushed too
hard.

4. Threading and Blocking
    LiteStep is single-threaded, and its API is not thread-safe. At some point,
someone added an option for "threaded module loading", which spawned separate
threads for loading modules. This of course lead to crashes, since modules do
non-thread-safe things on load. Nevertheless, before this option was removed
many users used it and became attached to it.
    Reintroducing threading in general is not feasible, but we might add a
watchdog thread to detect when a module's event or bang command handler has
gone into an infinite loop, and abort it. We certainly need some indication
of when modules are taking an excessively long time, and which module;
otherwise, module crashes may be misinterpreted as application or operating
system crashes, as with RabidVWM's WM_GETICON issue.

5. The Installer
    Right now, LiteStep lacks an official installer, but has a semi-official
third party installer, LOSI. This installer creates a framework of common
config files and installs, a set of core modules, and a default theme. While
modules may be auto-updated when switching themes, the common config files,
theme management scripts, and default theme cannot be updated. Users frequently
find themselves missing Visual C++ runtime libraries, which NetLoadModule is
unable to retrieve.

6. Taskbar Applets
    Explorer, OS X, GNOME, and KDE all have applets that can dock to the
taskbar, providing a little display showing the time, an RSS feed, CPU usage
or whatever else. End users can add and remove these applets without having to
look at config files or manually reposition other interface elements to make
room. The fact that LiteStep can't do this is downright embarrassing.

7. Configuration and Persistence
    Some theme options should be remembered when rebooting. For example, if
you drag Explorer's taskbar to a different screen edge, it remembers. LiteStep
does not provide any builtin mechanism for persisting options or for
identifying which options should be persisted.
    There are some options which you shouldn't have to edit RC files to change.
Explorer offers a dialog with checkboxes for autohiding the taskbar and radio
buttons for start menu styles. There should be a module which provides a user
interface for changing options, a standard way for themes to identify and
provide descriptions for options which can be changed in this way, and a set
of common options configured this way which are shared between themes.

-- jimrandomh