Community
Participate
Working Groups
I would like to be able to place my decoration along left/right edge of the field at random position. Right now, the only options are beginning, center and end alignments. My editor is form based editor (as opposed to text editor) with several widgets displayed simultaneously. Each of the widgets (I use StyledText mostly) can have some (sometimes large number) of associated "things". Things can be "standard", like errors, search results and bookmarks, as well as specific to our product. I would like to display decorations for those states, but I do not want them to overlap. I am using our in-house solution, which I would like to replace with FieldDecorators.
Are you referring to DecoratedField or the new ControlDecoration in 3.3 M3? ControlDecoration intends to provide this behavior in the future, and in fact there are some positioning methods that have been made protected for future experimentation. See also bug #162497. I'm not marking this as a duplicate since it is a request for general opening up of the placement code vs. the specific request for positioning by table row.
Alex, if you wanted to play with this now, see the method ControlDecoration.getDecorationRectangle(Control targetControl). This is the intended hook for custom decoration placement, although I have done nothing yet to try it out with alternate locations, as we are focusing on the base function for M3. Note that the API is still marked experimental and may evolve throughout 3.3....
cc'ing Kevin
Alex, I'm assuming there is enough support for you in the current implementation. Please annotate this bug if there is not, as we are freezing API in M6.
In fact I did not have time to even start experimenting with that class, Susan. Speak of being efficient ;-( I will wait for post M6 and hopefully all the interfaces and classes will be easier to find then.
I would like to comment on ControlDecoration functionality that I have seen so far: 1. In its present form it only supports 6 positions. We would prefer to be able to specify random position (in terms of offset from the top left or right corner) 2. It would be nice if there was a way to detect when user clicks mouse on the decoration, or on the area reserved for decoration(s) (along left or right edge) 3. Would be nice to be able to provide a way custom draw instead (or in addition to) of using images as decorations.
I will attempt to subclass (by example) ControlDecoration to show you how to do #1 and #2. I really don't see providing #3 in the near future. If needed, you could render onto an image.
Thank you Susan. In my custom solution I am creating images on the fly... thought it would be easier on resources (and perhaps faster) if I could just draw on DC instead. May be not though...
It likely would be more efficient to skip the image part, but I think dynamically rendered decorations are kind of stretching the intent of ControlDecoration, so I don't see doing owner draw in the API if you can successfully do it in client code. If this proves to be a common pattern, we can revisit. I'll still investigate items 1 & 2...
Sounds good -- I will be looking forward to this.
Hi, Alex. I have an example that shows (1) and (2). (1) arbitrary placed locations - can be done using the existing API, overriding the protected method getDecorationRectangle(control). (2) would require new API - Since the ControlDecoration may be rendering on any parent widget in the control hierarchy, it would be complicated for a client to implement this behavior on their own. Most likely we'd add API to let you install a MouseListener on the control decoration. I have not yet released any code since #2 requires new API, and all API changes must get PMC approval at this stage in the release. So my question is whether your comment "would be nice" on item (2) is from a use case in your product, or just a "would be nice someday." If it's a real requirement, I will refine the API and submit a request to the PMC. I'd just as soon add it now while ControlDecoration is still new, but I don't want to do it without understanding the priority and usage.
Regarding #2, here is the usecase: The editor(s) in our product are form-based editors. They display multiple controls/widgets. These widgets allow user to view/edit or otherwise modify some data attribute. There are various additional properties that can be associated with most attributes, generic, like errors, bookmarks and tasks, and product-specific such as data correlation sites. All of these are displayed in various forms of text styles inside StyledText-based attributes (other widgets also have some way of displaying them). Because the editor is form based editor, we want these attributes to be displayed along the left (and right) edges of the widget to which they "belong". We already do it now, using our own mechanism. The ultimate goal is to have annotation areas associated with a widget, as opposed to the entire editor. User should be able to click on the little decorations to navigate directly to the location inside an attribute. Can people live without it? Yes they can. Should they have this functionality? Yes they should... Hence, "nice to have".
Thanks, Alex. I can see that it would be useful function in general. Gee, there's a "thingie" there telling me something. I want to work with it. And especially in the error or info case, you might want to navigate to the specific part in the text. I'm only reticent so that this doesn't feature creep into something it's not. For example, I can't see dragging and dropping it, but clicking on it seems within the realm of a decoration. The most compelling reason in my mind to offer the API is that you'd have to rely on the underlying implementation to be able to do it from the outside (walk the parent tree and figure out where the decoration is located). So I think it's a reasonable request. Kevin McG - thoughts? I'm gut checking with you before proposing new API for the PMC.
You are correct, this should not be anything more than I have described. In fact, it ought to be almost identical to annotation mechanisms present in JFace, complete with markers, annotations types and specifications and so on... I wish I could use annotations, but they sit on top of IDocuments and editors, whereas we don't have IDocument and the editor is multi-widget. So if we could mimic the most common things from annotations (or somehow marry the annotations support with ControlDecoration, even better if more time consuming) that would suffice. Please let me know if I can help further.
Yes, I can see a possible relationship there. These features (click support, arbitrary placement) are allowing you to build a ruler of sorts for a multi-control editor. And annotations could be used to populate the control decorations. For now, I think it is important to limit the ControlDecoration API to general use features, and I think placement and mouse listeners are fairly general purpose. After we settle what's done for 3.3, it may be worth investigating whether there should be code that allows for more integration. Field assist in general arose from taking platform text features and making them more general (non-document oriented).
cc'ing Kim for comment
This seems entirely reasonable from my perspective.
Aside: should we branch a new bug to discuss the problem of selection listening? I understand the desire to back the ControlDecoration with behaviour. It could be quite useful in an number of places. I worry though about feature creep. My concerns are: 1. Too open There is a real tendency for this to be come "the one hammer to hit all nails with". Most of the controls in Eclipse have standard and predictable interaction behaviour. Eg. text controls, toolbar items, etc. You don't know what they'll do app wise, but you do know how to interact with them. There are a small number like the editor strip that introduces new controls (e.g. breakpoint, bookmarks, etc) but these benefit from being relatively small in number, used pervasively so people can learn them, and provide only very simple interaction (click to add/remove, and a menu). Allowing arbitrary mouse listening on the ControlDecoration opens up quite widely a set of uses which we hadn't envisioned. I don't feel comfortable with it becoming "a picture which you can put anywhere, to which can do anything". Lets say all we provide is a single "selected" event instead of the raw mouse event. Is this enough for the new requirements? (Even at that I'm not sure I'd be comfortable with how its been opened up). 2. Consistency in interaction behaviour We need a common language for interaction in the UI. Is it single click to activate? Double click? App dependent? More so, all uses of the "error" decoration should ideally have the same click behaviour in the IDE (e.g. take you to the error description, allow click fix, etc). Maybe that's just a style guide issue but another approach is that you subclass if you want behaviour, so there becomes an "ErrorDecoration" class that has code for showing errors on click. 3. Feedback We'd either need an alt image to tell you the item has been selected, or cursor change to the "hand" to tell you that clicking on it will do something. 4. Accessibility We need to consider accessibility. Are you going to be able to tab to it to trigger its click behaviour? I don't think so, its not a real control and can't live in the tab sequence. I don't see how to directly make this accessible. Perhaps nice developers will add equivalent key sequences, or a menu in the control. But there's nothing to tie one to the other so a user can learn what the accessible alternative is. 5. Popup Menu? Menu bar menu? The items in the editor LHS strip have popup menus associated with them. Do we expect ControlDecorations to have these too? If you allow clicking on them to do something, then why not a menu? Generally the rule is that you shouldn't have items in popup menus that you can't get from a menu bar. Something to note is that items in the editor strip also live in other views (e.g. Breakpoint view, bookmark view). This is their primary "home" and they happen as a convenience to show up in the editor too, which relaxes some constraints on them. In their specific views they have menu bar entries which then they can get away without in the editor strip.
Alex, I have opened up bug #176198 to address the request for mouse click events, which we will address for 3.3. After some discussion, we have decided to defer the support for arbitrary locations. Our rationale is: - Existing eclipse decorators have the same constraints on decorator position, and if we are to solve the issue of needing more slots, we want to address the general problem, not just the problem with ControlDecoration - Allowing arbitrary placement opens up the behavior too generally, especially for a first iteration of API. It also introduces complexities such as scrolling behavior, etc., that we don't want to address this late in the release. - We need to see more use cases in order to determine the appropriate API for specifying additional locations. - For your specific use case, it sounds as if using a ruler strip is more in line with what you are trying to achieve. There is a committed JDT plan item to open up support for these editor strips, so I suggest you contact Daniel Megert to determine what is available.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
