Common bugs
Child windows centering
Child dialogs should be centered on parent window, not on screen/main application window.
Steps to Reproduce:
- invoke some dialog (for example About dialog)
- check dialog centering
Actual results:
Dialogs centered on screen/main application window.
Expected results:
Dialogs centered on parent window.
Additional info:
This bug report is part of "System Configuration Tools Cleanup Project". Don't hesitate to ask project maintainers for any kind of help.
Controls sensitivity
"OK" button is sensitive even no changes were done but it should be insensitive when there is "Cancel" button available.
Steps to Reproduce:
- invoke some dialog
- check if "OK" button is sensitive
Actual results:
"OK" button is sensitive.
Expected results:
"OK" should not be sensitive.
Additional info:
This bug report is part of "System Configuration Tools Cleanup Project". Don't hesitate to ask project maintainers for any kind of help.
Layout - Frame border
Frames with a border around their perimeter have traditionally been used for denoting groups of related controls. This is advantageous because it physically seperates disimilar controls, and also avoids repitition of the frame's label in individual member control labels. Unfortunately, they add visual noise that can both make a window appear more complex than it really is, and reduce the ability to quickly scan window elements. Rather than using bordered frames, use frames without borders, bold labels to make the categories stand out, and indented contents. This, combined with good layout and spacing, is usually a better alternative to bordered.
Steps to Reproduce:
- invoke any dialog using frames
Actual results:
Frames with borders.
Expected results:
Frames without borders, using bold labels, spacing and indentation.
Additional info:
Look at GNOME Human Interface Guidelines 2.2 [1]
[1] http://library.gnome.org/devel/hig-book/stable/controls-frames.html.en
Layout - Spacings & layout
A clean, logical dialog layout helps the user to quickly understand what information is required from them. It's very important to have proper spacing between window borders, controls and separators (if used), controls alignment etc.
Steps to Reproduce:
- invoke any dialog
Actual results:
Incorrect controls spacing and alignment.
Expected results:
Correct window/dialog layout.
Additional info:
Look at GNOME Human Interface Guidelines 2.2 [1] [2] [3]
[1] http://library.gnome.org/devel/hig-book/stable/design-window.html.en
[2] http://library.gnome.org/devel/hig-book/stable/windows-dialog.html.en
[3] http://library.gnome.org/devel/hig-book/stable/windows-alert.html.en#alert-spacing
Descriptions
Every part of dialog window, which is not intuitive, should have description containing what is wanted from user
Steps to Reproduce:
Open any dialog.
Actual results:
Many widgets without any description.
Expected results:
Intuitive settings or nice description.
Additional info:
Missing tooltips
There should be tooltips on non-intuitive widgets. Especially toolbar buttons.
How reproducible:
Steps to Reproduce:
- Move mouse on top of the widget.
Actual results:
No tooltip appear.
Expected results:
Some explaining text should appear.
Additional info:
This can be easily done in .glade editor (if you use glade)
Missing help and/or convert to docbook
Every tool should have help in docbook format. And should be accessible via menu -> help
How reproducible:
Steps to Reproduce:
Actual results:
Missing help and/or not docbook format help
Expected results:
Additional info:
Use standard about dialog
Every tool should have standard gtk (glade) about dialog.
How reproducible:
Steps to Reproduce:
menu -> help -> about
Actual results:
Missing about dialog and/or bad format.
Expected results:
Standard format dialog like in system-config-firewall
Additional info:
About dialog can be easily created using GtkAboutDialog.
See http://www.pygtk.org/docs/pygtk/class-gtkaboutdialog.html
Port to PolicyKit
It's not a good approach to let system config tool run under superuser account - it's a security risk. Instead each tools which needs users privileges should be divided to two parts - one which serves as privileged backend running on demand and user interface that can ask for privileged action over message bus (and ask password if needed). Once action is approved by PolicyKit, it can be processed. Every tool should be ported to use PolicyKit.
How reproducible:
Steps to Reproduce:
Actual results:
Expected results:
Additional info:
Look at https://fedorahosted.org/python-slip/
Inputs checking
Every input should be tested and/or filtered.
How reproducible:
Steps to Reproduce:
- Do something nonsense. For example fill IP address field with "zywe"
Actual results:
Tool will not notify user, that he write it wrong.
Expected results:
In some cases you can filter input (appropriate settings on widget).
Notify user about his mistake and don't let tool to traceback.
Additional info:
You can set appropriate settings.
You can use signal changed and/or focus-out for text fields.
Be more verbose, status, progress bar
User is not notified that tool is something doing and/or something goes wrong.
How reproducible:
Steps to Reproduce:
Actual results:
Expected results:
Additional info:
Use status bar, progress bar and/or message dialogs...