GNOME.org
 

Re: Making the file labels easier to see

I meant to send this email months ago, and it got lost. Sorry about that.

On 28 January 2013 05:24, Angel Ezquerra <angel ezquerra gmail com> wrote:

On Fri, Jan 25, 2013 at 9:36 PM, Kai Willadsen <kai willadsen gmail com> wrote:

On 22 January 2013 04:34, Angel Ezquerra <angel ezquerra gmail com> wrote:

Hi again,

I am current integrating meld with the TortoiseHg mercurial client, of which
I am one of the developers. We were already able to run meld on Linux but
now that there is a nice Windows installer I'd like to be able to do so from
windows as well. In doing so I've been using meld for a few days (I had not
used it before because I normally use Windows), and I've noticed a few
things that could make our integration a bit better.

In particular, we use "label" command line options to modify the title that
meld shows when performing a diff in order to tell the user which file
versions are being diffed. This works fine, and puts this information both
on the meld window title and on the diff "tab". However this information is
not very easy to see for two reasons:

1. The window title is transparent on Windows 7. Depending on the background
it can be a bit hard to read.

2. The tab handles have a fixed size, and they do not expand with the tab
label contents. This means that in general the text that is shown on the tab
cut off, only showing part of the whole label. In most cases you can only
see part of the label of the first file that is being diffed.

In addition, setting the label does not change the text of the file
combobox. This is a pity because the combobox is big enough to show the
label, and because it is where your eyes are naturally drawn when the meld
window is open. It took me a little while to realize that I could see the
labels on the meld window title.

So I'd like to propose a couple of possible improvements:

1. Let the tab size increase to fit the label


Having a fixed tab size is a deliberate decision, as variable-width
tabs turn out to be a nightmare in practice. All it takes is a
comparison between two
CustomerSingletonInstanceCreatorSettingsFactoryFactory files, and your
window now contains a single tab.


That is true, but it could also be avoided by simply setting a
reasonable maximum label width (e.g. 1/2 or 3/4 of the windows size).


As far as I can recall, GTK has no support for setting proportional
maximums, at least in GTK 2. GTK 3 may be a different story, but I
haven't looked.


You can try this yourself by commenting out lines 46 and 55 of
notebooklabel.py (i.e., don't set ellipsization, and  don't set a size
request). My feeling from having tested it ages ago is that it works
okay for many cases, and then it breaks the UX.


2. Show a "label" text on top or below of the file combobox, showing the
label corresponding to the file. Alternatively, replace the actual file name
with the label (this is what Ataxia Merge does and it works pretty well).


Meld actually relies on those comboboxes containing the files being
compared in several places, so we flat-out can't do this. In my WIP
branch for a newer comparison UI, I've relaxed some of those
restrictions, so it might be doable in the future.


That is what Araxis Merge does and it works pretty well. That being
said having access to the actual file that is being diffed may be
nice.


Right, but I'm saying that as a current technical requirement, we
can't do that. Untangling that logic is doable (and I've partially
done it in a branch) but it's work and it's invasive.


BTW, it is surprising how similar are Meld and Araxis Merge in many
respects. It is not surprising that both are my favourite diff tools!
:-)


Showing label text above or below would be technically possible, but
I'm very sensitive to good use of space within our UI. The problem is
that in most cases, the label text is totally superfluous once you
have the file path in the combo, so it only makes sense to show the
extra label at all when the value in your combo doesn't matter. As
such, one option would be to hide the combo entirely if we have a
command-line-set label text, replacing it with a gtk.Label containing
the full label text in that case.


One option would be to add an extra command line argument that let you
chose between hiding the combo when a label is set or not. There is a
good case to make against unnecessarily complicating a command line
interface (or any other interface for that matter). However I suspect
that the label command line argument is probably only used by other
tools that launch meld (i.e. they are probably rarely directly used by
actual users). In that case I think you could see the command line
interface as a sort of API to meld, and in that case I think the
richer the better.


The problem here is that it *is* effectively an API, so whenever
something is added to the command-line interface, we're stuck with it!
API design is hard, and getting stuck with baggage that you have to
keep supporting is really, really bad. Also, this is basically adding
an option to hide a piece of UI that may not even continue to exist,
so that's really not something that I want to support.

It *may well* be possible to hide the combo when the label is set,
which would be... an interesting change. However, as you say, it's
very unlikely to break the way most people use the label option. I'd
have to prototype this, but I think it could work.


I appreciate why you're asking for this, and I think it would be good
to fix somehow. Could you provide some examples of labels that don't
fit, so I can get an idea of how big a difference we're talking about
here?


I attach a screenshot of a diff I I just made by calling meld from
TortoiseHg (BTW we'll have meld support on the next release which
hopefully will be in just a few days).

In the screenshot you can see how the text on the tab handle is
unusable. You cannot tell the version number not the version hash of
none of the two panels. This info is essential to tell which panel
shows the newer and the older version of the file.


I can see the problem, but I have to say that I think that if the tab
was slightly wider (say 40 characters instead of 30) and if TortoiseHg
used either the abbreviated hash or just the rev number instead of
both, then it should fit without problems.

We also add the *full* tab title as a tooltip to each tab. I realise
that having to hover over the tab to get these details is pretty bad
UI, but at least it's there.


Instead, you must look at the window title, and while it is usable it
is not very visible either due to the windows transparency on Windows
7.


Yeah that's not great, but unfortunately not something we can fix either.

Could you file a bug about this? I'm considering implementing the
'--label hides the combo-box' option. As I said though, making sure
that the UI works correctly without the combo may be a little tricky.

cheers,
Kai
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]