Community
Participate
Working Groups
The current choice for vertical alignment (SWT.TOP) is not very useful for field validation because it is already used for content assist. When SWT.MIDDLE is used for this purpose, it works well for simple controls such as single line text, but fails for trees, tables and multi-line text areas because it is too low. According to ongoing discussions on field validation, the latest recommendation is to vertically align the validation image to to first line of text. For single-line text field this would be the same as MIDDLE. However, for multi-line area, tree or table you would need to know a bit more about the Control you are handling in ControlDecoration. You could ask for the Font object from the control, compute the height from the font metrics, and align the image so that it is centered relative to the font size, not the entire control height. I didn't try this and don't know if it actually works, but it is a plausable theory :-).
In the last discussions I was part of, the idea was that the content assist decoration would be replaced by error or warning decorations if those were to be shown. I need to understand better what your goal is...are you trying to show error/warning decorations in addition to content assist? Is this a design you are trying to achieve for 3.3?
Control decorations are managed by the message manager in UI Forms (see http://www.eclipse.org/eclipse/platform-ua/proposals/forms/enhancements-3.3/index.html for details on the message manager). The manager does not know about the content assist or other decorations. All I am trying to do is know what combinations of styles to use to create a ControlDecoration instance for showing errors or warning as per our guidelines.
I think the latest guidelines are to use SWT.CENTER. The examples you provided are all text boxes, and this should suffice. If we have a concrete case where some other taller control is used, I would recommend using SWT.TOP. We talked early on about providing row-based rendering for controls like tables, but I don't know of a requirement yet... Kevin, do you have anything to add here?
I don't think SWT.TOP will yield the recommended position for taller controls. In addition, since message manager works on Control objects, it does not know if the control is 'taller' or not.
Do we know of cases where clients are running into this problem or are we talking about theory introduced by the MessageManager framework? I'm asking because early in the 3.3 cycle while discussing the visuals for all this, we didn't have a need for any specialized positioning and had decided to wait for the concrete cases. I guess I'm saying I'd like to see the specific case where SWT.TOP is not what we want.
The screenshots that are somewhere in the Wiki rabbit hole indicate that the image should be vertically centered with respect to the text of both single and multi-line widgets. The style MIDDLE happens to fit this descriptions for single line, but not for multi-line widgets. Using 'TOP' would not work for me short from using 'instanceof' for the Control I am passing to ControlDecoration. If we do nothing in 3.3 about this, I will simply use SWT.MIDDLE. Alternatively, we can wait until somebody (probably PDE as the first adopters) comes back with a multi-line text area issue. This is not a critical problem.
okay, I will leave this without a milestone for now, waiting for the concrete problem. I think that there will be (in the future) specialized placement of ControlDecoration for cases such as table rows, multi-line text, etc., but right now I expect clients to be aware of which control they are using and install the right positioning.
marking P5 until a concrete problem is described.
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.
