Bugzilla – Full Text Bug Listing
| Summary: | Spurious change events fired by the HtmlComposer | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Robert Munteanu <robert.munteanu> | ||||||
| Component: | Mylyn | Assignee: | Tom Seidel <tom.seidel> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Tom Seidel <tom.seidel> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | ||||||||
| Version: | 1.4 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| URL: | http://dev.eclipse.org/mhonarc/lists/mylyn-docs-dev/msg00018.html | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
The problems you described have different sources. Wrapping code in paragraphs: This is a configuration of the underlying ckeditor and can be disabled in the config. To disable automatic wrapping add the following lines to your /org.eclipse.mylyn.htmltext/ckeditor/config.js: config.enterMode = CKEDITOR.ENTER_BR; config.shiftEnterMode = CKEDITOR.ENTER_BR; HTML-Entities: Same as above, add the following line: config.entities = false; Additional newlines: This is probably a bit more complicated. There is no guarantee that you'll get exactly the same string via #getHtml that you have set in your #setHtml function. This is the nature of the underlying component. It will format the html based on given so-called writer-rules, which can be customized, see http://docs.cksource.com/CKEditor_3.x/Developers_Guide/Output_Formatting This has the advantage that the input is checked on a DOM-Level to provide some html-cleanup, for example composer.setHtml("<pre>Test"); composer.getHtml() // would return "<pre>Test</pre>" In this special case you could disable the newline with adding the following lines to your /org.eclipse.mylyn.htmltext/eclipsebridge/base.html CKEDITOR.on('instanceReady', function(ev) { var tags = ['pre']; // etc. for (var key in tags) { ev.editor.dataProcessor.writer.setRules(tags[key], { indent : false, breakBeforeOpen : true, breakAfterOpen : false, breakBeforeClose : false, breakAfterClose : false }); } }); The drawback is that you have to modify the files of the htmltext bundle, there is already Bug 332307 which describes the problem, but it should be a valid workaround for the moment. Your listener problem is a bug. We're already waiting for the initialization but are ignoring the point in time the modifylistener is added. For clarification: htmlComposer = new HtmlComposer(parent, SWT.NONE); htmlComposer.setHtml("Test"); htmlComposer.addModifyListener(new ModifyListener() { @Override public void modifyText(ModifyEvent e) { // This is fired, although it shouldn't } }); In addition the initialization state of the editor is not relevant, e.g. htmlComposer = new HtmlComposer(parent, SWT.NONE); htmlComposer.addModifyListener(new ModifyListener() { @Override public void modifyText(ModifyEvent e) { // This must be fired, although the editor is not initialized } }); htmlComposer.setHtml("Test"); I see no workaround ATM, this must be fixed... Created attachment 191942 [details]
Patch for the modify-listener management
Thanks for the reply and patch. A few comments below (In reply to comment #1) > The problems you described have different sources. > > Wrapping code in paragraphs: > This is a configuration of the underlying ckeditor and can be disabled in the > config. > > To disable automatic wrapping add the following lines to your > /org.eclipse.mylyn.htmltext/ckeditor/config.js: > > config.enterMode = CKEDITOR.ENTER_BR; > config.shiftEnterMode = CKEDITOR.ENTER_BR; > > HTML-Entities: > Same as above, add the following line: > > config.entities = false; > > Additional newlines: > This is probably a bit more complicated. There is no guarantee that you'll get > exactly the same string via #getHtml that you have set in your #setHtml > function. This is the nature of the underlying component. It will format the > html based on given so-called writer-rules, which can be customized, see > http://docs.cksource.com/CKEditor_3.x/Developers_Guide/Output_Formatting > > This has the advantage that the input is checked on a DOM-Level to provide some > html-cleanup, for example > > composer.setHtml("<pre>Test"); > composer.getHtml() // would return "<pre>Test</pre>" > > In this special case you could disable the newline with adding the following > lines to your /org.eclipse.mylyn.htmltext/eclipsebridge/base.html > > CKEDITOR.on('instanceReady', function(ev) > { > var tags = ['pre']; // etc. > > for (var key in tags) { > ev.editor.dataProcessor.writer.setRules(tags[key], > { > indent : false, > breakBeforeOpen : true, > breakAfterOpen : false, > breakBeforeClose : false, > breakAfterClose : false > }); > } > }); > > The drawback is that you have to modify the files of the htmltext bundle, there > is already Bug 332307 which describes the problem, but it should be a valid > workaround for the moment. I see. Then I will probably need to wait for the bug to be solved . I am going to mark the HtmlText integration as experimental and it will be opt-in, so there's no harm in _some_ minor changes being added. > > Your listener problem is a bug. We're already waiting for the initialization but > are ignoring the point in time the modifylistener is added. For clarification: > > htmlComposer = new HtmlComposer(parent, SWT.NONE); > htmlComposer.setHtml("Test"); > htmlComposer.addModifyListener(new ModifyListener() { > > @Override > public void modifyText(ModifyEvent e) { > // This is fired, although it shouldn't > } > }); > > In addition the initialization state of the editor is not relevant, e.g. > > htmlComposer = new HtmlComposer(parent, SWT.NONE); > htmlComposer.addModifyListener(new ModifyListener() { > > @Override > public void modifyText(ModifyEvent e) { > // This must be fired, although the editor is not initialized > } > }); > htmlComposer.setHtml("Test"); > > I see no workaround ATM, this must be fixed... You created a patch below. Is there a quick guide on how to apply it and build the bundle? Last time I tried to build the Docs features I needed to check out the all of Mylyn and I gave up. (In reply to comment #3) > You created a patch below. Is there a quick guide on how to apply it and build > the bundle? Last time I tried to build the Docs features I needed to check out > the all of Mylyn and I gave up. I checked out the bundle via EGit, but the Patch-generation did not work properly with EGit for me. So I used tortoise-git for the creating the patch. This patch can be applied easily via tortoise-git, I checked out only the Mylyn docs projects, so there is no need for the rest of Mylyn. I don't know which tooling is the best for Linux, but using a normal GIT client should work.. The htmlcomposer doesn't have any dependencies to other Mylyn bundles, so a normal export through your IDE should work. Sorry for taking so long to respond. I applied the patch and I no longer get have initialisation problems. Thanks! I had the chance to work further with HtmlText and the formatting toolbar from the example project, and I noticed a difference between the 0.7.0 bundle and the latest 0.8.0 bundle with the patch applied. When clicking on a toolbar item , the change is applied on the selected text with 0.7.0 but not with 0.8.0 . Furthermore, in neither case are any NodeSelectionEvents fired, which is the probable cause of the buttons' state not reflecting the current selection , i.e. when the selected text is bold the bold button is not 'pushed'. I did not open another bug since I'm not sure if this is indeed an error, please let me know if I should do that. Created attachment 193786 [details]
Patch 2
Yes, I could reproduce the problem. Small bug, I created another path which can be applied.
If that will resolve the problems, I'll push the two patches to the master..
Yes, the formatting toolbar works perfectly now for 0.8.0 . I still have some minor issues but I'll post on the email group to make sure they are actual bugs. pushed the patches to master, markin as fixed |
I've been investigating the use of the HtmlComposer as an attribute editor for the MantisBT connector for Mylyn. So far it looks quite promising. I have one stumbling block though - finding out when the composer is fully initialised, so that I can mark attributes as dirty. I am using code similar to: bc. composer.addModifyListener(new ModifyListener() { public void modifyText(ModifyEvent e) { String oldValue = getAttributeMapper().getValue(getTaskAttribute()); String newValue = composer.getHtml(); getAttributeMapper().setValue(getTaskAttribute(), newValue); boolean attributeChanged = oldValue != "" && !(newValue.equals(oldValue)); if ( attributeChanged ) attributeChanged(); } }); The problem is that I'm seeing spurious changes which seem to be internal to the HtmlComposer, for instance: * from <pre>Wow</pre> to <pre>Wow</pre>\n ( extra newline ) * from <b>Oops</b> to <p><b>Oops</b></p> ( wrapped in <p></p> ) * from Let's see how this works. to <p>Let's see how this works.</p> ( wrapped in<p></p>, encode entities ) I am interested in skipping these events, so want to find out whether I can register for events later on, after the editor is fully initialised, or find out if the events are internal.