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