On Thursday 31 July 2003 1:51 pm, Martin Vermeer wrote:
> > One small thing to ease your life: make 'name_' here a static member of
> > the class (add a line
> > string const InsetBranchMailer::name_ = "branch";
> > to insetbranch.C) and you will be able to remove that 'name' argument
> > from the InsetBranchMailer c-tor.
>
> Is that (the arg) a problem (except for having to carry it around)?
> Aren't statics frowned upon? (In general, perhaps not here.)
The name is used by the dialog code to identify the inset. It is important
that you don't introduce typos here, so type it once and be done with it.
> > As for colours. Why not give all new branches a default colour like so:
> >
> > static HSVColor default_branch_color(0.0, 1.0, 1.0);
> >
> > Each time a new branch is defined just increment the 'hue' by 10 or so:
> > default_branch_color.h += 10;
> > if (default_branch_color.h > 359.9) default_branch_color.h = 0.0;
>
> *)
>
> > Thereafter, add an "Alter" button to the dialog that just calls the new
> > colour picker I wrote last week. See FromPreferences to see how to use
> > it.
>
> That's a possibility. I also liked your proposal 'branch1, branch2, ...'
> if only we can keep those ugly names internal. If we put them in
> LColor they are redefinable through Prefs. Wouldn't that be good
> enough? The colour picker is a bit heavy artillery for this.
If you use the colour picker, you won't need to store the names in LColor at
all (I think). Save them in the lyx file as
branch <branch name>
color <RR>, <GG>, <BB>
> *) Actually we can manually record the output of this process into LColor!
>
> Also, note that the real "political" problem is not how we create and
> choose the colours (so you're too early with your proposal :), but what
> colour *names* we will allow to be stored in the document format, as
> pointed out by Jürgen. Once we make that choice, we'll have to support
> them; let's keep it simple.
Store the R,G,B triple...
> Personally I would be happy with a set of, say, 5-10 distinct
> Pref-configurable colours with hardwired colour names in LColor (I
> would prefer br_red, br_cyan etc; or alternatively plain red, cyan
> etc. mapped internally to your branch1, branch2, ... to make them
> configurable). You cannot actually usefully have more of them, I
> think, for *this* particular purpose.
shrug...
A
