Andre Poenitz wrote:
> 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...
No, you're right. That was the original motivation.
>> 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 know and agree. But really that is the point. All these various
'applications' are doing the same logical stuff in different ways at
the moment.
>> I imagine something like
>> int fontWidth(std::ostream & os) {
>> }
>
> 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()?
Yes!
std::ostringstream os;
os << font::setFamily(font::SERIF) << "Andre"
<< font::setFamily(font::SANS_SERIF) << "Ponitz";
> 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.
Ok, thanks. I did not understand that. However, before I stumbled
across the xalloc stuff I had a mental picture of a 'fontstream'.
Something like
class fontstream: public::basic_ostream<> {
private:
std::ostringstream data;
std::stack<position, Family> positionstack;
std::stack<position, Weight> weightstack;
};
Of course this would need lots of operator<< methods to either fill
the stringstream or add font info to the stacks (in the setFamily etc
version of ostream<<).
Now, this 'fontstream' would most certainly have the info I imagined
and could be subsequently iterated over by
int fontWidth(fontstream const &);
int paint(fontstream const &, Painter &);
void latex(std::ostream &, fontstream const &);
etc
> 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
I know and I started off this thread by saying that I was pissed off
that I had to do essentially the same thing twice, remember?
> 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.
You would in the way I describe above though...
> 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?
Have I answered this question with the above? I _really_ would like
the ability to mark-up text handled by the frontends and think that a
fully-fledged widget embedding one of our Painters would be excessive
in many instances...
--
Angus
