No RichEdit20A window class

Krzysztof Foltman kfoltman at
Sat Nov 27 10:34:32 CST 2004

Mike McCormack wrote:

> 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.

I may send the source code to people who are potentially interested, so 
that it may get taken over if I get very busy or bored of it, and so 
they can make up their minds about if the design and the actual code is 
good enough for WINE.

> 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,

I think I'll dual license it (LGPL/BSD). I can think of some closed 
source applications (freeware or not) that would definitely benefit from 
a free rich text editor that doesn't suck as much as RICHEDIT20 does. 
However, "straight" LGPL would be OK too, if BSD puts anybody off.

> so long as you are the sole author.

That's where part of the problem is: as long as someone sends me just a 
"Ctrl-arrow" patch, I can always be suspected of stealing that patch. It 
puts me in a very uncomfortable position.

> 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.

I'm not going to wait until it's finished, I just don't want people to 
add features that must be removed or rewritten a week later because of 
half of functions have their parameters changed.

For example, adding Undo functionality from scratch after everything 
else is done would be a disaster.

> 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.

Another reason not to accept patches just now. Luckily, a commercial 
version (made for particular use in two or three applications of a 
particular company) will be actually very simple, having little more 
features than it has now, and no RICHEDIT API at all. After that, I may 
safely fork the source.

> 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.

That's what I'm afraid of, too. I'm currently thinking of solutions for 
that problem.

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

I agree, this project has a lot of space for collaboration. For example, 
achieving high degree of compatibility with RICHEDIT will require a lot 
of reverse engineering and finetuning. However, doing advanced features 
with basic architecture screwed up is not going to work.


More information about the wine-devel mailing list