On Tue, Oct 21, 2003 at 10:04:44AM +0000, Angus Leeming wrote:
> My main point is that the metrics and draw routines repeat large
> blocks of code
Only in a few cases in which we could have a local helper function which
is called from both. Unless I miss the point completely...
> and that my separating the information from the way it
> is used we can only win.
>
> I agree that we need to operate on the resulting data and I openly
> admit that I haven't read enough to do that. Perhaps you can help
> fill in my knowledge gap?
I assume we are still talking about metrics/draw and not about output
formats. [For output it somehow would make much more sense...]
> I imagine something like
> int fontWidth(std::ostream & os) {
> int width = 0;
> std::ostream::iterator it = os.begin();
> std::ostream::iterator end = os.end();
> for (; it != end; ++it) {
> int const family = os.iword(setFamily::getAlloc())
> if (family == -1) {
> std::cout << "Family data not set\n";
> continue;
> }
> LyXFont font(family);
> width += (*it, font);
> }
> return width;
> }
I fail to see how this should work. At what point of time are you
actually writing to the ostream?
Is the stream already "filled" when passed to fontWidth()?
It seems you assume that the extra data somehow sticks to the position
in the stream where it is written. It does not work like that. This
extra data is "stream global data" which gets overwritten the second
time you write to it and it does not store a position or anything
similar.
Furthermore, I don't really see why it should be needed. We already have
a mechanism set up to pass data to metrics() _and_ draw(): The
MetricsBase structure. Which has a few advanteages:
1. It's there already and works.
2. It was specifically "designed" for this task of passing information
to metrics() and draw() [It's part of MetricsInfo and PainterInfo]
3. It already contains a "LyXFont"
4. .. and a few more items with more or less sensible names and thus..
5. .. has more decent access than 'word' sizes anonymous chunks
If you want to store record a certain width, try using the inset's
dim_.wid, or if you need something completely different, add a new
'fancy_width_' cache-variable to the inset, set it's value in metrics()
and use in in draw().
> But such a stream would also allow the frontends to implement their
> own mark-up. Ie, pass a stringstream to the dialog and get bold and
> italic mark up in the right places.
I am not sure why you need markup in some string. You won't get markup
_in_ the stream this way.
What problem are you trying to solve that's not solvable by locally
factoring out some common code from metrics() and draw() in a few fat
insets?
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
