Common bug reports
These are bug reports templates for most common bugs.
* child windows centering (jr) * "OK" button sensitivity and controls sensitivity (jr) * windows/dialogs layout (jr) * frame borders * spacings * text alignment * descriptions (jr) * missing tooltips (rr) * missing help/convert to docbook (rr) * use standard about dialog (rr) * port to PolicyKit (rr) * inputs checking (rr) * be more verbose, status, progress bar (rr)
Child windows centering
Description of problem
Child dialogs should be centered on parent window, not on screen/main application window.
How reproducible
/*places*/
Steps to Reproduce
1. invoke some dialog (for example About dialog) 2. 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
Description of problem
"OK" button is sensitive even no changes were done but it should be insensitive when there is "Cancel" button available.
How reproducible
/*places*/
Steps to Reproduce
1. invoke some dialog 2. 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
Description of problem
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
1. 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
Description of problem
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
1. 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
Description of problem
How reproducible
Steps to Reproduce
Actual results
Expected results
Additional info
Missing tooltips
Description of problem
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
Description of problem
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
Description of problem
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
Description of problem
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
Description of problem
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
Description of problem
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...