WinMerge 3 in active planning

[kimmov]

Good news! For past couple of weeks there's been active discussion about future of WinMerge and developing "next-gen" WinMerge 3 version. This discussion has happened mostly in developers (closed) mailing list and between some core people. One reason for that was we weren't sure if it really would be idea that will take off. Now it looks like we have some promise for it to happen so we can also make this really public and open subject.

There will be big changes - it will be more a rewrite than update of WinMerge 2.x. Major things to happen:

• It will be a cross-platform software. Most likely GUI will be created based on Qt. At least nobody has had any realistic ideas to use other frameworks.
• Development will happen in Mercurial repository hosted at Bitbucket. Mercurial allows distributed development and that makes our workflows much easier and faster when applying changes from different people. Also Bitbucket is much better Mercurial service than Sf.net where Mercurial is one of those second-class service citizens.
• Most components we use will change.
• Translation system will change. Though we might still use PO files as public API for translators. We'll see...
• Licensing might change. If we get permissions from relevant people we'd like to use LGPL 2 license in future.
• Feature list will change dramatically - we'll take a critical look at what can be done and maintained in future.

What we have so far is mostly visible in WinMerge repository Wiki. There are some initial plans and development ideas. Not much but a start anyway.

It is worth emphasizing that this will be a lots of work. For few developers. So don't expect us to have a "stable" release anytime soon. It will take time. Realistically speaking first alpha-level release having minimal set of features working might happen after the summer.

If you want it to happen faster then you need to get involved and start helping us to get it done.

We already separated Web pages to separate Mercurial repository at http://bitbucket.org/kimmov/winmerge-web. Web folder in Sf.net SVN won't be updated anymore.

If you want to help - first thing is to start participating discussions in this forum. If there is no existing topic yet - create new topic. There is no WinMerge 3 code yet. But you can use my winmergeqttest and libxdiff-testing -repositories. Especially ideas how to create current WinMerge editor features (diff block coloring is the most important) with QScintilla would be welcome.

[strump]

What's status of WinMerge 3?
As far as I can see, no commit from March 2011. I have a few question:
1. Why do you choose libxdiff? Winmerge 2 uses diffutils. Maybe multiple diif engines (plugins) should be used?
2. Do you have planed tasks in some bug tracking system? A good idea is to have one task for each feature to see all range of tasks and to know what features are going to be in version 1.0 and to see progress. I think WinMerge is at the early stage of development and it needs: Global settings, Settings UI, Diff engine binding, Multiple document interface, Two panel diff UI.

Does anybody going to continue development?

[kimmov]

What's status of WinMerge 3?

I guess nobody really knows. I myself haven't been giving any attention for it anymore.

As far as I can see, no commit from March 2011. I have a few question:
1. Why do you choose libxdiff? Winmerge 2 uses diffutils. Maybe multiple diif engines (plugins) should be used?

Integrating diffutils is very difficult as there is no API in diffutils and you have to use its internals directly. WinMerge 2 uses very old version of diffutils and nobody has even got diffutils updated in there despite of multiple attempts. libxdiff on the other hand offers nice API to use.

2. Do you have planed tasks in some bug tracking system? A good idea is to have one task for each feature to see all range of tasks and to know what features are going to be in version 1.0 and to see progress. I think WinMerge is at the early stage of development and it needs: Global settings, Settings UI, Diff engine binding, Multiple document interface, Two panel diff UI.

There are tasks and some initial plans outlined in the wiki: https://bitbucket.org/grimmdp/winmerge/wiki/Home

The main focus must be at first to create a good flexible architecture for the compare engine. Including extensive tests. Once we have that outlined and basics implemented the GUI is much easier to get going on. If we just start hacking on GUI things then we end up with the same mess than WinMerge 2 is.

What the project needs is people committed to work on it.

Does anybody going to continue development?

I don't know. I can develop if there is some real interest on it and we get more people developing it.

[strump]

The main focus must be at first to create a good flexible architecture for the compare engine. Including extensive tests. Once we have that outlined and basics implemented the GUI is much easier to get going on. If we just start hacking on GUI things then we end up with the same mess than WinMerge 2 is.

Good architecture means a lot. I think it must be created by a developer who knows pros and cons of WinMerge 2.

What the project needs is people committed to work on it.
...
I can develop if there is some real interest on it and we get more people developing it.

I'm interested in this project and my native language is Russian.

[jjm340]

I would also like to contribute to building WinMerge 3.

[kimmov]

That is very good news! It is sad everything and almost everybody has been away developing this project for a long time.

We've have couple of starts for WinMerge 3/Qt now. And we haven't got further than initial discussions of features. And some POC code.

I think if there really is interest and more than couple of people interested in working this time we could really start doing something.

First I would just scrap the plans currently written into bitbucket wiki pages. It didn't work. We need to think what we want to do and what we realistically can do. I cannot promise much time for this project still, but sure would be interested in working with it. Considering the amount of resources I still would pick some ready diff-library and use it instead of (like some still suggest) using diffutils or even developing our own library. It is huge amount of work, and I know because I did a lot of that work in WinMerge 2. IMHO WinMerge's "the thing" is the user interface. Even if the new WinMerge would not have all the WinMerge 2 features, improvements to GUI would make it worth of it. WinMerge 2 GUI is very painful to work with (especially the editor).

[jjm340]

So what is the next step(s)?

[kimmov]

So we've seen couple of people being interested in developing. I think we should start from really scratch again and think what can be done and how. I did some experiments which are in my bitbucket repositories. Probably the most important decision is to select/design the diffing. Second important is the UI framework and then the editor component. There are some discussion/points in the Dean's repository's wiki about the diffing and editor.

[gulbrain]

I'm a big fan on WinMerge and have been using it for some time.

I'd like to help with the testing of WinMerge 3 - how do I get involved?
When would you anticipate something being ready to test?

Thanks,
Tim

[christianlist]

I'm afraid there is not much activity towards WinMerge 3 for a long time now.
We are in dire need of someone to take the lead on this project to get it moving.