bundles/org.eclipse.platform.doc.isv/guide/jface.htm - platform/eclipse.platform.common - Git at Google

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML>
 <HEAD>
 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
 <META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">

 <LINK REL="STYLESHEET" HREF="../book.css" CHARSET="ISO-8859-1" TYPE="text/css">
 <TITLE>JFace UI framework</TITLE>

 <link rel="stylesheet" type="text/css" HREF="../book.css">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
 <H1>JFace: UI framework for plug-ins</H1>
 <P >
 The workbench defines extension points for plug-ins to contribute UI function to the platform. Many of these extension points,
 particularly wizard extensions,&nbsp; are implemented using classes in the
 <b>
 org.eclipse.jface.*</b> packages. What's the distinction? </P>
 <P >
 JFace is a UI toolkit that provides helper classes for developing UI features
 that can be tedious to implement. JFace operates above the level of a raw widget system. It provides classes for handling common UI programming tasks:</P>
 <ul>
   <li>
 <b>
 Viewers</b> handle the drudgery of populating, sorting, filtering, and updating widgets.</li>
   <li>
 <b>
 Actions</b> and <b> contributions</b> introduce semantics for defining user actions and specifying where to make them available.</li>
   <li>
 <b>
 Image</b> and <b> font registries</b> provide common patterns for handling UI resources.</li>
   <li>
 <b>
 Dialogs</b> and <b> wizards</b> define a framework for building complex interactions with the
 user.</li>
 </ul>
 <P >
 JFace frees you up to focus on the implementation of your specific
 plug-in's function, rather than focusing on the underlying widget system or solving problems that are common in almost any UI application. </P>

 <h2>
 JFace and the workbench</h2>
 <P >
 Where does JFace end and the workbench begin? Sometimes the lines aren't so obvious. In general, the JFace APIs (from the packages
 <b>org.eclipse.jface.*</b>) are independent of the workbench extension points and APIs. Conceivably, a JFace program could be written without using any workbench code at all.</P>
 <P >
 The workbench makes use of JFace but attempts to reduce dependencies where possible. For example, the workbench part model
 (<a href="../reference/api/org/eclipse/ui/IWorkbenchPart.html"><b>IWorkbenchPart</b></a>)
 is designed to be independent of
 JFace. We saw earlier that views and editors can be implemented using SWT widgets directly without using any JFace classes. The workbench attempts to remain &quot;JFace neutral&quot; wherever possible, allowing programmers to use the parts of JFace they find useful. In practice, the workbench uses JFace for much of its implementation and there are references to JFace types in API definitions. (For example, the JFace interfaces for
 <b><a href="../reference/api/org/eclipse/jface/action/IMenuManager.html">IMenuManager</a></b>,
 <b><a href="../reference/api/org/eclipse/jface/action/IToolBarManager.html">IToolBarManager</a></b>, and
 <b><a href="../reference/api/org/eclipse/jface/action/IStatusLineManager.html"> IStatusLineManager</a></b> show up as types in the workbench
 <b><a href="../reference/api/org/eclipse/ui/IActionBars.html">IActionBar</a></b>
 methods.)</P>


 <h2>JFace and SWT</h2>
 <P >
 The lines between SWT and JFace are much cleaner. SWT does not depend on any JFace or platform code at all. Many of the SWT examples show how you can build a standalone application. </P>
 <P >
 JFace is designed to provide common application UI function on top of the SWT
 library. JFace does not try to &quot;hide&quot; SWT or replace its function. It provides classes and interfaces that handle many of the common tasks associated with programming a dynamic UI using
 SWT.</P>
 <P >
 The relationship between JFace and SWT is most clearly demonstrated by looking at viewers and their relationship to SWT widgets.</P>

 <p><a href="../hglegal.htm"><img border="0" src="../ngibmcpy.gif" alt="Copyright IBM Corporation and others 2000, 2003." border="0" width="324" height="14"></a></p>

 </BODY>
 </HTML>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML>
	<HEAD>
	<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
	<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">

	<LINK REL="STYLESHEET" HREF="../book.css" CHARSET="ISO-8859-1" TYPE="text/css">
	<TITLE>JFace UI framework</TITLE>

	<link rel="stylesheet" type="text/css" HREF="../book.css">
	</HEAD>
	<BODY BGCOLOR="#ffffff">
	<H1>JFace: UI framework for plug-ins</H1>
	<P >
	The workbench defines extension points for plug-ins to contribute UI function to the platform. Many of these extension points,
	particularly wizard extensions,  are implemented using classes in the
	<b>
	org.eclipse.jface.*</b> packages. What's the distinction? </P>
	<P >
	JFace is a UI toolkit that provides helper classes for developing UI features
	that can be tedious to implement. JFace operates above the level of a raw widget system. It provides classes for handling common UI programming tasks:</P>
	<ul>
	<li>
	<b>
	Viewers</b> handle the drudgery of populating, sorting, filtering, and updating widgets.</li>
	<li>
	<b>
	Actions</b> and <b> contributions</b> introduce semantics for defining user actions and specifying where to make them available.</li>
	<li>
	<b>
	Image</b> and <b> font registries</b> provide common patterns for handling UI resources.</li>
	<li>
	<b>
	Dialogs</b> and <b> wizards</b> define a framework for building complex interactions with the
	user.</li>
	</ul>
	<P >
	JFace frees you up to focus on the implementation of your specific
	plug-in's function, rather than focusing on the underlying widget system or solving problems that are common in almost any UI application. </P>

	<h2>
	JFace and the workbench</h2>
	<P >
	Where does JFace end and the workbench begin? Sometimes the lines aren't so obvious. In general, the JFace APIs (from the packages
	<b>org.eclipse.jface.*</b>) are independent of the workbench extension points and APIs. Conceivably, a JFace program could be written without using any workbench code at all.</P>
	<P >
	The workbench makes use of JFace but attempts to reduce dependencies where possible. For example, the workbench part model
	(<a href="../reference/api/org/eclipse/ui/IWorkbenchPart.html"><b>IWorkbenchPart</b></a>)
	is designed to be independent of
	JFace. We saw earlier that views and editors can be implemented using SWT widgets directly without using any JFace classes. The workbench attempts to remain "JFace neutral" wherever possible, allowing programmers to use the parts of JFace they find useful. In practice, the workbench uses JFace for much of its implementation and there are references to JFace types in API definitions. (For example, the JFace interfaces for
	<b><a href="../reference/api/org/eclipse/jface/action/IMenuManager.html">IMenuManager</a></b>,
	<b><a href="../reference/api/org/eclipse/jface/action/IToolBarManager.html">IToolBarManager</a></b>, and
	<b><a href="../reference/api/org/eclipse/jface/action/IStatusLineManager.html"> IStatusLineManager</a></b> show up as types in the workbench
	<b><a href="../reference/api/org/eclipse/ui/IActionBars.html">IActionBar</a></b>
	methods.)</P>


	<h2>JFace and SWT</h2>
	<P >
	The lines between SWT and JFace are much cleaner. SWT does not depend on any JFace or platform code at all. Many of the SWT examples show how you can build a standalone application. </P>
	<P >
	JFace is designed to provide common application UI function on top of the SWT
	library. JFace does not try to "hide" SWT or replace its function. It provides classes and interfaces that handle many of the common tasks associated with programming a dynamic UI using
	SWT.</P>
	<P >
	The relationship between JFace and SWT is most clearly demonstrated by looking at viewers and their relationship to SWT widgets.</P>

	<p><a href="../hglegal.htm"><img border="0" src="../ngibmcpy.gif" alt="Copyright IBM Corporation and others 2000, 2003." border="0" width="324" height="14"></a></p>

	</BODY>
	</HTML>