Model View Controller and Event Driven UI
From CS 160 Fall 2008
Lecture on Oct 13, 2008
- Basics of Event Handling. Developing User Interfaces. Chap 4. Olsen.
Please post your critiques/commments on the required readings below. To do that, first login by using your user name and password, then click the "edit" tab on the top part of this page (between the "discussion" page and the "history" page), New to wikis? Read the Wiki editing guide. . Hint - Please put a whole line == ~~~~ == (literally) at the beginning of your submitted critique, so the wiki system will index, sign and date your submission automatically.
Vedran Pogacnik 04:47, 11 October 2008 (UTC)
It seems that the event driven programming was a carefully dissected issue in some days. One thing is the same in all approaches of implementation of windows: abstraction. The main thing is to provide a simple and uniform (standard) way to deal with the idea of windows. Some applications were, as noted in the text, overkill, while other seem to be really light-weight with a numbers of indirection levels. Of course, there is never “one best” type of approach for all systems. What helps choose which approach to use, are the usability studies. For example, one could imagine how in the old days, implementing the scroll functionality one way could raise red flags with users, so obviously another model of implementation was needed.
Also, the text brings up interesting points about the interaction between applications that are abstracted behind the windows, and how the windowing implementation can be impractical for some types of applications. By the looks of it, the book was written in ’98, so common software practices taught in school nowadays (software engineering) should at least provide some guidelines in avoiding the problems of the previous millennium.
KevinFriedheim 19:29, 11 October 2008 (UTC)
Windowing has really weaved itself into a commonplace thing in mainstream computing -- that is, it has become apart of a ubiquitous computing scheme where technologies (like windowing systems) find there way into the mainstream and slowly disappear in terms of their being a "technology."
When the discussion carries into mouse events, I found it very interesting that early Mac computers designed their windowing systems around mice hardware that only has one button click functionality. But contrary to this, there are programs on the Mac these days that do require a right-click functionality of the mouse and so many laptops that I have seen provide this ability despite the one button mouse (usually by means of a Ctrl-Click or MacKey-Click combination).
I found it interesting that the term "widget" is used differently in user apps the it is for programmers when they are programming apps (that uses techniques like callbacks when implementing such things as "scroll bars" that need constant update and position storage). These widgets were used to create events that the programmer can provide for the user -- but I think that since this text is old, these events have become much easier to implement and many features (like scrolling) have become commonplace.
James Yeh 21:01, 11 October 2008 (UTC)
Seeing as how this article was published ten years ago, I found the discussion about the scenario of event handling over a network to be, although factually correct, somewhat irrelevant to the current technological environment; as we are moving towards ubiquitous computing, the chances that event that require a quick response time (i.e. mouse movements and scroll buttons) need to sent over a network are near nonexistent, and thus such situations don’t present nearly as significant an issue. Furthermore, most of the reading focused on the history and past developments of mouse and keyboard I/O, something that, while necessary for covering the low-level basics of windowing design, had me wondering how we could apply this information to our actual game-building. A lot of techniques introduced in the beginning of the reading seemed to become obsolete when a new and improved techniques were presented ten pages later in the reading, so it makes sense that the current technology for windowing systems has changed since the object-oriented model described at the end of the reading. While the reading was definitely informative, I found it hard to relate the material that Olsen discussed with either the model of human-computer interaction or the serious game project we are working on. Maybe I am underestimating the power of low-level design of windowing interfaces, or maybe I would have found the reading more applicable if the pictures didn’t look like they came from computers clearly more than a decade old.
Karen Tran 06:35, 12 October 2008 (UTC)
The article provides a good introduction to event handling, and how it's used in several operating systems (though somewhat outdated). It's interesting to see that even though the systems eventually perform the same tasks, their implementations are very different, for example in how event loops and event dispatching is done. These differences translate into the balance of control vs amount of code that the programmer has to write. When the programmer has to write less event handling code, he or she can focus on the functionality of the program, and leave the rest of the UI to the system to handle. Even though this reduces how much control the programmer may have over the system, it leads to more stable code, and a more uniform interface that uses the same components as the rest of the system. Events should be the "primary communication vehicle" in interactive programs. However, it is not a good fit for other non UI applications. For example, while working on a group project and communicating via email, I am not going to poll my group members every five minutes to see if they have any questions, I will wait for them to email me. Furthermore, I will probably wait for several emails to pass before I check my email, then read them all at once. Thus, my algorithm for checking email is much more like "batch programming" rather than "event driven." Both have their uses, but event driven is definitely superior for interactive UI'
I think that's one of the problems with Windows - they support several methods of handling events, drawing on the screen, and creating/using GUI elements, from the old C Windows API, to C++ and MFC, to the newest C#. This means that various software packages are vastly different in how they handle events and the user interface. Because of this a lot of software is inconsistent, and requires many additional libraries to run properly. This also means that Microsoft has to continue supporting all of those methods in newer versions of Windows, which brings all the old bugs and security flaws into the new systems as well. I think that they should at some point switch to a single simpler, more consistent model, and phase out older systems just like they did with DOS and 16-bit support during the transition from Windows 95/98 to 2000/XP.
I very much like the idea of having a GUI that is functionally equivalent to a command line interface. That is, the GUI provides no more nor less functionality than a command line interface, and a user can accomplish all the same tasks using the GUI as using a command line interface. The command line interface is a powerful and efficient tool, once you learn it. The windowed GUI is easier for beginners to grasp, and is thus more natural, but both should be available. Most user applications today have redundant keyboard commands such that the mouse really is not necessary. This is great and can improve efficiency for power users as well as an easy interface for novices.
Stuart Bottom 06:38, 12 October 2008 (UTC)
As mentioned by the prior commentators, I found the age of this reading slightly disconcerting at first; however, looking beyond this issue reveals many points still relevant to design today. The comparison between the different methods used by various operating systems was interesting, and highlights core conflicts that still must be addressed. For example, Macs still have one-button mice, PC's still have two, three, or more (sometimes plus a scroll wheel, etc).
Additionally, I would argue concerns over latency and response time are still relevant today, particularly as windowing systems continue to become more graphics-intensive (hello Vista). In other UI's, such as Flash interfaces for websites, these are also concerns. UI designers can't always rely on the user's hardware being optimal enough to run their latest and greatest slick GUI, so writing event-handling code for efficiency is still good practice even today.
Gary Wu 19:47, 12 October 2008 (UTC)
In recent trends in operating systems, I see a shift away from the root windowing system. Instead, the standard navigation technique of parsing folders is used without seeing the hierarchy of the folders accessed in the process. I feel like the root windowing system is geared towards the super-user while the latter is built for the casual user. In interface design, there seems to be a huge push towards simplicity and ease-of-use over advanced features and customizations. More recently, software such as Top Desk and Stardock have been focusing on flashy and fun window management solutions. Nowadays, an object dock and flipping window screens are accepted as a standard. After reading the mouse input portion of the article, I wondered why the developers never added a function for the double-right click. While reading the section on the mouse focus dispatch algorithm for scroll bars, I can appreciate how such a simple algorithm can make user interaction that much better.
Jimmy Nguyen 20:21, 12 October 2008 (UTC)
Speaking of operating systems, personally, I have never been a Macintosh patron due to its large success solely based on marketing and interface, but lately I have been able to appreciate it more and more. Going on the trend of new user interface designs, everything is evolving into the much more simplistic and efficient designs. In addition to earlier remarks about command line vs. windows, Macintosh seems to be the best compromise of both worlds, having functionality for both the simplistic, yet sophisticated graphics embedded into the system, but also have command line power to work as a nix box. One of the programs that gary mentioned, Stardock/object dock, takes a lot of these cool graphical and applicable principles and puts them into the windoze system.
Perry Lee 21:14, 12 October 2008 (UTC)
KevinFriedheim's comment about early Mac computers' mice reminded me of a video that they show in cs61a. This video discusses the early forays into computer user interfaces. If I recall correctly, at one point in the video, they come to the topic of the mouse, and express the concern that multiple mouse buttons would be too confusing to the users. I find it interesting that to this day, Apple computers still only use one mouse button -- even on their Mighty Mouse (you have to enable the right click in the System Preferences; it does not come on as default).
Also, in response to Karen Tran's comment of having a GUI that is functionality equivalent to a CLI, I don't know how advantageous it'd be -- I see it more likely that users would be intimidated by the sheer number of options, or the GUI's options menu would become ridiculously large. As she mentions, the CLI is a powerful and efficient tool, but a GUI is easier for beginners to grasp. I am more of the thought that the GUI should provide the most commonly used options and expected default settings, and leave the more advanced, less-used ones, for the CLI.
JoshuaKwan 23:52, 12 October 2008 (UTC)
It's worth noting that this book is highly outdated. X, Motif, and NeXTSTeP both have a lot of longstanding issues that are no longer problems with modern operating systems. While understanding these concerns may serve as cautionary tales about how not to create the next great window manager implementation, I was more interested in hearing about the MVC model specifically and how it applies to real UI toolkits these days such as GTK+, Qt, Windows, and Aqua.
Jonathan Fong 04:21, 13 October 2008 (UTC)
This reading should not have been, but it seemed extremely dated. Windows are still in use in most operating systems, but for most web applications and games, windows are not critical. The algorithms for event handling were a good primer, though, for when our group will need to implement our interface in Flash. We will probably go with an object-oriented approach.
Kumar Garapaty 05:29, 13 October 2008 (UTC)
I found the discussion of mouse and other input/output devices interesting and should be a fundamental reason for the development of tangible user interfaces. The limitations of the mouse and keyboard are apparent and the development of other input/output devices can be important for many applications and various game designs. The event handling discussion is accurate and straightforward.
Billy Grissom 05:44, 13 October 2008 (UTC)
It seems like a lot of this article is a bit dated. The windowing system has become widely adopted in many desktop applications and...heck...Mac and Windows practically swear by it. That being said though I think that the event-like approach to UI that this article talks about is still very applicable towards exploring new UIs. Personally, I think the window approach is practically useless when it comes to phones. Given the tiny screen size and lack of a mouse, a window system seems rather impractical for a phone. Then again, with recent technology developments such as the IPhone's touch screen a hybrid system that kind of uses the windows approach might not be a bad idea. For example, the iPhone seems to really use this event driven system. Although you can't move your widnows around and such, you can still sort of "minimize" and "maximize" the different app screens.
Nevertheless, I did find the section about keyboard mapping rather interesting. It's interesting how there can be so many apps yet they can all still utilize similar keystrokes. i also think it's amazing how deep the event driven UI extends. I mean you would think a mouse and keyboard would be enough for total control, but alas a user is given even more options with various macros and hotkeys.
Yuta Morimoto 05:48, 13 October 2008 (UTC)
I think the reading is very good material to learn about historical knowledge of event model on user inter face. I think studying the past development of input devices is important for implementation of windowing design. However, these technique are enough elaborated and hard to relate the recent human-computer interaction products. No matter how I learn about model discussed in reading, I have no idea how to apply it to our project.
Buda Chiou 05:57, 13 October 2008 (UTC)
The windows system makes computer become more popular then it was. The reason is not because it's functionality but the graphical intertace it use. Graphical interface is so powerful that even for people who don't know the language that the system use or unfamiliar with computer can easily figure out how to operate the system. However, there are still some people who really love to use the text interface and I don't know why.
Frank Yang 06:15, 13 October 2008 (UTC)
Although this reading seemed dated, I still found it rather interesting. Since I've grown up using the windowing system, I've never thought that much about the algorithms behind it. As I was reading, I couldn't help but think about how the mouse and keyboards have been modified, yet still remained inherently the same. There are mice now with 10 buttons on them, but 8 of them are still considered extra to the typical left and right click and scroll wheel. And now with touch interfaces becoming increasingly popular, a new type of input will need to be considered.
Haosi Chen 06:36, 13 October 2008 (UTC)
There are a lot of techniques introduced in the beginning of the reading seemed to become obsolete when a new and improved techniques were presented ten pages later in the reading, so it makes sense that the current technology for windowing systems has changed since the object-oriented model described at the end of the reading. I like the idea of having a GUI that is functionally equivalent to a command line interface very much. That is the GUI provides no more nor less functionality than a command line interface, and a user can accomplish all the same tasks using the GUI as using a command line interface. The command line interface is a powerful and efficient tool, once you learn it. The windowed GUI is easier for beginners to grasp, and is thus more natural, but both should be available. Most user applications today have redundant keyboard commands such that the mouse really is not necessary. This is great and can improve efficiency for power users as well as an easy interface for novices.
Mohammed Ali 06:45, 13 October 2008 (UTC)
Event driven programming is the popular approach to most systems today including Windows, Macintosh, Ubuntu, etc. Their implementations however might be quite different. The readings were interesting having covered the the issues of windowing of the past and the basics involved in their implementations. These basics, although not at the verge of technological advancement, are always intriguing and force the issue of redesign perhaps, and consideration of design change. The very basics of input and output from the mouse to the screen can always be used in examining basic design principles.
Wenda Zhao 07:08, 13 October 2008 (UTC)
The article gave a brief intro on the evolution of windows and how system handles events. I was especially interested in the MVC way of building the application. As a matter of fact, the popular web frameworks ruby on rails forces developers to use the MVC models for developing. It provides a very clean way of developing applications. Each element is depending on and communicating with each other. And it gives developers a very fast development cycle for doing MVC. I personally also liked MVC a lot, I think we should do our project as MVC if we can. I found this reading was helpful in general.
Witton Chou 07:40, 13 October 2008 (UTC)
As computer systems have become more nad more complicated, the interfaces have had to adapt to address the changes. While some features have changed for the better, many other features have become hidden and hard to use. Sometimes just trying to get a microphone to work in Windows means digging deep into the control panel. And while the software interface has changed, so have the interfaces of I/O devices. We have keyboards with rows of media buttons, extra volume controls, and even programmable buttons. Now with touch screens becoming more and more popular on notebooks and handheld devices, it seems that interface interaction development has spawned more directions to develop towards.
Bing Wang 07:55, 13 October 2008 (UTC)
The article talks about the windowing system and how the events are triggered. It talks about the X windowing system which was the earliest system which is just simple with commands and can be carried out over the network with very little overhead.
The window system that we have now days that include window management and is seen in Windows OS, MAC OS as well as some user friendly Linux distributions is the most intuitive way of managing windows as the user can easily see what needs to be done as oppose to remember all the commands in the X window system. The X window system would probably greatly frustrate first time users as they have no idea how to even start using the system without first reading the documentation. From my own experience, the first system that I touched was a windows management system instead of an X windowing system. I was not very used to X windows until after two semesters of Computer Courses in Berkeley. However, I agree that most advanced users would prefer the advanced system as it gives you much more power over the windows management system. However, as a regular user, windows management is much more user friendly and has much more user appeals.
I also had some expierience doing windowing system. I find it just like the article described where different action triggers would cause different results. When I did swing, I had to write a lot of code to make a very simple UI which seems to be a lot more work than needed. Also as the early portion of the course explained about the iterative process, it just made making the embedded UI much more tedious, and often the developers are unwilling to change it.
However, designing a CLI (command line interface) is much easier. As long as a list of rule is found for the system, the rules can easily be edited. There is nothing to embed, and each flag is clear to trigger an event.
Jacekmw 08:12, 13 October 2008 (UTC)
Like many of the previous commentators, I found this article to be somewhat dated and not all that applicable toward the design of serious games. While it was interesting to note the issues of early operating system user interfaces, today's technology resolves many of them - for example, cheap memory and faster networks means that we don't need to worry as much about the speed of operations done over a network. The sections on double-clicking and mouse and keyboard events apply to games, yes, but are explaining what we already must have known, clearly, just in order to have read this and written this review. Learning about the event loop and the object-oriented methodology around it was interesting, but as our game will likely be done in flash and thus not specifically require a separate window, much of this does not apply.
Alan McCreary 08:14, 13 October 2008 (UTC)
The article makes a good explanation of windowing and event-driven interfaces, even if it is somewhat dated. It's interesting that we now take user-controlled interaction and the complexity involved in event handling for granted – as the author points out, interaction between the user and the program was once controlled by the program. This concept of user control is particularly important for game design, since we must make the player of the game feel some degree of power at all times.
Kai Lin Huang 17:29, 13 October 2008 (UTC)
Olsen's article carefully examines graphical user interface design in term of event flows, which is practical and analytical. For example, modifier for mouse clicks using combination keyboard input must be carefully designed to accompany correspondingly sensible functions. Even though event handling is a big part of focus in the article, Olsen also pays attention to the fact that pressing functional keys does not create an event themselves, and lists several possible implementations for this potential problem exploding feature. In fact, I attended a professional visual computing conference event in San Jose this summer, and one of the key note demonstrations was multi-point touching control graphic user interface. With a combination of multi-point motions on the touch screen, the application window is designed to respond in certain ways, or activate certain events, such as common functions cut and paste, intuitive picture editing functions and high level animated pictures creation directly from the cut and pasted photos. Since there will not be mouse scroll or buttons nor even keyboard potentially available for future touch screen stand alone user interface, the multi-point control has to rely on the touch screen motion event listeners that monitor strikes on each unit grid on the screen. To show the system/window's response on the user's touching, the architecture and algorithm must be fast enough in high definition coordinate transmission, and the X server-client model discussed in the article can be of disadvantage because of high network bandwidth requirement.
Antony Setiawan 08:45, 13 October 2008 (UTC)
It is helpful to know different kinds of events that a program, a window in particular, can receive. One example that Olsen discusses are the limitation of mouse button in different windowing system. It particularly still mysterious to me why diffrerent machine uses different mouse button. Why wouldn't they come up with a standardized number of button a mouse can have? Wouldn't it be much better to implement, focus and develop event handler for standart mouse instead of using modifier? This way, we can have a unified even handler that works for all machine in addition to less abstraction required(compared to using modifier). Having nonstandardized event handling creates problems.As Olsen also mentions, system like X and NeWS have problems. Designing interactive system for those system requires more consideration especially for the networked implementation.
nathanyan 09:20, 13 October 2008 (UTC)
One of the sections I found particularly interesting was the Parent Notification Model on page 36, 4.5.2. While it may seem fairly obvious, I don't think I've ever organized "widgets" or components of an interface into a parent-child organization system. It seems like it would be a very natural classification in most cases (all of the scroll bars in a window, a subset of options in an input form), and consistent with object-oriented abstractions, should make code more robust.
Volodymyr Kalish 09:55, 13 October 2008 (UTC)
Hao Luo 10:39, 13 October 2008 (UTC)
As others have noted, the article is quite dated (we are talking about the computer industry, after all) and some of the operating systems mentioned is pretty outdated. As for operating systems, I have used Windows all my life and have recently tried a Mac. I was completely lost. Everything felt out of place. The interface was very simple and elegant but simply did not come naturally to me. It seems like with operating systems at least, having people learning one standard operating system and learning its nuances seems to predominate over design itself. In other words, Macs may have a better design, but if people are used to Windows, then that habit of using Windows and being used to a certain interface is more important than an entirely different design that may or may not be better.
Cynthia T. Hsu 12:41, 13 October 2008 (UTC)
This article was very interesting - outdated, yes, but it really forced me to reconsider concepts that I'd taken for granted. In particular, the parent notification model presented on pg. 124 (PDF 36) brought an added dimension to the concept of a windowing interface - I feel like much of my experience in GUIs has lead me to be very convinced that a simple callback model by which different "screenshots" are pulled up in response to button clicks is suitable for designing an interface, as the simple callback model is implemented in many programs. However, the windowing system by which PCs and Macs display files and folders does seem to be best implemented with the Parent Notfificaiton Model, by treating each window as its own object that receives inputs in response to mouse clicks.
I really appreciated Antony Setiawan's comment about "One example that Olsen discusses are the limitation of mouse button in different windowing system. It particularly still mysterious to me why diffrerent machine uses different mouse button. Why wouldn't they come up with a standardized number of button a mouse can have? Wouldn't it be much better to implement, focus and develop event handler for standart mouse instead of using modifier?" Like most people accustome dto using PCs, I have definitely always felt that the switch over to Macs has been fairly counterintuitive, although they have a similar windowing system that should be capable of the same functionality. This article suggests that these are largely due to historical implementation choices that have simply been handed down over generations - in essence, it seems as if neither implementation style is willing to compromise. I wonder if this goes back to the idea of working software being difficult to change once it is in production; that what we are dealing with now is simply an artifact of limited testing performed at the time this article was written.
Juanpadilla 15:37, 13 October 2008 (UTC)
It is interesting to see how competing ideas that evolved into what is today's windowing systems borrowed ideas from each other and in some cases have mashed together, nextstep and mac os. Also, some people have stated that this is an outdated article and that much of the topic is somewhat irrelevant to today's systems. I think that is not true because it reminds me of the current mobile environment. For example, currently mobile phones can only run one app at a time, which is similar to the Mac os described in the article. In addition, the development of the mobile windowing system is in full swing and new event input devices such as the iPhone's touch system have opened a whole new way to poll for new events in a system. Stay tuned......
Saliem Than 15:56, 13 October 2008 (UTC)
I thought it was interesting that the same ideas outlined are still used in popular front end languages today:
Handlers mentioned in the reading
- Rectangle getBounds()
Trinhvo 16:01, 13 October 2008 (UTC)
It's an interesting article to learn what's underneath interactive windows programming. It's simply a loop running forever waiting on events. Whenever a user generates inputs, these input are translated into events that are forwarded to specific windows. Which window should receive an event are determined by many different mechanisms. I think this article will somehow help us in our interactive design.
Kevin Lam 16:16, 13 October 2008 (UTC)
Like most of my peers, I don't see the relevance in reading about window mechanisms. Some of the details about scroll bars and mouse button events are outdated. Many of the issues presented in the article are no longer issues or concerns today. But what we can get out of the article is way event handlers are used and structured. In particular, I thought the sections on the different models (i.e. event table model and simple callback model) and how they communicate with one another were the most useful.
Jeffrey Rosen 16:31, 13 October 2008 (UTC)
Event handlers are a great idea and are very useful. They are used in virtually all UI toolkits. Event driven programming is very intuitive and goes hand in hand with object oriented programming. It is hard to imagine any alternative to this system.
Mike Kendall 16:50, 13 October 2008 (UTC)
First, why is this paper pushing java and news? although both of these have smaller network overhead, they require more processing on both the client and server machines. they also both require that there is special software installed on these machines so that this encryption and decryption can happen.
this little part got me thinking about my experience with x forwarding... it's never fast enough, but that's mostly a product of drawing the window on the client machine rather than because of a lack of bandwidth. i see this most when i'm working on a cs project and i see the difference between being in a computer lab in soda (where the machines are hardly even machines) and when i'm on my laptop or my box at work. either way x forwards quickly and reliably. however, when i'm in the lab and i have an abundance of "bandwidth" between me and the server, everything is sluggish. this paper (book?) didn't cover how much overhead is caused by converting to postscript or the java toolkit, but i would wonder (and guess against it) if it would be easier.
MuQing Jing 16:53, 13 October 2008 (UTC)
Although the article is fairly outdated, it is still interested to read about facets of UI that we nowadays take as a given portion of any operating system. It is true that windowing systems have essentially become synonymous with GUIs, and in becoming so, a standard has essentially been set. The layout of the events and associate actions are all but uniform across all platforms, and rather than having to work with this extra set of variables, developers are able to harness the consistency of these actions. One interesting thing to note, though, is that the interfaces described in the article at the time bears striking similarities that we saw on early PDA's and even on many cell phones today. The event handling, although not terribly useful in today's world since most of it is handled by the windows manager, is still very interesting to learn about the design of the event flow.
Shyam Vijayakumar 17:08, 13 October 2008 (UTC)
This reading was interesting, but I was wondering how it applies to us now. We can just take all the models like simple callback model and event table model for granted. All we need to do is concentrate on the user interface our own application and these things will take care of themselves. Furthermore, since my project uses a cell phone, this reading really didn't apply to me because most cell phones don't even use a windowing system. Maybe something that might help in reading this article is to help us think about what would happen in cases like the user clicks on a popup message in our game and goes to a different window within the game or even a totally different application.
Anthony Kilman 17:15, 13 October 2008 (UTC)
I hate to agree with the rest of the class, but the article was pretty old. Though many of the issues are relevant to design issues of today.
Kudos to Jimmy for 'windoze' :-)
The article proceeds to describe events and how they are the means of communication between the user and interactive objects. The GUI itself is usually organized into a hierarchy of windows, with which a user can communicate via I/O devices. It then diverges into issues with X, Motif, etc., with some useful tidbits on event driven programming and how this is key to understanding 'interactive applications'.
Paul Im 17:27, 13 October 2008 (UTC)
This was an informative article regarding the basics of an operating system. Although it seemed slightly outdated, there were still many good details regarding the basics of input events as well as the interactions between events. Since this article, however, there have been many advancements in technology. Due to these advancements, the basic inputs described by this article are somewhat irrelevant. There are multiple ways you can control everything, and all of these ways must be taken into account. For example, there are 3 or 4 ways to open a program, a couple ways to zoom into a document, etc… However, this article was still a good tutorial on how to apply java programming into an operating system.
Geoffrey Lee 17:31, 13 October 2008 (UTC)
Mikeboulos 20:34, 13 October 2008 (UTC)
I agree that event handling is very important and is still widely used, but I disagree about the tree hierarchy, yes it can work for a 2D application, but how about 3D?! instead of having it as a tree, I can see that each part is now an atom instead and it should be seen like nodes that are part of a graph, because one thing might trigger the other. so if we have it as a tree then where would the leaf point at. Also the tree hierarchy won't work if you can reach the same task through out different paths, which is true nowadays.