events are one of C++'s weaker points as a language. basically there is no easy way to handle events in C??, and any C++ code syntax that is used to implement an event system just ends up being a big mess, regardless of how well it is designed.
for the same reason there aren’t really any standard names for the functions that are used to handle events. i guess keyPressed() could be named a ‘callback’, but that’s a pretty generic term that doesn’t mean anything in particular. it could also be named an ‘event handler function’.
ofEvents are a way of firing user-defined events. if i have a process that takes many frames to complete, like the fade in/fade out example you suggested, i can fire an event at the end of this process. other objects can listen for this event, and when they receive it they know that they should do something. one simple alternative is for each other object to maintain its on timer internally which is updated every frame, but this would mean lots of duplicated code and introduces many opportunities for bugs to appear. imagine a case when you have 100 other objects listening: having 100 timers running individually, in addition to the timer in charge of the fade effect, is clearly less reliable than having just the one timer (the fade effect) and an event that is fired.
openFrameworks uses Poco Events because Poco does a lot of the back-end of events. to a certain extent one of the design philosophies behind openFrameworks is to re-use existing code wherever possible: we could have created our own event handling loop but then we’d be responsible for tracking down and fixing any bugs in it, while Poco already provides a mature, bug-free event handling system.
for a brief overview of what a Listener might be, have a look at the Observer/Observable design pattern: http://en.wikipedia.org/wiki/Observer-pattern . the basic concept is that a ‘listener’ labels an object as being actively interested in a particular event. my app might have hundreds of events firing, but if my class is only a ‘listener’ for one particular event it will ignore all the other invents. (classes can be listeners for multiple events as well, of course.)
events and listeners are commonly used when handling GUI systems, but in general they are a design methodology that allows for decoupling parts of your application. http://en.wikipedia.org/wiki/Decoupling#Software-development suppose i have an app that uses a Kinect to detect a hand-wave gesture. by using events i can have the same hand-wave gesture detection code working in 3 different applications, one to trigger a sound, one to trigger a visual response like an animation, and one to trigger some data to be uploaded to a web site, without having to modify the hand-wave gesture detection code. if i was not using events i would need to modify the hand-wave gesture detection code each time to call the right method on the right class in each application.
the reason why keyPressed and keyReleased run as they are probably has a lot to do with the fact that this is how GLUT handles keyboard events, and in its early version openFrameworks was very much tied to GLUT. there are other ways of handling a keyboard input system, depending on exactly what you want to achieve. for example, one way is to have a buffer (a fixed location in memory) that is appended to every time a key is pressed. another way is to have an array of booleans, one for each key on the keyboard, each of which is either true or false depending on whether the key is currently pressed or not (this is how you can detect multiple simultaneous key inputs). this last way is actually how a keyboard works at the hardware level: it’s just an array of switches. there is a lot of fancy programming between the keyboard hardware and your application to allow a function to be called when a key is pressed, and another function to be called when the key is released – it’s generally the case, although not always, that this is the most convenient way of handling keyboard input.
hope this helps!