Hi James, Thanks so much for all your hard work! The commit touched a lot of files, there is no way I could have figured all that out in a day so I'm delighted you were interested to do this.
I will grab a copy of the nightly build :) Regards, Daniel On Monday, August 12, 2024 at 9:44:52 PM UTC+1 [email protected] wrote: > Daniel, > > Now committed to the v9 branch, so will be available in nightly builds > soon. If you're interested in taking a look, this is the commit: > > > https://gitlab.com/kicad/code/kicad/-/commit/6371b15aa4bbe4770d10a38bcd84b62c20da7e4e > > Currently the highlight width and transparency aren't configurable (but it > would be trivial to add this). Also, there is an edge-case whereby a custom > netclass colour that is the same a the default wire or bus colour won't > have highlights drawn. To fix that would need some significant > re-architecting of the schematic painting colour fetching code, and I think > it's likely to be a very rare edge case, so not worried about that for now. > > [image: Highlight.png] > > > Yours, > James. > > On Mon, 12 Aug 2024 at 16:20, exlabs <[email protected]> wrote: > >> Hi James, >> >> Yes, this is exactly what I was hoping for! Wow, you did that so fast. It >> would be great to see your Commit to learn how you accomplished this. >> >> This is totally usable to my eye, but here are some ascetic suggestions >> you might consider: >> >> 1. Swap the layer order to place the highlight on top of the wire: >> this will be more natural-looking as the wire has been highlighted by a >> pen. >> 2. Offset the highlight slightly so that it does not touch the >> beginning or end of the wire: it stays away from the component symbol. >> >> That's all I got—great job! >> >> Regards, >> >> Daniel >> On Monday, August 12, 2024 at 3:18:25 PM UTC+1 [email protected] >> wrote: >> >>> Daniel, >>> >>> Something like this? Need to tidy up some UI stuff (and make it apply to >>> buses with netclass colours) but is this the kind of thing you're looking >>> for? >>> >>> [image: NetHighlights.png] >>> >>> Yours, >>> James. >>> >>> >>> On Mon, 12 Aug 2024 at 13:05, James Jackson <[email protected]> >>> wrote: >>> >>>> Hi Daniel, >>>> >>>> Aha - I read too much in to your screenshot! In which case, ignore most >>>> of what I said, and listen to Jon ;-) >>>> >>>> Sounds like a separate rendering layer is the way forwards. Let me see >>>> if I can knock something up as a proof of concept. >>>> >>>> Yours, >>>> James. >>>> >>>> On Mon, 12 Aug 2024 at 10:31, exlabs <[email protected]> wrote: >>>> >>>>> Hi James, John, >>>>> >>>>> Thank you both for the welcoming discussion. >>>>> >>>>> I won't comment too much on the technical implementation side here - >>>>> but I will get a workspace setup and search the terms you mentioned. >>>>> >>>>> Just to clarify, yes, I'm mainly interested in adding a new way of >>>>> rendering netclass colours in the schematic. >>>>> >>>>> For example, I have used my incredible Photoshop skills to add a >>>>> checkbox to the Schematic Setup Window. >>>>> >>>>> [image: Kicad_netclass_highlight.png] >>>>> >>>>> Checkbox disable: No rendering changes; color is the line color. >>>>> Checkbox enabled: line color is a default value, and the color is >>>>> drawn in a highlighter pen style. >>>>> >>>>> I don't want to suggest that this is best UI, or the best way of >>>>> implementing it because I don't know the codebase at all! Please take >>>>> this >>>>> purely at a functional level - you can imagine how the feature would >>>>> work. >>>>> >>>>> By posting the Altium screenshot, I didn't mean to imply anything more >>>>> complicated than what is written above; it illustrated the highlighter >>>>> pen >>>>> rendering style quite nicely. >>>>> >>>>> I will watch the discussion develop and chime in when I have something >>>>> useful to say. >>>>> >>>>> Daniel >>>>> >>>>> On Monday, August 12, 2024 at 6:16:58 AM UTC+1 [email protected] >>>>> wrote: >>>>> >>>>>> (For further clarity - I'm looking specifically at how to do this in >>>>>> eeschema. We do have the net colouring mechanisms in pcbnew we could >>>>>> integrate this with to handle that side of things.). >>>>>> >>>>>> On Mon, 12 Aug 2024 at 05:50, James Jackson <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Jon, >>>>>>> >>>>>>> I think we've interpreted the feature differently (but not >>>>>>> necessarily orthogonally...). I read the ask as being able to colour >>>>>>> nets >>>>>>> (be that rendered as you say with a new highlight layer, or as we >>>>>>> currently >>>>>>> do). As far as I can see, the only way to currently colour a net is >>>>>>> through >>>>>>> netclasses. We can also set the colour of individual schematic wires, >>>>>>> but >>>>>>> that (to my mind) doesn't hit the 'colour a net' request. Have I missed >>>>>>> another method of colouring nets? >>>>>>> >>>>>>> I think the request here is twofold: a way to colour nets (not just >>>>>>> individual wires, and not just be using netclass directives), and a new >>>>>>> UI >>>>>>> method of quickly assigning colour to nets (which looks like an >>>>>>> extension >>>>>>> of the net highlighting tool - i.e a. 'colour this net please' tool).. >>>>>>> >>>>>>> I haven't used the equivalent Altium feature referred to in the >>>>>>> original email, but the way I read the docs is if I add another wire to >>>>>>> a >>>>>>> coloured net, that wire will also pick up the net colour. I don't >>>>>>> think, >>>>>>> without assigning a netclass, we have a way to do this at the moment >>>>>>> (nor, >>>>>>> as you say, do we have a way to transfer anything other than a >>>>>>> netclass-defined colour to the PCB, which seems an integral part of >>>>>>> this >>>>>>> feature for assisting in laying out complex boards). >>>>>>> >>>>>>> Yours, >>>>>>> James. >>>>>>> >>>>>>> On Mon, 12 Aug 2024 at 01:01, Jon Evans <[email protected]> wrote: >>>>>>> >>>>>>>> Hi Daniel, >>>>>>>> >>>>>>>> KiCad nightly (for V9) already has a feature to transfer schematic >>>>>>>> netclass colors to the board (this isn't done automatically because >>>>>>>> sometimes you want different colors in each place). This seems to >>>>>>>> address >>>>>>>> one of your desires. >>>>>>>> >>>>>>>> It seems like the crux of what you want is a rendering change: >>>>>>>> instead of showing net colors as a change in the line color, you show >>>>>>>> them >>>>>>>> as a "highlight", or in other words, a different line that is thicker >>>>>>>> and >>>>>>>> underneath the wire/bus. >>>>>>>> >>>>>>>> I think this should be done as an option (either a user preference, >>>>>>>> or a schematic/project option -- I would lean towards user preference >>>>>>>> here, >>>>>>>> but don't feel strongly) to change how netclass colors are rendered. >>>>>>>> >>>>>>>> As for the technical implementation -- it would require a new >>>>>>>> virtual rendering layer, I think. Search the code for >>>>>>>> LAYER_SELECTION_SHADOWS to see an example of how it is done. These >>>>>>>> rendering layers are used for Z-ordering since there cannot be >>>>>>>> different >>>>>>>> Z-order within a single layer. >>>>>>>> >>>>>>>> @James -- unless I'm missing something, I think this may be simpler >>>>>>>> than you put it. Schematic line color is not limited to netclasses, >>>>>>>> but >>>>>>>> netclasses are the only mechanism for transferring line color to the >>>>>>>> PCB. >>>>>>>> I don't think the proposed feature should be tied to any structural >>>>>>>> changes >>>>>>>> to how color works or how netclasses work -- it's really just a >>>>>>>> preference >>>>>>>> for how lines are drawn in the schematic editor, I think. >>>>>>>> >>>>>>>> Best, >>>>>>>> Jon >>>>>>>> >>>>>>>> On Sun, Aug 11, 2024 at 12:11 PM 'James Jackson' via KiCad >>>>>>>> Developers <[email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Daniel, >>>>>>>>> >>>>>>>>> JamesJ from the forum here! >>>>>>>>> >>>>>>>>> I've been thinking about how one would implement this feature >>>>>>>>> given the internals of KiCad since your forum post. The devil is, as >>>>>>>>> you >>>>>>>>> say, in the detail. I'd offer up the following thoughts: >>>>>>>>> >>>>>>>>> 1. Currently all net / trace colouring is tied to netclasses. Do >>>>>>>>> we want another (parallel) method of colouring nets? (That's one for >>>>>>>>> us to >>>>>>>>> come to a consensus on) >>>>>>>>> 2. 'Just changing the rendering' is not entirely trivial - the >>>>>>>>> question is from where (and how) is the colour information getting to >>>>>>>>> the >>>>>>>>> right place (this includes schematic rendering of various object >>>>>>>>> classes, >>>>>>>>> pcb rendering of various object classes, and ratsnest rendering)? As >>>>>>>>> a >>>>>>>>> rough guide, have a look through the codebase for calls to >>>>>>>>> GetEffectiveNetClass(); lots of these are to do with finding out >>>>>>>>> rendering >>>>>>>>> colours / line widths. If adding a bespoke method (see Approach 2 >>>>>>>>> below), >>>>>>>>> we'd have to add something to each of these to extract the connection >>>>>>>>> for >>>>>>>>> the object, grab the connection's net name, and query against some >>>>>>>>> net -> >>>>>>>>> colour lookup. >>>>>>>>> >>>>>>>>> I think there are two ways I'd look to implement this, if we >>>>>>>>> decided we'd like it: >>>>>>>>> >>>>>>>>> Approach 1: >>>>>>>>> Leverage the existing netclass mechanisms. The new tool could >>>>>>>>> create a new netclass per colour requested, with a high priority >>>>>>>>> value set, >>>>>>>>> and also add a netclass pattern assignment to match the netclass to >>>>>>>>> the >>>>>>>>> selected net names. >>>>>>>>> Advantages: Uses existing rendering infrastructure, so the tool >>>>>>>>> only needs to insert netclasses and pattern assignments (which is >>>>>>>>> very easy >>>>>>>>> to do) >>>>>>>>> Disadvantages: The new netclasses will show up in the status bars >>>>>>>>> (a net with no other netclass assignments with show as: "Netclass: >>>>>>>>> Green >>>>>>>>> and Default", for example). The new netclasses will 'clog up' the >>>>>>>>> netclass >>>>>>>>> setup dialog list. These could both be mitigated by special-casing >>>>>>>>> the net >>>>>>>>> colouring netclasses / pattern matching rules to not be displayed in >>>>>>>>> the >>>>>>>>> netclass setup UI, and to not count them for DRC constraint netclass >>>>>>>>> matching (but this feels a little messy). >>>>>>>>> >>>>>>>>> Approach 2: >>>>>>>>> Add a new data structure which maps netclass names to colour >>>>>>>>> overrides. Where we check nets for colour from netclasses, we also >>>>>>>>> add a >>>>>>>>> check to see if there is a net colour override. >>>>>>>>> Advantages: Doesn't impact on the netclass asignments >>>>>>>>> Disadvantages: Another layer of complexity in rendering colour >>>>>>>>> choice >>>>>>>>> >>>>>>>>> Both of these have a shared disadvantage in that the only >>>>>>>>> consistent identifier for a net is its name. And these are mutable >>>>>>>>> if, for >>>>>>>>> example, one adds a higher priority driver to a net, or changes a >>>>>>>>> driving >>>>>>>>> component designation or pin. As far as I can think, there's no easy >>>>>>>>> way to >>>>>>>>> map changes in net names on schematic edits, so sometimes colours >>>>>>>>> might >>>>>>>>> just drop on net name changes. >>>>>>>>> >>>>>>>>> UI considerations aside, either method actually wouldn't be that >>>>>>>>> hard to do (famous last words...), and I'd be happy to implement it >>>>>>>>> (I've >>>>>>>>> had my head buried deep in the rendering code for the multiple >>>>>>>>> netclass >>>>>>>>> work I recently implemented). I'd welcome comment from the other lead >>>>>>>>> devs >>>>>>>>> on if we want another way to colour nets though. FWIW, I think this >>>>>>>>> would >>>>>>>>> be a useful addition, but that's a weakly held view. >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> James. >>>>>>>>> >>>>>>>>> On Sun, 11 Aug 2024 at 15:58, Daniel Farrell < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Dear KiCad developers, >>>>>>>>>> >>>>>>>>>> I’ve been using KiCad for a number of years now, and I have a >>>>>>>>>> background in software and electronics. I enjoy doing both backend >>>>>>>>>> and >>>>>>>>>> frontend development. For example, here is a clone of a UI color >>>>>>>>>> picker in >>>>>>>>>> macOS that I wrote a while ago, >>>>>>>>>> https://github.com/danieljfarrell/DFColorWell 100% of the widget >>>>>>>>>> is rendered using the native drawing API. >>>>>>>>>> >>>>>>>>>> Anyway, to the point! >>>>>>>>>> >>>>>>>>>> There is an enhancement to the schematic editor I’d like to add >>>>>>>>>> and ask for some advice on how it might be implemented, if it is >>>>>>>>>> something >>>>>>>>>> you are interested in having. >>>>>>>>>> >>>>>>>>>> I really like to use netlist colors in the schematic editor; for >>>>>>>>>> me, it improves readability. The enhancement I’d like to make is to >>>>>>>>>> add a >>>>>>>>>> net “highlight pen” effect color option. >>>>>>>>>> >>>>>>>>>> Altium implements this quite nicely; they render a transparent >>>>>>>>>> highlight as if it has been drawn by a highlighter pen over the >>>>>>>>>> line, and >>>>>>>>>> the same colors appear in the PCB editors. See image. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That’s the proposal at a high level. >>>>>>>>>> >>>>>>>>>> But the devil is in the details. Some immediate questions that >>>>>>>>>> spring to mind are: 1) Does the highlight pen color appear as an >>>>>>>>>> addition >>>>>>>>>> color option in the Schematic Setup Window? 2) Does everything >>>>>>>>>> remain the >>>>>>>>>> same, but we just change the rendering? >>>>>>>>>> >>>>>>>>>> I think I prefer option 2, with a caveat: >>>>>>>>>> >>>>>>>>>> Imagine a text box on the schematic setup window, something like >>>>>>>>>> "Highlight." When not enabled, everything is the same as now: the >>>>>>>>>> color >>>>>>>>>> corresponds to the line color. However, when enabled, the line color >>>>>>>>>> is set >>>>>>>>>> to a default, and the color is drawn over the line like a >>>>>>>>>> highlighter pen. >>>>>>>>>> >>>>>>>>>> This has the nice feature that it’s automatically backwards >>>>>>>>>> compatible, as it can be made an opt-in rendering feature. It also >>>>>>>>>> means >>>>>>>>>> that no changes are needed to how colors are brought across to the >>>>>>>>>> PCB; >>>>>>>>>> there is only one color in both cases; all that changes is how it is >>>>>>>>>> rendered. Finally, in terms of persistence in the document, it is >>>>>>>>>> just a >>>>>>>>>> single Boolean. >>>>>>>>>> >>>>>>>>>> It would be very interesting to get your ideas, comments, >>>>>>>>>> suggestions on how to implement it, and feedback on whether this is >>>>>>>>>> something that would be welcomed. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Daniel >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>> Google Groups "KiCad Developers" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>> send an email to [email protected]. >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/a/kicad.org/d/msgid/devlist/CADXPdTxuUDf-RpTsizXvsydrUbVfHQXY%2BgMU9WybBzwajGYYvg%40mail.gmail.com >>>>>>>>>> >>>>>>>>>> <https://groups.google.com/a/kicad.org/d/msgid/devlist/CADXPdTxuUDf-RpTsizXvsydrUbVfHQXY%2BgMU9WybBzwajGYYvg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "KiCad Developers" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to [email protected]. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/a/kicad.org/d/msgid/devlist/CAMVX%3DtbaP%2B%3DLVTzWQB5qG%2BChN%3DknxQybyU_NC8zGDwkzewTriw%40mail.gmail.com >>>>>>>>> >>>>>>>>> <https://groups.google.com/a/kicad.org/d/msgid/devlist/CAMVX%3DtbaP%2B%3DLVTzWQB5qG%2BChN%3DknxQybyU_NC8zGDwkzewTriw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "KiCad Developers" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/kicad.org/d/msgid/devlist/CA%2BqGbCDdzEb%3D3StBbmbSd2Vsi5PcKkMAwJ5gYNYcaTq%2B36TCBQ%40mail.gmail.com >>>>>>>> >>>>>>>> <https://groups.google.com/a/kicad.org/d/msgid/devlist/CA%2BqGbCDdzEb%3D3StBbmbSd2Vsi5PcKkMAwJ5gYNYcaTq%2B36TCBQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >> You received this message because you are subscribed to the Google Groups >> "KiCad Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/a/kicad.org/d/msgid/devlist/3e53ffbc-bcc8-4138-af99-482b37d244a2n%40kicad.org >> >> <https://groups.google.com/a/kicad.org/d/msgid/devlist/3e53ffbc-bcc8-4138-af99-482b37d244a2n%40kicad.org?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "KiCad Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/7a612274-1fa4-4437-bb70-42436929ae60n%40kicad.org.
