The proposed patch creates a dll version of Raihan Kibria's free binary file editor FRHED (http://www.kibria.de/frhed.html), and adds the necessary frame/doc/view stuff to enable WinMerge to present users with a side by side hex diff/edit/merge view. The feature is accessible through DirView context menu item Compare Special > HEX.
About precompiled header settings: The simple rule is not to mix /Yu with /YX. If a particular file doesn't compile with /Yu (because it lacks the inclusion of stdafx.h), please don't set it to /YX, but rather entirely disable precompiled header usage for that file.
Logged In: YES
user_id=631874
Originator: NO
Interesting!
> Raihan Kibria's free binary file editor FRHED
Sources don't include COPYING, LICENSE.TXT or any other obviously named file with licensing information? Unfortunately that it says it is GPL in web page is not enough - we need clear mentioning of licensing in sources! Meaning we have a version of the sources that are under GPL license, even if the license changes in future. GPL requires this. So until this is cleared up we really can't add this code.
The idea sounds fine and I'll look at the changes more closely in next days.
> About precompiled header settings [...]
Oh, I've made a mess of that. I suppose project file changes are to fix this issue? Can you commit those changes as separate commit from other code in this patch item? Commit to 2.10 branch too.
Logged In: YES
user_id=766060
Originator: YES
The FRHED source tree includes a GPL.txt as part of the installer sources.
Logged In: YES
user_id=631874
Originator: NO
> The FRHED source tree includes a GPL.txt as part
> of the installer sources.
Then that file must be included sources added to our source tree.
Logged In: YES
user_id=766060
Originator: YES
Committing changes to precompiled header settings.
Trunk - Completed: At revision: 5767
R2_10 - Completed: At revision: 5768
Logged In: YES
user_id=766060
Originator: YES
Updated patch includes GPL.txt
File Added: side_by_side_hex_diff_edit_merge_view-2008-08-08.7z
Logged In: YES
user_id=631874
Originator: NO
Thanks. I took quick look at the changes. DirDoc/DirView changes look good an straightforward. Same for MainFrame and MergeApp changes.
Only real comment I have for code changes is that please don't add tabs to Merge.rc. And can you please fix tabs in previous line in menu item too.
Now, conceptually I think this is a good idea and I like it. I'm not sure if the sub-menu is a correct place to add this. Full compare method tells user if files are binary files, but other compare methods don't, so how user knows to use this binary file compare? Probably only after first trying normal text compare. And even then this is a bit of hidden in the menu.
From user's perspective I'd open files automatically to binary compare if we determine files are binary files. Perhaps we could ask user first still.
Another thing is how we want (text) file compare's binary file viewing and this binary file merge relate to each other. When should they be used and opened? And hmmm, it is possible to have plain text file in other side and binary file in other side (same file having totally different content in different folders). What then?
But as a first step, for integrating the feature and testing, it sounds good idea to have it in menu.
I think this patch can be applied to trunk. Great work!
Logged In: YES
user_id=766060
Originator: YES
heksedit - Completed: At revision: 5771
SplitterWndEx - Completed: At revision: 5772
other changes - Completed: At revision: 5773
Logged In: YES
user_id=631874
Originator: NO
Nice. Have you thought about translating hexedit resources? Should we have similar system to other WinMerge code and separate PO files for it?
Logged In: YES
user_id=631874
Originator: NO
Added SVN properties for new files:
Completed: At revision: 5774
Logged In: YES
user_id=766060
Originator: YES
> Have you thought about translating hexedit resources?
Yes, but I haven't come to a conclusion. We'd certainly first have to make heksedit compile for Unicode, and move all the hard-coded strings into resources...
Logged In: YES
user_id=631874
Originator: NO
Which actually leads to much bigger question. Looking at hexedit home page it has been practically abandoned without any recent development activity. Basically we have two options:
- create and host fork of it in WinMerge SVN repo, doing all modifications from WinMerge point of view
- create a own project for it to Sf.net or google code, develop it as separate project (but still keeping WinMerge in mind) and just synch it to WinMerge SVN periodically.
I'd like to avoid situation we have wit CrystaEditor where we have abandoned editor nobody cares about. I'll send original author a mail and ask what he thinks about this.
Patch for building/copying dll
Logged In: YES
user_id=631874
Originator: NO
Attaching a build patch which:
- uses \ as path separator for output/intermediate paths so they can be used in macros
- builds to Build\heksedit\$(target) (not a real macro but you get the point)
- copies dll to Build\heksedit so installer knows where to get it (target-independent)
File Added: Fix_Hexedit_build.patch
Logged In: YES
user_id=631874
Originator: NO
Committed the patch below to SVN trunk:
Completed: At revision: 5797
Will submit a patch for installer later today.
Logged In: YES
user_id=631874
Originator: NO
Installer patch
#2051475 Add heksedit dll to the installer
http://winmerge.org/patch/2051475
committed to SVN trunk:
Completed: At revision: 5814
Logged In: YES
user_id=766060
Originator: YES
<Tool
- Name="VCPostBuildEventTool"/>
+ Name="VCPostBuildEventTool"
+ CommandLine="copy $(OutDir)\heksedit.dll ..\..\Build\pcre"/>
That post-build CommandLine referring to pcre build directory looks unintentional.
Logged In: YES
user_id=631874
Originator: NO
Ugh. Simple copy-paste error. I committed a fix:
Completed: At revision: 5835
Thanks for noticing this.
Logged In: YES
user_id=766060
Originator: YES
First step towards UI translation: There is no separate unicode build configuration. heksedit.dll offers distinct window classes for unicode and ansi environments, and lets the hosting application decide which one to use. Naming of PO files for heksedit is based on ISO 639 language codes and ISO 3166 country/region codes as returned by WINAPI GetLocaleInfo(). de.po is a *very* incomplete translation providing german translations for the text snippets that happen to appear in the "Character Set" dialog (Ctrl+R).
Logged In: YES
user_id=766060
Originator: YES
I don't seem to be able to attach a file today...
Logged In: YES
user_id=766060
Originator: YES
Completed: At revision: 5863
Completed: At revision: 5864
Completed: At revision: 5865
Logged In: YES
user_id=631874
Originator: NO
You seem to have committed two zero-size files to Externals/heksedit/Languages:
20080825T174325.CreateMasterPotFile
20080825T175125.UpdatePoFilesFromPotFile
I assume these aren't really needed?
Logged In: YES
user_id=766060
Originator: YES
Completed: At revision: 5875
Completed: At revision: 5876
Completed: At revision: 5877
Those zero-size files are used for up-to-date checking.
*.CreateMasterPotFile reflects heksedit.rc's last modification time by the time CreateMasterPotFile.vbs was last executed.
*.UpdatePoFilesFromPotFile reflects en-US.pot's last modification time by the time UpdatePoFilesFromPotFile.vbs was last executed.
Logged In: YES
user_id=631874
Originator: NO
That kind of state files don't belong to version control. What happens when I build WinMerge - SVN status says I have two missing files in that folder - those status files. This won't work. Maybe we should start using revision number for POT and PO files.
WinMerge building is already way too complex. Which means way too many errors for people compiling WinMerge. And making it even more complex is not an option. We should think of ways to make it easier. And indeed I'm working with a script to handle version numbering.
Basic things for hexedit are:
- it can't invent yet another way to name translated files. Translators have already problems finding correct files and most don't even bother finding all of them. Which is a big problem for us.
* we need to have consistent naming and less places for translatable files, not more. Yes, WinMerge translation file naming isn't good and we can improve it. But heksedit/frhed and WinMerge translation files must be named with similar scheme.
* probably we also need to have these files under some common folder for most components.
WinMerge project will not translate heksedit/frhed. It is one important reason I created the upstream frhed project. All translations updates go there and WinMerge receives them when we get next version of frhed/heksedit. Same way than we do with Innosetup - I've refused to apply updates to Innosetup strings, and only get updates for them from Innosetup official/unofficial translation files. And yes, I tried to manage the mess there was before this decision.
- it probably means heksedit and frhed must share same translated resources 1:1.
I know this may feel frustrating now. But frhed/heksedit integration must be done with good and clean way so that we can manage it in future too. There is no much use of translatable editor if translators don't find the files. We have documented WinMerge exe PO file's location in several places and I've written about it many many times. Still I constantly get messages people asking to send the latest files. So we need to make things easier, not more complex.
Logged In: YES
user_id=766060
Originator: YES
Feel free to remove state files from version control. Scripts work without them. Only up-to-date checking doesn't work, but that should be an easy fix.
> But heksedit/frhed and WinMerge translation files must be named with similar scheme.
heksedit uses ISO language and country/script codes to form canonical filenames. This saves the need for parsing all translation files to know which translations are available, which happens to simplify code quite a bit. It is also quite easy to allow heksedit to fall back to a default translation in case it doesn't find a country-specific one, just by cutting off the country/script code from the filename. I'd like to see this in WinMerge, too.
There is a dropdown list to select the UI language in frhed's View Settings dialog (Ctrl+I). It shows all languages returned by WINAPI EnumSystemLocales(). Languages for which no translation is present are shown in gray. The filename to use is evident from the leftmost column of the list.
I still work in WinMerge repo because it helps me sort out integration problems. However, now that there is reasonable folder layout for translation files (i.e. heksedit translation files reside in heksedit.lng so they won't conflict with anybody else's translation files), I don't see much potential for further integration problems. So next step will be to update the frhed project.