I updated the project with concepts screens of what the final outputs will look like. Ideally the information is contained in modules that can be re-positioned using some kind of outside app which generates a configuration file which contains the information for displaying modules on the main screen, and contains triggers for how to get to the module-specific screens. For instance, if you say, "Weather", and a weather module is installed, the screen will switch to a full-screen version of that module, displaying more detailed information. This could also be the same for the agenda, music, and stock market modules when they get implemented. I've also been thinking about how all these modules are going to be able to update quickly. I think I'm going to research more into window managers and see how they implement, well, window managing and see if I can learn anything from them. I am also looking into having the main process daemon-ize when the command is run, and then being updated through some command line interface which communicates with the main process by telling it what to do. I know that the cmus music player for Linux does this, so I will have to look into it. Hopefully I can use the Linux internals, since they are proven to work and I would learn something new. Other than that, I've been busy with a number of other projects but have been doing a lot of conceptual thinking of how I want to lay out the architecture of this project. Going forward I will have to be mindful of the fact that I may switch to a C program using OpenVG, so I will need to document how my code works so that I can port it easily. Or perhaps write C bindings for use with Python so that I get the great modules in python and the important screen drawing code in OpenVG for speed.