Community
Participate
Working Groups
Currently the description field uses the standard text widget. Upgrade it to use the text viewer support so that we get the nice copy/paste/etc menu and spell checking.
Agreed. Raphael: are you interested in taking this one on?
Yes, I would like to take it on. I've been working on a mechanism for adding description/summary lines with spell checking that can also be used in the wizards. e.g. the attach context and attach attachment wizard pages. In the end it would be nice if they could all use the same code to achieve a consistent UI.
Excellent! That sounds like a great idea. I imagine that it could be encapsulated with a special widget/editor like class, or with a factory that knows how to create the source viewer accordingly. Once you come up with the design could you post on bug so that Rob can give feedback? I also wanted to thank you for your contributions of late, they have been useful.
Raphael: please feel free to provide a patch for this if still interested.
Created attachment 83691 [details] Patch While implementing this Patch I noticed that when you open an local Task the Summery did not have the focus. But I did not find a way to fix this.
Created attachment 83692 [details] mylyn/context/zip
Frank, you patch changed summary control from a single line to multiline widget with a scroll bar, but it still takes a single line on screen, so it is probably not a good idea to use that. There is also a weird issue, though I think it was there before your patch. When you put very long text into the summary field, and then collapse and then collapse and expand again "personal planning" section, the summary field will be expanded beyond screen and editor will have ugly horizontal scrollbar. I am not sure how to fix that, but suspect that root of the problem is in FormPage.createPartControl() which creates ScrolledForm with both horizontal and vertical scrollbars enabled. The only way to fix that I can think of is to not use FormPage and make TaskFormPage directly extend EditorPart.
(In reply to comment #7) > Frank, you patch changed summary control from a single line to multiline widget > with a scroll bar, but it still takes a single line on screen, so it is probably > not a good idea to use that. Yes, consider sending SWT.FLAT | SWT.SINGLE to the construction of the summary viewer. > There is also a weird issue, though I think it was there before your patch. When > you put very long text into the summary field, and then collapse and then > collapse and expand again "personal planning" section, the summary field will be > expanded beyond screen and editor will have ugly horizontal scrollbar. I am not > sure how to fix that, but suspect that root of the problem is in > FormPage.createPartControl() which creates ScrolledForm with both horizontal and > vertical scrollbars enabled. The only way to fix that I can think of is to not > use FormPage and make TaskFormPage directly extend EditorPart. This is a long standing problem. Frank, try using an alternate layout on the summary to address this: GridDataFactory.fillDefaults().hint(summaryComposite.getSize().x - 100, SWT.DEFAULT).minSize(100, SWT.DEFAULT).grab(true, false) .applyTo(summary);
Created attachment 83703 [details] new version What is with this implementation. 1) Restrict the length in partEditor Title to 20 chars. If longer add "..." at the end 2) Restrict the length in TaskEditor HeaderForm to 40 chars. If longer add "..." at the end
Created attachment 83704 [details] mylyn/context/zip
(In reply to comment #9) > What is with this implementation. > 1) Restrict the length in partEditor Title to 20 chars. If longer add "..." at > the end > 2) Restrict the length in TaskEditor HeaderForm to 40 chars. If longer add "..." > at the end IMHO it is a very bad idea. this is an editable field and it should not be restricted because of the UI layout issues
(In reply to comment #11) > IMHO it is a very bad idea. this is an editable field and it should not be > restricted because of the UI layout issues No I did not truncate the summary editable field. In two other places the same text is used. But I now think that the trunc of the PartEditor Title should not be needed. This should be handeled by Eclipse. For the HeaderForm we have the problem that if you put in a large summary it get wrap to more then one line, so I think it is better to trunc tat text. Actually I did not know how to get the size of the HeaderForm. So calculate the char that fit in a line is not possible.
Patch applied, ip log updated. Modified patch by removing truncation of summary. Although not ideal, we would have to dynamically re-render the summary when the user resized the editor. This should actually be handled by platform.
Marking resolved.
