Development system with application browser user interface6247020Abstract A component-based, rapid application development (RAD) Java environment providing an improved user interface is described. The interface includes a single Application Browser or "AppBrowser" that is used to perform all the usual development functions. The AppBrowser lets the user explore, edit, design, and debug all in one unified window. Serving as a mechanism for hosting arbitrary documents or other objects related to development, the AppBrowser presents the documents or other objects for manipulation in a window that consists of three panes: Navigation pane, Content pane, and Structure pane. In general, the Navigation pane displays a list of documents, the Content pane displays the document itself, and the Structure pane displays the structure of the document if available. The grouping of the three panes exists on a browser "context" or mode. Multiple contexts can appear on an AppBrowser represented by a tab in a tab set at the lower left of the window. These contexts add a 3D feel to AppBrowser by layering its functionality in one window rather than spread across multiple windows. Switching between completely different contexts is then as easy as selecting a tab. The AppBrowser may have different logic for any given context that is global across the three panes; the logic is provided by implementing a standard browser context interface. Claims What is claimed is: Description COPYRIGHT NOTICE
Menu Commands for
File menu Creating, opening, closing, renaming and saving files and
projects;
removing files from projects; configuring printers; printing
files.
Edit menu Copying, pasting, deleting and selecting text; undoing and
redoing
actions.
Search menu Finding and replacing text; searching for text incrementally
and by line
number; searching for text across a source path; searching
for a
symbol.
View menu Viewing Debugger windows, a new AppBrowser, the next or
previous
error message, the tool bar or the Component Palette.
Build menu Making or building the selected node.
Run menu Running the application or applet; stepping over or tracing
into code;
running to the end of a selected method; pausing the program;
setting
watches or breakpoints; inspecting, evaluating and modifying.
Wizards menu Running utility wizards for tasks such as implementing an
interface,
overriding a method, bundling resources, and wrapping an
applet.
Tools menu Displaying the Environment Options dialog; invoking the
Windows
Notepad and Calculator and other internal tools.
Help menu Displaying documentation, such as the Help system, a
BeansExpress
tutorial for creating Java Bean components, the JDK API
Reference,
and the JBCL API Reference. Also for viewing Online web site
in the
user's default web browser, loading the Welcome project for
experimenting, and seeing information about this release of
product.
Working in conjunction with the main menu, tool bar 363 provides the user with shortcuts to the most common commands from the main menu for commonly performed tasks, such as opening and saving a project; creating a new application; building, compiling and debugging; undoing an action; and searching and replacing text. The tool bar is configurable by the user for including icons for most of the menu commands. In an exemplary embodiment, the following are provided.
Button Commands for
File.vertline.Open Opens a project, file, or package.
File.vertline.Close Closes the active window.
File.vertline.Save File Saves the active file.
File.vertline.Save Project Saves the current project and all changed files
that are shown in the
system's project tree.
Edit.vertline.Undo Reinserts any characters deleted, deletes any characters
inserted,
replaces any characters the user overwrites, or moves the
cursor back
to its prior position.
Edit.vertline.Redo Reverses the effects of an Undo.
Search.vertline.Find Searches for text within the active file.
Search.vertline.Replace Replaces specified text with other specified text
in the current file.
Search.vertline.Search Again Finds the next occurrence of a search string
in the current file.
Search.vertline.Browse Loads the specified class into the AppBrowser. The
class must be on
the imports path of the current file.
Run.vertline.Run Compiles and runs the application using the startup
parameters in the
Parameters dialog box.
Run.vertline.Debug Compiles the program and runs it in the Debugger using
the startup
parameters in the Parameters dialog box.
Build.vertline.Make Compiles any .java files within the selected node that
have outdated or
nonexistent .class files. Also compiles any of the node's
imported files
that the node depends on which have outdated or nonexistent
.class
files.
Build.vertline.Rebuild Compiles all .java files within the selected node,
regardless of whether
their .class files are outdated. Also compiles the imported
files upon
which the node depends, regardless of whether their .class
files are
outdated.
By placing the mouse pointer over the tool bar buttons, without clicking, the user can view flyover labels of the buttons. The component palette 364 displays components available in the Borland JBuilder component library. Components are the elements which a user employs to build his or her applications. They include all of the visible parts of an application, such as dialog boxes and buttons, as well as those which are not visible while the application is running (e.g., system timers). In the programming environment 360, components are grouped functionally on different pages of the component palette 364. Each functional group is identified by a tab member, which includes a label indicating the particular nature of the group. The palette can incorporate user-created custom controls, which the user installs onto the palette. Additionally, the user can install third-party components. Further description of Borland JBuilder.TM. is provided by the following manuals (available from Borland International, Inc. of Scotts Valley, Calif.): JBuilder User's Guide (Part No. JBA1310WW21770), JBuilder Programmer's Guide (Part No. JBA1310WW21771), and Java Beans Component Library Reference Volumes 1&2 (Part Nos. JBA1310WW21772 and JBA1310WW21773). The disclosures of the foregoing are hereby incorporated by reference. When the user first opens the IDE, the system also displays an Application Browser user interface or "AppBrowser" 370 of the present invention. The following description will focus on those features of the development system 200 which are helpful for understanding methods of the present invention for implementing an application browser user interface in the visual development environment. Application browser (AppBrowser) user interface A. General The system's user interface is structured to increase one's productivity, particularly when developing in Java. Because Java projects use many files, and because the various development tasks (such as editing, debugging, and browsing for information) have traditionally used multiple windows, it can be difficult to find the window one needs. To simplify one's job, therefore, the present invention introduces a new concept in user interfaces for development environments: a single Application Browser or "AppBrowser" that is used to perform all the usual development functions. The AppBrowser, which is shown in particular detail at 400 in FIG. 4A, lets the user explore, edit, design, and debug all in one unified window. Serving as a mechanism for hosting arbitrary documents related to development, the AppBrowser 400 presents the documents (or other objects) for manipulation in a window that consists of three panes: Navigation pane 410, Content pane 450, and Structure pane 430. In general, the Navigation pane 410 displays a list of documents, the Content pane 450 displays the document itself, and the Structure pane 430 displays the structure of the document if available. The grouping of the three panes exists on a browser "context". Multiple contexts can appear on an AppBrowser represented by a tab in a tab set at the lower left of the window. These contexts add a 3D feel to AppBrowser by layering its functionality in one window rather than spread across multiple windows. Switching between completely different contexts is then as easy as selecting a tab. The AppBrowser may have different logic for any given context that is global across the three panes; this logic is provided by implementing a standard browser context interface. Each of the three panes has specific behaviors which will now be described. B. Navigation pane The Navigation pane 410 displays a tree 411 comprising a single parent node that may have children. The parent may or may not be visible but the children always are. Each child may also be a parent of other arbitrary nodes. An example of a parent node would, for instance, include a development project with its children being files within the project or folders containing other files. Actions allowed in the Navigation pane include the selecting of a current node which, in turn, synchronizes the Content and Structure panes to point to the same node. The nodes in the Navigation pane may also present menu items on the main window, context menus, or tool bar buttons on the AppBrowser's local tool bar. A node may also decide to change the root parent of the Navigation pane to another node (i.e., "Drilling Down"). When a new node is set as the main parent node of the Navigation pane, it is added to a history list of visited parent nodes. This history list is navigated using Home, Previous, and Next buttons shown at 405, at the top of the Navigation pane. The Home button goes to the first node in the history list; the Previous and Next buttons incrementally travel backward and forward in the list. Nodes that are able to be used in the Navigation pane implement standard interfaces (ANT or Addon Node Type nodes). ANT nodes that are available for the system to use are provided by the host of the AppBrowser window or by addins to the system. C. Content pane The actual view of the current node (from the Navigation pane) is shown in the Content pane 450. For instance, if the user selects a Java file in the Navigation pane, the source code for the file is displayed ready for editing in the Content pane. As shown at 451, the Content pane includes tabs which control the kind of viewer or editor used in the Content pane. The actual view displayed may take different concurrent forms. Examples include the Editor (Source tab), the UI Designer (Design tab), and Documentation Viewer (Doc tab). Other available viewing contexts or modes of the Content pane are HTML (HyperText Markup Language) Browser (View tab) and Image Viewer (Viewer tab). The views may be layered in the pane. The layering of views for a node is shown as tabs within a tab set at the bottom of the Content pane. An example of content layering would be that an HTML file which has both a WYSIWYG editor and an HTML editor for the HTML source code. These would each be represented by tabs that can then be selected by the user. The Content pane displays the detailed content of the file selected in the Navigation pane with the actual editor or viewer being used is determined by the file's extension, as shown in the following table.
File Type Editor(s) or Viewer(s) available in the Content pane
Text files If the user selects a text file in the Navigation pane (a file
with an extension such as .txt or
.bat), a single editor, identified by the Source tab, is
available in the Content pane. This is a
simple text editor that lets one see and modify the text file.
JBuilder recognizes certain file
extensions (such as .txt and .bat) as text files. However, the
user can extend this list.
Image files If the user selects a .GIF, .JPG, or .BMP image file in the
Navigation pane, an image
viewer, identified by the View tab, is available in the Content
pane.
HTML files If the user selects an HTML file in the Navigation pane, two
tabs are displayed at the
bottom of the Content pane, labeled View and Source.
View tab
The View tab selects an HTML viewer. This viewer lets
the user see the
rendered HTML flle, as the user would see it in a web
browser.
Source tab
The Source tab selects an Editor that lets the user
see and edit the file as raw
HTML source.
.java files If the user selects a .java file in the Navigation pane, the
system displays three tabs labeled
Source, Doc, and Design.
Source tab
If the user selects the Source tab when viewing a
.java file, the system will
display the JBuilder Java Source Code Editor. This is
a full-featured,
syntax-highlighted programming editor, with several
popular key mappings.
Doc tab
If the user selects the Doc tab when viewing a .java
file, the system will display
the corresponding reference doc for that .java file,
if there is one. Java supports
a documentation standard called JavaDoc that
automatically generates HTML
documentation pages from .java source code and
comments.
JBuilder has produced an enhanced version of JavaDoc,
called JBDoc. JBDoc
produces HTML files that show additional information
about JavaBeans
properties, methods and events. JBuilder comes with
JavaDoc or JBDoc HTML
pages installed for the following:
JavaSoft packages (JavaDoc)
Borland JBuilder (borland.jbcl) packages (JBDoc)
Selected third-party packages
If the user clicks on the Doc tab for any of these
provided java files, will view
the HTML documentation page for the class.
Design tab
If the user selects the Design tab when viewing a java
file, the system will
display the JBuilder visual design tools for that
class. For example, if the user
selects the WelcomeFrame.java class in the Welcome
project (or a Frame class
in the user's own project), the system will display
the JBuilder UI Designer in
the Content pane. This designer will show the user
what the UI appearance of
this class will be at run-time, and lets the user
visually construct and develop
the user's UI.
The user can expand the Content pane to fill the entire AppBrowser window. The user simply toggles it in and out of full window mode with the View.vertline.Toggle Curtain menu command or with the keyboard accelerator indicated on that menu (Alt+Z key in the default key mapping). The user can also use the mouse to resize the window or any of its panes by dragging the pane boundaries. Internally, the viewers used in the Content pane implement a standard interface. The ANT node used in the Navigation pane provides a list of viewers to be used when selected. Viewers can also be provided via addins to the system. Viewers used in the Content pane can respond to navigational requests called Anchors. An anchor represents a location within a view that can be tracked such as a line number in a source file or an HTML anchor in an HTML document. Viewers in the Content pane have access to a status bar that is common to all viewers in this pane. The status bar has multiple status areas that can be written to. They also can provide menu items to the system's menu, a local tool bar for the Content pane, or context menus. D. Structure pane The Structure pane of the AppBrowser shows a structural analysis of the file that the user has selected in the Navigation pane. When the user has selected a java file and then selects the Design tab at the bottom of the Content pane, the Structure pane displays the designable objects in the file, and how they are nested and interrelated. For example, if one selects a java file, the Structure pane shows structural information about the java code in that file, such as Imported packages. The classes and/or interfaces in the file. Any ancestor classes and/or interfaces. Variables and methods. This structural analysis is in the form of a hierarchical tree, resembling a table of contents for the file. This tree view is called the "Component Tree." The Structure pane facilitates user navigation of source files. Not only does the Structure pane show the user the structure of the file, the user can also use it as a quick navigation tool to the various structural elements in the file. For example, if the user has selected a java file, the system displays classes, variables, and methods for the file in the Structure pane. The user can then click on any of those elements in the Structure pane and the Content pane will move to and highlight that element in the source code. As illustrated in FIG. 4B, for instance, selection of a button bar tag 463 in the Structure pane automatically causes the Content pane to display the corresponding source code line 461, corresponding to that selected tag. Specifically, the Content pane moves automatically to the place in the Java source file where the object is declared. This gives the user a much faster way to browse and find the elements of a java file than scrolling through it or searching for a word. The user can also use the Structure pane for "drilling down" into other ancestor classes and interfaces. Internally, the Structure pane shows one or more representations of the structure of the current node. The node may have different "flavors" of its structure depending on the current viewer. At the time a node is selected in the Navigation pane, the Structure pane will ask the current viewer for the type of structure anchors it expects and will display a matching structure tree that is created by the ANT node in the navigation pane. Examples of structure include a list of the HTML anchors and links within an HTML document or the tree of classes and their data members and methods found in a Java source file. The selection of a structure node (anchor) will cause its anchor to be passed to the current viewer of the Content pane which will then navigate the view of the node to a specific location. In the case of Java source files, selecting a method in the Structure pane causes the system to navigate the source file displayed in the Content pane to the line starting the declaration of the method. Structure nodes can provide menu items to the system's menu, context menus, and can support "drilling down" into a new root parent node for the Navigation pane. For example, "drilling down" into a link from an HTML node causes the Navigation pane to show the new document as its root node and add it to the history list. E. AppBrowser contexts The AppBrowser operates in several different contexts or modes. Each context is accessed by selecting one of the tabs in the lower right-hand corner of the AppBrowser. Different contexts will now be described. 1. Project context The Project context, shown at 510 in FIG. 5A, is the default context and is the context which the user will employ most often. It comes up automatically if the user does not click any of the AppBrowser's tabs. In Project context, the Navigation pane shows a tree of all the files the user has put into his or her project, with the main project (jpr) file at the root, and the other files (Java source files, image files, HTML files, and so on) in the branches. 2. Opened Files context To keep certain files close at hand, the user puts them in a list in an Opened Files context, shown at 520 in FIG. 5B. The Opened tabbed page provides a list of currently active or open files. These include files that the user has edited in the current AppBrowser session as well as files that the user explicitly dropped onto the Opened tab from the Directory or Project tabs. Thus to add a file to the Opened Files list, the user simply drags it to the Opened tab at the bottom of the AppBrowser (which is showing even when the AppBrowser is in Project context). The user can even drag a file from another AppBrowser's Project context, when more than one AppBrowser is opened. In this manner, the user can gain quick access to files from the Opened Files context. 3. Directory context The Directory context, shown at 530 in FIG. 5C, is where the user obtains a tree view of the file directory of the user's system. The view is optimized for Java projects, by showing only certain kinds of files relevant to Java projects and hiding all the others. 4. Hierarchy context To invoke the Hierarchy context, the user right clicks the name of any Java file or Java package in the Navigation pane (while in the Project context, the Opened Files context, or the Directory context). This action causes the system to display a pop-up menu with a Class Hierarchy option, as shown at 610 in FIG. 6A. Upon the user selecting that option, the AppBrowser displays a new tabbed page with a list showing the Java file or Java package that the user chose, plus all its ancestors among the Java classes. This is illustrated in FIG. 6B at 620. Here, the user can see inheritance relationships among classes. For a given class, for instance, the user can determine which class it extends from, which class is its parent, which class is its grandparent, and which methods it inherits from its ancestors. As shown in FIG. 6C at 630, the user can easily select among different files and packages. 5. Search context To invoke the Search context, the user selects from the main JBuilder menu Search Source Path. The system displays a dialog box asking the user what terms to search for. After the user has completed input, the system finds all the files with the search word in them and displays their names in the Navigation pane (in a tree). Now, the user can select any file name in this new Navigation pane, to see the Java source code in the Content pane. F. Drilling down into other classes and interfaces Often the user will need to look at java files that are not part of the user's project, but which are referred to in the class the user is editing. This might be an ancestor class or the class of some instance variable. There are several traditional ways the user could navigate to the file needed. If the user knows the full package and class name, he or she could open it in a separate browser (File.vertline.Open/Create), browse for it using Search.vertline.Browse Symbol, or use the Directory Browser to look for it on the disk. The Structure pane provides a much faster way, however. To see the java file for an ancestor class, an interface, or the type of a variable shown in the Structure pane, the user just double-clicks it in the AppBrowser. In turn, the AppBrowser will immediately go to that file, showing it in all three panes. This is illustrated in FIGS. 7A-C. In FIG. 7A, the user has opened a project (e.g., Welcome Project) and selected WelcomeFrame java in the Navigation pane, as shown at 710. In the Structure pane, note that WelcomeFrame extends DecoratedFrame, as shown at 713. Upon the user double-clicking DecoratedFrame in the Structure pane, the AppBrowser shows DecoratedFrame, as illustrated in FIG. 7B. Note particularly that DecoratedFrame is shown in all three panes 720a, 720b, and 720c. Continuing with the example, upon the user double-clicking Frame at 721, the system "drills down" another level into the Frame parent class of DecoratedFrame, as shown by panes 730a, 730b, and 730c in FIG. 7C. Note that not only is the source of the Frame class shown (at 730c), but the user can also click on the Doc tab and read the reference doc for the class as well. If the user navigates to a file for which no source code is found, the system will synthesize a temporary source file to show in the Source pane. This temporary file contains method stubs for corresponding public methods. The temporary stub file displays method signatures for public methods and comments indicating that no implementation information is available. The stub source is only generated temporarily in memory, and it is not saved to disk. A Doc tab is also displayed that shows the reference HTML doc for the class. G. Methodology summarized FIG. 8A is a flow chart summarizing the general methodology of the present invention. At step 801, the user opens a project, which is associated with a particular application project (e.g., Java project) under development. At step 802, the system enumerates the various members (e.g., files) and relationships thereof, for the project. Based on this determination, the system can now display a hierarchical view (e.g., tree) of the project in the navigation pane, as indicated at step 803. At step 804, the system gets the currently selected node in the navigation pane; node selection is affected by use of the navigation buttons (e.g., forward, back, and home buttons). From this, the system can determine the actual document or object (for the selected node), as indicated at step 805. At step 806, the system enumerates the view(s) for the selected document or object. Based on these determined views, the system populates the content pane with tabs (i.e., labels corresponding to the different view types), and displays a current view (i.e., content). The user switches to a particular view by selecting its tab. As indicated at step 808, the system proceeds to enumerate the designable elements (i.e., subobjects) and relationships thereof for the selected document or object. Now, at step 809, the system can proceed to display a hierarchical view of these elements in the structure pane. Thereafter, the method can loop back to step 804 to refresh the panes for a newly selected node (i.e., a new node selected by the user), or terminate in the event that the user has finished. FIG. 8B is a block diagram illustrating synchronization among the different panes. As shown, navigation pane 851 displays the project hierarchy. Upon the occurrence of a user event in the navigation pane (e.g., the user selects a new node), the content pane 853 and the structure pane 855 update the display of their respective information, based on the newly selected node. In a similar manner, the content pane 853 and the structure pane 855 maintain synchronization for user events in those panes. For instance, if the user selects a particular node in the structure pane 855 (e.g., the user selects a particular method or property of an object), the content pane 853 updates display of the particular information associated with that selected structure node, such as displaying a particular source code line relevant to that selected node. In a corresponding manner, selection of a particular line of code in the content pane 853 triggers synchronization of the structure pane 855, so that the structure pane displays the appropriate node for the element or object in the currently selected line of source code. While the invention is described in some detail with specific reference to a single-preferred embodiment and certain alternatives, there is no intent to limit the invention to that particular embodiment or those specific alternatives. Thus, the true scope of the present invention is not limited to any one of the foregoing exemplary embodiments but is instead defined by the appended claims.
|
Same subclass Same class Consider this |
||||||||||
