At the moment, we're not only busy, but we are also doing heavy foundational work on WiSeSLAp. In fact, we are moving towards full support for Freepascal property streaming/component serialization and WiSeSLAp factory/builder functionality, doing much work which was on the agenda only for post-baklava releases. Since we decided that the impact for the API would require major refactoring and rewriting if these technologies were incorporated later, we decided to do them now.
WiSeSLAp (the Widget Set for Super Light Applications, also WSL, pronounce wizzl) is a GUI toolkit written mostly in Pascal (using Freepascal) mainly by Michael Karg and Roland Schäfer, built on a GNU/Linux foundation and fit to run on the framebuffer console (via DirectFB). It can be used cross-platform, however. We now have three completed backends: Xlib (using either core X or XRender rendering), SDL, and DirectFB. The SDL backend will always be maintained as a fallback and for systems otherwise unsupported (like Windows(TM) and MacOS(TM)). We wrap the backends in the WslBackend layer in a way that there is a uniform object-oriented model of access to screen and input resources (in the form of the TWslDriver and TWslSurface classes), where surfaces are automatically cached and memory-managed by the driver.
WSL is planned for to handle many aspects of user-GUI interaction in a fashion different from that of traditional desktop GUI frameworks. Reduction of clutter and an adaptively behaving GUI with near-zero configuration are key design goals. In the future, WSL will be bundled with a GUI manager (more closely resembling a tabbed window manager than an ordinary window manager). WSL follows a from-scratch philosophy, and compatibility with applications written for Gnome, KDE, etc. is not among our goals. We are confident that, while this makes WSL a research system at first, WSL will be highly suitable for embedded applications. We are developing it to be used in our planned music/audio workstation HuMuS which is intended for desktop use (most naturally in fullscreen mode) as well as embedded/touch screen use. The selection of widgets (see WslWidgets) is influenced by the intended primary use in an audio application.
We see WSL neither as a competitor to any embedded/mobile extension to existing frameworks (like Hildon) nor to Clutter. Disko might be regarded as similar, but it's still different in scope and intention.
We use many established technologies like SDL, Cairo, Pango, and Portaudio, and DirectFB.
Documentation
We have set up our own ROBODoc customizations and have started documenting the API. Results can be checked in HTML and PDF Format:
A technical overview of the components of WiSeSLAp is being written: Technical Overview.
Download the Zenwalk 6.2 WiSeSLAp Testbed with DirectFB 1.4.2 ready to use
This VMWare virtual machine allows you to code with the latest DirectFB version if your regular distribution does not have up to date DirectFB binaries. VMWare tools are installed. DirectFB is compiled manually, and Cairo was re-compiled to support DirectFB. It also includes FreePascal, and a checkout of the WiSeSLAp SVN. It is based on the great GNU/Linux distribution Zenwalk. Use wiseslap:wiseslap to login (or root:wiseslap). New as of 2009-09-12: Based on final Zenwalk 6.2 and includes Gobby, Sun Java, Acroread, and RoboDOC pre-installed.
Bittorrent | Direct download (server capacity kindly provided by a-fon.org)
Please be patient when downloading the torrent. We will eventually go online!
You could use WSL …
- as a graphical UI framework for embedded devices supporting framebuffers,
- ... for standalone GUI aplications on GNU/Linux consoles (with frambuffer enabled),
- ... for standalone GUI aplications on almost any graphical system (X, Windows(TM)... and where SDL, Cairo, and Pango exist)*,
- ... as a complete graphical desktop system on GNU/Linux using the DirectFB multi-application core.
* Due to the absence of a unified open source build system on Windows(TM), we provide no build support on that platform (i.e., no Makefiles). We release Win32 binaries when we have time to spare. We personally aren't interested in MacOS(TM), but encourage people with GCC and FPC build experience to come forward and contribute to the project by providing Makefiles or builds for that platform.
Organization of SVN repositories
As of 2009-09-12, we have moved back to SVN from Git. Unfortunately, Sourceforge doesn't enable Git support in Trac, which lead to this decision.
- /trunk contains code which is partially feature-frozen and moving towards an official release
- /trunk/external contains bindings (if you like to check out just these)
