Re: Some ideas about GogStyle

[Jody Goldberg <jody gnome org>]

Apologies for the delay, conference season interrupted,  and this
required some thought.

On Wed, Jul 02, 2003 at 09:57:07AM +0200, Jean Brefort wrote:
> - I think that flags should remain in the structure and that we should
> use them to decide what to put in the style editor. There is no interest
> to have a font dialog for a background.

Now that I've had time to consider this I disagree.  The selection
of which fields to display in the editor is handled at the
GogObject::editor level, not in the style itself.  What we really
need is a solid notion of what set of fields can be auto, and which
are tied together.

eg for lines it makes sense to have the colour, and the (weight, style)
as two distinct auto-able elements

> So we should also split the  glade file to several files for outline,
> fill, markers, and possibly font and display only what is needed,
> depending on the flags.
Dunno if we need different glade files, but I basicly agree with the
concept.  That is why the editor creation routine takes a set of
flags, they are intended to indicate which elements are editable.

> - About GOG_FILL_STYLE_NONE, it is not absolutely necessary as I already
> wrote, but it might be more efficient that a transparent solid color.
> So, we can keep it or not.
I'd like to go the other way on this one.  We remove the
GogStyle::flags, and use NONE in some places.  Remember that just
because a field is filled does not mean it has to be used.  For
example, in the line plot, drawing a line with a style that has a
fill specified does not fill anything.  Only the line parameters are
used.  This greatly simplifies the theme code for now.

> - I suggest only one is_auto field in the fill part of GogStyle. Having
> one for solid color, another for patterns, and so on,  is not sensible
> as only one can be defined in the union.
I'm mostly in agreement, but by the same token we want to support a
theme that does gradient fills of bars/cols.  Ms XL seems to have
the same sort of semantic conundrum with lines.  They have 'auto,
none, custom' then for custom they allow colour == auto.  As far as
I can tell if you manually select the auto colour they forget that
it was manually selected and revert to auto.  We'll probably have to
play with this.

> - The line part of the structure does not seem necessary, as it has
> exactly the same fields as outline. It would be better to have a new
> flag value such as GOG_STYLE_LINE.
Lets keep it for now.  As long as the theming engine is assigning
series styles based purely on index, with no knowledge of plot type
it is useful to allow a style with
    fill solid, color = %d
    outline = black hairline
    line = 2pt, color = %d

If this is too cumbersome we revisit the decision and start passing
in more info to the theme engine.

> - We might need a font structure, the question is whether we should have
> only simple text or rich text. In the last case, we should store the
> style in the text itself using some sort of markup (probably pango
> markup). I prefer rich text even if it is more difficult to implement
> because labels might contain subscripts or superscripts (and it is a
> feature existing in Excel).

We definitely need font information.  There are even some widgets in
Gnumeric that should move down to handle the basic font selection.
Indeed we'll probably want to pull out more of the Gnumeric cell
format dialog to get support for underlines and the like.  Rich text
is a larger question.  It would be nice to import it from XL in
spots but the framework to support it isn't really there yet.
Remember that all data comes from Gnumeric, which does not have rich
text.  There is also no interface from pango -> gnome-print right
now.  So I'd suggest holding off on this until later.