Community
Participate
Working Groups
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.
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
