Re: No RichEdit20A window class
Krzysztof Foltman wrote: Mike McCormack wrote: ... 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. Perhaps a suggestion... ask that for some period of time, people who submit patches against your code do so under a BSD or X11 license. Wine itself was under an X11 style license for quite a few years, so that probably won't scare too many people off. Be specific (and reasonable) about the period of time, though.
Re: No RichEdit20A window class
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. Krzysztof
Re: No RichEdit20A window class
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
Re: No RichEdit20A window class
Shachar Shemesh wrote: - MBCS support (and it would be very hard to add) Then you are doing something very wrong. Aren't you working in Unicode? I am. However, I've assumed that one character = one wchar_t, and there are no prefix/suffix non-printable characters. However, I'm speaking about encodings where character size may vary depending on a character. Like using utf-8 internally. All string operations (even benign ones like calculating number of characters) become much more complex, instead of O(1) mapping between character index (in characters) and character offset (in bytes or words), we have O(N). Chris
Re: No RichEdit20A window class
Krzysztof Foltman wrote: - MBCS support (and it would be very hard to add) Then you are doing something very wrong. Aren't you working in Unicode? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: No RichEdit20A window class
James Hawkins wrote: I just want to make sure I've got this right. So we need to implement riched20, and then forward requests from riched32 to riched20 because riched20 supercedes riched32? Right. The current implementation of riched32 is Wrong(tm). We'll implement riched20 from scratch and do it the right way. When it's good enough, we can then rewrite riched32 to use the riched20 control instead of the edit control. All that can be done in small incremental improvements, which is the key to making cooperative development work. Mike
Re: No RichEdit20A window class
I just want to make sure I've got this right. So we need to implement riched20, and then forward requests from riched32 to riched20 because riched20 supercedes riched32? On Sat, 20 Nov 2004 11:46:12 +0900, Mike McCormack <[EMAIL PROTECTED]> wrote: > > James Hawkins wrote: > >>which is why this code is not in WineHQ. > > > > > > What is it exactly that is keeping this code out of wine? Just > > curious because if it's something that just needs to be worked on, we > > should let developers know so we can get started on that. > > The current riched32 is wrong. It should not be based on the edit > control. While it is, no incremental improvement is possible. The code > I sent in the previous mail is not going in to WineHQ any time soon, so > that somebody will have motivation to fix Richedit 2.0 properly, which > is the path forward for Richedit 1.0 also. > > Mike > -- James Hawkins
Re: No RichEdit20A window class
James Hawkins wrote: which is why this code is not in WineHQ. What is it exactly that is keeping this code out of wine? Just curious because if it's something that just needs to be worked on, we should let developers know so we can get started on that. Like most things that are in CrossOver, but not in Wine, it is a hack that are encourages working around the problem rather than fixing the cause of the problem. The solution is to start work on a skeleton control, perhaps that just has some basic drawing functionality and not much else. Then gradually extend it to become the mini word processor it actually is. Rob
Re: No RichEdit20A window class
James Hawkins wrote: which is why this code is not in WineHQ. What is it exactly that is keeping this code out of wine? Just curious because if it's something that just needs to be worked on, we should let developers know so we can get started on that. The current riched32 is wrong. It should not be based on the edit control. While it is, no incremental improvement is possible. The code I sent in the previous mail is not going in to WineHQ any time soon, so that somebody will have motivation to fix Richedit 2.0 properly, which is the path forward for Richedit 1.0 also. Mike
Re: No RichEdit20A window class
> which is why this code is not in WineHQ. What is it exactly that is keeping this code out of wine? Just curious because if it's something that just needs to be worked on, we should let developers know so we can get started on that. On Sat, 20 Nov 2004 10:16:39 +0900, Mike McCormack <[EMAIL PROTECTED]> wrote: > > Hi Michael, > > > This isn't quite clear to me. It sounds like you are saying there is a > > riched20.dll in wine, but I can't find one. > > No, there's no riched20.dll implementation in Wine as yet. > > > Are these statements correct? > > > > * Wine's only implements RichEdit10A via riched32.dll. Wine does not > > implement RichEdit20A. > > Right. > > > * Win2K (and later) provides riched20.dll which implements > > RICHEDIT_CLASS20A. This one I can verify as true on my winxp system. > > Right. > > > * There are significant differences between the two window classes > > RICHEDIT_CLASS20A extends RichEdit10A ... so it supercedes it. > > > My winelib app is hosting a 3rd party DLL which is specifically > > requesting "RichEdit20A". That suggests that the DLL was built with > > win2K or later, from what you were saying. Sounds like my options are > > to: > > > > * hack their request to use the window class registered by wine's > > riched32.dll. How well could I expect this to work? How big are the > > diffs between 10A and 20A? > > I think that would probably work. > > > * get them to provide win2k's riched20.dll > > My preference is always to fix Wine... > > > * have them change their DLL to ask for RichEdit10A instead > > Yes, that would work. > > > * implement riched20.dll in Wine. Sounds like a big job! > > Yes, it's a big job, but once the correct skeleton is in place, people > will extend it. > > > Sound right? Any comments? Thanks a bunch... mo > > We have an empty implementation of riched20 that simply forwards > requests to edit. That is the wrong, and the existing riched32 code is > broken too (since it uses the edit control). > > CrossOver's riched20 code is attached... it's a quick and easy way to > fix the problem, but the correct, longterm solution for Wine is to > implement riched20.dll properly and then forward requests from riched32 > to riched20 rather than the edit control, which is why this code is not > in WineHQ. > > It depends how nice you want it to look... > > Mike > > > -- James Hawkins
Re: No RichEdit20A window class
Hi Michael, This isn't quite clear to me. It sounds like you are saying there is a riched20.dll in wine, but I can't find one. No, there's no riched20.dll implementation in Wine as yet. > Are these statements correct? * Wine's only implements RichEdit10A via riched32.dll. Wine does not implement RichEdit20A. Right. * Win2K (and later) provides riched20.dll which implements RICHEDIT_CLASS20A. This one I can verify as true on my winxp system. Right. * There are significant differences between the two window classes RICHEDIT_CLASS20A extends RichEdit10A ... so it supercedes it. My winelib app is hosting a 3rd party DLL which is specifically requesting "RichEdit20A". That suggests that the DLL was built with win2K or later, from what you were saying. Sounds like my options are to: * hack their request to use the window class registered by wine's riched32.dll. How well could I expect this to work? How big are the diffs between 10A and 20A? I think that would probably work. * get them to provide win2k's riched20.dll My preference is always to fix Wine... * have them change their DLL to ask for RichEdit10A instead Yes, that would work. * implement riched20.dll in Wine. Sounds like a big job! Yes, it's a big job, but once the correct skeleton is in place, people will extend it. Sound right? Any comments? Thanks a bunch... mo We have an empty implementation of riched20 that simply forwards requests to edit. That is the wrong, and the existing riched32 code is broken too (since it uses the edit control). CrossOver's riched20 code is attached... it's a quick and easy way to fix the problem, but the correct, longterm solution for Wine is to implement riched20.dll properly and then forward requests from riched32 to riched20 rather than the edit control, which is why this code is not in WineHQ. It depends how nice you want it to look... Mike riched20.tar.gz Description: Unix tar archive
Re: No RichEdit20A window class
--- Michael Ost <[EMAIL PROTECTED]> wrote: > On Fri, 2004-11-19 at 03:22, Mike McCormack wrote: > > Michael Ost wrote: > > > > > (1) The wine bug (I think) is that riched32.dll is registering the wrong > > > window class name. Here's a suggested patch: > > > > RICHEDIT_CLASS20A is provided by riched20.dll, not riched32.dll. The > > windows 2000 implementation uses riched20.dll to implement riched32.dll > > (ie. moves the richedit code to riched20.dll and implements the > > RICHEDIT_CLASS10A class using the new RICHEDIT_CLASS20A class. > > > > In short, the existing code registers the correct class name, but we > > need to make a new dll dlls/riched20, and do alot of work on the > > richedit control :) > > This isn't quite clear to me. It sounds like you are saying there is a > riched20.dll in wine, but I can't find one. Are these statements > correct? > He's saying that "riched32.dll in wine registers the correct class name, which is RICHEDIT_CLASS10A. To implement RICHEDIT_CLASS20A, we need to make another dll, that is, riched20.dll" > * Wine's only implements RichEdit10A via riched32.dll. Wine does not > implement RichEdit20A. > > * Win2K (and later) provides riched20.dll which implements > RICHEDIT_CLASS20A. This one I can verify as true on my winxp system. > > * There are significant differences between the two window classes > I think all 3 statements are correct. > My winelib app is hosting a 3rd party DLL which is specifically > requesting "RichEdit20A". That suggests that the DLL was built with > win2K or later, from what you were saying. Sounds like my options are > to: > > * hack their request to use the window class registered by wine's > riched32.dll. How well could I expect this to work? How big are the > diffs between 10A and 20A? > > * get them to provide win2k's riched20.dll > > * have them change their DLL to ask for RichEdit10A instead > > * implement riched20.dll in Wine. Sounds like a big job! > > Sound right? Any comments? Thanks a bunch... mo > Last option is the best :) __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
Re: No RichEdit20A window class
On Fri, 2004-11-19 at 03:22, Mike McCormack wrote: > Michael Ost wrote: > > > (1) The wine bug (I think) is that riched32.dll is registering the wrong > > window class name. Here's a suggested patch: > > RICHEDIT_CLASS20A is provided by riched20.dll, not riched32.dll. The > windows 2000 implementation uses riched20.dll to implement riched32.dll > (ie. moves the richedit code to riched20.dll and implements the > RICHEDIT_CLASS10A class using the new RICHEDIT_CLASS20A class. > > In short, the existing code registers the correct class name, but we > need to make a new dll dlls/riched20, and do alot of work on the > richedit control :) This isn't quite clear to me. It sounds like you are saying there is a riched20.dll in wine, but I can't find one. Are these statements correct? * Wine's only implements RichEdit10A via riched32.dll. Wine does not implement RichEdit20A. * Win2K (and later) provides riched20.dll which implements RICHEDIT_CLASS20A. This one I can verify as true on my winxp system. * There are significant differences between the two window classes My winelib app is hosting a 3rd party DLL which is specifically requesting "RichEdit20A". That suggests that the DLL was built with win2K or later, from what you were saying. Sounds like my options are to: * hack their request to use the window class registered by wine's riched32.dll. How well could I expect this to work? How big are the diffs between 10A and 20A? * get them to provide win2k's riched20.dll * have them change their DLL to ask for RichEdit10A instead * implement riched20.dll in Wine. Sounds like a big job! Sound right? Any comments? Thanks a bunch... mo
Re: No RichEdit20A window class
Michael Ost wrote: (1) The wine bug (I think) is that riched32.dll is registering the wrong window class name. Here's a suggested patch: RICHEDIT_CLASS20A is provided by riched20.dll, not riched32.dll. The windows 2000 implementation uses riched20.dll to implement riched32.dll (ie. moves the richedit code to riched20.dll and implements the RICHEDIT_CLASS10A class using the new RICHEDIT_CLASS20A class. In short, the existing code registers the correct class name, but we need to make a new dll dlls/riched20, and do alot of work on the richedit control :) Actually, since we need to work on riched20, we might as will implement that properly, rather than trying to reuse the edit control. Mike
Re: No RichEdit20A window class
I'm re'ing my own post, but I think there's a combination of (1) a wine
bug and (2) user error at work here.
(1) The wine bug (I think) is that riched32.dll is registering the wrong
window class name. Here's a suggested patch:
[EMAIL PROTECTED] dlls]# diff -Naur richedit/richedit.c
richedit.MUSE/richedit.c
--- richedit/richedit.c 2004-11-18 12:28:53.0 -0800
+++ richedit.MUSE/richedit.c2004-11-18 17:03:33.0 -0800
@@ -792,7 +792,11 @@
wndClass.cbWndExtra = RTFInfoOffset + sizeof(RTFControl_Info*);
wndClass.hCursor = LoadCursorA(0, (LPSTR)IDC_ARROW);
wndClass.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
+#if (_RICHEDIT_VER >= 0x0200 )
+wndClass.lpszClassName = RICHEDIT_CLASS20A; /* WC_RICHED32A; */
+#else
wndClass.lpszClassName = RICHEDIT_CLASS10A; /* WC_RICHED32A; */
+#endif
RegisterClassA (&wndClass);
}
Can any wise ones comment on this?
(2) My user error is that Windows requires that RICHED32.DLL be manually
loaded before use, it seems. At least that's what MFC requires, via its
AfxInitRichEdit2() function. I called LoadLibrary("RICHED32.DLL") and,
with my above patch, CreateWindow(RICHEDIT_CLASS,...) works fine.
This isn't true for other DLLs... but, oh well, there it is.
Cheers... mo
