Frhed integration

Main development forum.

Frhed integration

Postby kimmov » Thu Oct 16, 2008 9:04 pm

So, the Frhed has been included in couple of latest experimental releases. And we still haven't any new Frhed related bugs in our bug tracker? Either people haven't noticed this new feature or it just works...

There are still few things to sort out with this integration. And these issues we must sort out before I will add Frhed to stable release. If we have no solution in month or so, I'll drop Frhed from 2.12 release. Simple as that.

The Manual
This is a big item. Currently we don't ship any kind of help for Frhed with WinMerge. In what format and how we ship the manual? Frhed project generates HTML help file from single HTML file. Basically we should use that same help. But then the Frhed stand alone program's help contains things that aren't there when we embed the editor. Which can cause quite a confusion (is it Frhed's menu or WinMerge's menu etc).

Second HTML help file has also problems. Opening correct help file is not a problem, but linking the help files is. For users there is one program (WinMerge) and they expect to have one manual. Sure we can add own Frhed Help menuitem to WinMerge help menu and Windows start menu. But it is far from ideal or even good solution. Acceptable perhaps?

Ideal would be if Frhed manual was converted to DocBook. Then we could just include parts of it to the WinMerge manual. We'd need some edits to the Frhed manual too, but I think those changes wouldn't be too hard to maintain in future. I personally would prefer this solution. But who has time to do the conversion?

Translation (system)
WinMerge is translated application and has over twenty translations. Frhed must be translated too. Basically the translation system works already. But as we don't have any real translations for Frhed yet we can't even test it. We'd need to get one or two translations.

One thing we haven't yet agreed is where to put those translation files (*.po) and how to name them. My personal opinion is location and naming must match WinMerge location and naming. We can't just invent new folders and naming systems. With WinMerge we already have a problem most translators only bother to translate the .po file and forget/ignore readme files and the shellextension. Basically that is because those are all in different folders and people don't find them. So having WinMerge .po files and Frhed .po files in different folders sounds a bad solution.

Tim suggested to have naming like projectname_languagecode.po. So we'd have files like WinMerge_de.po and Frhed_de.po in the WinMerge's Languages-subfolder. I personally didn't like this idea at first but now I'd prefer it. This of course means we have to rename WinMerge's language files. But it solves more problems than it adds. Like WinMerge's current inconsistency in naming (Brazil.po vs. Portuguese.po).

Opening Frhed from WinMerge
This is an important usability issue. Currently we have just new Compare Special | HEX -menu item in the folder compare context menu. It opens selected files to the binary editor. We must rename the menu item ('HEX') to something more meaningful and understandable.

But then the question is if we should hide the Frhed to context menu or make starting it easier. I think most users don't need the binary file editor or binary file compare. If they compare two jpeg images or mp3 files they couldn't care less which bytes differ. So ideas like automatically opening binary files to Frhed are out of question. Even asking user if one wants to open binary file to text editor or binary file editor is poor solution. How could the user choose?

Frhed Configuration
This is a smaller issue than above ones, not a blocker one. But we need to think about this too. Frhed standalone program allows setting some options for how the data is shown etc. Those are available in Frhed's Options-menu. when used as WinMerge editor component there is no way for the user to modify those options.

Perhaps we can add new context menu item and allow setting most important options from it? Other ideas?
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Frhed integration

Postby gerundt » Tue Oct 28, 2008 9:29 pm

kimmov wrote:Ideal would be if Frhed manual was converted to DocBook. ... But who has time to do the conversion?


Currently I plan my first apartment with my girlfriend. So I have currently less time, but I can work on it in my short free time. ;)

kimmov wrote:But as we don't have any real translations for Frhed yet we can't even test it. We'd need to get one or two translations.


I can work at the German translation! But the most strings are menu items and Frhed don't use this translations currently. If you fix this, I can work on a complete German translations. :mrgreen:

kimmov wrote:We must rename the menu item ('HEX') to something more meaningful and understandable.


Maybe "Compare with Binary Editor" or "Compare with HEX Editor"? Or use "Binary Mode"?

kimmov wrote:Even asking user if one wants to open binary file to text editor or binary file editor is poor solution. How could the user choose?


Maybe we should add a option like "Open binary files with HEX editor" to the preference?

kimmov wrote:Perhaps we can add new context menu item and allow setting most important options from it? Other ideas?


The best would be a "Hex Editor" page at the options dialog. I think this would be the most user-friendly way.
gerundt
Site Admin
 
Posts: 192
Joined: Wed Sep 24, 2008 8:47 am
Location: Germany

Re: Frhed integration

Postby kimmov » Wed Oct 29, 2008 9:56 am

gerundt wrote:
kimmov wrote:Ideal would be if Frhed manual was converted to DocBook. ... But who has time to do the conversion?

Currently I plan my first apartment with my girlfriend. So I have currently less time, but I can work on it in my short free time. ;)


I'm wondering if this could be done with some tool or script. Hand-editing is quite a lot of work. Perhaps there is tool/script available somewhere... So before somebody starts doing that job one should look for those tools/scripts.

gerundt wrote:
kimmov wrote:But as we don't have any real translations for Frhed yet we can't even test it. We'd need to get one or two translations.


I can work at the German translation! But the most strings are menu items and Frhed don't use this translations currently. If you fix this, I can work on a complete German translations. :mrgreen:


Basically all the messageboxes and strings set/formatted by the code are not translatable at the moment. Jochen had some ideas how to do it in the patch item:
#2036603 Side by side hex diff/edit/merge view http://winmerge.org/patch/2036603

gerundt wrote:
kimmov wrote:We must rename the menu item ('HEX') to something more meaningful and understandable.


Maybe "Compare with Binary Editor" or "Compare with HEX Editor"? Or use "Binary Mode"?


I'm bit of reluctant to use term HEX in GUI as it doesn't really mean anything. There is no such thing like hexfile. So I'd prefer binary term.

gerundt wrote:
kimmov wrote:Even asking user if one wants to open binary file to text editor or binary file editor is poor solution. How could the user choose?


Maybe we should add a option like "Open binary files with HEX editor" to the preference?


Which won't work as different people have different meaning for binary files. And as seen in numerous tracker items already we always get the binary file detection from for somebody's files. Perhaps we should just open files we suspect being binary files into the binary editor. AND allow easy and fast switching back to text editor. So from user's perspective it should be just two different views, not two different editors, with easy switch between them. Then it wouldn't be so harmful to guess the filetype wrong.

gerundt wrote:
kimmov wrote:Perhaps we can add new context menu item and allow setting most important options from it? Other ideas?


The best would be a "Hex Editor" page at the options dialog. I think this would be the most user-friendly way.

It also means integration will be a lot more involved from code/GUI point of view. But for the user that would likely be the best solution.
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Frhed integration

Postby gerundt » Wed Oct 29, 2008 9:52 pm

kimmov wrote:So from user's perspective it should be just two different views, not two different editors, with easy switch between them. Then it wouldn't be so harmful to guess the filetype wrong.


Maybe like they can switch the "Tree Mode" in folder compare? "Text Mode" for normal text editor component and "Binary Mode" for Frhed. That would be really easy for the users! They have just one "Compare" button and can later switch between the mods. But it is easy to program? ;)
gerundt
Site Admin
 
Posts: 192
Joined: Wed Sep 24, 2008 8:47 am
Location: Germany

Re: Frhed integration

Postby kimmov » Wed Oct 29, 2008 11:17 pm

kimmov wrote:
gerundt wrote:
kimmov wrote:Ideal would be if Frhed manual was converted to DocBook. ... But who has time to do the conversion?

Currently I plan my first apartment with my girlfriend. So I have currently less time, but I can work on it in my short free time. ;)

I'm wondering if this could be done with some tool or script. Hand-editing is quite a lot of work. Perhaps there is tool/script available somewhere... So before somebody starts doing that job one should look for those tools/scripts.

I did some quick googling and found this tool:
Html2DocBook - http://wiki.docbook.org/topic/Html2DocBook

Looks promising!
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Frhed integration

Postby kimmov » Wed Dec 03, 2008 4:49 pm

So, what has happened with integration is:
  • manual is now converted to DocBook
  • some improvements in translation support

But this is very very far from what we can have in WinMerge stable release. WinMerge stable release definitely won't wait for this to advance (as the speed is moderate so to say).

Which simply means I'll disable Frhed and binary file editing from next stable (2.12) WinMerge release. We won't distribute "alpha level" integration in stable WinMerge release. We have already enough bug reports about WinMerge itself.

No complaints unless you are ready to put lots of time and effort to finishing the integration. And I mean a lot of time.
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Frhed integration

Postby kimmov » Sun Dec 14, 2008 10:01 pm

One idea just came to my mind - what if WinMerge would use heksedit.dll from stand-alone Frhed integration?

So to use heksediting in WinMerge user needs to install Frhed. Which is a small annoyance, and we may even allow WinMerge installer to offer installing also Frhed. Then We'll tell WinMerge where Frhed is installed and WinMerge uses it.
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Frhed integration

Postby jtuc » Sat Dec 20, 2008 11:31 am

kimmov wrote:I'm bit of reluctant to use term HEX in GUI as it doesn't really mean anything.


Ever noticed that Hex button on the Visual Studio Debug toolbar? Now did you have to read the docs to get an idea of what it does?
jtuc
Developer
 
Posts: 182
Joined: Sat Dec 20, 2008 11:05 am

Re: Frhed integration

Postby kimmov » Sat Dec 20, 2008 1:53 pm

jtuc wrote:Ever noticed that Hex button on the Visual Studio Debug toolbar? Now did you have to read the docs to get an idea of what it does?


Visual Studio is not the reference here. It is developer tool and we are making tool for user who never have seen any development tools. And have no any idea about bits, bytes and hex.

Yeah, times have changed with WinMerge, it is not anymore a developer tool we can just assume people know what they are doing.

We must have consistent terminology with this. We discussed about this with Denis when he updated the WinMerge manual for 2.10.
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Re: Frhed integration

Postby kimmov » Wed Apr 15, 2009 10:56 pm

Some progress with this.

The most important change is that Jochen added possibility to register heksedit (Frhed editor component) as COM server to be used from other applications. And added support for WinMerge to use COM-heksedit. So WinMerge now can use hex editor component from stand-alone Frhed installation. This simplifies things a lot.

Other changes:
  • Translations were enabled for latest Frhed Alpha release (1.5.2) - still some strings to do
  • some work done for Frhed Unicode support - but lots of work to do still
This means that
  • as of next WinMerge experimental release we won't be shipping heksedit.dll with WinMerge
  • we'll remove forked Frhed codes from WinMerge source tree
  • if Frhed version with new heksedit interface is not installed, there is no hex editor in WinMerge
  • hex editor inside WinMerge uses settings from stand-alone Frhed
  • hex editor inside WinMerge uses translations (selection too) from stand-alone Frhed
I've been doing some testing with Frhed 1.5.2 Alpha and current WinMerge SVN trunk. Seems to work nicely so once I've updated my build scripts etc needed changes I'll release next WinMerge experimental release.
kimmov
 
Posts: 562
Joined: Thu Sep 11, 2008 8:51 pm
Location: Finland

Next

Return to Developers

Who is online

Users browsing this forum: No registered users and 3 guests