GNOME Bugzilla – Bug 614869
File paths get cut off in properties dialog
Last modified: 2011-10-03 21:29:01 UTC
Created attachment 157970 [details] Screenshot with comments The file path usually cannot be seen in the properties dialog, since it gets cut off. I have attached a screenshot to show you what I mean. A user is forced to resize the window in order to view the full file path, but this operation will not be obvious to most people. There are other things that could be improved in this dialog, btw: the general tab is unecessary as far as I can see. So too are the next and previous buttons and the white area in which information is displayed. I can provide a mockup of an alternative layout if required. (A sidebar might be a better approach than a standalone window, though.)
> > The file path usually cannot be seen in the properties dialog, since it gets > cut off. I have attached a screenshot to show you what I mean. It could instead be ellypsized in the middle if necessary. > > A user is forced to resize the window in order to view the full file path, but > this operation will not be obvious to most people. I think it is a compromise between making the window arbitrarily big, adding a scrolled view, and keeping the window at a reasonable size and without unnedded complexity. > > There are other things that could be improved in this dialog, btw: the general > tab is unecessary as far as I can see. The tab is used when the image has metadata. In that case, other tabs appear. But there is a point on that a more clean approach could be to hide the tab label when there is no metadata. > So too are the next and previous buttons What's so bad about it? I think they are handy for users wanting to browse through the images properties. > and the white area in which information is displayed. This is a consecuence of using the notebook, I think. > I can provide a mockup of > an alternative layout if required. (A sidebar might be a better approach than a > standalone window, though.) Thanks, feel free to provide any mockups. Just in case, there is a plugin already with a sidebar for relevant metadata, but the sidebar approach with general image properties was dropped long time ago (around 5 years ago, during the eog-ng rewrite, I would say). There might be a bug report about that somewhere.
(In reply to comment #1) > > > > The file path usually cannot be seen in the properties dialog, since it gets > > cut off. I have attached a screenshot to show you what I mean. > > It could instead be ellypsized in the middle if necessary. That's a possibility. It could be coupled with a copy button (to copy the text of the file path). The first thing to do is to identify why people might need the file path in the first place. The main reason that I can think of is that they do not have the image's location open with Nautilus and want to perform some kind of operation on it (copy, cut, open with an editor, etc). In this case the addition of an 'Open image location' button could do the trick. > > A user is forced to resize the window in order to view the full file path, but > > this operation will not be obvious to most people. > > I think it is a compromise between making the window arbitrarily big, adding a > scrolled view, and keeping the window at a reasonable size and without unnedded > complexity. Sure. The current window layout does not help though. Is the image thumbnail necessary? Could it be moved elsewhere? > > There are other things that could be improved in this dialog, btw: the general > > tab is unecessary as far as I can see. > > The tab is used when the image has metadata. In that case, other tabs appear. > But there is a point on that a more clean approach could be to hide the tab > label when there is no metadata. Agreed. > > So too are the next and previous buttons > > What's so bad about it? I think they are handy for users wanting to browse > through the images properties. What's bad about the next and previous buttons? They reproduce functionality that is already present in the interface. They don't indicate what is being browsed through, so they wont be intuitive to some people. > > and the white area in which information is displayed. > > This is a consecuence of using the notebook, I think. In usability terms, the problem with the white area is that it suggests editability. Aesthetically, it doesn't look great. > > I can provide a mockup of > > an alternative layout if required. (A sidebar might be a better approach than a > > standalone window, though.) > > Thanks, feel free to provide any mockups. Just in case, there is a plugin > already with a sidebar for relevant metadata, but the sidebar approach with > general image properties was dropped long time ago (around 5 years ago, during > the eog-ng rewrite, I would say). There might be a bug report about that > somewhere. I've had a look for that bug. Can't find it. What was the rationale behind removing the sidebar? It makes more sense to me than having properties in a separate window, since it makes the relationship between properties and the viewer window explicit, removes any possible need for an image thumbnail, etc.
(In reply to comment #2) > (In reply to comment #1) > > > > > > The file path usually cannot be seen in the properties dialog, since it gets > > > cut off. I have attached a screenshot to show you what I mean. > > > > It could instead be ellypsized in the middle if necessary. > > That's a possibility. It could be coupled with a copy button (to copy the text > of the file path). > > The first thing to do is to identify why people might need the file path in the > first place. The main reason that I can think of is that they do not have the > image's location open with Nautilus and want to perform some kind of operation > on it (copy, cut, open with an editor, etc). In this case the addition of an > 'Open image location' button could do the trick. The reason that this page exists is likely that the information it has was displayed in the old sidebar before. So, to preserve the information... > > > > A user is forced to resize the window in order to view the full file path, but > > > this operation will not be obvious to most people. > > > > I think it is a compromise between making the window arbitrarily big, adding a > > scrolled view, and keeping the window at a reasonable size and without unnedded > > complexity. > > Sure. The current window layout does not help though. Is the image thumbnail > necessary? Could it be moved elsewhere? The dialog generally has a problem with its size(width to be precise): bug 502023. Having the thumbnail there was likely a try to make the dialog look more like nautilus'. Then, if you have multiple eog windows with properties dialogs open, it helps to find the image you actually check the properties of. > > > There are other things that could be improved in this dialog, btw: the general > > > tab is unecessary as far as I can see. > > > > The tab is used when the image has metadata. In that case, other tabs appear. > > But there is a point on that a more clean approach could be to hide the tab > > label when there is no metadata. > > Agreed. Not sure how nice this would be from the terms of usability as it's quite a change if you switch images and suddenly not only the Metadata tab disappears but the tabs in general. But yeah, could be a solution. > > > > So too are the next and previous buttons > > > > What's so bad about it? I think they are handy for users wanting to browse > > through the images properties. > > What's bad about the next and previous buttons? They reproduce functionality > that is already present in the interface. They don't indicate what is being > browsed through, so they wont be intuitive to some people. > > > > and the white area in which information is displayed. > > > > This is a consecuence of using the notebook, I think. > > In usability terms, the problem with the white area is that it suggests > editability. Aesthetically, it doesn't look great. > The white background is determined by your GTK theme. Although we could override this, it's not really practical as the solution would be destined to look bad (if it's at all recognizable) if custom themes don't carry a specific override for eog. > > > I can provide a mockup of > > > an alternative layout if required. (A sidebar might be a better approach than a > > > standalone window, though.) > > > > Thanks, feel free to provide any mockups. Just in case, there is a plugin > > already with a sidebar for relevant metadata, but the sidebar approach with > > general image properties was dropped long time ago (around 5 years ago, during > > the eog-ng rewrite, I would say). There might be a bug report about that > > somewhere. > > I've had a look for that bug. Can't find it. What was the rationale behind > removing the sidebar? It makes more sense to me than having properties in a > separate window, since it makes the relationship between properties and the > viewer window explicit, removes any possible need for an image thumbnail, etc. I don't think there was a bug report for the dialog's inclusion. It was added during eog-ng development (2006/07) and IIRC the main reason behind it was to get more horizontal space for the image area in eog's default layout. Being a dialog it could have been moved to a different display while having the first display solely for the actual image (I think it might even work in fullscreen). Oh, yeah an there's bug 540686 asking for the "old" behavior.
Back to the original bug report: the file path in the properties dialog is typically too long. This makes it difficult to read it or to copy the text. One good solution could be the inclusion of an 'Open location...' button. This would open the file directory with Nautilus. From there a user can get the file path or do any other action which might have prompted the search for the file path.
A couple of other options for fixing this: * Make the file path that is currently used a button label. Clicking on the path opens the directory in Nautilus. * Replace the current 'Location' entry with a 'Folder' entry. Make the value a button, but just display the name of the file's directory as the label. I think the last option would be best: it is simplist, cleanest, and easiest to understand.
(In reply to comment #5) > * Replace the current 'Location' entry with a 'Folder' entry. Make the value a > button, but just display the name of the file's directory as the label. > > I think the last option would be best: it is simplist, cleanest, and easiest to > understand. Just did that :) Might not be perfect though as glade doesn't appear to be up-to-date with GtkGrid development. commit 81acc92c57f6713b4fb494c0c789ac3ec17adaed Author: Felix Riemann <> Date: Mon Oct 3 23:01:50 2011 +0200 Make the URI-label in the properties dialog a button showing the folder This should avoid the label being cut-off while still being informative enough. Clicking the button opens the folder in the file manager. https://bugzilla.gnome.org/show_bug.cgi?id=614869 This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.