Re: [RFC/PATCH 0/7] Tab updates

[Kai <kai willadsen gmail com>]

On 31 August 2010 16:17, Peter Tyser <ptyser gmail com> wrote:
> These 7 patches change the tab behavior of meld.  I couldn't find hard
> human interface guidelines, but I personally view the changes as an
> improvement.  Others may feel differently, so feel free to reject
> some of them, ask for additional info, etc.

I'm keen to see something happen with the tabs. I like where you're
going with these patches, but in some cases I'm not convinced that
it's the right way to fix the problem. I'm going to respond very
quickly to these here, rather than in the individual patches.

> Peter Tyser (7):
>  Only show tabs if there are more than 1

I'm of two minds about this. Getting rid of clutter is great. However,
I personally think that tabs should always be shown in any application
where you expect users to use multiple tabs. For me, this means that
starting with a VcView or a DirDiff should show tabs; starting with a
single FileDiff... probably shouldn't?

Anyway, discussion required I think.

>  Allow reordering of tabs

This is a gtk 2.10 feature, so can't go in to current head. I'm happy
to put it in post-1.4 though.

>  Add ability to set the tooltip text of a tab

Looks good.

>  Update handling of tab labels and tooltips

I like the tab tooltip changes, but I'm not convinced that this is the
right way to deal with tab labels. I'd like to figure out what the
minimum detail is that we can use to differentiate comparisons.

Here's a strawman proposal. We should omit repetition of file and
directory names, shorten path names down to the closest unique
element, and generally abbreviate where it makes sense. For some
specific examples, a VcView of /home/me/Geekery/meld should probably
display as:
    [git] ~/Geekery/meld
and if the path component got too long, we'd just abbreviate it to:
    [git] meld
and leave the detail to the tooltip. FileDiff tabs launched from a
VcView should be roughly the same, so:
    [git] meld/meld/filediff.py
or
    [git meld] meld/filediff.py
also abbreviating the path component if required. DirDiff tabs (and
FileDiff tabs launched from DirDiff) are more complicated. I'd say
that we want to trim identical prefixes and suffixes from both paths
for the tab label, so comparing /home/me/Geekery/meld/meld/ui/ to
/home/me/Geekery/meld-1.3.3/meld/ui should yield something like:
    [meld -> meld-1.3.3] ui/
and comparing meld/filediff.py from that DirDiff would give:
    [meld -> meld-1.3.3] filediff.py
It's possible that just taking the first differing element in the path
would suffice here.

Anyway, that's my strawman, so... comments?

>  Update NotebookLabel tab drawing

You're correct that the HIG recommends dynamic tab widths, but I
suspect that this might an out-of-date recommendation; FWIW, Meld's
tab drawing was heavily inspired by Epiphany, and it's difficult to
think of a more Gnome-y app. It would be interesting to know what HIG
version 3 is going to say here, though with natural text width in 3.0,
dynamic tab widths + ellipsizing should make more sense too.

>  filediff: Make non-writable files uneditable
>  vcview: Make version control base files un-writable

I agree that we need to do something better with non-writable files,
but I don't know that this is it. I think it's not that unusual to
want to make changes to an uneditable file in order to get diffs to
match up better. I often do something like this in three-way merges.

There are things that could be done here though: we could make them
uneditable by default, and have a small unlock button; or we could
keep them editable, but have a InfoBar-like warning pop up to indicate
that the file can't be saved.

cheers,
Kai