I meant to send this email months ago, and it got lost. Sorry about that. On 28 January 2013 05:24, Angel Ezquerra <[email protected]> wrote: > On Fri, Jan 25, 2013 at 9:36 PM, Kai Willadsen <[email protected]> > wrote: >> On 22 January 2013 04:34, Angel Ezquerra <[email protected]> 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 _______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
