The Photon Architecture

Why the Photon Programming Model Is Important

It makes windowing programming and windowing behavior more consistent by depicting the behavior of processes and events important to programmers. By contrast, the Microsoft Windows programming model is less coherent. A process (each individual window) doesn't normally receive an event unless it's the active process (the one closest to the user). If you want other processes (other windows in the same application) to respond to events, Windows requires you to find a way to do this. The active window may collect an event and then pass it on to other windows, like prospectors panning for gold. If the first prospector (the process) finds a gold nugget, he or she keeps it; if it is fool's gold, he or she throws it back into the stream for the next prospector. Implemented in a process-by-proces s manner in Windows, this type of solution is natural behavior in Photon.

Event control like this is important for a handwriting-recognition program in a PDA or for data-acquisition and process-control applications. For example, you might want a user-initiated event to change the visual image of an instrument control and also have that event let a process-control driver send a signal to an electronic control.

Programmer's Notes

Programming for Photon centers on initially positioning a region, telling the Photon microkernel which types of events are relevant to the region and then dispatching based on the event received. Photon consists of a single X Window System-like API. The API may consist of four separate libraries: graphics; a Photon Window Manager, which is optional; AppBuilder, a visual C-code application development environment; and widget, the user-interface component. The windows manager can automatically control windows and regions created by applications. The wi ndow manager creates icons, and resizes and repositions process regions within event space.

---

Event space: conceptually where all Photon processes and events reside.

illustration_link (64 Kbytes)

Photon is not just another GUI. It is an event-driven system that waits for the user (or sometimes the system) to send a signal; it then redirects the signal to the appropriate process or processes. Photon developers control whether and how various processes respond to the same events. This control is a characteristic of Photon's architecture rather than being something that a developer must add. The Photon microkernel is also compact: about 24 KB of code plus 40 KB of data.

Process Regions

Application processes own regions that enable applications and device drivers to interact with the Photon event space. Applications and drivers differ only in how they respond to and generate events.

Every region has two properties that determine how it responds to events--sensitivity and opacity. If a region is sensitive to an event, the process that owns the region collects a copy of the event. If it's insensitive, the event is ignored. If the region is opaque, the event is clipped, or possibly changed in some manner (see the "Clipped Regions" icon). If transparent, the event passes through the region unaltered.

A region may be both sensitive and opaque, which allows the owning process to act as a filter. Such a process might collect a connected sequence of pen events: After a touch pen writes a word, the process performs handwriting recognition and then generates the equivalent keyboard events in the event space. Apple's Newton does handwriting recognition, but not with such a coherent model of operation.

Events

User-generated events begin at the user interface and travel to the root process. Events generated by data a cquisition devices and other outside sources begin at the process collecting them and travel to the user or to another process. Events may intersect with any process region.

Clipped Regions

As an event travels through coordinate space, a part of it may be clipped off by the opaque region of another process. The unclipped part continues through the event space. This means the region modified the event in some way. For example, a draw event travels through the event space and arrives at a graphics driver. Only the unclipped portion of the event will be drawn on screen.

Event Initiators

-- Keystrokes
-- Mouse or touchscreen button input
-- Mouse or touchscreen pointer movements
-- Boundary crossings (moving a window to the foreground or background)
-- Drag operations (cut, copy, and paste)
-- Drawing functions

User Interface

The programs that run immediately in front of the user.

Device Drivers

These are the enablers of events in Photon. Mouse and keyboard drivers are input drivers; the graphics driver is an output driver. Device drivers run as user programs, which makes it possible to dynamically load drivers when you require them. You can have multiple drivers running in the same coordinate space. For example, multiple graphics drivers can display different portions of the visual output on different screens or even screens on other computers on a network. With Photon, you could drag an application from the screen of a desktop computer to the screen of a PDA.