Community
Participate
Working Groups
Opening this bug to separate out this feature request which was made in Bug #162770 by Alex Bernstein: 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)
Note: The original request was to provide mouse click notification in order to enable bookmark-style navigation: (from bug #162770): "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."
The original use case suggests that use of a ruler-type mechanism rather than ControlDecoration might be more suitable. However, additional requests have been received for mouse click functionality: - a click event to be interpreted by the application - an event for triggering a context menu After discussing the various use cases, we think the best approach is to provide: - a selection event notification for click-select - a selection event (default select) for double-click - a menu detect event for menu popup gesture At this time we won't provide a visual such as selection animation or mouse cursor change. We are trying to supply the minimum function needed for this first iteration. We noted that the Windows XP notification area shows small icons that support app-defined click and context menu behavior, without showing a visual indication that these actions are available.
cc'ing interested parties from Bug #162770.
API REQUEST: Add API to add and remove untyped listeners to ControlDecoration, supporting SWT.Selection, SWT.DefaultSelection, and SWT.MenuDetect. Listeners are untyped because the underlying SWT.MenuDetect event is untyped, and we want to treat all ControlDecorationEvents consistently. It also allows for future addition of event types if necessary. RISKS: None PERFORMANCE IMPACT: Negligible. For simplicity, the underlying SWT events (mouse down, mouse double click, menu detect) are hooked when other events are hooked, but no work is done on receipt of these events unless a client has registered a listener. We are already listening to hover/enter/exit events to support the hover help. OTHER IMPACTS: Field assist example will be updated to demonstrate use. JAVADOC: /** * Adds the listener to the collection of listeners who will be notified * when an event of the given type occurs. When the event does occur in the * decoration, the listener is notified by sending it the * <code>handleEvent()</code> message. The event type describes the type * of event of interest. * <p> * When listeners are notified, the event data field will contain the * decoration. The widget field will contain the composite on which the * decoration is rendered. For <code>SWT.Selection</code> and * <code>SWT.DefaultSelection</code> events, the x and y fields will * describe where the event occurred in coordinates relative to the * composite on which the decoration is rendered, not relative to the * decoration itself. For the <code>SWT.MenuDetect</code> event, the x and * y fields are in display relative coordinates. * * @param eventType * the type of event to listen for. It should be one of * <code>SWT.Selection</code>, * <code>SWT.DefaultSelection</code>, or * <code>SWT.MenuDetect</code>. All other event types are * ignored. * * @param listener * the listener which should be notified when the event occurs * * @see org.eclipse.swt.widgets.Listener * @see #removeListener */ /** * Removes the listener from the collection of listeners who will be * notified when an event of the given type occurs. The event type describes * the event of interest. * * @param eventType * the type of event to listen for. It should be one of * <code>SWT.Selection</code>, * <code>SWT.DefaultSelection</code>, or * <code>SWT.MenuDetect</code>. * @param listener * the listener which should no longer be notified when the event * occurs. This message has no effect if the listener was not * previously added to the receiver. * * @see org.eclipse.swt.widgets.Listener * @see #addListener */
+1
fixed in HEAD >20070312 (should be in the IBuild). Modified example to show its usage. A prettier (semantic) example, such as quick fix, might be nice for the future, but not necessary for M6.
I was not sure if this was discussed before, or was taken care of, but there is one more thing: I think it will be useful to have a way to custom paint (or/and just have an access to) the area (composite?) where the icons are placed. I am adding a screenshot from my editor. Notice the yellow background in "notification" area. This is a visual clue to the user that "data-correlation" can be performed in that field. Blue areas in the notification area correspond with the areas inside related widgets.
Created attachment 60939 [details] Notification area is custom drawn
Alex, you mentioned this feature request in #162770, which also addressed mouse behavior and custom positioning. I suggest you open up a new bug for the owner draw capability or else it's likely to get lost in the other bug. We don't plan to add any more functionality to decorations in 3.3, but we should track that request for the future.
Reopening bug. In bug #81334, SWT is now adding a typed listener for MenuDetect. This eliminates the rationale for untyped listeners in JFace discussed in comment #4. Given SWT is adding a typed MenuDetect event, we should expose those typed events for selection and menu detect in JFace rather than using the untyped.
(In reply to comment #10) Agree, makes sense. Originally we wanted typed, but also wanted consistency with SWT, and now we can have both. A bit late coming but oh well lets do it right.
API REQUEST: change the listeners to typed listeners RISKS: None, this is new API PERFORMANCE IMPACTS: This is actually a slight improvement in calling listeners. Now that SWT documents a MenuDetectEvent we don't have to copy all relevant fields from an untyped event to a new untyped event object. We can use the SWT constructors to copy only the relevant fields. REMOVE: the untyped add/remove listener calls from comment #4 ADD 4 METHODS: /** * Adds the listener to the collection of listeners who will be notified * when the platform-specific context menu trigger has occurred, by sending * it one of the messages defined in the <code>MenuDetectListener</code> * interface. * <p> * The <code>widget</code> field in the SelectionEvent will contain the * Composite on which the decoration is rendered that received the click. * The <code>x</code> and <code>y</code> fields will be in coordinates * relative to the display. The <code>data</code> field will contain the * decoration that received the event. * </p> * * @param listener * the listener which should be notified * * @see org.eclipse.swt.events.MenuDetectListener * @see org.eclipse.swt.events.MenuDetectEvent * @see #removeMenuDetectListener */ public void addMenuDetectListener(MenuDetectListener listener) /** * Removes the listener from the collection of listeners who will be * notified when the platform-specific context menu trigger has occurred. * * @param listener * the listener which should no longer be notified. This message * has no effect if the listener was not previously added to the * receiver. * * @see org.eclipse.swt.events.MenuDetectListener * @see #addMenuDetectListener */ public void removeMenuDetectListener(MenuDetectListener listener) /** * Adds the listener to the collection of listeners who will be notified * when the decoration is selected, by sending it one of the messages * defined in the <code>SelectionListener</code> interface. * <p> * <code>widgetSelected</code> is called when the decoration is selected * (by mouse click). <code>widgetDefaultSelected</code> is called when the * decoration is double-clicked. * </p> * <p> * The <code>widget</code> field in the SelectionEvent will contain the * Composite on which the decoration is rendered that received the click. * The <code>x</code> and <code>y</code> fields will be in coordinates * relative to that widget. The <code>data</code> field will contain the * decoration that received the event. * </p> * * @param listener * the listener which should be notified * * @see org.eclipse.swt.events.SelectionListener * @see org.eclipse.swt.events.SelectionEvent * @see #removeSelectionListener */ public void addSelectionListener(SelectionListener listener) /** * Removes the listener from the collection of listeners who will be * notified when the decoration is selected. * * @param listener * the listener which should no longer be notified. This message * has no effect if the listener was not previously added to the * receiver. * * @see org.eclipse.swt.events.SelectionListener * @see #addSelectionListener */ public void removeSelectionListener(SelectionListener listener)
+1.
Fixed (again). Available >20070316. Note you have to load the latest SWT to load JFace until the next build. I will send a notice to platform-ui-dev
verified I20070320-0010, WinXP using FieldAssist example.
