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