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

[Philippe Bossut]

+1 in punting this: would be great to have if it were cheap, but it's a 
typical case where the work is expanding beyond the original intent.

BTW, for localizers, I used all the abbreviations I saw iCalendar uses 
in its own Detail View to polish Chandler... Saved me lots of time (and 
sizing headaches...).

Cheers,
- Philippe

Bryan Stearns wrote:
> 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
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev