kicad-developers team mailing list archive

[Maciej Suminski <maciej.suminski@xxxxxxx>]

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
>>
>