Bugzilla – Full Text Bug Listing
| Summary: | make Bugzilla URL link clickable | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | sam <s.marshall> | ||||||||||||
| Component: | Mylyn | Assignee: | Eugene Kuleshov <ekuleshov> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||
| Severity: | enhancement | ||||||||||||||
| Priority: | P3 | CC: | daniel_megert, robert.elves, wmitsuda | ||||||||||||
| Version: | unspecified | ||||||||||||||
| Target Milestone: | 3.0 | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Windows XP | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Attachments: |
|
||||||||||||||
+1 Rob: do we already have a bug for this? Lets keep this one open to target that field specifically. But both the url field and the summary field will be hyperlinked as soon as I convert them over to our viewer widget (pending resolution of layout issues). (summary field is bug#155278). Created attachment 78400 [details]
proposed patch
This makes url field in bugzilla clickable.
Someone may want to do some refactoring for addTextEditor() methods to reuse change listeners and incoming decoration as in addTextField()...
Created attachment 78401 [details]
mylyn/context/zip
Patch reviewed but not applied. With my testing this had the regression of not setting the incoming background color. There appears to be a bit of blue background added, but the text is not blue. Also, this changes the visual style of the URL box not to match the others. As that may be necessary, I wonder if it's position in the Attributes section should be moved to preserve visual consistency. (In reply to comment #6) > Patch reviewed but not applied. With my testing this had the regression of not > setting the incoming background color. There appears to be a bit of blue > background added, but the text is not blue. Right. It seems like this is result of hyperlinking/annotation decoration coloring and after quick look I couldn't figure out how to get around that. > Also, this changes the visual style of the URL box not to match the others. As > that may be necessary, I wonder if it's position in the Attributes section > should be moved to preserve visual consistency. Mik, can you please elaborate about visual style and/or post screenshot of what you mean? If you are speaking about hyperlink presentation that is underlined/activated by default with this change, that supposed to be tracked on bug 203399 Speaking of consistency, I just discovered that there is a hidden time management subsection in Bugzilla editor that is not visible on eclipse.org bugzilla. Note that this hidden section is NOT using flat form look and the whole section don't seem to belong under Attributes section. By "visual style" I meant that the box for entering the value looked different than the other boxes. I wasn't citing that as a problem per se, because this box now had additional functionality, just saying that if it's going to look inconsistent it should be moved. That hidden attributes section only works if time tracking is enabled on the Bugzilla repository. (In reply to comment #8) > By "visual style" I meant that the box for entering the value looked different > than the other boxes. I wasn't citing that as a problem per se, because this > box now had additional functionality, just saying that if it's going to look > inconsistent it should be moved. Can you please post screenshot of that? I don't see any visual difference in Eclipse 3.3 and Win XP > That hidden attributes section only works if time tracking is enabled on the > Bugzilla repository. I know that, but that ain't an excuse for not using SWT.FLAT :-) My 10minutes weren't enough to get the background to change properly either. Willian: do you know the trick to this? Also note that instead of making colorIncoming protected you can just use getColorIncoming(). Created attachment 79842 [details]
updated patch
Rob, here is updated patch for conflicting changes in CVS and with cahnge you suggested. Issue with the background is still not resolved.
Daniel, I am sorry to bother you, but maybe you can give us a hint?
There is a SourceViewer with spellchecking decoration and standard hyperlinking enabled and we need to set non white background on that widget.
We tried to get text control and then use setBackground() method, but that doesn't work and it seem like background is covered by something that is drawing decoration over that control.
SourceViewer is created in org.eclipse.mylyn.tasks.ui.editors.TaskFormPage.addTextEditor() method. There is also Mylyn context attached that include relevant classes.
Created attachment 79843 [details]
mylyn/context/zip
>We tried to get text control and then use setBackground() method,
This should work i.e. the source and text viewers don't set the background color - that's at the level of editors. Maybe the text is selected and hence you don't see your color? Maybe you added an annotation and it draws on top of it?
Thanks Daniel, I also though that it could be something with decorations, but I am not sure how to debug that. Do you know if there are any limitations around using multiple source viewers within same form? Rob, I tried to look at it again and now I am totally puzzled. If you look at the summary field, which is created using the same TaskFormPage.addTextedtior() method as I used for url field, so code is identical. But then summary field is rendered just fine (you can stick url to summary to verify that it is highlighted properly), but for url field we have this weird rendering where only thin border is around url field is being highlighted. Hi Eugene, what does #addTextEditor do? Is it maybe adding a LineBackgroundListener or LineStyleListener? Here are two interesting points to start debugging: - org.eclipse.swt.custom.StyledText.handlePaint(Event) - org.eclipse.swt.custom.StyledTextRenderer.getLineBackground(int, Color) Created attachment 79954 [details] wrong source viewer rendering (In reply to comment #15) > what does #addTextEditor do? Is it maybe adding a LineBackgroundListener or > LineStyleListener? It creates initialized instance of the SourceViewer. You can look at the source code at http://tinyurl.com/3a8hk7 > Here are two interesting points to start debugging: > - org.eclipse.swt.custom.StyledText.handlePaint(Event) > - org.eclipse.swt.custom.StyledTextRenderer.getLineBackground(int, Color) I checked those and can see that my widget has the right background color in handlePaint() and getLineBackground() returns the same color, but widget is drawn with the white background. On attached screenshot you can see that summary text is rendered correctly with blue background, but "URL" field only have 1px thin blue border instead of the solid blue background. It could be the cursor line painter (depending on which source viewer config and which prefs you use). (In reply to comment #17) > It could be the cursor line painter (depending on which source viewer config and > which prefs you use). Can you give me a pointer how to trace cursor line painter? BTW, widget is created with SWT.SINGLE This viewer config is a subclass of org.eclipse.ui.editors.text.TextSourceViewerConfiguration http://tinyurl.com/26mvzz and it gets preferences from the EditorsUI.getPreferenceStore() >Can you give me a pointer how to trace cursor line painter? org.eclipse.jface.text.CursorLinePainter.lineGetBackground(LineBackgroundEvent) But this will only play a role if you've also setup source viewer decoration support along with the correct preference keys i.e. called org.eclipse.ui.texteditor.SourceViewerDecorationSupport.setCursorLinePainterPreferenceKeys(String, String) >BTW, widget is created with SWT.SINGLE You're probably the first one to try this out with a viewer ;-) Try without and see what happens. I give up on this. Can't make it work I found why it is not working. For some reason, the color settings from enclosing Section widget is interfering with TextViewer background color setting.
Just for testing, if you apply the following patch after applying Eugene's one, it will work as expected. If you use ExpandableComposite.TITLE_BAR style on FormToolkit.createSection, it triggers a lot of color settings I was not able to understand yet.
### Eclipse Workspace Patch 1.0
#P org.eclipse.mylyn.tasks.ui
Index: src/org/eclipse/mylyn/tasks/ui/editors/AbstractRepositoryTaskEditor.java
===================================================================
RCS file: /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.tasks.ui/src/org/eclipse/mylyn/tasks/ui/editors/AbstractRepositoryTaskEditor.java,v
retrieving revision 1.241
diff -u -r1.241 AbstractRepositoryTaskEditor.java
--- src/org/eclipse/mylyn/tasks/ui/editors/AbstractRepositoryTaskEditor.java 26 Oct 2007 03:36:28 -0000 1.241
+++ src/org/eclipse/mylyn/tasks/ui/editors/AbstractRepositoryTaskEditor.java 2 Nov 2007 23:37:17 -0000
@@ -2492,7 +2492,7 @@
}
protected Section createSection(Composite composite, String title) {
- Section section = toolkit.createSection(composite, ExpandableComposite.TITLE_BAR | Section.TWISTIE);
+ Section section = toolkit.createSection(composite, Section.TWISTIE);
section.setText(title);
section.setExpanded(true);
section.setLayout(new GridLayout());
Daniel, can you explain how a parent color setting (in this case, a form toolkit Section widget) may interfere in a child TextViewer rendering?
The following sample view reproduces the same situation with minimum code:
public class SampleView extends ViewPart {
private SourceViewer viewer;
@Override
public void createPartControl(Composite parent) {
ManagedForm mf = new ManagedForm(parent);
mf.getForm().setLayoutData(GridDataFactory.fillDefaults().grab(true, true).create());
Composite body = mf.getForm().getBody();
body.setLayout(new GridLayout());
Section section = mf.getToolkit().createSection(body, ExpandableComposite.TITLE_BAR | Section.TWISTIE);
section.setText("Test");
Composite composite = mf.getToolkit().createComposite(section, SWT.NONE);
composite.setLayoutData(GridDataFactory.fillDefaults().grab(true, true).create());
composite.setLayout(new GridLayout());
section.setClient(composite);
viewer = new SourceViewer(composite, null, SWT.NONE);
viewer.getControl().setLayoutData(GridDataFactory.fillDefaults().grab(true, true).create());
viewer.configure(new TextSourceViewerConfiguration());
Document doc = new Document("bababa\rbobobo");
viewer.setDocument(doc);
viewer.getControl().setBackground(Display.getDefault().getSystemColor(SWT.COLOR_GREEN));
}
@Override
public void setFocus() {
viewer.getControl().setFocus();
}
}
This view contains a TextViewer with a green background inside a expandable section. It will only be rendered with the green background if you remove ExpandableComposite.TITLE_BAR from "Section section = mf.getToolkit().createSection(..." call.
Just revisited this and seems to work now (background colour being set properly). Fixed layout (width) issue. Fixed (In reply to comment #22) > Just revisited this and seems to work now (background colour being set > properly). Fixed layout (width) issue. Thats great Rob! Did you had a chance to check it with both Eclispe 3.3 and 3.4? Tested fine on 3.4, still fails on 3.3 (note added to code warning not to backport to 3.3). |
(I am using whatever Mylar version you get if you download today. Eclipse 'About' box gives it as version 1.0.0, but that isn't listed in the version box above.) When viewing a bug from Bugzilla it displays the URL field as an edit box, which is fine. However it would be nice if the label ('URL') next to the field was an underlined, clickable link which would launch the user's default browser [as per Eclipse preferences]. Current use: 1) View bug 2) Expand 'Attributes' 3) Click in URL field 4) Press Ctrl-A, Ctrl-C 5) Switch to external browser program 6) Open new window or tab 7) Press Ctrl-V, Return (Now viewing URL in preferred browser) Use after proposal implemented: 1) View bug 2) Expand 'Attributes' 3) Click the underlined label 'URL' (URL launches in preferred browser)