For a custom Eclipse plugin, I've been looking into creating a perspective that will help organize views in a way that makes work easier for the editors, with the main requirement that we would like to simultaneously see two editor areas in the perspective.
Our plugin uses two new editor types: A "Workflow Editor" (WE) and a "Trial Editor" (TE) We would like to make sure that all instances of the WE are opened in one area of the perspective, and all in the TE are opened in a separate area.
Essentially, it looks like the perspective whose link is below, except that in place of the Java editing views in the top-right, we'd have the WE views, and in place of the text editing views in the bottom-right, we would have the TE views.
(http://dl.dropbox.com/u/4148918/eclipse-multi-editor.jpg)
I took a look at the tutorial on creating perspectives here: http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html . While this is a good start, it looks like by default perspective layouts only support one editor area, in which all editor views are opened:
public void defineLayout(IPageLayout layout) {
// Editors are placed for free.
String editorArea = layout.getEditorArea();
// Place navigator and outline to left of
// editor area.
IFolderLayout left =
layout.createFolder("left", IPageLayout.LEFT, (float) 0.26, editorArea);
left.addView(IPageLayout.ID_RES_NAV);
left.addView(IPageLayout.ID_OUTLINE);
}
How would one customize this layout such that it has two editor areas instead of one, each of which supports the editing of one distinct file type? While I have found a couple of online samples where the editor pane is split, these examples don't inherently support the automatic opening of one file type in one of the editors vs. the other, which is a desired feature for this plugin.
Alternatively, could one use 'folders,' and have instances of each editor open in these specialized folders? If so, what would be the entry point for defining new views associated with these editors, like those enumerated with "IPageLayout.ID_*" above?
Would much appreciate any advice someone has -- I think it's a cool problem to get two editors to show up simultaneously in different sections of an eclipse plugin, and it would be great if we could get it to work!
How would one customize this layout such that it has two editor areas instead of one, each of which supports the editing of one distinct file type?
You can't. As you've mentioned, you can only define one editor area in an Eclipse perspective.
You have two choices. Your first choice is to create your own multi page editor with a "Workflow Editor" (WE) on one page and a "Trial Editor" (TE) on the other page.
You second choice is to build an Eclipse workspace from the ground up with two (or more) editor areas. You can look through the Eclipse source for help, but you would basically be building your own Eclipse.
Related
In Lazarus, there are 2 different kinds of tab elements (cf. Free Pascal docs):
TPageControl
TPageControl is a multi-page component that provides a container to hold a variety of controls per page.
TTabControl
It is a tabbed container component which looks identical to a TPageControl. However, there is a fundamental difference because the control always shows the same page whichever tab is selected. In fact, it containts only a single page. The idea behind this concept is illustrated best by an editor or viewer for text files: When the TabControl contains a TMemo then the individual tabs refer to the files loaded into the memo; whenever the active tab changes another file is loaded into the (same) memo.
In this sense, JavaFX TabPanes are quite similar to TPageControls, but I rather want to replicate a TTabControl. I know I could in fact programmatically create a new Tab(), but I want to visually design it in SceneBuilder.
Is there maybe a way to load a separate .fxml file into a new Tab() element which is then added to the TabPane? (And how could I then access a tab's children?)
I chose the easiest approach: Implementing a head-less TabPane to detect when the user switches between tabs. The elements that appear to the user as the “tab content” are actually placed outside the TabPane, and their content is dynamically changed whenever the tab is switched.
I'm want to document the asymptotic runtime of a function, as it will be used for algorithm-engineering for graph problems.
What's the most idiomatic way to do this? Is there a way to create new tags in Javadoc like #return or #author?
I provided an example below, which is the method to delete a vertex in the graph.
/**
* Runtime: O( degreeOf(v) ) because every neighbour of [v] also needs to be updated.
*/
fun deleteVertex(v: V): SimpleGraph<V> {
if (v in m.keys) {
for (nb in m[v]!!)
m[nb]!!.remove(v)
m.remove(v)
}
return this
}
To create custom tags for Javadocs, simply follow these instructions.
You can create other customizations for Javadoc. For example, in Eclipse, you can create "templates" so that when you create new classes or add new methods, the IDE automatically apply this template to add a (Javadoc) comment formatted in the prescribed style of the template you applied. You can save these templates in an XML file so that you could share it with other members of your team. I am sure that IntelliJ and other modern IDEs will have similar features. I am just more familiarized with Eclipse. Here is a video I created many years ago on how to create a Code Formatter in Eclipse. If you advance to the 1:48 mark, you will see "Code Template" right above the "Code Formatter" option I selected in the video. Creating a code template is much easier than a formatter.
To do this, simply click on Windows > Preferences menu to get the Preferences popup. There, select Java > Code Style > Code Templates. in the right pane, expand Comments and select the component you wish to create a comment template for, for example Methods. Click Edit button and format the Javadoc comment to your liking. Obviously, you will have to do a bit of research to get really creative with your comments. For example, you might need to figure out how to use system variables or create your own. For example, in the image below, I made use the year variable to apply the current year whenever I create a new class.
Once you finish with all your template customizations, simply click the Export button and use the File Chooser dialog to save the file wherever you would like.
One last tip, if you need to embed code snippets in your Javadocs, you can follow the recommendations in this article. I do this very often. Sometimes I find it useful to embed a few lines of code to illustrate different use cases for the method. That way, other developers can see how to use the method in the correct context.
I want to add references to other elements inside javadoc. The javadoc should look similar to:
/**
* ...
* #my.tag SomeElement
*/
I want to reuse the existing Java editor inside Eclipse. Of course I can type above javadoc already, however I'd like to add some features:
Navigation: upon Ctrl-Click / F3 I want to navigate to the editor showing SomeElement
Auto-completion: Ctrl-Space should complete the text / show valid alternatives
Checking: I want to create a warning marker and underline the SomeElement if it cannot be found
I already figured out that I can do the auto-completion by using the extension point org.eclipse.jdt.ui.javaCompletionProposalComputer, though this seems to be little more complex than I had hoped, so I might be on the wrong track here?
For checking my elements I might be able to use org.eclipse.jdt.core.compilationParticipant, which can generate markers upon compilation which afaik happens with every save operation.
But how can I can manage the navigation feature? Any pointers are welcome!
For navigation you can provide a Hyperlink Detector. You'll want to look at how the Java Editor and its existing detectors are declared in the org.eclipse.jdt.ui plug-in to determine the correct target ID.
I would like to see visually how much space each box takes with as little effort/changes to the code as possible.
I would like to know if it's possible to just put a line around the outer margins of the View or ViewGroup object.
Since it's just for debugging and styling I would like to also quickly turn it off, so I do rather make the changes to my code in one place so it's easy and quick to undo. Is this a default option I am missing? Somehow I expect this feature to exist already.
Here someone asks a different but slightly related question with not a nice answer for my case.
Here someone gives an answer on how to outline one View.
Border for an Image view in Android?
Code-wise you could follow the answer to the first link you posted and create a drawable with the name "developer_borders" or something similar and apply it to every view you wish to have its borders visible.
To easily remove it afterwards, you can right-click the directory of your project and click Replace in Path.... For Text to find you want to search for android:background="#drawable/developer_borders and for Replace with don't use anything. This will find every occurrence of what you are searching and replace it with an empty string.
There might be an easier option. Some devices have quite powerful Developer Options. "Show layout bounds" is what you want but take a look at the rest while you are at it, some are pretty awesome.
Hello there fellow SO members!
I am writing a plugin for a Eclipse RCP application, and when I am selecting a row from a TreeViewer its properties appear in the Properties View.
Initially I was looking for a way I could make certain properties read-only, and found this SO question.
Now what I am asking is, how can I make these properties grey? I ask this because I'd like it to be more evident that they are read-only.
Any help/opinions are appreciated.
If I look at the createItem method from the PropertySheetViewer (org.eclipse.ui.views.properties.PropertySheetViewer) , it doesn't look too good for you, I guess. The only attributes updated from the TreeItems are the text and the image. There is no coloring done based on any attribute.
Edit: You asked for suggestions too, so I should finish it correctly: If you look at Properties View, then its not more than a simple view with a two-column table, which is wired to the SelectionService. So, I guess with a little effort you may implement your own Properties view visualizing the current selection in a proper way.