Re: Meld 3.11.3

[Kai Willadsen <kai willadsen gmail com>]

On 25 August 2014 22:22, Angel Ezquerra <angel ezquerra gmail com> wrote:
> Hi,
>
> I just tried these windows binaries and I had a few problems. I list
> them here starting from the most serious in case you are interested:

While I appreciate the feedback, this is way too late in the release
cycle to fix most of these for 3.12. I may look at a couple, but most
will have to wait for 3.14.

> 1. The most serious issue is that I can just not diff some files. I
> get the following error message:
>
>     
> E:\aem\Workspaces\TERMINATOR\LTE\SW\LTE_L1_SW_SRC\LTE_L1\AcquisitionDriver\src\AcquisitionDriver.cpp.orig
> is not in encodings: ['utf8']
>
> I believe I could open these files with Meld 1.8. I can open them fine
> with every text editor I've tried. I don't think meld should expect
> the files to be in a particular encoding. This problem is so serious
> that I cannot use this version of meld at all.

The previous version of Meld tried by default to decode in UTF-8 and
latin1. This was *extremely* broken behaviour, as latin1 will always
succeed, regardless of actual file encoding.

In 3.11.x, I've removed the latin1 default. I'm *not* going to put it
back into the list in the settings, because that would mean that that
monstrosity would persist (i.e., the setting may persist when someone
updates). I *could* put a latin1 fallback in code and remove the
fallback in 3.14 once this is fixed properly. This would then be
more-or-less the same awful behaviour that we've always had so...
well... great, I guess?

The "Release Plans" email that I just sent mentions 'per file encoding
selection' for 3.14:
    https://mail.gnome.org/archives/meld-list/2014-August/msg00015.html
Between that and some auto-detection fallback code, this should fix
the problem more sanely.

> 2. I cannot get syntax highlighting to work (tab completion was
> disabled on the preferences by default, but enabling it did not fix
> the problem).

I'm not sure why syntax highlighting isn't working, but we've
definitely never supported tab completion.

> 3. TortoiseHg does not detect meld:
>
> The reason is that TortsoiseHg expected to find an entry on the
> registry that would tell it where to find the meld executable (either
> "SOFTWARE\Meld\Executable" or "SOFTWARE\Wow6432Node\Meld\Executable").
> It is possible to manually fix this problem since you can tell
> TortoiseHg the exact location of meld. Also, I am a member of the
> TortoiseHg team, so we can change that so that TortoiseHg looks for
> the meld executable by location (in
> "${ProgramFiles(x86)}/Meld/meld.exe"), but having a registry entry (as
> many other diff tools on windows do) seems better, since it would let
> the user install Meld somewhere else.

Yeah I don't really know anything about the MSI we're generating
here... obviously it would be nice to be generating something more
sensible. Keegan had several similar suggestions that I've failed to
followed up on due to complete lack of time.

Could you file a bug for this please?

> 5. Every time that I open a new meld comparison from TortoiseHg a new
> meld instance is open. I don't recall if older versions of meld
> behaved this way. In any case, is there some flag that we can pass to
> the meld executable so that a single meld instance is used?

I don't know whether this works on Windows, but on Linux the opposite
of this is now true. We used to by default run a separate instance
each time we were run, and now we're a single instance app that
happens to open multiple windows, though with a few exceptions you
shouldn't notice this.

If you're just talking about the number of windows we create, then
yes, we've always created new windows by default. The --newtab option
should still work however.

> 6. The open externally option does not work by default. I guess it is
> because by default the "Use default system editor" is enabled by
> default. It should be possible to use a windows API to open a file
> with its default editor.

Could you be more specific about 'does not work'? It has (fairly)
recently worked for me.

On Windows, this is equivalent to running 'start <path>'. According to
a comment I don't remember writing, file type detection with gio on
Windows is broken, so if you're expecting to see some more specialised
behaviour then that could be the issue.

> 7. The text in the meld menus seems very "squeezed". The text in the
> menus seems have a proper size, but the height of the menu rows seems
> to bee too small.

This is the GTK theme. I believe this should be fixed by updating the
GTK we bundle.

> 8. In my pretty powerful PC scrolling a diff is a bit jerky. It is not
> as smooth as in other diff tools.

This probably isn't something I can do much about. It's certainly
possible that it's us, but just as likely that it's GTK on Windows.
Are you saying that this is noticeably less smooth than 1.8.x?

> In addition, and this is not related to the windows port, I find the
> new comparision window very confusing. The problem is that there are 3
> buttons (file comparision, directory comparision, and Version Control
> View) and 3 file combo boxes right below them, but they are totally
> unrelated! That is, if you click file comparison the combo boxes are
> all related to file comparisons, if you click directory comparision
> they are related to that. The only visual clue that tells you that
> they are related to a mode is that the mode button that you clicked is
> highlighted, but IMHO this is not enough. I think there should either
> be some additional visual clue (e.g. a panel surrounding the combo
> boxes linked to the selected mode button or something of the sort) or
> perhaps the combo boxes should be stacked vertically instead of
> horizontally so that it does not seem that they are related to the
> comparison type buttons.

Others have had similar comments. If someone want to look at improving
the layout and/or themeing then that would be great. However, I
haven't actually seen any suggestions that I like yet.

> Anyway, despite these problems (expcept perhaps #1 and #2) this
> version looks very promising. I can't for #1 to be fixed so that I can
> actually use it.

You should be able to 'fix' this manually by setting the
(unsupported!) gsettings key at /org/gnome/meld/detect-encodings to
["utf8", "latin1"] or similar. I don't actually know how to do this on
Windows however. I believe that gsettings on Windows backs on to the
registry, but can't tell you anything else about it.

cheers,
Kai