Community
Participate
Working Groups
If you create attributes of different types and navigate between them in the tree viewer, the "use" field floats up and down. I recommend moving the "use" field under the "deprecated" field so it never moves (regardless of attribute type).
I have taken some artistic license with this bug and moved the default field up beside the use ComboBox. Removing the "Default Value:" label exposed a layout issue with the details pages. The size of the label column on the GridLayout for each page depends on the size of the largest label. This means that the alignment of the fields jumps all over the place as you select different attribute types or different schema object types. The problem is already visible between SchemaElementDetails and SchemaRootElementDetails without any changes. I came up with a way to make the alignment uniform, but it is not the prettiest code in the world. The fix is a bit of a hack. I think there are a number of different ways to go on this and I'm going to upload several alternative patches now.
Created attachment 74203 [details] set uniform size for elements and attributes only Does not set the size of compositor and reference detail label widths as these pages are significantly different.
Created attachment 74204 [details] set uniform size for all detail pages This one has a minor bug in which the compositor and reference labels are narrower than the rest for some reason (even though it's whole purpose was to set their size also). The patch should give a rough idea though.
Created attachment 74205 [details] set uniform size only for attribute detail pages This localizes the messy fix to one file and makes the problem as subtle as it was before.
Created attachment 74206 [details] move the field but do not use the hack This moves the default field beside the use field as with all the others but lets the details pages have whatever label size is calculated for them. The problem is most evident with this patch.
Created attachment 74207 [details] does not put the default field beside the use field This is the bare minimum to resolve this bug. Just moves the use and default fields above type as requested.
My favourites are the patch from comment 2 and from comment 4 in that order. ;)
I like the patch in comment 6. Putting the default text field without a label next to the combo box is too busy and a bit confusing on what the field is supposed to represent.
Created attachment 74213 [details] modified version of comment 2 patch I have one last secret weapon to not have my efforts be in vain. What do you think?
I had thought about that, but since 'default' is the least common option, most of the time we end up with a combo box that is inexplicably smaller than the one under it.
Created attachment 74215 [details] secret weapon #2 How about now?
Created attachment 74216 [details] secret weapon #2.1 Fixes a focus problem.
Created attachment 74217 [details] secret weapon #2.2 Fixes one edge case where the default value field is not shown even when default is selected.
I like it. I like it a lot. Can we replace the "(default)" text with "Enter default value"?
Created attachment 74220 [details] final version Changes the default text to "Enter default value".
After applying the patch for bug 196882, this patch does not apply cleanly any more.
Created attachment 74315 [details] synchronized patch
Released patch. Thanks Adam.