All the Simple Graphics Library code lives in the sgl.hpp header file. You must #include the sgl.hpp header in exactly one C++ source file in your SGL-based project. For single source file projects, simply include the line

 #include <GL/sgl.hpp>

at the top of your source with the rest of the #include directives. This sgl.hpp file itself #includes the file sgl.h.

For projects that consist of multiple source files, every source file that involves SGL code must #include the file sgl.h—with one exception; exactly one source file must instead #include the sgl.hpp header file. These two header files play different roles:

In multiple source file C++ projects, the compiler processes each source file separately and independently producing one machine language object file for each source file. The linker then combines the machine language code from all the object files into a single executable file. Since the sgl.hpp header file contains implementations of all the SGL functions and classes, if more than one source file in a project attempts to #include the sgl.hpp header file, linker will detect the multiple definitions for identical functions and methods and issue an error. That is why programmers must #include the sgl.hpp header file in one and only one source file in a project.

All SGL programs consist of at least one graphical window. The window provides output to the user, typically with graphical images. The window also is capable of receiving user input events from the mouse and keyboard. The application's window is an instance of a class derived from sgl::Window:

 #include <GL/sgl.hpp>

 class MyAppWindow: public sgl::Window {
     /* 
      *  Provide application-specific data and
      *  override virtual functions for handling
      *  events.
      */
 };

The classes and global constants in the SGL are part of the sgl namespace, so the above code could be written instead as

 #include <GL/sgl.hpp>

 using namespace sgl;

 class MyAppWindow: public Window {
     /* . . . */ 
 };

The using namespace sgl; directive exposes everything from the SGL to the client code. Another approach that eliminates the requirement of the sgl:: prefix but does expose all the SGL identifiers is shown here:

 #include <GL/sgl.hpp>

 using sgl::Window;

 class MyAppWindow: public Window {
     /* . . . */
 };

The sgl::Window class is an abstract class because its paint method is a pure virtual function. It is the responsibilty of the paint method to draw the contents of the window. The programmer does not call paint directly; instead, the event manager of the SGL framework code calls a window object's paint method when the window needs to be displayed; for example, when the window first appears or when the user resizes an existing window. A programmer can request explicitly that the framework redraw the window by calling the window's repaint method. The SGL framework reacts to this repaint call by queuing a window repaint event. The event manager in turn processes the repaint event by calling the affected window object's paint method.

The Window class has other methods that the SGL framework calls to handle specific events:

Each of these input events has empty concrete implementations in the Window class. This means if a derived class does not override one of these methods, an instance of the derived class will effectively ignore any events of that type sent by the framework.

Historical note: Initial implementations of the SGL were more Java-like, using MouseEvent and KeyEvent objects. These early implementations, however, simply took the parameters passed by GLUT (such as the x, y, and button parameters for a mouse event), wrapped them within an object, and then forwarded that object to the appropriate window method. Since the window method ultimately had to extract the parameters from the object it received in order to use them, the overhead of using event objects was abandoned for the simpler approach of passing the individual primitive parameters.