All Packages from com.port80.eclipse.perl.* to com.port80.eclipse.xml.*

Home >> All >> com >> port80 >> eclipse

Page 1 2

•

Package Samples:

• com.port80.eclipse.util
• com.port80.eclipse.util.antlr
• com.port80.eclipse.util.widgets
• com.port80.eclipse.xml.editors
• com.port80.eclipse.xml.parser
• com.port80.eclipse.xml.properties
• com.port80.eclipse.xml.util
• com.port80.eclipse.perl.editors
• com.port80.eclipse.perl.editors.scanner

Classes:

• RegionContentFormatter: Standard implementation of IContentFormatter . The formatter supports two operation modi: partition aware and partition unaware. In the partition aware mode, the formatter determines the partitioning of the document region to be formatted. For each partition it determines all document positions which are affected when text changes are applied to the partition. Those which overlap with the partition are remembered as character positions. These character positions are passed over to the formatting strategy registered for the partition's content type. The formatting strategy returns a string containing ...
• FileDependGraphAction: Depend Graph depicts the source file and class file type reference relationships. For source file, all types in the source file are grouped into one node. For binary class file, nested class are grouped to the node for their enclosing class. Reference is depicted by an edge to the referenced type/file. To make the graph more readable, edge from an inherited type is removed if its super class/interface exists in the graph and already has an edge to the same destination. Type are represented by vertex. The vertex name is the absolute file path for source type and fully qualified typename + ".java" ...
• MethodView: Show methods of a type including methods inherited from super classes. This is similar to the Outline view except that it shows only methods and it shows non-private methods from the super classes even though they are not overriden. So user can knows what methods are available. This sample class demonstrates how to plug-in a new workbench view. The view shows data obtained from the model. The sample creates a dummy model on the fly, but a real implementation would connect to the model available either in this or another plug-in (e.g. the workspace). The view is connected to the model using a content ...
• AnnotationManager: Data model for AnnotationView. Annotation keep the set of visited IResources together with access information. It kept all visited objects automatically upon visiting instead of manually by user. It can be used to backtrace visit history. It can be further bookmark or annotated by user. This is an enchancement of the BookmarkView which, unfortunately as of Eclipse 2.0, cannot bookmark binary classes and it is not easy for annotation. AnnotationManager also works without the AnnotationView active and manage only the visited object list and its related actions.
• DependGraphAction: Extract an method call graph in UML like format for a given set of classes ( 'selected' objects). Each vertex represent either a caller or a callee. Caller is a method or a class labelled with method that calls external methods. Callee is method that is called by a caller. Edges of type '-hasCalls' represent calls from the caller vertex to the callee vertex. Edges of type '-typehier' represent type herierhical from superclass to derived classes. Edges of type '-implemented' represent that the head vertex (method) implements tail vertex (interface).
• ScopeStack: Scope stack is used by the parser to keep track of the current lexical scopes and performs symbol lookups. . Scope stack from bottom to top: RootContext scope CompilationUnit scope TopLevelClass scope class/block/method...etc. scopes ... . When a variable is encountered in the statement, its type is determined by searching the scopes from the top of the scope stack downwards until it found the variable declaration/definition. If a scope belongs to an IType (parent!=null), IType would search the super-class and/or super-interfaces.
• IScopeStack: Scope stack is used by the parser to keep track of the current lexical scopes and performs symbol lookups. . Scope stack from bottom to top: rootNode scope compilationUnit scope topLevelClass scope class/block/method...etc. scopes ... . When a variable is encountered in the statement, its type is determined by searching the scopes from the top of the scope stack downwards until it found the variable declaration/definition. If a scope belongs to a classs (parent!=null), ASTClassNode would search the superclasses and interfaces.
• PersistentItem: Wrapper around object to make it a tree item and persistable. Currently, valid objects that can be persisted are IType, IMethod, other object type are not persisted. Each item is uniquely identified by its Kind, FullName, FullPath, Project. Items with the fields equal is the same item. When the presistable object is resolved to an actual object in the workspace, it is cached and subsequently return by getCached(). Use resolve() to force resolving again. Used by MethodView and WorkingSetView to save history objects.
• CSharpEditorPreferencePage: This class represents a preference page that is contributed to the Preferences dialog. By subclassing FieldEditorPreferencePage , we can use the field support built into JFace that allows us to create a page that is small and knows how to save, restore and apply itself. This page is used to modify preferences only. They are stored in the preference store that belongs to the main plug-in class. That way, preferences can be accessed directly via the preference store.
• CSharpEditorFormatterPreferencePage: This class represents a preference page that is contributed to the Preferences dialog. By subclassing FieldEditorPreferencePage , we can use the field support built into JFace that allows us to create a page that is small and knows how to save, restore and apply itself. This page is used to modify preferences only. They are stored in the preference store that belongs to the main plug-in class. That way, preferences can be accessed directly via the preference store.
• EditorsPreferencePage: This class represents a preference page that is contributed to the Preferences dialog. By subclassing FieldEditorPreferencePage , we can use the field support built into JFace that allows us to create a page that is small and knows how to save, restore and apply itself. This page is used to modify preferences only. They are stored in the preference store that belongs to the main plug-in class. That way, preferences can be accessed directly via the preference store.
• PerlEditorPreferencePage: This class represents a preference page that is contributed to the Preferences dialog. By subclassing FieldEditorPreferencePage , we can use the field support built into JFace that allows us to create a page that is small and knows how to save, restore and apply itself. This page is used to modify preferences only. They are stored in the preference store that belongs to the main plug-in class. That way, preferences can be accessed directly via the preference store.
• HTMLEditorPreferencePage: This class represents a preference page that is contributed to the Preferences dialog. By subclassing FieldEditorPreferencePage , we can use the field support built into JFace that allows us to create a page that is small and knows how to save, restore and apply itself. This page is used to modify preferences only. They are stored in the preference store that belongs to the main plug-in class. That way, preferences can be accessed directly via the preference store.
• XMLEditorPreferencePage: This class represents a preference page that is contributed to the Preferences dialog. By subclassing FieldEditorPreferencePage , we can use the field support built into JFace that allows us to create a page that is small and knows how to save, restore and apply itself. This page is used to modify preferences only. They are stored in the preference store that belongs to the main plug-in class. That way, preferences can be accessed directly via the preference store.
• CSSEditorPreferencePage: This class represents a preference page that is contributed to the Preferences dialog. By subclassing FieldEditorPreferencePage , we can use the field support built into JFace that allows us to create a page that is small and knows how to save, restore and apply itself. This page is used to modify preferences only. They are stored in the preference store that belongs to the main plug-in class. That way, preferences can be accessed directly via the preference store.
• MakefileEditorPreferencePage: This class represents a preference page that is contributed to the Preferences dialog. By subclassing FieldEditorPreferencePage , we can use the field support built into JFace that allows us to create a page that is small and knows how to save, restore and apply itself. This page is used to modify preferences only. They are stored in the preference store that belongs to the main plug-in class. That way, preferences can be accessed directly via the preference store.
• LLKEditorPreferencePage: This class represents a preference page that is contributed to the Preferences dialog. By subclassing FieldEditorPreferencePage , we can use the field support built into JFace that allows us to create a page that is small and knows how to save, restore and apply itself. This page is used to modify preferences only. They are stored in the preference store that belongs to the main plug-in class. That way, preferences can be accessed directly via the preference store.
• AntlrEditorPreferencePage: This class represents a preference page that is contributed to the Preferences dialog. By subclassing FieldEditorPreferencePage , we can use the field support built into JFace that allows us to create a page that is small and knows how to save, restore and apply itself. This page is used to modify preferences only. They are stored in the preference store that belongs to the main plug-in class. That way, preferences can be accessed directly via the preference store.
• JavaccEditorPreferencePage: This class represents a preference page that is contributed to the Preferences dialog. By subclassing FieldEditorPreferencePage , we can use the field support built into JFace that allows us to create a page that is small and knows how to save, restore and apply itself. This page is used to modify preferences only. They are stored in the preference store that belongs to the main plug-in class. That way, preferences can be accessed directly via the preference store.
• JdtPreferencePage: This class represents a preference page that is contributed to the Preferences dialog. By subclassing FieldEditorPreferencePage , we can use the field support built into JFace that allows us to create a page that is small and knows how to save, restore and apply itself. This page is used to modify preferences only. They are stored in the preference store that belongs to the main plug-in class. That way, preferences can be accessed directly via the preference store.
• CustomFontFieldEditor: Customized FontFieldEditor to save font spec. in family-style-size format since Eclispe-gtk-2.1.0 have problem creating fonts from the FontData. toString() internal spec. format. All we want to do is to override doStore and setToDefault which save persistent representation of the FontData to preference store. Unfortunately, FontFieldEditor.chosenFont is not accessible and so we have to cut and paste the whole FontFieldEditor class here.
• AnnotationView: A TreeViewer that shows content of the AnnotationModel. The View provides various filter and sorting functions for inspecting and searching in the Annotation. The Annotation machanism automatically maintain the set of IResource/IJavaElement visited in various way with access information. The Annotation can be used for backtracing to previous location and for annotation.
• IJavaCodeSymbol: Maps each terminal symbol in the java-grammar into a unique integer. This integer is used to represent the terminal when computing a parsing action. Disclaimer : These constant values are generated automatically using a Java grammar, therefore their actual values are subject to change if new keywords were added to the language (i.e. 'assert' keyword in 1.4).

Home | Contact Us | Privacy Policy | Terms of Service