On Tuesday 30 September 2008 12:32:41 Ales Hvezda wrote: > Hi Peter, > > [snip] > > > - "Overlay" screen colour map (what is this even used for?) > > Where do you see this color map?
Sorry, I meant "outline", not "overlay". From gschem-darkbg:
; In all of the color modes:
; the first string is the actual color name
; the second string is the outline color name <--- THIS ???
; the third string is the postscript color name
; and the final 3 integers are the RGB values for PNG image files
> > N.b. that the "colour override" feature would be disabled for the time
> > being. What was the original motivation behind this feature, anyway?
>
> End users would be able to override the color of all nets, pins,
> buses, but I suspect it is not used at all and can probably be removed.
> As long as there is a way of changing the color of these objects (nets,
> pins, buses; when loaded/saved), then the override feature can be removed.
Hrm. Not sure how easy this would be to implement with the current Scheme API.
With the TinyScheme API it'll be something along the lines of:
(define (override-net-color coloridx)
(map (lambda (x) (set-color x coloridx))
(filter geda-net? (page-objects (current-page)))))
> >Feedback appreciated.
>
> Seems reasonable. A couple of things that I would like preserved
> from the existing colormap mechanisms:
>
> - Setup of the color maps should still happen in the gschem-darkbg
> or gschem-lightbg scheme files. Unless there really is a good
> reason to move them elsewhere.
Yep. There'll also be a B&W "builtin" colour map used if for some reason the
Scheme files can't be loaded.
> - The whole mechansim with the index of the color being stored in
> the individual object definitions (in sch/sym files). I don't
> see how we could change this without breaking everybody.
This won't change.
> - The mapping of index to what the color is used for cannot be
> changed. I.e. Color index 6 has to stay as logic bubble color.
> I'm okay with disallowing the end user to change this mapping
> (as you can today; but that's just silly as doing so would
> break things).
Yes, the indices will stay the same, but the end user won't be able to modify
them (that always seemed to be a misfeature to me).
> - Ability to understand the color index mapping. Somehow the
> end user should be able to figure out that color index 4 is the
> net color or that 5 is the attribute attached color. If this
> is just a comment in the *bg files, I'm okay with that too.
So a full (dark) colour map might look like (from Scheme's point of view):
'((0 "#000000")
(1 "#ffffff")
(2 "#ff0000")
(3 "#00ff00")
(4 "#0000ff")
(5 "#ffff00")
(6 "#00ffff")
... )
But users could also use symbols as aliases for the numerical offsets (and
yes, there would be functions to convert between the two):
'((background "#000000")
(pin "#ffffff")
(net-endpoint "#ff0000")
(graphic "#00ff00")
(net "#0000ff")
(attribute "#ffff00")
(logic-bubble "#00ffff")
... )
The config files would of course use the symbolic method rather than the
numerical one.
> - It's "color" not "colour" <g> :->
The code will use "color", don't worry. But writing prose in "American" messes
my brain up. :-P
Peter
--
Peter Brett
Electronic Systems Engineer
Integral Informatics Ltd
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
