I am trying to implement an Eclipse editor which consists of a design part, Palette part and the Properties part for the selected palette item. All in the same editor page.
After a long time of googling, I have come to know that there are no proper articles or examples for this issue. Is there some solution that I could get from anyone here?
The SWT Design editor implements this feature in its editor. However, I am unable to access its source.
To access the properties view, you have to have three things:
Your editor must define its SelectionProvider (getSite().setSelectionProvider()). A SelectionProvider is either a JFace Viewer, or can be any class that return a corresponding ISelection interface.
The objects returned by the ISelection must either implement IPropertySource or return an IPropertySource adapter using the getAdapter(IPropertySource.class).
In multi-page editors you have to make sure, that the SelectionProvider also returns what expected.
For details about the first two point, see the following Eclipse Corner article: Take control of your properties, or if you would like to use the Tabbed properties view seen in GMF editors, The Eclipse Tabbed Properties View.
Related
Is it possible to define a perspective stack and perspective in the fragment.e4xmi?
The Eclipse 4 model editor doesn't seem to allow it. Why?
I add a new Model Fragment and for Feature Name I click Find ....
When I want to add a Perspective or a Perspective Stack, the dialog greys out the OK-Button.
Also, I have a lack of understanding what this Dialog is showing in general. It lists certain UI Elements and a lot of items below them, like
children
handlers
menus
and so on.
But those are listed multiple times. For example children is listed under CompositePart and under Dialog. But it doesn't make any difference which one I chose.
I know I can define the Perspective in the plugin.xml using the extension point and implementing IPerspectiveFactory. Is there no way to do it with the fragment.e4xmi?
Not sure about that dialog as I don't usually use it.
What you want to add is a Model Fragment with the 'Extended Element-ID' set to the id of the TrimmedWindow you want to put the perspective in. The 'Feature Name' would be children.
The model editor should then let you add a "Perspective Stack" as a child.
You can add the Perspective to the stack.
Note: Using the plugin.xml and IPerspectiveFactory is for Eclipse 3.x compatability mode, not pure e4. If you are using compatability mode I'm not sure how defining a perspective in the model editor fits.
Unity3d allows to construct window with custom UI. Just need to use EditorGUI/EditorGUILayout classes and their static methods.
Example of custom window:
The problem is that all the components have to be added manually via script. Then need to save, switch to Editor, wait for little compile things, and then we can see the result.
In web-development people use Web Inspector (for example, we can press F12 in chrome, Tab Elements -> Styles). We can add all needed properties to element and can see the result in real-time.
EDIT. another example (better than previous): we know C# winFormApp, C++ MFC e.t.c, which has form designer. We can choose any elements and set their properties:
It would be nice to have similar plugins for Unity
So. Does Unity3d have similar tools, utilities, plugins? Utilities to inspect code and editing styles (position, margin, padding, background, width, height, color e.t.c.)?
Well, I found something interesting...Editor window designer
The plugin is almost what I need
The project had been started but not completed yet.
As the author says: he decided to release Editor Window Designer as an open source project, that code is here
For now plugin allows add elements and styling them (position, padding, width, height, e.t.c)
Base demo window:
And here is hierarchy window and properties of concrete element
I wonder why Unity developers (or someone else) still didn't do something like that? It is very useful and necessary thing...
I noticed #javadoc view in my eclipse. Could you please tell me what is the use of this and how to use it.
Eclipse actually does provide decent tools for creating your own JavaDoc, which is a good idea, as then others who have to use your code will have the ability to see what it does.
There is a keyboard shortcut for adding a block for a class or method (on Mac it's Command-Shift-J I think, but search Javadoc in the key mappings.
You can define templates for adding things like links, which are pretty important, that make creation of JavaDoc go very quickly
When you document in Eclipse, it is intelligent enough to point to existing docs, so say you make an interface, you document the methods in the interface, then inside each implementer, if you created them after the interface, you will get a block that points you back to the interface
When you have added your own, or other people on your team have, this view let's you see what that will look like, so it's got a dual purpose: for making it easier to read the markup of others' JavaDoc, and for previewing your own.
The view you are showing is the Eclipse # Javadoc view. The Javadoc view shows the Javadoc of the element selected in the Java editor or in a Java view.
To use it, simply open a Java file that contains Javadoc in the Java view (or use the Java perspective). Once you do so the Javadoc view will automatically populate.
I have an eclipse RCP application that uses and Editor Area. I have a few things that I would like to do programatically but cannot find any documentation:
1) Do not restore editor sash layout. I.e., I like to use rcp saveAndRestore functionality, but for my perspectives, views, and other momentos. I do not however want to restore the editor area multiple tab groups at all. I choose not to implement the IPersistableEditor interface, and therefore my editor sessions are not restored, but when my application restarts, it still has split windows (swt sashes for multiple tab groups), etc, and i wish it was just 1 editor area tab group like default.
2) I would like to programaticaly split/duplicate an editor into another tab group, for example I would like a button that says "Split Horizontal" and that opens a new editor in a new tab group beside the current one.
Any help is much appreciated! Happy Coding!
/P
1) Funny, seems like a bug in the platform.
You can explicitly close all editors upon workbench window close. One option to do this would be to override the preWindowShellClose method in your WorkbenchWindowAdvisor:
public class ApplicationWorkbenchWindowAdvisor extends WorkbenchWindowAdvisor {
#Override
public boolean preWindowShellClose() {
getWindowConfigurer().getWindow().getActivePage().closeAllEditors(true);
return super.preWindowShellClose();
}
}
If you don't have access to the ApplicationWorkbenchWindowAdvisor, you can try to do the same with the IPerspectiveListenerX
2) I think there is no public API for this. The editor area behavior is defined in the presentation factory (see org.eclipse.ui.presentationFactories extension-point). You could clone the RCP standard presentation and implement the desired split-editor-area-on-demand functionality.
I'm writing a JFace standalone application using eclipse/windowbuilder pro. Windowbuilder is a nice tool to work with, but I'm having trouble finding information on the organizational structure of such an application.
Currently I'm extending the standard ApplicationWindow class (as is standard in windowbuilder examples) for the main window of my application and subclassing SWT composites for my 'sub windows' in the application. The problem I'm having is that I lose the ability to use JFace actions / databindings when I'm graphically building SWT Composite subclasses in windowbuilder. The palette for adding JFace actions is inaccessible when using SWT designer while subclassing standard SWT components. I've searched at length for how to add this palette to no avail (the standard method fails since this isn't a 'normal' palette that appears in the palette manager). I've also tried adding the JFace action component to my existing palette, but can't find documentation on how to add an abstract class (Action) to the palette. I know that I can write all the code I want by hand, but it defeats the purpose of using windowbuilder.
I'd really like to stick to the standard JFace viewer/action model, but I can't figure out which components I should be subclassing for my 'sub windows' in my app. I've tried subclassing the Window class directly but this doesn't yield access to windowbuilder's JFace Actions palette. I'm not sure under what conditions that palette is accessible (I've been iteratively removing and adding components to ApplicationWindow, I'm getting desperate). I have a few custom widgets that I'd gladly write JFace Viewers for if I could figure this out.
Any windowbuilder fans out there? Is subclassing SWT Composite a reasonable/standard way to go about making components of this application? What is the standard for writing apps that are more complicated than a single ApplicationWindow? I've searched high and low, but can only seem to find tutorials and examples that are a single application window -- nothing composite. I feel like I'm missing some key pieces of information with regard to the structure of more complicated JFace applications. I suppose my holy grail would be the JFace version of SWT Composite that would allow me access to JFace actions code generation through windowbuilder.
Any tips and/or reading material explaining standard JFace design for larger applications would be appreciated!
I've been working with WBPro for about 6 to 7 years now... I think we can have a conversation about your problem. I might not be able to answer your question completely, but I will do my best. So, first off, for your sub-windows you should use JFace Dialogs. You can create a template one from New>Other>WbPro>JFace>Dialog or just subclass it yourself. You can also use TitleAreaDialog which is cooler and has a Title Bar at the top just like all Eclipse Dialogs. These two classes are both within JFace and are available in WBPro.
You have the JFace widgets and viewers available in the Design Tab, but not the actions. But the reason for that is that Dialogs and sub-Windows do not have Toolbars or Menu bars, I think that's why they are not there in the palette, but if you have a Context Menu for one of your inner widgets, I think you should implement that yourself. I can dig a little deeper for you if you want, se tell me if there is still something to address.