| OK, so I've been looking through the code and from what I see I suspect a big reason for the rewrite was to move huge chunks into platform-independent C++ for an ultimate Win32/Linux/Mac trifecta release (maybe for TM3). If so, this would explain why things got so bogged down. The actual layout/folding code, for example, is in C++. When it needs to draw it calls Core Graphics C functions. A lot of the other things like commands are similarly abstracted. But the thing is, if you look in Frameworks/layout/src/layout.cc for example (the code that actually lays out the text), it looks like nice platform-independent C++ code. Ah, you think, this will be easy! Until you get to, say, CGRect layout_t::rect_for (row_tree_t::iterator rowIter). The return type is CGRect and it's calling CGRectMake. These are Mac-specific Core Graphics calls. The drawing code is similarly Mac-specific. So the first thing you'd need to do is follow the architecture and start TRULY abstracting the core functionality into these C++ classes and, when they make a call to something platform-specific, you'll need to replace it with something platform-independent. To do this, you'll need to: - Make or move to an abstracted Graphics Context library. You could use something like Cairo or roll your own (which is what WebKit does). - Further abstract the application structure away from the actual classes. So, for example, you would have platform neutral code to talk about the UI logically but then have each "MyWindow" C/C++ class hold a "PlatformWindowHandle" which, on Linux might be a GTKWindow pointer, on Win32 might be a Window HANDLE or COM object reference to a .NET Window, and on Mac be a pointer to an NSWindow. You'd obviously need similar platform-neutral library infrastructure to call into each of these with a similar API and translate to the platform actually running at the bottom. You could write this yourself, or you could maybe just use wxWidgets or some other library that's had a decade-long head start. You lose some control that way, though. - Repeat with all other areas of the app that are still Mac-specific. My opinion is this would be a good starting point for such a thing, and if you really wanted to make it happen you could. But you're NOT going to just go in there and replace NSWindows with GTKWindows and NSButtons with GTKButtons and call it a day. It will be MUCH more work than that. |