kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

Hi Orson,

I have started down the road of using COLOR4D as I think it's a better idea
than introducing so much woven dependency on wxWidgets.  But, I ran into a
concern that I thought I'd ask the devs about...

Since COLOR4D is part of libgal, if I want to use COLOR4D as part of the
color config system (which I do), that means adding libgal as a dependency
of (all of?) the binaries.  Or, I could hoist COLOR4D out of GAL into
common.

Any preferences as to how to approach that?

Wayne -- I will do some tests on "auto-picking" legacy colors and see how
good/bad it looks.

Thanks,
Jon

On Tue, Feb 7, 2017 at 4:34 PM, Maciej Suminski <maciej.suminski@xxxxxxx>
wrote:

> Hi Jon,
>
> On 02/07/2017 04:03 AM, Jon Evans wrote:
> > Hi all,
> >
> > I started working on the idea of a color theme system for KiCad, starting
> > with the schematic editor.
> >
> > This change relies on a complete removal of EDA_COLOR_T from the code,
> and
> > replacement with a color structure that can handle arbitrary colors.
>
> Have at look at COLOR4D (include/gal/color4d.h), it may be a good
> starting point. It has a constructor taking wxColour as the argument, if
> you prefer wx classes.
>
> GAL should be capable of using any color you like (see e.g.
> PCB_RENDER_SETTINGS in pcbnew/painter.cpp. The only problem is the color
> picker, and as you have already noticed, resolving the new colors in the
> legacy canvas. IMHO resorting to the closest 'safe' color is the best
> option.
>
> Your work-in-progress screenshots look very neat. I would love to see
> the final version.
>
> Regards,
> Orson
>
> > I
> > think this is important and the right path for the future, but since
> it's a
> > significant change, I wanted to get buy-in before going any farther down
> > this road.  I can understand the reasons for using an enum for
> > color--especially since it lets the developers restrict the colors to
> those
> > that will work well with the drawing technique of the legacy canvases.
> > But, since the new canvases will have no problem supporting arbitrary
> > colors, I think it makes sense to start setting up the groundwork for
> that.
> >
> > In my test code, I have replaced EDA_COLOR_T with wxColour, since that is
> > used internally in a few places already, and it was pretty simple
> (although
> > somewhat time-consuming) to replace all usages.  wxColour has the nice
> > property of serializing/deserializing from hex color codes like "#80FC62"
> > so that's what I use for storing in the settings for now (eventually I
> > think color settings should be in their own files so that they can be
> > traded by users).  Plus, there is a canned wxColourPicker widget that I
> can
> > use in place of the custom color picker buttons that are used in the
> > settings today.
> >
> > You can see some screenshots of the (work-in-progress) settings dialog
> > changes, and an example of a custom color theme in the schematic editor,
> > here:
> > http://imgur.com/a/MxMmb
> >
> > So, any feedback from the core team?  Any reason why I shouldn't move
> > forward with preparing a patch to move from EDA_COLOR_T to wxColour
> across
> > the board?
> >
> > Best,
> > Jon
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>