← Back to team overview

kicad-developers team mailing list archive

Re: RFC: Arbitrary color support

 

On 2/7/2017 9:00 AM, Chris Pavlina wrote:
> On Tue, Feb 07, 2017 at 08:57:23AM -0500, Jon Evans wrote:
>> Hi Simon, JP,
>>
>> I understand the issue with the colors chosen for OR-mixing.  I thought a
>> good first step would be to set the framework for the future when that is
>> no longer relevant (i.e. when there is no legacy canvas anymore).  It can
>> be a "under the hood" change only in pcbnew, until the legacy canvas is
>> removed.
>>
>> BTW Chris, I also have some ideas for improving the visualization of very
>> busy (dense and high layer count) boards, I will play with them soon...
> 
> Nice! I look forward to that. Definitely an area we can improve on.

Since the schematic editor canvas doesn't support transparency, you
could make the colors anything you want.  In the board editor, the layer
managers handles colors for both legacy and gal canvases so I'm not sure
it makes sense until the legacy canvas is deprecated.

> 
>>
>> -Jon
>>
>> On Tue, Feb 7, 2017 at 6:32 AM, Chris Pavlina <pavlina.chris@xxxxxxxxx>
>> wrote:
>>
>>> Let people choose. Have the default colors be wxDC-friendly. Trust me,
>>> nobody is choosing to work with eight-layer boards in legacy.
>>>
>>> On Tue, Feb 07, 2017 at 09:01:10AM +0100, jp charras wrote:
>>>> Le 07/02/2017 à 06:31, Simon Wells a écrit :
>>>>> i thought this wasn't possible due to wxDC limitations
>>>>
>>>> Exactly, wxDC does not have a transparency feature to draw items.
>>>>
>>>> In this case, when you want to draw board layers with a transparency
>>> effect, the only one other way
>>>> to do that is to use logic combination between colors (for transparency:
>>> the OR operation.)
>>>>
>>>> In other to achieve a good result, you cannot use any color for layers.
>>>> You have to choose a set of colors which allows this good result.
>>>> (by adjusting the 32 bits binary values of each color to ensure a good
>>> result when 2 or more color
>>>> values are ORed)
>>>>
>>>> There are not a lot of suitable binary values.
>>>> In all cases the background must be black (when using OR or
>>> transparency).
>>>>
>>>> Note also Eeschema does not use currently transparency, and the choice
>>> of colors is not critical.
>>>>
>>>>>
>>>>> On 7 February 2017 at 17:00, Chris Pavlina <pavlina.chris@xxxxxxxxx>
>>> wrote:
>>>>>> I'm working on an eight-layer board and really can't wait for this to
>>>>>> hit pcbnew too. It's bloody impossible to tell layers apart with
>>> KiCad's
>>>>>> state-of-the-80s-art color system.
>>>>
>>>> I have made a few boards with 8 and one with 16 layers.
>>>> There is no perfect way to see all layers.
>>>>
>>>> I used Pcbnew and Altium (in a company which has a Altium license) to
>>> design a 8 layers board (2
>>>> very similar boards, one with Pcbnew, the other with Altium, because
>>> this company used Altium).
>>>>
>>>> Altium allows arbitrary colors and transparency, but a 8 layers board is
>>> not easy to manage.
>>>>
>>>> So do not expect allowing arbitrary colors and transparency will fix
>>> your problem.
>>>> (In the best case, it slightly helps).
>>>>
>>>>
>>>> Having said that, using a selected set of colors does not imply using
>>> EDA_COLOR_T in Kicad code.
>>>> wxColor can be used instead of.
>>>>
>>>> This is only the *color choice* in Pcbnew which is constrained in legacy
>>> canvas.
>>>>
>>>> EDA_COLOR_T comes from the fact the legacy graphic primitives where
>>> written for an other library,
>>>> not for wxWidgets.
>>>> (Kicad was started before wxWidgets exists)
>>>>
>>>>>>
>>>>>> On Mon, Feb 06, 2017 at 10:03:11PM -0500, 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.  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
>>>>>
>>>>
>>>>
>>>> --
>>>> Jean-Pierre CHARRAS
>>>>
>>>> _______________________________________________
>>>> 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
> 


Follow ups

References