On Tue, 12 Nov 2002, Edwin Leuven wrote:

> On Tue Nov 12, 2002 05:22, Allan Rae wrote:
> > The thing is the bullet tabs were always supposed to have the current
> > bullet "pushed" for whatever level you were setting (ie. the
> > pseudo-push-button was supposed to be indented but that never worked
> > because of limitations in the image map thingy.
>
> thing is the ui changed.

So now the appropriate bullet will be highlighted/pushed/whatever?
Hmmm... doesn't seem to be.

One other thing I wanted to have but never succeeded in getting to
work¹ was to have the four bullet depth buttons actually display the
appropriate bullet pixmap (ignoring rotations or resizes -- any custom
string would have gotten a "Custom" label instead of a pixmap)

¹ The best I got was a segfault and Alejandro had a go at fixing my
code but still got segfaults so we gave up and just labelled the
buttons instead.  The problem was writing something like what bitBlt()
does in QBrowseBox.

> > A string is stored however for those cases where a person decides to
> > customise the latex command -- such as wanting a rotated \ding{49}.
>
> I was wondering btw why you didn't store the bullet as a string in general.
> what's the advantage of storing it as a font/char combination?

It was generally simpler to figure out what additional packages needed
to be loaded and meant I didn't need to write a parser (or at least a
scanner that searched for a string match in the table of bullets).

It also kept a clear distinction between customised bullets (where the
text field has been edited) and a known bullet.  It also means that
the text in the text field is always correct -- it shows the size and
the bullet; if a user decides to edit the field then they are entirely
responsible for the result.  This way they can choose a basic form for
the string, say "\Large\(\star\)" and then decide to put it in a
\raisebox{} so it looks right to them giving
"\raisebox{-2pt}{\Large\(\star\)}".  Using your method they end up
writing "\raisebox{-2pt}{\(\star\)}" and have a \Large prepended.
This separation of some of the information looks confusing to me even
if it does give the same result in this case.

BTW, the two formats for writing bullets in lyx files are:

\bulletLaTeX 0
        "\Large\(\bullet\)"
\end_bullet

and

\bullet 0
        0
        8
        6
\end_bullet

It so happens the above two are equivalent it's just that the first
entry was hand editted.  In your case where you want to write strings
you can use the first format -- you'll just have to parse the size as
well.  After all if you want to write strings you must either have a
parser or a custom bullet string.  The second format (actually the
primary format) just shows:

        \bullet level
                panel   (0 = standard and so on)
                offset
                size    (standard latex sizes with 0 = \tiny)
        \end_bullet


Anyway, we all know I'm into bad UI but in this case I still think my
way is better.  Besides you have all the info you need to support both
existing formats.

> > Why couldn't you just request the string when the appropriate button
> > is pushed?  That is, use a Bullet as a lookup table.
>
> yes, perhaps I should store a Bullet for this but bulletEntry(int f, int c) is
> private which means that I first need to set the bullet and then get the
> text. not very nice imho.

Instead of having src/frontends/qt2/bulletstrings.[Ch] create a
singleton that is used by both frontends (removing the tables from
Bullet.[Ch]) and use that for lookup of strings.  Then such functions
as:

void BulletsModule::standard(int row, int col)
{
        le_->setText(bullets_standard[6*row + col]);
}

would look like:

void BulletsModule::standard(int row, int col)
{
        le_->setText(bullet_strings.get("standard", 6*row + col));
}

or similar and the Bullets.C code would also use that.

And while I'm at it I'd prefer to see:

void BulletsModule::standard(int row, int col)
{
        le_->setText(size_strings.get(size) +
                     bullet_strings.get("standard", 6*row + col));
}


> the pixmaps have got nothing to do with it.

I was thinking you might have been wanting to iterate through the
table to construct the name of the next pixmap to load into the
next button in the GUI -- but I see now you do this in a manner
similar to XForms frontend.

Allan. (ARRae)

Reply via email to