On Thu, Jul 31, 2003 at 01:25:27PM +0000, Angus Leeming spake thusly: > > Martin Vermeer wrote: > > > Attached. > > > > New: > > - open/close selected/deselected branches on FormDocument exit > > - clean in-document format for branch definitions > > - branchlist editor cleaned up a bit > > - branch colours not yet implemented (more discussion required; > > Pref-definable, how?) but infrastructure is ready > > > > ...for your benevolent consideration. > > > > - Martin > > It's looking good IMO. > > 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.)
> +class InsetBranchMailer : public MailInset {
> +public:
> + ///
> + InsetBranchMailer(string const & name, InsetBranch & inset);
...
> I vote that this thing just goes in...
Hmmm, we have a bit special kind of democracy here...
> 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.
*) 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.
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.
> --
> Angus
Martin
--
Martin Vermeer [EMAIL PROTECTED]
Helsinki University of Technology
Dept. of Surveying, Inst. of Geodesy
P.O. Box 1200, FIN-02015 HUT, Finland
:wq
pgp00000.pgp
Description: PGP signature
