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)

Plus, accept and undo/reset won't be in the object inspector to begin with. Tshead 17:38, 31 Mar 2006 (EST)

5. Saving space

Saving space is good, but we still don't want to go too far. The gui should still look normal. In Cubit, we saved some space by using a layout margin of 5 pixels and layout spacing of 4 pixels. I think the default is something like 11 and 6 for dialogs. That seems a bit big. We don't want to go too small either. There needs to be some space between the gui elements. Anyone have an idea for what spacing we use?

--Mark Richardson 17:24, 31 Mar 2006 (EST)