>> - The "Patch all items" button overlaps the little "resize-grip" in the
>> lower right corner.
> Strange, I don't see the resize-grip. Even on my XP VM it doesn't show.
> But I'll add some more code to really disable the grip.
The grip is gone now for me as well. Looks much better!

>> I still feel that it's confusing that the "File patches"-window is the
>> child of the TortoiseMerge window. I understand why, but it feels backward.
>> I would excpect the "File patches" window to be a regular stand alone
>> window, that swpawns TortoiseMerge instances if I want to preview a
>> file. In the same way as the "Changed Files" dialog works.
> If it would spawn separate TMerge instances, imagine the slowdown and
> memory use if the user clicks on "patch all".
I'm not talking about how it is done "behind the scenes", only how it will appear to the end user. I don't see any problem with running the "patch all" (or to patch an individual file) execution from within the (not yet existing) patch dialog. Or if that feels awkward, do it in a single (preferably non-visible) tortoise merge instance in the background. Is there a particular reason that the patch-code is located in TMerge?
The only time a tortoise merge window would need to be created would be (as in "Changed Files") when a user wants to view a diff, and the slowdown of starting a new TMerge instance in those cases is OK, I'd say. (We do not share the same TMerge instance for "Changed Files" or for the "Log Messages" dialog.)