Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Abstract Window Toolkit From Wikipedia, the free encyclopedia Windows form with some AWT examples The Abstract Window Toolkit (AWT) is Java's original platform-independent windowing,graphics, and user-interface widget toolkit. The AWT is now part of the Java Foundation Classes (JFC) — the standard API for providing a graphical user interface (GUI) for a Java program. AWT is also the GUI toolkit for a number of Java ME profiles. For example,Connected Device Configuration profiles require Java runtimes on mobile telephones to support AWT. Contents [hide] 1 History 2 Architecture 3 Mixing AWT and Swing components 4 Implementation 5 See also 6 References 7 External links [edit]History When Sun Microsystems first released Java in 1995, AWT widgets provided a thin level of abstraction over the underlying native user-interface. For example, creating an AWT check box would cause AWT directly to call the underlying native subroutine that created a check box. However, a check box on Microsoft Windows is not exactly the same as a check box on Mac OS or on the various types ofUnix. Some application developers prefer this model because it provides a high degree of fidelity to the underlying native windowing toolkit and seamless integration with native applications. In other words, a GUI program written using AWT looks like a native Microsoft Windows application when run on Windows, but the same program looks like a native Apple Macintosh application when run on a Mac, etc. However, some application developers dislike this model because they prefer their applications to look exactly the same on every platform. In J2SE 1.2, the Swing toolkit largely superseded the AWT's widgets. In addition to providing a richer set of UI widgets, Swing draws its own widgets (by using Java 2D to call into low-level subroutines in the local graphics subsystem) instead of relying on the operating system's high-level user interface module. Swing provides the option of using either a system "look and feel" which uses the native platform's look and feel, or a cross-platform look and feel (the "Java Look and Feel") that looks the same on all windowing-system. Abstract Window Toolkit (AWT) is a set of application program interfaces ( API s) used by Java programmers to create graphical user interface ( GUI ) objects, such as buttons, scroll bars, and windows. AWT is part of the Java Foundation Classes ( JFC ) from Sun Microsystems, the company that originated Java. The JFC are a comprehensive set of GUI class libraries that make it easier to develop the user interface part of an application program. [edit]Architecture the AWT provides two levels of APIs: A general interface between Java and the native system, used for windowing, events, and layout managers. This API is at the core of Java GUI programming and is also used by Swing and Java 2D. It contains: The interface between the native windowing system and the Java application; The core of the GUI event subsystem; Several layout managers; The interface to input devices such as mouse and keyboard; and A java.awt.datatransfer package for use with the Clipboard and Drag and Drop. A basic set of GUI widgets such as buttons, text boxes, and menus. It also provides the AWT Native Interface, which enablesrendering libraries compiled to native code to draw directly to an AWT Canvas object drawing surface. AWT also makes some higher level functionality available to applications, such as: Access to the system tray on supporting systems; and The ability to launch some desktop applications such as web browsers and email clients from a Java application. Neither AWT nor Swing are inherently thread safe. Therefore, code that updates the GUI or processes events should execute on theEvent dispatching thread. Failure to do so may result in a deadlock or race condition. To address this problem, a utility class calledSwingWorker allows applications to perform timeconsuming tasks following user-interaction events in the event dispatching thread. [edit]Mixing AWT and Swing components Prior to Java 6 Update 12, mixing Swing components and basic AWT widgets often resulted in undesired side effects, with AWT widgets appearing on top of the Swing widgets regardless of their defined z-order. This problem was because the rendering architecture of the two widget toolkits was very different, despite Swing borrowing heavyweight top containers from AWT.[1] Starting in Java 6 Update 12, it is possible to mix Swing and AWT widgets without having z-order problems.[2][3] [edit]Implementation As the AWT is a bridge to the underlying native user-interface, its implementation on a new operating system may involve a lot of work, especially if it involves any of the AWT GUI widgets, because each of them requires that its native peers be developed from scratch. A new project, Caciocavallo, has been created, that provides an OpenJDK-based Java API to ease AWT implementation on new systems.[4][5] The project has successfully implemented AWT widgets using Java2D.[6] All the necessary core-JDK modifications have since been pushed to OpenJDK 7,[7] which means that Java can now be used on a graphics stack other than one of those provided by the official JDK (X Window System, OpenGL or DirectX), by including an external library and setting some system properties. ADirectFB backend for Caciocavallo[8] is under development, as is an HTML5 backend; the aim is to deploy existing Swing applications—without Java support—as ordinary web applications running on a web server.[8][9] [edit]See also Java portal The Wikibook Java_Swings/AWThas a page on the topic of:graphic programming in Java Standard Widget Toolkit [edit]References This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later. 1. ^ Fowler, Amy (1994). "Mixing heavy and light components".Sun Microsystems. Retrieved 17 December 2008. 2. ^ Geertjan, Wielenga (16 December 2008). "A Farewell to Heavyweight/Lightweight Conflicts". Retrieved 17 December 2008. 3. ^ "Bug/RFE fixed in current JDK 6u12 build". Sun Microsystems. 12 December 2008. Retrieved 17 December 2008. 4. ^ Torre, Mario (2 March 2008). "FINAL PROPOSAL: Portable GUI backends". Retrieved 7 September 2008. 5. ^ Kennke, Roman (18 December 2008). "Caciocavallo Architecture Overview". Retrieved 7 September 2008. 6. ^ Kennke, Roman (3 September 2008). "Cacio Swing AWT peers". Retrieved 7 September 2008. 7. ^ "How much has been pushed upstream?". openjdk.java.net. 20 September 2009. Retrieved 7 March 2010. "You don't need anymore those patches, with the latest FontManager push, everything is upstream now, so just use the Cacio repo, it's completely self contained." 8. ^ a b Kennke, Roman (28 July 2011). "JDK7 and Cacio coolness". Retrieved 8 August 2011. 9. ^ Eisserer, Clemens. "HTML5/Canvas backend for Caciocavallo (GNU-Classpath)". Archived from the original on 10 August 2011. Retrieved 8 August 2011. Structure of the AWT The structure of the AWT is rather simple: Components are added to and then laid out by layoutmanagers in Containers. We have a variety of event handling, menu, fonts, graphics classes in addition to those two, but they'll be only briefly discussed here. Nothing prevents us from using threads, audio, I/O, networking classes alongside the AWT. The AWT by itself is rather bare and empty. Imagine a text editor that couldn't save! As a side note, the AWT can be used in a standalone Java application or in an applet that is embedded within a HTML document. The AWT hierarchy Classes: BorderLayout CardLayout CheckboxGroup Color Component o Button o Canvas o Checkbox o Choice o Container Panel Window Dialog Frame o Label o List o Scrollbar o TextCompoment TextArea TextField Dimension Event FileDialog FlowLayout Font FontMetrics Graphics GridLayout GridBagConstraints GridBagLayout Image Insets MediaTracker MenuComponent o MenuBar o MenuItem CheckboxMenuItem Menu Point Polygon Rectangle Toolkit Interfaces LayoutManager MenuComponent Components and Containers: There are two user-interface classes in the AWT to focus on: Components and Containers. Containers Containers(Frames, Dialogs, Windows and Panels) can contain components and are themselves components, thus can be added to Containers. Containers usually handle events that occurred to the Components, although nothing prevents you from handling events in the component. In short all classes derived from Container can be one. The method of handling events in the Container(i.e Frame) is preferred over the latter, since we want to centralize event handling. If you don't want to handle events in one common area of code, then you must sub-class every Component you create an instance of and override its action() or handleEvent() method. public class TextEditor extends Frame { Button myButton; public TextEditor() { ... setTitle("Text Editor") setLayout(new BorderLayout()); setBackground(Color.orange); myButton = new Button("Hit This"); add("Center", myButton); pack(); show(); } public boolean handleEvent(Event evt) { if("Hit This".equals(evt.arg)) { System.out.println("He hit me"); return true; } } } This is another method of event handling. The event is handled in the Component rather than the Container. First we must sub-class Button. public class MyButton extends Button { ... ... public boolean action(Event evt, Object arg) { if(evt.target == this) { System.out.println("He hit me"); return true; } } } public class AnotherTextEditor extends Frame { MyButton anotherButton; public AnotherTextEditor() { setTitle("Another Text Editor") setLayout(new BorderLayout()); setBackground(Color.white); anotherButton = new MyButton("Hit This"); add("Center", anotherButton); pack(); resize(300, 300); show(); } } All Containers have common functionality, due to the fact they are derived from Container which includes many pre-defined event handling methods(called callbacks). These events are useful for handling user input in a specialized(i.e sub-class or derived) Container class where you'd override the default behavior such as the appearance(i.e font, color, etc.) by overriding the methods. A quick-and-dirty summary of common methods: add(Component) add(String, Component) remove(Component) getComponents() setLayout(LayoutManager) getLayout() Every Container Is-A Component since it is derived from Component, thus it can also behave and be used like an Component. All of the methods in Component can be used in a Container. Components Components are generally the stuff that the user interacts with. The meat and potatoes of your application. You'll need to display Windows and Buttons. You'll want Lists within Windows. You'll want the user to enter some text/input. You'll want easy access to features and functions. Components will do that for you. Components are Buttons, TextAreas, Scrollbars, etc. in other words the visible UI controls that the user interacts with, all of which have been added to a Container. Anything that is derived from the class Component can be one. p A quick-and-dirty summary of common methods: getBackground() setBackground(Color) getFont() setFont(Font) mouseDown(Event, int, int) show() resize(int, int) paint(Graphics) update(Graphics) move(int, int) Layouts: How Components are "laid out" within a Container is described by the LayoutManager class. Since the LayoutManager class is abstract, we can not use it directly. You must sub-class it and provide your own functionality or use a derived class of LayoutManager(i.e BorderLayout, CardLayout, GridLayout, etc) already created for you. There are man different layout schemes, but the ones pre-defined for us are BorderLayout This scheme lays out the Component in 5 ways 1. North - Northern part of the Container 2. South - Southern part of the Container 3. East - Eastern part of the Container 4. West - Western part of the Container 5. Center - Centered in the Container CardLayout - Allows for what Windows programmers have called for years "tabbed dialogs" or dynamic dialogs(now available on all versions of Netscape). GridLayout - Allows for the layout of Components in a grid -like fashion rather than "North" or "Center". GridBagLayout - HTMLTable-ish style of layout FlowLayout - Allows for Component to be laid out in a row(or flow) and aligned(left, right, center). None - No layout, the Container will not attempt to reposition the Components during a update. To use a layout we must call setLayout() for the Container with an instance of a LayoutManager(since LayoutManager is abstract, a sub-class will do). Using each layouts is different. For BorderLayout you specify the type of layout(North, South, etc.) by passing a string(i.e "North", "South", etc to the method add() in a Container. i.e add("Center", myComponent); adds myComponent to the Container and centers it. With other layouts, the first String parameter is different. Using Components and Containers Like all Java classes, to use a class from the AWT we need to create an instance of it via "new". add(new Button("Hello")); Button b = new Button("World"); add(b); The first add creates a new instance of a Button before adding it to the Container. To a C++ programmer, this is bizarre. "new Button" never gets assigned to a variable, so you can't delete it. When do you delete the Button? Never. Java has automatic garbage collection and will free the memory up when the Button is no longer used(i.e b = null and calling gc() may remove it). You can handle events given the label of the Component, thus new Button("Hello") makes perfect sense to a Java programmer. The second add(), adds the previously created component 'b'(a Button) to the Container. Event handling Event-handling? Geez don't I just poll and grab user-input? No, this is Java and how the GUIs it runs under operate. GUIs and Windowing systems use the event-driven model rather than the old procedural-grab-the-input-yourself model. The OS is the one polling for events. When it finds ones, it tells you what has happened. If you say, "bah, I don't care about that event". Fine, the OS handles it with its own default handler, otherwise you better do something with it or you get the default, which maybe nothing at all. Here are the some of the events you will need to handle. This list of all events your application will probably need to handle is in the Event's class documentation. 1. 2. 3. 4. ACTION_EVENT MOUSE_DOWN KEY_PRESS WINDOW_DESTROY ACTION_EVENT occurs when you press a button, select a menu, etc. To handle ACTION_EVENT you have two choices 1. Handle it handleEvent() 2. Handle it in action() Both are located in the Component class so all derived classes have these methods and you should override them to provide your own custom behavior. The following examples shows you how and why... public boolean handleEvent(Event evt) { switch(evt.id) { case Event.ACTION_EVENT: { if((Hey I've been hit " + n + "times).equals(evt.arg)) { return true; } // Here evt.target contains the target // i.e java.awt.MenuItem[label=Quit] // evt.arg contains the label of the button pressed // or menu item hit } default: return false; } } The same thing came be accomplished with action(evt, arg), because when an ACTION_EVENT occurs action() is called. public boolean action(Event evt, Object arg) { if(("Hey I've been hit " + n + "times").equals(arg)) { return true; } return false; } As you can see, even if the labels change you can still receive the event. The above is a button that changes everytime you hit it. But this isn't the only way to handle events. In fact you can compare objects instead of labels such as if(evt.target == myButton). public boolean handleEvent(Event evt) { switch(evt.id) { // Examples of what can be handled case Event.KEY_PRESS: case Event.HOME: case Event.WINDOW_MOVED: return true; // ... default: return false; } } Also you can override a sub-class's method handler such as keyDown(), mouseDown() to provide your own event handling code. For example a specialized(sub-class) version of a TextArea that overrides mouseEnter() can determine when the mouse enters the Component and thus can decide to hilight the text if needed.