> Offset the highlight slightly so that it does not touch the beginning or end of the wire: it stays away from the component symbol.
This is not trivial. I'd advise against spending time on this personally. On Mon, Aug 12, 2024 at 11:20 AM exlabs <daniel.james.farr...@gmail.com> 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 ja...@jamesjackson.org > 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 <ja...@jamesjackson.org> >> 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 <daniel.jam...@gmail.com> 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 ja...@jamesjackson.org >>>> 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 <ja...@jamesjackson.org> >>>>> 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 <j...@craftyjon.com> 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 <dev...@kicad.org> 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 < >>>>>>>> daniel.jam...@gmail.com> 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 devlist+u...@kicad.org. >>>>>>>>> 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 devlist+u...@kicad.org. >>>>>>>> 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 devlist+u...@kicad.org. >>>>>>> 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 devlist+unsubscr...@kicad.org. > 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 devlist+unsubscr...@kicad.org. To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CA%2BqGbCC5qTZE6huxCmKgq%3D-XrMJouFwZBvtgsm3E5gf-J9RBRA%40mail.gmail.com.
