Cross-platform support and related things have been discussed in many topics in old forums and numerous tracker items. So far we have cleaned up lots of non-GUI code from MFC. Which doesn't yet mean it is all cross-platform, but it is remarkably easier to convert.

So far my code just creates editor view and enables syntax highlighting for C/CPP files. So it is in very beginning. But I intend to try to implement features we currently depend on WinMerge. Like adding block highlighting (for diffs), additional panes etc etc.

I think the big question for many is why QT? Simply because QT is currently the most interesting GUI (and cross-platform) framework. It is technically superior to wxwidgets (sorry wx fans but it is). My main problem wit wxwidgets is it mimics Windows/MFC programming model which makes easier to port code from MFC but it is also hacky and ugly (with all those message handler macros etc). Earlier I didn't want to use QT because of its licensing. And lack of free Visual Studio support in Windows. Last releases have fixed all these. I've been programming QT with Visual Studio past months and much enjoyed it.

If my experiments succeed it will be very likely I'll continue working with QT porting. Even though it means rewriting most of the GUI. It will be a lot of work, but it will be also worth of it. We'll have a good change to get rid of lots of old cruft and hacks around.

how to use both simple and low-level APIs of QScintilla at the same time? (We need also the low-level API for efficiency)

Yes, I'm concentrating on file compare. Folder compare GUI is a lot easier to do and I don't even see any hard parts in implementing it with GUI. If/when we have good ideas how to solve above problems (and others we find later) we can start the real porting work...

So if somebody wants to help, clone my repository from Bitbucket, and start sending patches to my e-mail. Or send pull requests to clone in Bitbucket. If there are problems with QT, QScintilla or building my code reply to this topic.

The hard problem is what to do about the name, when WinMerge is not just for Windows. But that's a good problem: I look forward to using WinMerge on Linux!

Looking at the QT web site, I don't see any problems migrating help. The QT Assistant is implemented with plain HTML topics wrapped in some small XML collection files - very similar to compressed MS HTML Help.

So you should be able to continue sourcing QT Help in DocBook - I think KDE does this. We would need a little new XSL: maybe just customize the stock htmlhelp.xsl stylesheets, generating the QT Help project file instead of the HHP file. This should not be a huge effort, please keep me in mind if somebody else hasn't already done it.

Yes, there are lots of open questions related to this porting work. And that is exactly why I started this experimentation project - to get answers. Perhaps I should enable the wiki in BitBucket and start recording results there too.

Manual is one interesting question. Using QAssistant might be a good move, but at start we can just continue using existing system and build only HTML for Linux.

Translations are one big question. Probably we need to switch to using QT:s system and convert PO files to TS files. Tool exists.

Then there are questions like if we continue using expat or switch to QT:s XML module (I don't see why not). If we switch to QT:s QFIle and other classes in our lower level code or not. In general - how much we keep code in standard C/C++ (+STL) and how much use QT:s classes. Basically the same question we currently have with MFC. But with the big difference that QT is cross-platform and doesn't lock us to one platform like MFC does.

Hi,I like a lot this piece of soft, I have used it on win during my dev time on .Net ( really bad exp ehehe ) however I'm lucky now to work on more open technology (php mostly) ... ... So what about this nice idea to port it to QT (Linux rules :O ) ? it is a dead project ? what about Kickstarter ?

I will be very happy to install it on my debian machine that actually use for work