Jim Babcock | 16 Feb 07:59
Favicon

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.

(Continue reading)

chris | 16 Feb 18:31
Picon
Favicon

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

Jim Babcock wrote:
> 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.

I have, as do other developers, our own "experimental" branches of code 
in which we try out different ideas to see whether we want to bring 
these into the core.  What you suggest is a norm, but we purposefully do 
not include such things in the repository.

We have long since learned to not put LiteStep through a complete 
rewrite/ conceptualization.  You have come into the scene at the start 
of the slow incremental process of bringing LiteStep into a place where 
it can grow and be updated with new functionality without cycles of 
"scrap everything, rewrite, developers disappear, stagnate in abandoned 
code base, new developers, rewrite, developers disappear,  ... ad nauseam".

0.24.7 was the first step in breaking that cycle, and 0.24.8 is the 
first update after having established a decent code base of 
functionality that supports existing modules and themes.

The following step is 0.25.x which starts dropping legacy code (Win95 
cruft) and brings in support for the latest Vista/Win7 systems.  This 
will provide the ability for the existing rich LiteStep content to be 
available on the latest systems while we move forward in providing new 
functionality in future releases.

> 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
(Continue reading)


Gmane