In this page I will describe the control center project and the design I had in mind.
WinLibre’s control center should provide the user with a clean and easy-to-use GUI that provides the following options:
The control center program can be divided into three main parts:
For every task that WinLibre needs to perform there is a single module. Every module must extend the WLModule class, and needs to override the following (and perhaps additional) functions:
When starting, WinLibre’s control Ceter reads a text file with all modules names and loads them one by one, that way adding new functionality to WinLibre is easy: just write a WLModule subclass, put the source code in the same directory as the other modules, and add this module name to the text file.
The following modules must be implemented
This module is responsible for launching different programs. Its hasDisplay() function returns False (this module has no display), and therefore its getHtmlDisplay return an empty string.
The run() takes a non-empty list of string, where the first item is the name of the program to be lanched, and the rest of the items (if they exist) are command line arguments to the program
For security reasons this module will only launched programs that are registered as WinLibre programs. The list of registered programs will be generated on startup using an XML file. The same file should be used to keep track of the different versions and will probably be used by the updater as well, since this part is common to both projects I will continue the discussion about it in the collaboration page.
This module generates the main welcome page. Its run method does nothing (it doesn’t really do anything except for generating the HTML source of the welcome page)
This module is responsible for getting news. I did not think of a complete design yet but I am aware of the following notes:
This module is responsible for providing quick access to web services such as Wikipedia, google search and more.
I did not work on it yet so I don’t have a complete design.
The idea I had for the GUI was a frame with tabs (Notebook and NotebookPage objects in wxPython). There is a single tab for each module (that has a visual display) that consists of a single WLHtmlWindow (a HtmlWindow subclass). When starting, the control center adds a tab for each module (that has a visual display) it loads and sets the HTML contents, that way future developers can add new functionality without changing existing wxPython code (actually they don’t even need to know wxPython, only HTML).
Advantages of using HTML as the display format:
Disadvantages of using HTML as the display format:
The WLHtmlWindow is a regular HtmlWindow with the OnLinkClicked(link) function implemented as follows: Each link will be of the form:
<a href="Module:Function:parameter1;parameter2;parameter3 ..."> link </a>
Clicking a link will call the appropriate module’s function with the given parameters. This mechanism will be used by all modules to provide access to their functionality.
To make things easier we will have (at least this one) special case:
<a href="http://www.somewhere.com"> somewhere </a>
Clicking that link will do the expected thing - launch Firefox and open the given link.
The WLControlCenter class is the communication tool between the WLGUI (the user) and the WLModules (the program). The usual cycle will be: WLGUI gets request from the user, sends it to the control center, the control center tells a module to do something useful, and finally the control center sets some visual attributes of the GUI (e.g: User clicks the “get news" link, the GUI sends the control center the request, the control center asks the WLModuleNews module for a HTML page containing updated news and sets this page as the HTML page of the News tab in the GUI).
In addition to that the WLControlCenter is in charge of all the error handling. It catches exceptions raised by the modules, and tells the GUI to display a meaningful error message.
These are some issues that I need to think about:
My programming strategy is some hybrid of XP and usual programming. I like to build a simplistic model of my program, see how things work, then write unit tests and start adding functionality and tests as I go.
My approximated schedule is:
Text documents (text/doc/pdf/whatever):