GNOME Bugzilla – Bug 518179
Starting new comparisons could be better
Last modified: 2014-03-03 06:07:10 UTC
I have been thinking a little bit on Meld's usability, especially the dialog that appears when you click the New button. I hate how the current thing works because you either have to type the whole path by hand, or be very patient to do drag and drop. Things should be more fun to use. So what I suggest is a brand new dialog, without tabs (Meld should be smart enough to understand what I want to diff. Really.). Only three filechooser buttons for dragging stuff onto them, or for clicking them and selecting a file of folder. When this dialog is shown, the main window (which is often maximized) should set its state to HIDDEN, that way it encourages dragging and dropping files or folders from your file browser or desktop, in a much more efficient way. Otherwise, the main window will be in the way. We don't need it on startup *anyway*, we only need the "New diff" dialog. See attached mockup. So, here are the changes I propose: 1- hide the main window unless there really is data to show in there, otherwise show the "new diff" dialog. If the user clicks cancel, the main window reappears. Or you might want to use minimization if you want to avoid hiding at all costs. 2- kill those complicated tabs in the "New diff" dialog. Meld should be smart enough to know that I either a) dragged 2, or 3 files b) dragged 2, or 3 folders c) dragged a version-controlled folder Maybe there could be a "recent diffs" button added to this dialog. When you click it, a listview of previously diffed stuff appears, and allows you to select one (or cancel). That way, everybody is happy.
Created attachment 105801 [details] mockup
To make things even easier, the "OK" button should be set sensitive as soon as meld detects that conditions A, B, or C are satisfied. It would be like a "green light" signal for the user.
I also often use drag-and-drop, since I use Meld almost exclusively for local files and directories. The most annoying thing for directory compares is that, if I didn't remember to switch to the directory tab first, then I get an error when I drag two directories and press "OK". Meld should simply do a directory compare for two or three directories in the files tab, as long as they're not a mix of files and directories (and inversely, for two or three files in the directories tab). I do see the need for a tab in a way: The dialog box presented needs to "stop" on a directory for directory compares. So the "Open" button selects it for compare, and double-clicks open it (navigate into it). Conversely, for the file dialog, the "Open" button navigates into the directory since the user can only select a file. I propose: Add a "Select" button to the dialog. "Open" always opens a directory (unless none is selected). "Select" always selects a directory or file for use in the file comparison. And of course, "Open" would also select a file (since it makes no sense otherwise). This way, a single dialog box could be used for file and directory compares, instead of forcing the user to make a pre-selection.
I'm not sure why there should even be an open dialog at all. Shouldn't we just drag the files directly into the pane in order to open them? We should be able to drag multiple files at once, too, and it will automatically assign them to panes, and then there should be buttons for swapping the panes around if we put them in the wrong order. What does kdiff3 do for this?
I don't think that can work since the selector button in the mockup makes you specify at creation time whether it's a file selector or a folder selector. I'm in favour of dropping the popup new dialog. However I don't think we can purely rely on drag and drop since many people will paste paths into the file entry. One possibility is that <Control>+N creates a new tab right away. The contents of the tab are the three tabs from the popup dialog, except stacked vertically so all are visible. Now you can drop items onto the three areas or browse and click ok and the tab contents will be replaced with the correct component. Also I think it's reasonable that even if you haven't created a new tab, files dropped should attempt to fire up the correct view.
Opening a new, empty tab makes some sense. I don't think a dialog box is bad, but removing that intermediate step isn't a bad idea. On the other hand, there'd have to be some sort of equivalent to the OK button to start the comparison (closing the tab would be the same as Cancel). I wouldn't want the diff to automatically start, especially for a large directory compare. Still, whether dialog or not, the user has to select a tab *before* dragging or selecting items to indicate his intention. There have been many times where I've started a process in the File tab and realized that I couldn't select a directory, so I have to re-navigate the same path in the Directory tab. Personally, I think a *lot* would be improved if there was simply a change to the validation logic for the paths - with or without a change to the dialog/new pane. Currently, if I drag two/three folders into the File pane, I get two/three (not just one!) error dialogs. Same if I drag two/three files into the Directory pane. Meld obviously knows whether the target path is a directory or a file. So why not simply do the expected comparison if all paths are the same type? And if they aren't the same type, a simple dialog (but only one :-) ) stating that the paths are mixed types. And please don't close the dialog box before the validation... That means I have to start over, instead of being able to correct my error. (Obviously, wouldn't apply if the dialog moved into a new tab in the main window.)
(In reply to comment #5) > I don't think that can work since the selector button in the mockup makes you > specify at creation time whether it's a file selector or a folder selector. Well, there are three modes, right? File comparison, Folder comparison, and version control view. What if you had three buttons, for "New file compare tab" "New folder compare tab" and "New version control tab"? Instead of having three tabs in a "New" dialog, each with file choosers. The tabs already have file choosers at the top, so why do we need the New dialog at all? The only functionality it provides is to select between the three modes, and to select between two-pane and three-pane mode. Each of these selectors could just be added to the main toolbar somehow.
Coincidentally, I'm working on code to change the number of panes in a filediff, so that part is ok. However switching between modes (filediff, dirdiff etc) seems unnatural to me. I'm thinking here of IDEs which allow mixed tabs of source, bitmaps and resources, but don't allow you to mutate one into another. John: See the attached screenie of a "new tab" tab. If you drag and drop items onto meld without first opening the tab, we could open this "new tab" tab with the values filled in, giving you a chance to validate. You'll get inline error reporting if something goes wrong (no dialogs!). I think that addresses everything? BTW the screen is a 10 min hack, not working code. Though I don't think it's a big job.
Created attachment 135456 [details] "new tab" tab
Why do you need a three-way compare checkbox? If there are only two files in the boxes when the user presses Ok, then they only want two panes. Also, I think it should be possible to have a two-pane tab open, and then change your mind and insert a third file.
Yes, I didn't remove the checkbox for the hack but it should go away. And yes, as part of a separate feature, you'll be able to change the number of panes in a diff.
Wow, well it certainly gives visibility to everything! I see now what you meant about a vertical layout. Stephan: I definitely like the idea if inline error reporting! I have an idea for the file/folder selection dialogs that pop up... I know that e.g. the standard Open dialog box is extensible (for previews, file type filters, etc.) Is it possible to do the same with the dialog box that comes up when you press a Browse... button? I ask because it could be possible to simplify things. Say this is the path dialog box: +-----------------------------------+ | +-----+ +----------------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-----+ +----------------------+ | | | | [ Cancel ] [ Open ] [ Select ] | +-----------------------------------+ Instead of simply having Open, there would be an explicit "Select" button. Double-clicking on a folder would open it (navigate to its contents), same as Open. But Select would choose that folder for the diff. For files, either Open or Select would select the file, as would double-clicking. This would completely avoid having to find and click on the "right" button. With the 7 "Browse..." buttons in the mockup, I think that it might actually be harder to focus on the task of choosing a set of files or folders than in the current tabbed interface. BONUS: Once the user has made one selection, then the next Browse... dialogs would filter to the same kind. So a folder selection dialog would show the same interface (since "Open" vs. "Select" still makes sense), but wouldn't allow to select files. And a file selection dialog wouldn't allow "Open" to select a folder, but would rather open it in the same way as the folder selection dialog would. EXTRA BONUS: no need for 6 buttons (3 for file, 3 for folder) - only need three. The first selection would choose the item *and* the type at the same time. Not sure if that's totally clear, it's been a long day. But of course, it would have to be technically possible, and I'm not the one who can say... :-)
Er... EXTRA BONUS: no need for 6 buttons (3 for file, 3 for folder) in the "new diff" page, only three. The first selection (in the resulting Browse... dialog) would choose the item *and* the type at the same time (for the Browse... dialogs that would follow for the same diff operation). ...maybe that's a bit better-explained.
"Open" vs "Select" doesn't seem intuitive to me. I think "Select" only makes sense in the context of a dialog that does nothing but select a folder. Could it be "File" and "Folder" buttons instead? (Is there any precedent for a file chooser that can accept either files or folders, to compare with? Maybe a media player that lets you import individual files or all the files in a folder?) Is it possible to select more than one file in the Open dialog? Like Ctrl+click on three files to select them all for three-way compare? (Of course this wouldn't work for files in separate directories.) Would it make sense to somehow fold the browsing and selecting functionality of the Open dialog directly into the New Diff tab?
I'm glad to see some attention given to this bug, but please compare, for a minute, attachment #105801 [details] to attachment #135456 [details]. There's something troubling me here. Steph's "newer" mockup is 99% the same as the current implementation, minus the tabs! The point of this was to get rid of this 7+ widget-mumbo-jumbo stuff that does not look very good, clutters the ui, and doesn't seem to provide added functionality over 3 native filechooser buttons. I also agree with some stuff from comment #12 The reason I reported this bug was that the current workflow was suboptimal in the sense that it "wanted the user to understand how the software thinks behind the scenes" instead of just figuring out what to do with whatever the user unleashes on it. This is part of doing Good Design that makes you think "damn, Meld is smart". Here is a rehash of my thoughts: - The user shouldn't care about "this is a three way compare" or not; the software can count to three and pull the Holy Pin automatically. - The native filechooser buttons feel more native/integrated, allow drag and drop for free, allow showing the file chooser (which itself has built-in "hand-typed path", searching, shortcuts, etc.). Why use a combination of a gtk comboboxentry + button instead? I don't understand. - Meld could be more intelligent. It should figure out what to do (or tell me that I'm asking for impossible stuff if I didn't read the instruction label), not expose its inner plumbing. See Matthew Garrett's great analogy for this: http://www.advogato.org/person/mjg59/diary/180.html
Jean Francois - Fair point, the screenshot is only marginally better than the existing dialog. The idea is that there's not enough context in a drag and drop to do exactly the right thing (you dropped a folder, is it the first of two or do you want a vc view?), so the new interface should fill out it's best guess and give you a chance to confirm. Perhaps a better option is to embed a single filechooser widget (not chooser button! - we don't want several popups) directly into the tab along with a list of the items you've selected so far or the items you've dropped. They are entries so you can paste into them too. There are three buttons somewhere near the entries to start each of the three tab types with the values provided so far. We can put focus on the one we think most relevant given the current inputs or tell the user why a given combination won't work. Glade mockups welcome! Personally, I hate file browse dialogs and usually paste the paths directly into the entries. With the above approach though, I think the drag&droppers, path pasters and file browsers can all be happy. As for the reason for the combo+button, it's mostly due to inertia - in the beginning meld used the old GnomeFileEntry widget and the replacement mimicked that interface. If there's an alternative which allows pasting & editing without going through a popup, I'm all for it. I think their use in the rest of the app should be revisited, but that's a separate bug.
In Git HEAD, the old dialog has been replaced with a 'New comparison' tab. In my opinion, this is a significant improvement, but it could still use some love. If anyone is still interested in discussing this piece of (particularly tricky) UI then here is a good place to do it.
*** Bug 342701 has been marked as a duplicate of this bug. ***
Looks like no suggestions are forthcoming, so closing. Feel free to open up new bugs about the current UI if needed.
FWIW, looking at version 1.8 and 3.11, I think I'm quite happy with that new UI. It's actually not far from the mockup I had originally designed in 2008. It doesn't hide the big main window (so if maximized, dragging from another app requires working "around" that window), but I guess I'll let that requirement go, it's not the end of the world. Thanks, Kai!