The future of Desktop customization. Pt. I.

Greetings. Sacrat online. This time I'd liked to share some of my (and not only my) thoughts about the future of Desktop customization. And as i mostly work with shells, this article would be biased towards them.

In my personal shell classification I divide them into three large groups.
The first group contains pure minimalist shells. They were designed to free up some vital memory, eaten by Explorer (a known resource hog) and replace the same explorer for the most common tasks, like launching applications, browsing windows, etc...
The second group of applications was still often used to save system resources, though allowing users to customize their environment in an easier way. A clean application of such kind os hells are Litestep and Aston. Shells could be customized by adding plugins, changing elements' appearancy by applying skins and so on. With some effort from the themer's side second generation shells could have quite a different appearance and functionality.
The last group does not have any samples yet. With some limitations Stardock's DesktopX could be called a precessor of the third generation shells, which, I believe, should appear in next five years.

So, what should such a third generation shell be? First of all, at the beginning of the XXI century, where we live now, the problem of a lack of resources is less important, than it was a decade ago (surely, there would always remain some twisted handed programmers) and I have some doubts that even such a monster, as Longhorn would be able to waste them all. And, operating with such powers, shell programmers would be able to make a shift from resource saving to usability and customization. In other words, I expect third generation shells to be slower just because of their additional functionality (as EMEDitor is slower, than MS DOS EDIT).

So what should such "functionality" look like? The process of separating a shell into several parts should come to its logical closure. For example, most second generation shells consisted of a core (usually drawing some basic control elements) application and a set of plugins, which were "attached" to this core, extending its functionality. In some cases (SharpE) a shell itself was divided into few parts, each of them can work independent. Third generation shells might be performed by a core, capable of drawing needful elements on demand, but not having any specific embedded controls, like before. In other words a core (it might be called a kernel) itself won't draw any taskbars, toolbars and menus, like its precessors did some years ago. Instead all the control elements would be done by plugins, working on a completely new principle, than before.

Unlike before, a plugin itself doesn't draw anything. It just sends messages to the core, which does all the work. Such an approach is more flexible and allows avoiding numerous problems, typical to second generation shells. From another point, such plugins must be more stable, than before, as crashing, e.g. a tasbar.plg could cause serious troubles to a user.

The role, previously played by plugins, would be performed by widgets, small visual applications, running inside a shell. Operated by messages, sent by core and plugins they would be able to do much more, than any second generation shell plugin ever could. For example, if would be possible to combine Winamp control and clock in a single widget. Or even more weird idea: combine RSS news aggregator with a weather worecast component. With such an approach there would simply be no need for a standalone taskbar or Toolbar: one could construct and define its behaviour manually.

Scripting, basicly implemented in some second generation shells would become an important part of any third generation shell. Scripting would allow designers create widgets in a more flexible way, extending their functionality. From another point, such scripting languages should not be complex enough to be used by themers, which are mostly not familiar with programming. Otherwise theme creators would have to unite with programmers (just like it happened with Winamp 3 and 5) in order to work, which may cause reducing theme making speeds.

The idea os dynamic skins, partially implemented in current DesktopX would be developped. So there would be able to create themes, changing their appearance according to the time, date and use behaviour. Control elements would "recognize" its owner and ease his work. No, I'm not referring to talentless "ergonomic" menus, "invented" by Microsoft. There are a way better ideas (some of them were suggested by Ivan Oshchepkov)...

...to be continued...
pt II is coming soon