I think the challenge we face with WinMerge in general is that a) it
is a mature product that does mostly what we need it to do, and b) we
are all so busy that we contribute to the project to the extent that
we need things done, which is not often. I think that in order to
spark interest in development, people need a compelling reason to
devote their scarce time. Speaking personally, I like WinMerge, and
use it every day. Would a sexier version of the product be nice?
Maybe. Do I need it? No.
The one piece that has me interested is the notion of being able to
use a common product for Win/Mac/Linux. I like our usage paradigm, and
it would make me more productive on all my projects if I had a cross
platform version. Again speaking personally, I don't need to compare
archive contents, binary contents, etc... I just need a simple tool to
compare code branches and interact with source control (it would be
excellent if I could do an Hg commit on the current set of merged
files, for example).
I can relate to the notion of Qt being a relief; I still maintain some
VB code and recently ported it to C#. Like .net or not, it was like
stepping out into the sunlight after a cold winter. Everything is just
easier, makes more sense, makes me more productive. I'm sure Qt is
As I said previously, I'm willing to take a piece of the project, but
it will take time. If everyone is serious about this, then we need to
start defining some basic needs and divvy them up. I'm not totally
thrilled about learning yet another framework (sure would be nice if
Java could work), but if Qt is the consensus then let's get it going.
We need some initial basics like:
* Class layout
* Basic GUI
* Directory comparison view
* File diff/editor view (do we need to prototype this before we start
on anything else?)
* LibXdiff interface layer
* Plugin architecture? Do we want to go here?
Kimmo, do you have any ideas on what you'd like to work on? Let's
start talking about some specific directions so we can split up some
On Mar 10, 2011, at 11:14 AM, Kimmo Varis wrote:
> Hi all,
> it has been quiet with the WinMerge 3 effort in past months. No
> or anything.
> I started looking at this again, from a new point of view. Earlier we
> were thinking too much of "cloning" current WinMerge to new toolkit
> environment. Which, while doable, is inefficient and hard to do. I
> the main idea was we could use existing code. But more I think about
> less I want to use the existing code!
> We should use just the good ideas and knowledge from the WinMerge 2.x
> and write the code again. Why not re-use lots of working code? Mostly
> because the code is written for one specific environment (Windows 9x/
> and some support for later versions) and for MFC toolkit. Converting
> most of that to the new cross-platform enviroment and new toolkit is
> easy and probably leads to all kinds of hacks (above all the current
> hacks). So we just get even worse code.
> I know I'm balanced (fan of Qt) but sometimes it is just amazing how
> easy things are with it (remembering it is C++). See this commit I did
> couple of days ago:
> There it is, basic idea of dir compare, done in 15 minutes. Of course
> most of the logic is missing, threading is missing etc. But getting
> listing of files in two folders and comparing them is there. In
> 2.x we spent months for that. Of course there is some performance
> penalty in using higher level Qt classes. But does somebody notice?
> there are certainly possibilities for optimizing it later on.
> But my point is - by using Qt classes we can do much of the WinMerge
> things much easier now. And lots faster. I bet what Qt already
> offers is
> enough in most places, like threading, GUI, XML handling, regular
> expressions etc etc.
> There are couple of challenges though:
> - the file compare diff handling
> - the file compare GUI
> LibXdiff produces nice diffs but they are different (Git-style) from
> what difftools produced. And there is no whitespace ignore etc. So we
> need some logic layer above LibXdiff. I can forget things like writing
> difftools-compatible patches for now on.
> File compare GUI is challenging. There is simple editor with Qt but we
> need much more. Scintilla and its Qt bindings have been discussed. But
> I'm not very happy about it. I think most things we want to do are
> doable. Remembering we don't need to do everything exactly like in
> WinMerge 2.x.
> Few days ago I got a new idea about using QtCreator's editor etc
> plugins. QtCreator is very nice development IDE and basically
> in it is a Qt plugin. Editor is code editor so it supports many
> we want.
> Which got me thinking about WinMerge 3 architecture. What if we did it
> similar way to QtCreator and heavily use Qt's plugin architecture...
> Perhaps not in level that everything is plugins but things like
> filtering, version control support, archive support etc. That is
> something I really need to think about more...
> Following days I will continue working with very basic folder
> compare. I
> hope to get some very simple GUI done too. And start testing some
> new ideas.
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> Winmerge-dev mailing list