[Chandler-dev] Setting aside the detail-view relayout work

[Bryan Stearns]

BKirsch (and others),

I've hit a wall (actually, a series of walls) with the detail-view 
relayout work: accomplishing what I set out to do keeps leading me into 
more and more changes, and the original issue doesn't seem to be 
important enough to make the additional work worthwhile.

To recap: the original goal was to allow labels in the detail view to 
expand dynamically, to allow longer words to be used by translations, as 
well as to preserve alignment in English if a plugin added a longer 
label. This was bug 10133:
https://bugzilla.osafoundation.org/show_bug.cgi?id=10133

To accomplish this, I creating a custom wx sizer that owned layout of 
the detail view in both dimensions. I chose the sizer approach because 
"sizing time" seemed like the right time to address label width, and it 
allowed me to also fix several other issues that have been bugging me 
(and others, though to a lesser extent):

- we could let widgets assume their native size (instead of hardcoding 
their height to a size that looks good on Mac, ok on Windows, and sucky 
on Linux)
- we could now align baselines of text in controls and widgets (Mac's 
currently manually aligned, Windows is one pixel off, and Ubuntu is a 
few pixels off).
- we could control arrange of widgets without hard-coding their 
positions in persisted blocks (so all three platforms would look equally 
good), and without lots of extra "spacer blocks" that just add overhead.
- we could work toward true "expando" fields, that would wrap and grow 
vertically as the user entered more text in them.

To accomplish this, I changed the way detail views are declared (since 
layout information needs to be persisted differently). I got this 
generally working for the core detail view, but once I tried to update 
all the plugins' detail views, I found that some of my earlier 
assumptions didn't hold, and that in some cases, the plugins don't 
follow (what I thought were) the rules for how new items and detail 
views are added to Chandler.

Fixing that will take a lot more work, both on the plugins, on the 
sizer, and on the existing attribute editors (sizing behavior is 
distributed all over the place!), but I don't think now is the right 
time to figure those issues out, since the rearchitecture effort will 
obsolete all of this soon. Also, we've already shipped the localization 
release, and no one seems too upset about our inability to dynamically 
resize labels in the detail view.

So: I'm setting aside this work in favor of the other stuff that's 
piling up and prioritized for 1.0. It's possible that the sizer work 
will be useful in the rearchitected world - I'll be talking with Grant 
about this soon.

If the width of the labels really is a problem we need to deal with 
before the rearchitecture branch takes over, we could hard-code a larger 
size than we need now, or maybe find some other solution that doesn't 
try to fix the other issues.

...Bryan