Model View Controller and Event Driven UI

From CS1635 Spring 2014
Jump to: navigation, search

Contents

Slides

slides

Readings

Matt Landram 2:47:01 1/21/2014

Today's reading provided a good overview of the importance of usability when designing a product. The final example, in my opinion, did the best job, by asking how to combine all of the features listed into one item. The resulting product was a convoluted machine with many switches and features that would be easily to confuse as a consumer. The designer even had a switch on the product that he didn't know the purpose of. The example of the car speaker adjustment was also effective. When designing a product or feature you have to keep in mind that the user won't have the inherent knowledge of the product that you have, thus it has to be intuitive, like up moves the sound forward and down moves it to the back. The trade of for functionality is appearance, like the doors in the hotel lobby in Boston. They have an elegant aesthetic by hiding the hinges, but if you push the wrong side of the door it won't budge. This is the other major point the author brings up. While your product has to look appealing to the user, it can't compromise the usability.

Sara Provost 19:43:17 1/21/2014

From this reading I learned that graphical user interfaces are generally built on top of a windowing system, which is a set of software services that allows programs to create and organize windows as well as to implement interactive fragments in those windows. Modern windowing systems view the entire screen as a work area and the user has control over this work area. There are also variations on the windowing system such as X Windows, which was designed so that the user and the application software do not need to be on the same machine, NeWS which fixes some of the issues of X Windows such as the fact that all user interactions must make a round trip over the network, and the Java approach, which downloads interactive applets into the server. This reading also taught me that there are a variety of events that the user interface must be able to handle such as mouse button events, which are things such as double clicking, mouse movements, and mouse-enter and mouse-exit events, which occur when the mouse enters or leaves a window. They must also be able to handle keyboard events, such as the use of special “hot” key button presses and the function keys. A user interface must also respond to windowing events, which are related to the managing of the window itself. An example of this type of event is redrawing, which occurs when the window must update. Finally, this reading taught me that windowing systems run off of a main event queue, which determines how events are distributed to objects, and determines the importance of the events that are being added into the queue. In conclusion, I found this reading to be very helpful with the understanding of how user interfaces work, beginning with the software that they are built on top of and ending with the different types of events and how they are handled by the window managing software.

Guoyang Huang (Guh6) 22:30:31 1/21/2014

In chapter 4 of The Basics of Event Handling, it talked about all of the necessary information about the history of even handling for Mac and Windows. First, I learned about direct manipulation and how user is in control rather than the program. Second, the events are related in a windowing system and windows manager that the interactive objects are called widgets or controls. Third, windows can recursively contain windows. These helped me understand the basic definition of events. The chapter also talked about the functions of events on servers and different protocols. For the server, it does not need to know the specific of a window. I learned that PostScript is used to reduce network traffic. The event type is another distinction about events and the most important ones are user generated events such as mouse click. The multithreading was also discussed for the mouse events of how xPaint had a null queue event to take the processing time away from other processes. The redraw is when user action requires a window to be redrawn and not when the application wants to redraw. The chapter also focused on how the basic implementation worked for MacApp and Windows. There was bottom-first event dispatch model and top-down. The difference between them is that top-down allow for some portion of the code to be modified by programmers whereas bottom-first allows window system to handle all of the arbitrary actions between windows. The GIGO is another way to implement events where there exists a table with pointers of integer to event procedures. It also discussed delegation which is each window handles the events that it understands and delegates all other events to some other window procedure. For object oriented programming, the events are built on top of larger layer of windowing class which is abstract. One problem of such is that sometimes it creates new classes rather than only modifying it slightly. Lastly, objects can communicate with one another through callback, parent-notification, and connections. I learned that Windows and MacApp both use parent-notification.

Longhao Li 14:36:05 1/22/2014

At the beginning of the article, it tells us a basic description of the development of the event handling system, from simple to complex. Then, the author starts to talk about the windowing system. Most of them are based o the hierarchy of nested rectangles because it is simple. Window contains widgets to help the user, and the window cares recursively contain other windows. With the development of the window system, window management is becoming more important since user is using the windowing system as a work area. Then, the author talked about some different windowing system like X windows, which support different machine operation (user and application can be on different machine). Using X as fundamental, there are more system came up with more support than X like NeWS and Java. The author talked about window events, which mainly focused on user input. Mouse button events are one of the most important events for the operation. Using mouse button user can achieve a lot of job since the mouse cursor is moving on the window. One click and double click did most jobs on the operation. Also there are keyboard inputs. Using different combinations of keys, user can achieve a lot of action easily like the short cuts in Mac. With all of these events working on the system, there are strategies to make them working correctly, like the use of event queues. Then the author talked about event dispatching and also the event handling. The handlings are different in different system. We have Macintosh-style and also windowProc-based (Microsoft) etc. In general, I think the article gave me a preliminary understanding about why we can operate computer like this and how these windowing system works to make it happened. Great article.

Ryan Ulanowicz 17:57:24 1/22/2014

Modern computing systems are not directly manipulated like systems that can only be controlled by a text terminal. They are event driven, through Windowing systems that provide programmers with access to tools to build and program GUI programs for a modern system. Events are the communications between the various inputs (mouse, keyboard, etc.) and the underlying code that runs. The windowing system has two parts, the software to allow window creation and organization, along with something allows the placement and sizing of windows, called the window manager. Application are best viewed as a tree, where the window is the root with the other components being divided up into the branches, such as buttons, scroll bars, and objects. These objects are generally built into the windowing system, as described before, and are called Widgets. Systems such as X extract enough functionality so that the widgets and first part of the windowing system can be done by another program. Systems allowed users to have a windowed system in front of them while the computation was done by another computer on the network. These complicated issues by having to allow for latency. Eventually more and more of the information needed was sent over the network before the user needed it, like Java, so that latency was less of an issue. Since we said that programs are event driven, we have to understand how these events work. One of the largest in a modern windowing system is mouse button events. Depending on the system, an event is fired on mouse down, the system marks where you are, figures out what part of the active application you are interacting with, or which other application you wish to use, and on mouse up fires that event. This gives the program, or the system(on exit or resize) the opportunity to run the required subroutines. Modifier keys and double-clicking complicated this process but allowed for more events to be fired at anytime. Polling was initially how programs took care of things that required holding down the mouse button, such as painting on screen. However this doesn’t work, because it eats up every CPU cycles that it can, while not needing that much information. Eventually windowing systems moved to a mouse motion system, that alerted the program of a mouse move on a given interval. This allowed other programs to run in a multiprogram system, while still being able to draw on screen. Along with mouse-enter and mouse-exit on window events, CPU usage because of mice greatly decreased. Keyboards are similar but different, they can thought of as a large array of keys that can be pressed, however they are not standard. Because of this, and modifier keys, windowing systems had to do more to handle keyboard input. With replacement of keys with ASCII or Unicode characters, the keyboard was able to have a standard interface, no matter the language. Windowing events are events that happen on screen that the windowing system has to deal with. One example is redrawing, this is generally done when an application that was previously hidden by another application comes to the forefront. Now we have to deal with the main loop of the program, this is what is running while the application is open. It is running because in an event driven environment the application must always be ready for any number of button presses or key combinations. In this way the main functionality of the program is responding to events that are passed along to it from the windowing system. These events are placed in a queue, one per process, that is fed into the application to be done one at a time. In an object oriented environment a lot of the standard code is already written, and must only be rewritten if special functionality. This type of overloading and polymorphism is a strength of event driven application development with object oriented languages. Now we have to understand how events are dispatched within the application. Generally they are done from a bottom up approach, starting with the lowest level in the application tree. In this way things that are the highest up in the users view are the ones that take in the inputs. Now that we know how applications deal with events, we have to understand how objects communicate with each other. This is generally done through pseudo-events. These are events that aren’t done by the user or the windowing system, but instead by the object to send information to another object in the system.

MJ (Mary Letera) 18:42:25 1/22/2014

Today’s reading focused on windows interfaces. The author discusses several implementations of these. GUIs are typically organized in trees of windows. Event handling can be complicated in this situation, and events can be forwarded from one window to another. How the various components of an application work together is essential to being able to program the parts. The author points out that reading the code of a GUI application is quite different from that of a traditional desktop application, as the main() function does very little in a GUI application. I’ve found this to be true in my own experiences, and they can be trickier to debug for this reason.

Guoyang Huang (Guh6) 19:47:15 1/22/2014

In chapter 4 of The Basics of Event Handling, it talked about all of the necessary information about the history of even handling for Mac and Windows. First, I learned about direct manipulation and how user is in control rather than the program. Second, the events are related in a windowing system and windows manager that the interactive objects are called widgets or controls. Third, windows can recursively contain windows. These helped me understand the basic definition of events. The chapter also talked about the functions of events on servers and different protocols. For the server, it does not need to know the specific of a window. I learned that PostScript is used to reduce network traffic. The event type is another distinction about events and the most important ones are user generated events such as mouse click. The multithreading was also discussed for the mouse events of how xPaint had a null queue event to take the processing time away from other processes. The redraw is when user action requires a window to be redrawn and not when the application wants to redraw. The chapter also focused on how the basic implementation worked for MacApp and Windows. There was bottom-first event dispatch model and top-down. The difference between them is that top-down allow for some portion of the code to be modified by programmers whereas bottom-first allows window system to handle all of the arbitrary actions between windows. The GIGO is another way to implement events where there exists a table with pointers of integer to event procedures. It also discussed delegation which is each window handles the events that it understands and delegates all other events to some other window procedure. For object oriented programming, the events are built on top of larger layer of windowing class which is abstract. One problem of such is that sometimes it creates new classes rather than only modifying it slightly. Lastly, objects can communicate with one another through callback, parent-notification, and connections. I learned that Windows and MacApp both use parent-notification.  

Zach Liss 20:11:23 1/22/2014

Today's reading was about event handling. It began by giving an overview of Windowing Systems including X, NeXTSTEP and eventually java. It talked about how it is almost universal in GUIs to be able to decompose objects into a tree. I learned that the most important input events are those generated by the user. This makes sense because the user is what drives the application forward. Another type of event is the windowing event. These are fired when the actual window needs to be managed. There is also the entire issue of dispatching the events. This reading has made me realize how complicated a process it is for an application to listen for a event and the dispatch it.

David Grayson 20:43:19 1/22/2014

Basics of Event Handling begins by discussing direct manipulation, which is when users interact with and change objects on the screen. Event handling is the underlying process for the direct manipulation model; using this model gives the user control, instead of the software. The chapter then discusses windowing, or the partitioning of screen into small rectangles containing individual interfaces that combine to create the interface of an entire piece of software (the root window being the top level window. This is not necessarily how all windows work, however, as some windows allow other applications access to part of the window space. X Windows and NeWS are types of windowing that allows the user to be on one machine and interact with the window of an application on a different machine. The window manager allows users application-independent control over windows, such as resizing. Some types of events are input events (mouse events, modifiers, double clicking, function buttons, mouse movement events, mouse enter and mouse exit events, keyboard events), windowing events, and redrawing events. The chapter then discusses how events are handled, most of which seems very complicated. One way events are handled that is of particular interest is the object-oriented model, which provides application methods for handling events such as starting or quitting. Two methods for event dispatch are discussed: bottom-down and top-up. Bottom-down dispatch is good because “objects that control windows only need to consider their own events” and the window management system handles inter-window events (111). Top-most dispatch is when the highest level window with focus handles all events. It seems that there are many systems for handling events, typically specific to the operating system (and architecture) of a given computer. However, none appear to be the absolute best method and it seems to be the case that much of event handling, dispatch, and programming is/should be application/use specific.

Zhanjie Zhang 20:50:05 1/22/2014

This chapter discusses the topic of event handling. To understand this topic, we are given a overview of some common user interfaces that has been used. The book discusses the topic of events which is helpful in getting the reader acquainted with the model. By using a windowing system, we can decompose the interactive process into an interactor tree. There is however several variations on the windowing system model that should be studied which may be of use to someone that is studying user interface design. The X windows, NeWS system, and Java. Each has their own strength and weakness that depends on the system that is being used. The chapter then moves on to input events from the user. This is important in understanding how users interact with their devices and how the implementation of the system aids in that task. Some systems implement activities different- for example, Microsoft and Macintosh. These implementations caused some problems while solved some, X has trouble with double clicking since it was used over a network. The ways mouse are used to interact with the windows differ from the way keyboard events occur. Unlike the mouse, the keyboard is thought as an array of buttons. For keyboards, we must be aware of the fact that different layouts of keyboards exits due to the differing languages of countries. Also, depending on the operating systems, different key presses may mean different things to the system, something we must be aware of. Another aspect we must be aware is the redrawing of windows, during resizing, are often changed and must be analyzed. For windows, we must be aware of how windowing works. It’s important to be aware of event queues, input events, and quitting applications. The chapter continues to discuss dispatching events using Canvas/GIGO. We may also use a top-down algorithm. There are many different ways to handle events, through OS such as Windows and OSX which is important to be aware of. For students in user interface design class, it is important to understand how objects cooperate to make up an interactive application. This chapter provided important background for interactive software.

Max 21:13:27 1/22/2014

This reading covered event handling. The first section of the text covered windowing. Windowing systems break the screen system into independent fragments for user interface functionality. The fragments are composed in a tree structure to make an application which allocates resources for interactive use. The next topic covered events. Event types include input events, which are generated by the user and take into account mouse position, etc. There are also mouse button events, which are click events, modifiers such as keys and double clicking. Also included are function events, mouse movement events (which are important for handwriting recognition), mouse enter/exit events, and keyboard events. A visual display must undergo redrawing in order to be updated when changes occur. Dispatching events are then covered in the reading and defining application code to dispatch events. This includes recognizing events and then performing the proper event handling procedures. Last, the idea of communication between Objects is discussed. This is how other react to certain events happening to different objects. Users being in control and there being no uniform flow control through a program defines interactive software architectures.

Brian Kelly 21:27:02 1/22/2014

While this reading felt like a bit of a history lesson at times, there were many valuable lessons to be learned about event driven computing. Though it make sense that there are so many things to coordinate when it comes to graphical user interfaces, I think that we often take these things for granted. Even though most graphical systems used window-based interfaces, it was a bit surprising to find that they often found different ways of tackling some of the event-driven issues they faced. They accepted inputs from things like mouse clicks and key strokes and figure out how to perform the actions that the user expected from them. They overcame these challenges by using things like modifiers, double-clicking, redrawing, and event queues.

Brett Lilley 22:03:54 1/22/2014

"Basics of Event Handling" was an introduction to how software handles user interactions with the interface, which are called events. Starting off introducing the concept of interfaces containing windows, and how windows are conventionally situated within a window tree, the information behind windows is introduced to the reader. Windows are the backbone of modern user interactions with the interface, as windows contain the components that are selected/fired causing events. Events are the main method of communication between the user and the interface, and thus are an extremely vital component of any application, software, or operating system. After windows, basic events such as keyboard input and mouse clicking are introduced, leading into the most important part of the chapter, which is how these events are dispatched and handled. Various methods/models of handling and dispatching events are introduced, bringing the reader to an understanding of modern handling of events within object-oriented program. This was a good reading and important for our class as we can take the points made in the chapter and utilize them when designing and programming the interfaces of our applications.

Hao Zhang 22:04:49 1/22/2014

Besides functions and speeds, UI is another important thing for a program. Based on same functions, a better UI can gain more users experiences. Every detail such as, a place to put button, a reaction for mouse-down event, the colors and so on are important to UI design. This chapter first shows the UI of some classic systems like Windows and UNIX. And why these UI designed in these way and how to operate them. There are some examples like how Display PostScript works and how to use FORTH language. And then this chapter shows us some important input events that we need to consider like Mouse Button Events, Modifiers, Double-Clicking, Function Buttons, Mouse Movement Events, Mouse-Enter and Mouse-Exit Events and Keyboard Events. It teaches us how to use and edit these events. It also provides us some sample of codes and table of these functions. The final topic to be discussed relative to event handling is the communication between interactive objects and network. This chapter mostly shows us the existing systems which give us ideas and some basic factors to design a wonderful UI. From this chapter, I learn a lot about some famous systems like X and NeWS which I never hear before. Although they are behind the times, they give me some senses that why these basic interfaces are important and how to use them.

Ariana Farshchi 22:14:00 1/22/2014

Chapter four, Basic Event Handling, outlines the services performed by systems and how interactive applications work within them. Events are used as the primary mechanism for communication between the user and the interactive objects, and among the interactive objects themselves. Communication via events is crucial to the understanding of interactive software. This chapter beings talking about the windowing system, which graphical user interfaces are built on top of. The primary purpose of the windowing system is to arbitrate interactive resources. The chapter discusses the variety of input events such as Mouse button events, mouse movement events, function buttons, and keyboard events. It also talks about communication between interactive objects, and discusses communication problems, which are handled by psuedoevidents. Which are new events that have been created for communication between objects and are not real input events. The chapter ends with explaining that communication among objects that cooperate to make up an interactive application is essential to understanding interactive software.

Melissa Thompson 22:14:04 1/22/2014

This reading is about event handling, or dealing with object and I/O communication through graphical user interfaces. It discusses four major topics that need to be kept in mind when designing event model architectures. The first is window system management, which includes the software window services (i.e. creation and organization) and user window functions (i.e. movement and resizing). It explains that different systems define windows and root windows differently...but according to this reading, the interactive parts of a window are actually called controls or widgets, and the box-like sections are the windows. Window management is important because it allows the management of screen space, and the windowing system itself is built as a tree to allow for organization and -- on the coding side -- reuse of code fragments like widgets. Window events are another thing that affect the event model architecture. These can be events that literally affect the window's display, or they can be input events, like interaction through the click of a mouse, movement of a stylus, or the press of a key (or "function button"). Once the window has been created and an event has been received, it also has to be handled. This is therefore the third aspect that affects the event model architecture. When events occur, they are put into their respective queues until they are able to be processed. The way that events are dispatched and taken care of can be tailored by the programmer (and the different programming languages) to fit the application. They have to choose a method that designates the window to which an event belongs based on mouse location, event address, or another form of information. The programmer can also use OOP languages to make handling the events a bit easier. I actually had no idea we have so much control over event handling. Up until this point we learned about device to window communication. Lastly, the reading talked about interactive object communication, a problem solved with "pseudoevents". These are events that don't originate from an external device, but are rather created as a reaction or response to another event. Three ways of doing this were discussed in the text: the callback model, which adds procedures to specific events or controls that are invoked after an event, the parent-notification model, where every ancestor window is notified of an event so that reactions can take place, and the connections model, where objects communicate with one another directly. After reading this I have a better understanding of what is important to consider when designing event handling models. We have to make sure that the model is tailored to the application by designing the windows that the user interacts with, deciding how to process events (and which events to even allow), and programming psuedoevents to make the application more dynamic and useable.

Steven Bauer 22:42:20 1/22/2014

Todays reading is about the start of event driven applications and how developing them is fundamentally different from the command line programs of the past. In command line programs the software is in control and prompts the user when it wants input. In the new GUI paradigm the user is the one in control. The next section describes the use of windowing systems in modern operating systems, it is interesting that in many of the newest OS's (ios,android, somewhat windows 8) we seem to be moving away from this windowing system. Next the article describes the various events that could happen in this environment they describe clicking, function buttons, and various other mouse input, they also mention keyboard and even handwriting recognition. The main event loop describes the "flow" of these applications, not much code is in their "main" because all main does is set up the windows. Actual code execution is event driven and usually won't be run until the user triggers it. The next section is an important one, it deals with event dispatching and handling. To dispatch events in a windowing system we need to associate an event handler with each window so we can translate between events and program methods. The final section is on communication between objects because the user controls the "flow" of the program it is important that objects in our software are able to send data to each other. Things such as buttons and scroll bars are made such that they notify their parent when an event happens but it is also possible to have each widget have an individual identifier. This was an interesting article because along with going through the various topics, it would delve into how many of the common operating systems would handle these issues. I was quite interested to see the differences between NeXT and Windows.

MJ McLaughlin 23:09:37 1/22/2014

This chapter on the “Basics of Event Handling” provided a very interesting look at everything that goes on behind the scenes to support the direct manipulation interfaces that have become such a major part of our everyday lives. The event model of the communication between user input and the objects that users can interact with is at the heart of and drives direct-manipulation interfaces. These are interfaces in which users are presented with objects, such as windows, scrollbars, and buttons, on a display that they can manipulate via input methods like mice, keyboards, and, nowadays especially, touchscreens. Driving all the interacting we do with all kinds of devices every day is a windowing system and many processes that support the windowing system and user interface. The windowing system creates and presents users with the application windows that we have become accustomed too, as well as the ability to move and resize these windows. The windows house applications that can run independently and concurrently and that we can interact with, which necessitates the ability to identify, for example, which windowed application is currently in focus and should receive keystrokes, or which window the mouse pointer is pointing at. Different systems, such as the Macintosh and Microsoft operating systems, implement these systems in different ways, but most utilize a tree-based layout consisting of a “root” window and the elements that make up the application in that window, such as toolbars, buttons, and so on, as well as the scrollbars attached to that window. All of these different elements communicate via “events,” such as keystrokes and mouse clicks, which are again handled in different ways, such as passing which window/object is to receive input and what type of input has been received. An interesting point that I never really thought about was how the underlying programming language used to construct all these different windowing systems plays a key role in how these systems operate. Object-oriented languages like Java make inheriting element classes like buttons and overriding methods for specific desired functionality a smart design choice, and the ability to store and pass method identifiers in languages such as Objective-C allows for the objects underlying application elements to communicate with each other closely as in the Object Connections Model. These objects themselves have methods that respond to different types of user input, as well as other objects, appropriately and allow for the interaction between user and application that is central to user interfaces. And this all made me think about how these are the same ideas that underlie the Android OS and how we as designers and programmers can use it to interact with users in unique ways. The onClickListener on a button, for example, allows the button to respond the button presses from the user with programmed methods to obtain the desired results. And we can also inherit the properties of supplied classes and overwrite methods to provide new functionalities unique to our situation, such as is suggested in our second programming assignment. There is a lot that goes into the user interfaces that we interact with all the time and in many different ways, and it was pretty cool to see some of what drives these systems that are becoming more and more central to our everyday lives.

James Devine 23:20:12 1/22/2014

This article says that the main program of an application is a loop that handles input from a user. Events are created from the input and then sent to certain windows. It discussed how multiple applications can be run simultaneously and that object communication is vital for interactive applications. I also found it interesting to read how mouse and keyboard events are handled mainly because they are used the most.

Zach Sadler 23:28:10 1/22/2014

I found the reading to be pretty dated, talking about 'a World Wide Web browser,' the origins of Java, and old school operating systems. All the same, it was interesting reading about these ideas as if they were new concepts. Mouse focus is certainly a topic that makes more sense nowadays, with touchscreen input leading mouse focus to be a relevant topic again. The actual logistics of using abstract classes and such were ideas I'd been introduced to before, but I still found some of it useful, like the refresher on callbacks.

Brian Kacin 23:56:19 1/22/2014

The beginning of the article talks about window event handling. On most computes, users can have multiple window screens running simultaneously. Because of this, having a user interface is crucial, for the user to resize and organize windows without chaos. Then it goes into talking about events. Events are indentified by types that allow the receiving software to distinguish the information the particular event is trying to communicate. The most important events are the ones that are interacted with the user, input events. When reading this article, there should be a few Input Events that we should be aware of. One of the most important event features is the Mouse. Where you can double click, click and drag, and click. Also there is a Keyboard event, which can be thought of as an array of keys to the computer; however, because keyboards are not standard, they tend to get a little tricky. For example, the currency logo is different in the UK so it will be used for different purposes. Then it goes talking about the Event Loops, event queues and filtering inputs. It consists of initialization followed by a loop that gets events and dispatches them to the appropriate objects. All application behavior is encoded in the event handling of various interactive objects. After all of this, it explains how all of these are dispatched and handled. It goes into great detail on Object Oriented Event Handling. The main program for a graphical application is usually minimal. To understand the communication between the software for interaction is a crucial thing to understand if you want to do anything with software. After reading this article, it thought it was too vanilla and plain, plus a hard read to critique on top.

Nicholas Amoscato 0:12:08 1/23/2014

In this chapter “Developing User Interfaces”, Dan Olson describes the primary mechanisms that enable communication between the user and interactive objects. In general, the event model supports the creation of direct manipulation interfaces. Direct manipulation is an interaction style in which the user is presented with concrete objects on the display and then manipulates those objects using the interactive devices. Unlike command line interfaces, the user, not the program, is in control. Most graphical user interfaces run under a windowing system that consists of two elements: software services and window management. Software services enable the creation and organization of windows in their respective interactive fragments. Organized as a hierarchal tree, root windows provide the interface abstraction for multiple applications, and all descendant windows derived from a root window generally belong to the same application. Widgets or controls are a built-in set of interactive objects provided by windowing system. The window management element is an interface that enables users to control the size and placement of windows. There are several types of windowing systems. X Windows was designed such that user and application software do not need to be on the same machine; that is, they interact over a network. In general, much of this client/server architecture is hidden from the application programmer. The NeWS windowing system was also designed to handle interactive sessions over a network, but it uses a display PostScript graphics model in which input events could be handled locally. Finally, the Java windowing system’s embedded interactive servers are isolated virtual machines that implement the majority of interface components on the client side. As mentioned earlier, the event model has become the standard means in which user actions are distributed to the appropriate window. There are several different types of events that are distinguished based on the information they transmit. Input events include the mouse button which carries information such as the position of the cursor and is dependent on the machine hardware and windowing system. Modifiers are special function keys such as ‘Shift’ or ‘Control’ that extend the interactive action space; they are usually passed to existing events as a bitmap or flag. Mouse movement events are triggered when the mouse changes position, and this event can be masked depending on whether a button is being pressed or not. Keyboard events are relatively complex considering the lack of keyboard standardization, the relationship between keys and the handling of accelerator keys (such as those system-defined keys used for menu selection). Every key press and key release generates an event that contains a scan code corresponding to the appropriate key. Windowing events deal with creating, destroying, opening, closing and resizing the window while redrawing events signify the appropriate window region that must be redrawn in response to a user action. Unlike standard sequential programs, interactive programs consist of a main event loop that simply listens for events. Events are generally placed on a queue that is processed by the main event loop, and irrelevant, low level events are generally filtered before being acted upon in this loop. In dispatching mouse-related events, the window tree is generally traversed in a bottom-first fashion; that is, the (irrelevant) windows higher in the tree are ignored. Keyboard events do not have an inherent position and usually use either the current position of the mouse or the previously clicked window. Mouse focus, initiated with a mouse down event, sends all mouse events to the “focused” window regardless of the mouse position until a mouse up event is recorded. Pseudoevents are derived events created for communication between objects. There are several models that implement pseudoevents: the simple callback model allows C procedures to be attached to widgets at runtime; the parent-notification model notifies the window immediately above the window in which the event occurs; and the connections model allows any object to communicate with each other. The event-handling framework is largely determined by the programming language of the original system design.

Bret Gourdie 0:56:37 1/23/2014

This reading talked about event-driver UI. In it, we analyzed a Macintosh screenshot of two windows. Mac really shines here; their presentation and user-friendly approach to UI is center-stage. It begins with discussing the windowing system, talking about how to manage all of the potential windows that would spawn. Moving on to the window events, the reading discusses things such as window redrawing, something I would not even think about in building a windowed system. The next part is that of a Main Event Loop, wherein we discuss how we would even process these events if implemented, involving low-level key press captures. Getting toward the end, the second-to-last section on event dispatching and handling is a doozy; it turns out that one has to be quite smart about handling these windows and removing them whenever finished. Finally, the last section involves communication between devices, a smaller yet important section concerning itself with three different models of communication. Although difficult, getting all the little pieces to work in unison is incredibly satisfying and much easier to conceptualize than having some monolithic monstrosity to maintain!

Chris Solis 0:58:49 1/23/2014

The reading was split into 5 different sections that focused on user interfaces and their implementation. The reading specifically focused on the windowing system interface which is the dominant user interface in today's society. In the windowing system the user has direct influence over the objects presented to them. The first section focused on the software and how root windows are the top tier in a hierarchy within an application. The remainder of the section focuses on different implementation of the windowing system by X Windows, NeWS, and Java. The second section focused on the the windows events. It details real world examples of window events such as mouse buttons, double clicking, modifiers, and keyboard events. All of those are input events where the user is directly inputting some action for the computer to resolve. There are also windowing events which have to do with controlling the window itself. These include closing the window, opening it, and closing the window. Emphasis is placed on what happens when the window size, shape, or orientation is altered. The third section focuses on event processing. In the average case an event is placed on a queue and then the events are periodically removed from the queue. Certain low priority events are filtered out of the queue to make sure unnecessary events are not triggered. This allows for faster processing of events and priority management for more important events. The rest of the section focuses on exiting the main loop of an event and an object-oriented approach to processing events. It provides examples such as Microsoft Visual C++ which provides its own event-handling processes.The fourth section presented the basic framework for dispatching and handling the events. Some people implement a bottom-first approach where once a window is clicked the code if forwarded to the lowest window in the tree controlling that window. An example would be when the user clicks to move the scroll bar. The code is sent to the scroll bar window. In contrast, the top-down algorithm sends the code to the top window. In the above case it would be the window that houses the scroll bar. The rest of the section focused on different models for event dispatching such as the Microsoft and Apple dispatching model focusing on each model's pros and cons. The last section focused on communication between objects. An example if when the scroll bar is moved the text must also move. In order to generate this movement there are pseudoevents for handling communication between objects. Overall the reading seems to do a really good cost-benefit analysis of each different event handling model.

Matt Landram 2:39:27 1/23/2014

This reading provides an overview of different methods of event handling. The reading starts off by outlining some ways that different interfaces (Mac, Windows) handle events. A Macintosh, for example, stored identifiers for each type of window, and the event handler would use those identifiers in case statements to figure out which code would be used to handle the event. Event tables were created, providing a database that would enable event handlers to just look up what to do when certain events were triggered Windows used something different, called WindowProcs. WindowProcs contained a pointer to the window that received the event, an integer event type of the event, and two other parameters that changed depending on the type of event triggered. The WindowProc enabled the event dispatch algorithm to be rather simple. The next portion of the reading describes object oriented event handling, and even lays out an abstract class that can be used for event handling. The next section explains how to link the abstract class with the windowing system. Later on in the reading, the author describes how to use this class with examples of communicating between objects.

Megan Ziegler 2:43:07 1/23/2014

The basis of all user-driven programs is the event. Events are actions, usually triggered by the user, which cause a program to execute in a certain way. Many elements of windows-based systems that we take for granted, such as clicking and typing, are actually long, complicated series of events that any low-level programmer should consider. Input events are user interactions, such as clicking and keyboard inputs. There are many variations of these, and it's important to find a solution that has low overhead. For instance, mouse clicks that operate with function keys— such as a control-click— can be handled with a "modifier" bit that determines an action. These inputs trigger actions onscreen, such as drawing new windows or terminating processes. There are many ways to handle events, but with the rise of object-oriented programming, OOP models have become preferred. For instance, a high-level "application" class can take care of all basic, common input. It is also easy to build a tree of objects, linking them with pointers, which makes it easy for the operating system to dispatch and execute events to the correct locations. Should objects need to interact with one another, most classes contain some form of callback function which allows them to communicate quickly and easily.

Buck Young 3:22:21 1/23/2014

This reading spoke of several important topics. First, it spoke of window events and possible user-input events: mouse button events, possible modifiers, double-clicking, function buttons, movement, enter/exit, and keyboard events. These events all occur, essentially, to a system and are broken up based on the open window tree (many procedures determine who should receive the event). Windows, themselves, have events too (redrawing). The article then proceeds to discuss how events are dispatched and handled. Events are usually resolved with an EventHandler implemented as an Abstract class. Any functionality can be coded into the class and will be executed when the event takes place.

Kyle Tanczos 3:57:36 1/23/2014

Today's reading was extremely useful, especially to me because I haven't programmed applications primarily focused on user interfaces before. Most of my programs have just been computational and not focus on how the user interacts with the computer. Learning about event handling is useful because of my lack of experience with interfaces. While some aspects of the reading, such as the windowing system, was already common knowledge to me, it was good to learn how the management of windows leads to easier communication from user events. Also, considering network traffic in software which needs to different machines is very important to the functionality of the interface. Because data must be sent back and forth between the machines, you need to plan how to communicate so that both interfaces are responsive and intelligent.

Pedro Alvillar 4:34:21 1/23/2014

In modern graphical user interfaces there is communication with other applications, with the windowing system, and with the code used to implement the interface. All of the communication that a particular GUI is involved with is achieved through events. In order to efficiently handle running many applications at a time, a windowing system is used which allows the user to manipulate the size and placement of said windows. These windows are organized in a three-like structure usually with a root window provided by the operating system which provides the user with interface abstraction for multiple applications. Input events triggered by user interaction are among the most important events that need to be dealt with; these include : mouse clicking and movement events, and keyboard events. For the most part, events are input into a queue (usually one queue per program) and are later removed from the queue by the main event loop and processed accordingly. There exists a large quantity of windowing systems that implement the bottom-first even dispatch model. The bottom-first even dispatch model sends events directly to the window and in doing so makes it difficult to impose any control over event dispatching that is independent of the algorithm. There have been various models for even handling used: Macintosh-Style , even table model, Xtk/Mottif callback model, and Windows WindowProc-Based even handling. All these models however require programmers to either directly sort events with switch statements or register the addresses of the handling procedures. With this in mind it made sense to develop object-oriented event handling (with the use of an Abstract class) which would be less prone to errors. It is also essential to deal with communication amongst programs, however said implementation is made difficult by the fact that there is no standard flow of control through the program.

Derrick Ward 7:02:15 1/23/2014

In todays reading we discuss the way a different computer systems and operating system architecture handle event handling. In the reading, in the early days of computers, event handling was very controlled and simple. A user would simply be greeted with a textual prompt and then he or she would reply to that said prompt in the same fashion. As a programmer, that sure takes away a lot of the error catching protocols that one now has to write for a more complex user interface. The reading then gets into exactly how the OS architecture handles multiple graphic windows for a program and multiple graphic windows for multiple programs that are running simultaneously. We begin discussing how root windows, widgets and other controls help the software architecture to manage these graphic windows, which the user will use to interact with a given application. Then we jump into the different ways the architecture can vary to carry out these graphical event-handling protocols, such as a network-based interaction (like a workstation). In discussing the network-based interaction, I learned about the existence of language called FORTH. Until today I had never heard of that language. The passage then gets into other user input mechanisms such as the keyboard and mouse events (double click, right click, and left click). For the most part I understand the mechanism that support that interface. The section that seems to have caught most of my interest was the Object-Oriented Event Handling section. That approach of passing messages to different objects to handle a key press or a mouse exit or redraw flows better with how I imagine handling a graphical user interface for my users.

Alex Stiegel 8:37:22 1/23/2014

The windowing system is a very common system used today. I find it interesting that windows 8 was pushing away from that a bit. It's more like they have multiple full screen desktops as opposed to windows with some of their applications. It's actually really frustrating because it's so different. The next section talks about mouse and keyboard events. Again this is a common occurrence across most platforms. Event loops and handling can be pretty interesting, but it's also a common occurrence among systems. The way they can handle streams of events in a queue is really nice for how we use computers, but on the other hand if you have an eager user that double clicks on their browser too many times, you end up with 30 browsers because of the queue.

Cody Giardinello 8:40:14 1/23/2014

Today’s reading is all about interfaces and how they function as the main intermediary between user and system. The reading starts off with a discussion of the early interfaces like DOS and UNIX that had a much simpler architecture until windowing systems were created. The first aspect of a windowing system is to allow programs to create and organize windows as well and to implement the interactive fragments within those windows. The author leads us into a discussion of how a windowing system is seen to the user (scroll bars, exit buttons, etc.) then begins a behind the scenes look into how the software actually works behind a windowing system. This discussion brings us to the hierarchical structure of such a system, showing the layers that are built in the software. Then, the author begins discussion with the windows management which is just code built to allow a user to manipulate windows. Next the author speaks about the variations of these systems for a network based implemention, ranging from X Windows and NeWS all the way to Java. From here, the reading leads us into all of the events that could possibly occur in an application that would trigger an event. These include double-clicking, mouse movement events, and keyboard events. All of these actions require software to handle the event and provide the appropriate feedback and response. The main event loop is discussed in detail because it is the backbone to how all events are processed. You will quickly find that the “main” in most programs do not hold much useful information like most programs do. More topics that were explored in the reading include event object-oriented models for the event loop (where the application classs is defined in the tool kit), dispatching and handling events (based on a windows tree since Canvas/GIGO), Macintosh vs. Windows approaches, and more detail in how object-oriented event handling is done today. This is done with functions built in such KeyPress, MouseEnter, and Redraw. The final topic discussed is the communication between interactive objects. Pseudoevents handle communication between objects that are not necessarily real input events. The three basic models of this kind of communication are the simple callback model, parent notification model, and the object connections model. All of these approaches have their advantages and the decision for which to use is based on user need and programmer choice.

Matthew O' Hanlon 8:56:58 1/23/2014

Windows seem like a free form interface over which the user has (mostly) total control, but the windowing system follows object oriented designs thoroughly. Windows in most operating systems are arranged in a hierarchy of nested rectangles because its shape makes it easier to divide up the screen for drawing the windows. Once the screen is divided up, the windowing system performs its main responsibility which is to arbitrate interactive resources in a shared root window. This arbitration is specially designed software known as window management code. The window management code has two general design patterns, one is the client side app handling all windows, and the other uses the client/server model to handle events over the network. Microsoft Windows and Mac use the client side architecture, while X windows utilizes client/server architecture. There are generally two types of user input, the mouse and the keyboard. These input are generally handled the same with a few exceptions. Mouse events are passed with coordinates and the button number of the button that was pressed. The window manager handles the event to instruct the window how to redraw/react to the mouse event. Usually one click of a mouse or one press of a key is handled in the same way, by the dispatcher. But for added functionality, the mouse and keyboard events can generate different events through sequences of clicks (double-click) or keys pressed. Double-clicking is handled by simply letting both clicks have meaning. The first click is a select. The object waits for a second click, and then acts on the second one in a time frame if it receives one. Modifiers are keys that can be pressed with mouse clicks to gain other actions/functionality. A bit-word is checked to see which, if any, modifiers have been used in conjunction with the mouse. Each modifier is mapped to a bit in the word. The window manager also has to know how to handle events, and there are two general algorithms to do this. The bottom up approach, and the top down approach. The bottom up approach allows the from most, bottom most leaf in the tree of a window to receive or reject mouse events. This doesn’t allow for a lot of control over the handling system, so the top down approach is also used. It allows the selected window to receive events, and then pass down the event to the proper control or sub-window.

Robert McDermot 8:58:39 1/23/2014

Today's reading is about how event driven interfaces have developed. The author describes each of the major platforms and the differences between them.

I didn't have a lot of new information to take away from this, although the historical perspective was interesting. As the author described the differences in the evolution of different systems, it became more clear to me why certain design choices were made. For instance single button mouses vs multi-button and single click vs double click to interact.