1Fall 2005 6.831 UI Design and Implementation 1 2Fall 2005 6.831 UI Design and Implementation 2 Suggested by Daniel Swanton3Fall 2005 6.831 UI Design and Implementation 3 Suggested by Robert Kwok4Fall 2005 6.831 UI Design and Implementation 4 InputToday’s lecture continues our look into the mechanics of implementing user interfaces, by looking at input in more detail.Our goal for these implementation lectures is not to teach any one particular GUI system or toolkit, but to give a survey of the issues involved in GUI programming and the range of solutions adopted by various systems. Presumably you’ve already encountered at least one GUI toolkit, probably Java Swing. These lectures should give you a sense for what’s common and what’s unusual in the toolkit you already know, and what you might expect to find when you pick up another GUI toolkit.5Fall 2005 6.831 UI Design and Implementation 5 !" Console I/O uses blocking procedure callsprint (Enter name: )name = readLine();print (Enter phone number: )name = readLine(); System controls the dialogue GUI input uses event handling instead User has much more control over the dialogue User can click on almost anythingVirtually all GUI toolkits use event handling for input. Why? Recall, when you first learned to program, you probably wrote user interfaces that printed a prompt and then waited for the user to enter a response. After the user gave their answer, you produced another prompt and waited for another response. Command-line interfaces (e.g. the Unix shell) and menu-driven interfaces (e.g., Pine) have interfaces that behave this way. In this user interface style, the system has complete control over the dialogue – the order in which inputs and outputs will occur.Interactive graphical user interfaces can’t be written this way – at least, not if they care about giving the user control and freedom. One of the biggest advantages of GUIs is that a user can click anywhere on the window, invoking any command that’s available at the moment, interacting with any view that’s visible. In a GUI, the balance of power in the interaction swings strongly over to the user’s side.As a result, GUI programs can’t be written in a synchronous, prompt-response style. A component can’t simply take over the entire input channel to wait for the user to interact with it, because the user’s next input may be directed to some other component on the screen instead. So GUI programs are designed to handle input asynchronously, receiving it as events.6Fall 2005 6.831 UI Design and Implementation 6# ! Raw input events Mouse moved Mouse button pressed or released Key pressed or released Translated input events Mouse click or double-click Mouse entered or exited component Keyboard focus gained or lost (loss of focus is sometimes called blur ) Character typedThere are two major categories of input events: raw and translated.A raw event comes right from the device driver. Mouse movements, mouse button down and up, and keyboard key down and up are the raw events seen in almost every capable GUI system. A toolkit that does not provide separate events for down and up is poorly designed, and makes it difficult or impossible to implement input effects like drag-and-drop or video game controls.For many GUI components, the raw events are too low-level, and must be translated into higher-level events. For example, a mouse button press and release is translated into a mouse click event (assuming the mouse didn’t move much between press and release – if it did, these events would be translated into a drag rather than a click). Key down and up events are translated into character typed events, which take modifiers into account to produce an ASCII character rather than a keyboard key. If you hold a key down, multiple character typed events may be generated by an autorepeatmechanism. Mouse movements and clicks also translate into keyboard focus changes. When a mouse movement causes the mouse to enter or leave a component’s bounding box, entry and exit events are generated, so that the component can give feedback – e.g., visually highlighting a button, or changing the mouse cursor to a text I-bar or a pointing finger.7Fall 2005 6.831 UI Design and Implementation 7$ ! Mouse position (X,Y) Mouse button state Modifier key state (Ctrl, Shift, Alt, Meta) Timestamp Why is timestamp important?Input events have some or all of these properties. On most systems, all events include the modifier key state, since some mouse gestures are modified by Shift, Control, and Alt. Some systems include the mouse position and button state on all events; some put it only on mouse-related events.The timestamp indicates when the input was received, so that the system can time features like autorepeat and double-clicking. It is essential that the timestamp be a property of the event, rather than just read from the clock when the event is handled. Events are stored in a queue, and an event may languish in the queue for an uncertain interval until the application actually handles it.8Fall 2005 6.831 UI Design and Implementation 8 !% Events are stored in a queue User input tends to be bursty Queue saves application from hard real time constraints (i.e., having to finish handling each event before next one might occur) Mouse moves are coalesced into a single event in queue If application cant keep up, then sketched lines have very few pointsUser input tends to be bursty – many seconds may go by while the user is thinking, followed by a flurry of events. The event queue provides a buffer between the user and the application, so that the application doesn’t have to keep up with each event in a burst. Recall that perceptual fusion means that the system has 100 milliseconds in which to respond.Edge events (button down and up events) are all kept in the queue unchanged. But multiple events that describe a
View Full Document
Unlocking...