Order, order!We now have a speech bubble, but where's our text gone to? If you added the statement to draw the irregular shape to the end of your sketch, Processing would have drawn the speech bubble over your text. Your text is still there just underneath the speech bubble, obviously this is not the desired effect. So we are going to reorder things in our sketch, with some simple cut and paste commands. Cut the three statements that relate to rendering text to the Display Window textAlign(), textSize() and text() to the end of the sketch so that they are run after the speech bubble is drawn. If you were to run the sketch at this point your text will still appear to be missing, but in fact is still there it's just that because it's been drawn after the speech bubble it's also been effected by the fill() function issued to change the speech bubble's fill to white. White text on a white background isn't very legible so we'll change the text to another color, I'm going to make my text the same color as the speech bubble outline by adding the following statement before the text is drawn and after the speech bubble is rendered:
Finishing the sketch
To add the final touches to the Hello World 1.2 Program we're going to get Processing to display an image for the sketches background instead of the black background. This exercise will also be our first introduction to the programming paradigm known as Object Oriented Programming and the concept of data typing.
The first thing we need to do is set our sketch up to accept external data in the form of an image. With the PDE still open, via your computer's operating system open a file browser and locate the file named “smileBkg.png”. From your file browser click and drag the image file into the sketch you are currently working on in the PDE.
When you have dropped the file to the sketch Processing, will confirm this in the debugging area by printing the phrase “One file added to the sketch”. If you get this message you are ready to start using the image in your sketch.
The simplest way to use external data, such as an image, in your Processing sketch is to ensure that the data exists in a folder called “data”, which must be a subdirectory of the location where your sketch is saved. For example, we set up Processing to store all sketches in folder called “Sketchbook”, stored within this folder will be the sketches we create with the PDE. I've called my Hello World 1.2 Program “smile” so within the Sketchbook folder is another folder called “smile” and within the smile folder is the file smile.pde (which is my Hello World sketch) and another folder called “data”. When we dropped the image into the PDE Processing automatically created the data folder, and placed a copy of the smileBkg.png file in it. If you would like to view the contents of this folder you can access it from the PDE by clicking:
Sketch → Show Sketch FolderOr simply navigating to the folder with your operating system's file browser. When transporting your Processing sketches from one computer to another you must always retain this directory structure of having your data folder as a subdirectory of the location where your processing sketch resides, which should always have the extension .pde.
A programming paradigm is a fundamental style of programming, the term is often confused with programming methodology which is a style of addressing a problem within a program. But perhaps a better way to understand what a programming paradigm is, would be to look at some examples of it. Many modern day software languages offer at least two fundamental programming paradigms, most commonly amongst these two choices are the Objected Oriented Programming Model and the Procedural Programming Model (Procedural programming is also sometimes referred to as imperative programming). Like the name implies imperative programming is a programing paradigm that is used to determine a set of commands and/or steps a computer program must take in order to reach a desired state. It's worth knowing that the Object oriented programming model is often contrasted to the procedural programming model because of the fundamental differences (which we are about to discuss) that separate these programming paradigms. Procedural Programming can be summarized as a style of programming where the program is tailored to suite the data as opposed to Object Oriented Programming which is more akin to a style of programming where the data is tailored to suite the program. So what exactly does that mean? As mentioned earlier, programs are made up of statements and one of the things statements are made up of, is commands. As you might recall a command in programming, much like in a natural language, is used to communicate a directive. In this way procedural programming is a list of statements telling a computer what to do. At this point you could be thinking “Isn't that the purpose of all programming i.e. telling a computer what to do, so how then does procedural programming differ from any other programming paradigms?” In one way or another we use programming to represent data, whatever that data may be the amount of tea compared to the amount of coffee consumed over the past ten years world wide, determining the choices a character has in a game then choosing to act on those choices or something as simple as representing a set of alpha numeric characters on a screen that spells your name. Whatever way you look at it creating a program requires data. In procedural programming we use the tools provided to us by the language we are programming in to break down that data into smaller data types that the language predetermines for us and then use those representations to create a program that ultimately represents the larger original data set programmatically. This can be contrasted to object oriented programming where we use the tools provided to us by the language we are programming in to create our own data types for which we determine their meanings and use these new data types to create a program that ultimately represents our original data set. Either way you look at it the results of both procedural and object oriented programming can produce software that is modular in design, meaning that components of the data that can be represented with either one of these paradigms can be dynamic or changing, or even completely non-existent. Designing software that does not have to be rewritten each time the data that it represents changes or is removed from the main program entirely, is a challenge regardless of which programming paradigm you might use and it is this key feature of software design that determines how modular the main program is. Object Oriented Programming since it's earliest inceptions in the late 1950's programming language LISP has consistently seen various implementations on the concept of modularity amongst other features such as encapsulation (which we will discuss in more detail later), contributing to it's modern day popularity. As software development needs have become more demanding and larger data structures are required for abstractions, Object Oriented Programming due to it's inherent ability to represent complex data structures, modularly has grown in popularity to meet the needs of software developers creating these sophisticated programs. That is however not to say that procedural programming lacks sophistication. To summarize programming paradigms in a utilitarian sense, people tend to address problems in different ways, programming paradigms accommodate for these shifts in thought and conceptualization.