Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
16 Cards in this Set
- Front
- Back
|
how to program an interactive application without events |
a monolithic loop: -check keyboard -check mouse -check touch panel -check timers for animation -parse input -do actions -program processing etc this takes up alot of cpu power and time and stuff |
|
|
how to program an interactive application with events |
program sets up connections -provide fn for when keyboard is pressed -provide fn for when mouse is pressed -provide fn for when specific on screen button is pressed -provide fn on a timer for animations interactive compnent goes to sleep. if any of the above interactions happen, the program wakes up and those registered functions are called |
|
|
central even loop that runs our program |
hidden inside your GUI library, gets started when you make a GUI application while(not time to quit) { get next event E (waits) dispatch event E(calls assoc. fn) } |
|
|
event queues |
input events are typically placed in a queue ensures that events are processed in order main loop removes them from the queue |
|
|
event system benefits |
distributed and isolated coding standardized events - develop a API and re-use it less worrying about core loops and other simultaneous tasks live changes - you can add new event listeners in real time with code without thinking of other parts of the program |
|
|
types of events |
device events -mouse button 1 down, wheel turned GUI events - enter/leave screen or widget, scroll, repaint window events -resize window, close window programmer-defined events -message arrived, calculation finished events available are heavily dependant on the OS, programming language, libraries etc |
|
|
event information |
nature of event info depends on event type, toolkit windowing system common info in an event record - event type - event time - state of modifier keys (alt, shift, ctrl etc) event specific info - mouse location, button state - key pressed/released - window/compnent affected |
|
|
hierarchy and events |
if a button is pressed, does the button get the event, or the encapsulating window, or both |
|
|
containment hierarchy |
components can be contained within other components used to determine where to send an event |
|
|
bottom-up dispatch (bubbling) |
floats up the lowest in the hierarchy gets it first widget get a lot of power, and get "first crack" at it to act first or to cancel an event |
|
|
top down dispatch (capturing) |
the highest in hierarchy gets it first, and it then works its way down can globally manage your events - a frame can filter which events hits its children |
|
|
positional dispatch |
the item pointed to by the positioning device (mouse, touch, etc) gets the event |
|
|
focused dispatch |
the item with "focus gets the event |
|
|
focus |
a way of indicating the current active widgets usually shown visually can be modified programmitically |
|
|
life cycle of a mouse click |
SYSTEM SPACE (OUTSIDE PROGRAM) user: clicks mouse button OS: mouse button was clicked as screen position X,Y Windowing system: mouse button even in window Z, at relative window coordinates X1,Y1 PROGRAM SPACE, YOU DO THIS UI toolkit: widget button1 was clicked. check for callback or notification request for this widget, and invoke appropriate associated code. Application: some procedure or method carries out action that we want attrached to that button |
|
|
events: lessons |
events are just simple loops and queues its a programming model that helps with divide and conquor - isolates each event and controller's actions to make programming easier there are various dispatch styles |
