Talk:Auto Generated Object Inspector Issues
Most of the changes Berk suggested were counter to the suggestions I made to Clint. Here's a breakdown of the reasons.
1. Array properties on one line
At some point, having the edit fields on the same line becomes too wide. There are properties with array lengths of 5 and 6. We could put in an arbitrary cut-off point. If there are more than 3, space them vertically. Doing so would not make a consistent gui.
Besides the width, there is a usability issue. Presenting the user with an array of edit fields forces them to look up what each input field is supposed to represent. Then, they have to remember what it was for the next time. If they forget, they have to look it up again. Even the current object inspector has this problem, since it labels the fields by array index. (Why do the labels start at zero instead of one?) This is why I wanted to add a label to the filter information in the xml. Then, center[0] could be labeled 'X' and so on. Placing the edit fields on the same row would make it difficult to label each field.
--Mark Richardson 16:34, 31 Mar 2006 (EST)
2. Sliders for int properties with a lower and upper bound
A slider is useful for setting the value relative to the min and max. A slider is not very precise though. At certain resolutions, the slider may not be able to set all possible values. For instance, if the slider's range is 1000 and it is displayed in 300 pixels. As a default, I think int properties with lower and upper bounds should be represented using a spin box. Then, either leave the use of a slider to the custom panel or as a per property setting in the gui.
--Mark Richardson 14:34, 31 Mar 2006 (EST)
- While we're on the subject of lower and upper bounds, I think it's useful to have those bounds represented, or at the very least accessible. If we can't spare the space for a lower and upper label, we can have the limits accessible in a 'help' balloon you get when you hover over the slider or entry (or whatever). This might be good to have for all properties anyway.
- --David 14:44, 31 March 2006 (EST)
3. Check boxes on the right side of the label
Putting the checkbox on the right is not normal. For easy adoption by users, the gui should behave like other applications as much as possible. For checkbox properties, the label should be set in the checkbox widget, which will put the label to the right of the text. (I haven't found any QStyle settings that might reverse them). There are cases when a checkbox can be by itself. I've seen that mostly in some sort of table/tree view where the setting the checkbox changes is the column label.
--Mark Richardson 14:34, 31 Mar 2006 (EST)
- Berk - In general, I think check boxes and radio buttons have their boxes/circles to the left. Then, they always line up, because spacing is based on the box/circle.
- --David 14:44, 31 March 2006 (EST)
4. Colored buttons?
The accept button should not change color. We should use enabled/disabled to indicate if the button can be pressed.
--Mark Richardson 16:34, 31 Mar 2006 (EST)
