No RichEdit20A window class
kfoltman at portal.onet.pl
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
> 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