winmerge-development Mailing List for WinMerge (Page 4)
Windows visual diff and merge for files and directories
Brought to you by:
christianlist,
grimmdp
You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(15) |
Nov
(4) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(3) |
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(3) |
Dec
(1) |
2008 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(2) |
Jun
(5) |
Jul
(4) |
Aug
(6) |
Sep
(12) |
Oct
(2) |
Nov
(1) |
Dec
(3) |
2009 |
Jan
(2) |
Feb
(1) |
Mar
(3) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(8) |
Sep
(17) |
Oct
|
Nov
(2) |
Dec
|
2011 |
Jan
|
Feb
(3) |
Mar
(8) |
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
2012 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2013 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Kimmo V. <ki...@wi...> - 2009-03-05 19:10:36
|
Hi all, I've just uploaded WinMerge 2.12.0 stable release to sf.net. It is again a great release, with few major new improvements and lots and lots of smaller improvements and bug fixes. Enjoy! Regards, Kimmo |
From: Kimmo V. <ki...@wi...> - 2009-02-05 19:30:58
|
Hi all, I've just uploaded 2.11.2 beta release to Sourceforge. This is the (first and) last 2.11.x beta release. This release is also a "freeze" release for 2.12.0 stable release. Only non-risky bug fixes, documentation updates and translation updates are allowed for 2.12 branch until 2.12.0 release is done. The plan for 2.12.0 stable release is: - 2.12 RC in 1-2 weeks (only if there are more than few patches committed) - 2.12.0 stable release in 2-3 weeks This is again a bit short notice for translators, but there is not much we can do about it. It probably means (once again) that most translators won't have time to do a full updates (if they haven't been actively submitting updates) before stable release. But the experience has shown that even if we wait for few weeks it doesn't add many translation updates. It only delays the release. The situation with translation and updating them is in many ways a bit problematic currently. I simply don't have the time to keep everybody informed and keep in contact with all translators. If somebody wants to help us with translations and better organizing them it would be very welcome contribution. Regards, Kimmo |
From: Kimmo V. <ki...@wi...> - 2009-01-29 16:41:27
|
Hi, > after a long pause, I am finally finding some time to work on Winmerge. welcome back! :) > Last time I did something I was kind of stuck in a chicken and egg > situation about what I needed to do next. Here is the situation. I'm at that situation constantly.. There are many bugs that need to be fixed, but then only fixing bugs don't improve things a lot. Age of the codebase starts to show up in many places. > 1. I'd like to rewrite the line-diff algorithm to fix a lot of small > bugs without causing regressions. > 2. To prevent regressions and make sure the code has the right behaviour > I want to write lot of tests. Yes, line-diff is in quite unknown state. And seems fixing one bug easily causes two new bugs so touching that code is quite challenging. If you didn't notice yet, I've removed cppunit code from SVN and I've created few new tests with Google Test. It looks very promising unit testing framework and I really hope people start using it. While creating tests with cppunit was a real pain, Google Test seems to be very easy. Only setting up the test project with VS is a bit of work. > 4. WinMerge is a single executable without libraries, we'd need to > refactor the code to have some New libraries? Why? I'd rather see the refactoring of non-GUI code out of MFC GUI classes (view/document classes) as the most important refactoring work. > 5. Since my contributions until now have been small I don't know if the > team would appreciate me doing such radical changes Code improvements are very much welcome. But discuss them with others first. Don't do the error of sending big refactoring patch that then doesn't fit to other plans. We've lost lot of good job because of huge patches that cannot be applied. I'd prefer smaller patches or even working in SVN branch. One interesting option is also creating a public GIT/Mercurial/Bazaar repository and working in it. And then merge the outcome to SVN. Perhaps as a set of exported patches. > 6. To prove myself worthy ;-) I'd need to give a more important > contribution (like #1 above) Nah. Every contribution is valuable. > I've seen that current test projects just recompile the winmerge's code. > That is probably what I will do anyway but I know that is not the right > solution. How else can you unit test C++ code? There is no Java/.Net kind of runtime system you can use to run code... > In the rest of this lengthy email, I will write what I've seen while > looking at current code base a few months ago when thinking about > creating the first library: common I wouldn't start this split now/yet. Its not clear how we even define the 'common'. Traditionally we've added code that we have got outside into there, code that is not strictly WinMerge specific. But that hasn't been a strict rule. Its more important to have code architecture improved than to move files around or to libraries. After all you only get some namespace separation from library. And compilation problems. :) > A. The product is composed of 2 executables: > a) WinMerge in Src/ > b) the ShellExtension in ShellExtension/ > > B. They share the following files > src\common\coretools.cpp > src\common\RegKey.cpp > src\common\UnicodeString.cpp > and their includes. Which we propably should just copy to ShellExtension folder for ShellExtension to use. We've already broken other component when changing the file for the other. And needs of ShellExtension from those files are pretty small anyway. > > C. There is a lot of code in the Src/Common folder that is not common at > all, including a lot of UI-related classes See above. It is not about sharing with WinMerge executable and ShellExtension. And ShellExtension is pretty new addition (I wrote it few years ago) to WinMerge. > D. There is 4 configurations in winmerge project > Debug > UnicodeDebug > Release > UnicodeRelease I think we'll drop ANSI targets soon. > while there are 6 in ShellExtension > Debug > Unicode Debug > Release MinSize > Release MinDependency > Unicode Release MinSize > Unicode Release MinDependency > > E. The only differences between the MinSize and MinDependency > configurations are the usage of ATL > MinDependency: Static Link to ATL > MinSize: Dynamic Link to ATL > all other configurations of both projects: not using ATL I've been releasing for a long time with MinSize so I think MinDependency targets can be removed. > > F. Differences between ShellExtension and Merge projects (besides #E > above) are: Not sure why this is relevant at all? Independent products... > > Usage of MFC => I guess common library could Use Standard Windows > Libraries > Shell: Use Standard Windows Libraries > Merge: Use MFC in a Shared DLL Yep, we've removed all MFC from ShellExtension. But switching WinMerge to another GUI toolkit is still a dream... > Preprocessor directives (showing differences only): > > Merge: > HAVE_STDLIB_H; > STDC_HEADERS; > HAVE_STRING_H=1; > PR_FILE_NAME=\"pr\"; > DIFF_PROGRAM=\"diff\"; > REGEX_MALLOC; These are for diffutils... > USG=1; No idea about this one?? > EDITPADC_CLASS=; For crystaleditor (editlib). > I think we can start the migration to a product which uses libraries > (statically linked to prevent DLL hell) with the following steps. What > do you think? > > 1. Remove ATL from Release builds of ShellExtension and make it only 4 > configurations like winmerge > (takes care of D,E) Not sure how you can do this (Remove ATL). ShellExtension is about accessing shell objects and using them from pure C++ would be quite a pain. And we aren't getting back to MFC. Propably just lots and lots of time wasted for nothing. I really wouldn't start here if I have other things to do... > 2. Look at the remaining differences in F and see if any could cause > problems if we create a common.lib library used in both > ShellExtension(U).dll and WinMerge(U).exe. Not worth the time. What we need to share is few functions we can just copy to ShellExtension project and be done with that. > 3. Create the library common (.vcproj/.dsp). Later... Again it won't improve things considerably. > 4. Create a test library for common (some of the unicodestring functions > for example). There is already /Testing with couple of Google Test projects. Now they could be organized better and built from one solution etc. Skipped rest of your steps as they are with the assumption of having common lib. Which I don't see much point at the moment. I'm not against creating new libraries. But I don't really see any point with that common library having couple of functions (what WinMerge executable and ShellExtension share). What would help *a lot* is creating library for: * editor code. That cleans up lots of types, macros etc. Not trivial to do though. * compare engines. Needs some architecture work first, but would make comparing a lot easier to handle (getting rid or at least simplifying of DiffWrapper, FolderCmp and other related classes having lots of old tricky code. * diffutils. It just brings lots of globals to the code. Its also worth reading the new phpBB forums, I've written about ideas for new compare types etc there. http://forums.winmerge.org I hope I didn't sound too negative for your ideas. It is easy to misunderstand the 'Common' folder. Its not been about sharing code, but more about code bin where we've put code copied from other sources/projects. Regards, Kimmo |
From: Marcel G. <mar...@po...> - 2009-01-29 06:35:56
|
Hi everybody, after a long pause, I am finally finding some time to work on Winmerge. Last time I did something I was kind of stuck in a chicken and egg situation about what I needed to do next. Here is the situation. 1. I'd like to rewrite the line-diff algorithm to fix a lot of small bugs without causing regressions. 2. To prevent regressions and make sure the code has the right behaviour I want to write lot of tests. 3. To compile and run tests, I need to access the new line-diff implementation. 4. WinMerge is a single executable without libraries, we'd need to refactor the code to have some 5. Since my contributions until now have been small I don't know if the team would appreciate me doing such radical changes 6. To prove myself worthy ;-) I'd need to give a more important contribution (like #1 above) That is the chicken and egg situation. I've seen that current test projects just recompile the winmerge's code. That is probably what I will do anyway but I know that is not the right solution. In the rest of this lengthy email, I will write what I've seen while looking at current code base a few months ago when thinking about creating the first library: common A. The product is composed of 2 executables: a) WinMerge in Src/ b) the ShellExtension in ShellExtension/ B. They share the following files src\common\coretools.cpp src\common\RegKey.cpp src\common\UnicodeString.cpp and their includes. C. There is a lot of code in the Src/Common folder that is not common at all, including a lot of UI-related classes D. There is 4 configurations in winmerge project Debug UnicodeDebug Release UnicodeRelease while there are 6 in ShellExtension Debug Unicode Debug Release MinSize Release MinDependency Unicode Release MinSize Unicode Release MinDependency E. The only differences between the MinSize and MinDependency configurations are the usage of ATL MinDependency: Static Link to ATL MinSize: Dynamic Link to ATL all other configurations of both projects: not using ATL F. Differences between ShellExtension and Merge projects (besides #E above) are: Usage of MFC => I guess common library could Use Standard Windows Libraries Shell: Use Standard Windows Libraries Merge: Use MFC in a Shared DLL Preprocessor directives (showing differences only): Merge: HAVE_STDLIB_H; STDC_HEADERS; HAVE_STRING_H=1; PR_FILE_NAME=\"pr\"; DIFF_PROGRAM=\"diff\"; REGEX_MALLOC; __MSC__; __NT__; USG=1; EDITPADC_CLASS=; COMPILE_MULTIMON_STUBS; _CRT_SECURE_NO_DEPRECATE Shell: _ATL_NO_UUIDOF Precompiled headers I think we can start the migration to a product which uses libraries (statically linked to prevent DLL hell) with the following steps. What do you think? 1. Remove ATL from Release builds of ShellExtension and make it only 4 configurations like winmerge (takes care of D,E) 2. Look at the remaining differences in F and see if any could cause problems if we create a common.lib library used in both ShellExtension(U).dll and WinMerge(U).exe. 3. Create the library common (.vcproj/.dsp). 4. Create a test library for common (some of the unicodestring functions for example). 5. Remove the files defined in B from different test projects and link against new library. 6. Remove the files defined in B from Merge.(vcproj/dsp) and link against new library. 7. Remove the files defined in B from ShellExtension.(vcproj/dsp) and link against new library. 8. Start thinking of next steps a. moving files around using subversion to keep history (to take care of A, C) b. new libraries c. new tests ... So, an hour and a half later, how does this sound? Marcel Gosselin |
From: Kimmo V. <ki...@wi...> - 2008-12-20 13:57:15
|
> This is long overdue branching as I've been waiting for some > things to happen in trunk first. Namely the situation of > Frhed/heksedit integration. As it now has become clear we > can't include Frhed/heksedit in 2.12 stable branch (see > the my posts in new developers forum) I should clarify that dropping Frhed/heksedit from 2.12 was difficult decision. But the amount of work needed has surprised everybody involved. And this is kind of feature we simply cannot ship without things like good documentation. Earlier we have added new features with hurry before the stable release. Which has caused incomplete features being in stable releases. And features that have never been finished after that. Frhed/heksedit will be included when it is ready for it. And the bar is now a lot higher than it was couple of years ago. Now there are millions of users. Even the nature of integration is still a bit unclear. One idea I have is to simply not distribute heksedit with WinMerge. But use heksedit dll from Frhed distribution. This would simplify things quite a lot. And most importantly reduces duplicated work between the WinMerge and Frhed projects. Regards, Kimmo |
From: Kimmo V. <ki...@wi...> - 2008-12-20 09:10:37
|
Hi all, I've just created new branch to SVN for 2.12 stable release. The branch is in 'branches' folder and named as 'R2_12'. This is long overdue branching as I've been waiting for some things to happen in trunk first. Namely the situation of Frhed/heksedit integration. As it now has become clear we can't include Frhed/heksedit in 2.12 stable branch (see the my posts in new developers forum) I'll start planning of 2.12 release in new branch. And trunk is again open for other work. My initial plan is to release a 2.10.2 beta release (first 2.10.x beta!) in middle of January. That will also be the translations freeze release. After that release only bug fixes will be accepted to the branch. 2.12.0 stable release follows in few weeks after the beta release. Absense of beta release is remarkable. But there are couple of reasons I haven't been doing them: - there are no big new features or improvements we could really show for users - latest beta releases didn't get many downloads. Second point is important. If users don't download and test these releases, what is the point in doing them? I think we need to change our release policy for beta releases. Regards, Kimmo |
From: Kimmo V. <ki...@wi...> - 2008-12-15 18:51:22
|
Hi all, I'm not anymore updating user manual or shell extension version numbers in the sources. Indeed I will set the version numbers to some dummy values later. The reason is I created a script for setting these different version numbers. The script is: Tools/Scripts/SetVersions.py My release script also uses this script to set correct version numbers. The script reads version numbers from config file: /versions.ini and that is the file we will be updating in the future. There were several reasons to switch to using script: - it was way too easy to forget to update version number - it was also time consuming to check before doing a release if there were changes and version number bump was needed - installer number used four-number version number from WinMerge which produced ugly release version numbers shown for users (2.10.0.0). - now all version numbers are in one file that is easy to find and keep up to date More info about SetVersions.py script is in SetVersions.txt located in the same folder. Regards, Kimmo |
From: Kimmo V. <ki...@wi...> - 2008-11-06 19:49:51
|
Hi all, I've just uploaded WinMerge 2.10.2 stable release to the Sourceforge. There aren't many changes (which is good!) as 2.10.0 was already very solid release. Only remarkable problem in 2.10.0 was couple of installer regressions. It is totally possible that 2.10.2 will be the last 2.10.x release. Unless there are some new bugs found and/or new translation updates submitted. Otherwise I'd expect we can now fully focus to the 2.11.x development. Regards, Kimmo |
From: Kimmo V. <ki...@wi...> - 2008-10-20 18:21:01
|
Hi all, I just committed the patch: #2175736 Add compare statuses without bin/text info http://winmerge.org/patch/2175736 to SVN trunk. So this will be in 2.12 stable too. I've written about reason for the change in the devel-forum post: http://apps.sourceforge.net/phpbb/winmerge/viewtopic.php?f=6&t=4 I understand this change can cause some confusion as the status texts and icons change from what people have used to. But more I think about this change, more important I think it is. So far WinMerge has shown simply incorrect information - we have told the user that the file is text file (with icon and text) even if we didn't have any clue what kind of file it is. Now we do tell only what we know. E.g. in date/size compare method we have no clue if the files are text/binary so "general" status is proper. For full compare we always know the type so we show text/binary file statuses. Icons are quite unfinished as I just made them different enought from current icons for testing. Help is appreciated with icons. If this makes results harder to read or even more confusing, I think we should consider changing the text/binary statuses, but the generalized status is there to stay. I don't know how many bug reports I've closed about this "feature" earlier. Hopefully this eventually makes results more consistent in regards text/binary status. Regards, Kimmo |
From: Kimmo V. <ki...@wi...> - 2008-10-01 21:02:43
|
Hi all, there's been lately a bit of confusion if we should/need/want to support VC6. And I admit I've formatted my comments a bit vaguely. Like that we can take patches if they don't effect to other versions etc. But as of now, in SVN trunk, and in next experimental release as a first public release the VC6 support is deprecated totally. No buts, no ifs and certainly no complaints about this. We simply forget the VC6 and its support now. I won't apply any "VC6 fix" patches anymore, and most probably just reject possible bugs reported against VC6. The very simple reason is VC6 is outdated and buggy. It is over 10 years old too. We need to modernize WinMerge and the code to take advantage of modern technology. WinMerge cannot be build upon limitations of 10 years old compiler. I will update the documentation in SVN and in wiki in next days. Regards, Kimmo |
From: Kimmo V. <ki...@wi...> - 2008-09-22 14:06:24
|
>> Translations >> |-Installer >> | |-German.isl >> | |-Spanish.isl >> [...] >> |-Readme >> | |-ReadMe-German.txt >> | |-ReadMe-Spanish.txt >> [...] > > Sounds good! But should we maybe name the folder for the installer > "InnoSetup"? Hopefully we have one day a MSI setup too and need then a > folder for his translations. Good point. Though until we'll get MSI setup we propably have changed the system again... :) >> Perhaps our solution could be a bit more user-friendly solution to use >> Languagename_countrycode.po? E.g. German_DE.po, Portuguese_BR.po? > > Is the country code not also the top level domain for the country? So I > think the most German WinMerge users should know, that they must work > with the file "de_DE.po". ;-) > > So I would vote for "languagecode_countrycode"! Although I had some reservations for this earlier, I think this is the best way after all. Gettext uses this style so it must be familiar for lots of translators. So let's use this naming scheme. > Should we add the project name to the files? Like "WinMerge-de_DE.po" > and "frhed-de_DE.po"? In this case the translators don't would need > subfolders for their work. Nice idea. Downside is the folder gets cluttered as there are several kinds of files in the same folder, different naming schemes, different extensions etc. And I think it is easier for tools to handle files when all the files in the same folder (e.g. copy all .po files to correct folder when building). So what we now need is somebody willing to do the work for moving files and fixing scripts etc. Regards, Kimmo |
From: Kimmo V. <ki...@wi...> - 2008-09-22 13:54:08
|
[I sent this few days ago, apparently it got lost somewhere..] Hi all, I just noticed WinMerge has been downloaded over four million times! That is huge amount for this kind of software. WinMerge is also #95 in all time Sf.net downloads. To look at the stats, go either to WinMerge download stats in project pages or to Sf.net all time download numbers in: http://sourceforge.net/top/topalltime.php?type=downloads Regards, Kimmo |
From: Kimmo V. <ki...@wi...> - 2008-09-17 12:04:21
|
Hi all, finally the 2.10.0 release is available. It got delayed week or so as I was busy with other things. I'm really hoping this release will be "the" release we can compare further releases. Reasons I'm considering this so special release are simply: - this time we didn't add new features - but we fixed lots of bugs and - made many improvements - manual was practically rewritten (look at it: http://winmerge.org/docs/manual/) Development-wise the 2.10 branch will be limited (like before the release) to: - bug fixes with minimal risk - documentation updates - translation updates Trunk is for new features development. I'll create new stable branch for 2.12 branch in few weeks. I'll send more information about 2.12 and branch later. Regards, Kimmo |
From: Kimmo V. <ki...@wi...> - 2008-09-10 19:11:59
|
Tim Gerundt wrote: > Kimmo Varis wrote: >> Only commits allowed to 2.10 branch are: >> - bug fixes with minimal risk >> - translation updates >> - documentation updates > > We must still change the URL from the web manual in the help menu. Or > should we drop the "use web manual when CHM file is missing" feature? We need to update the URL (its in Src/Constants.h). For trunk we can remove using web manual altogether, but we don't do such changes in branch. > I work on the patch for the new website structure and the new manual URL > would be: http://winmerge.org/docs/manual/ Sounds good. Regards, Kimmo |
From: <ti...@ge...> - 2008-09-10 16:22:49
|
Kimmo Varis wrote: > Only commits allowed to 2.10 branch are: > - bug fixes with minimal risk > - translation updates > - documentation updates We must still change the URL from the web manual in the help menu. Or should we drop the "use web manual when CHM file is missing" feature? I work on the patch for the new website structure and the new manual URL would be: http://winmerge.org/docs/manual/ Greetings, Tim |
From: Kimmo V. <ki...@wi...> - 2008-09-09 17:41:09
|
The 2.10 RC release is now uploaded to Sf.net. This means we are very close to 2.10.0 stable release. I expect to release 2.10.0 next week. Exact date depends how much I have time and if we have some last-minute fixes. Only commits allowed to 2.10 branch are: - bug fixes with minimal risk - translation updates - documentation updates Regards, Kimmo |
From: Tim G. <ti...@ge...> - 2008-09-02 20:47:57
|
Kimmo Varis wrote: > I'm not sure we really need every manual version in the web anymore. We > always install local manual anyway. Who needs to look for old version > manual from the web? And pretty much same for the release notes. Release > notes is included into releases. I think too, that the manual in the web now only a bonus is. Every new installation has the correct manual as CHM file. And I think you can work local better (and faster) with the CHM manual instead with a web version. And old release notes are only interesting for history reasons. I will work on a patch. Maybe I can even use my old patch #1893155 "Web: Initialize 'Documentation' tab": http://winmerge.org/patch/1893155 Greetings, Tim |
From: Kimmo V. <ki...@wi...> - 2008-09-02 20:46:25
|
>> Perhaps our solution could be a bit more user-friendly solution to use >> Languagename_countrycode.po? E.g. German_DE.po, Portuguese_BR.po? > > Is the country code not also the top level domain for the country? So I > think the most German WinMerge users should know, that they must work > with the file "de_DE.po". ;-) Unfortunately domain names and ISO country codes aren't 1:1. There are exceptions, though not many: http://en.wikipedia.org/wiki/Country_code_top-level_domain And yes I know my country's country code. But I've no idea about (for example) Slovenian country code. So when someone sents me Slovenian.po I need to find correct country code first. Which most likely just delays me committing that update. -Kimmo |
From: Tim G. <ti...@ge...> - 2008-09-02 20:35:01
|
Kimmo Varis wrote: > First problem of files being scattered all over folder structure could > be solved by creating new top-level folder for them. E.g. > "Translations". Under that folder we could have own subfolder for each > component having actual files. Like this: > > Translations > |-Installer > | |-German.isl > | |-Spanish.isl > [...] > |-Readme > | |-ReadMe-German.txt > | |-ReadMe-Spanish.txt > [...] Sounds good! But should we maybe name the folder for the installer "InnoSetup"? Hopefully we have one day a MSI setup too and need then a folder for his translations. > Perhaps our solution could be a bit more user-friendly solution to use > Languagename_countrycode.po? E.g. German_DE.po, Portuguese_BR.po? Is the country code not also the top level domain for the country? So I think the most German WinMerge users should know, that they must work with the file "de_DE.po". ;-) So I would vote for "languagecode_countrycode"! Should we add the project name to the files? Like "WinMerge-de_DE.po" and "frhed-de_DE.po"? In this case the translators don't would need subfolders for their work. Greetings, Tim |
From: Kimmo V. <ki...@wi...> - 2008-09-02 17:18:43
|
I added a comment to Jochen's patch item for binary editor about this: #2036603 Side by side hex diff/edit/merge view http://winmerge.org/patch/2036603 I objected two things: - yet another folder for translatable files - yet another naming scheme Of course I don't mean Jochen's patch added these problems. The problem has already existed for a long time. But I don't want to make it worse. What kind of translated files we have: #1 WinMergeU.exe - Src/Languages - filename is [languagename].po (German.po) #2 Installer - Installer/InnoSetup/Languages - filename is [languagename].isl (German.isl) #3 ShellExtension - ShellExtension/Languages - filename is ShellExtension[languagename].rc (ShellExtensionGerman.rc) #4 Readme - Docs/Users/Languages - filename is ReadMe-[languagename].txt (ReadMe-German.txt) #5 heksedit (as in current trunk) - Externals/heksedit/Languages - filename is [languagecode].po (ge.po) Now imagine being translator and: - trying to keep up with the changes and keep translations up to date - wanting to translate WinMerge and find all those files Many translators find/bother only with WinMergeU.exe part. First problem of files being scattered all over folder structure could be solved by creating new top-level folder for them. E.g. "Translations". Under that folder we could have own subfolder for each component having actual files. Like this: Translations |-Installer | |-German.isl | |-Spanish.isl [...] |-Readme | |-ReadMe-German.txt | |-ReadMe-Spanish.txt [...] The problem with different filenaming schemes is trickier. Jochen's idea to use languagecode is good. But only language code makes filenames short and "uncomfortable". Where is the German file? And we have two Chinese translations. Currently we also have a bit weird naming for executable lang files. E.g. we have Brazilian.po and Portuguese.po. Which isn't very logical. The gettext uses languagecode_countrycode.po scheme, as documented here: http://www.gnu.org/software/gettext/manual/gettext.html#Locale-Names Perhaps our solution could be a bit more user-friendly solution to use Languagename_countrycode.po? E.g. German_DE.po, Portuguese_BR.po? Note, I'm not really suggesting real solutions (yet). I'm just document the issues and present some possible solutions. Changing folder structure and/or filenames requires changes to many places: installer, documentation, scripts etc. So it takes time and effort to do. We can't do these kind of changes many times, so we'll need some real solutions first before starting doing these changes. Regards, Kimmo |
From: Kimmo V. <ki...@wi...> - 2008-09-02 15:58:45
|
>> now that 2.8.6 as a last 2.8.x stable release is out it is time for 2.10 >> stable release planning. As far as I'm planning releases that is. ;) > > Btw, what is with the website? Need we a "2.10" tab or should we now > switch to a website without version number tabs/folders? If we really > release 2-3 stable x.y.0 releases in a year, we will get many content > that must maintained. Good question. And unfortunately I don't have a good answer. Obvious per-release data we have are: - manual - release notes I'm not sure we really need every manual version in the web anymore. We always install local manual anyway. Who needs to look for old version manual from the web? And pretty much same for the release notes. Release notes is included into releases. Regards, Kimmo |
From: Tim G. <ti...@ge...> - 2008-09-01 22:29:32
|
Kimmo Varis wrote: > now that 2.8.6 as a last 2.8.x stable release is out it is time for 2.10 > stable release planning. As far as I'm planning releases that is. ;) Btw, what is with the website? Need we a "2.10" tab or should we now switch to a website without version number tabs/folders? If we really release 2-3 stable x.y.0 releases in a year, we will get many content that must maintained. Greetings, Tim |
From: Marcel G. <mar...@po...> - 2008-08-16 14:18:53
|
Thanks for the clarifications Marcel |
From: Kimmo V. <ki...@wi...> - 2008-08-16 08:03:43
|
> The Winmerge.csproj has 4 configurations: > Debug/Release > UnicodeDebug/UnicodeRelease > > I know the Debug/Release are for Windows 95/98/Me but I was wondering: > Are we still supporting these platforms? I'm not personally testing WinMerge in W9X, but I know there are people who do, especially W98 is still popular. W95 might not work anymore, and no idea about WMe. > If we are, we might want to use the > "Microsoft Layer for Unicode" (see > http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx) > instead of: I know "MSLU", its been discussed few times between developers in past. But it is kind of hack that really wouldn't byu anything for us. It is not a real unicode support. It might even make WinMerge implementation harder as then we had to deal with its "features". And more importantly it requires users to install such a beast to their Windows. They aren't going to do that just for WinMerge. So they don't install WinMerge. This installing point is *VERY* important. WinMerge is a *tool* that wants to help people doing their work. That means it must be easy and fast for users to install WinMerge to new machines when they happen to need a compare/merge program. Any additional dependencies makes it much more unlikely people bother to install WinMerge "just for comparing couple of log files". And WinMerge still can be installed with "xcopy" method. Just unzip the binary release zip to new folder and run it. Yes, new runtimes might be needed also, but it is not like installing new system components. For 2.8.0 there are over 12 thousands of downloads for executable zip. So people definitely are using and needing this way of installing. I know lots of programs already have abandoned W9X support. But I don't want to do that yet. I've been writing good amount of WinMerge code and additional work done for W9X support has been small. Nobody installs W9X to new machines, but there are still machines running W98. Some day we have to drop W98 support, but I don't think that day is yet. We need to think this again after 2.12.0 release. Indeed, we just integrated hex editor component into trunk, which is plain ANSI supporting code... Regards, Kimmo |
From: Marcel G. <mar...@po...> - 2008-08-16 03:53:41
|
Hi all, The Winmerge.csproj has 4 configurations: Debug/Release UnicodeDebug/UnicodeRelease I know the Debug/Release are for Windows 95/98/Me but I was wondering: Are we still supporting these platforms? If we are, we might want to use the "Microsoft Layer for Unicode" (see http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx) instead of: 1- having 2 different builds 2- cluttering the code with: #ifdef UNICODE /// something #else /// something else #endif or #ifdef _UNICODE /// something #else /// something else #endif 3- Having DBCS-specific code (at least in stringdiffs.cpp, ccrystaltextview.cpp,crystalparser.cpp) 4- Having TCHAR, LPCTSTR, LPTSTR, etc. instead of wchar_t (or WCHAR) const wchar_t* (or LPCWSTR) wchar_t* (or LPWSTR) So, do we still support Windows9x/Me? If yes, what do you think about the "Microsoft Layer for Unicode"? Marcel |