> 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 <[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/CA%2BqGbCC5qTZE6huxCmKgq%3D-XrMJouFwZBvtgsm3E5gf-J9RBRA%40mail.gmail.com.
