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.sumin...@cern.ch> 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@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
