Re: [Kicad-developers] Eeschema Subsheets

[jp charras]

Le 29/03/2018 à 06:48, Andrey Kuznetsov a écrit :
> Hi Seth,
> 
> I thought subsheets didn't have any issues, at least my experience didn't 
> present any issues, could
> you please link to the bug you're working on?
> 
> Thanks

Yes, what is the bug to fix?

> 
> On Wed, Mar 28, 2018 at 7:34 PM, Seth Hillbrand  > wrote:
> 
> ​Hi All-
> 
> I'm working on a bug in renaming sub-sheets.  In testing the fix, I've 
> run up against a set of
> conflicting paradigms for how subsheets are handled.  I'd like some 
> feedback on how we expect to
> handle the subsheets.
> 
> Either: 
> 1) we treat them as actual objects such that renaming the sheet's 
> filename renames the file on
> the computer but keeps the contents unchanged​ or
> ​2) we treat them as links to the objects and renaming the filename​ of 
> the subsheet doesn't
> change the subsheet's file but instead just changes which file is 
> referenced.
> 
> Right now, we do both depending on whether there is an existing file and 
> more than one reference
> to the subsheet or not.  This is confusing as it is difficult to 
> determine when an operation
> will result in actually overwriting an existing file and thereby losing 
> data.

Complex hierarchies are tricky. Be *extremely* careful with them.

But what is the case that create losing data? I never saw that.

> 
> I'm inclined to make all actions (2).  This would allow a subsheet file 
> to become unlinked from
> the project if you change the filename referencing it but would not allow 
> overwriting subsheets
> on disk.
> 
> Does anyone feel strongly that (1) is the correct action?  
> 
> -S

(1) is incompatible with complex hierarchies.

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

[Wayne Stambaugh]

Most likely they will remain separate for re-usability purposes.  We
have users thate create modular schematics using sub-sheets that can be
used in multiple projects so embedding them would require an export tool.

On 3/29/2018 12:46 AM, Russell Oliver wrote:
> Will the new schematic file format embed subsheets? Or keep them in
> separate files on disk? 
> 
> On Thu, 29 Mar 2018 15:44 Andy Peters,  > wrote:
> 
> 
> 
> On Mar 28, 2018, at 7:34 PM, Seth Hillbrand
> mailto:seth.hillbr...@gmail.com>> wrote:
> 
>> ​Hi All-
>>
>> I'm working on a bug in renaming sub-sheets.  In testing the fix,
>> I've run up against a set of conflicting paradigms for how
>> subsheets are handled.  I'd like some feedback on how we expect to
>> handle the subsheets.
>>
>> Either: 
>> 1) we treat them as actual objects such that renaming the sheet's
>> filename renames the file on the computer but keeps the contents
>> unchanged​ or
>> ​2) we treat them as links to the objects and renaming the
>> filename​ of the subsheet doesn't change the subsheet's file but
>> instead just changes which file is referenced.
>>
>> Right now, we do both depending on whether there is an existing
>> file and more than one reference to the subsheet or not.  This is
>> confusing as it is difficult to determine when an operation will
>> result in actually overwriting an existing file and thereby losing
>> data.
>>
>> I'm inclined to make all actions (2).  This would allow a subsheet
>> file to become unlinked from the project if you change the
>> filename referencing it but would not allow overwriting subsheets
>> on disk.
>>
>> Does anyone feel strongly that (1) is the correct action?  
> 
> If the project is in source-code control, then Kicad renaming a file
> that’s under that control breaks things. 
> ___
> 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 Subsheets

[Wayne Stambaugh]

On 3/28/2018 10:34 PM, Seth Hillbrand wrote:
> ​Hi All-
> 
> I'm working on a bug in renaming sub-sheets.  In testing the fix, I've
> run up against a set of conflicting paradigms for how subsheets are
> handled.  I'd like some feedback on how we expect to handle the subsheets.
> 
> Either: 
> 1) we treat them as actual objects such that renaming the sheet's
> filename renames the file on the computer but keeps the contents
> unchanged​ or

Renaming the files could break sheets that are used in other projects
breaking re-usability so I would be reluctant to rename files.

> ​2) we treat them as links to the objects and renaming the filename​ of
> the subsheet doesn't change the subsheet's file but instead just changes
> which file is referenced.
> 
> Right now, we do both depending on whether there is an existing file and
> more than one reference to the subsheet or not.  This is confusing as it
> is difficult to determine when an operation will result in actually
> overwriting an existing file and thereby losing data.

The question is when do we allow the user to overwrite and existing
file.  The current logic seem reasonable to me.  What would happen if
the user edited the contents of a sheet and decided to change the sheet
file name to an existing file.  If you only allow linking, the users
edits will be replaced by the contents of the new file also resulting in
data loss.  I think the current logic handle both cases.

Do we not currently warn the user that an existing file will be
overwritten?  If not, we should.

> 
> I'm inclined to make all actions (2).  This would allow a subsheet file
> to become unlinked from the project if you change the filename
> referencing it but would not allow overwriting subsheets on disk.
> 
> Does anyone feel strongly that (1) is the correct action?  
> 
> -S
> 
> 
> 
> ___
> 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] wxWidgets

[Jeff Young]

Remember that compliment I threw wxWidget’s way a week or so ago regarding a 
menu to hide/show grid columns?

Yeah, well, it turned out it was the Mac native header control doing it.

I’ll implement the equivalent in GRID_TRICKS….
___
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 6.0 file format / data structure

[Jeff Young]

I reported a bug earlier about the difficult user model of symbol aliases.

One of the biggest problems is that what is owned by a parent symbol and what 
is owned by an alias is not cleanly presented in the GUI.  A nice way to solve 
that would be to remove the Description/Keywords/DocFilename from the Symbol 
Settings dialog and have all Symbol Fields be owned by the alias.  (That way 
the Symbol Settings dialog maps 1:1 with the parent symbol, and the Symbol 
Fields dialog maps 1:1 with the alias.)

Will the new file format support generic alias fields?  (We also need this to 
support SPICE.  As I understand it you can’t currently have a model associated 
with an alias — which is troublesome as you’d like your 15V regulator to behave 
differently than your 5V regulator.)___
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] wxWidgets

[Jon Evans]

I think we should measure the amount of time we spend fixing or extending
wxWidgets vs. doing anything else.
I'm not proposing that we should be doing anything else in particular at
this time, but I think it would be good data to have.

-Jon

On Thu, Mar 29, 2018 at 8:55 AM, Jeff Young  wrote:

> Remember that compliment I threw wxWidget’s way a week or so ago regarding
> a menu to hide/show grid columns?
>
> Yeah, well, it turned out it was the Mac native header control doing it.
>
> I’ll implement the equivalent in GRID_TRICKS….
> ___
> 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] wxWidgets

[Wayne Stambaugh]

Also, please keep in mind that one of the objectives of wxwidgets is to
stick with the stock look and behavior of platform controls as much as
possible.  Users on windows and linux will not expect this behavior even
though it might be a nice feature on macos.

On 3/29/2018 9:32 AM, Jon Evans wrote:
> I think we should measure the amount of time we spend fixing or
> extending wxWidgets vs. doing anything else.
> I'm not proposing that we should be doing anything else in particular at
> this time, but I think it would be good data to have.
> 
> -Jon
> 
> On Thu, Mar 29, 2018 at 8:55 AM, Jeff Young  > wrote:
> 
> Remember that compliment I threw wxWidget’s way a week or so ago
> regarding a menu to hide/show grid columns?
> 
> Yeah, well, it turned out it was the Mac native header control doing it.
> 
> I’ll implement the equivalent in GRID_TRICKS….
> ___
> 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] wxWidgets

[Jeff Young]

In this case we kind of need it as we don’t want to display a bunch of 
never-used field data columns, but everyone’s definition of “never-used” is 
likely to be different.

But I certainly agree in principle.


> On 29 Mar 2018, at 15:17, Wayne Stambaugh  wrote:
> 
> Also, please keep in mind that one of the objectives of wxwidgets is to
> stick with the stock look and behavior of platform controls as much as
> possible.  Users on windows and linux will not expect this behavior even
> though it might be a nice feature on macos.
> 
> On 3/29/2018 9:32 AM, Jon Evans wrote:
>> I think we should measure the amount of time we spend fixing or
>> extending wxWidgets vs. doing anything else.
>> I'm not proposing that we should be doing anything else in particular at
>> this time, but I think it would be good data to have.
>> 
>> -Jon
>> 
>> On Thu, Mar 29, 2018 at 8:55 AM, Jeff Young > > wrote:
>> 
>>Remember that compliment I threw wxWidget’s way a week or so ago
>>regarding a menu to hide/show grid columns?
>> 
>>Yeah, well, it turned out it was the Mac native header control doing it.
>> 
>>I’ll implement the equivalent in GRID_TRICKS….
>>___
>>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


___
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] wxWidgets

[Wayne Stambaugh]

On 3/29/2018 10:27 AM, Jeff Young wrote:
> In this case we kind of need it as we don’t want to display a bunch of 
> never-used field data columns, but everyone’s definition of “never-used” is 
> likely to be different.

If you have time, by all means implement this feature for windows and
linux users.  I'm sure once they discover it, they will appreciate it.

> 
> But I certainly agree in principle.

It's one of the things I love to hate about wxWidgets.  It does a pretty
good job of keeping the native UI look and feel but makes development
more difficult because if you are not careful, the platform differences
will bite you.

> 
> 
>> On 29 Mar 2018, at 15:17, Wayne Stambaugh  wrote:
>>
>> Also, please keep in mind that one of the objectives of wxwidgets is to
>> stick with the stock look and behavior of platform controls as much as
>> possible.  Users on windows and linux will not expect this behavior even
>> though it might be a nice feature on macos.
>>
>> On 3/29/2018 9:32 AM, Jon Evans wrote:
>>> I think we should measure the amount of time we spend fixing or
>>> extending wxWidgets vs. doing anything else.
>>> I'm not proposing that we should be doing anything else in particular at
>>> this time, but I think it would be good data to have.
>>>
>>> -Jon
>>>
>>> On Thu, Mar 29, 2018 at 8:55 AM, Jeff Young >> > wrote:
>>>
>>>Remember that compliment I threw wxWidget’s way a week or so ago
>>>regarding a menu to hide/show grid columns?
>>>
>>>Yeah, well, it turned out it was the Mac native header control doing it.
>>>
>>>I’ll implement the equivalent in GRID_TRICKS….
>>>___
>>>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
> 

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

[Seth Hillbrand]

Thanks for the feedback.  It helps me get my head around how the subsheets
are meant to work.

Here is one of the bugs:

1) Take the attached project and unzip into KiCad.
2) Open the schematic and you will find a schematic with 5 subsheets
referencing 3 subsheet files.
  - Each subsheet file has a label with its associated file name.  So A.sch
contains "A".
3) Rename the file for Sheet B to "A.sch"
  - This works as expected for linking.  There is a warning, you replace
the contents of B with the contents A.sch.
4) Rename the file for Sheet B again, this time to "D.sch"
  - You get a warning about the sheet using shared data in a complex
hierarchy.  Click "OK"

At this point, Eeschema creates "D.sch" using the data from "A.sch".  If I
understand Wayne correctly, the mixing of these metaphors is fine.
Renaming a sheet filename to an existing filename replaces the sheet's
current contents with the existing file contents but renaming a sheet
filename to a non-existing filename will create a new copy of the current
contents.

5) Now, open the subsheet "B", notice that it has the label "A".  Edit the
contents to be "D" and save.

The bug here is that if you now open the original subsheet A, its contents
have also been changed to "D".  But only until you close and re-open the
project.  At that point, it is back to "A".  I'll deal with this bug but
leave the copying/linking behavior as is unless people feel otherwise.  It
confused me but I think I can clarify it in the dialog text.

-S

Hmm... Apparently Gmail has started blocking my attachments.  So here is
the zipped project
https://drive.google.com/file/d/1W9aEzpx_mh4sS2ebtAOPQrw5QeuJrlKK/view?usp=sharing


2018-03-29 5:04 GMT-07:00 Wayne Stambaugh :

> On 3/28/2018 10:34 PM, Seth Hillbrand wrote:
> > ​Hi All-
> >
> > I'm working on a bug in renaming sub-sheets.  In testing the fix, I've
> > run up against a set of conflicting paradigms for how subsheets are
> > handled.  I'd like some feedback on how we expect to handle the
> subsheets.
> >
> > Either:
> > 1) we treat them as actual objects such that renaming the sheet's
> > filename renames the file on the computer but keeps the contents
> > unchanged​ or
>
> Renaming the files could break sheets that are used in other projects
> breaking re-usability so I would be reluctant to rename files.
>
> > ​2) we treat them as links to the objects and renaming the filename​ of
> > the subsheet doesn't change the subsheet's file but instead just changes
> > which file is referenced.
> >
> > Right now, we do both depending on whether there is an existing file and
> > more than one reference to the subsheet or not.  This is confusing as it
> > is difficult to determine when an operation will result in actually
> > overwriting an existing file and thereby losing data.
>
> The question is when do we allow the user to overwrite and existing
> file.  The current logic seem reasonable to me.  What would happen if
> the user edited the contents of a sheet and decided to change the sheet
> file name to an existing file.  If you only allow linking, the users
> edits will be replaced by the contents of the new file also resulting in
> data loss.  I think the current logic handle both cases.
>
> Do we not currently warn the user that an existing file will be
> overwritten?  If not, we should.
>
> >
> > I'm inclined to make all actions (2).  This would allow a subsheet file
> > to become unlinked from the project if you change the filename
> > referencing it but would not allow overwriting subsheets on disk.
> >
> > Does anyone feel strongly that (1) is the correct action?
> >
> > -S
> >
> >
> >
> > ___
> > 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

[Kicad-developers] Build failure w.r.t. wxDateTime

[Thomas Figueroa]

I recently started getting a "Call of overloaded 'wxDateTime(timestamp_t&)' is 
ambiguous" compilation failure
in class_module.cpp line 573. I modified it to static_cast 
m_LastEditTime, but I'm not sure that is
what is intended here. This occurs both on MSVC and MSYS2 builds.
(MSYS2 build here: http://darine.hogyros.de:8080/job/windows-kicad-msys2/244/)

Thomas
___
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 Subsheets

[jp charras]

Le 29/03/2018 à 18:04, Seth Hillbrand a écrit :
> Thanks for the feedback.  It helps me get my head around how the subsheets 
> are meant to work.
> 
> Here is one of the bugs:
> 
> 1) Take the attached project and unzip into KiCad.  
> 2) Open the schematic and you will find a schematic with 5 subsheets 
> referencing 3 subsheet files.
>   - Each subsheet file has a label with its associated file name.  So A.sch 
> contains "A".
> 3) Rename the file for Sheet B to "A.sch"
>   - This works as expected for linking.  There is a warning, you replace the 
> contents of B with the
> contents A.sch.
> 4) Rename the file for Sheet B again, this time to "D.sch"
>   - You get a warning about the sheet using shared data in a complex 
> hierarchy.  Click "OK"
> 
> At this point, Eeschema creates "D.sch" using the data from "A.sch".  If I 
> understand Wayne
> correctly, the mixing of these metaphors is fine.  Renaming a sheet filename 
> to an existing filename
> replaces the sheet's current contents with the existing file contents but 
> renaming a sheet filename
> to a non-existing filename will create a new copy of the current contents.
> 
> 5) Now, open the subsheet "B", notice that it has the label "A".  Edit the 
> contents to be "D" and save.
> 
> The bug here is that if you now open the original subsheet A, its contents 
> have also been changed to
> "D".  But only until you close and re-open the project.  At that point, it is 
> back to "A".  I'll
> deal with this bug but leave the copying/linking behavior as is unless people 
> feel otherwise.  It
> confused me but I think I can clarify it in the dialog text.
> 
> -S

Hi Seth,

I tried that, and I did not noticed your issue.
All sheets are OK, and the subsheet A.sch was not modified.

-- 
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 6.0 file format / data structure

[Simon Richter]

Hi,

On 29.03.2018 15:02, Jeff Young wrote:

> (That way the Symbol
> Settings dialog maps 1:1 with the parent symbol, and the Symbol Fields
> dialog maps 1:1 with the alias.)

I wonder if it would make sense to go the opposite direction, and
introduce an inheritance hierarchy. Symbols can inherit from other
symbols, define or override attributes and also add new attributes that
may in turn be abstract.

So for example, a "generic diode" would

 - provide a diode symbol as vectors
 - provide a SPICE type of D
 - provide the reference prefix "D"
 - define abstract properties for forward voltage, maximum current etc.

Specific diodes would inherit that, provide the forward voltage and
maximum current and name of the correct SPICE model, and would also map
the pins in the drawing.

Components that use the same graphical representation can then be easily
exchanged without having to adjust the schematic, which would be useful
e.g. when exchanging a single-unit device for a multi-unit one.

   Simon



signature.asc
Description: OpenPGP digital signature
___
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 6.0 file format / data structure

[Wayne Stambaugh]

On 3/29/2018 12:30 PM, Simon Richter wrote:
> Hi,
> 
> On 29.03.2018 15:02, Jeff Young wrote:
> 
>> (That way the Symbol
>> Settings dialog maps 1:1 with the parent symbol, and the Symbol Fields
>> dialog maps 1:1 with the alias.)
> 
> I wonder if it would make sense to go the opposite direction, and
> introduce an inheritance hierarchy. Symbols can inherit from other
> symbols, define or override attributes and also add new attributes that
> may in turn be abstract.
> 
> So for example, a "generic diode" would
> 
>  - provide a diode symbol as vectors
>  - provide a SPICE type of D
>  - provide the reference prefix "D"
>  - define abstract properties for forward voltage, maximum current etc.
> 
> Specific diodes would inherit that, provide the forward voltage and
> maximum current and name of the correct SPICE model, and would also map
> the pins in the drawing.
> 
> Components that use the same graphical representation can then be easily
> exchanged without having to adjust the schematic, which would be useful
> e.g. when exchanging a single-unit device for a multi-unit one.
> 
>Simon

The new symbol library file format uses inheritance.  I don't have the
preliminary file format document with me at work.  When I get home this
evening I will post both the preliminary symbol library and schematic
file format documents to the mailing list for those of you who have not
seen them yet.  I do not want to open the discussion on this just yet.
We need stay focused on the v5 release so please do not comment on it.
I will make an RFC before I begin working on the new file format.

Cheers,

Wayne

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

[Seth Hillbrand]

Hi JP-

That's correct, A.sch does not get modified.  Only the contents shown are
changed.

Here is a video showing the behavior:
https://drive.google.com/file/d/1LnG2khusuEal3E2I8-NPEZ-A9dA_ag8O/view?usp=sharing

If you don't see the same behavior, perhaps this is linux-only?

-S

2018-03-29 9:23 GMT-07:00 jp charras :

> Le 29/03/2018 à 18:04, Seth Hillbrand a écrit :
> > Thanks for the feedback.  It helps me get my head around how the
> subsheets are meant to work.
> >
> > Here is one of the bugs:
> >
> > 1) Take the attached project and unzip into KiCad.
> > 2) Open the schematic and you will find a schematic with 5 subsheets
> referencing 3 subsheet files.
> >   - Each subsheet file has a label with its associated file name.  So
> A.sch contains "A".
> > 3) Rename the file for Sheet B to "A.sch"
> >   - This works as expected for linking.  There is a warning, you replace
> the contents of B with the
> > contents A.sch.
> > 4) Rename the file for Sheet B again, this time to "D.sch"
> >   - You get a warning about the sheet using shared data in a complex
> hierarchy.  Click "OK"
> >
> > At this point, Eeschema creates "D.sch" using the data from "A.sch".  If
> I understand Wayne
> > correctly, the mixing of these metaphors is fine.  Renaming a sheet
> filename to an existing filename
> > replaces the sheet's current contents with the existing file contents
> but renaming a sheet filename
> > to a non-existing filename will create a new copy of the current
> contents.
> >
> > 5) Now, open the subsheet "B", notice that it has the label "A".  Edit
> the contents to be "D" and save.
> >
> > The bug here is that if you now open the original subsheet A, its
> contents have also been changed to
> > "D".  But only until you close and re-open the project.  At that point,
> it is back to "A".  I'll
> > deal with this bug but leave the copying/linking behavior as is unless
> people feel otherwise.  It
> > confused me but I think I can clarify it in the dialog text.
> >
> > -S
>
> Hi Seth,
>
> I tried that, and I did not noticed your issue.
> All sheets are OK, and the subsheet A.sch was not modified.
>
> --
> 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 6.0 file format / data structure

[Ouabache Designworks]

On Thu, Mar 29, 2018 at 9:30 AM, Simon Richter 
wrote:

> Hi,
>
> On 29.03.2018 15:02, Jeff Young wrote:
>
> > (That way the Symbol
> > Settings dialog maps 1:1 with the parent symbol, and the Symbol Fields
> > dialog maps 1:1 with the alias.)
>
> I wonder if it would make sense to go the opposite direction, and
> introduce an inheritance hierarchy. Symbols can inherit from other
> symbols, define or override attributes and also add new attributes that
> may in turn be abstract.
>
> So for example, a "generic diode" would
>
>  - provide a diode symbol as vectors
>  - provide a SPICE type of D
>  - provide the reference prefix "D"
>  - define abstract properties for forward voltage, maximum current etc.
>
> Specific diodes would inherit that, provide the forward voltage and
> maximum current and name of the correct SPICE model, and would also map
> the pins in the drawing.
>
> Components that use the same graphical representation can then be easily
> exchanged without having to adjust the schematic, which would be useful
> e.g. when exchanging a single-unit device for a multi-unit one.
>
>Simon
>
>
This is a good idea. Give a symbol the ability to link to any other child
symbol. You instantiate the
parent and it provides its name and attributes before pulling in the
attributes from the children. Anything
already defined is ignored but all other attributes are added.

So I create a symbol for a specific diode that links to a generic diode
that is instantiated on my schematic. All
I do is change the component name from generic to specific and I get all
the new info from the specific but still
retain everything from the generic that wasn't overridden(including the
graphic and all the pins).


I can create a generic NAND gate and instantiate that on my schematic. I
then create a 74LS00 component that
has a graphic for power and ground along with four links back to my NAND
gate. When I package my gates it keeps
the NAND graphic but adds the slot and pin swap info from the 74LS00 symbol.

I can even create a generic 7400 symbol and have specific
74LS00,74HC00,74ACT00 etc symbols link to it.

Hierarchy is your friend.

John Eaton
___
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 Subsheets

[Andrey Kuznetsov]

Hi Seth,

OK, yeah that makes it clear, Subsheet A should not have shown contents of
subsheet D since subsheet D was created and or supposed to have it's own
contents.

On Thu, Mar 29, 2018 at 10:00 AM, Seth Hillbrand 
wrote:

> Hi JP-
>
> That's correct, A.sch does not get modified.  Only the contents shown are
> changed.
>
> Here is a video showing the behavior:
> https://drive.google.com/file/d/1LnG2khusuEal3E2I8-NPEZ-
> A9dA_ag8O/view?usp=sharing
>
> If you don't see the same behavior, perhaps this is linux-only?
>
> -S
>
> 2018-03-29 9:23 GMT-07:00 jp charras :
>
>> Le 29/03/2018 à 18:04, Seth Hillbrand a écrit :
>> > Thanks for the feedback.  It helps me get my head around how the
>> subsheets are meant to work.
>> >
>> > Here is one of the bugs:
>> >
>> > 1) Take the attached project and unzip into KiCad.
>> > 2) Open the schematic and you will find a schematic with 5 subsheets
>> referencing 3 subsheet files.
>> >   - Each subsheet file has a label with its associated file name.  So
>> A.sch contains "A".
>> > 3) Rename the file for Sheet B to "A.sch"
>> >   - This works as expected for linking.  There is a warning, you
>> replace the contents of B with the
>> > contents A.sch.
>> > 4) Rename the file for Sheet B again, this time to "D.sch"
>> >   - You get a warning about the sheet using shared data in a complex
>> hierarchy.  Click "OK"
>> >
>> > At this point, Eeschema creates "D.sch" using the data from "A.sch".
>> If I understand Wayne
>> > correctly, the mixing of these metaphors is fine.  Renaming a sheet
>> filename to an existing filename
>> > replaces the sheet's current contents with the existing file contents
>> but renaming a sheet filename
>> > to a non-existing filename will create a new copy of the current
>> contents.
>> >
>> > 5) Now, open the subsheet "B", notice that it has the label "A".  Edit
>> the contents to be "D" and save.
>> >
>> > The bug here is that if you now open the original subsheet A, its
>> contents have also been changed to
>> > "D".  But only until you close and re-open the project.  At that point,
>> it is back to "A".  I'll
>> > deal with this bug but leave the copying/linking behavior as is unless
>> people feel otherwise.  It
>> > confused me but I think I can clarify it in the dialog text.
>> >
>> > -S
>>
>> Hi Seth,
>>
>> I tried that, and I did not noticed your issue.
>> All sheets are OK, and the subsheet A.sch was not modified.
>>
>> --
>> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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 Subsheets

[jp charras]

Le 29/03/2018 à 19:00, Seth Hillbrand a écrit :
> Hi JP-
> 
> That's correct, A.sch does not get modified.  Only the contents shown are 
> changed.
> 
> Here is a video showing the behavior:
> https://drive.google.com/file/d/1LnG2khusuEal3E2I8-NPEZ-A9dA_ag8O/view?usp=sharing
> 
> If you don't see the same behavior, perhaps this is linux-only?
> 
> -S
> 

After tests, I confirm:
It happens on Linux, but not on Windows.
Really strange.


> 2018-03-29 9:23 GMT-07:00 jp charras  >:
> 
> Le 29/03/2018 à 18:04, Seth Hillbrand a écrit :
> > Thanks for the feedback.  It helps me get my head around how the 
> subsheets are meant to work.
> >
> > Here is one of the bugs:
> >
> > 1) Take the attached project and unzip into KiCad.  
> > 2) Open the schematic and you will find a schematic with 5 subsheets 
> referencing 3 subsheet files.
> >   - Each subsheet file has a label with its associated file name.  So 
> A.sch contains "A".
> > 3) Rename the file for Sheet B to "A.sch"
> >   - This works as expected for linking.  There is a warning, you 
> replace the contents of B with the
> > contents A.sch.
> > 4) Rename the file for Sheet B again, this time to "D.sch"
> >   - You get a warning about the sheet using shared data in a complex 
> hierarchy.  Click "OK"
> >
> > At this point, Eeschema creates "D.sch" using the data from "A.sch".  
> If I understand Wayne
> > correctly, the mixing of these metaphors is fine.  Renaming a sheet 
> filename to an existing filename
> > replaces the sheet's current contents with the existing file contents 
> but renaming a sheet filename
> > to a non-existing filename will create a new copy of the current 
> contents.
> >
> > 5) Now, open the subsheet "B", notice that it has the label "A".  Edit 
> the contents to be "D" and save.
> >
> > The bug here is that if you now open the original subsheet A, its 
> contents have also been changed to
> > "D".  But only until you close and re-open the project.  At that point, 
> it is back to "A".  I'll
> > deal with this bug but leave the copying/linking behavior as is unless 
> people feel otherwise.  It
> > confused me but I think I can clarify it in the dialog text.
> >
> > -S
> 
> Hi Seth,
> 
> I tried that, and I did not noticed your issue.
> All sheets are OK, and the subsheet A.sch was not modified.
> 
> --
> 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 
> 
> 
> 


-- 
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] Build failure w.r.t. wxDateTime

[Seth Hillbrand]

Hi Thomas-

Your analysis is correct.  m_LastEditTime was recently changed to
timestamp_t but holds time_t information and (for now) can be safely cast.

I've pushed an update, let me know if it's still problematic.

-S

(Sorry for the double-email.)

2018-03-29 9:14 GMT-07:00 Thomas Figueroa :

> I recently started getting a “Call of overloaded
> 'wxDateTime(timestamp_t&)' is ambiguous” compilation failure
>
> in class_module.cpp line 573. I modified it to static_cast
> m_LastEditTime, but I’m not sure that is
>
> what is intended here. This occurs both on MSVC and MSYS2 builds.
>
> (MSYS2 build here: http://darine.hogyros.de:8080/
> job/windows-kicad-msys2/244/)
>
>
>
> Thomas
>
> ___
> 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 6.0 file format / data structure

[Wayne Stambaugh]

As promised, attached are the schematic and symbol file library file 
formats.  Please note, they are preliminary and need some updates. 
There was a pretty in depth discussion a while back on the mailing list 
which you should take a look at so we do not rehash the same discussion 
unless there is a reason.


Cheers,

Wayne

On 03/29/2018 12:30 PM, Simon Richter wrote:

Hi,

On 29.03.2018 15:02, Jeff Young wrote:


(That way the Symbol
Settings dialog maps 1:1 with the parent symbol, and the Symbol Fields
dialog maps 1:1 with the alias.)


I wonder if it would make sense to go the opposite direction, and
introduce an inheritance hierarchy. Symbols can inherit from other
symbols, define or override attributes and also add new attributes that
may in turn be abstract.

So for example, a "generic diode" would

  - provide a diode symbol as vectors
  - provide a SPICE type of D
  - provide the reference prefix "D"
  - define abstract properties for forward voltage, maximum current etc.

Specific diodes would inherit that, provide the forward voltage and
maximum current and name of the correct SPICE model, and would also map
the pins in the drawing.

Components that use the same graphical representation can then be easily
exchanged without having to adjust the schematic, which would be useful
e.g. when exchanging a single-unit device for a multi-unit one.

Simon



___
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



eeschema_schematic_sexpr_file_format_EN.odt
Description: application/vnd.oasis.opendocument.text


eeschema_symbol_library_sexpr_format_EN.odt
Description: application/vnd.oasis.opendocument.text
___
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 6.0 file format / data structure

[Andy Peters]

> On Mar 29, 2018, at 3:32 PM, Wayne Stambaugh  wrote:
> 
> As promised, attached are the schematic and symbol file library file formats. 
>  Please note, they are preliminary and need some updates. There was a pretty 
> in depth discussion a while back on the mailing list which you should take a 
> look at so we do not rehash the same discussion unless there is a reason.

One quick comment about the “atomic parts” section in the library format 
document. It calls out 

 (footprint “14-SOP”)

Should we assume the footprint must also include the library from which that 
footprint is pulled? That is, this line would more likely be:

(footprint “Package_SOP:14-SOP”)

and of course Package_SOP has to be in the user’s footprint library table.

thanks,
-a
___
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] [PATCH] Don't create an extra segment at the end of closed SHAPE_LINE_CHAIN

[Jon Evans]

Hi Orson,

I decided to just fix it in POLYGON_GEOM_MANAGER for now as it is way less
risky.  I was worried we don't have a good way to test all the places that
use SHAPE_LINE_CHAIN and don't want to add risk for RC2.

Maybe we should revisit this after 5.0 release, I think fixing this could
simplify some code in places where SHAPE_LINE_CHAIN is used because there
no longer be this special case to check for.

-Jon

On Mon, Mar 26, 2018 at 6:58 AM, Maciej Sumiński 
wrote:

> Hi Jon,
>
> If we decide to handle this special case, then we need to account for
> the point count as well. Otherwise it may lead to situations when the
> number of points is higher than the number of segments.
>
> Please see the attached patch (particularly 0002). I think these changes
> might be committed after a short test period. If we want to go the safe,
> but not so elegant way, then perhaps a simple condition could be added
> to POLYGON_GEOM_MANAGER::IsSelfIntersecting().
>
> Cheers,
> Orson
>
> On 03/25/2018 04:07 AM, Jon Evans wrote:
> > Hi all (but especially Orson),
> >
> > I wanted to fix the issue Bernhard raised here:
> > https://bugs.launchpad.net/kicad/+bug/1751654/comments/7
> >
> > I dug in to it a bit and found out
> > that SHAPE_LINE_CHAIN::SelfIntersecting() doesn't work right when
> polygons
> > are actually closed (i.e. the last point is the same as the first) and
> when
> > m_closed is set to true.
> >
> > The attached patch fixes this by only generating a closing segment when
> the
> > last point isn't the same as the first point.  It fixes the issue with
> the
> > self-intersection warning showing up even when you aren't yet
> intersecting
> > (i.e. when the last point is the same as the first), and I didn't notice
> > any obvious other issues, but maybe you can double-check that changing
> the
> > behavior of SegmentCount() won't have any strange side-effects.
> >
> > Thanks,
> > -Jon
> >
>
>
___
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