SystemConfig/CommonBugs

Common bugs

Child windows centering

Child dialogs should be centered on parent window, not on screen/main application window.

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

"OK" button is sensitive even no changes were done but it should be insensitive when there is "Cancel" button available.

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

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

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

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:

1. 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:

1. 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...