Community
Participate
Working Groups
Its currently not possible to use the FormText outside a form, cause it refuses to draw itself transparently over its parent. I tried every trick (transparent GIF as parents background image, setting the background colour to null gets reverted to the default control colour). Is there a reason why every other control can render itself transparently when its parent has the INHERIT_FORCE background mode set, except for the FormText? Does its paragraph rendering not support rendering without a background colour set? It would be very nice, if that behaviour could be changed, although I have no idea how. Maybe just allow to set a null background colour would do the trick?
Do you have a code sample which illustrates the problem? Can you attach a screenshot also?
Created attachment 142857 [details] Non-transparent form on composite
I am painting the background myself in the resize listener, and set a background image for the parent. On top of that I create controls, which are all transparently painted except for the FormText. See attached screenshot. parent.setBackgroundMode(SWT.INHERIT_DEFAULT); final String message = formTextNotification.getFormTextMessage(); text = new FormText(parent, SWT.WRAP | SWT.NO_FOCUS); ((FormText) text).setText(message, true, true);
I can verify this as well. The implementation of FormText does not seem to support any kind of transparency at all. The problem seems to be the way FormText is being painted: there is a bit of hand crafteed double buffering going on, where the text is being painted on an intermediate image (FormText.java lines 1573-1603): On the line 1581, the text buffer is being created: GC textGC = new GC(textBuffer, gc.getStyle()); On the line 1585, the text buffer is being filled with the background color: textGC.fillRectangle(0, 0, width, height); And later on the line 1601, the buffer image is being painted to the GC: gc.drawImage(textBuffer, x, y); I see few problems with this approach: 1) the most obvious one is that the text background is being explicitly repainted 2) the less obvious one is tat the text is being painted on the image. As I've found out the hard way, the image objects created inside the SWT are opaque by default and making them partially transparent does not come naturally to them (e.g. you'll have to manually post-process the resulting image data to insert alpha channel information - painting on a transparent image is not very useful either, as the whole result remains transparent) One possible solution (with the least amount of changes) would probably be to paint the FormText content twice on two images in parallel - once for the actual display value and once on a grayscale image for a alpha channel calculations, then compose the grayscale and full color imaged into a new image with appropriate alpha channel bits set up and use that image to draw to the canvas. This would of-course be also twice as slow as current method, so it might not be as desirable approach as some other, but would probably yield the most accurate results.
The control could check the SWT.TRANSPARENT style and only perform the described approach if the user created it in transparent mode. This would also not affect existing code.
(In reply to comment #5) there's a warning in SWT.TRANSPARENT javadoc:: * WARNING: THIS API IS UNDER CONSTRUCTION AND SHOULD NOT BE USED
Added my vote to this bug. FormText is a good control to use in any UI where one needs a stand-alone label that would not be normally read by a screen reader. Since it can get focus on tab traversal, it will be read. The other alternative is to use a read-only border-less Text field, which has a number of undesirable characteristics on some platforms when used in this way. Unfortunately, the lack of background transparency for FormText, is a show-stopper for this usage. You don't have to draw your own background to run into a problem with this. Some variants of Windows, for instance, will draw a gradient across the active tab in a tab group. A FormText in this context looks terrible. I am even seeing this problem in default Vista config. The default tab background is plain white, the default dialog background is gray. FormText draws a gray background. There is a related problem with how FormText handles disabled state. It sets the background to a fixed color (among other things). There needs to be a way to tell it to leave the background alone in either enabled or disabled state. Resolving this issue would make it easier for people to write accessible UI in Eclipse without sacrificing appearance.
Is this assigned to the correct inbox? FormText seems to me more of a general facility than help system. I just went through and ripped out out all references to FormText from the product that I am working on. Too many transparency glitches that aren't getting addressed. We aren't even doing anything fancy with the UI. It's just that the lack of transparency in FormText makes it not render properly when placed in a tab group on many operating systems.
(In reply to comment #8) > Is this assigned to the correct inbox? FormText seems to me more of a general > facility than help system. FormText is from org.eclipse.ui.forms.widgets. The Forms API is owned by UA (User Assistance). This is why I sent it there [from UI] last year. Ownership has not changed since then. Sending back. :o
Any comment from UA team?
I took a look at the example code you pasted. It didn't look exactly like the screenshot - did you try using FormToolkit.adapt() as follows: FormToolkit toolkit = new FormToolkit(parent.getDisplay()); parent.setBackgroundMode(SWT.INHERIT_DEFAULT); final String message = "This is my message"; FormText text = new FormText(parent, SWT.WRAP | SWT.NO_FOCUS); toolkit.adapt(text); ((FormText) text).setText(message, false, true); If that doesn't work can you paste in a larger chunk of your example - in particular the code that is setting the background.
:o
The easiest repro of this problem is to put FormText in a tab group and then run it on any operating system that paints active tab background differently than the default window background. No custom painting required. For instance, Win XP paints a gradient, Win Vista and 7 paint solid. Toolkit adapt will not do anything for this problem. FormText makes explicit calls to set background color on GC all over the place.
Tab Group as in Launch Configuration Tab Group? If someone can paste a self contained example it will be a lot easier to investigate the problem.
> Tab Group as in Launch Configuration Tab Group Basic SWT tabs. Used in launch configuration and other places. Will attach a repro shortly.
Created attachment 166688 [details] Repro (main java file) A dialog that shows formtext directly on top of dialog's composite and also nested inside SWT tab folder. Variants are shown with and without FormToolkit styling.
Created attachment 166690 [details] Repro (full project zip) Runnable plugin project containing the repro dialog. Run source and look for ReproBug284393 menu at the top level.
Created attachment 166691 [details] Repro (screen capture on Windows 7)
Created attachment 166699 [details] Repro (screen capture on Windows XP) The size of the dialog doesn't make the gradient very evident, but it is there if you load it in a graphics tool. The screen capture does clearly show that the embedded FormText is not transparent, not matter how you configure it.
Thanks, I will give that a try next week.
(In reply to comment #11) > FormText text = new FormText(parent, SWT.WRAP | SWT.NO_FOCUS); > toolkit.adapt(text); FormToolkit.adapt(Control) only relieves the problem very slightly - it is masking the problem by painting the background with a diferent solid color. It is quite impossible for example for FormText to have any kind of gradient or custom-drawn background. (In comment #4 I pointed out the primary causes for this issue) > > On the line 1581, the text buffer is being created: > GC textGC = new GC(textBuffer, gc.getStyle()); > > On the line 1585, the text buffer is being filled with the background color: > textGC.fillRectangle(0, 0, width, height); > > And later on the line 1601, the buffer image is being painted to the GC: > gc.drawImage(textBuffer, x, y); > The lines above cause the FormText widget to always draw a sdolid background to the text. Setting a background image or putting the widget on the composite/canvas widget that has a non-solid background will be negated by the fact that the text is drawn on a offscreen image that has been filled with an explicit background color and then that image is painted on the FormText, effectively overriding any background the FormText might have...
Thanks for the example I can clearly see the problem now (although I don't yet see a solution). Are you suggesting adding a style flag which could be passed into the constructor to make the FormText be transparent?
> Are you suggesting adding a style flag which could be passed into the > constructor to make the FormText be transparent? Standard behavior for similar SWT controls (such as Label or Canvas) is to be transparent unless background color or image is explicitly set on the control in question. That would be the preferred option, but if not possible a new style flag or some other method for indicating that transparent behavior is desired would work too.
(In reply to comment #22) > Thanks for the example I can clearly see the problem now (although I don't yet > see a solution). Are you suggesting adding a style flag which could be passed > into the constructor to make the FormText be transparent? I would not want to use SWT.TRANSPARENT or some such style flag to denote that a widget should be transparent. Konstantin is only partly correct in his comment #23, where he claims that Label and other such widgets are transparent by default unless an explicit background color has been set. Another part of the story is that it also depends on the parent composite's backgroundMode attribute value. From Composite.setBackgroundMode(int) javadoc: Sets the background drawing mode to the argument which should be one of the following constants defined in class SWT: INHERIT_NONE, INHERIT_DEFAULT, INHERIT_FORCE. And SWT JavaDoc has this to say about above constants: SWT.INHERIT_NONE: The <code>Composite</code> constant to indicate that an attribute (such as background) is not inherited by the children (value is 0). SWT.INHERIT_DEFAULT: The <code>Composite</code> constant to indicate that an attribute (such as background) is inherited by children who choose this value as their "default" (value is 1). For example, a label child will typically choose to inherit the background color of a composite while a list or table will not. SWT.INHERIT_FORCE: The <code>Composite</code> constant to indicate that an attribute (such as background) is inherited by all children.
As to the solution, I can only offer some things I've thought that might help. As I currently do not have the few days to experiment with this, these will have to stay only suggestions for now. One possibility would be to use Canvas.drawBackground(GC, int, int, int, int) method to copy canvas's background to the text buffer. before painting the text on top of it, thus creating a plausible illusion of transparency. Since I've never used the method before, I have no idea if this will work though. Another solution would be to actually paint the text on 2 images - one would be the full color image with a text and graphics as usual, another would be on a grayscale image and then inserting the grayscale image data into the text buffer image as an alpha channel, thereby creating the transparency. Third and maybe the best solution to this would be to alter the implementation of Image and GC in such a way that we could create a transparent image so start with and when drawing on the transparent image with GC, also modify the transparency of the pixels. In some ways, the second option seems to me the most reliable of three and I expect that in most cases, it would fit perfectly with most expectations. The extra double drawing step has me somewhat worried, but considering the sizes of the text n my use of FormText widget, I am not too concerned about it...
I'm not sure what to do next. For Eclipse 3.6 this is too late to be fixed, and even in 3.7 we don't have a committer assigned to work on forms, I have been fixing a few bugs myself but this looks like it might be complex and take more time than I have available. Do any of you feel like looking into creating a patch?
I took a look at the code, but I am afraid I do not have sufficient expertise with custom controls and painting techniques to be of much use on this. Perhaps part of the issue with resources is with bucketing this in UA. I understand that this is part of forms api which has seen drastic reduction in attention as of recent, but perhaps this control should be treated separately as it is very useful independent of forms context and base SWT/JFace provides nothing comparable?
Created attachment 177573 [details] Patch v1 I am attaching a partial fix to this bug. The patch contains the fix that will draw itself transparently when the parent has a background image or background color is set. I believe the only issue that's not addressed is Konstantin's example in which the FormText is added to the tab which on Window's XP is light grey.
Created attachment 177574 [details] Test case showing the fix Tab1 shows the existing behavior that was not fixed. Tab2 shows the fix.
Created attachment 177576 [details] Image before the patch
Created attachment 177577 [details] Image after the patch
Created attachment 177654 [details] Patch v2 I removed the double buffer draw in the paint callback and added DOUBLE_BUFFER style bit, plus a few minor fixes to make work. I tested on Windows XP only.
Created attachment 177655 [details] Repro v2 (full project zip) Repro project showing both problems that this patch is seeking to address: 1. FormText on custom drawn gradient. 2. FormText on TabFolder's TabItem.
Created attachment 177656 [details] Repro v2 (main java file)
Created attachment 177658 [details] After Patch (Windows 7)
Created attachment 177659 [details] Before Patch (Windows 7)
Could we get consideration for this patch for 3.6.1 release. This problem has been a collective pain in our behinds for a while now. Ling just spent about a week learning SWT custom draw, understanding this problem and producing this patch. I have updated the repro to show the two problem cases that have been described in this bug. The before and after captures show that the problem has been corrected and that the case where background color is explicitly set has not been compromised. This can be seen by observing that the lines labeled "adapted with FormToolkit" retain their white background regardless of placement. Ling, please download my revised repro and attach before/after captures on WinXP. Make sure to save them as png, not bmp. I will do the same for Linux.
Comment on attachment 177654 [details] Patch v2 The 'iplog' flag shall be applied after said attachment has actually contributed to the resolution of a bug. There is no need to flag it pre-emptively as the attachment may require additional revisions.
I'm going to commit this for Eclipse 3.7. I don't want to try to push this into 3.6.1 which is in the final stages, see http://www.eclipse.org/eclipse/development/plans/freeze_plan_3_6_1.php for the 3.6.1 endgame plan.
If it's too late for 3.6.1, what about 3.6.2? This is a very important fix for the adopter community. We cannot wait until 3.7 to have this resolved.
Created attachment 177751 [details] Before Patch (Linux Ubuntu 10)
Created attachment 177752 [details] After Patch (Linux Ubuntu 10)
Patch v2 applied to HEAD, Fixed.
Thanks, Chris. Could you comment on feasibility of releasing these changes into Helios SR2 stream? Should we open a separate bug to track that?
Can you open a new bug for Helios? To release into the Helios stream we would need additional approvals.
A new bug has been created: Bug 325908 - [Forms] [Helios] Allow FormText to be transparent
We've discovered that there is an issue with Patch V2 on Windows 7. The issue happens with <a> link in the form text during mouse over. The hover changes the text color and the text gets thicker and out of focus (probably because of anti-aliasing on Windows7, since this patch works in both XP and Linux) The issue is line 67 in TextHyperlinkSegment.java: gc.drawText(s, clipX, clipY, false); I have been unable to find a way to repaint just the background before drawing the text. Please revert patch v2 change until this issue is resolved.
I am re-opening this as it is important to revert the patch due to ill effect on Windows 7 systems. Doesn't seem to be a problem on WinXP and Linux, likely due to more primitive anti-aliasing algorithms (not using alpha channel blending). Haven't tried MacOS. There are two possible solutions that I see: 1. Request SWT API to trigger background re-painting prior to re-drawing the text. Ling, please open an enhancement request for this and post back the bug number. 2. Get rid of the on-hover color change behavior. It is on-hover re-painting that is causing anti-aliasing artifacts on Windows 7. On every re-paint, the text gets progressively thicker as transparent pixels at the edge of the text mix with previous text's anti-aliasing pixels. We are pursuing #2 in Sapphire by branching FormText as working transparent support in FormText is very important for our use cases. If there is general interest in getting rid of on-hover behavior globally as a trade-off for getting transparency, we can contribute that as a patch here.
I have opened Bug 332482 - [Forms] Revert Fix for Bug #284393 to track the reversion of the patch, I should be able to get to this before the end of the year.
(In reply to comment #49) > I have opened Bug 332482 - [Forms] Revert Fix for Bug #284393 to track the > reversion of the patch, I should be able to get to this before the end of the > year. *ping* Chris, did this make it's way into 3.7, any chance to get it into 3.7.1/3.8? Helmut
The fix did not make it into 3.7. Unfortunately UA forms is understaffed at the moment ( there is no full time committer ) and will likely continue to be that way, which is the main reason this did not make it into 3.7. This is a fairly complex section of code and it has been hard to create a patch that did not cause regressions.
(In reply to comment #51) > The fix did not make it into 3.7. Unfortunately UA forms is understaffed at the > moment ( there is no full time committer ) and will likely continue to be that > way, which is the main reason this did not make it into 3.7. This is a fairly > complex section of code and it has been hard to create a patch that did not > cause regressions. Thanks for the comment! :) Is there any way we could help, by testing a fix or something? Helmut
I've got the same problem with Label - it is not transparent (and also not listen to SWT.TRANSPARENT). I also tried to find another solution, but due to the hided LayoutComposite class or the protected computeSize-methode in ColumnLayout it is not possible. Sven
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. If the bug is still relevant, please remove the stalebug whiteboard tag.
