GNOME Bugzilla – Bug 342682
too much information in 'features' dialog
Last modified: 2014-02-19 17:55:56 UTC
There is too much information in this dialog at first sight. Maybe you could use alternating colours for the lines (filesystems) or smaller icons. Other information:
hmmz, i even planned on adding more data ;) stuff like: - support through GParted, LibParted or External tools - and in case of External Tools, the webpage of this tool. Apart from alternating rows, do you have any ideas on how to display all this info effectively?
ok, i've added alternating colours. Please let me know if you have any more ideas...
Not sure if I agree with the submitter, I think perhaps a better option than the ticks might be coloured or shaded squares for each feature/filesystem type. That sounds like it might introduce an accessibility issue for colour-blind people though, hmmm. Perhaps a combination of the colour changes, smaller icons and remove the crosses, just leaving ticks.
Created attachment 122690 [details] Picture of File System Suport dialog with Legend closed As noted by Plors in comment #2, alternating colours have been added to the rows. Further changes to align with the GNOME Human Interface Guidelines v2.2, specifically to "Keep it Simple and Pretty", are as follows: - Moved menu "Gparted->Show Features" to "View->File System Support" (Better location) - Changed title Features to File System Support (more descriptive) - Renamed button Refresh to Rescan Support (more descriptive - Created expander for legend and added narrative (progressive disclosure) - Removed columns detect and read (limited value to user) The attachment contains a picture of the enhanced dialog.
Closing this bug.
Created attachment 136326 [details] file-system-support_legend_modified
In think it has improved. But, in my humble opinion, I think there's room for some more improvements. 1. The colours of the icons for 'avialable' and 'not available' draw the same amount of attention. Because of this it is hard to get the information I want. By changing the colour of one of the icons to a colour that attracts less attention, the information one wants is easier to get. 2. Adding categories to distinguish between different operations that are possible. For example one can group the operations grow and shrink, and move and copy. Please see the attached picture in comment #6.
One suggestion I had for improving the File System Support dialog comes from bug #695396 comment #15. Specifically: <snip> With <Patrick Verner's> recent patch, the number of file systems supported is increasing. One challenge introduced by this increase is that the "View --> File System Support" dialog window is becoming quite long. This can cause a problem with smaller displays (e.g., 800x600). Perhaps you might want to investigate enhancing this window to be resizable with scrollbars? <snip>
Created attachment 255661 [details] [review] Scroll features dialog (Draft 1) Hi Curtis, Here's a DRAFT patch for evaluation. Quoting the commit message: DRAFT: Make file system support dialog scroll (#342682) Make the list of file systems in the File System Support dialog scrollable and ensure the maximum height of the dialog is less that 600 pixels. With my window decoration and font sizing, the dialog is 504 pixels height with the legend hidden and 584 pixels height with the legend expanded. The dialog remains non-resizable. If this is an acceptable solution I will trim the commit message and submit. I attempted to make it resizeable with this change: diff --git a/src/DialogFeatures.cc b/src/DialogFeatures.cc index afcd12b..79d31ad 100644 --- a/src/DialogFeatures.cc +++ b/src/DialogFeatures.cc @@ -27,7 +27,6 @@ DialogFeatures::DialogFeatures() { set_title( _("File System Support") ) ; set_has_separator( false ) ; - set_resizable( false ) ; //treeview liststore_filesystems = Gtk::ListStore::create( treeview_filesystems_columns ); But this leads to undesirable UI behaviour. When the dialog is larger than the minimum height expanding and contracting the legend takes and returns space from the scrollable list, rather than growing and shrinking the overall height of the dialog, and thus moves the expander control from under the mouse. Nasty. Unfortunately my Gtk Widget programming knowledge isn't up to solving this. N.B. This draft patch doesn't interfere with Phillip's changes in Bug 694622 - Add support for online resize. Thanks, Mike
Hi Mike, Thanks for this patch. It works well on my system, but does exhibit the expander behaviour you mentioned. I do not claim to be an expert on gtkmm either. :-) I suspect that there is a way to implement the original behaviour, perhaps with a dedicated vbox for the expander, but in my tinkering I have not discovered a solution. I think one viable option would be to remove the expander widget and keep the legend visible at all times. This might be a good path to take since we are considering adding a multi-indicator for both/online/offline/not supported. Hence it might be advantageous to always have the legend visible. What are you thoughts on removing the expander for the legend? Curtis
I think that GTKMM 3.2 might provide the feature we are seeking to change the expander behaviour. void Gtk::Expander::set_resize_toplevel(bool resize_toplevel = true) Sets whether the expander will resize the toplevel widget containing the expander upon resizing and collpasing. https://developer.gnome.org/gtkmm/stable/classGtk_1_1Expander.html#ad957b5d73c8d73f4b003b7a8d7b229b5 Unfortunately this is not available in GTKMM 2.4 and I am questioning the value of coding a complex solution in GTKMM 2.4 to implement similar behaviour.
Hi Curtis, So the options are either: 1) fixed size dialog with expanding legend, or 2) resizing dialog with always shown legend. If the legend stays the same size it would be an even toss between these two options. If we do expect to add 2 or 4 more icons and labels to the legend it is likely to get significantly larger. In such a case I would prefer option (1). To be sure I think we should finalise the UI changes for bug 694622 and then we can evaluate this again. Then I will probably also implement option (2) and test them both to see what I like best. Thanks, Mike
Hi Mike, (In reply to comment #12) > To be sure I think we should finalise the UI changes for bug 694622 and > then we can evaluate this again. Agreed. We can decide on the best approach after the patches for bug 694622 are landed. Curtis
Created attachment 261361 [details] [review] Scroll features dialog (Draft 2) Hi Curtis, Here's the code to evaluate which of the 2 options for changes to the File System Support dialog we want to make: 1) fixed size dialog with expanding legend, 2) resizing dialog with always shown legend. Apply all the patches in a test branch to get option (2); cherry-pick just the last patch into another test branch to get option (1). Please test and let me know which you prefer. On the small 1024x600 screen on my netbook I prefer option (1), but on a larger screen there doesn't seem much to choose between them. Thanks, Mike
Hi Mike, Thanks for creating the patch set in comment 14 and indicating how to test the two types of File System Support dialogs. While both options 1 and 2 work, I prefer option 2 because on a large screen it permits me to expand the dialog so that all file systems supported and the legend are viewable at once. This is handy for making a screenshot with all file systems. Out of curiousity, what led you to choose 8 pixels as the spacing versus the 12 pixels specified in the Gnome HIG? I believe we have room to grow the File System Support dialog wider without exceeding our 800x600 smallest target screen resolution. Curtis
Hi Curtis, I'll tidy up the patchset and implement option (2) resizing dialog with always shown legend. On the question of choosing 8 pixels versus 12 specified in the HIG? GNOME HIG 2.2.1 / Visual Design / Window Layout. https://developer.gnome.org/hig-book/stable/design-window.html.en In section 8.2.3 Spacing and Alignment one of the guidelines is: * Indent group members 12 pixels to denote hierarchy and association. but in Figure 8-4 Layout specification the picture shows 12 pixel indent from window edge to section header but less from section header to dependant labels. So the HIG is inconsistent. GParted only seems to use 10 pixel indent from window edge to first widget, not just in the File System Support dialog but other places to. So I chose 8 pixels to look right given what GParted already does and match what Figure 8-4 Layout specification looks like. Thanks, Mike
Hi Mike, Thank you for the detailed explanation. I was just curious. So even the HIG contains inconsistencies. Imagine that. ;-) I trust your judgement. Curtis
Created attachment 266585 [details] [review] Scroll features dialog (v1) Hi Curtis, Finally tidied up the code for patch set v1. Kept the small changes in the UI code as it's still newish to me. I would like to prevent the Features dialog being 1) resized wider, and 2) taller than the scroll bar disappearing, but I don't know how to do it. Tested on CentOS 5.10, Debian 6, Fedora 19. On Fedora 19 (Gtk3) the dialog doesn't want to be resized passed about plus 20% from default. Thanks, Mike
Hi Curtis, I have done some more testing and found that on Kubuntu 12.04 LTS (KDE Desktop) the "Legend" text in the frame above the legend is displayed in the centre, where as on every GNOME desktop it is always on the left. I tried using get_label_Align() to report the alignment and it reported X alignment of 0.0 (left). I suspect that the gtk2-oxygen theme included in Kubuntu 12.04 LTS is overriding the alignment to centre and we shouldn't try to do anything about it. See call setting centre x alignment in the source of gtk2-engines-oxygen package, version 1.2.2-0ubuntu1.1: 337 // modify alignment 338 gtk_frame_set_label_align( frame, 0.5, 0.0 ); http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/gtk2-engines-oxygen/precise/view/head:/src/animations/oxygenanimations.cpp#L338 Thanks, Mike
Created attachment 266673 [details] Kubuntu 12.04 LTS screen shot of Features dialog differences Hi Curtis, I've now 100% confirmed that on Kubuntu 12.04 LTS that the gtk2-engines-oxygen package causes the legend text to appear in the middle. In fact the theme changes a lot of how the widgets are rendered including: icons, fonts sizes and lots of other details. Here's a screen shot of the difference. On the left GParted was started while gtk2-engines-oxygen package was installed, and on the right GParted was started after the theme package had been removed. Looks significantly different. Thanks, Mike
Hi Mike, Thank you for your work on this report, including the patch set in comment #18, the testing results, and screen shots. In my testing on Kubuntu 12.04 LTS I confirmed your finding that the "Legend" text is centered instead of placed on the left. OpenSUSE 12.2 (with KDE) has the same behaviour. This isn't a show stopper for me, but I will investigate further. I also confirmed your finding on Fedora 19 that the dialog resists resizing, and will grow at most 10-20%. This is really strange. Testing with Debian 7 Wheezy and Debian 8 Jessie yield the expected behaviour with "Legend" on the left, the dialog able to resize to the size of the screen, and the list of file systems scrollable. With Fedora 20, I am experiencing a segmentation fault when I choose "View -> File System Support". If you have a chance, please try testing on Fedora 20. In the meantime I will spend some time coming up to speed with graphics again with an eye to more closely reviewing this patch set. Curtis
Hi Mike, I was going to grab a stack trace of the segmentation fault with Fedora 20, but an interesting thing has occurred. When I turn on debugging and install the debug libraries, the segmentation fault no longer occurs. For debugging I did the following: As root install debug libraries with # debuginfo-install gtkmm24-2.24.4-2.fc20 As normal user compile with debugging symbols and no optimization with: $ export CXXFLAGS="-g -O0" # That's minus g minus Oh zero $ ./configure && make As root I ran src/gpartedbin and selected "View -> File System Support" and the segmentation fault did not occur. Strange... To test if this is related to optimization, I performed the following steps: $ make clean $ export CXXFLAGS="-g" $ ./configure && make On re-testing, no segmentation fault. To test the original crash situation I performed the following: $ make clean $ unset CXXFLAGS $ ./configure && make Upon running src/gpartedbin and selecting "View -> File System Support" I discovered that the original segmentation fault was now gone! Based on this I think that installing the debug libraries must have updated some package that previously contained an error. I am curious as to whether you are able to reproduce the segmentation fault. Curtis
Hi Curtis, Thanks for testing on more distros. I'm installing a Fedora 20 VM now (64-bit, GNOME desktop) and I'll see if I can generate a crash. By the way this command will list all the packages installed, most recent first, so you can see what debuginfo-install actually installed and consider uninstalling or downgrading them to retest. rpm -qa --queryformat '%{INSTALLTIME} %{INSTALLTIME:date} %{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' | sort -rn | less Mike
I've install Fedora 20 now and built GParted GIT head with my patch "Scroll features dialog (v1)" from comment #18 applied. Didn't get a crash. Found the same behaviour of limited ability to resize the dialog. Amount of resizing depends on the size of the main GParted window. Maximise the GParted main window, then open and resize the File System Support dialog. It can be resize much more. Make the main window much smaller than default; the dialog can't be resized at all. Guessing, I would think that GNOME Shell is trying limiting the maximum area of dialogs based on the area of the main window.
Hi Mike, Thanks for the rpm command info. I'm not overly concerned about recreating the segmentation fault by going back to older versions of packages. I don't think there is much value to be gained by that effort. The key thing is that with more up-to-date packages on Fedora 20, GParted does not crash. Regarding your theory on GNOME Shell, I think you are onto something there. The bigger I make the GParted main window, the larger I can resize the features dialog. It seems that something behind the scenes is trying to ensure that dialog windows are no larger than the main window. In reviewing the patch set I found one minor typo in 3 of 5. "loosing" should be "losing" Overall I believe that this patch set is an improvement on the previous behaviour, especially because it is now completely viewable on a small 800x600 screen. If I do not see any notes to the contrary, then I will make the comment change and commit this to the gnome git repository master branch mid-week. Curtis
Since we are fortunate to have Larry able to help us with testing. I have asked Larry to test the patch set in comment #18 and Larry has agreed. The key improvements added by this patch set are: 1) The file system support (also known as features) dialog will display properly on devices with screens as small as 800x600 2) The file system list is scrollable 3) The dialog is resizable I will hold off on committing this patch set until Larry has had a chance to finish testing. Curtis
Created attachment 266927 [details] window popup too low Dear you all, Here is my testing patch v1. Distro : centos 6.5, fedora 18, fedora 19, fedora 20, debian 7.2, ubuntu 13.10, mint 16, opensuse 13.1 archi : x86 resolutions : 800x600 & 1360x768 operations : scrolling, resizing, closing, updating fs support centos 6.5 800x600 : the FS windows popup a bit too low, so one cant close the window without moving it to the top, otherwise close button is out of the desktop (see screenshot : too_low.jpg) 1360x768 : resizing is OKAY ! fedora 18 800x600 : the only way to resize the windows is to take the bottom right corner and move it : nothing else works to resize the window. 1360x768 : if the FS windows is close to one side, one cant increase the size. To increase the size, one needs to move the GParted windows exactly in the middle of the Desktop. This come from the fact that all sides need to change in the same time. fedora 19 same as 18 except with 1360x768 resolution, when moving the gparted window to the top left, display become weird (see screenshot : display_weird.jpg) fedora 20 same as 18 debian 7.2 800x600 : the FS windows popup a bit to low, so one cant close the windows without moving it to the top, close button is out of the desktop (see screenshot : too_low.jpg) 1360x768 : resizing is OKAY ! ubuntu 13.10 800x600 & 1360x768 : both works very well mint 16 800x600 & 1360x768 : both works very well opensuse 13.1 same as fedora 18
Created attachment 266928 [details] display weird This is the second screenshot about fedora 19. (I dont know if there is a way to add more than one screenshot in the same reply). Hope this help. Larry
Hi Larry, Thank you for your extra testing. CentOS 6 - You've written the same text as for Debian 7. When I tested CentOS 6 at 800x600 with top and bottom panels I found that the File System Support dialog opens just fitting between panels with a one or two pixels to space. Debian 7 - screen shot "window popup too low" from comment #27 - I haven't tried Debian 7 myself, but what I think is happening is because of the modal behaviour of dialogs under GNOME Shell. Dialogs are fixed to the parent window with just the title bar showing. At 800x600 the bottom of the screen has pushed the dialog up a bit, but the very bottom is behind the bottom panel. Optional fix: Make the dialog ~20 pixels shorter so it fits with the wanted positioning. The GNOME Shell, The modal windows behavior http://gnomeshell.wordpress.com/2011/09/10/the-modal-windows-behavior/ Fedora 19 - screen shot "display weird" from comment #28 - I haven't seen this exact behaviour where the dialog is made too narrow and the narrative and legend icons are displayed on top of each other, but GNOME Shell on Fedora seems to want to try to limit the size of the dialog to be no bigger than the main window behind it. I guess in your case it managed to force the dialog to be too narrow and that is how the widgets draw themselves. Setting a minimum width for the dialog may prevent this. Curtis and I discussed this above in comments: (In comment #18) > Tested on CentOS 5.10, Debian 6, Fedora 19. On Fedora 19 (Gtk3) the > dialog doesn't want to be resized passed about plus 20% from default. (In comment #21) > I also confirmed your finding on Fedora 19 that the dialog resists resizing, > and will grow at most 10-20%. This is really strange. (In comment #24) > Found the same behaviour of limited ability to resize the dialog. > Amount of resizing depends on the size of the main GParted window. > Maximise the GParted main window, then open and resize the File System > Support dialog. It can be resize much more. Make the main window much > smaller than default; the dialog can't be resized at all. > > Guessing, I would think that GNOME Shell is trying limiting the maximum > area of dialogs based on the area of the main window. Hi Curtis, Can you hold off committing at the moment and I'll try reducing the dialog height and setting a minimum width and see how it goes. Thanks, Mike
Hi Mike and Larry, I will hold off on committing this enhancement. Larry's testing has revealed a few other anomalies that would be nice to fix. Mike's suggestion of shortening the height by ~20 pixels sounds reasonable, and with the weird display Larry encountered we might need the other suggestion of a minimum width. Curtis
Hi, Finally managed to reproduce the weird display issue Larry found in the screen shot in comment #28 - with legend narrative and icons displaying on top of each other. Used Fedora 19 VM. Screen resolution doesn't seem to matter, produced with 1024x768 and 800x600. Steps: 1) Move the main GParted window to the top left of the screen; $ xwininfo | grep geom (Click on GParted main window) Default size: -geometry 775x500+-9+19 2) Resize the main window as small as possible; $ xwininfo | grep geom (Click on GParted main window) Minimum size: -geometry 327x231+-9+19 3) Open dialog with: View > File System Support; $ xwininfo | grep geom (Click on dialog) Default size: -geometry 711x500+-6+27 4) Resize dialog using a bottom corner to any size. GNOME Shell forces the dialog to be too small based on not wanting it larger than the main window. $ xwininfo | grep geom (Click on dialog) Fored size: -geometry 516x365+-6+27 GNOME Shell only does this when the GParted window has been resized a lot smaller than default, and only when the main window is at or near the top left hand corner of the screen. At the moment I consider this broken behaviour from GNOME Shell. Anyway I'll do some experiments with Gtk::Widget::set_size_request(), set_default_size(), set_geometry_hints() and see if anything can be done easily and compatibly within the bounds of gtkmm-2.4 API. Mike
I tried making the following changes in DialogFeatures::DialogFeatures() (beyond setting the overall height to 500 pixels) to try to prevent the legend narrative and icons displaying on top of each other: 1) Set minimum width request with: set_size_request(740, 500); 2) Set default width request with: set_size_request(-1, 500); set_default_size(740, -1); 3) Set geometry hint to set minimum and default size with: set_size_Request(-1, 500); Gdk::Geometry g = {740, 500, -1, -1, 740, 500}; set_geometry_hints(*this, g, Gdk::HINT_MIN_SIZE|Gdk::HINT_BASE_SIZE); They all end up setting the X11 window minimum size property, and in case (3) the base (a.k.a. desired) size too [1][2]. Yet none of them prevented the display issue under GNOME Shell. Still end up with the program setting the minimum size of the dialog window and GNOME Shell forcing it smaller in the unusual case. $ xprop | grep size (Click on overly shrunk dialog) program specified minimum size: 740 by 500 program specified base size: 740 by -282 $ xwininfo | grep geom (Click on overly shrunk dialog) -geometry 530x233+-6+27 GNOME Shell is just overriding the programmed size and I don't see that there is anything in the code I can do to stop it. Just don't (1) minimise GParted main window, (2) move it to the top left of the screen, and (3) try to resize the dialog. In my opinion it's a bug it GNOME Shell and as far as I can tell it can't be fixed in GParted. My only advice to the user is don't do it! Thanks, Mike [1] Xlib Manual, Chapter 14: Inter-Client Communication Functions, 14.1.7 Setting and Reading the WM_NORMAL_HINTS Property http://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-normal-hints.html [2] Inter-Client Communication Conventions Manual Version 2.0, 4.1.2.3. WM_NORMAL_HINTS Property http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.3
Created attachment 267240 [details] [review] Scroll features dialog (v2) Hi All, Here's patchset v2. The only user visible change is that the Features dialog is now a bit shorter, only 500 pixels high. The patchset itself has changed a bit more: 1) The tidyup DialogFeatures constructor patch has been moved to first place so that it was easier to understand the changes the other patches were making and when I was changing those commits I didn't have to keep fixing up the tidyup commit; 2) The indent legend narrative patch has been simplified from the previous 5 lines adding a padding hbox widget to just 1 line which sets the padding of the legend narrative widget when it is packed to achieve the same result; 3) The make the dialog resizable patch, sets the height of the dialog widget to the desired minimum height of the dialog, rather than setting the desired minimum of scroll widget some where within it. Makes it more direct to understand what setting the minimum height is actually about. Larry, Can you test this on Debian 7.2 to confirm the dialog now fits on the screen displayed in its default position, at least enough to see the Scan and Close buttons. Curtis, This is ready for committing subject to Larry's testing and your review. Thanks, Mike
(In reply to comment #33) > Created an attachment (id=267240) [details] [review] > Scroll features dialog (v2) > > Hi All, > > Here's patchset v2. The only user visible change is that the Features > dialog is now a bit shorter, only 500 pixels high. > (...) > Larry, > > Can you test this on Debian 7.2 to confirm the dialog now fits on the > screen displayed in its default position, at least enough to see the > Scan and Close buttons. > Hi Mike, I confirm the dialog does fit on the screen displayed. No problem to click the close botton. Good work :) Larry
Great work on this bug report guys! Thank you Larry for your testing efforts. Without your testing we would not be aware of some of the issues encountered with this patch set. Also thank you Mike for improving the understandability of the code while also improving the features dialog so that it will display correctly on screens as small as 800x600. The patch set in comment #33 has been committed to the Gnome repository for inclusion in the next release of GParted. The relevant git commits can be viewed at the following links: Enhance readability of the DialogFeatures constructor https://git.gnome.org/browse/gparted/commit/?id=dd9e2161d40af918e6e2f2ebcdaf4b970f314bfc Always show the File System Support dialog legend (#342682) https://git.gnome.org/browse/gparted/commit/?id=59f684d8cdc5ea77f63e44ff8c92977647da2df5 Indent File System Support legend narrative (#342682) https://git.gnome.org/browse/gparted/commit/?id=cb8ce9caea881648faef8378c4009b1262eaeb1d Make the File System Support dialog resizable (#342682) https://git.gnome.org/browse/gparted/commit/?id=6f9b99f13822aa6beedff301d398995271756ce5 Restore compilation order of source files https://git.gnome.org/browse/gparted/commit/?id=a70bfd32feddfc442bde216eaeaf24d773b27a55 Curtis
Created attachment 268325 [details] [review] Update docs to match new file system support dialog (v1) Hi Mike, While recently reading the GParted Manual I noticed that we forgot to update the help manual to reflect that the legend is now always displayed on the File System Support dialog. This patch set (for your review) includes updates to reflect the change in legend, updates to the copyright year, and the addition of a missing dependency for fedora. Thanks, Curtis
Hi Curtis, Reviewed docs update patchset v1 from comment #36. All looked good. I've pushed the following commits upstream to the GIT repository for inclusion in the next release of GParted: Update help manual to match file system support dialog (#342682) https://git.gnome.org/browse/gparted/commit/?id=4a85e3cd660c9c503b3ab308efa0c824c47a1103 Add gnome-common to fedora dependencies in README https://git.gnome.org/browse/gparted/commit/?id=93f7cb3f47cb26b954e809b58feb9f09e0fe2612 Update copyright year https://git.gnome.org/browse/gparted/commit/?id=203a345cfb3413cebbf5c9749e0734d7dd4a7128 Thanks, Mike
This enhancement was included in the GParted 0.18.0 release on February 19, 2014.