Community
Participate
Working Groups
The RCP will be a great platform for many different products. Some products will need an richtext editor (e.g. Email client, CRM products, Helpdesk systems, ...). The best way would be, if the eclipse project provided an richtext editor. The Look&Feel of the products would be similar and the machine resources would be less used. Needed Features: -> Multiline editor -> Different Fonts (include: Bold, Underline, Italic) -> Different colors (Foreground, Background) -> The text could contain Bullets (and enumeration) -> The text could contain Tables -> The text could contain Images -> The text could contain Attachments Data API: -> Get and set HTML -> Get and set MIME multipart (including HTML, Images and Attachments)
Moving to SWT for comment, and for consideration post 3.0. I know that some other teams are extending the Browser control to allow access to the Mozilla HTML editor functionality. Are there any plans to push this kind of support down to SWT, or to enhance StyledText to allow embedded images or other controls?
SN can you comment? (future)StyledText vs. Browser for doing this?
Taking ownership for now, but this isn't something will be addressed before 3.0.
We're not sure right now. There is a third approach that is to use the RichText editor that the platform provides (if there is one). Grant, there were other PR's that asked for enhancements to StyledText. They should be marked as duplicates of this.
*** Bug 48354 has been marked as a duplicate of this bug. ***
There is an internal HTML editor also in windows/ie6. Is the one every blog site is using and is triggered using a special iframe style property. So this could be the right way. Maybe, it's even possible to use it right now in SWT, with the right HTML code passed to the bowser widget and catching the post that results from a submit, at least under windows. But certainly it's not the same thing that having a setHtml getHtml ...
I've currently patched StyledText to support different fonts, with different sizes. I still have some problems with redraw since all the existing code assumed rows were all the same height, and all redraw optimization is based on row heights. Since row height calculations are quite CPU intensive, I implemented a small cache and have placed a flag to mimic the "old" behaviour : all lines with the same height. Althought the code still permits a lot of optimization, the first performance tests I've made are quite good. Also, I have some problem with word wrap. As soon as i solve this problems, I'm planning to implement left/right/center alignment and fixed indent with bullets (to make lists and similar stuff). Is anyone intrested? Does someone from the SWT team would be so kind to help me in this effort? Sometimes it tooks me hours to figure out where a certain operation takes place, while I'm sure a SWT guy would point me in the right direction in just a few moments. Please let me know.
Assigning to Felipe. We were considering adding multi-font to StyledText.
Simone, could you attach the code you have to this PR ? Thanks
Created attachment 14503 [details] My work on multifont This is what i've done to support multifont in StyledText. It actually works fine, also with word wrap, althought the code is not yet optimized and could be improved in many places. I've not tested printing features (i.e. the PrintRenderer), but i've tested the display part also under linux GTK and works fine. It has also been tested with "long" text (10K) and performs decently. As I told Felipe i'm planning to add also : - Per-line fixed pixel indent - Per-line bullet (this permits lists and similar stuff). - Per-line Left/Center/Right alignment I'll work on it in the next 2/3 weeks, since i need it anyway for an application of mine. It would be nice to cooperate on this! Ciao, Simone P.S. Sorry, i included the files and not a patch since it seems there are some problems on the net and the connection to CVS is extremely unstable. If you need another format than zip just let me know.
Some problems: 1) force bidi = true and notice how wrong the caret is 2) set a few styles with the same font name but different size, notice how the code fails in StyledTextRenderer#getFont(StyleRange) and always pick the first font with the same font name (ignoring the size), the fix is easy: use int fdef = (range.fontStyle << 16) + range.fontSize; instead of int fdef = range.fontStyle << 16 + range.fontSize; 3) after fixing 2, set a few styles with different sizes in the same line, add and remove some breaking lines typing Enter key and backspace/delete. Notice how the renderer fails and draw line on top of line. 4) Baseline is wrong - japanese, chinese, indic can be all wrong. 5) Not sure if the line heights cache is been reset properly. StyledText is probably the most important widget in SWT, we can not add bugs to it or make it performance any slower. Due the volume of changes is pretty hard to verified it. As far as design goes I not sure if we should add font name and font style to StyleRange or add a Font field. To decide this we will need SN and SSQ.
:) I was afraid after deeper testings bugs would arise. > 1) force bidi = true and notice how wrong the caret is This is because bidi carets are created using bitmaps, which are based on the line height (line 2327). It would require to create and set new bitmaps for every line. While the "normal" Caret can simply be adapted with a setSize (line 6746), this seems not to work when bitmaps are in place. >int fdef = (range.fontStyle << 16) + range.fontSize; >instead of >int fdef = range.fontStyle << 16 + range.fontSize; Ooops :D >3) after fixing 2, set a few styles with different sizes in the same line, > add and remove some breaking lines typing Enter key and backspace/delete. > Notice how the renderer fails and draw line on top of line. Yep, refactoring all the "linenumber * lineheight" to a dynamic line height calculation has been quite difficult, and surely we missed some places (they are 8000 lines of code :))). Anyway, it seems to happen only the first time the line break is typed, and only if the line is the last one. This is probably because the refresh rectangle is cached/calculated before actual text modification happens in the content, and at that time the renderer is returning height values for the OLD text and not yet for the new one. we've added 4 lastTextModification* explicitly to avoid this in many other situations. We'll try to figure out where this happen. > 4) Baseline is wrong - japanese, chinese, indic can be all wrong. I don't have this problem here (Wxp ita, gentoo kde gtk ita), except for some very exotic fonts that give the same problem in other softwares too. But maybe it'is in TextLayout construction, where all the TextLayout properties are set, that a proper calculation of the ascent and descent should take place (line 621 in renderer). > 5) Not sure if the line heights cache is been reset properly. Try to comment it out right now, just make it always do full calculations. This is a simple but central part, and if it's not completely functional can make all the rest work very badly. Surely you'll lose performace, however commenting it out in this phase solves point 3, since the old data is not cached and gets recalculated when the new line is rendered. > As far as design goes I not sure if we should add font name and font style > to StyleRange or add a Font field. To decide this we will need SN and SSQ. You're right, just kept on the safe side, to avoid creating tons of Font instances. > StyledText is probably the most important widget in SWT, we can not add bugs > to it or make it performance any slower. Due the volume of changes is pretty > hard to verified it. I do perfectly understand. Unfortunately the changes I've made are just the minimum amount needed, and great part of the time we had to test it has gone away in endless debug sessions trying to figure out where a certain thing takes place. We have scheduled three days of tests on it starting wednesday, and we'll test also bidi if we manage to find a suitable keyboard :D. We have to keep working on it anyway.
Simone, check out StyledText#LineCache, this is how StyledText caches line widths for computing the horizontal scrollbar length, how about move the line heights cache from the renderer to the lineCache ?
Created attachment 18391 [details] HTML editor for SWT-Win32 using native DHTMLEDIT control This is my work on an HTML editor under SWT using W32 DHTMLEDIT control. It is still quite rude, but does the job. The interface is quite simple and self explaining, also it (the interface) is platform independent, so that it is possible to implement the same control under linux or other platforms using the native HTML editing control (i know GTK has one, which is also quite similar to the MS one). Currently it works on W32 (98 and above) EXCEPT if the KB891781 security patch is installed (released 8 feb) ... people is still tying to investigate this : http://www.talkaboutsoftware.com/group/microsoft.public.inetsdk.programming.dhtml_editing/messages/11672.html http://forum.iamnotageek.com/t-816120.html (possible solution?) Please let me know what you think about it, I'm curretly using it to edit HTML, convert it to XHTML and then producing everything from it.
Is there any update on this? Also is this in regards to the Microsoft Rich Text Format or is it just for abilities in the StyledText widget?
Eclipse 3.1 M6 (API freeze) is only 10 days away. We don't have time to add more features. StyledText already has: bold, italic, underline and strikeout style; foreground and background; line background.
Is the API freeze the freeze for 3.1 or just for 3.1M6 and once 3.1M6 is released will there be an opportunity to add this functionality? Basically is this something that could get into 3.1 if the priority is high enough or will we be waiting for at least 3.2?
After Eclipse 3.1 M6 no more new APIs will be allowed. Visit: http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_1.html
As IBM bases their Workplace Client Technology projects on Eclipse, I'm sure they have a nice SWT rich text editor already. Maybe somebody could knock at the right door and ask for a donation?
See the new Text example shipping with GEF. Eventually we will add table support. Probably 3.2 release.
Here are some thoughts about the proposed HTML/RTF editor: 1. RTF editors for Linux are scarce and/or buggy/limited/broken. 2. Most people are used to the "features" of HTML. 3. It would take a long time to implement a text element which offers the same functionality as any decent browser (KHTML, Mozilla, IE). Basically, it would mean to reimplement existing work. 4. Mozilla is available on each platform and behaves exactly the same way. 5. IE is only available on Windows. Therefore, I would put my efforts into finishing/optimizing the StyledText component maybe with multi-font support and then move on to a Mozilla-based editor solution for anything which needs more than that. This would allow to concentrate on integrating the editor component into the SWT frame while all the really ugly things (cross-platform behavior, complicated layouts, embedding components, etc) are already solved. This should allow to have a great any-purpose text editor finished in 3.2.
In reference to Comment #21. I am assuming that you are proposing that Mozilla would have to be installed on the system in order for this Rich Text editor to work. If what you are proposing is that the requisite parts of Mozilla be bundled in with SWT in order to support this feature then my comment does not pertain. My concern with this idea is the an SWT application that uses the Rich Text widget would require that Mozilla be installed and would either fail or have to gracefully devolve functionality if it is not available. For many projects we do not have sufficient control over the target environment to require that additional components be installed. This would leave many with still not usable Rich Text widget.
Personally I'd be a little hesitant to make this dependant upon any browser. With the usage of any specific browser it would require that this be installed on any machine wanting to utilize the rich editor. Mozilla isn't installed on the majority of desktops by default and would have to be made a part of the install of SWT. That might not be a big deal, I don't know but the SWT broswer implementation would have to allow for the usage of multiple browsers because some may want to use IE at times as well, at least on windows. Also users are familiar with HTML but they want Word. Keyboard shortcuts also seemed to be a point where a browser and a rich text editor differ. It's been a while but I thought that in a broswer there was a limited amount of keys that actually get sent to the page. Can you receive CTRL, ALT, and Function keys in a page?
We are working on improving StyledText right now, we plan to have this fixed by 3.2 M3. Note: StyledText is pure java, it doesn't depend on the browser or anything.
MY first try was a modification of StyledText to support at least multifont, planning to add then other behaviours. Anyway, this IS a reimplementation of existing stuff, since under windows you can always count on IE being installed and thus on the DHTMLEDIT activex, while under linux i bet you have a high percentage with Mozilla on, since it's also required by the browser widget. So, the second file I attached is an implementation of a full featured HTML editor based on DHTMLEDIT activex but with a platform independent interface. So, it could be a good idea to implement this interface, eventually adapting and expanding it, but using existing HTML editor of mozilla, the same many on-line editors uses. Also, it seems like the mozilla ones behaves very similar to the activex one, so maybe it could be a quite simple work. Regarding RTF, once you have editor informations in HTML, it's possible to save it as XHTML, RTF, whatever.
StyledText was improved dramatically for 3.3. Many of the features requested in this bug report were fixed. Please enter separate bug reports for each particular feature that is missing. Thanks.
(In reply to comment #26) > StyledText was improved dramatically for 3.3. Many of the features requested > in this bug report were fixed. Please enter separate bug reports for each > particular feature that is missing. Thanks. > Is there documentation to this effect? I'm looking at the New & Notworthy for 3.3 M1 and M2, and there's only a brief mention of StyledText on the 3.1 page (http://www.eclipse.org/swt/R3_3/new_and_noteworthy.html).
take a look in the snippet pages: http://www.eclipse.org/swt/snippets/
I think Grant meant 3.2.
(In reply to comment #29) > I think Grant meant 3.2. I think Eclipse 3.2 has already supported the mixed fonts. Is is it?
> I think Eclipse 3.2 has already supported the mixed fonts. Is is it? yes
