The Problems view in Eclipse provides filtering and grouping support for quickly navigating large sets of problem markers. If you’re creating custom problem markers, you can register a custom marker group and associate priorities to the different group entries. This will make navigating your custom markers much faster.
There are three extension points that you need to implement:
The first extension point defines your custom marker type, associating a custom ID with it. The persistent attribute should be set to true if you want your markers to be persisted across the workbench invocations. The list of super types would usually include org.eclipse.core.resources.problemmarker and org.eclipse.core.resources.textmarker. If your custom markers are associated with Java classes, use org.eclipse.jdt.core.problem as well.
The second extension point is used to associate the markers with the text documents. Whenever the document is displayed in the associated editor, it will show the marker annotations in the relevant areas (usually the gutters). The markerType attribute should be the ID of the marker type specified above, and the super attribute would usually be org.eclipse.ui.workbench.texteditor.*, where the last segment is info, warning or error.
The third extension point is used to create a custom marker group, and further categorize the custom markers.
The markerTypeCategory sub-element declares the custom category shown in the Types part of the Configure Contents dialog. The name attribute will be used in the relevant tree node. The markerTypeReference should point to the ID of the marker type specified in the first extension point.
The markerGrouping sub-element declares the custom grouping shown in the Group By popup menu. The name attribute will be used for the popup menu entry, and the id attribute will be used to associate the group entries (see below).
The markerGroupingEntry sub-element is used to group the different custom markers when the parent group is selected in the matching Group By popup menu. If you have different validation / analysis rules, you can group the resulting markers to present a clean visual separation. You can have multiple grouping entries. Each entry has the associated priority – groups with higher priority (use values in 0..100 range) are shown first in the Problems view.
The markerGrouping attribute of the markerGroupingEntry sub-element should point to the ID of the markerGrouping sub-element declared above. The label attribute is used in the Problems view parent node that groups all markers belonging to this grouping entry.
The last piece of configuration is the markerAttributeGrouping sub-element. Its markerType points to the ID of the custom marker from the first extension point, and its attribute is used as a custom attribute on the IMarker (see below) to associate the specific marker with its grouping entry. The markerAttributeMapping sub-elements specify the mapping itself.
Suppose the markerAttributeGrouping.attribute is categoryId. Then, the IMarker will have the following:
marker.setAttribute(“categoryId”, 50)
where 50 is a sample value. Then matching markerAttributeMapping will have value attribute equal to 50, and markerGroupingEntry attribute equal to ID of one of the markerGroupingEntry elements above.
How does it work at runtime? Suppose your org.eclipse.core.resources.marker extension point has the id attribute equal to com.my.company.custom.problem. Then, you create the marker with
IMarker marker = resource.createMarker(“com.my.company.custom.problem”)
set all the usual attributes (line number, priority, severity, message), and then set the categoryId attribute (the name must correspond to the matching markerAttributeGrouping.attribute entry) to one of the values of markerAttributeMapping. This marker will:
- Be associated with the specific resource.
- Be shown in the problems view with the set message, priority and severity.
- If the Problems view is grouped with the custom grouping, the marker’s categoryId value will be used to map it to its grouping entry, and the marker will be placed under the relevant parent node in the tree.
The latest addition in the Flamingo component suite is support for horizontal scrolling of collapsed ribbon tasks and shrinked task toggle buttons. This has been one of the items on the roadmap for version 4.0 (code named Fainnear), and is now available in the latest 4.0dev drop of Flamingo core and 5.1dev drop of Substance Flamingo plugin.
The new functionality kicks in when you start to shrink the ribbon frame horizontally. At a certain point, the content needs to be either shrinked or scrolled, depending on the minimum size of the corresponding ribbon components and the overall content of the frame. The first screenshot shows three first stages of the ribbon component at progressively smaller widths (all the screenshots in this entry are taken under the Substance Business skin):
The second step shows that the contextual task group header (in the title pane) does not overflow into the bounds of the min / max / close buttons. The third step shows what happens when there is not enough width to show the preferred content of all the task toggle buttons – they begin to shrink (note the last letters that are cut off on some of the buttons), and the area shows horizontal dividers between the buttons.
At a certain point, there is not enough space to show all the task toggle buttons under the minimum width (that is still able to show the first few letters). At this point, the area that hosts the task toggle buttons becomes a scrollable panel:
Clicking on the scroller buttons scrolls the task toggle buttons:
Finally, at some point there is not enough space to show the ribbon bands under the most restrictive resize policy. At that point, the area that hosts the ribbon bands becomes a scrollable panel as well:
As above, clicking the scroller buttons scrolls the ribbon bands:
There are a few usability points built in to this mechanism:
- When the task toggle buttons become shrinked, the left / right insets become gradually smaller to allow showing more text (compare with the first two steps).
- When the task toggle buttons become shrinked, they show the full title in the tooltip.
- You can mouse-wheel the task toggle button area to cycle through the tasks (as before). When you cycle to a task which button is not visible, it will be scrolled to and revealed.
- The content can be scrolled repeatedly by pressing and holding the mouse over a scroller button.
- Once the content reaches the edge, the corresponding button is disabled.
If you want to see the scrolling in action under the core look-and-feels, run the following WebStart demo:
If you want to see this functionality under Substance, run the following WebStart demo:
If you want to test the new functionality in your applications, you would need the following (the last two only for applications running under Substance look-and-feel):
The latest 4.0dev drop of Flamingo also introduced a breaking API change. The support for help ribbon task has been removed. Instead (as in the screenshots above), you can place a help button on the far right side of the task toggle buttons using the new org.jvnet.flamingo.ribbon.JRibbon.configureHelp API. It gets two parameters – the icon and the action listener that will be invoked when the button is clicked.
Your feedback is, as always, greatly appreciated.
Here are some Swing links that you might have missed during the last week:
JavaFX 1.0 is one week away, and the full feature list is still unknown. However, an interesting bug report has found its way to the bug parade (bug 6770914):
http://javaweb.sfbay.sun.com/~ngthomas/javafx/mediaplayer/test.html
This is the javafx media player applet. At the bottom of the applet, there are three buttons, which will trigger a javascript -> fx call:
document.getElementById(“app”).script.playVideo(url);
with will change the video clip playing inside the applet. It works with 6u10, and our latest 6u12 nightly. But with 6u11 b03, document.getElementById(“app”).script is undefined/null
Looks like an applet playing media and being controlled by JavaScript associated with HTML buttons. Is this an example of enhanced applet support? At this point, it will take nothing short of a spectacular collection of applets to make them a viable competitor (and no, dragging the applets to desktop is not going to be it).
In the spirit of transparency and openness, the submission process for EclipseCon 2009 conference is very refreshing. As the main site says
The selection is done transparently and in the open. Specifically, all submissions are made through our submission system. Everyone in the community (including you) is invited to review the submissions, ask for more information, provide comments and critiques – just as everyone in community is invited and encouraged to do for Eclipse bugs and features.
I have just submitted a proposal to talk about our experiences in developing a visual designer for form-based applications, built on top of rich Eclipse tools such as the core platform itself, as well as JDT, EMF, GEF, VE and JEM. The proposal is called “On The Shoulders of Giants: Harnessing the Power of Eclipse Enterprise Ecosystem“, and you are more than welcome to leave comments on the entry. Here is the abstract:
Code reuse in large projects is not just a trendy buzzword. If you can build upon solid, evolving and well tested foundations that are developed and maintained by committed teams, you have much less code to test, integrate and support. The Eclipse Ecosystem is a prime example of an extremely rich foundation for building enterprise grade applications, and this talk is going to show the diverse, yet interoperable technologies that allow businesses to concentrate on their specific requirements without reinventing the plumbing layers.
A part of a larger client-facing offering, Amdocs Smart Client Designer is an advanced visual designer that allows seamless collaboration between designers and developers in creating complex business form-based applications for Support Call Centers in the telecommunication industry. Harnessing the power of such technologies as JDT, GEF, EMF, JEM and VE has allowed us to dramatically reduce the effort to build the basic blocks of the tool (such as persistence, code generation and java syntax tree manipulations). In addition, core platform features such as task and job managers, builders, natures, markers and many more are enabling user-centric asynchronous business flows in a clean, simple and maintainable way.
Building on top of a vibrant and evolving ecosystem has been a pleasant experience, further strengthened by a recent migration to Java 6, Eclipse 3.4 and the latest version of the dependent plugins. In addition, we are going to talk about the “Eclipse way” of designing the flows, where the existing core features guide the design process to facilitate familiar flows and simpler implementation.
If you are developing a large Eclipse-based offering, or considering Eclipse as the vehicle for your next enterprise-grade tool, come to our session to hear about our experiences in this area.
