design - free open source church worship presentation...

Timothy Ebenezer OpenLP Documentation

Page 8

Design Overall system design This system is going to be deployed on x86 hardware, for the Windows platform. This is most suitable as Windows is the platform of choice for almost all churches around the world, and is what the users of my current system are most familiar with. Windows also has very good integration for multiple monitor support. The system will work in such a way that a user interface will be displayed for the projector operator on their laptop screen, or desktop primary display, and the image they wish to be projected is displayed on the projector and optionally, via a video splitter, to monitors for the singers/worship leaders. This idea is displayed below.

The church already owns a laptop which can be used in a similar way to the desktop computer illustrated above. The laptop runs Windows XP, so the software must be compatible with Windows XP. However, for transferability it would be nice for the software to run on any multi-monitor supporting Windows version (98, ME, 2000 and XP). The implementation will be carried out in the Delphi programming language. This language allows access to all the standard Windows API for multiple monitor interfacing and also allows access to DirectX API with a DirectX interfacing unit. The support for interfacing with Powerpoint using OLE was also a major factor in choosing to use this language. The databases connected to will be stored in the SQLite format. This is a very light SQL database, which is open source, embeddable, and very fast compared to MySQL, PostgreSQL, MS SQL Server and Microsoft Access. It also does not require the user to have any additional software and only takes up around 320k for the DLL file with all bindings. This is of particular interest considering that the application will most likely be available for download, and therefore size is of the essence. Description of modular structure of system The program will be built up completely of modules. These will be stored on the end-users hard disk as DLL files; however, within each DLL file there will be many modules which refer to different sets of procedures and functions. DLLs are being used in order to make updating the system easier. When updates are downloaded from the internet the file size is typically critical, and storing the whole system in one .EXE file would be unsuitable with a project of this magnitude because updating a small bug would require


Page 9

a massive download. Splitting each part of the project up into DLLs will allow for easier bug catching at runtime also, as Windows automatically tells you what DLL caused the error. The user interface could be completely overhauled and updated in a (relatively) tiny file, without having to touch other code. Also, the use of DLLs will make development of a possible plug in engine to support new features relatively simple. The way the system will be structured is illustrated below.

Main Program Executable

(This is a small .exe file to start up

the system and call the starting

form from the main DLL)

Name: OpenLP.exe

Main DLL

(This holds all the forms to for

the user interface and also the

main startup functions)

Name: OpenLPMain.dll

fmSplash

Form which shows

the user how

loading is going

fmMain

Main user interface

fmAbout

Form to show

information about

program

fmGphSettings

Form to allow the

user to change

graphic settings

fmScreen

Form which is

displayed onto the

display monitor

fmSongEditor

Form which helps

the user input and

edit songs

Database DLL -

Handles all database

functionality.

Name: OpenLPDB.dll

Graphics DLL -

Handles all graphical

functionality.

Name: OpenLPGraphics.dll

OLE DLL – Handles all of the

interfacing with Powerpoint.

Name: OpenLPOLE.dll

uDBCommon

Holds all the

common

database

functions.

uSongDB

Holds all

functions

specific to

songs

uBibleDB

Holds all

functions

specific to

bibles

uGraphics

Holds all

graphics

functions

uOLE

Holds all OLE

functions


Page 10

Definition of data requirements Data will be input into the system using standard text via a GUI with standard widgets. These will be converted by the program into a format that can be read by the database. The output will all come from the database in the form of strings, and will then be processed to produce output to the second display. Mostly VarChar fields will be used. This is a datatype which allows Alpha Numeric text of a specified length to be input. Blob fields be used to store the large bits of data (such as song lyrics). Blob fields can hold up to 4 billion characters so are perfectly suited for this. Description of database and record structure The data for the songs and bibles are stored as a number of tables. The fields in these tables will be organised as follows: Songs DB Table: Authors Field Name Type Length Required? Primary Key? Index? AuthorID AutoNumber 11 bytes Yes Yes No AuthorName VarChar 40 bytes Yes No Yes CopyRightLabel VarChar 255 bytes No No No Table: Songs Field Name Type Length Required? Primary Key? Index? SongID AutoNumber 11 bytes Yes Yes No SongTitle VarChar 50 bytes Yes No Yes Lyrics Blob - Yes No No AuthorID Integer 11 bytes Yes No No Bible DB Table: Text Field Name Type Length Required? Primary Key? Index? Book VarChar 17 bytes Yes Yes No Chapter Integer 8 bytes Yes Yes No Verse Integer 8 bytes Yes Yes No Text Blob - Yes No No Set lists will also be stored as database files (individually). This will allow the entire contents of a song to be stored inside the set list, so that if, for example, a set list was saved in December, but by March one of the songs had been deleted, importing the December list would allow the song words to be imported too. Set list DB Field Name Type Length Required? Primary Key? Index? ItemOrder Integer 8 bytes Yes Yes No ItemName VarChar 100 bytes Yes Yes No ItemType Integer 8 bytes Yes Yes No Extra VarChar 40 bytes No No No Lyrics Blob - No No No Copyright VarChar 255 bytes No No No


Page 11

Identification of appropriate storage media and format The initial system installer will be distributed via the internet and also on CDs. The program will have a standard Windows installer. The reason CDs will be used for distribution rather than floppy disks is the potential size of a system like this. Once sample data is included of public domain songs and the whole bible it will be well in excess of 1.44mb. The data for the system will be stored on the hard disk as a random access database. It will be possible to export all this data to a single file which then can be stored on a CD or tape as backup. Identification of any validation required There will be checks for duplicates before new items are input into the songs/artists tables. The only other validation which will be required is for the Powerpoint side of the system. Jumping to certain slides will have to be validated for range, as will starting from a specific slide. Other than that, due to the complexity of the automatic processing of the system, the validation required is kept to a minimum. User interface design and sample of planned valid output The user interface must be simple to use for a beginner, so the use of a similar layout to other windows applications will be used. The possible views of the main forms, as underlined above, are shown below. The user interface must also be able to size well to different screen resolutions. All of these user interface samples were built using Delphi. They use panelling to ensure portability to different screen sizes. (Please note, the following are all sample outputs and forms, final versions may differ slightly from these.) fmMain – Lyrics section


Page 12

fmMain – Bible section

fmMain – Powerpoint section


Page 13

fmMain – Video section

fmScreen – Main screen display (what will be displayed on the second monitor)


Page 14

fmGphSettings – Background selector

fmGphSettings – Font selector


Page 15

fmGphSettings – Monitor selector

fmGphSettings – Transition selector

Planned valid output can be seen in the fmScreen design above. This form will be the main form of output for the user. The form designs for fmAbout and fmSplash are not relevant to the user interface design, all these need to display is information and do not need to interact with the user.


Page 16

Identification of suitable algorithms for data transformation The main processes in the system are to:

• Retrieve a song by Title and Author Name • Retrieve a bible verse by compiled reference and bible name • Display song or bible words using the appropriate method • Start Powerpoint • Save a Powerpoint presentation to a suitable format and display as a preview

(JPEG pictures most likely, due to their relatively small size, and easy integration in Delphi using the tImage class)

• Close Powerpoint • Show the Powerpoint Window for advanced Powerpoint editing • Hide the Powerpoint Window for beginners • Display MPEG and AVI videos to the screen • Save all items in the order of service list to a specified files • Load all items from a specified file to the order of service list

The way each of these processes will work is outlined below: Retrieve a song by Title and Author Name

1. Connect to the songs database 2. Run a query on the songs and authors table to find the song where the title

equals the specified title, where the author name equals the specified author name and where the author ID matches between the two tables

3. Send this information back to where it was requested from 4. Close the songs database

Retrieve a bible verse by compiled reference and bible name

1. Connect to the bible database by bible name 2. Split the compiled reference into its components 3. Run a query on the bible database to find the text for the verse specified 4. Send this information back to where it was requested from 5. Close the bible database

Display song or bible words using the appropriate method

1. Read in the users preferences from an INI file 2. Cache the current display, in case it is needed for a transition 3. Paint the background specified in the INI file onto a new memory resident

image 4. Paint the words requested with the font from the INI file with shadow or outline,

if requested, and all in whatever colours are specified 5. Check if a transition is specified 6. If not, paint the new image directly to the display 7. If a transition is specified, paint each stage of the transition, using the two

memory resident images for this purpose Start Powerpoint

1. Use OLE to check if Powerpoint is running, if it is acquire the Window, if not, start a new instance


Page 17

2. Check that Powerpoint version is greater than or equal to 2000 (previous versions do not support OLE correctly)

3. If it is, save the reference to this window, if not, close Powerpoint and send the module that requested it a failed response.

4. If Powerpoint is not present send a failed response. Save a Powerpoint presentation to a suitable format and display as a preview

1. Open the Powerpoint presentation using OLE 2. Save it as a JPEG file 3. Ensure the output window is empty 4. Load each JPEG file into the selected output window using the tImage

component Close Powerpoint

1. Try to close Powerpoint and unassign the memory assigned to it 2. If this fails, exit without making a fuss

Show the Powerpoint Window for advanced Powerpoint editing

1. Use the SHOWWINDOW API call to show the Powerpoint Window with argument SW_SHOW

Hide the Powerpoint Window for beginners

1. Use the SHOWWINDOW API call to hide the Powerpoint Window with argument SW_HIDE

Display MPEG and AVI videos to the screen

1. Use the tMediaPlayer component to access the Windows Multimedia drivers and play the video to the screen using the display property

2. Update the trackbar to show progress Save all items in the order of service list to a specified files

1. Check if file exists, if it does, ask the user if they wish to overwrite it 2. Overwrite the file with the saving template 3. Open the file as a database 4. Check if each item is a song 5. If it is, retrieve the lyrics from the main song database 6. The item type is generated by the image index property of the item 7. Write each item from the Order of Service list to the file, including, if it is a song,

the lyrics 8. Close the database file

Load all items from a specified file to the order of service list

1. Open the file as a database 2. Check if each item is a song 3. If it is, check if this song is in the main song database, if not, load it into it 4. Check if each item is a Bible verse, if there are no Bibles present on the system

then alert the user, and don’t insert this item into the Order of Service list


Page 18

5. Check if each item is a Powerpoint presentation, if it is not present on the system, alert the user, and don’t insert this item into the Order of Service list

6. Check if each item is a Video, if it is not present on the system, alert the user, and don’t insert this item into the Order of Service list

Data capture and entry As this is a system in which a lot of electronic copies of the data already exist, the data capture is extremely simplified. Existing on my computer is a Word Document with 1000 songs in it, each on a separate page. To put this into the database I simply wrote a parser for the file. In order to run the parser on the file I needed to save the Word Document as a standard Text file. Each song was formatted as follows: Author Copyright Info TITLE Lyrics Lyrics Lyrics with a blank line in between each song. The parser took this information and put each author into the authors database, and each song into the songs database with the corresponding authored, ensuring that no author was duplicated. From the internet I downloaded a copy of the Bible text. For this, again I wrote a parser to take each verse and enter it into the database. As it was a TSV (Tab separated values) file, this was relatively simple. Each line was formatted as follows: Book identifier<tab>Chapter<tab>Verse<tab>Words The parser took this information, delimited it by tabs, and then entered each part into the database. Data validation Most of the validation is carried out by the database itself. For example, all fields are type checking, so that the data entered into it will be of the correct format. The only validation required will be to ensure that quote marks are not attempted to be entered into the database without checking for them, as this would lead to premature termination of a string. Instead DOUBLE QUOTES must be used. For example, if a user entered: Blessed by your name When the sun’s shining down on me When the world’s “all as it should be”


Page 19

It would cause an error in the database. However if the program first replaced this with: Blessed be your name When the sun’s shining down on me When the world’s “”all as it should be”” no error would be caused. Because of this, I will check all the Lyrics about to be inserted into a table for quote marks, and replace them with double quote marks. Security Integrity of data will be ensured using SQLite’s built in fsync() functionality, which checks that each INSERT SQL query is properly completed. The church multimedia co-ordinator indicated to me that he did not feel password security would be necessary for the system. In fact, he insisted that it NOT be put on, due to the possibility of the operating system crashing, in which case it would need to be necessary to restart the system extremely quickly, and passwords would only confuse this process, in addition to slowing it down. However, he did request that there be a function to back up his songs database easily, and restore it easily, in case of a hard disk or system failure. Overall test strategy During the testing phase of the system I will use four main types of testing:

• functional testing, which will check that all my functions and procedures do what they are meant to

• system testing, which will ensure that the overall system is working as specified • recovery testing, which will test what happens if the computer is reset during

running, and also test how well the backup system works • acceptance testing, which will ensure that the user is happy with the final

product Functional/black-box testing – During this phase of testing I will run each main procedure and function with various types of input and see whether the expected output is produced. System testing – During this phase of testing I will run the whole program and do what I expect to be the most common tasks that would be done by a real user. I will see if what I expect to happen, happens. Recovery testing – During this phase of testing I will run the program and randomly reset the computer in between. I will see what effect this has when I restart the program if any. I will attempt to reset during writes, and reads. I will also test the backup system and see if it performs as specified. Acceptance testing – During this final phase of testing I will give the user a release candidate and allow them to use it in a real situation, while running the old system in case the new one breaks down. This will assure me that my user is happy with the final product.

design - free open source church worship presentation...

Documents