Only create an X window for top-level windows, not for child windows. Get rid of the X client window too, it's no longer needed.

It's a bit hard to build a complete list, I mostly make it up as I go... The main optimisation I know about is the repainting on window moves that needs to copy the bits instead of invalidating the whole window. The loose ends are mostly related to dll separation, the exported functions in user32.spec can give you a rough idea of what remains to be done. For OpenGL what we need is to implement proper clipping when drawing to a child window. There are also a number of window management hacks in the Crossover tree that need to be cleaned up and brought over.

Basically, the problem with OpenGL is that there is no way (that I know of) in OpenGL to do non-simple clipping (what I mean by 'non-simple' is non-rectangular). Ie if a (non top-level) OpenGL window is obscured by another (non top-level) window, there is no way (that is not a hack) to prevent GL to draw over the obscured window.

The best way to fix this would be to have the X server export via a GLX extension its hardware clip-list implementation (which is something that I need to discuss with the FreeDesktop guys as this would be something that could help all the 3D X servers implementations which people are working on as, basically, it's exactly the same issue).

The other way is to do indirect rendering for GL contexts not associated to top-level windows: basically, draw in a Pixmap (or a PBuffer) and then use the plain Wine 'DIB' code to blit this back-buffer to the screen (doing then the clipping). This should work easily at the price of some performance (especially on cards / drivers who do not support accelerated off-screen rendering).

The additionnal advantage of the latter solution is to solve also the 'multiple windows / different GL attributes' problem.

If Alexandre committed a patch that converted the entire code base from C to pure assembler, his changelog would read:

Code optimizations

(Although if he could find a way to say it in one word, he would) <grin>

My rich text control is still far from even semi-complete, but I think too much is done to start over, so I'm releasing it today. The number one reason of its incompleteness is that I put more emphasis on making things work exactly like in the original than on implementing more functions.

It's been neglected for weeks, and only recently I've fixed some old bugs and slowly started implementing the simplest parts of the RICHEDIT control API. I'm still not done with the basic stuff, like undo stack, so there is not much to hack on. On the other hand, it's likely I've made some bad decisions during design, and having someone experienced to look at that seemed to be a good idea to me.

Some things look really tricky to implement with the current architecture, like the printing API (it will likely be an ugly hack, but I expect the same from the original, as screen formatting and print formatting may be very different). Some things just need time. I will probably need others' help to do the RTF parser. It's just way too much work.

So, if anyone cares:

http://foltman.com/richtext-20050130.tar.gz

Compile using the recent-ish mingw (plus original SDK richedit header file).

Fantastic. This is good work. I haven't reviewed the code in depth, but I think the way forward is to submit an implementation of dlls/riched20 then make that work, and after it's debugged and worked out, rip out the old dlls/riched32 code and forward it to the new completed riched20 code.

Code review notes:

You've writen the code to deal with unicode as default, which is good, but you need to deal with both ASCII and unicode messages in the window procedure.

It might be better to use libwineunicode and kernel32 unicode string manipulation functions rather than msvcrt ones. eg lstrlenW, lstrcpyW, etc. instead of wcslen, wcscpy, etc. Avoid the TCHAR type in Wine code.

Similarly, you'll need to use "winbase.h" and friends instead of "windows.h".

From what I can see in the old riched32 code, the rtf parser looks quite good, so don't try rewrite that (which from my quick check you haven't). We can merge the parser into the riched20 code quite easily... it's just enters the text into the existing control using EM_SETSEL and some formatting messages.

I have a test I can send to you if you wish. Again, my preference is to get this into the Wine CVS sooner rather than later, so others can start helping improve it.

I'll see what can be done. As soon as there is a minimal text manipulation API (based on RichEdit API, not on function calls), I can separate the control into a DLL and move the app code in the test directory.

So far, the next version is available at:

http://foltman.com/richtext-20050130b.tar.gz

Main changes are:

• editor.c contains a list of which messages/notifications/styles work and which don't
• incomplete read-only mode
• replacement of MSVCRT wcs functions with Win32 lstr
• a modification flag
• a shy attempt at starting undo
• a #define to choose between my editor and the original RICHEDIT. It's not what I want it to be, but it's better than nothing.

Undo should be pretty easy as long as you can represent easily represent user actions in a transactions stack. A user doing something will then cause an action to be pushed onto the stack (although you would probably want some coalescing so that you don't have to undo each character you typed, you can just undo a sentence). The undo command will pop a transaction of the stack and apply the inverse. I've written a fairly nice implementation of this before in Java and it didn't take me very long.

It seems that I already have something useful. I've added multilevel undo/redo, GetCharFormat/SetCharFormat (very incomplete) and modify flag, and cleaned up the code a lot. The source code is downloadable from here:

http://foltman.com/richtext-20050204.tar.gz

I'll try to add handlers for basic editing messages (like WM_SETTEXT) and maybe notifications too, DLLize it and then make a Wine patch out of it. Is that OK ?

It's not like everything is done the way it should be (for instance, coordinate system is still pixel-based and not twips-based), but in this stage the risk of having to constantly rewrite everyone else's code is much lower.

I have been using in a few projects, Windows side and Linux, a great rich edit control, I'm sure everybody knows, and used even if he doesn't know. "Scintilla"! It has anything a RichEdit control needs (and much more but that does not have to be used). It even has the export to RTF function. (And to HTML for clipboard operations) It has 95% EditBox emulation. It is very stable, heavily used and debugged, and highly portable. The License is a BSD type license so I don't think it will be any problem. The only things missing are the RTF parser and the MS-RichEdit emulation (Data types and message translations). But it looks like these two are what above patch and existing code has. I am almost positive that if such a parser (And emulation layer) is submitted to the Scintilla project it will be farther maintained by the project. One more thing good about it, that makes a lot of sense, is its popularity, which means there are a lot of people that know this code-base and can help fix problems. (And it does compile under wine out of the box.)

Most OLE objects should be threadsafe, which requires use of the thread-safe increment and decrement functions InterlockedIncrement(&This->ref) and InterlockedDecrement(&This->ref) instead of This->ref++ or This->ref--. See an example patch of how to fix this problem.

To be consistent, references to This->ref in TRACE's should be avoided as well.

If there are not objections I'll send the attached patch to wine-patches.

Changelog

The Interlocked cleanup is completed.

There is an exciting announcement out today:

http://www.desktoplinux.com/news/NS7711938137.html

Essentially, OSDL has funded a community oriented pro-bono legal service for Free and Open Source Software Projects. The Center is led by Eben Moglen, the chief counsel for the FSF.

I've been speaking privately with Eben Moglen about this new effort, and he tells me that they would like to have the Wine Project as one if their very first clients.

Candidly, this seems fantastic to me; one of the difficult things that I face when promoting Wine is peoples Fear, Uncertainty, and Doubt about the legality of Wine. Having an opportunity to clarify these legal issues is probably the most important thing that could happen for Wine, in my opinion (well, okay, maybe it's less important than support for Pirates! <grin>).

However, before I go off to request the services of the SFLC, I thought I would post this announcement here and open it for any discussion. I'd particularly like to hear if folks can think of any reasons why this might be a bad thing.

Finally, the key objectives from my standpoint are as follows:

1. Get an opinion written on Wine and copyright issues (imho, we have no IP issues here)
2. Get some legal research done on Patent issues I don't know how this will turn out, so I think we should wait for the research.
3. Investigate the legal doctrine surrounding what use a monopoly can make of its patents; I know that US antitrust law provides some restraints, but it would be great to have a legal opinion on the matter.

Thoughts? Comments?

Ok, I finished up the winetools Debian packages.

It's on the same repository as the Wine packages at WineHQ, so you should be able to install it easily from there.

To run it simply type "winetools" or use the (hopefully created) menu entry.

One day I hope to have a man page and such, but for now it seems good.

Not really related to the actual wine development but more to the make/build/install environment.

Remembering the most wine users will not necessarily be developers we should consider improving the output of running (./configure && make) to make it more user friendly. Hopefully it should also be less confronting and confusing to non developers. I propose something similar to the way the Linux kernel currently compiles. The included patch changes make so that a regular make will produce much nicer output while for those die-hards who prefer the original output this can be achieved by executing

make VERBOSE=yes

I personally prefer the neater output even for development work, the compile output doesn't scroll off the screen as quickly and warnings/errors can be more easily spotted.

This patch doesn't do the complete job, instead only produces output for the compile (gcc) stages. In fact, (make install) will produce no output at all! If people think this is a good idea, simple extensions will lead to complete output, just add the necessary

$(NICE_ECHO) " whatever"

to the proper places in each Make*.in file

I am willing to do this if it is deemed to be good.

Making in libs/wine/
     Compiling           config.c
config.c: In function `init_server_dir':
config.c:120: warning: right shift count >= width of type
config.c:125: warning: right shift count >= width of type
     Compiling           debug.c
     Compiling           ldt.c
     Compiling           loader.c
     Compiling           mmap.c
     Compiling           port.c
   Creating Library      libwine.so.1
   Creating Library      libwine.so

The developer can use "make -s" if he wants to see less.

vis and emacs automatic errorline jump will also stop working.

I will not bring this up any more after this email.

I note that while the patches are extensive they are merely the addition of one ECHO line to each rule.

For those who are interested, I attach the patch here (hoping it works this time) for the completed output cleanup. I ran

diff -urN wine-20050111 wine-20050111.new > make_patches

where wine-20050111/ is the directory with the current wine sources and wine-20050111.new/ is the patched directory

All the changes are to the Make*.in files.

Closing off my input now.