Plan for WinMerge 2.16

Main development forum.

Re: Plan for WinMerge 2.16

Postby kimmov » Mon Feb 18, 2013 10:45 am

jtuc wrote:Two remaining gaps to close for a fully functional 64-bit release are Merge7z and Frhed (heksedit). I plan to do the Merge7z part in near future, and hope that Kimmo will look after Frhed.

At the moment I have no time or plans for Frhed. Once I have I think I'm going to move it quite radically forward too.

jtuc wrote:Restarting WinMerge 2 trunk is IMHO a waste of time.

Depends what you mean with restart.

This kind of application whose whole point is in GUI and usability cannot look like 20 year old anymore. No matter how much you like those small toolbar buttons etc it just is not modern GUI people want to use anymore. And MFC is dead end. Diff engine is very dated, we are missing all the bug fixes and improvements for last 15 years. Just to mention couple of things. We need radical jump forward if we want to be application people choose to use.

The only thing to choose is if we want to start from almost scratch with new GUI or if we try to modify the existing GUI to become the modern GUI. Starting from scratch of course means we lose a lot of work. But we also can easily forget all the crap there is after years of modifying and start with a clean desing. It is not necessarily any less work than converting current code.

Everybody loves the code they have written. But code also gets old and sometimes needs rewriting. What worked and was good 10 years ago is outdated now.
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Plan for WinMerge 2.16

Postby jtuc » Wed Feb 20, 2013 9:52 am

WinMerge is not about entertaining users. It is about supporting their workflows. GUI is there for accessiblity, not for looking modern. Making this kind of software more attractive for users means listening to their feature requests. Item 4.6 in http://manual.winmerge.org/Faq.html is an example of how to distract users.
jtuc
Developer
 
Posts: 182
Joined: Sat Dec 20, 2008 11:05 am

Re: Plan for WinMerge 2.16

Postby kimmov » Wed Feb 20, 2013 11:24 am

jtuc wrote:WinMerge is not about entertaining users. It is about supporting their workflows. GUI is there for accessiblity, not for looking modern. Making this kind of software more attractive for users means listening to their feature requests. Item 4.6 in http://manual.winmerge.org/Faq.html is an example of how to distract users.

Nice pick. I'm not interested in discussing about that particular FAQ item or its reasoning. I stand by that decision I've made and I have no reason to change it. If you want to implement it to your own fork that is of course your own decision. If some user can't use WinMerge because of one single feature, one can find more proper tool on his use elsewhere. WinMerge is not and can't be tool for every use somebody can have. We have certain workflows we can support, and support them well. With well thought ideas and use cases.

Trying to support everything just does not work. Numerous projects have already proved that numerous times trying to do it. It only leads to bad compromises, sometimes you have to cripple your important feature just to be able to support something else. So in WinMerge we must recognize the features and uses we want to support well. If some new feature would cripple some more important features it can't be done.

Plugins support was a big mistake for example. It allows doing interesting things users want to do. But it also destroys some more important things, like having complete translations. Translations are very important for (millions of) people.

It is easy to just look some minor things and keep complaining. Understanding the big picture for WinMerge as a product is much harder. In most discussions people are only interested of some minor details, not the product.
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Plan for WinMerge 2.16

Postby kimmov » Thu Feb 21, 2013 7:55 am

One important thing to remember is that few loudly complaining users don't make our all users. Most users are just happy using the program. So feature requests can't be thought as "all users want it" but "one user wants us to consider it".
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Plan for WinMerge 2.16

Postby christianlist » Sun Feb 24, 2013 2:31 pm

kimmov wrote:WinMerge is not and can't be tool for every use somebody can have. We have certain workflows we can support, and support them well. With well thought ideas and use cases.


I fully agree here.
Well thought out ideas and implementations are always welcome for WinMerge.
For the niche cases where a few users have very special requests, I have no problem simply directing them to use a fork like WinMerge 2011.

kimmov wrote:Plugins support was a big mistake for example. It allows doing interesting things users want to do. But it also destroys some more important things, like having complete translations. Translations are very important for (millions of) people.


Here is a point were Kimmo and I have been disagreeing for many years now.

I think the plugins are one of the important features that makes WinMerge stand out and be more useful than other diff and merge tools.
The ability to see differences in Word and Excel documents is the killer feature that gets WinMerge installed throughout the company were I work.
It does have problems and shortcomings, but in my opinion they are all outweighed by the benefits.
christianlist
Site Admin
 
Posts: 68
Joined: Thu Sep 11, 2008 5:16 pm
Location: USA

Re: Plan for WinMerge 2.16

Postby christianlist » Sun Feb 24, 2013 2:42 pm

jtuc wrote:WinMerge is not about entertaining users. It is about supporting their workflows. GUI is there for accessiblity, not for looking modern. Making this kind of software more attractive for users means listening to their feature requests. Item 4.6 in http://manual.winmerge.org/Faq.html is an example of how to distract users.


We really need both here.
If we concentrate on workflows and neglect the GUI, then we'll loose our users when they migrate to more modern looking GUIs.
If we concentrate on GUI and neglect workflows, then we'll loose our users when they get tired of using an inefficient tool.
christianlist
Site Admin
 
Posts: 68
Joined: Thu Sep 11, 2008 5:16 pm
Location: USA

Re: Plan for WinMerge 2.16

Postby jtuc » Tue Feb 26, 2013 5:04 am

Plugin support is not a mistake by itself. Mistakes have been made in its design, parts of which are overly complex and inefficient.

Automatic unpacking is a usability issue. It is easy to leave it enabled and then wonder why WinMerge does odd things like truncating log files.

One of the more unfortunate mistakes was ruling out scriptlets for file transforms (WinMerge 2 term: unpackers). This has severely limited the usefulness of the feature for users who won't follow the complex plugin development procedure demanded by WinMerge 2.
jtuc
Developer
 
Posts: 182
Joined: Sat Dec 20, 2008 11:05 am

Re: Plan for WinMerge 2.16

Postby kimmov » Thu Mar 07, 2013 11:41 am

christianlist wrote:Here is a point were Kimmo and I have been disagreeing for many years now.

Please remember I was advocate of the plugins when they were added. I supported Lauren and others when they worked with the feature, investing quite a lot of my time into plugins too.

christianlist wrote:I think the plugins are one of the important features that makes WinMerge stand out and be more useful than other diff and merge tools.

That is where we disagree heavily. Plugins don't solve any real problem we could not solve without plugins and all the complexity and problems involved with current implementation. Basically plugins just allow you to develop with other languages. Everything other we could implement without plugins in much better way. Simple C/C++ DLLs, no fancy COM interfaces or anything.

christianlist wrote:The ability to see differences in Word and Excel documents is the killer feature that gets WinMerge installed throughout the company were I work.

You really don't need plugins for that. Much better to just add the code in native DLL and add GUI to call it.

The idea with plugins was people start writing many of them for different purposes and we don't even need to host them all. In practice all plugins available are in our repository and distributed with WinMerge. So they could be just DLLs distributed with WinMerge. There is the difference I'm talking about. Technically you can say DLLs we distribute are plugins as well, but concept is much simpler as we don't need to support users doing the development independent of WinMerge development. We don't need stable APIs etc.
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Plan for WinMerge 2.16

Postby kimmov » Thu Mar 07, 2013 3:07 pm

jtuc wrote:Plugin support is not a mistake by itself.

If we define plugins as traditional way, as code that can be "plugged-in" to binary, then I agree. But considering these pre-differ etc etc concepts it was a huge mistake. We tried to so something nobody really needs. If users need all that, we sure had tens and tens of plugins using those fancy features? Right? I'd say users have spoken already.

jtuc wrote:Mistakes have been made in its design, parts of which are overly complex and inefficient.

No. The mistake was simple, we didn't know what users really want so we created something we thought users could want. And it appears they don't. Technical things are totally different story.

What I think we need to abandon the current thinking of doing such "fine" plugins. Nobody is implementing them even though the feature has been there for years.

We need just simple C-API with callbacks for the things the current plugins do. And rewrite some Visual Basic code to C++. Make plugins our internal tool without stable public API. Make them just code modules one can load dynamically via some GUI.

Only thing we lose is that users need to compile the plugins agains the WinMerge sources. They can't develop plugins "out of the source tree". That might affect couple of users. And make them to look and learn about WinMerge internals. Versus everybody suffering about the current mess.
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Plan for WinMerge 2.16

Postby jtuc » Fri Mar 08, 2013 7:12 am

kimmov wrote:But considering these pre-differ etc etc concepts it was a huge mistake. We tried to so something nobody really needs.

Very true. Prediffer plugins compensate for crippled linefilters. Once linefilters have a way to take effect before diffutils, prediffer plugins lose much of their point.

I think I remember Perry was going to enhance linefilters in such way, disapproval of which was among reasons to start WinMergeX.

Editor plugins were proof-of-concept code but as such did not match their purpose.

What remains is (un)packers. The term once mislead me to believe they are for dealing with archives. Which turned out to be an illusion. Which is why Merge7z exists.

Command line tools like sort, tidy, MediaInfo, XDoc2Txt to name a few, read from a file and write to stdout. Like good old CGI in web servers. Easy to do with perl/php/python/whatever. WinMerge could technically support this model without messing with temporary files like existing unpackers do, and without requiring precompiled plugins in the form of DLLs, thereby taking away from most users the option to plug in their own code.
jtuc
Developer
 
Posts: 182
Joined: Sat Dec 20, 2008 11:05 am

PreviousNext

Return to Developers

Who is online

Users browsing this forum: No registered users and 3 guests