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

[Brian Kirsch]

Hi Bryan,
See comments in-line.

-Brian

On Dec 7, 2007, at 3:19 PM, 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.

I think this makes sense given the difficulty the resizing is causing.

>
> 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.

I think a larger size may be all that is needed for now. Let's see  
what feedback we get as more localizations are contributed before  
addressing this issue further.


>
> ...Bryan
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev