Re: [Kicad-developers] Eeschema annotate block / specific component types proposal

[James Jackson]

Thanks Jon - I don't have access to Altium so that's really helpful.

I was wondering about the possibility of locking components; I sometimes
want to do this with, for example, key ICs - MCUs, DACs, etc. One could add
this as a Symbol Property, which wouldn't need any changes to file formats.
Whether it got a custom checkbox in the Symbol Properties dialog, or would
just be there as another option that a user may add (which would make it a
'power user' feature as it wouldn't be obvious unless one knew to add it)
would need to be considered - UI clutter vs. access to features for all.

With the multi-part consideration, where on the schematic does it dump the
new components? It wouldn't be too difficult to implement an algorithm
which finds a space in which all the sub-components required could fit,
with some gross assumptions on layout. Or can Altium add a component to the
BOM without it being on the schematic?

I'm also mindful that some algorithms can't solve everything (although this
strikes me as a non-trivial problem, rather than an impossible problem...)
- and bailing out and telling the user why is also always a option, in the
spirit of 'do no harm'.

Yours,
James.

On Thu, May 7, 2020 at 9:59 PM Jon Evans  wrote:

> Altium doesn't have "annotate selected"
> It does let you lock the annotation on components at will, so you can lock
> some, reset everything (which ignores locked) and then re-annotate.
> If you change the annotation of one part of a multi-part component, it
> will result in two components being forwarded to the PCB like Janvi
> proposes.
> And also likewise, the ERC will warn about this if configured
> appropriately.
>
> As to how it handles the complex hierarchy situations JP mentioned, I'm
> not certain to be honest, because Altium's hierarchy model is a bit
> different from KiCad's (in some ways simpler) and I haven't checked to see
> if the same situations are possible.
>
> -Jon
>
> On Thu, May 7, 2020 at 4:48 PM James Jackson <
> james.a.f.jackso...@gmail.com> wrote:
>
>> That's an interesting take on it. I can foresee the catastrophic addition
>> of loads of other components though, if there's an error in the schematic
>> somewhere and a rogue missing / one-over unit gets cascaded down sheets.
>>
>> What do other EDA tools do with annotation? Do they have this feature? Do
>> they handle these conditions?
>>
>> On Thu, May 7, 2020 at 8:18 PM ja...@veith.net  wrote:
>>
>>> > - What about multi-units components: for instance what about renaming
>>> 2 of 5 units when one unit is the unit handling the power pins?
>>> > this is the best way to break a design.
>>>
>>> This should add another component to the BOM and schematic DRC should
>>> report unused gates for both of the reference designators
>>>
>>> > Good luck with block annotation.
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Eeschema annotate block / specific component types proposal

[Jon Evans]

Altium doesn't have "annotate selected"
It does let you lock the annotation on components at will, so you can lock
some, reset everything (which ignores locked) and then re-annotate.
If you change the annotation of one part of a multi-part component, it will
result in two components being forwarded to the PCB like Janvi proposes.
And also likewise, the ERC will warn about this if configured appropriately.

As to how it handles the complex hierarchy situations JP mentioned, I'm not
certain to be honest, because Altium's hierarchy model is a bit different
from KiCad's (in some ways simpler) and I haven't checked to see if the
same situations are possible.

-Jon

On Thu, May 7, 2020 at 4:48 PM James Jackson 
wrote:

> That's an interesting take on it. I can foresee the catastrophic addition
> of loads of other components though, if there's an error in the schematic
> somewhere and a rogue missing / one-over unit gets cascaded down sheets.
>
> What do other EDA tools do with annotation? Do they have this feature? Do
> they handle these conditions?
>
> On Thu, May 7, 2020 at 8:18 PM ja...@veith.net  wrote:
>
>> > - What about multi-units components: for instance what about renaming 2
>> of 5 units when one unit is the unit handling the power pins?
>> > this is the best way to break a design.
>>
>> This should add another component to the BOM and schematic DRC should
>> report unused gates for both of the reference designators
>>
>> > Good luck with block annotation.
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Eeschema annotate block / specific component types proposal

[James Jackson]

That's an interesting take on it. I can foresee the catastrophic addition
of loads of other components though, if there's an error in the schematic
somewhere and a rogue missing / one-over unit gets cascaded down sheets.

What do other EDA tools do with annotation? Do they have this feature? Do
they handle these conditions?

On Thu, May 7, 2020 at 8:18 PM ja...@veith.net  wrote:

> > - What about multi-units components: for instance what about renaming 2
> of 5 units when one unit is the unit handling the power pins?
> > this is the best way to break a design.
>
> This should add another component to the BOM and schematic DRC should
> report unused gates for both of the reference designators
>
> > Good luck with block annotation.
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Eeschema annotate block / specific component types proposal

[James Jackson]

Thanks Jeff - I'll take a look at a nightly to see where things are now.
Sounds like a much better selection strategy too!

Jean-Pierre - You're quite right to highlight these complications, which
I've been mulling over myself. I don't yet have proposed solutions, but I'm
going to give it a good think.

Your comments on multi-part units would I think, at least partially, be a
problem even now. For example, if I have one unit providing power on one
sheet, and another unit on a sheet that gets annotated alone, they could
become broken.

Thinking out loud, in cases where a unit is nested in a hierarchy, it would
make sense to keep the annotation of an already-annotated unit at a higher
level in the hierarchy (towards the root schematic), and to
forward-propagate the annotation to units at a lower level in the
hierarchy. I'll need to think about ways to handle when units in different
sheets are at at the same hierarchy level, or in different
hierarchical trees with no unit in a common root. That would arguably be
messy design, but it's a possibility so should be handled.

Of course, anything is an implementation decision, and users should neither
be surprised by what a feature does, or have things done that they don't
know about. I.e. there should be some warnings to the user if some form of
forward, back, or sideways propagation to units not in the currently
annotation scope (selection or sheet) are going to be updated. I presume
there is an algorithm already which tracks the annotation of multi-part
units (by counting sub-units remaining? Or...) - so I'll study that and see
what it does currently too.

Yours,
James.

On Thu, May 7, 2020 at 7:28 PM jp charras  wrote:

> Le 07/05/2020 à 20:15, Jeff Young a écrit :
> > Hi James,
> >
> > You might first want to download one of the nightlies (5.99) and play
> with it.  Block selections are gone: eeschema now has a “normal” selection
> model where you click on things and/or drag-select and they get highlighted.
> >
> > So from the GUI perspective you’d just need to add the options to the
> Scope section of the Annotate dialog.
> >
> > I believe there’s already a Wishlist item for this in the issue database.
> >
> > I suck at git, so you don’t want to know what I do for branching, etc. ;)
> >
> > Cheers,
> > Jeff.
> >
>
> Annotating just a selected area is not trivial:
>
> - What about multi-units components: for instance what about renaming 2 of
> 5 units when one unit is the unit handling the power pins?
> this is the best way to break a design.
> - What about complex hierarchies: selecting an area selects in fact as
> many areas as sheet instances.
>
> - and what about multi-units components in complex hierarchies.
>
> Good luck with block annotation.
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Eeschema annotate block / specific component types proposal

[jp charras]

Le 07/05/2020 à 20:15, Jeff Young a écrit :
> Hi James,
> 
> You might first want to download one of the nightlies (5.99) and play with 
> it.  Block selections are gone: eeschema now has a “normal” selection model 
> where you click on things and/or drag-select and they get highlighted.
> 
> So from the GUI perspective you’d just need to add the options to the Scope 
> section of the Annotate dialog.
> 
> I believe there’s already a Wishlist item for this in the issue database.
> 
> I suck at git, so you don’t want to know what I do for branching, etc. ;)
> 
> Cheers,
> Jeff.
> 

Annotating just a selected area is not trivial:

- What about multi-units components: for instance what about renaming 2 of 5 
units when one unit is the unit handling the power pins?
this is the best way to break a design.
- What about complex hierarchies: selecting an area selects in fact as many 
areas as sheet instances.

- and what about multi-units components in complex hierarchies.

Good luck with block annotation.

-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Eeschema annotate block / specific component types proposal

[Jeff Young]

Hi James,

You might first want to download one of the nightlies (5.99) and play with it.  
Block selections are gone: eeschema now has a “normal” selection model where 
you click on things and/or drag-select and they get highlighted.

So from the GUI perspective you’d just need to add the options to the Scope 
section of the Annotate dialog.

I believe there’s already a Wishlist item for this in the issue database.

I suck at git, so you don’t want to know what I do for branching, etc. ;)

Cheers,
Jeff.

> On 7 May 2020, at 14:19, James Jackson  wrote:
> 
> Hi all,
> 
> Firstly thanks Wayne for adding me to the list - long time KiCad user for 
> hobby stuff, but I've got a background (partially) in fast real-time 
> mixed-signal electronics.
> 
> Working on a fairly large personal project recently, with many nested and 
> shared schematics, I would really have liked the ability to only 
> automatically annotate either a selected block of components, and/or only a 
> subset of the component types. I haven't done an KiCad UI-facing dev work 
> (or, frankly, much at all bar poking around in the code a little bit) but I'd 
> be happy to have a bash at implementing it - but would welcome others' 
> thoughts. I can't find any mention of it in roadmaps etc.
> 
> Proposal: Add the ability to annotate only a selected block and / or only 
> specific component types
> UI Flow: Two changes required, as detailed below. As described, they do not 
> change the current default UI flow, but offer up more options for users 
> should they wish to use them:
> 
>1. Add a new menu item to the block selection context menu, with text 
> 'Annotate block...'. On clicking, takes the user to the current 'Annotate 
> Schematic' dialog.
>2. Modify the 'Annotate Schematic' dialog to include:
>a. Within the 'Scope' radio button selection list, add 'Use the 
> current selected block' (not enabled if the dialog is entered the existing 
> way through the Tools menu) - autoselected if dialog entered through the 
> block context menu
>b. Add a checklist containing the prefixes of component types 
> available for annotation (i.e. 'R', 'C', 'U', whatever...). Default to all 
> being selected.
> 
> I'd welcome thoughts on this proposal, and also, if people think it's worth 
> looking at, any pointers to a quick guide to KiCad dev wrt branch handling. 
> I.e., do developers work to the head of the repository or the last stable 
> release, etc etc? I couldn't find anything on this hiding in the dev docs. I 
> can figure the rest out (internationalisation, code structures, etc etc).
> 
> Yours,
> James.
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Consider changing .pro extension in the future

[Jon Evans]

You heard it here first: not a tentative plan, a definite plan :) (or at
least as definite as these things get)

Project format will be changing, and the extension will change to kicad_pro
along with it.
The extension change will not apply to the existing file format.
This change is tied to other work to extract project settings from various
files and put them in a more logical place, to make it easier to copy
settings between projects and enable other features.

On Thu, May 7, 2020 at 12:27 PM Ian McInerney 
wrote:

> There is a tentative plan to change this to a `.kicad_pro` file in v6, but
> it hasn't been completely thought through yet. See
> https://gitlab.com/kicad/code/kicad/-/issues/2169#note_286814996.
>
> -Ian
>
> On Thu, May 7, 2020 at 5:05 PM RigoLigo RLC  wrote:
>
>> Hello everyone,
>>
>> The .pro project file extension might be a historical problem, but I
>> really should mention that this extension was used by too many programs,
>> for example, Qt Creator.
>>
>> Now the kicad_sch extension came with the S-expression style schematics
>> format, I'd like to ask would KiCad plan to change the project file
>> extension name.
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Consider changing .pro extension in the future

[Jon Evans]

It's on my TODO list, it will happen as part of a new project format
https://gitlab.com/kicad/code/kicad/-/issues/2169

-Jon

On Thu, May 7, 2020 at 12:18 PM Wayne Stambaugh 
wrote:

> I'm pretty sure this has been discussed to death but but until a new
> project file format is created, the file extension will remain .pro.
> It's bad enough that this clashes with other applications but having an
> internal file format clash just fix something unrelated to KiCad doesn't
> make much sense to me.  This is problem that affects many applications
> not just KiCad.
>
> On 5/7/20 12:04 PM, RigoLigo RLC wrote:
> > Hello everyone,
> >
> > The .pro project file extension might be a historical problem, but I
> > really should mention that this extension was used by too many programs,
> > for example, Qt Creator.
> >
> > Now the kicad_sch extension came with the S-expression style schematics
> > format, I'd like to ask would KiCad plan to change the project file
> > extension name.
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Consider changing .pro extension in the future

[Wayne Stambaugh]

I'm pretty sure this has been discussed to death but but until a new
project file format is created, the file extension will remain .pro.
It's bad enough that this clashes with other applications but having an
internal file format clash just fix something unrelated to KiCad doesn't
make much sense to me.  This is problem that affects many applications
not just KiCad.

On 5/7/20 12:04 PM, RigoLigo RLC wrote:
> Hello everyone,
> 
> The .pro project file extension might be a historical problem, but I
> really should mention that this extension was used by too many programs,
> for example, Qt Creator. 
> 
> Now the kicad_sch extension came with the S-expression style schematics
> format, I'd like to ask would KiCad plan to change the project file
> extension name. 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Consider changing .pro extension in the future

[Ian McInerney]

There is a tentative plan to change this to a `.kicad_pro` file in v6, but
it hasn't been completely thought through yet. See
https://gitlab.com/kicad/code/kicad/-/issues/2169#note_286814996.

-Ian

On Thu, May 7, 2020 at 5:05 PM RigoLigo RLC  wrote:

> Hello everyone,
>
> The .pro project file extension might be a historical problem, but I
> really should mention that this extension was used by too many programs,
> for example, Qt Creator.
>
> Now the kicad_sch extension came with the S-expression style schematics
> format, I'd like to ask would KiCad plan to change the project file
> extension name.
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Consider changing .pro extension in the future

[RigoLigo RLC]

Hello everyone,

The .pro project file extension might be a historical problem, but I really
should mention that this extension was used by too many programs, for
example, Qt Creator.

Now the kicad_sch extension came with the S-expression style schematics
format, I'd like to ask would KiCad plan to change the project file
extension name.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] New schematic and symbol library file formats

[Nick Østergaard]

github for now

tor. 7. maj 2020 15.55 skrev Wayne Stambaugh :

> I just made some changes to the blog post to reflect a code change.  Are
> we still using the GitHub repo or have we migrated the website to the
> GitLab repo?
>
> On 5/6/20 10:59 PM, Mark Roszko wrote:
> > I made it better, maybe
> >
> > On Wed, May 6, 2020 at 6:00 PM Nick Østergaard  > > wrote:
> >
> > I have done it, could't be bothered with the bullet points though. :)
> >
> > On Wed, 6 May 2020 at 23:11, Wayne Stambaugh  > > wrote:
> > >
> > > If you have time, I'm fine with that.  Thanks for the help.
> > >
> > > On 5/6/2020 4:57 PM, Nick Østergaard wrote:
> > > > I can do it, I will probably just copy paste from the forum post
> > more
> > > > or less and then you can edit it if you want.
> > > >
> > > > On Wed, 6 May 2020 at 22:56, Wayne Stambaugh
> > mailto:stambau...@gmail.com>> wrote:
> > > >>
> > > >> It's on my short list.  I planned on having it done already but
> > I've
> > > >> been busy fixing bugs so it got pushed back a bit.
> > > >>
> > > >> On 5/6/2020 4:16 PM, Nick Østergaard wrote:
> > > >>> Shouldn't we post that on the blog on the website as well?
> > Looks copy pastable.
> > > >>>
> > > >>> What you do think Wayne?
> > > >>>
> > > >>> On Mon, 4 May 2020 at 22:53, Wayne Stambaugh
> > mailto:stambau...@gmail.com>> wrote:
> > > 
> > >  For those nightly build users, the merge request to make the
> new
> > >  schematic and symbol library file formats the default file
> > format was
> > >  merged so builds should soon be available.  I wrote a detailed
> > >  description on the KiCad user forum[1] if you are interested
> > in the
> > >  changes.  Please test it and report any bugs so I can get
> > this stable as
> > >  quickly as possible so we can start to add new features.
> > > 
> > >  Cheers,
> > > 
> > >  Wayne
> > > 
> > >  [1]:
> > > 
> >
> https://forum.kicad.info/t/kicad-nightly-v5-99-new-schematic-and-symbol-library-file-formats-are-now-the-default/22655
> > > 
> > >  ___
> > >  Mailing list: https://launchpad.net/~kicad-developers
> > >  Post to : kicad-developers@lists.launchpad.net
> > 
> > >  Unsubscribe : https://launchpad.net/~kicad-developers
> > >  More help   : https://help.launchpad.net/ListHelp
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
> > --
> > Mark
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Eeschema annotate block / specific component types proposal

[James Jackson]

Brian,

Great to know that I'm not the only one who thought it a useful addition.
Really happy to collaborate, and to try and unpick those issues. As I'm not
the KiCad dev it'll take me a little while to figure out the code flow, but
no harm in having a crack. Great if you were able to bring your branch up
to date - and yes, git can be a pain to conceptually grasp. I've never
reached the level of fluency with it I'd like.

Yours,
James.

On Thu, May 7, 2020 at 2:33 PM Brian Piccioni 
wrote:

> Hello James
>
> I had been working on this for some time and ran into a brick wall so I
> set it aside.
>
> There seems to be an issue with the structures used within eeSchema
> (sheets, screens, etc.) which don't seem to consistently track UUIDs, etc.
> I suspect that this may be because eeSchema started as a single page app
> then added hierarchies. Currently, annotate has an essentially binary
> approach (whole schematic or single page) and, in theory it should be
> possible to add those functions but you end up with bad pointers, display
> not refreshing, etc..
>
> I put out several requests for the devs for help but, given the lock down
> got no replies.
>
> I implemented similar functionality for PCBNew. My gitlab is
> https://gitlab.com/bjpiccioni/kicad and the branch is annotate if you
> want to take a look. It is out of date because I got really frustrated
> trying to unnscramble it. All the menus, etc., are done, the problem is
> just that the result doesn't work.
>
>
> If you want to collaborate, let me know. And I'll try bring it up to date
> with the current dev branch of Kicad. Alas I find git to be a  nightmare.
>
> Brian
>
>
>
> On 2020-05-07 9:19 a.m., James Jackson wrote:
>
> Hi all,
>
> Firstly thanks Wayne for adding me to the list - long time KiCad user for
> hobby stuff, but I've got a background (partially) in fast real-time
> mixed-signal electronics.
>
> Working on a fairly large personal project recently, with many nested and
> shared schematics, I would really have liked the ability to only
> automatically annotate either a selected block of components, and/or only a
> subset of the component types. I haven't done an KiCad UI-facing dev work
> (or, frankly, much at all bar poking around in the code a little bit) but
> I'd be happy to have a bash at implementing it - but would welcome others'
> thoughts. I can't find any mention of it in roadmaps etc.
>
> *Proposal*: Add the ability to annotate only a selected block and / or
> only specific component types
> *UI Flow: *Two changes required, as detailed below. As described, they do
> not change the current default UI flow, but offer up more options for users
> should they wish to use them:
>
>1. Add a new menu item to the block selection context menu, with text
> 'Annotate block...'. On clicking, takes the user to the current 'Annotate
> Schematic' dialog.
>2. Modify the 'Annotate Schematic' dialog to include:
>a. Within the 'Scope' radio button selection list, add 'Use the
> current selected block' (not enabled if the dialog is entered the existing
> way through the Tools menu) - autoselected if dialog entered through the
> block context menu
>b. Add a checklist containing the prefixes of component types
> available for annotation (i.e. 'R', 'C', 'U', whatever...). Default to all
> being selected.
>
> I'd welcome thoughts on this proposal, and also, if people think it's
> worth looking at, any pointers to a quick guide to KiCad dev wrt branch
> handling. I.e., do developers work to the head of the repository or the
> last stable release, etc etc? I couldn't find anything on this hiding in
> the dev docs. I can figure the rest out (internationalisation, code
> structures, etc etc).
>
> Yours,
> James.
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] New schematic and symbol library file formats

[Wayne Stambaugh]

I just made some changes to the blog post to reflect a code change.  Are
we still using the GitHub repo or have we migrated the website to the
GitLab repo?

On 5/6/20 10:59 PM, Mark Roszko wrote:
> I made it better, maybe
> 
> On Wed, May 6, 2020 at 6:00 PM Nick Østergaard  > wrote:
> 
> I have done it, could't be bothered with the bullet points though. :)
> 
> On Wed, 6 May 2020 at 23:11, Wayne Stambaugh  > wrote:
> >
> > If you have time, I'm fine with that.  Thanks for the help.
> >
> > On 5/6/2020 4:57 PM, Nick Østergaard wrote:
> > > I can do it, I will probably just copy paste from the forum post
> more
> > > or less and then you can edit it if you want.
> > >
> > > On Wed, 6 May 2020 at 22:56, Wayne Stambaugh
> mailto:stambau...@gmail.com>> wrote:
> > >>
> > >> It's on my short list.  I planned on having it done already but
> I've
> > >> been busy fixing bugs so it got pushed back a bit.
> > >>
> > >> On 5/6/2020 4:16 PM, Nick Østergaard wrote:
> > >>> Shouldn't we post that on the blog on the website as well?
> Looks copy pastable.
> > >>>
> > >>> What you do think Wayne?
> > >>>
> > >>> On Mon, 4 May 2020 at 22:53, Wayne Stambaugh
> mailto:stambau...@gmail.com>> wrote:
> > 
> >  For those nightly build users, the merge request to make the new
> >  schematic and symbol library file formats the default file
> format was
> >  merged so builds should soon be available.  I wrote a detailed
> >  description on the KiCad user forum[1] if you are interested
> in the
> >  changes.  Please test it and report any bugs so I can get
> this stable as
> >  quickly as possible so we can start to add new features.
> > 
> >  Cheers,
> > 
> >  Wayne
> > 
> >  [1]:
> > 
> 
> https://forum.kicad.info/t/kicad-nightly-v5-99-new-schematic-and-symbol-library-file-formats-are-now-the-default/22655
> > 
> >  ___
> >  Mailing list: https://launchpad.net/~kicad-developers
> >  Post to     : kicad-developers@lists.launchpad.net
> 
> >  Unsubscribe : https://launchpad.net/~kicad-developers
> >  More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> -- 
> Mark

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Eeschema annotate block / specific component types proposal

[Brian Piccioni]

Hello James

I had been working on this for some time and ran into a brick wall so I 
set it aside.


There seems to be an issue with the structures used within eeSchema 
(sheets, screens, etc.) which don't seem to consistently track UUIDs, 
etc. I suspect that this may be because eeSchema started as a single 
page app then added hierarchies. Currently, annotate has an essentially 
binary approach (whole schematic or single page) and, in theory it 
should be possible to add those functions but you end up with bad 
pointers, display not refreshing, etc..


I put out several requests for the devs for help but, given the lock 
down got no replies.


I implemented similar functionality for PCBNew. My gitlab is 
https://gitlab.com/bjpiccioni/kicad and the branch is annotate if you 
want to take a look. It is out of date because I got really frustrated 
trying to unnscramble it. All the menus, etc., are done, the problem is 
just that the result doesn't work.



If you want to collaborate, let me know. And I'll try bring it up to 
date with the current dev branch of Kicad. Alas I find git to be a  
nightmare.


Brian



On 2020-05-07 9:19 a.m., James Jackson wrote:

Hi all,

Firstly thanks Wayne for adding me to the list - long time KiCad user 
for hobby stuff, but I've got a background (partially) in fast 
real-time mixed-signal electronics.


Working on a fairly large personal project recently, with many nested 
and shared schematics, I would really have liked the ability to only 
automatically annotate either a selected block of components, and/or 
only a subset of the component types. I haven't done an KiCad 
UI-facing dev work (or, frankly, much at all bar poking around in the 
code a little bit) but I'd be happy to have a bash at implementing it 
- but would welcome others' thoughts. I can't find any mention of it 
in roadmaps etc.


*Proposal*: Add the ability to annotate only a selected block and / or 
only specific component types
*UI Flow: *Two changes required, as detailed below. As described, they 
do not change the current default UI flow, but offer up more options 
for users should they wish to use them:


   1. Add a new menu item to the block selection context menu, with 
text 'Annotate block...'. On clicking, takes the user to the current 
'Annotate Schematic' dialog.

   2. Modify the 'Annotate Schematic' dialog to include:
       a. Within the 'Scope' radio button selection list, add 'Use the 
current selected block' (not enabled if the dialog is entered the 
existing way through the Tools menu) - autoselected if dialog entered 
through the block context menu
       b. Add a checklist containing the prefixes of component types 
available for annotation (i.e. 'R', 'C', 'U', whatever...). Default to 
all being selected.


I'd welcome thoughts on this proposal, and also, if people think it's 
worth looking at, any pointers to a quick guide to KiCad dev wrt 
branch handling. I.e., do developers work to the head of the 
repository or the last stable release, etc etc? I couldn't find 
anything on this hiding in the dev docs. I can figure the rest out 
(internationalisation, code structures, etc etc).


Yours,
James.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Eeschema annotate block / specific component types proposal

[James Jackson]

Hi all,

Firstly thanks Wayne for adding me to the list - long time KiCad user for
hobby stuff, but I've got a background (partially) in fast real-time
mixed-signal electronics.

Working on a fairly large personal project recently, with many nested and
shared schematics, I would really have liked the ability to only
automatically annotate either a selected block of components, and/or only a
subset of the component types. I haven't done an KiCad UI-facing dev work
(or, frankly, much at all bar poking around in the code a little bit) but
I'd be happy to have a bash at implementing it - but would welcome others'
thoughts. I can't find any mention of it in roadmaps etc.

*Proposal*: Add the ability to annotate only a selected block and / or only
specific component types
*UI Flow: *Two changes required, as detailed below. As described, they do
not change the current default UI flow, but offer up more options for users
should they wish to use them:

   1. Add a new menu item to the block selection context menu, with text
'Annotate block...'. On clicking, takes the user to the current 'Annotate
Schematic' dialog.
   2. Modify the 'Annotate Schematic' dialog to include:
   a. Within the 'Scope' radio button selection list, add 'Use the
current selected block' (not enabled if the dialog is entered the existing
way through the Tools menu) - autoselected if dialog entered through the
block context menu
   b. Add a checklist containing the prefixes of component types
available for annotation (i.e. 'R', 'C', 'U', whatever...). Default to all
being selected.

I'd welcome thoughts on this proposal, and also, if people think it's worth
looking at, any pointers to a quick guide to KiCad dev wrt branch handling.
I.e., do developers work to the head of the repository or the last stable
release, etc etc? I couldn't find anything on this hiding in the dev docs.
I can figure the rest out (internationalisation, code structures, etc etc).

Yours,
James.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] New schematic and symbol library file formats

[Nick Østergaard]

Awesome, thanks!

tor. 7. maj 2020 04.59 skrev Mark Roszko :

> I made it better, maybe
>
> On Wed, May 6, 2020 at 6:00 PM Nick Østergaard  wrote:
>
>> I have done it, could't be bothered with the bullet points though. :)
>>
>> On Wed, 6 May 2020 at 23:11, Wayne Stambaugh 
>> wrote:
>> >
>> > If you have time, I'm fine with that.  Thanks for the help.
>> >
>> > On 5/6/2020 4:57 PM, Nick Østergaard wrote:
>> > > I can do it, I will probably just copy paste from the forum post more
>> > > or less and then you can edit it if you want.
>> > >
>> > > On Wed, 6 May 2020 at 22:56, Wayne Stambaugh 
>> wrote:
>> > >>
>> > >> It's on my short list.  I planned on having it done already but I've
>> > >> been busy fixing bugs so it got pushed back a bit.
>> > >>
>> > >> On 5/6/2020 4:16 PM, Nick Østergaard wrote:
>> > >>> Shouldn't we post that on the blog on the website as well? Looks
>> copy pastable.
>> > >>>
>> > >>> What you do think Wayne?
>> > >>>
>> > >>> On Mon, 4 May 2020 at 22:53, Wayne Stambaugh 
>> wrote:
>> > 
>> >  For those nightly build users, the merge request to make the new
>> >  schematic and symbol library file formats the default file format
>> was
>> >  merged so builds should soon be available.  I wrote a detailed
>> >  description on the KiCad user forum[1] if you are interested in the
>> >  changes.  Please test it and report any bugs so I can get this
>> stable as
>> >  quickly as possible so we can start to add new features.
>> > 
>> >  Cheers,
>> > 
>> >  Wayne
>> > 
>> >  [1]:
>> > 
>> https://forum.kicad.info/t/kicad-nightly-v5-99-new-schematic-and-symbol-library-file-formats-are-now-the-default/22655
>> > 
>> >  ___
>> >  Mailing list: https://launchpad.net/~kicad-developers
>> >  Post to : kicad-developers@lists.launchpad.net
>> >  Unsubscribe : https://launchpad.net/~kicad-developers
>> >  More help   : https://help.launchpad.net/ListHelp
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> --
> Mark
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp