No RichEdit20A window class

[Mike McCormack]

I have been working on richedit a little also, and am quite keen to get 
the ball rolling by having some richedit 2.0 code in winehq that others 
can help work on it.  I'm quite interested to see the source for this.

Whether you show us or not, the copyright for the source still belongs 
to you.  If you choose to license it under LGPL, then you can still 
release it under a different license later, so long as you are the sole 
author.

I think you'll find that the development proceeds much quicker if you 
release your source, and get it integrated into the Wine tree sooner 
rather than later.  People will submit patches fixing your code, and new 
features.

When you do release your "completed" riched20 code, LGPL patches will 
still be submitted against it, and you'll experience the same licensing 
problems if you wish to incorporate other people's code.

Frankly speaking, people promising to release their source code "at a 
later date" is an impedement to development, because nobody is motivated 
to work on the promised feature in the mean time.

Please consider "release early, release often", so we can work together 
on this :)

Mike


Krzysztof Foltman wrote:
> Just for the record, I'm still trying to develop a "proper" RichEdit 
> control. I've written from scratch with RichEdit compatibility in mind, 
> so I don't expect any copyright or suitability problems. At least, 
> unless I screw something up or I'm less smart than I think.
> 
> If someone isn't afraid of running closed-source .exe from barely known 
> developer (or can run it in a controlled environment), you can find the 
> latest binary at:
> 
>    http://foltman.com/riched.zip
> 
> I'm not releasing the source yet, because I don't think it's hackable, 
> until at least its architecture is complete. What's more, I'm planning 
> to license a heavily modified derived product comercially to some 
> company (a rich text viewer/editor tailored for a specific application), 
> so any copyright-related problems are undesirable.
> 
> What IS done:
> 
> - basic text wrapping with support for proportional fonts and character 
> formatting, no major known bugs (the only supported attribute is Bold, 
> but the rest will be relatively easy to add)
> - simple editing (typing text, backspace, delete, no overwrite mode yet)
> - a very incomplete implementation of Shift-arrow selection (done in a 
> few  hours yesterday :-) ), mouse operations don't support selection yet
> - per-paragraph alignment
> - pitiful low-level style management
> - bold attribute
> - some basic optimizations (avoiding rewrapping unmodified paragraphs 
> unless editor window is resized)
> - uses UNICODE internally (not necessarily a good thing)
> 
> What isn't done:
> 
> - RichEdit API (which is a mess; I'm taking care of it in order to 
> ensure compatibility wrt how editing functions work, however, basic 
> editing functionality is the number one priority, as it's more difficult 
> to achieve)
> - RTF interface
> - Undo
> - Clipboard
> - tabs
> - bulleted lists
> - setting paragraph attributes (margins are implemented internally but 
> can't be changed with current interface, setting alignment by Ctrl+L/E/R 
> works)
> - all RichEdit f3 functionality
> - MBCS support (and it would be very hard to add)
> - BiDi and CTL support (ditto)
> - everything not mentioned in the first list
> 
> Krzysztof
>