input fields in object properties dalog not aligned

[dopelover]

I see strong effort to clean up and improve interface of Inkscape. This is my little contribution.
I noticed that input fields in object properties dialog are not aligned properly (have different widiths?).
See attached screenshot.

[su_v (suv-lp)]

Proposed patch which makes all three entry fields align to the same right column.

[su_v (suv-lp)]

Screenshot of patched version (r11668+patch) on OS X 10.7.4

[su_v (suv-lp)]

About the patch:
The diff only fixes the most obvious "typo" - a leftover from the conversion of the old floating dialog to the dockable one (the layout had been slightly changed: the 'Set' button did get moved to the bottom row).

AFAICT the third column of the 'TopTable' table could be removed altogether, but I had troubles getting the 'Description' text field aligned properly while reducing the larger than needed padding at the right side of the table (at the moment, the padding mostly seems to result from column spacings set for 'TopTable').

Maybe I'll make another attempt to make it match closer to the table layout from 'objects-attributes.{cpp,h}, but I'm afraid that's likely way beyond what I can do without C++ and more detailed GTK+ skills.

[Kris (kris-degussem)]

Improved patch which should solve the markup issues.

[su_v (suv-lp)]

@Kris - alignment of the entry fields looks fine to me in your patch.

<nitpicking>
The only thing I'd probably try to change back to the prior status is to keep the label 'Description:' and the top of the description text entry fixed right below the ID/Label/Title fields, and expand the text entry box itself if the dialog height increases (while the row with toggle/button still aligns to the bottom of the dialog).

The current version in the second patch looks odd a bit odd IMHO if the dialog is higher than minimally required: ID/Label/Title are aligned to the top, the description label, the description text entry and the toggle/button row below are aligned to the bottom of the dialog, with a (large) empty space in-between.
</nit-picking>

[Kris (kris-degussem)]

Oops. I do not play that much with the sliders ...
This patch should solve the UI issue with empty space.

[su_v (suv-lp)]

@Kris - r11715+1050938v3.patch looks ok to me (visually).
One tiny detail: based on other changes in the GUI in trunk, maybe 'Description' should be 'Description:', like the other labels…?

[Kris (kris-degussem)]

Added colon after description.
Committed patch in trunk revision 11722 (thanks suv for pointing me to the right solution).

[su_v (suv-lp)]

Reopening - AFAICT the committed patch contains changes which result in creating broken SVG code:

    <rect
       style="fill:#ff0000;stroke:#ffffff;stroke-width:0.25"
       id="rect9"
       width="200"
       height="200"
       x="100"
       y="100"
       onmouseover:="setAttribute('fill-opacity','1.0')"
       onmouseout:="setAttribute('fill-opacity',0.75)" />

The appended ':' in the names for SVG interactivity attributes do not comply with the SVG specification [1] and causes e.g. the mouseover commands to fail in the browser.

[1] <http://www.w3.org/TR/SVG11/script.html#GraphicsEvents>

[su_v (suv-lp)]

… or rather don't even load in the browser:

XML Parsing Error: not well-formed
Location: file:///tmp/drawing-r11725.svg
Line Number 61, Column 20: onmouseover:="setAttribute('fill-opacity', '1.0')"
-------------------^

[su_v (suv-lp)]

Attaching quick fix to produce valid SVG code again - a fix (code refactoring) to separate the labels used in the GUI from the actual attribute names (to be able to use ':' like for the 'static' labels) is way above my skills.

[su_v (suv-lp)]

Patch to partially revert r11722 committed in r11963.

[Kris (kris-degussem)]

Re comment 11-14: what if we do something like in this patch (= having a list for the labels shown in the GUI separate from the list of the object's attributes)?

PS: my setup is still broken so I could not check the patch (patch file was created from rev 11827)

[su_v (suv-lp)]

@Kris - sorry if I committed that patch too early without waiting for a reply.

Attaching a modified version of your latest patch against current trunk (r11963).

<opinion>personally, I'm not sure whether the ':' are really needed here - the atttribute names as labels don't conform to other aspects of the HIG applied to labels of entry fields elsewhere anyway.</opinion> The patch itself AFAICT works as intentioned.

[su_v (suv-lp)]

@Kris - please tell if you want me to commit that last diff (or whether I better wait until you can do it yourself once your bzr access is functional again).

[Kris (kris-degussem)]

Readded colons in revision 12049 (for a uniform UI)