← Back to team overview

kicad-developers team mailing list archive

Re: RFC: Arbitrary color support

 

OK, sounds good.  That's the way it's implemented now on my branch.

On Fri, Feb 10, 2017 at 2:35 AM, Maciej Suminski <maciej.suminski@xxxxxxx>
wrote:

> Hi Jon,
>
> Normally, when you use external libraries, you would simply link every
> library you need, even if only a single class/function is needed. I
> would prefer to keep libgal decoupled from everything else, so my
> preference would be to link other apps with libgal instead of migrating
> parts of it to libcommon.
>
> Regards,
> Orson
>
> On 02/09/2017 04:07 PM, Jon Evans wrote:
> > 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
> >>
> >
>
> _______________________________________________
> 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
>

References