← Back to team overview

kicad-developers team mailing list archive

Re: RFC: Arbitrary color support

 

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.

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


Follow ups

References