Re: [Kicad-developers] [RFC] Symbol library file format

[kristoffer Ödmark]

I agree with Carsten Here,

The same way the footprints are not part of the symbol, the same way 
SPICE models should be defined separate.


I would rather have a new atomic file-format or storage format, so one 
could actually send a complete part in an easy way, that would include 
3D-Files, SPICE data, symbol and footprints, and it would also mean that 
one could do the mapping to pins in that directory or file instead.


And since the discussion about adding a manufacturer part number to 
libraries went nowhere, I cannot see how adding a SPICE model would fit 
here, and if SPICE models are added. Well then I suggest we add 3D-Files 
and Footprints as well, no use in half-assing it.


- Kristoffer

On 2019-01-02 11:27, Thomas Pointhuber wrote:

Hi Carsten,

Unfortunate, I don't think the reality works like that. While my
experience with SPICE is quite sparse (especially inside KiCad), I do
NOT think in this case about open and free spice model for IC's. Not
everyone uses the KiCad supplied libraries but their own, and simple
spice stuff like putting some resistors together for an R-Network can be
done in the official as well.

Fully separate spice out of the symbol would not work anyway because
from what I noticed spice pin does not map to symbol pin in many cases.
You need to link that somewhere anyway. I'm heavily in favor of
simplifying handling of simulation for users. Integrating this into one
file would be less error-prone than separating simulation into multiple
additional files. Including external SPICE models would then be an
option, but not necessary.

A modular approach where SPICE is only one of many possibilities is in
my favor, but in a different way than you proposed (integrated in the
symbol). There is for example the topic of digital simulation, which
would require different types of models. We should at least think about
it so it can be integrated later in a nice way.

Regards,
Thomas

Am 02.01.19 um 11:05 schrieb Carsten Schoenert:

Hello Thomas,

Am 02.01.19 um 10:39 schrieb Thomas Pointhuber:

* I do not see anything related to SPICE in this document. I would vote
to add it including the possibility to embedded spice models
(BASE64-encoded) into the symbol itself.

I disagree on that.
Please do not mix two different main purposes and add more complexity.

Schematic simulation is a add-on, not a primary key feature of a symbol
format or within Eeeschema.

Including such stuff into a schematic symbol make it harder to maintain
the symbols in along term as you always need to touch the symbol no
matter what peace need a update. But the (new extended) symbol format
can get of course a new field of course for a referenced file to look
at. Like similar done for associated footprints. Add a new environment
variable like SPICE_MODEL_DIR to add a default folder.

Currently it's not clear how a open and free spice working model can
look like, I really suggest to not create a own world for spice models.
Make it modular so work needs to be done more than needed.

I also suggest to get in touch with Holger from the ngspice project
about his thoughts and possible suggestions on this topic.



___
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] [RFC] Symbol library file format

[kristoffer Ödmark]

I like the idea of using something as Protobuf and I agree fully with 
the benefits, especially since one can add/remove fields with minimal 
impact.


Basically the S-expression system used now is looking very much like a 
reinvented XML to me anyway, and storing protobuf-defined stuff as XML 
or similar seems actually nice.
There is one catch, and that is that we have to support opening a newer 
file, in an old software, and then store it again, without losing data 
that the software is not aware of. Or implement a way of not being able 
to store values in older software, when they open something newer.


There is also a middle way here, and that is to actually implement a 
Protobuf to S-Expression decoder/encoder, with the real benefit of 
actually defining fields in a modern well-known way, where the 
specification and implementetation does not have to manually be synced 
in code, comments, and a google doc. I have yet to see anything actually 
stay synchronized in such a manner over time, and many bugs manifest 
themself in these synchronization attempts. Anyway to avoid having to 
change the file-format another time, or add extra files to the side, I 
think that using an IDF is great next-step, mostly since the tooling, 
libraries and workflows for these are better defined.


But to be honest, I have a hard time understanding why we have to stick 
to the KiCad S-Expression, when there are quite readable text-formats 
that are widely supported already.


I know the requirement for the file format is readability, but I have 
yet to find and editor that actually understands the KiCad S-Expression 
(I have not searched extensively), but JSON,XML,YAML are usually read 
just fine, with syntax highlighting out of box. And an IDF would make 
these discussions quite reduntant, since changing file formats would be 
a minimal change in code, and not as now, where it is actually quite 
time-consuming.


- Kristoffer

On 2019-01-02 01:37, Andrew Lutsenko wrote:

Hi Wayne,

I would like to take this opportunity to do an elevator pitch for idea 
of using one of IDL languages widely accepted in the industry like 
Apache Thrift or Google Protobufs to define formats in KiCad.

There are few large benefits in favor of using such languages:

1. They are self documenting. No more keeping a google doc in sync 
with sources.
2. They are easily extensible. Just add a field, old parsers will 
ignore it, new ones will pick it up. Need to deprecate a field? Just 
add it's ID to reserved list to never reuse it again.
3. They have code generators for pretty much all commonly used 
languages. That means anyone can pick KiCad file and just parse it in 
Java/Go/Haskell or whatever language they fancy without porting over 
s-expressions library or meticulously studying the file format doc. 
This opens lot's of possibilities for third party tools to be added to 
KiCad ecosystem. Writing a web viewer for schematic/pcb would be a 
piece of cake for example.


Other probably less impactful benefits:
4. Easy to serialize/encode in multiple formats. Need to send data 
over network in compact form? No problem, just serialize using compact 
binary protocol. Need to store in text file? just use text encoder.
5. Code generators will reduce amount of boilerplate in KiCad source. 
Only actual application logic needs to be added on top of generated 
data objects.


I have personally worked extensively with both Thrift and Protobufs, I 
think for KICad use case proto is better fit. Thrift has a lot more 
library support for client/server RPC logic and defining RPCs is core 
part of the language but we don't need any of that (at least for now). 
Proto has all of that as extensions but it's core is just definition 
of data types and it has better support for plain text format.

Here are docs for both:
https://developers.google.com/protocol-buffers/
https://thrift.apache.org/tutorial/

Let me know if any of that sounds interesting and if you have any 
questions. I think this is worth investing time into and I'm willing 
to help if needed.


Regards,
Andrew

On Tue, Jan 1, 2019 at 11:59 AM Wayne Stambaugh > wrote:


I have updated and published the symbol file format[1] for comment.
Hopefully there isn't too much to change.  The only thing to really
finalize is the internal units.  The initial concept was unitless but
the more I think about it and discuss with other developers, it makes
more sense to use units for the following reasons:

1. It's easier to visualize in your head how the symbols on a
given page
size will layout.

2. Converting from other file formats (Eagle, Altium, etc) will be
easier since most if not all of them have a defined unit.

I'm thinking 10u (or possibly 100u) will make a good internal units
value.  Once we nail down the units, I will update the file format
document accordingly.

Please keep in mind that this is the symbol library file 

Re: [Kicad-developers] 5.1 preview

[kristoffer ödmark]

On Fri, 2018-07-13 at 11:33 -0600, Jeff Young wrote:
> Hi Kristoffer,
> 
> What platform are you on?

Ill just paste my entire build info :)

Application: kicad
Version: (5.0.0-rc3-dev-82-g0bf877f83), release build
Libraries:
wxWidgets 3.0.4
libcurl/7.60.0 OpenSSL/1.1.0h zlib/1.2.11 libidn2/2.0.5
libpsl/0.20.2 (+libidn2/2.0.4) nghttp2/1.32.0
Platform: Linux 4.16.18-1-MANJARO x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+
2.24
Boost: 1.67.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.60.0
Compiler: GCC 8.1.1 with C++ ABI 1012

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_ACTION_MENU=OFF
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON
> 
> 
> Right-click the footprint cell or datasheet cell to get the footprint
> picker or open datasheet.   (These need to be made more discoverable,
> but I don’t have any good ideas how yet.)

Hmm, yeah I tried that, doesnt seemt to be working for me, I was
suspecting It was something hidden like that, but nothing pops up when
i right click. The old approach with a greyed out button for the
different fields wasnt all that bad was it? 

I would really like to be able to add python scripts to the other
fields that dont have a special button. But that is kinda out of scope
:)

> 
> The original actually had it inverted, but it felt better with the
> more-often-edited stuff on top.  In any case, it’s easy enough to
> change.

For me it always feel better with any kind of list taking up the entire
 height of the window, and having the boxes of options on the side of
them. 

However I really like the unifrom style you managed to get in the UI
with a similar layout of all the dialogs. Not just a big fan of the
particular style, but for me the uniformity is more important, it kinda
makes one familiar with the whole program quicker. 

Let me know If you want me to test anything, 
I dont really have a lot of time on my hands, but some testing and
feedback I am happy to help out with.

- Kristoffer

> 
> Cheers,
> Jeff.
> 
> > 
> > Thanks for your efforts!
> > 
> > - Kristoffer
> > 
> > On Thu, 2018-07-12 at 22:19 -0600, Jeff Young wrote:
> > > Thanks to some great help from Nick, I believe my 6.0 (aka 5.1)
> > > tree
> > > should compile cleanly on other platforms if any of you want to
> > > try
> > > it out.
> > > 
> > > https://git.launchpad.net/~jeyjey/kicad/?h=6.0  > > hpad
> > > .net/~jeyjey/kicad/?h=6.0>
> > > 
> > > Cheers,
> > > Jeff.
> > > ___
> > > 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] 5.1 preview

[kristoffer ödmark]

Hey! Nice job!

I am not really sure what is the difference everywhere but i will give
my opinion on what i noticed :)


Good:
   - Finally i can read the status text on the bottom thank you!
   - The BOM plugin menu is much nicer
   - Text and graphics view in pcbnew, very nice

Bad:
   - Crashes on trying to edit outlines in pcbnew.
   - Its much harder to change the footprints of components in eeschema
now, also i miss the open datasheet button etc. 
   - I dont really like the design choice of having a list above all  
the buttons, makes for awkward scrolling in the cases where i have many
deifned fields

Thanks for your efforts!

- Kristoffer

On Thu, 2018-07-12 at 22:19 -0600, Jeff Young wrote:
> Thanks to some great help from Nick, I believe my 6.0 (aka 5.1) tree
> should compile cleanly on other platforms if any of you want to try
> it out.
> 
> https://git.launchpad.net/~jeyjey/kicad/?h=6.0  .net/~jeyjey/kicad/?h=6.0>
> 
> Cheers,
> Jeff.
> ___
> 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] More default fields in schematic

[kristoffer ödmark]

I agree with all of these points and I am very happy that there now is
a plan! There is one thing I would like clarified for this though. 

Would It be okay to add the suggested template fields as a starting
point for users? Ofcourse without the "silent" adding to symbols and
netlists and boms.

On Tue, 2018-05-29 at 15:55 -0400, Wayne Stambaugh wrote:
> v5 point release:
> 
> Remove the "silent" add template fields behavior from the symbol
> properties dialog.
> 
> Add a button to the symbol properties dialog to add the template
> fields
> to the symbol.
> 
> Add an option in the template field option panel to add the template
> fields to symbols as they are added to the schematic.
> 
> Add a menu command and possibly a toolbar button to add the template
> fields to all symbols in the schematic.
> 
> Any adding of template fields assumes that any duplicate existing
> symbol
> fields will not be overwritten.
> 
> During v6 development, I would like to see the storage of the
> template
> fields moved from the Eeschema config file to the default project
> file.
> This would allow users to define project specific template fields.  I
> could see this being useful for consultants who lay out boards for
> multiple customers with differing BOM requirements.




___
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] More default fields in schematic

[Kristoffer Ödmark]

Yes, the only way to make them translateable is to hard-code these and
other values into kicad, same as the existing hard-coded fields.

That would be a good solution for me, having similar to layers a large set
of predefined fields, being able to name them and enable them at will. But
storing them in the files as the hard-codes values.

This means a large change to the code though, at least if we must have the
enable/disable feature for this, along with creating new custom fields. Not
even the PCB editor has this yet.

Also, I don't think any of the bom exporter plug-ins are localized, and at
least one of them completely ignores custom fields and adds it own instead,
regardless of what is in the file.

Meanwhile my patch does not affect existing installations, does not change
any BOM, and does not enforce anything and comes in at a whooping 3-4 lines
of patch in a single file. It will however add 3 lines to two dialogs
(field editor and symbol editor) for new installations, which can be
removed, with 6 clicks of the mouse in eeschema.

- Kristoffer

On Tue, May 22, 2018, 20:01 Jeff Young  wrote:

> I can confirm that default fields only get added when the symbol is edited
> AND the default field’s value is non-empty.  So it doesn’t seem to me that
> the proposed patch would pollute existing BOMs.  Or am I missing something?
>
> Seth’s comment regarding localisation is an issue, though, as we don’t
> currently translate default fields.
>
> > On 22 May 2018, at 17:53, Wayne Stambaugh  wrote:
> >
> > On 5/22/2018 12:43 PM, Jeff Young wrote:
> >>> It should output all fields defined in schematic symbols regardless if
> >>> each optional field is defined in every symbol.  If they are outputting
> >>> anything other than that, I would consider this a bug.
> >>
> >> I had trouble parsing this.  Are you saying that the list of output
> fields should be the union of all fields which have a value somewhere (but
> excluding default fields which are uniformly blank)?
> >
> > Yes.  It should be the equivalent of a logical OR.  If a field exists in
> > a single symbol, it should get added to the BOM.
> >
> >>
> >> As it stands in 5.0, default fields don’t get pushed to symbols unless
> the symbol is edited.  At that point I’m not sure if they’re all pushed, or
> only those with values.
> >>
> >
> > It used to be that fields only get saved when they are added to the
> > symbol using the edit symbol properties dialog.  That code has changed a
> > lot since it was originally written so I cannot confirm this.
>
>
___
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] More default fields in schematic

[kristoffer ödmark]

My updated patch forgot to add the files before doing the --amend.

So it only updated the commit message. Here is the real file

On Tue, 2018-05-22 at 07:52 -0500, Ben Hest wrote:
> From a Digi-Key KiCad library standpoint, as we're still in beta, I
> would
> gladly change the fields to whatever would be decided.  Uniformity
> for
> plugins use would definitely be an advantage.
> 
> -Ben
> 
> On Tue, May 22, 2018 at 5:38 AM kristoffer ödmark <
> kristofferodmar...@gmail.com> wrote:
> 
> > Thanks! This is exactly what i was going for, non-intrusive
> > oppurtunity
> > for uniformity!
> > 
> > I tested the bom2csv plugin, It did not include the empty fields.
> > 
> > I also tested the bom_csv_sorted_by_ref, it did not include the
> > empty
> > values, but it included some values I had not specified, such as
> > Manufacturer and Vendor even if they were not provided in the
> > schematic.
> > 
> > - Kristoffer
> > 
> > On Tue, 2018-05-22 at 11:05 +0100, Jeff Young wrote:
> > > I think I like this new patch.  It provides the /opportunity/ for
> > > uniformity, without getting in the way of those who want to go
> > > their
> > > own way.
> > > 
> > > Do the BOM generators automatically output all default fields or
> > > only
> > > those with values?
> > > 
> > > > On 22 May 2018, at 09:22, kristoffer ödmark  > > > @gma
> > > > il.com> wrote:
> > > > 
> > > > Please disregard my previous mail, it got mangled badly
> > > > somehow, it
> > > > did
> > > > not look like that in my editor at least.
> > > > 
> > > > On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
> > > > > Eeschema already supports creating default optional fields in
> > > > > the
> > > > > configuration settings dialog.  Used correctly, these will
> > > > > give
> > > > > you
> > > > > the
> > > > > same optional field names for every project without having to
> > > > > add
> > > > > them
> > > > > by hand to each symbol and possibly typing in different field
> > > > > names
> > > > > by
> > > > > accident.
> > > > 
> > > > Different users will still type in different field names for
> > > > the
> > > > same
> > > > things though. What you describe works as long as there is only
> > > > one
> > > > person in the entire projects lifetime, using only one
> > > > computer.
> > > > 
> > > > > The proposed patch would intermingle the default fields
> > > > > with
> > > > > existing schematic symbol fields which would break existing
> > > > > BOMs
> > > > > which I
> > > > > don't think users will appreciate.
> > > > 
> > > > The proposed patch will only change default settings, existing
> > > > users
> > > > with a config already in place will not be affected. I realised
> > > > that
> > > > the fields now accept empty values as well, so existing boms on
> > > > new
> > > > installations will not be affected either. I updated the patch,
> > > > so
> > > > it
> > > > will not affect anyone that doesnt use the fields.
> > > > 
> > > > > [...] As I've stated before, I can set 10
> > > > > different designers down and I will get 10 different sets of
> > > > > default
> > > > > field names.  This really seems like me to be a configuration
> > > > > issue.
> > > > 
> > > > This is the problems I want to address, because those 10
> > > > designers
> > > > will
> > > > by experience also spell the same field in 10 different ways.
> > > > Making
> > > > their fields incompatable. MPN, MFPN, #mfg, ManufPart, etc etc.
> > > > Let
> > > > those 10 designers remove the fields they do not want instead.
> > > > 
> > > > > The only possible solution that I would accept is to move the
> > > > > default
> > > > > field definitions from the eeschema configuration file into
> > > > > the
> > > > > default
> > > > > kicad project file.  This way existing projects would not be
> > > > > polluted
> > > >

Re: [Kicad-developers] More default fields in schematic

[kristoffer ödmark]

Thanks! This is exactly what i was going for, non-intrusive oppurtunity
for uniformity! 

I tested the bom2csv plugin, It did not include the empty fields.

I also tested the bom_csv_sorted_by_ref, it did not include the empty
values, but it included some values I had not specified, such as
Manufacturer and Vendor even if they were not provided in the
schematic.

- Kristoffer

On Tue, 2018-05-22 at 11:05 +0100, Jeff Young wrote:
> I think I like this new patch.  It provides the /opportunity/ for
> uniformity, without getting in the way of those who want to go their
> own way.
> 
> Do the BOM generators automatically output all default fields or only
> those with values?
> 
> > On 22 May 2018, at 09:22, kristoffer ödmark <kristofferodmark90@gma
> > il.com> wrote:
> > 
> > Please disregard my previous mail, it got mangled badly somehow, it
> > did
> > not look like that in my editor at least.
> > 
> > On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
> > > Eeschema already supports creating default optional fields in the
> > > configuration settings dialog.  Used correctly, these will give
> > > you
> > > the
> > > same optional field names for every project without having to add
> > > them
> > > by hand to each symbol and possibly typing in different field
> > > names
> > > by
> > > accident.  
> > 
> > Different users will still type in different field names for the
> > same
> > things though. What you describe works as long as there is only one
> > person in the entire projects lifetime, using only one computer.
> > 
> > > The proposed patch would intermingle the default fields
> > > with
> > > existing schematic symbol fields which would break existing BOMs
> > > which I
> > > don't think users will appreciate.  
> > 
> > The proposed patch will only change default settings, existing
> > users
> > with a config already in place will not be affected. I realised
> > that
> > the fields now accept empty values as well, so existing boms on new
> > installations will not be affected either. I updated the patch, so
> > it
> > will not affect anyone that doesnt use the fields. 
> > 
> > > [...] As I've stated before, I can set 10
> > > different designers down and I will get 10 different sets of
> > > default
> > > field names.  This really seems like me to be a configuration
> > > issue.
> > 
> > This is the problems I want to address, because those 10 designers
> > will
> > by experience also spell the same field in 10 different ways.
> > Making
> > their fields incompatable. MPN, MFPN, #mfg, ManufPart, etc etc. Let
> > those 10 designers remove the fields they do not want instead.
> > 
> > > The only possible solution that I would accept is to move the
> > > default
> > > field definitions from the eeschema configuration file into the
> > > default
> > > kicad project file.  This way existing projects would not be
> > > polluted
> > > with the proposed default fields and users could define their own
> > > default fields in a custom project file.  
> > 
> > Default fields does not pollute if they are empty, they just give a
> > hint of what data could be put into the schematic, same as with the
> > datasheet field, which is not often used. Funny how noone ever
> > complains about that one.
> > 
> > > [...]
> > > A more flexible solution would be to add a "File->New from Custom
> > > Template" command to KiCad to allow the user to select any custom
> > > project file.  This would allow for multiple custom project files
> > > instead of forcing the user to use only a single default project
> > > file.
> > 
> > As long as the "File->New Project" would include the additional
> > fields
> > and then people can use "New from Custom Template" means they can
> > use a
> > template that is empty. Otherwise it would defeat the purpose. I am
> > proposing a slightly different default configuration, not any
> > change in
> > how people will use the software.
> > 
> > > Cheers,
> > > 
> > > Wayne
> > > 
> > > On 05/20/2018 06:27 PM, Andrey Kuznetsov wrote:
> > > > I agree, I had the same issue when I was doing my board, I
> > > > needed a
> > > > field for all components, and I had to manually add it for
> > > > every
> > > > item,
> > > > there was 

Re: [Kicad-developers] More default fields in schematic

[kristoffer ödmark]

On Tue, 2018-05-22 at 10:11 +0200, Maciej Sumiński wrote:
> One more field that could become predefined and receive a special
> meaning is 'Mounted' or similar. This will come handy when we decide
> to
> support assembly variants and will let us add a visual distinction
> between mounted and not mounted components if we want it.
> The remaining fields is a matter of configuration, particularly that
> there is a way to specify the default fields in eeschema. I am quite
> sure that there are existing libraries using other field names than
> the
> ones we would hard-code, so such change would make users upset. I do
> not
> see there is a reason to enforce field naming for everyone, unless
> the

There is no enforcement, there is only suggestion with a default
config. I feel that maybe I am not getting that point across. For
example, giving the users the field MPN as an option field gives them a
starting point, nothing with my approach locks them into using that
specific name or even keep it, they can change it. It only helps when
people wants to use it, since it hints that this name might be
compatible with other tools.

> field needs to be treated in a special way:
> 
> - "Reference" as the unique component identifier and a link between
> schematics and board
> - "Footprint" to pick the physical representation with the footprint
> browser
> - "Datasheet" lets open corresponding documentation for a component
> - "Value" is the only field that serves the description purpose only,
> but it seems a sensible exception to the rule

MPN - When I want to forward my schematic to a one-click order or check
 price on mouser, digikey or wherever. But we dont have that now, and
we can never have that. Because we can not suggest a name, that would
be rude. I dont get the problem with a default config that hints at
what it might be called. I chose MPN in my example since it is used be
the Digikey library on github amongst other projects i found.

> 
> Cheers,
> Orson
> 
> On 05/20/2018 10:00 PM, kristoffer Ödmark wrote:
> > Hello!
> > 
> > I will open this can of worms again, I feel that I have to. So from
> > what
> > I gather we have proffessionals as the main aim in Kicad.
> > The reason I will open this issue again is that I feel we have a
> > collaboration issue, maybe not a mayor one. But one nonetheless.
> > 
> > We really need more default fields for our schematic symbols. Im
> > not
> > proposing required fields, I am *ONLY* proposing that
> > there should be default fields added into the default fields
> > settings
> > tab. I am not proposing they need to be filled in the
> > libraries, nor that people need to use them. only that they need to
> > exist with a fresh install of kicad so that easy problems
> > such as theese do not happen:
> > 
> > - Collaborators working on the same project will not create
> > duplicate fields in libs/projects describing the same thing by
> > mistake
> > - Projects that aim to interact or add to Kicad can assume that
> > the
> > Fields will exist, and will know what name/tag to look for
> >   (bom exporters, price checkers, MacroFab, etc)
> > - Open source projects will be easier to collaborate, read and
> > order
> > 
> > The reason I think it is better to have the fields by default than
> > the
> > current solution to add them is that the majority will use
> > what exists, and tools can support it from the very beginning,
> > people
> > with inhouse tools seems to dislike this, since they map their
> > parts with an inhouse number - and then handle the information
> > about the
> > part there. From what I gather, this is not the majority, and
> > these persons still modify the default fields settings.
> > 
> > I spent maybe 30-40 mins checking the "made with kicad" projects, I
> > found that the most common addition to libs and schematics are:
> > - Manufacturers part number, these were named widely different
> > in
> > projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value
> > field )
> > I even saw a mix of these in the same project once, along
> > with
> > some people having the vendor id only.
> > - Manufacturer ( found some different languages though )
> > 
> > more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W,
> > 85C,
> > 16V ), Vendor information and different Descriptions. They were
> > named
> > and abbreviated
> > very differently accross projects.
> > 
> > What I would like to see is these additional fields by default, but
> > hidden 

Re: [Kicad-developers] More default fields in schematic

[kristoffer ödmark]

Please disregard my previous mail, it got mangled badly somehow, it did
not look like that in my editor at least.

On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
> Eeschema already supports creating default optional fields in the
> configuration settings dialog.  Used correctly, these will give you
> the
> same optional field names for every project without having to add
> them
> by hand to each symbol and possibly typing in different field names
> by
> accident.  

Different users will still type in different field names for the same
things though. What you describe works as long as there is only one
person in the entire projects lifetime, using only one computer.

> The proposed patch would intermingle the default fields
> with
> existing schematic symbol fields which would break existing BOMs
> which I
> don't think users will appreciate.  

The proposed patch will only change default settings, existing users
with a config already in place will not be affected. I realised that
the fields now accept empty values as well, so existing boms on new
installations will not be affected either. I updated the patch, so it
will not affect anyone that doesnt use the fields. 

> [...] As I've stated before, I can set 10
> different designers down and I will get 10 different sets of default
> field names.  This really seems like me to be a configuration issue.

This is the problems I want to address, because those 10 designers will
by experience also spell the same field in 10 different ways. Making
their fields incompatable. MPN, MFPN, #mfg, ManufPart, etc etc. Let
those 10 designers remove the fields they do not want instead.

> The only possible solution that I would accept is to move the default
> field definitions from the eeschema configuration file into the
> default
> kicad project file.  This way existing projects would not be polluted
> with the proposed default fields and users could define their own
> default fields in a custom project file.  

Default fields does not pollute if they are empty, they just give a
hint of what data could be put into the schematic, same as with the
datasheet field, which is not often used. Funny how noone ever
complains about that one.

> [...]
> A more flexible solution would be to add a "File->New from Custom
> Template" command to KiCad to allow the user to select any custom
> project file.  This would allow for multiple custom project files
> instead of forcing the user to use only a single default project
> file.

As long as the "File->New Project" would include the additional fields
and then people can use "New from Custom Template" means they can use a
template that is empty. Otherwise it would defeat the purpose. I am
proposing a slightly different default configuration, not any change in
how people will use the software.

> 
> Cheers,
> 
> Wayne
> 
> On 05/20/2018 06:27 PM, Andrey Kuznetsov wrote:
> > I agree, I had the same issue when I was doing my board, I needed a
> > field for all components, and I had to manually add it for every
> > item,
> > there was no way to add this field to all components at the same
> > time or
> > to have it add by default from the addition of a new component to
> > the sheet.
> > 
> > Which reminds me, Cadence Designer has tools to manipulate fields
> > on a
> > large scale, whether to add, delete, show, hide, etc, this is
> > something
> > that would be nice to have in KiCAD, either that or a table of all
> > components for the sheet or schematic and columns for each field,
> > with
> > ability to show/hide each cell individually.
> > 
> > I think the ultimate goal is to make the Symbol Table more useful,
> > but
> > that'll take to long for v5 so if Kristoffer's patch allows an easy
> > way
> > to add fields to all components or similar, I'd say do it because
> > people
> > will be pissed and waste their time doing it for every component in
> > their schematic.
> > 
> > On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark
> > <kristofferodmar...@gmail.com <mailto:kristofferodmar...@gmail.com>
> > > wrote:
> > 
> > I obvviously disagree, the correct solution would be to have
> > both.
> > This does not hinder that, its not even the same problem.
> > 
> > The problem is for everyone who want for example the
> > Manufacturer
> > Part Number will have to define a fieldname, which every time
> > results in them abbreviating it to something different. Hence
> > nobody
> > can work with Manufacturer Part Numbers.
> > 
> > Here is something similar, Imagine all of the colours in Kicad
> > for
>

Re: [Kicad-developers] More default fields in schematic

[kristoffer Ödmark]

The proposed patch would intermingle the default  > fields with existing schematic symbol fields which would break > 
existing BOMs which I don't think users will appreciate. The proposed 
patch will only change default settings, existing users with a config 
already in place will not be affected. I realised that the fields now 
accept empty values as well, so existing boms on new installations will 
not be affected either. I updated the patch, so it will not affect 
anyone that doesnt use the fields.
As I've stated before, I can set 10 different designers down  > and I will get 10 different sets of default field names. This really 
> seems like me to be a configuration issue. This is the problems I 
want to address, because those 10 designers will by experience also 
spell the same field in 10 different ways. Making their designs 
incompatable, resulting in 100 different fields, but only describing 10 
different things
Is this feature not  > useful enough or not documented well enough for users? Hard coding > 
default field names that no one can agree upon is not going to > happen. 
The problem is that they will spell differently, MPN, MFPN, #mfg, 
ManufPart, etc etc The problem is really that those who want to embedd 
the part number can not to that in an easy way, they cannot set the 
field in any compatible way, creating many problems for people that has 
to compare/view others design. Many hours can be lost, just because the 
simple phrase "Set the Manufacturers Part number in the schematic of 
your desing", all that can be solved by a single step of spelling the 
value name for the users. Ofcourse they will still be able to change it 
later if they want.
the same optional field names for every project without having to add  > them by hand to each symbol As long as you assume there will only 
ever be one person involved here, and that they will always use the same 
computer over the projects lifetime. > The only possible solution that I 
would accept is to move the > default field definitions from the 
eeschema configuration file into > the default kicad project file. This 
way existing projects would not > be polluted with the proposed default 
fields and users could define > their own default fields in a custom 
project file. I would like this as well, all I want is a default name, 
to give users a hint, I really do not care where it is set, or even if 
there would be a lot of fields that I personally will never use in it, 
because it is much easier to remove the fields than to add them in a 
uniform way over the globe. Still though, I think having the fields set 
in eeschema is better, makes my changes stick over different projects. > 
This would allow for multiple > custom project files instead of forcing 
the user to use only a single > default project file. As long as the 
"File->New Project" would include the additional fields and then people 
can use "New from Custom Template" means they can use a template that is 
free from the fields, sure. Otherwise we are back at square one, and we 
added a lot of shit, helping no one. - Kristoffer On 2018-05-22 00:22, 
Wayne Stambaugh wrote:
introduced a change that allows the user to define a custom template  > path which takes precedence over the system template path so this > 
solution is workable. A more flexible solution would be to add a > 
"File->New from Custom Template" command to KiCad to allow the user > to 
select any custom project file. > > Cheers, > > Wayne > > On 05/20/2018 
06:27 PM, Andrey Kuznetsov wrote: >> I agree, I had the same issue when 
I was doing my board, I needed >> a field for all components, and I had 
to manually add it for every >> item, there was no way to add this field 
to all components at the >> same time or to have it add by default from 
the addition of a new >> component to the sheet. >> >> Which reminds me, 
Cadence Designer has tools to manipulate fields >> on a large scale, 
whether to add, delete, show, hide, etc, this is >> something that would 
be nice to have in KiCAD, either that or a >> table of all components 
for the sheet or schematic and columns for >> each field, with ability 
to show/hide each cell individually. >> >> I think the ultimate goal is 
to make the Symbol Table more useful, >> but that'll take to long for v5 
so if Kristoffer's patch allows an >> easy way to add fields to all 
components or similar, I'd say do it >> because people will be pissed 
and waste their time doing it for >> every component in their schematic. 
>> >> On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark >> 
<kristofferodmar...@gmail.com >> <mailto:kristofferodmar...@gmail.com>> 
wrote: >> >> I obvviously disagree, the correct solution would be

Re: [Kicad-developers] More default fields in schematic

[Kristoffer Ödmark]

No, that is one usage of it, some people likes to make the schematic 
their bom, some tools and services can also rely on such values.


Once again, the only people complaining are the ones that do not use it, 
and also the ones that will not be affected. Sure name it PartNum and 
use it the way you describe, you would never use any other tools to 
interact anyway, since that apparently is not your job... I only want 
there to be a common denomination for the the field names by default.


Because right now, anyone who actually uses the Schematic this way, 
which are quite many will always have to randomly define and abbreviate 
the same field, which just hinders anything smart to be done on top of it.


To better go with your thinking, I suggest you remove all the 
keybindings i KiCad, and then set them to what you want. That way you 
will get the current field experience. Everything is better with no 
defaults, amiright?


 -Kristoffer

On 2018-05-21 06:13, Jean-Paul Louis wrote:

That discussion once again shows how people misunderstand the concept of part 
number.
In a schematic, the part number attached to a RefDes should be unique AND NOT a 
manufacturer number.
   There should be a one to one relationship between a part number (symbol) and 
a physical shape, so the PCB will be a unit manufacturable only when the BOM is 
generated, and is one to one relationship between part number and Mfg part 
number.
The BOM is only for manufacturing assembly and procurement purpose
and does not need to be part of the design database, so Manufacturing can use 
Equivalent Mfg numbers for a given part number. That’s why many companies use 
internal numbering systems that are non picture coded and just sequential.
The relationship Symbol, Shape, Supplier is the responsibility of the master 
library, not the designers.

Just my $0.02,
Jean-Paul
N1JPL



On May 20, 2018, at 6:27 PM, Andrey Kuznetsov <kandre...@gmail.com> wrote:

I agree, I had the same issue when I was doing my board, I needed a field for 
all components, and I had to manually add it for every item, there was no way 
to add this field to all components at the same time or to have it add by 
default from the addition of a new component to the sheet.

Which reminds me, Cadence Designer has tools to manipulate fields on a large 
scale, whether to add, delete, show, hide, etc, this is something that would be 
nice to have in KiCAD, either that or a table of all components for the sheet 
or schematic and columns for each field, with ability to show/hide each cell 
individually.

I think the ultimate goal is to make the Symbol Table more useful, but that'll 
take to long for v5 so if Kristoffer's patch allows an easy way to add fields 
to all components or similar, I'd say do it because people will be pissed and 
waste their time doing it for every component in their schematic.

On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark 
<kristofferodmar...@gmail.com> wrote:
I obvviously disagree, the correct solution would be to have both. This does 
not hinder that, its not even the same problem.

The problem is for everyone who want for example the Manufacturer Part Number 
will have to define a fieldname, which every time
results in them abbreviating it to something different. Hence nobody can work 
with Manufacturer Part Numbers.

Here is something similar, Imagine all of the colours in Kicad for all of the 
layers where white by default. Have fun defining all the colours yourself.
Maybe you want to define them yourself, nobody is stopping you now either, just 
get cracking.

How easy would it be for you to look at the board someone else made later and 
understand what is what? Maybe for some that is a better solution, but for me 
that
would be an extreme example of bad default values.

This is how the default fields are now, they are white, or more like 
see-throught, which makes life harder for anyone that
wants to contribute or create tools that interact with kicad, and as I 
previously said, this is only a default, you are still
equally able to add/remove or change the fields how you want to. But, tools 
like kibom or various other web-based tools can much
easier integrate to it, or at least support a default value as well. So for the 
majority of users, who doesnt change defaults,
the tool would just work.

I will reiterate, I do not care what they are named, I want a default field 
where I can put my manufacturer part number, amongs others.
The specific abbreviation or name does not matter, If i care, I can manually 
add/remove my own fields *JUST AS I DO NOW*, but for the people
who use it, it will be easier across projects, for the people that dont, It 
will not matter.

Sane defaults matter. A lot actually.

- Kristoffer

On 2018-05-20 23:40, José Ignacio wrote:
I dont like this, the right solution would be to allow for importing a default 
config into kicad for things like that, as different groups will have different 
policies.

On Sun, 

Re: [Kicad-developers] More default fields in schematic

[kristoffer Ödmark]

I obvviously disagree, the correct solution would be to have both. This 
does not hinder that, its not even the same problem.


The problem is for everyone who want for example the Manufacturer Part 
Number will have to define a fieldname, which every time
results in them abbreviating it to something different. Hence nobody can 
work with Manufacturer Part Numbers.


Here is something similar, Imagine all of the colours in Kicad for all 
of the layers where white by default. Have fun defining all the colours 
yourself.
Maybe you want to define them yourself, nobody is stopping you now 
either, just get cracking.


How easy would it be for you to look at the board someone else made 
later and understand what is what? Maybe for some that is a better 
solution, but for me that

would be an extreme example of bad default values.

This is how the default fields are now, they are white, or more like 
see-throught, which makes life harder for anyone that
wants to contribute or create tools that interact with kicad, and as I 
previously said, this is only a default, you are still
equally able to add/remove or change the fields how you want to. But, 
tools like kibom or various other web-based tools can much
easier integrate to it, or at least support a default value as well. So 
for the majority of users, who doesnt change defaults,

the tool would just work.

I will reiterate, I do not care what they are named, I want a default 
field where I can put my manufacturer part number, amongs others.
The specific abbreviation or name does not matter, If i care, I can 
manually add/remove my own fields *JUST AS I DO NOW*, but for the people
who use it, it will be easier across projects, for the people that dont, 
It will not matter.


Sane defaults matter. A lot actually.

- Kristoffer

On 2018-05-20 23:40, José Ignacio wrote:
I dont like this, the right solution would be to allow for importing a 
default config into kicad for things like that, as different groups 
will have different policies.


On Sun, May 20, 2018 at 3:31 PM, Kristoffer Ödmark 
<kristofferodmar...@gmail.com <mailto:kristofferodmar...@gmail.com>> 
wrote:


The patch should only affect first startup, changes to the fields
will be saved

On May 20, 2018 22:18, "Seth Hillbrand" <seth.hillbr...@gmail.com
<mailto:seth.hillbr...@gmail.com>> wrote:

​Hi Kristoffer-

This feels like a management issue rather than a tool issue. 
If the user doesn't want any extra fields, how would your
patch allow that?

-S


Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark
<kristofferodmar...@gmail.com
<mailto:kristofferodmar...@gmail.com>>:

Hello!

I will open this can of worms again, I feel that I have
to. So from what
I gather we have proffessionals as the main aim in Kicad.
The reason I will open this issue again is that I feel we
have a
collaboration issue, maybe not a mayor one. But one
nonetheless.

We really need more default fields for our schematic
symbols. Im not
proposing required fields, I am *ONLY* proposing that
there should be default fields added into the default
fields settings
tab. I am not proposing they need to be filled in the
libraries, nor that people need to use them. only that
they need to
exist with a fresh install of kicad so that easy problems
such as theese do not happen:

 - Collaborators working on the same project will not
create
duplicate fields in libs/projects describing the same
thing by mistake
 - Projects that aim to interact or add to Kicad can
assume that the
Fields will exist, and will know what name/tag to look for
   (bom exporters, price checkers, MacroFab, etc)
 - Open source projects will be easier to collaborate,
read and order

The reason I think it is better to have the fields by
default than the
current solution to add them is that the majority will use
what exists, and tools can support it from the very
beginning, people
with inhouse tools seems to dislike this, since they map their
parts with an inhouse number - and then handle the
information about the
part there. From what I gather, this is not the majority, and
these persons still modify the default fields settings.

I spent maybe 30-40 mins checking the "made with kicad"
projects, I
found that the most common addition to libs and schematics
are:
 - Manufacturers part number, these were named widely

Re: [Kicad-developers] More default fields in schematic

[Kristoffer Ödmark]

The patch should only affect first startup, changes to the fields will be
saved

On May 20, 2018 22:18, "Seth Hillbrand" <seth.hillbr...@gmail.com> wrote:

​Hi Kristoffer-

This feels like a management issue rather than a tool issue.  If the user
doesn't want any extra fields, how would your patch allow that?

-S


Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark <
kristofferodmar...@gmail.com>:

> Hello!
>
> I will open this can of worms again, I feel that I have to. So from what
> I gather we have proffessionals as the main aim in Kicad.
> The reason I will open this issue again is that I feel we have a
> collaboration issue, maybe not a mayor one. But one nonetheless.
>
> We really need more default fields for our schematic symbols. Im not
> proposing required fields, I am *ONLY* proposing that
> there should be default fields added into the default fields settings
> tab. I am not proposing they need to be filled in the
> libraries, nor that people need to use them. only that they need to
> exist with a fresh install of kicad so that easy problems
> such as theese do not happen:
>
>  - Collaborators working on the same project will not create
> duplicate fields in libs/projects describing the same thing by mistake
>  - Projects that aim to interact or add to Kicad can assume that the
> Fields will exist, and will know what name/tag to look for
>(bom exporters, price checkers, MacroFab, etc)
>  - Open source projects will be easier to collaborate, read and order
>
> The reason I think it is better to have the fields by default than the
> current solution to add them is that the majority will use
> what exists, and tools can support it from the very beginning, people
> with inhouse tools seems to dislike this, since they map their
> parts with an inhouse number - and then handle the information about the
> part there. From what I gather, this is not the majority, and
> these persons still modify the default fields settings.
>
> I spent maybe 30-40 mins checking the "made with kicad" projects, I
> found that the most common addition to libs and schematics are:
>  - Manufacturers part number, these were named widely different in
> projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value field )
>  I even saw a mix of these in the same project once, along with
> some people having the vendor id only.
>  - Manufacturer ( found some different languages though )
>
> more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W, 85C,
> 16V ), Vendor information and different Descriptions. They were named
> and abbreviated
> very differently accross projects.
>
> What I would like to see is these additional fields by default, but
> hidden from the schematic unless changed by user.
>  Tolerance ( used for setting tolerances of resistors, capacitors,
> oscillators, etc )
>  MaxRating ( field were one can specify max Voltage, Ampere,
> Frequency, or whatever the component needs )
>  Manufacturer ( For inhouse numbers, they could either just remove
> it, or use the company/group name )
>  MPN ( Maybe PartNumber could be used here, and people who use
> inhouse numbers use it aswell, I dont really care what its called, as
> long as its called something )
>  Vendor
>  Notes
>
> I would be all up for extra additions/removals, but I would prefer if
> the naming is not discussed, but rather just decided/agreed upon by
> someone in the lead team.
> The very least I think should be added in case the previous is to much are:
>  Tolerance
>  Manufacturer
>  MPN
>
> I attach a patch for the minimal set, tested on linux by removing the
> .config/kicad/eeschema file.
>
> - Kristoffer
>
>
> ps
> Some github files i reviewed, not all:
>
> https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-I_SN.lib
>
> https://github.com/jonpe960/blixten/blob/master/Blixten%20LED%20Device/Blixten.sch
>
> https://github.com/paltatech/half-bridge/blob/master/pcb%20design/IGBT_board-cache.lib
> https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib
>
> https://github.com/jim17/memtype/blob/master/schematic_pcb/electronic_design_kicad/electronic_design_kicad.sch
> ___
> 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] More default fields in schematic

[kristoffer Ödmark]

Hello!

I will open this can of worms again, I feel that I have to. So from what 
I gather we have proffessionals as the main aim in Kicad.
The reason I will open this issue again is that I feel we have a 
collaboration issue, maybe not a mayor one. But one nonetheless.


We really need more default fields for our schematic symbols. Im not 
proposing required fields, I am *ONLY* proposing that
there should be default fields added into the default fields settings 
tab. I am not proposing they need to be filled in the
libraries, nor that people need to use them. only that they need to 
exist with a fresh install of kicad so that easy problems

such as theese do not happen:

    - Collaborators working on the same project will not create 
duplicate fields in libs/projects describing the same thing by mistake
    - Projects that aim to interact or add to Kicad can assume that the 
Fields will exist, and will know what name/tag to look for

  (bom exporters, price checkers, MacroFab, etc)
    - Open source projects will be easier to collaborate, read and order

The reason I think it is better to have the fields by default than the 
current solution to add them is that the majority will use
what exists, and tools can support it from the very beginning, people 
with inhouse tools seems to dislike this, since they map their
parts with an inhouse number - and then handle the information about the 
part there. From what I gather, this is not the majority, and

these persons still modify the default fields settings.

I spent maybe 30-40 mins checking the "made with kicad" projects, I 
found that the most common addition to libs and schematics are:
    - Manufacturers part number, these were named widely different in 
projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value field )
        I even saw a mix of these in the same project once, along with 
some people having the vendor id only.

    - Manufacturer ( found some different languages though )

more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W, 85C, 
16V ), Vendor information and different Descriptions. They were named 
and abbreviated

very differently accross projects.

What I would like to see is these additional fields by default, but 
hidden from the schematic unless changed by user.
    Tolerance ( used for setting tolerances of resistors, capacitors, 
oscillators, etc )
    MaxRating ( field were one can specify max Voltage, Ampere, 
Frequency, or whatever the component needs )
    Manufacturer ( For inhouse numbers, they could either just remove 
it, or use the company/group name )
    MPN ( Maybe PartNumber could be used here, and people who use 
inhouse numbers use it aswell, I dont really care what its called, as 
long as its called something )

    Vendor
    Notes

I would be all up for extra additions/removals, but I would prefer if 
the naming is not discussed, but rather just decided/agreed upon by 
someone in the lead team.

The very least I think should be added in case the previous is to much are:
    Tolerance
    Manufacturer
    MPN

I attach a patch for the minimal set, tested on linux by removing the 
.config/kicad/eeschema file.


- Kristoffer


ps
Some github files i reviewed, not all:
https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-I_SN.lib
https://github.com/jonpe960/blixten/blob/master/Blixten%20LED%20Device/Blixten.sch
https://github.com/paltatech/half-bridge/blob/master/pcb%20design/IGBT_board-cache.lib
https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib
https://github.com/jim17/memtype/blob/master/schematic_pcb/electronic_design_kicad/electronic_design_kicad.sch
>From f0af6575bfa46e70168c1d3cfcafdf19dbc7b125 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= 
Date: Sun, 20 May 2018 21:59:13 +0200
Subject: [PATCH] Added minimal set of default template fields

---
 eeschema/eeschema_config.cpp | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/eeschema/eeschema_config.cpp b/eeschema/eeschema_config.cpp
index 205ab2674..53b510bac 100644
--- a/eeschema/eeschema_config.cpp
+++ b/eeschema/eeschema_config.cpp
@@ -588,7 +588,10 @@ void SCH_EDIT_FRAME::LoadSettings( wxConfigBase* aCfg )
 m_replaceStringHistoryList.Add( tmpHistory );
 }
 
-wxString templateFieldNames = aCfg->Read( FieldNamesEntry, wxEmptyString );
+// Read the template field settings, use default if no found
+const wxString defaultTemplateFieldNames =
+"(templatefields (field (name Tolerance)(value ~)) (field (name Manufacturer)(value ~)) (field (name MPN)(value ~)))";
+wxString templateFieldNames = aCfg->Read( FieldNamesEntry, defaultTemplateFieldNames );
 
 if( !templateFieldNames.IsEmpty() )
 {
-- 
2.17.0

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

Re: [Kicad-developers] Indeterministic netlist export for multiunit components

[Kristoffer Ödmark]

I think another stop gap measure is to have the ERC handle this, but
otherwise I am for Orsons patch.

Better a defined bad behavior than an undefined random behavior is my
opinion :)

On Fri, May 18, 2018, 16:53 Maciej Sumiński  wrote:

> How about my patch? I do not dare to go for the ultimate solution right
> now, but is it acceptable as a stop gap measure for v5?
>
> Cheers,
> Orson
>
> On 05/18/2018 03:28 PM, Wayne Stambaugh wrote:
> > The suggestions made are all good and valid but I think to some extent
> > there will always be some ambiguity.  Users being users will make
> > mistakes filling in field data which will cause issues when annotating
> > and generating the netlist.  In complex designs with lots of multiple
> > units symbols it's not always possible to know which units should be
> > grouped together by reference.  More often that not, this cannot be
> > known until board layout time.  This is something that I am all to
> > familiar with because I do lots of designs with several dual and quad
> > op-amps.  I don't think we will ever be able to completely do this
> > without some ambiguity until some type of human brain interface is
> > created to allow us to know what the user wants versus what the user
> > specified.
> >
> > That being said, I suggest we define the behavior we want before we
> > start coding so there is no ambiguity it what we hope to accomplish.  A
> > simple bulleted list would be fine.  Once we define the desired
> > behavior, we should get some user input so that we don't create
> > something that doesn't work well for users.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 05/18/2018 08:44 AM, Jeff Young wrote:
> >> Hi Orson,
> >>
> >> The problem should become less prevalent over time: for 6.0 I plan on
> fixing the multi-sheet undo issues so that we can update all units in
> unison.  (Of course that still fails if you edit before annotating as we
> then don’t know which units go with which.)
> >>
> >> But I agree that anytime we have a non-matching field across units it
> looks like a bug to the user.  Your proposal is certainly an improvement in
> that regard.
> >>
> >> I think the one thing that would be left would be to flag unit field
> mismatches when annotating (or perhaps even try and group units by matching
> their fields).  But that carries enough risk to relegate it to 6.0 along
> with the undo stuff.
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>
> >>> On 18 May 2018, at 12:16, Sergey A. Borshch <
> sb...@users.sourceforge.net> wrote:
> >>>
> >>> On 18.05.2018 11:14, Maciej Sumiński wrote:
>  Hi,
>  Recently I have found out that the netlist exporter uses an algorithm
>  that for multiunit components uses non empty field values from the
> last
>  processed unit [1]. The problem is that the processing order depends
> on
>  the order of the units in the item list, so completely random.
> >>> I want to remind that there is another bug in netlist generator
> related to units processing order: https://bugs.launchpad.net/bugs/1704083
> >>>
>  Instead, I propose we try to get all field values from the first
>  available unit (e.g. unit A), and resort to other units only if there
>  are any fields left empty.
> 
>  To give an example of what can go wrong with such approach: recently I
>  generated BOM and assembly documentation, where unit A had 'Mounted'
>  field set to 'No'. I was surprised to find out that in the generated
>  output it has been marked as mounted, as the unit B had 'Yes' set for
>  the field. I would qualify it as a bug, but I seek your input before I
>  proceed with pushing my changes. See my proposal in the attached
> patch.
> >>> I think there no need in Artificial Intelligence while generating
> netlist from incorrect schematics, but all fields in component units must
> be consistent instead. I mean that changing in schematics editor any field
> in one unit must also change same field in other units with same RefDes.
> Automatic annotation must take into account all fields values and assign
> different RefDes to units which differs with fields values.
> >>> One more proposal - manual RefDes change shoud not be allowed with
> appropriate warning if unit(s) with new RefDes already exist in schematics
> and belongs to another component type or has different fields value(s). It
> would be best helpful if warning message will show that units belongs to
> different component types or which field value differs if component type is
> the same.
> >>>
> >>>
> >>> --
> >>> Regards,
> >>>  Sergey A. Borshchmailto: sb...@sourceforge.net
> >>>SB ELDI ltd. Riga, Latvia
> >>>
> >>>
> >>> ___
> >>> 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 Footprint libs and wizard issues

[Kristoffer Ödmark]

Thank you JP!

I will have a look when I get home, It was not happening on linux, and I 
do not currently have a windows computer anywhere, but maybe I can force 
the cursor to the end some other way.


 -Kristoffer

On 2018-04-09 16:21, jp charras wrote:

Le 08/04/2018 à 00:42, kristoffer Ödmark a écrit :

Agreed, hereis a patch for that :)


Hi kristoffer,
I tested your patch (about lowercase) on W7.

It has an issue: if I try to enter a lowercase char, it is converted to the 
corresponding uppercase
char (as expected), but the cursor moves to the beginning of the text after the 
char is inserted.



- Kristoffer

On 2018-04-06 17:18, Kevin Cozens wrote:

On 2018-04-06 06:30 AM, kristoffer Ödmark wrote:

Attached is a patch that adds support for custom environment paths. Previously 
the wizard would
only accept KISYSMOD, KIPRJMOD and the github one.


I added MYSYSMOD as a custom path ages ago. What I find odd about the dialog 
boxes that let you
add paths is that they won't accept lower case letters in the name of the 
environment variable. If
you type a lowercase letter nothing happens on the screen. If it doesn't want 
lowercase it should
force what you entered to uppercase when you are done entering the variable 
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 Footprint libs and wizard issues

[Kristoffer Ödmark]

I know its not the most elegant solution, but it is actually quite 
convenient. Just checking so that this tiny improvement isnt lost :)


 -Kristoffer

On 2018-04-08 00:42, kristoffer Ödmark wrote:

Agreed, hereis a patch for that :)

- Kristoffer

On 2018-04-06 17:18, Kevin Cozens wrote:

On 2018-04-06 06:30 AM, kristoffer Ödmark wrote:
Attached is a patch that adds support for custom environment paths. 
Previously the wizard would only accept KISYSMOD, KIPRJMOD and the 
github one.


I added MYSYSMOD as a custom path ages ago. What I find odd about the 
dialog boxes that let you add paths is that they won't accept lower 
case letters in the name of the environment variable. If you type a 
lowercase letter nothing happens on the screen. If it doesn't want 
lowercase it should force what you entered to uppercase when you are 
done entering the variable 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 Footprint libs and wizard issues

[kristoffer Ödmark]

Agreed, hereis a patch for that :)

- Kristoffer

On 2018-04-06 17:18, Kevin Cozens wrote:

On 2018-04-06 06:30 AM, kristoffer Ödmark wrote:
Attached is a patch that adds support for custom environment paths. 
Previously the wizard would only accept KISYSMOD, KIPRJMOD and the 
github one.


I added MYSYSMOD as a custom path ages ago. What I find odd about the 
dialog boxes that let you add paths is that they won't accept lower 
case letters in the name of the environment variable. If you type a 
lowercase letter nothing happens on the screen. If it doesn't want 
lowercase it should force what you entered to uppercase when you are 
done entering the variable name.




>From defbd12daaa1876787b63ed784997bf2a4702de2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= <kristoffer.odmar...@gmail.com>
Date: Sun, 8 Apr 2018 00:39:06 +0200
Subject: [PATCH] Make Environment Editor accept lowercase, but transform them
 to uppercase when editing

---
 common/dialogs/dialog_env_var_config.cpp | 12 
 common/validators.cpp|  2 +-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/common/dialogs/dialog_env_var_config.cpp b/common/dialogs/dialog_env_var_config.cpp
index 8e327ccb2..f94ce0970 100644
--- a/common/dialogs/dialog_env_var_config.cpp
+++ b/common/dialogs/dialog_env_var_config.cpp
@@ -62,6 +62,8 @@ public:
 m_envVarName->Enable( false );
 }
 
+		void TextToUpper( wxCommandEvent& aEvent );
+
 protected:
 void OnSelectPath( wxCommandEvent& event ) override;
 void onHelpClick( wxCommandEvent& event ) override;
@@ -410,10 +412,20 @@ DIALOG_ENV_VAR_SINGLE::DIALOG_ENV_VAR_SINGLE( wxWindow* parent,
 DIALOG_ENV_VAR_SINGLE_BASE( parent )
 {
 m_envVarName->SetValue( aEnvVarName );
+
+		//Allow lovercase in the validator, but then make them uppercase when inserted.
+m_envVarName->Bind( wxEVT_TEXT, _ENV_VAR_SINGLE::TextToUpper, this, wxID_ANY );
 m_envVarPath->SetValue( aEnvVarPath );
 m_envVarName->SetValidator( ENVIRONMENT_VARIABLE_CHAR_VALIDATOR() );
 }
 
+void DIALOG_ENV_VAR_SINGLE::TextToUpper( wxCommandEvent& aEvent )
+{
+		aEvent.Skip();
+		auto val = m_envVarName->GetValue().Upper();
+		m_envVarName->ChangeValue( val );
+}
+
 
 void DIALOG_ENV_VAR_SINGLE::OnSelectPath( wxCommandEvent& event )
 {
diff --git a/common/validators.cpp b/common/validators.cpp
index bb67a7e96..a5f1e6f1f 100644
--- a/common/validators.cpp
+++ b/common/validators.cpp
@@ -80,6 +80,6 @@ FILE_NAME_WITH_PATH_CHAR_VALIDATOR::FILE_NAME_WITH_PATH_CHAR_VALIDATOR( wxString
 ENVIRONMENT_VARIABLE_CHAR_VALIDATOR::ENVIRONMENT_VARIABLE_CHAR_VALIDATOR( wxString* aValue ) :
 wxTextValidator( wxFILTER_INCLUDE_CHAR_LIST | wxFILTER_EMPTY, aValue )
 {
-wxString includeChars( wxT( "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_" ) );
+wxString includeChars( wxT( "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_" ) );
 SetCharIncludes( includeChars );
 }
-- 
2.16.2

___
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 Footprint libs and wizard issues

[kristoffer Ödmark]

Turns out the redundant code was not very redundant. There would have to 
be some more refactoring of the code to

get this all using the NormalizePath command in common/env_paths.cpp

I am also uncertain, since I dont understand the codebase good enough, 
to why Pgm.GetLocalEnvVars does not

include the env var to KIPRJMOD, I guess there is a reason?


On 2018-04-06 13:05, Jeff Young wrote:

Patch looks good to me, although I’d rather see the redundant code removed.



On 6 Apr 2018, at 11:30, kristoffer Ödmark <kristofferodmar...@gmail.com> wrote:

<0001-Footprint-Wizard-now-also-handles-custom-Env-paths.patch>


>From 561524c7e84d0fc3f0dca70057505e0f84d5147d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= <kristoffer.odmar...@gmail.com>
Date: Fri, 6 Apr 2018 12:06:05 +0200
Subject: [PATCH] Footprint Wizard now also handles custom Env paths

---
 common/env_paths.cpp| 17 +
 include/env_paths.h | 16 ++--
 pcbnew/dialogs/wizard_add_fplib.cpp | 19 +++
 3 files changed, 38 insertions(+), 14 deletions(-)

diff --git a/common/env_paths.cpp b/common/env_paths.cpp
index 3569c436d..9e6a6715c 100644
--- a/common/env_paths.cpp
+++ b/common/env_paths.cpp
@@ -64,9 +64,8 @@ static bool normalizeAbsolutePaths( const wxFileName& aPathA,
 return true;
 }
 
-
 wxString NormalizePath( const wxFileName& aFilePath, const ENV_VAR_MAP* aEnvVars,
-const PROJECT* aProject )
+const wxString& aProjectPath )
 {
 wxFileName envPath;
 wxString tmp, varName, normalizedFullPath;
@@ -90,9 +89,10 @@ wxString NormalizePath( const wxFileName& aFilePath, const ENV_VAR_MAP* aEnvVars
 }
 }
 
-if( varName.IsEmpty() && aProject )
+if( varName.IsEmpty() && !aProjectPath.IsEmpty()
+&& wxFileName( aProjectPath ).IsAbsolute() && wxFileName( aFilePath ).IsAbsolute() )
 {
-envPath.SetPath( aProject->GetProjectPath() );
+envPath.SetPath( aProjectPath );
 
 if( normalizeAbsolutePaths( envPath, aFilePath,  ) )
 varName = PROJECT_VAR_NAME;
@@ -111,6 +111,15 @@ wxString NormalizePath( const wxFileName& aFilePath, const ENV_VAR_MAP* aEnvVars
 return normalizedFullPath;
 }
 
+wxString NormalizePath( const wxFileName& aFilePath, const ENV_VAR_MAP* aEnvVars,
+const PROJECT* aProject )
+{
+  if( aProject )
+return NormalizePath( aFilePath, aEnvVars, aProject->GetProjectPath() );
+  else
+return NormalizePath( aFilePath, aEnvVars, "" );
+}
+
 
 // Create file path by appending path and file name. This approach allows the filename
 // to contain a relative path, whereas wxFileName::SetPath() would replace the
diff --git a/include/env_paths.h b/include/env_paths.h
index bac92ffca..a27fbcc7c 100644
--- a/include/env_paths.h
+++ b/include/env_paths.h
@@ -39,6 +39,18 @@
 wxString NormalizePath( const wxFileName& aFilePath, const ENV_VAR_MAP* aEnvVars,
 const PROJECT* aProject );
 
+/**
+ * Normalizes a file path to an environmental variable, if possible.
+ *
+ * @param aFilePath is the full file path (path and file name) to be normalized.
+ * @param aEnvVars is an optional map of environmental variables to try substition with.
+ * @param aProjectPath is an optional string to normalize the file path to the project path.
+ * @return Normalized full file path (path and file name) if succeeded or empty string if the
+ *  path could not be normalized.
+ */
+wxString NormalizePath(
+const wxFileName& aFilePath, const ENV_VAR_MAP* aEnvVars, const wxString& aProjectPath );
+
 /**
  * Searches the default paths trying to find one with the requested file.
  *
@@ -48,7 +60,7 @@ wxString NormalizePath( const wxFileName& aFilePath, const ENV_VAR_MAP* aEnvVars
  * @return Full path (apth and file name) if the file was found in one of the paths, otherwise
  *  an empty string.
 */
-wxString ResolveFile( const wxString& aFileName, const ENV_VAR_MAP* aEnvVars,
-const PROJECT* aProject );
+wxString ResolveFile(
+const wxString& aFileName, const ENV_VAR_MAP* aEnvVars, const PROJECT* aProject );
 
 #endif /* ENV_PATHS_H */
diff --git a/pcbnew/dialogs/wizard_add_fplib.cpp b/pcbnew/dialogs/wizard_add_fplib.cpp
index 193253cb3..b34822f0f 100644
--- a/pcbnew/dialogs/wizard_add_fplib.cpp
+++ b/pcbnew/dialogs/wizard_add_fplib.cpp
@@ -46,6 +46,7 @@
 #include 
 
 #include 
+#include 
 
 #ifdef BUILD_GITHUB_PLUGIN
 #include <../github/github_getliblist.h>
@@ -222,17 +223,14 @@ wxString WIZARD_FPLIB_TABLE::LIBRARY::GetRelativePath( const wxString& aBase, co
 
 wxString WIZARD_FPLIB_TABLE::LIBRARY::GetAutoPath( LIB_SCOPE aScope ) const
 {
-const wxString& global_env = FP_LIB_TABLE::GlobalPathEnvVariableName();
 const wxString& project_env = PROJECT_VAR_NAME;
 const wxString& github_e

Re: [Kicad-developers] New Footprint libs and wizard issues

[kristoffer Ödmark]

Found a bug shortly after, I will reupload. I will also remove the 
redundant code and check if it still works.



On 2018-04-06 13:05, Jeff Young wrote:

Patch looks good to me, although I’d rather see the redundant code removed.



On 6 Apr 2018, at 11:30, kristoffer Ödmark <kristofferodmar...@gmail.com> wrote:

<0001-Footprint-Wizard-now-also-handles-custom-Env-paths.patch>



___
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 Footprint libs and wizard issues

[kristoffer Ödmark]

Attached is a patch that adds support for custom environment paths. 
Previously the wizard would only accept KISYSMOD, KIPRJMOD and the 
github one.


left some legacy handling in the GetAutoPath, as to not break anything, 
I can remove it if wanted.



- Kristoffer


On 2018-04-04 11:02, jp charras wrote:

Le 04/04/2018 à 10:01, kristoffer Ödmark a écrit :

Hello!

So it was a while since I made some noise, so its time again.

Is there a way to create new footprint libs from KiCad? I cannot find it,
right now I create them by mkdir name.pretty, thento be able to add them
with the wizard, I have to create a temp.kicad_mod file in that folder.

Should this be considered a bug, and if so, would it go into v5? I would
like to be able to add/create empty libs, and then populate them all from within
kicad.

In footprint library, the third tool.
(Tooltip: Create new lib and save current footprint)


I also noticed that the wizard does not autoreplace the paths with the 
configured
paths in kicad the same way that the symbol library editor does. Should this 
also
be considered a bug and would a fix be accepted in v5?

- Kristoffer

It works for me.




>From 419f409524fe2ab95fcee5eefc7404cbefda1ab7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= <kristoffer.odmar...@gmail.com>
Date: Fri, 6 Apr 2018 12:06:05 +0200
Subject: [PATCH] Footprint Wizard now also handles custom Env paths

---
 common/env_paths.cpp| 16 
 include/env_paths.h | 16 ++--
 pcbnew/dialogs/wizard_add_fplib.cpp | 10 --
 3 files changed, 34 insertions(+), 8 deletions(-)

diff --git a/common/env_paths.cpp b/common/env_paths.cpp
index 3569c436d..ae3d08b1e 100644
--- a/common/env_paths.cpp
+++ b/common/env_paths.cpp
@@ -64,9 +64,8 @@ static bool normalizeAbsolutePaths( const wxFileName& aPathA,
 return true;
 }
 
-
 wxString NormalizePath( const wxFileName& aFilePath, const ENV_VAR_MAP* aEnvVars,
-const PROJECT* aProject )
+const wxString& aProjectPath )
 {
 wxFileName envPath;
 wxString tmp, varName, normalizedFullPath;
@@ -90,9 +89,9 @@ wxString NormalizePath( const wxFileName& aFilePath, const ENV_VAR_MAP* aEnvVars
 }
 }
 
-if( varName.IsEmpty() && aProject )
+if( varName.IsEmpty() && !aProjectPath.IsEmpty() )
 {
-envPath.SetPath( aProject->GetProjectPath() );
+envPath.SetPath( aProjectPath );
 
 if( normalizeAbsolutePaths( envPath, aFilePath,  ) )
 varName = PROJECT_VAR_NAME;
@@ -111,6 +110,15 @@ wxString NormalizePath( const wxFileName& aFilePath, const ENV_VAR_MAP* aEnvVars
 return normalizedFullPath;
 }
 
+wxString NormalizePath( const wxFileName& aFilePath, const ENV_VAR_MAP* aEnvVars,
+const PROJECT* aProject )
+{
+  if( aProject )
+return NormalizePath( aFilePath, aEnvVars, aProject->GetProjectPath() );
+  else
+return NormalizePath( aFilePath, aEnvVars, "" );
+}
+
 
 // Create file path by appending path and file name. This approach allows the filename
 // to contain a relative path, whereas wxFileName::SetPath() would replace the
diff --git a/include/env_paths.h b/include/env_paths.h
index bac92ffca..a27fbcc7c 100644
--- a/include/env_paths.h
+++ b/include/env_paths.h
@@ -39,6 +39,18 @@
 wxString NormalizePath( const wxFileName& aFilePath, const ENV_VAR_MAP* aEnvVars,
 const PROJECT* aProject );
 
+/**
+ * Normalizes a file path to an environmental variable, if possible.
+ *
+ * @param aFilePath is the full file path (path and file name) to be normalized.
+ * @param aEnvVars is an optional map of environmental variables to try substition with.
+ * @param aProjectPath is an optional string to normalize the file path to the project path.
+ * @return Normalized full file path (path and file name) if succeeded or empty string if the
+ *  path could not be normalized.
+ */
+wxString NormalizePath(
+const wxFileName& aFilePath, const ENV_VAR_MAP* aEnvVars, const wxString& aProjectPath );
+
 /**
  * Searches the default paths trying to find one with the requested file.
  *
@@ -48,7 +60,7 @@ wxString NormalizePath( const wxFileName& aFilePath, const ENV_VAR_MAP* aEnvVars
  * @return Full path (apth and file name) if the file was found in one of the paths, otherwise
  *  an empty string.
 */
-wxString ResolveFile( const wxString& aFileName, const ENV_VAR_MAP* aEnvVars,
-const PROJECT* aProject );
+wxString ResolveFile(
+const wxString& aFileName, const ENV_VAR_MAP* aEnvVars, const PROJECT* aProject );
 
 #endif /* ENV_PATHS_H */
diff --git a/pcbnew/dialogs/wizard_add_fplib.cpp b/pcbnew/dialogs/wizard_add_fplib.cpp
index 193253cb3..838222402 100644
--- a/pcbnew/dialogs/wizard_add_fplib.cpp
+++ b/pcbnew/dialogs/wizard_add_fplib.cpp
@@ -46,6 +46,7 @@
 #include 
 
 #include 
+#include 
 
 #ifdef BUILD_GITHUB_PLUGIN
 #include 

Re: [Kicad-developers] New Footprint libs and wizard issues

[kristoffer Ödmark]

Ah, I was using it wrong. I was looking for someway to start a new lib, 
not realising
I need to start a new footprint and then start a new lib from that. 
Thanks and sorry
for that. Although, would be nice to be able to start a new footprint in 
a new lib directly
when opening the footprint editor, I will add that as a wishlist, i 
noticed some of my friends

did the same when trying to create a new lib.

The other part doesnt work for me though. I have set a path called 
SHARED that
points to "/home/krille/projects/kicad_libs". I then use the wizard to 
add the lib located at

"/home/krille/projects/kicad_libs/footprints/antennas.pretty".

expected outcome is that the library path will become 
"${SHARED}/footprints/antennas.pretty"


outcome is that the library path become 
"/home/krille/projects/kicad_libs/footprints/antennas.pretty"



- Kristoffer

On 2018-04-04 11:02, jp charras wrote:

Le 04/04/2018 à 10:01, kristoffer Ödmark a écrit :

Hello!

So it was a while since I made some noise, so its time again.

Is there a way to create new footprint libs from KiCad? I cannot find it,
right now I create them by mkdir name.pretty, thento be able to add them
with the wizard, I have to create a temp.kicad_mod file in that folder.

Should this be considered a bug, and if so, would it go into v5? I would
like to be able to add/create empty libs, and then populate them all from within
kicad.

In footprint library, the third tool.
(Tooltip: Create new lib and save current footprint)


I also noticed that the wizard does not autoreplace the paths with the 
configured
paths in kicad the same way that the symbol library editor does. Should this 
also
be considered a bug and would a fix be accepted in v5?

- Kristoffer

It works for me.





___
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] New Footprint libs and wizard issues

[kristoffer Ödmark]

Hello!

So it was a while since I made some noise, so its time again.

Is there a way to create new footprint libs from KiCad? I cannot find it,
right now I create them by mkdir name.pretty, thento be able to add them
with the wizard, I have to create a temp.kicad_mod file in that folder.

Should this be considered a bug, and if so, would it go into v5? I would
like to be able to add/create empty libs, and then populate them all 
from within

kicad.

I also noticed that the wizard does not autoreplace the paths with the 
configured
paths in kicad the same way that the symbol library editor does. Should 
this also

be considered a bug and would a fix be accepted in v5?

- Kristoffer

___
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 lead developers

[Kristoffer Ödmark]

Congratulations! I am very glad to see this! I have been following the 
mailing list for a while now and seen the great contributions and ideas 
from you guys! Well deserved promotion!


 -Kristoffer

On 2018-03-02 15:05, David Novak wrote:

Great job guys! Thanks for your investment in the project.

David




On 3/2/2018 2:40 AM, Maciej Sumiński wrote:

Congratulations fellow developers! You have received well deserved
promotions, and I am glad to see your names in the
kicad-product-committers group. Keep on rocking!

Cheers,
Orson

On 03/01/2018 08:15 PM, Wayne Stambaugh wrote:

I am pleased to announce the promotion of three developers to the KiCad
lead development team.  Their efforts since joining the project have
really helped move KiCad forward.  They have shown excellent technical
skills and a willingness to cooperate with the development team.  Please
congratulate Jon Evans, Seth Hillbrand, and Jeff Young for their
promotion to the lead developers team.  Thank you gentlemen for all of
you hard work.

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





___
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] Pads front and F.Cu visibility, possible bugs?

[kristoffer Ödmark]

I started investigating this some more, there is much more rendering 
problems here.


for example, disbling rendering of front footprints disables all the 
F.Silk, F.Fab, adhesive and many more.


Disabling the rendering of Text on the front only disables text 
belonging to a footprint, no other. Basically the Render tab does not do 
what it says at all.


A lot of this seems to because of what is set in pcb_draw_panel_gal.cpp:417

There is a lot of SetRequired-> (layer, layer)

And that implementation seems broken, could someone shed some light on 
the purpose there?



On 2018-02-07 22:32, Kevin Cozens wrote:

On 2018-02-07 04:25 PM, Wayne Stambaugh wrote:

If you use legacy renderer then turn off Pads Front and Pads Back under
the Render tab on the right the pads disappear. If you are in GAL mode
they remain visible.



Given that the legacy canvas will hopefully be removed in the v6
development cycle, I guess this issue will go away.


True, but I wanted to point out that as far as I was concerned it 
hasn't always been this way. I would still expect the pads to 
disappear if I turn off display of front and back pads.


[Oops. Sending again as I meant to send it to the list.]




___
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] Schematic symbol chooser clarification

[kristoffer Ödmark]

Attached is a minimal patch that differs the dialog title.

- Kristoffer

On 2018-02-05 13:25, Marco Ciampa wrote:

On Mon, Feb 05, 2018 at 01:10:08PM +0100, kristoffer Ödmark wrote:

Hey!

I just spent some time trying to "debug" a library non-issue with a EE
switching from Altium for a test. He had added the libraries correctly, and
they showed up. But everytime he tried adding a symbol to the schematic, no
symbols was there. We sent pictures back and forth, and indeed the libraries
added, but did not show up.

To make a long hassle short, turns out the shortcut "P" is used to place
symbols in Altium, but to place Power symbols in kicad.
This is not an issue, however, there is no indication at all that the symbol
chooser is actually filtered or limited when using the shortcut key.

I think there could be benefits of adding some kind of visualization to the
symbol chooser that the list is limited to only power symbols, maybe just
changing the window title to something like "Choose Power Symbol" or the
more general term of adding the filter to the window name. Let me know what
you think

Also when you place a power symbol, the dialog shows normal symbols in
the history list, and it also permits to insert these symbols even if
they are not power symbols... that to me seems incoherent...



>From 0c0fe309e3ee9cc2286847f330d9310eefacb810 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= <kristoffer.odmar...@gmail.com>
Date: Thu, 8 Feb 2018 10:58:22 +0100
Subject: [PATCH] Differ the dialog text for when choosing power-symbols and
 all symbols

---
 eeschema/getpart.cpp | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/eeschema/getpart.cpp b/eeschema/getpart.cpp
index 4f54bb588..46dc53b58 100644
--- a/eeschema/getpart.cpp
+++ b/eeschema/getpart.cpp
@@ -159,7 +159,11 @@ SCH_BASE_FRAME::COMPONENT_SELECTION SCH_BASE_FRAME::SelectComponentFromLibrary(
 if( aHighlight && aHighlight->IsValid() )
 adapter->SetPreselectNode( *aHighlight, /* aUnit */ 0 );
 
-dialogTitle.Printf( _( "Choose Symbol (%d items loaded)" ), adapter->GetComponentsCount() );
+if( adapter->GetFilter() == CMP_TREE_MODEL_ADAPTER::CMP_FILTER_POWER )
+dialogTitle.Printf( _( "Choose Power Symbol (%d items loaded)" ), adapter->GetComponentsCount() );
+else
+dialogTitle.Printf( _( "Choose Symbol (%d items loaded)" ), adapter->GetComponentsCount() );
+
 DIALOG_CHOOSE_COMPONENT dlg( this, dialogTitle, adapter, aConvert, aAllowFields, aShowFootprints );
 
 if( dlg.ShowQuasiModal() == wxID_CANCEL )
-- 
2.16.1

___
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] Pads front and F.Cu visibility, possible bugs?

[Kristoffer Ödmark]

Hey!

Another confusion arised when I was speaking to a friend. When disabling 
the F.Cu layer, the pads are still visible. I can understand the need to 
be able to disable the pads on the front layer separate from everything 
else, to check for things under pads etc.


What I cannot understand is why the pads are visible if I want to 
disable the entire front layer in pcbnew, also if one wants transparent 
layers, one can actually se the compositioning for the front pads and 
front traces, and allowing them to be different colors also seem a bit 
confusing actually.


I could basically change the front pad colors to look like they belong 
to the back layer, I know its stupid, but this seems like the kind of 
thing one would not want to even be possible, except maybe for pranks.


TLDR;

Possible bugs:
1. pads not affected by layer visibility setting
2. pads and layer compositioning even when same setting
3. pads and corresponding layer color setting

Possible solution:
1. Both layer and pads setting must be enabled for pads to render.
2. Seems hard, Dont know
3. pads and layer share color setting, not necessarily opacity setting.

Comments on these?


--
 -Kristoffer

___
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] Schematic symbol chooser clarification

[kristoffer Ödmark]

Yeah, that to adds to the confusion. I think maybe coherency should be 
one of the main goal for v6.



On 2018-02-05 13:25, Marco Ciampa wrote:

On Mon, Feb 05, 2018 at 01:10:08PM +0100, kristoffer Ödmark wrote:

Hey!

I just spent some time trying to "debug" a library non-issue with a EE
switching from Altium for a test. He had added the libraries correctly, and
they showed up. But everytime he tried adding a symbol to the schematic, no
symbols was there. We sent pictures back and forth, and indeed the libraries
added, but did not show up.

To make a long hassle short, turns out the shortcut "P" is used to place
symbols in Altium, but to place Power symbols in kicad.
This is not an issue, however, there is no indication at all that the symbol
chooser is actually filtered or limited when using the shortcut key.

I think there could be benefits of adding some kind of visualization to the
symbol chooser that the list is limited to only power symbols, maybe just
changing the window title to something like "Choose Power Symbol" or the
more general term of adding the filter to the window name. Let me know what
you think

Also when you place a power symbol, the dialog shows normal symbols in
the history list, and it also permits to insert these symbols even if
they are not power symbols... that to me seems incoherent...




___
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] Schematic symbol chooser clarification

[kristoffer Ödmark]

Hey!

I just spent some time trying to "debug" a library non-issue with a EE 
switching from Altium for a test. He had added the libraries correctly, 
and they showed up. But everytime he tried adding a symbol to the 
schematic, no symbols was there. We sent pictures back and forth, and 
indeed the libraries added, but did not show up.


To make a long hassle short, turns out the shortcut "P" is used to place 
symbols in Altium, but to place Power symbols in kicad.
This is not an issue, however, there is no indication at all that the 
symbol chooser is actually filtered or limited when using the shortcut key.


I think there could be benefits of adding some kind of visualization to 
the symbol chooser that the list is limited to only power symbols, maybe 
just changing the window title to something like "Choose Power Symbol" 
or the more general term of adding the filter to the window name. Let me 
know what you think


- Kristoffer


___
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] Update PCB from Schematic

[Kristoffer Ödmark]

It would be trivial if the "duplicate tool" either generated new unique 
identifiers or left the unique identfier value empty.


I honestly dont understand why to have unique identifiers if they are 
not unique, so maybe this should be a bug? I know they are referenced as 
"timestamps" in the code, but everywhere they are used, they seem to 
represent a unique identifier.


 -Kristoffer

On 01/23/2018 01:51 PM, Maciej Sumiński wrote:

I *think* it has been done to easily get board state coherent with
schematics, no questions asked. It means that it should delete
components that do not occur in the schematics.

Regarding the bug report: I suppose the duplicated components get the
same sheet path, so the netlist updater treats them as if they were
legit components placed in the schematics. Even if it could realize that
there are duplicates, it would be hard to decide which one is the
original to be kept.

On 01/23/2018 12:57 PM, Jeff Young wrote:

Ping.  (I’ll log a bug on this if I’m not crazy, but I just want to make sure I 
don’t have the wrong end of the stick first….)


On 13 Jan 2018, at 23:02, Jeff Young  wrote:

Update PCB from Schematic is a shortcut for eeschema Annotate + eeschema Write 
Netlist + pcbnew Read Netlist, right?

Is there a reason the Update PCB from Schematic dialog doesn’t include the 
“keep/delete” options we have in the Read Netlist dialog?

(It appears to mostly do a delete, but not entirely: 
https://bugs.launchpad.net/kicad/+bug/1682970 
 )






___
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] FYI: Horizon

[kristoffer Ödmark]

Yeah, just downloaded it and gave it a whirl.

This project really shows some promise! The "pool" idea actually shows 
some promise for library management.
I like how they want everything as parts. I will keep an eye on this. 
Might be something to learn and integrate into kicad!


- Kristoffer

On 2018-01-19 04:32, Chris Pavlina wrote:

Gonna be honest, it looks pretty cool so far...

On Thu, Jan 18, 2018 at 10:47:21PM +, Vesa Solonen wrote:

https://github.com/carrotIndustries/horizon

Must be interesting to see at FOSDEM...

-Vesa

___
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] Copy/paste eeshema block betwee two different application

[Kristoffer Ödmark]

I do see the value of copy pasting between schematics. Its very common 
for design reuse.


The way the copy-paste for pcbnew is done is like this:

Copy:
1. checks what items are selected.
2. check what requirements the selected items have( nets, layers etc)
3. this creates a new pcb file in memory with only the selected items ( 
using the regular parser)
4. instead of writing the pcb file to disk, it is written as plaintext 
to the clipboard.


Paste:
1. load the pcb file from clipboard as a regular pcb_file ( using the 
regular parser )
2. check what new nets layers etc are present in the file and add to 
current working pcb.

3. add each item to the pcb and to selection.
4. enter "move" mode for the current selection of items.

Maybe something similar can be done for the schematic, although I was 
lucky, because a lot of the functionality was already in pcbnew, so I 
only had to connect most of it in a more streamlined way.



The current way I copy paste between schematics is like this:
1. create new hierarchical schematic.
2. copy block ( ctrl+c )
3. enter new hierarchical schematic and paste there. save.
4. remove the hierarchical schematic from project.

Now you have your selection in the new scheet file, and can move it 
wherever you want. Not the most elegant solution, but since I usually 
create as much I can as "schematic modules" I have a small collection of 
schematics i add to a project to get the stuff I usually have.


With the work being done on improving the bus things in eeschema, I cant 
wait to improve my modules!


 -Kristoffer

On 01/18/2018 01:53 PM, Wayne Stambaugh wrote:

Hi Badr,

As far as I know, no one is working on this.  We still have a lot of
work to do just to get a full copy/paste implementation for each editor.
  I'm not sure copy/paste between eeschema applications has a lot of
value but there could be some overlap for graphical objects.  Copying a
pin from the symbol editor and pasting it in the schematic editor has no
meaning since pins are not schematic objects.  Pins are symbol objects
and only have meaning in library symbol objects.  Copy/paste between the
to editors will not be trivial to implement.

Cheers,

Wayne

On 1/17/2018 4:55 PM, Badr Hack wrote:

Hi,
I'd like to add the possibility to make a copy/paste of a block between
two different eeschema applications, or either to export a selected
block to a new .sch file.
Any idea if it is ongoing by someone, or a hint from where to start?
Thank you in advance,
Regards,
Badr

___
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] Libedit and Modedit Icons

[kristoffer Ödmark]

For me it feels more natural with thins flowing from left to right, so 
that means moving the import arrow to the left side, and also making it 
flowing into the document.


Export also flow from left to right, so making it flowing from inside 
the document to out on the right side. These are good goals.


I also find that when i load something, the closest analogy is to pick 
it up, and saving is putting it down. Note that these do however not 
flow into or out of any document. Unless you save it somewhere else, in 
that case it would flow out (export) and down (save) a combination of 
exportin and putting it down.


The current icons makes this much more clear and is much much more 
intuitive, but the two things you listed are important. I read someone 
claiming that the new icons wasnt well designed, I disagree. Sure there 
may be some design policy not being followed, I wouldnt know. But at 
least the icons now provide recognition and usability with less 
complexity. Which makes my work faster, since I dont have to read the 
tooltip every time. This is what is most important for me.


Thank you Oliver for taking your time and moving this forward.


On 2018-01-16 12:55, Jeff Young wrote:
I think the in/out axis is more important than the left/right axis. 
 So your suggestion would be an improvement.


On 16 Jan 2018, at 11:40, Oliver Walters 
> wrote:


I think you are all correct. During my revamp of the icons I tried to 
achieve two things:


1. Differentiate between import and export based on arrow direction 
(generally import arrows are right to left, and export are left to right)
2. Place import icons on the left, and export on the right (following 
the "flow" outlined in 1)


However this means that both arrows are effectively flowing "out of" 
the document.


I think that if the import icons are moved to the right hand side, 
then they will then look like they are flowing "into" the document.


Thoughts?

On Tue, Jan 16, 2018 at 9:10 PM, Jeff Young > wrote:


FWIW, I also agree that the current import arrow is backwards.

> On 16 Jan 2018, at 07:11, Marco Ciampa > wrote:
>
> Hi Oliver, your thoughts?
>
> On Mon, Jan 15, 2018 at 09:09:48AM +0100, jp charras wrote:
>> Le 15/01/2018 à 08:51, Marco Ciampa a écrit :
>>> Hi Oliver,
>>> about the bikeshedding thing I am not even a developer and I
have the
>>> audacity to say my thoughts about the icons!!!
>>>
>>> Follows my 0.002 euro cents
>>>
>>> My very humble opinion is that the import icon is not that
clear and can
>>> be improved alot in this way: just change the direction and
position of
>>> the arrow, the colour could stay as it is, it doesn't matter.
>>>
>>> I mean that the export icon is (almost) ok since it represent
what I
>>> expect in an "export" icon: the "out" direction is clear:
just describe
>>> an arrow that points _out_ of a document.
>>>
>>> Similarly the import icon should represent the "in"
direction: and arrow
>>> that point _into_ a document, not another arrow pointing out
of the same
>>> document but with a different color...
>>
>> I fully agree...
>>
>>>
>>> I mean (ascii art: see it with a monospaced font):
>>>
>>> Export:
>>>
>>> ||
>>> |        | |\
>>> |      |---| \
>>> |      |      \
>>> |      |      /
>>> |      |---| /
>>> |        | |/
>>> ||
>>>
>>> Import:
>>>
>>>  ||
>>>  | |\     |
>>> |---| \    |
>>> |      \   |
>>> |      /   |
>>> |---| /    |
>>>  | |/     |
>>>  ||
>>>
>>>
>>> I think this is much clearer...
>>>
>>> --
>>>
>>>
>>> Marco Ciampa
>>
>>
>> --
>> 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

>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> 
>
> GNU/Linux User #78271
> FSFE fellow #364
>
> 
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers

> Post to     : kicad-developers@lists.launchpad.net

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

[kristoffer Ödmark]

I have 2560x1440, 24" screens, I think those qualifies as high DPI?

The slider value is at 100, and the diag value is at 23. The icons are 
ish 5mm large.


But i guess that is uneccesary since It seems the scaling works as 
intended, I was just doing it wrong, so no errors, sorry :)


The scaling seems correct as well, 100 = 5mm, 150 = 7.5, 200 = 11, 
measured with a tape measure, so variance in size is expected.



Application: kicad
Version: (2018-01-11 revision a5b3d8e57)-master, debug build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 
libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0

Platform: Linux 4.9.74-2-MANJARO x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.65.1
    Curl: 7.57.0
    Compiler: GCC 7.2.1 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=OFF
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON


On 2018-01-11 01:13, Chris Pavlina wrote:

If your system DPI is already within a certain range it won't do
anything. Are you using a high DPI display? If it's not scaled
correctly, would you please share with me the diagnostic number reported
by the scale slider in eeschema prefs as well as a rough indication of
the icons' physical size? Thanks.

On Wed, Jan 10, 2018 at 11:16:46PM +0000, kristoffer Ödmark wrote:

Tried the patch, didnt really notice anything different though, I guess you
need to add some custom scaling for this to take effect?


On 2018-01-10 22:23, Chris Pavlina wrote:

Sure, assign me to it. I should have time to work on it tonight or
tomorrow.

On Wed, Jan 10, 2018 at 04:20:21PM -0500, Wayne Stambaugh wrote:

FYI, the edit footprint dialog in Pcbnew is not sized properly (at least
on windows) which I'm pretty sure is related to your recent HiDPI work.
Do you want me to file a bug report for it?

On 1/10/2018 2:01 PM, Chris Pavlina wrote:

By the way, I'm going to go ahead and push this tonight-ish if nobody
objects. I know it's on the big side, but due to my limited number of
machines to test on I really want time for user feedback. I'll be around
to put out any fires.

On Wed, Jan 10, 2018 at 11:07:49AM -0700, Chris Pavlina wrote:

Rebased patch attached.

On Tue, Jan 09, 2018 at 01:27:16PM +, Maciej Sumiński wrote:

Hi Chris,

The patch does not apply cleanly on the current master, would you rebase
it? Thanks in advance.

Cheers,
Orson

On 01/09/2018 03:43 AM, Chris Pavlina wrote:

Hi,

As discussed with Wayne earlier, I've attached a patch which adds simple
toolbar icon scaling so the toolbars are readable on high-DPI systems.

This is meant as a stopgap for 5.0, with plans to add proper scaled
icons in the 6.0 cycle. A function KiScaledBitmap() is added, which
works like KiBitmap() except it scales the bitmap according to the
calling window's font size. Controls have been added to all the main
applications to let the user select scaling manually (these were omitted
from smaller apps that didn't already have a place to put them).

In addition, in eeschema only, the pixel height of the system font is
shown in the options dialog for diagnostics. This is only for collecting
feedback before 5.0 release from users with different displays and will
be removed.

I would like to push this fairly soon, as I want to get as much user
feedback as possible before release. I have a limited number of systems
to test this on myself.



___
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


___
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



___
Ma

Re: [Kicad-developers] [PATCH] Implement primitive icon scaling for high DPI

[kristoffer Ödmark]

I have 2560x1440, 24" screens, I think those qualifies as high DPI?

The slider value is at 100, and the diag value is at 23. The icons are 
ish 5mm large.


But i guess that is uneccesary since It seems the scaling works as 
intended, I was just doing it wrong, so no errors, sorry :)


The scaling seems correct as well, 100 = 5mm, 150 = 7.5, 200 = 11, 
measured with a tape measure, so variance in size is expected.



Application: kicad
Version: (2018-01-11 revision a5b3d8e57)-master, debug build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 
libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0

Platform: Linux 4.9.74-2-MANJARO x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.65.1
    Curl: 7.57.0
    Compiler: GCC 7.2.1 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=OFF
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON


On 2018-01-11 01:13, Chris Pavlina wrote:

If your system DPI is already within a certain range it won't do
anything. Are you using a high DPI display? If it's not scaled
correctly, would you please share with me the diagnostic number reported
by the scale slider in eeschema prefs as well as a rough indication of
the icons' physical size? Thanks.

On Wed, Jan 10, 2018 at 11:16:46PM +0000, kristoffer Ödmark wrote:

Tried the patch, didnt really notice anything different though, I guess you
need to add some custom scaling for this to take effect?


On 2018-01-10 22:23, Chris Pavlina wrote:

Sure, assign me to it. I should have time to work on it tonight or
tomorrow.

On Wed, Jan 10, 2018 at 04:20:21PM -0500, Wayne Stambaugh wrote:

FYI, the edit footprint dialog in Pcbnew is not sized properly (at least
on windows) which I'm pretty sure is related to your recent HiDPI work.
Do you want me to file a bug report for it?

On 1/10/2018 2:01 PM, Chris Pavlina wrote:

By the way, I'm going to go ahead and push this tonight-ish if nobody
objects. I know it's on the big side, but due to my limited number of
machines to test on I really want time for user feedback. I'll be around
to put out any fires.

On Wed, Jan 10, 2018 at 11:07:49AM -0700, Chris Pavlina wrote:

Rebased patch attached.

On Tue, Jan 09, 2018 at 01:27:16PM +, Maciej Sumiński wrote:

Hi Chris,

The patch does not apply cleanly on the current master, would you rebase
it? Thanks in advance.

Cheers,
Orson

On 01/09/2018 03:43 AM, Chris Pavlina wrote:

Hi,

As discussed with Wayne earlier, I've attached a patch which adds simple
toolbar icon scaling so the toolbars are readable on high-DPI systems.

This is meant as a stopgap for 5.0, with plans to add proper scaled
icons in the 6.0 cycle. A function KiScaledBitmap() is added, which
works like KiBitmap() except it scales the bitmap according to the
calling window's font size. Controls have been added to all the main
applications to let the user select scaling manually (these were omitted
from smaller apps that didn't already have a place to put them).

In addition, in eeschema only, the pixel height of the system font is
shown in the options dialog for diagnostics. This is only for collecting
feedback before 5.0 release from users with different displays and will
be removed.

I would like to push this fairly soon, as I want to get as much user
feedback as possible before release. I have a limited number of systems
to test this on myself.



___
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


___
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



___
Ma

Re: [Kicad-developers] Libedit and Modedit Icons

[Kristoffer Ödmark]

Practially I would read this as:

Go back to the single calculator icon, instead of the +-= boxes.
Revert the camera icon to the "a" character, cleanup if wanted but dont 
change concept fundamentally.


Otherwise I went throught the old icons in my current build and checked 
them against the latest email. They are pretty similar, but much more 
polished and coherent, so I think that qualifies as being inside scope.


I like the gerber icon change, but that one, dont know if it is outside 
scope or not.


Wayne did i interpret correctly?

 -Kristoffer

On 01/10/2018 03:58 PM, Wayne Stambaugh wrote:

I see scope creep happening here.  I thought the original goal was to
make some minor tweaks to our existing icons not wholesale replacement
of the them.  I don't like the camera either.  I'm not a big fan of the
calculator icon.  Both of these icons looks completely out of place with
our other icons.  Please keep the scope of these changes in check.  If
we want to discuss an entirely new icon theme for v6, that's fine at the
appropriate time but not for v5.

On 1/10/2018 9:42 AM, Jeff Young wrote:

Splendid!

Although I agree with Kristoffer that the new bitmap2component icon
isn’t much help.  Import/Export is the one area where we’ve kept the
arrows (which I think is fine).  Given that, the pixelated “a” with an
import arrow would be perfect.

FWIW, this is one area where I disagree with Nick.  I did user interface
design and software architecture for Adobe for 25 years and in my
professional opinion, these icons are a HUGE improvement.

Cheers,
Jeff



On 10 Jan 2018, at 14:28, Oliver Walters
<oliver.henry.walt...@gmail.com
<mailto:oliver.henry.walt...@gmail.com>> wrote:

 Also, would it be too much to ask for getting the arrows, the
 diskette and the folder in the repo with the patch, basically if
 someone wants to create future icons. They could use the same
 arrows for any kind of export, import, save, inspect or view.


I have created a set of "common icons" for exactly this purpose :)
  


On Thu, Jan 11, 2018 at 1:27 AM, Kristoffer Ödmark
<kristofferodmar...@gmail.com <mailto:kristofferodmar...@gmail.com>>
wrote:

 Wow, really nice! Although, the icon for the bitmap2component
 basically looks like a screenshot symbol to me, or something
 related to a webcam.

 The old one isnt as polished, but I think it fits better.

 Also, would it be too much to ask for getting the arrows, the
 diskette and the folder in the repo with the patch, basically if
 someone wants to create future icons. They could use the same
 arrows for any kind of export, import, save, inspect or view.

 Basically to help get a icon theme thing going ;)



  -Kristoffer


 On 01/10/2018 03:13 PM, Oliver Walters wrote:

 Wayne,

 Here is the outcome of removing the save / load arrows and
 replacing with
 standard load / save icons.

 I have also further tweaked the main icons as per suggestions.

 Screenshots here:

 https://imgur.com/a/DzZhZ

 This is about as far as I want to go with this, please let me
 know if there
 are any outstanding issues that prevent me from submitting a
 patch.

 Thanks,
 Oliver

 On Wed, Jan 10, 2018 at 8:09 AM, Oliver Walters <
 oliver.henry.walt...@gmail.com
 <mailto:oliver.henry.walt...@gmail.com>> wrote:

 Ok, that's good to hear. I will take another look at the
 Gerber icons and
 otherwise see if anyone can suggest some simple clean
 replacements for the
 arrows. If not, I'll push a patch.

 On Wed, Jan 10, 2018 at 8:05 AM, Wayne Stambaugh
 <stambau...@gmail.com <mailto:stambau...@gmail.com>>
 wrote:

 One good thing about bitmaps is they are low risk
 (other than the
 complaining that will surely ensue) so we can merge
 them just about any
 time.  I don't want to wait too long so our doc images
 can be updated to
 reflect the changes so if we cannot come up with
 better alternatives to
 replace the arrows, I'm OK with leaving them as is and
 pushing it off
 until v6.

 Cheers,

 Wayne

 On 1/9/2018 3:31 PM, Jeff Young wrote:

 I think the changes are absolutely good in
 general, and I’d very much
 like to see them get merged.  Not that I have any
 control over that. ;)

 As for the arrows, I’d still really like to see
 them go away.  The
 colour isn’t the problem, it’s the arrows
   

Re: [Kicad-developers] Libedit and Modedit Icons

[Kristoffer Ödmark]

Wow, really nice! Although, the icon for the bitmap2component basically 
looks like a screenshot symbol to me, or something related to a webcam.


The old one isnt as polished, but I think it fits better.

Also, would it be too much to ask for getting the arrows, the diskette 
and the folder in the repo with the patch, basically if someone wants to 
create future icons. They could use the same arrows for any kind of 
export, import, save, inspect or view.


Basically to help get a icon theme thing going ;)



 -Kristoffer

On 01/10/2018 03:13 PM, Oliver Walters wrote:

Wayne,

Here is the outcome of removing the save / load arrows and replacing with
standard load / save icons.

I have also further tweaked the main icons as per suggestions.

Screenshots here:

https://imgur.com/a/DzZhZ

This is about as far as I want to go with this, please let me know if there
are any outstanding issues that prevent me from submitting a patch.

Thanks,
Oliver

On Wed, Jan 10, 2018 at 8:09 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:


Ok, that's good to hear. I will take another look at the Gerber icons and
otherwise see if anyone can suggest some simple clean replacements for the
arrows. If not, I'll push a patch.

On Wed, Jan 10, 2018 at 8:05 AM, Wayne Stambaugh 
wrote:


One good thing about bitmaps is they are low risk (other than the
complaining that will surely ensue) so we can merge them just about any
time.  I don't want to wait too long so our doc images can be updated to
reflect the changes so if we cannot come up with better alternatives to
replace the arrows, I'm OK with leaving them as is and pushing it off
until v6.

Cheers,

Wayne

On 1/9/2018 3:31 PM, Jeff Young wrote:

I think the changes are absolutely good in general, and I’d very much
like to see them get merged.  Not that I have any control over that. ;)

As for the arrows, I’d still really like to see them go away.  The
colour isn’t the problem, it’s the arrows themselves. ANY of the
alternatives discussed (that don’t include arrows) would be better.

Cheers,
Jeff.



On 9 Jan 2018, at 20:13, Oliver Walters
> wrote:

The coloured arrows were already in place, all I have done is made
them all the same "style". In fact, previously concepts like "save"
and "load" were conveyed both with a downward pointing arrow, and the
arrow colour was the only point of difference.

I thought I had made an improvement on what was already existing. My
intent was not to necessarily do a sweeping redesign.

If this is now an additional requirement I can make these not arrows,
but I'd like some direction on what to do instead. It will be hard to
fit a more detailed icon.

Other than this, what are your thoughts overall? Is it worth my time
pursuing this further? Are these changes good in general and can you
see them being merged?

On 10 Jan 2018 04:44, "Wayne Stambaugh" > wrote:

 On 1/9/2018 12:05 PM, Rene Pöschl wrote:
 > On 09/01/18 16:50, Wayne Stambaugh wrote:
 >> I'm with Jose on the arrows.  If we are going to use them,
 please don't
 >> make the all different colors.  I don't see how a blue left
 arrow versus
 >> a magenta right arrow conveys any meaning to the user.
 >>
 >
 > I like the idea of coloring them differently. For me this will
 give an
 > additional way to distinguish the buttons. (Some of them have
 only the
 > direction of the arrow as a difference. Which is easily
 overlooked.) I
 > hope having different colors will make it easier for my brain to
 > remember which button does what. (I can't tell you how often i
 clicked
 > load symbol instead of update symbol while working on the
 reorganization
 > of the official lib.)

 What information does the different color arrow convey?  If you are
 using different colors for contrast, that is one thing but just

making

 them different colors for informational purposes doesn't make any
 sense
 to me.  If you are trying convey information with different color
 buttons, what is the impact on users who are color blind.

 >
 > Maybe there is a better way to communicate differences but if
 buttons
 > look as similar as a lot of them currently do, adding
 differentiating
 > colors might help.
 >
 > ___
 > 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] Libedit and Modedit Icons

[Kristoffer Ödmark]

I think trying to replicate what this guy does here would be quite time 
saving wouldnt it?


http://scottbezek.blogspot.se/2016/04/automated-kicad-schematic-export.html

Basically scripting keypresses, and then using something like scrot to 
take a screenshot of the intended area. This would keep the docs in sync :)


 -Kristoffer

On 01/10/2018 02:19 PM, jp charras wrote:

Le 10/01/2018 à 13:55, Jörg Hermann a écrit :

Hello Oliver,

congrats on the huge improvement on the icons!
For further simplification I would remove the gray “paper-boundary” on 
schematic and worksheet icons, citing Jeff Young: “… adding visual complexity 
without any cognitive benefit”.

When Wayne refers to the doc team - I expect the icons are pulled in from the 
sources, so the doc is always in sync?


"so the doc is always in sync"
Of course no: icon sources are svg files, but toolbars, menus and many other 
pictures are created
only by screen copy (there are no other way).
And if pictures are containing texts, screen copy update must be made for all 
languages.

So, be careful with modifying icons: be sure it is worth: the cost is *high*.



I would like to see and use them in the V5 release - what is holding back the 
commit?

Cheers,
Jörg




___
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] One more quick plug for reducing "Clarify Selection" dialogs

[kristoffer Ödmark]

Hmm, cannot compile, get a lot of undefiner references. Even after 
nuking the build dir.



../../common/libpcbcommon.a(class_pad.cpp.o): In function 
`D_PAD::HitTest(EDA_RECT const&, bool, int) const':
kicad/pcbnew/class_pad.cpp:982: undefined reference to 
`TestPointInsidePolygon(wxPoint const*, int, wxPoint const&)'
../../common/libpcbcommon.a(class_zone.cpp.o): In function 
`ZONE_CONTAINER::Hatch()':
kicad/pcbnew/class_zone.cpp:1219: undefined reference to 
`FindLineSegmentIntersection(double, double, int, int, int, int, 
double*, double*, double*, double*, double*)'
../../common/libcommon.a(shape_poly_set.cpp.o): In function 
`SHAPE_POLY_SET::convertToClipper(SHAPE_LINE_CHAIN const&, bool)':
kicad/common/geometry/shape_poly_set.cpp:466: undefined reference to 
`ClipperLib::Orientation(std::vector<ClipperLib::IntPoint, 
std::allocator > const&)'
kicad/common/geometry/shape_poly_set.cpp:467: undefined reference to 
`ClipperLib::ReversePath(std::vector<ClipperLib::IntPoint, 
std::allocator >&)'
../../common/libcommon.a(shape_poly_set.cpp.o): In function 
`SHAPE_POLY_SET::booleanOp(ClipperLib::ClipType, SHAPE_POLY_SET const&, 
SHAPE_POLY_SET::POLYGON_MODE)':
kicad/common/geometry/shape_poly_set.cpp:489: undefined reference to 
`ClipperLib::Clipper::Clipper(int)'



On 2018-01-09 19:22, Wayne Stambaugh wrote:

Does the patch resolve your issue?

On 1/9/2018 1:21 PM, kristoffer Ödmark wrote:

Yes, I can reproduce this with very thick tracks!


On 2018-01-09 16:55, Jeff Young wrote:

Hi Kristoffer,

That’s odd.  Did you try it with your mouse pointer directly over the
corner?  (You may need a reasonably thick track for this to happen.
Try something on the order of 2mm.)

Without my change the selection disambiguation is run *before* we know
it’s a drag action on a simple corner, so the selection_tool thinks it
needs to know which of the two segments is to be selected.

Cheers,
Jeff.



On 9 Jan 2018, at 15:37, Kristoffer Ödmark
<kristofferodmar...@gmail.com> wrote:

If i understand him correctly that would only be when on a corner, I
think it would be the desired behaviour.

Although, when I try it on my build on my laptop, there is no clarify
selection menu popping up when trying do drag ( 'd' ) or such on
corners. Not in opengl anywas. So I dont know.

Application: kicad
Version: (2017-12-30 revision b55eb0b5f)-master, release build
Libraries:
     wxWidgets 3.0.3
     libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4
libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0
Platform: Linux 4.14.12-1-MANJARO x86_64, 64 bit, Little endian, wxGTK
Build Info:
     wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+
2.24
     Boost: 1.65.1
     Curl: 7.57.0
     Compiler: GCC 7.2.1 with C++ ABI 1011

Build settings:
     USE_WX_GRAPHICS_CONTEXT=OFF
     USE_WX_OVERLAY=OFF
     KICAD_SCRIPTING=ON
     KICAD_SCRIPTING_MODULES=ON
     KICAD_SCRIPTING_WXPYTHON=ON
     KICAD_SCRIPTING_ACTION_MENU=ON
     BUILD_GITHUB_PLUGIN=ON
     KICAD_USE_OCE=ON
     KICAD_SPICE=ON


-Kristoffer

On 01/09/2018 04:27 PM, Wayne Stambaugh wrote:

Jeff,
Have actually confirmed that this is the desired behavior for this
outside of you own objectives?  I'm not saying that this is or isn't a
good idea but I personally don't drag trace corners around so I'm not
sure what the appropriate behavior should be.  You should get comments
from the dev list and users before you make a change like this.  As far
as pushing this to the dev repo, if it's not too invasive I will
consider it.  If it is a large change set, I would prefer that we hold
off until after the stable release.
Thanks,
Wayne
On 1/8/2018 5:49 AM, Jeff Young wrote:

Wayne, if I could get you to don that old project manager’s hat one
more time:

If we’re still weeks out from declaring an RC, I wanted to make one
more plug for getting rid of the Clarify Selection dialog when
dragging corners or using ‘U’ or ‘I’ over a corner[1].

While it’s marked Wishlist, it seriously impacts productivity when
editing tracks, and I think most users would consider it a bug
(particularly in the corner case when dragging the corner is
clearly moving both the tracks listed in the Clarify Selection menu).

I’ve been running the patch for about a week now with no issues.

Cheers,
Jeff.

[1] https://bugs.launchpad.net/kicad/+bug/1708869
___
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

Re: [Kicad-developers] One more quick plug for reducing "Clarify Selection" dialogs

[kristoffer Ödmark]

I just about to try :) hang on, got some merge conflicts on some local stuff


On 2018-01-09 19:22, Wayne Stambaugh wrote:

Does the patch resolve your issue?

On 1/9/2018 1:21 PM, kristoffer Ödmark wrote:

Yes, I can reproduce this with very thick tracks!


On 2018-01-09 16:55, Jeff Young wrote:

Hi Kristoffer,

That’s odd.  Did you try it with your mouse pointer directly over the
corner?  (You may need a reasonably thick track for this to happen.
Try something on the order of 2mm.)

Without my change the selection disambiguation is run *before* we know
it’s a drag action on a simple corner, so the selection_tool thinks it
needs to know which of the two segments is to be selected.

Cheers,
Jeff.



On 9 Jan 2018, at 15:37, Kristoffer Ödmark
<kristofferodmar...@gmail.com> wrote:

If i understand him correctly that would only be when on a corner, I
think it would be the desired behaviour.

Although, when I try it on my build on my laptop, there is no clarify
selection menu popping up when trying do drag ( 'd' ) or such on
corners. Not in opengl anywas. So I dont know.

Application: kicad
Version: (2017-12-30 revision b55eb0b5f)-master, release build
Libraries:
     wxWidgets 3.0.3
     libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4
libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0
Platform: Linux 4.14.12-1-MANJARO x86_64, 64 bit, Little endian, wxGTK
Build Info:
     wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+
2.24
     Boost: 1.65.1
     Curl: 7.57.0
     Compiler: GCC 7.2.1 with C++ ABI 1011

Build settings:
     USE_WX_GRAPHICS_CONTEXT=OFF
     USE_WX_OVERLAY=OFF
     KICAD_SCRIPTING=ON
     KICAD_SCRIPTING_MODULES=ON
     KICAD_SCRIPTING_WXPYTHON=ON
     KICAD_SCRIPTING_ACTION_MENU=ON
     BUILD_GITHUB_PLUGIN=ON
     KICAD_USE_OCE=ON
     KICAD_SPICE=ON


-Kristoffer

On 01/09/2018 04:27 PM, Wayne Stambaugh wrote:

Jeff,
Have actually confirmed that this is the desired behavior for this
outside of you own objectives?  I'm not saying that this is or isn't a
good idea but I personally don't drag trace corners around so I'm not
sure what the appropriate behavior should be.  You should get comments
from the dev list and users before you make a change like this.  As far
as pushing this to the dev repo, if it's not too invasive I will
consider it.  If it is a large change set, I would prefer that we hold
off until after the stable release.
Thanks,
Wayne
On 1/8/2018 5:49 AM, Jeff Young wrote:

Wayne, if I could get you to don that old project manager’s hat one
more time:

If we’re still weeks out from declaring an RC, I wanted to make one
more plug for getting rid of the Clarify Selection dialog when
dragging corners or using ‘U’ or ‘I’ over a corner[1].

While it’s marked Wishlist, it seriously impacts productivity when
editing tracks, and I think most users would consider it a bug
(particularly in the corner case when dragging the corner is
clearly moving both the tracks listed in the Clarify Selection menu).

I’ve been running the patch for about a week now with no issues.

Cheers,
Jeff.

[1] https://bugs.launchpad.net/kicad/+bug/1708869
___
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

___
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] One more quick plug for reducing "Clarify Selection" dialogs

[kristoffer Ödmark]

Yes, I can reproduce this with very thick tracks!


On 2018-01-09 16:55, Jeff Young wrote:

Hi Kristoffer,

That’s odd.  Did you try it with your mouse pointer directly over the corner?  
(You may need a reasonably thick track for this to happen.  Try something on 
the order of 2mm.)

Without my change the selection disambiguation is run *before* we know it’s a 
drag action on a simple corner, so the selection_tool thinks it needs to know 
which of the two segments is to be selected.

Cheers,
Jeff.



On 9 Jan 2018, at 15:37, Kristoffer Ödmark <kristofferodmar...@gmail.com> wrote:

If i understand him correctly that would only be when on a corner, I think it 
would be the desired behaviour.

Although, when I try it on my build on my laptop, there is no clarify selection 
menu popping up when trying do drag ( 'd' ) or such on corners. Not in opengl 
anywas. So I dont know.

Application: kicad
Version: (2017-12-30 revision b55eb0b5f)-master, release build
Libraries:
wxWidgets 3.0.3
libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 
(+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0
Platform: Linux 4.14.12-1-MANJARO x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.65.1
Curl: 7.57.0
Compiler: GCC 7.2.1 with C++ ABI 1011

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_SPICE=ON


-Kristoffer

On 01/09/2018 04:27 PM, Wayne Stambaugh wrote:

Jeff,
Have actually confirmed that this is the desired behavior for this
outside of you own objectives?  I'm not saying that this is or isn't a
good idea but I personally don't drag trace corners around so I'm not
sure what the appropriate behavior should be.  You should get comments
from the dev list and users before you make a change like this.  As far
as pushing this to the dev repo, if it's not too invasive I will
consider it.  If it is a large change set, I would prefer that we hold
off until after the stable release.
Thanks,
Wayne
On 1/8/2018 5:49 AM, Jeff Young wrote:

Wayne, if I could get you to don that old project manager’s hat one more time:

If we’re still weeks out from declaring an RC, I wanted to make one more plug 
for getting rid of the Clarify Selection dialog when dragging corners or using 
‘U’ or ‘I’ over a corner[1].

While it’s marked Wishlist, it seriously impacts productivity when editing 
tracks, and I think most users would consider it a bug (particularly in the 
corner case when dragging the corner is clearly moving both the tracks listed 
in the Clarify Selection menu).

I’ve been running the patch for about a week now with no issues.

Cheers,
Jeff.

[1] https://bugs.launchpad.net/kicad/+bug/1708869
___
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] Renaming headers?

[Kristoffer Ödmark]

Now that you say it, indeed the class prefix is kinda stupid, but at 
least it helps when doing ls, since they are grouped in one place, 
whatever the name after class_ :)


Sorting them by function would be the best i guess, I would suggest that 
the commit(s) that is exactly where rc1 branches off be the one with 
these changes, since there will be major confusion with patches otherwise.


I would lend support here, but I doubt I would be much help. But I would 
very much like to see a sorting/renaming etc here, I think it would help 
in attracting new devs as well, I remember getting stuck on the 
Legacy/GAL stuff in the very beginning, not finding what was where.


 -Kristoffer

On 01/09/2018 05:02 PM, Tomasz Wlostowski wrote:

On 09/01/18 16:21, Kristoffer Ödmark wrote:

Oh I was not planning on doing this, I am way to new to do a good job of
sorting the codebase. Just wanted to see if there have been anyone else
thinking in these lines. Currently in the pcbnew folder, the files seems
to be grouped by their names, which is also fine. I would just enjoy if
the files where grouped into folders more. there are currently 200+
files in the pcbnew root directory.

For example:
 9 files starting with specctra
 47 files starting with class
 29 files starting with pcb



Hey,

I would vote for moving the files into folders grouped by functionality.
For example:
- board/ - board model (class_board, track, via, etc) + core algorithms
(zone filling, connectivity, ratsnest)
- io/ - all I/O plugins and exporters (in separate subdirectories) +
plugin management code
- io/kicad - kicad plugin
- io/legacy - legacy plgugin
- io/exporters/specctra - specctra export code
- io/importers/eagle - eagle import code
- view/ - GAL display code
- tools/ - all GAL tools
- legacy/ - all legacy tools/canvas code
- ui/ - wx-specific user interface stuff (dialogs, frames, etc.).

If we go for separate subfolders, I'd also suggest removing the class_
prefixes from the file names. All of the new code is OOP, so each source
file contains a class (or more).

In the long term, we could also eliminate linking dependencies between
these folders (so that class BOARD has no dependency on the GUI, etc).

Cheers,
Tom



___
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] One more quick plug for reducing "Clarify Selection" dialogs

[Kristoffer Ödmark]

If i understand him correctly that would only be when on a corner, I 
think it would be the desired behaviour.


Although, when I try it on my build on my laptop, there is no clarify 
selection menu popping up when trying do drag ( 'd' ) or such on 
corners. Not in opengl anywas. So I dont know.


Application: kicad
Version: (2017-12-30 revision b55eb0b5f)-master, release build
Libraries:
wxWidgets 3.0.3
libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 
libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.29.0

Platform: Linux 4.14.12-1-MANJARO x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.65.1
Curl: 7.57.0
Compiler: GCC 7.2.1 with C++ ABI 1011

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_SPICE=ON


 -Kristoffer

On 01/09/2018 04:27 PM, Wayne Stambaugh wrote:

Jeff,

Have actually confirmed that this is the desired behavior for this
outside of you own objectives?  I'm not saying that this is or isn't a
good idea but I personally don't drag trace corners around so I'm not
sure what the appropriate behavior should be.  You should get comments
from the dev list and users before you make a change like this.  As far
as pushing this to the dev repo, if it's not too invasive I will
consider it.  If it is a large change set, I would prefer that we hold
off until after the stable release.

Thanks,

Wayne

On 1/8/2018 5:49 AM, Jeff Young wrote:

Wayne, if I could get you to don that old project manager’s hat one more time:

If we’re still weeks out from declaring an RC, I wanted to make one more plug 
for getting rid of the Clarify Selection dialog when dragging corners or using 
‘U’ or ‘I’ over a corner[1].

While it’s marked Wishlist, it seriously impacts productivity when editing 
tracks, and I think most users would consider it a bug (particularly in the 
corner case when dragging the corner is clearly moving both the tracks listed 
in the Clarify Selection menu).

I’ve been running the patch for about a week now with no issues.

Cheers,
Jeff.

[1] https://bugs.launchpad.net/kicad/+bug/1708869
___
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] Renaming headers?

[Kristoffer Ödmark]

Oh I was not planning on doing this, I am way to new to do a good job of 
sorting the codebase. Just wanted to see if there have been anyone else 
thinking in these lines. Currently in the pcbnew folder, the files seems 
to be grouped by their names, which is also fine. I would just enjoy if 
the files where grouped into folders more. there are currently 200+ 
files in the pcbnew root directory.


For example:
9 files starting with specctra
47 files starting with class
29 files starting with pcb

I know you cant sort directly like that, but it gives a bit of an overview.

Anyway, I just wanted to see what anyone thought about it, if a renaming 
was to happen, a good time for something like this might be around the 
same time.


 -Kristoffer

On 01/09/2018 04:08 PM, Wayne Stambaugh wrote:

On 1/9/2018 10:01 AM, Kristoffer Ödmark wrote:

Quite a bit of files under the root directory that could benefit from
some sorting as well :) Would be two patches then, one for renaming, and
one for sorting them somehow, both kinda large.

Maybe move classes to a folder called classes?


Please do not do this unless you are grouping related code such as the
swig/ folder in pcbnew/ or the netlist_exporters/ folder in eeschema.



  -Kristoffer

On 01/09/2018 02:59 AM, Wayne Stambaugh wrote:

On 1/8/2018 8:06 PM, Chris Pavlina wrote:

Hi,

Soonish, I'd like to go through and rename header files to actually
match the names of the classes they define. It's a bit...unobvious that
PCB_EDIT_FRAME is in wxPcbStruct.h, for instance. Now, because this
would be a pretty large patch, I'd normally hold on until after 5.0 is
released, but I think it'd actually be best to get this in BEFORE 5.0,
because moving that many things around immediately after 5.0 would draw
a line in the history through which bugfix backports onto the 5.0 series
become difficult. The very end of the 4.0 series seems like a perfect
place. Because it's just a (large) rename, I think it has a relatively
small likelihood of actually breaking anything - either it compiles or
it doesn't, no change in functionality.

Wayne, would you be okay with this?



Chris,

I'm OK with this since it's not really a code change.  I agree that it
makes more sense to do it now rather than to wait and create major
headaches when back porting bug fixes from the v6 development branch.

Thanks,

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



___
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] Renaming headers?

[Kristoffer Ödmark]

Quite a bit of files under the root directory that could benefit from 
some sorting as well :) Would be two patches then, one for renaming, and 
one for sorting them somehow, both kinda large.


Maybe move classes to a folder called classes?

 -Kristoffer

On 01/09/2018 02:59 AM, Wayne Stambaugh wrote:

On 1/8/2018 8:06 PM, Chris Pavlina wrote:

Hi,

Soonish, I'd like to go through and rename header files to actually
match the names of the classes they define. It's a bit...unobvious that
PCB_EDIT_FRAME is in wxPcbStruct.h, for instance. Now, because this
would be a pretty large patch, I'd normally hold on until after 5.0 is
released, but I think it'd actually be best to get this in BEFORE 5.0,
because moving that many things around immediately after 5.0 would draw
a line in the history through which bugfix backports onto the 5.0 series
become difficult. The very end of the 4.0 series seems like a perfect
place. Because it's just a (large) rename, I think it has a relatively
small likelihood of actually breaking anything - either it compiles or
it doesn't, no change in functionality.

Wayne, would you be okay with this?



Chris,

I'm OK with this since it's not really a code change.  I agree that it
makes more sense to do it now rather than to wait and create major
headaches when back porting bug fixes from the v6 development branch.

Thanks,

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



___
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] Libedit and Modedit Icons

[Kristoffer Ödmark]

>> <mailto:pavlina.ch...@gmail.com
 <mailto:pavlina.ch...@gmail.com>>> wrote:
 >>>
 >>> I wish we had something resembling a

policy for

 >>> icons. It seems like
 >>> someone always wants to change them. We had
 >>> decent icons for these
 >>> _before_, and then someone submitted new

ones,

 >>> and they were accepted
 >>> because... I don't know? Many of the new

icons

 >>> are really ambiguous and
 >>>     kind of useless. Shouldn't have been

merged.

 >>>
 >>>
 >>> This is why I'm pushing for *a* change and not

*my*

 >>> change, I remember how the argument went last

time,

 >>> before they were silently merged.
 >>>
 >>> I also note that there is a lack of consistency
 >>> between similar icons. e.g. there are many

icons

 >>> which incorporate an arrow but the style/shape
 of the
 >>> arrows varies.
 >>>
 >>> For the record, I like these proposed

ones. They

 >>> bring back the ability
 >>> to recognize them at a glance.
 >>>
 >>> On Sat, Jan 06, 2018 at 05:52:49PM +,
 >>> kristoffer Ödmark wrote:
 >>> > I would love to see improved icons, I

still

 >>> never get used to them so i read
 >>> > the tooltip, newer know which one is pcb

and

 >>> which one is module editor.
 >>> >
 >>> > Luckily most of the time I only need to

double

 >>> click the kicad_pcb file
 >>> > anyway :)
 >>> >
 >>> >
 >>> > On 2018-01-06 15:08, Nick Østergaard

wrote:

 >>> > > 2018-01-06 14:15 GMT+01:00 Jeff Young
 >>> <j...@rokeby.ie <mailto:j...@rokeby.ie>
 <mailto:j...@rokeby.ie <mailto:j...@rokeby.ie>>
 >>> > > <mailto:j...@rokeby.ie
 <mailto:j...@rokeby.ie> <mailto:j...@rokeby.ie
 <mailto:j...@rokeby.ie>>>>:
 >>> > >
 >>> > > +1
 >>> > >
 >>> > > And I like Oliver’s proposed

icons.  I’d

 >>> suggest two further
 >>> > > changes though:
 >>> > >
 >>> > > 1) The schematic icon (which Oliver
 >>> didn’t change) should really
 >>> > > use the default colours (dark red
 >>> symbols, green wires).  Then
 >>> > > there’s a stronger tie-in with the
 >>> libedit icon.
 >>> > >
 >>> > > 2) I think I’d drop the dimensions

from

 >>> the modedit icon, and
 >>> > > change the pad colour to the

default

 >>> (yellow).
 >>> > >
 >>> > >
 >>> > > The default pad color is not yellow,

that is

 >>> only what you see for THT
 >>> > > pads. Default pad color is green for

bottom

 >>> and red for top copper
 >>> > >
 >>> > >
 >>> > > 3) Projects should use the current

New

 >>> Project icon, rather than
 >>> > > the application icon.
 >>> > >
 >>

Re: [Kicad-developers] [PATCH] Add bidirectional net highlight cross-probing

[kristoffer Ödmark]

I was just expecting the net to be highlighted when i filed the report, 
I have a memory of being able to do this on a previous nightly, nothing 
else.


But after the comments, maybe I remember wrong? Jumping around in the 
schematic when highlighting net is not something I want at least. I 
rather just have it highlighted and manually move around.
Actually I would prefer if the pcbnew highlight didnt even zoom, I would 
like to just see if a line of this net is crossing where I am currently 
zoom, otherwise I can manually zoom to fit the pcb to the highlight.


my 2 cents, thanks for creating a patch for this though!

- Kristoffer


On 2018-01-07 15:50, Jon Evans wrote:
Now we are really straying into new-feature land...  as far as I can 
tell, there is no code in eeschema for "locate and zoom to fit a net".
I could pick some random object on the net and locate that without 
much code, but is that the behavior we want? (especially for nets that 
exist on multiple sheets)


-Jon

On Sun, Jan 7, 2018 at 9:02 AM, Nick Østergaard > wrote:


Hi Jon,

I just tested this woth both patches applied. It seems that
selecting nets in eeschema the zoom to view works good in pcbnew,
but the other way around not so well. It does not always zoom to
the net in eeschema when selecing nets in pcbnew.

2018-01-07 3:30 GMT+01:00 Jon Evans >:

Hi Wayne,

Give this patch a try on top of my first one and see if it
does what you want.

-Jon

On Sat, Jan 6, 2018 at 8:58 PM, Chris Pavlina
> wrote:

On Sun, Jan 07, 2018 at 01:48:34AM +, Jon Evans wrote:
> Do I get a pass if I did this because I was browsing the
bug list looking
> for more things to fix? ;-)

I suppose so, I disagree with it having been classified as
a bug but
that's not your fault ;)

>
> Wayne, I'll work on the recentering in PcbNew, it
shouldn't be too much to
> add.
>
> On Sat, Jan 6, 2018 at 7:45 PM, Chris Pavlina
>
> wrote:
>
> > I like it too, I just worry that by accepting even
small features during
> > freeze we're encouraging people to do things that
aren't bugfixes and
> > release cleanup...
> >
> > On Sun, Jan 07, 2018 at 12:35:58AM +, Wayne
Stambaugh wrote:
> > > Jon,
> > >
> > > I just tested this and I like it!  It doesn't seem
like a high risk
> > > feature so if now one objects I'm going to merge
it.  If you have time,
> > > I do have one minor request.  When highlighting a
net in the board
> > > editor, if the net in the schematic editor is
scrolled of the display,
> > > the schematic editor centers the net so you can see
it. The same thing
> > > does not happen when a net is highlighted in the
schematic editor and
> > > the net on the board is scrolled off the display. 
Would you please fix
> > > this so the net in the board editor is centered on
the display when the
> > > net in the schematic editor is selected.
> > >
> > > Thanks,
> > >
> > > Wayne
> > >
> > > On 01/06/2018 03:52 PM, Jon Evans wrote:
> > > > I implemented this in response to a bug report:
> > > > https://bugs.launchpad.net/kicad/+bug/1738875

> > > >
> > > > But it is kind of on a blurred line between bug
fix and new feature.
> > > > I'll leave it up to Wayne et. al. to decide on if
to merge this for V5.
> > > >
> > > > Basically, beforehand, cross-probing highlighted
nets only if you
> > > > clicked on a component pad.
> > > > Now there is a separate cross-probing message for
a net name, so that
> > if
> > > > the highlight tool is selected in both eeschema
and pcbnew, selecting
> > > > any part of a net will cross-probe.
> > > >
> > > > -Jon
> > > >
> > > >
> > > > ___
> > > > Mailing list:
https://launchpad.net/~kicad-developers

> > > > Post to     : 

Re: [Kicad-developers] Libedit and Modedit Icons

[kristoffer Ödmark]

I agree on all of this points, unsure about the GBR, but i think it 
might help in the same way that the netlist icon has "NET".


In addition the DRC ladybug icon could use the letters DRC.

The current set of icons are really "engineer-icons" as i like to call 
them, they try to tell the entire function-set of the program/product, 
instead of an icons purpose of being easier/faster to recognize than 
reading its name. Almost every Technical researcher and Engineer i have 
met falls for this, including me.


Also, not many icons actually do better than a 3 letter 
word/abbreviation as long as it is very common knowledge.


Just my opinions, feel free to discard them if you like :)

Ps. thank you Oliver for putting in the time here. Everytime i present a 
student to KiCad the icons are actually confusing them more than helping 
from what I see.


- Kristoffer


On 2018-01-07 10:59, Jeff Young wrote:

+1 to eeschema icon changes

+1 to reverting libedit and modedit, but with no pencils

+1 to no magnifying glass  (the drill file, net and BOM icons all have 
three letters on them; I’m sure GBR would fit on the gerber icon)


I still think we need to change the project icon in the navigation to 
something similar to the New Project icons (instead of the application 
icon).


Kudos to Oliver for spear-heading this.

Cheers,
Jeff.

On 7 Jan 2018, at 08:32, Andrey Kuznetsov <kandre...@gmail.com 
<mailto:kandre...@gmail.com>> wrote:


I agree, no pencils, no magnifying glass.

By the way, anyone else thinks the .lib file icons in the navigation 
looks weird? If it's meant to look like a few stacked books, why are 
they tilted in weird directions?


On Sun, Jan 7, 2018 at 12:26 AM, Simon Wells <swel...@gmail.com 
<mailto:swel...@gmail.com>> wrote:


if the modedit/libedit icons are to be reverted then i believe
the pencils should be removed, seeing as they were used to
portray edit i believe but now that pcbnew/eeschema don’t have
them they just seem odd


On 7/01/2018, at 2:28 PM, Nick Østergaard <oe.n...@gmail.com
<mailto:oe.n...@gmail.com>> wrote:

I have been intending to revert the annotate icon in eeschema to
the old one, which made much more sense to me thatn the current one.

2018-01-07 1:24 GMT+01:00 Oliver Walters
<oliver.henry.walt...@gmail.com
<mailto:oliver.henry.walt...@gmail.com>>:

I have attached a patchset which performs the following:

1. Revert libedit icon to previous version
2. Revert modedit icon to previous version
3. Updates pcbnew icon to look more like a PCB
4. Update colors of eeschema icon
5. Various (almost imperceptible) tweaks to a number of
icons to fix graphic alignment issues

Here is a screenshot of the updated icons:







On Sun, Jan 7, 2018 at 8:34 AM, Oliver Walters
<oliver.henry.walt...@gmail.com
<mailto:oliver.henry.walt...@gmail.com>> wrote:

On 7 Jan 2018 05:04, "Chris Pavlina"
<pavlina.ch...@gmail.com
<mailto:pavlina.ch...@gmail.com>> wrote:

I wish we had something resembling a policy for
icons. It seems like
someone always wants to change them. We had decent
icons for these
_before_, and then someone submitted new ones, and
they were accepted
because... I don't know? Many of the new icons are
really ambiguous and
kind of useless. Shouldn't have been merged.


This is why I'm pushing for *a* change and not *my*
change, I remember how the argument went last time,
before they were silently merged.

I also note that there is a lack of consistency between
similar icons. e.g. there are many icons which
incorporate an arrow but the style/shape of the arrows
varies.

For the record, I like these proposed ones. They
bring back the ability
    to recognize them at a glance.

On Sat, Jan 06, 2018 at 05:52:49PM +, kristoffer
Ödmark wrote:
> I would love to see improved icons, I still never
get used to them so i read
> the tooltip, newer know which one is pcb and which
one is module editor.
>
> Luckily most of the time I only need to double
click the kicad_pcb file
> anyway :)
>
>
> On 2018-01-06 15:08, Nick Østergaard wrote:
> > 2018-01-06 14:15 GMT+01:00 Jeff Young
<j...@rokeby.ie <mailto:j...@rokeby.ie>
> > <mailto:j...@rokeby

Re: [Kicad-developers] Via dialog to support

[kristoffer Ödmark]

Attached patch that implements the via choices, they seem to render fine 
and work as expected under linux.


I guess that not many tests with different vias, since they have been 
hard to use, and usually only used for larger projects. So please test 
this a bit.


I found 1 bug/feature missing when doing this, the DRC doesnt warn if 
there are vias that are buried are on the board, but not allowed in the 
design rules.


I will file a bug report.

On 2018-01-06 21:51, Wayne Stambaugh wrote:

On 01/06/2018 02:46 PM, Tomasz Wlostowski wrote:

On 06/01/18 20:41, kristoffer Ödmark wrote:

The menu for the vias have the via type choice disabled, I cannot change
the via type from through via to buried via. It is grey.


Sorry, it's not implemented yet... Help appreciated.

This is going to have to fixed before stable v5.  We cannot release with
a partially implemented feature.


Tom

- Kristoffer


On 2018-01-06 20:26, Wayne Stambaugh wrote:

What do you mean by can't get it to work.  Is the via type not changing
or is it something else.  Are you setting the layers correctly for a
buried/blind via?

On 01/06/2018 01:03 PM, kristoffer Ödmark wrote:

Hello!

I just tested changin a via to a buried/blind via but I cannot get it to
work, Is this a bug or am I missing something?. I have enabled the
blind/buried via in the design rules.

- Kristoffer


___
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


___
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


>From a4cc28ad33a664e7e7cd5ae5f4e74c03917be8a2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= <kristoffer.odmar...@gmail.com>
Date: Sat, 6 Jan 2018 23:32:22 +0100
Subject: [PATCH] Implemented missing via dialog functions

---
 pcbnew/class_track.cpp |  46 --
 pcbnew/class_track.h   |  13 +++
 pcbnew/dialogs/dialog_track_via_properties.cpp | 117 +
 3 files changed, 168 insertions(+), 8 deletions(-)

diff --git a/pcbnew/class_track.cpp b/pcbnew/class_track.cpp
index 2ae4cebd7..0d9cd254c 100644
--- a/pcbnew/class_track.cpp
+++ b/pcbnew/class_track.cpp
@@ -428,17 +428,22 @@ LSET VIA::GetLayerSet() const
 
 void VIA::SetLayerPair( PCB_LAYER_ID aTopLayer, PCB_LAYER_ID aBottomLayer )
 {
-if( GetViaType() == VIA_THROUGH )
-{
-aTopLayer= F_Cu;
-aBottomLayer = B_Cu;
-}
-
-if( aBottomLayer < aTopLayer )
-std::swap( aBottomLayer, aTopLayer );
 
 m_Layer = aTopLayer;
 m_BottomLayer = aBottomLayer;
+SanitizeLayers();
+}
+
+
+void VIA::SetTopLayer( PCB_LAYER_ID aLayer )
+{
+m_Layer = aLayer;
+}
+
+
+void VIA::SetBottomLayer( PCB_LAYER_ID aLayer )
+{
+m_BottomLayer = aLayer;
 }
 
 
@@ -464,6 +469,31 @@ void VIA::LayerPair( PCB_LAYER_ID* top_layer, PCB_LAYER_ID* bottom_layer ) const
 }
 
 
+PCB_LAYER_ID VIA::TopLayer() const
+{
+return m_Layer;
+}
+
+
+PCB_LAYER_ID VIA::BottomLayer() const
+{
+return m_BottomLayer;
+}
+
+
+void VIA::SanitizeLayers()
+{
+if( GetViaType() == VIA_THROUGH )
+{
+m_Layer= F_Cu;
+m_BottomLayer = B_Cu;
+}
+
+if( m_BottomLayer < m_Layer )
+std::swap( m_BottomLayer, m_Layer );
+}
+
+
 TRACK* TRACK::GetBestInsertPoint( BOARD* aPcb )
 {
 TRACK* track;
diff --git a/pcbnew/class_track.h b/pcbnew/class_track.h
index 67980d61f..e38ed6412 100644
--- a/pcbnew/class_track.h
+++ b/pcbnew/class_track.h
@@ -403,6 +403,9 @@ public:
  */
 void SetLayerPair( PCB_LAYER_ID aTopLayer, PCB_LAYER_ID aBottomLayer );
 
+void SetBottomLayer( PCB_LAYER_ID aLayer );
+void SetTopLayer( PCB_LAYER_ID aLayer );
+
 /**
  * Function LayerPair
  * Return the 2 layers used by  the via (the via actually uses
@@ -412,6 +415,16 @@ public:
  */
 void LayerPai

Re: [Kicad-developers] Via dialog to support

[kristoffer Ödmark]

I am implementing it now, just a question, what should be the logic 
behind micro vias? Not very familiar with those.


Can they go between any number of layers, or only adjecent ones? I will 
treat them like buried vias currently, so that they can go between any 
two layers.



On 2018-01-06 21:51, Wayne Stambaugh wrote:

On 01/06/2018 02:46 PM, Tomasz Wlostowski wrote:

On 06/01/18 20:41, kristoffer Ödmark wrote:

The menu for the vias have the via type choice disabled, I cannot change
the via type from through via to buried via. It is grey.


Sorry, it's not implemented yet... Help appreciated.

This is going to have to fixed before stable v5.  We cannot release with
a partially implemented feature.


Tom

- Kristoffer


On 2018-01-06 20:26, Wayne Stambaugh wrote:

What do you mean by can't get it to work.  Is the via type not changing
or is it something else.  Are you setting the layers correctly for a
buried/blind via?

On 01/06/2018 01:03 PM, kristoffer Ödmark wrote:

Hello!

I just tested changin a via to a buried/blind via but I cannot get it to
work, Is this a bug or am I missing something?. I have enabled the
blind/buried via in the design rules.

- Kristoffer


___
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


___
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] Via dialog to support

[kristoffer Ödmark]

Alright! I will have a look at it :)


On 2018-01-06 20:46, Tomasz Wlostowski wrote:

On 06/01/18 20:41, kristoffer Ödmark wrote:

The menu for the vias have the via type choice disabled, I cannot change
the via type from through via to buried via. It is grey.


Sorry, it's not implemented yet... Help appreciated.

Tom

- Kristoffer


On 2018-01-06 20:26, Wayne Stambaugh wrote:

What do you mean by can't get it to work.  Is the via type not changing
or is it something else.  Are you setting the layers correctly for a
buried/blind via?

On 01/06/2018 01:03 PM, kristoffer Ödmark wrote:

Hello!

I just tested changin a via to a buried/blind via but I cannot get it to
work, Is this a bug or am I missing something?. I have enabled the
blind/buried via in the design rules.

- Kristoffer


___
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] Via dialog to support

[kristoffer Ödmark]

The menu for the vias have the via type choice disabled, I cannot change 
the via type from through via to buried via. It is grey.


- Kristoffer


On 2018-01-06 20:26, Wayne Stambaugh wrote:

What do you mean by can't get it to work.  Is the via type not changing
or is it something else.  Are you setting the layers correctly for a
buried/blind via?

On 01/06/2018 01:03 PM, kristoffer Ödmark wrote:

Hello!

I just tested changin a via to a buried/blind via but I cannot get it to
work, Is this a bug or am I missing something?. I have enabled the
blind/buried via in the design rules.

- Kristoffer


___
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] Via dialog to support

[kristoffer Ödmark]

Hello!

I just tested changin a via to a buried/blind via but I cannot get it to 
work, Is this a bug or am I missing something?. I have enabled the 
blind/buried via in the design rules.


- Kristoffer


___
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] Libedit and Modedit Icons

[kristoffer Ödmark]

I would love to see improved icons, I still never get used to them so i 
read the tooltip, newer know which one is pcb and which one is module 
editor.


Luckily most of the time I only need to double click the kicad_pcb file 
anyway :)



On 2018-01-06 15:08, Nick Østergaard wrote:
2018-01-06 14:15 GMT+01:00 Jeff Young >:


+1

And I like Oliver’s proposed icons.  I’d suggest two further
changes though:

1) The schematic icon (which Oliver didn’t change) should really
use the default colours (dark red symbols, green wires).  Then
there’s a stronger tie-in with the libedit icon.

2) I think I’d drop the dimensions from the modedit icon, and
change the pad colour to the default (yellow).


The default pad color is not yellow, that is only what you see for THT 
pads. Default pad color is green for bottom and red for top copper



3) Projects should use the current New Project icon, rather than
the application icon.


I have considered to submit a patch for this for some time, but I 
guess it is an appropiate time to do this with a major version bump.



4) Both the New Project and New Project from Template icons should
get yellow “new” star.

5) New Footprint in modedit also needs the star, and the star on
New Symbol in libedit made more prominent.

Cheers,
Jeff.



On 6 Jan 2018, at 12:30, Oliver Walters
> wrote:

I think there is a need to tweak the libedit and modedit icons,
as identified below:





1. The blue 'textured' background is out of place with the other
icons
2. They are very cluttered and hard to read
3. Weirdly specific callout of dimensions and part names (out of
character with other icons)

Further, I think that the pcbnew icon could be adjusted slightly
to make it look a bit more like a PCB

Even as someone who uses KiCad on a regular basis I find myself
double checking which icon I am about to click on (and still
getting it wrong half of the time).

Below is a /**suggestion**/ of some improvements. I am not trying
to back my own horse here, I'd be happy for anyone else to
suggest a better design for any of these. But I feel that
changing these icons would be a good improvement to make before
the v5 release. There have been many people complaining about
these icons in particular, both here and on the user forums.



Is this a worthwhile endeavor, or are people attached to the
weird blue icons?
___
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] Default Canvas for v5

[kristoffer Ödmark]

The same settings that were set during your first startup currently, but 
behind the scenes, a wizard would just give you the option of choosing, 
or going with the "default"



On 2017-12-31 23:11, Simon Wells wrote:
the big problem i have with setup wizards is it is not always obvious 
which options will be or were set by the setup dialog


Simon

On 1/01/2018, at 11:08 AM, Kristoffer Ödmark 
<kristofferodmar...@gmail.com <mailto:kristofferodmar...@gmail.com>> 
wrote:


There is still some functionality in it that is missing from what I 
gather.


I do like the idea that just having an "enable hw acceleration" 
button or switch in the nagdialog, it feels proffessional, and most 
people will try it i think.


Also, these problems seems like there could be some benefit of having 
a setup wizard, IE a series of nagdialogs that is only run once, and 
can be reenabled when new user choices are mandated( download 
libraries, dark/light theme, standard projects folder, 
hardware/software rendering)


I think changing so that the only option is to run with or without HW 
acceleration should be a good goal for v6, along with _maybe_ having 
a setup wizard.


-Kristoffer

On 12/31/2017 07:09 PM, Jon Evans wrote:
Do we actually need the legacy canvas anymore? I know we need the 
code in
it for printing, but do we need the option to render the UI in 
legacy mode
or could we hide that in some place less prominent than the view 
menu? It

would be a lot less confusing if the only choice was between hardware
acceleration or not.
On Dec 31, 2017 13:07, "Jon Evans" <cdaw...@gmail.com 
<mailto:cdaw...@gmail.com>> wrote:

How about "Modern" instead of GAL for user-facing stuff?

"Legacy"
"Modern (Accelerated)"
"Modern (Fallback)"

On Dec 31, 2017 12:38, "Nick Østergaard" <oe.n...@gmail.com 
<mailto:oe.n...@gmail.com>> wrote:


I don't think the term standard for Cairo is good. It is better to 
call

it fallback or faillsafe.

Calling it standard gives the impression that this is what they should
choose, but really we want them to select OpenGL.

Den 31. dec. 2017 18.12 <20%2017%2018%2012> skrev "Wayne Stambaugh" <
stambau...@gmail.com <mailto:stambau...@gmail.com>>:


Looks good to me.

On 12/31/2017 12:04 PM, Jon Evans wrote:

How about something like this?

Inline image 1

(N.B. I agree with Andy, and think we could consider renaming the
options in the View menu to "Legacy", "Accelerated (OpenGL)" and
"Standard (Cairo)" or something like that)

-Jon

On Sun, Dec 31, 2017 at 11:40 AM, Andy Peters <de...@latke.net 
<mailto:de...@latke.net>

<mailto:de...@latke.net>> wrote:


On Dec 31, 2017, at 6:49 AM, Simon Wells <swel...@gmail.com 
<mailto:swel...@gmail.com>

<mailto:swel...@gmail.com>> wrote:

What about having the default set to cairo, and when the
first/once run dialog runs it talks about openGL (this goes
against you already set to GAL) but it allows a default 
that even

if it crashes won’t require manually editing a configuration to
make it workable


User perspective:

The names for the canvases are “engineering terms,” that is,
something named by the developers for their own internal use but
were never renamed for the end user who might have no idea 
what is

meant by “Cairo canvas” or what “GAL” stands for. I say that

because

early on I asked myself, “WTF is this ‘Cairo’ thing?”

I now understand (I think …) that Cairo and GAL implement 
the same

features but the latter requires proper OpenGL hardware and

drivers,

and Cairo does not.

So perhaps better terms for these options is “Standard” and
“Accelerated (OpenGL).” Users know what OpenGL means (I 
hope, it’s

nothing new). As for why a user with access to OpenGL hardware

would

not choose to use it by default? Battery life on a laptop, I
suppose, but in using Kicad for a few years now I can say I’ve

never

used the Cairo canvas at all.

-a






Simon

On 1/01/2018, at 2:48 AM, Wayne Stambaugh 
<stambau...@gmail.com <mailto:stambau...@gmail.com>

<mailto:stambau...@gmail.com>> wrote:

I spite of my disdain for nagware, I'll tolerate this 
under the

following conditions:

The current canvas is not already on one of the gal canvases.

If the
user is already using a gal canvas, a dialog to inform the 
user

about

the gal canvas is silly.

It's a one shot dialog that never appears again.

If the gal canvas crashes, the user isn't going to have to
manually edit
a configuration file to restore the legacy canvas.  This
requirement may
prevent us from setting the opengl canvas as the default 
so the

solution
may not be as easy as it seems.

On 12/31/2017 07:34 AM,

Re: [Kicad-developers] Default Canvas for v5

[Kristoffer Ödmark]

There is still some functionality in it that is missing from what I gather.

I do like the idea that just having an "enable hw acceleration" button 
or switch in the nagdialog, it feels proffessional, and most people will 
try it i think.


Also, these problems seems like there could be some benefit of having a 
setup wizard, IE a series of nagdialogs that is only run once, and can 
be reenabled when new user choices are mandated( download libraries, 
dark/light theme, standard projects folder, hardware/software rendering)


I think changing so that the only option is to run with or without HW 
acceleration should be a good goal for v6, along with _maybe_ having a 
setup wizard.


 -Kristoffer

On 12/31/2017 07:09 PM, Jon Evans wrote:

Do we actually need the legacy canvas anymore? I know we need the code in
it for printing, but do we need the option to render the UI in legacy mode
or could we hide that in some place less prominent than the view menu? It
would be a lot less confusing if the only choice was between hardware
acceleration or not.

On Dec 31, 2017 13:07, "Jon Evans"  wrote:


How about "Modern" instead of GAL for user-facing stuff?

"Legacy"
"Modern (Accelerated)"
"Modern (Fallback)"

On Dec 31, 2017 12:38, "Nick Østergaard"  wrote:


I don't think the term standard for Cairo is good. It is better to call
it fallback or faillsafe.

Calling it standard gives the impression that this is what they should
choose, but really we want them to select OpenGL.

Den 31. dec. 2017 18.12 <20%2017%2018%2012> skrev "Wayne Stambaugh" <
stambau...@gmail.com>:


Looks good to me.

On 12/31/2017 12:04 PM, Jon Evans wrote:

How about something like this?

Inline image 1

(N.B. I agree with Andy, and think we could consider renaming the
options in the View menu to "Legacy", "Accelerated (OpenGL)" and
"Standard (Cairo)" or something like that)

-Jon

On Sun, Dec 31, 2017 at 11:40 AM, Andy Peters > wrote:



 On Dec 31, 2017, at 6:49 AM, Simon Wells > wrote:

 What about having the default set to cairo, and when the
 first/once run dialog runs it talks about openGL (this goes
 against you already set to GAL) but it allows a default that even
 if it crashes won’t require manually editing a configuration to
 make it workable


 User perspective:

 The names for the canvases are “engineering terms,” that is,
 something named by the developers for their own internal use but
 were never renamed for the end user who might have no idea what is
 meant by “Cairo canvas” or what “GAL” stands for. I say that

because

 early on I asked myself, “WTF is this ‘Cairo’ thing?”

 I now understand (I think …) that Cairo and GAL implement the same
 features but the latter requires proper OpenGL hardware and

drivers,

 and Cairo does not.

 So perhaps better terms for these options is “Standard” and
 “Accelerated (OpenGL).” Users know what OpenGL means (I hope, it’s
 nothing new). As for why a user with access to OpenGL hardware

would

 not choose to use it by default? Battery life on a laptop, I
 suppose, but in using Kicad for a few years now I can say I’ve

never

 used the Cairo canvas at all.

 -a






 Simon


 On 1/01/2018, at 2:48 AM, Wayne Stambaugh > wrote:

 I spite of my disdain for nagware, I'll tolerate this under the
 following conditions:

 The current canvas is not already on one of the gal canvases.

If the

 user is already using a gal canvas, a dialog to inform the user

about

 the gal canvas is silly.

 It's a one shot dialog that never appears again.

 If the gal canvas crashes, the user isn't going to have to
 manually edit
 a configuration file to restore the legacy canvas.  This
 requirement may
 prevent us from setting the opengl canvas as the default so the
 solution
 may not be as easy as it seems.

 On 12/31/2017 07:34 AM, Jeff Young wrote:

 +1 to the startup dialog idea.

 I think we also need to set reasonable transparencies in the
 layers so that it looks more like the default legacy canvas.


 I don' think this is necessary given that the gal canvas layer

colors

 and transparencies are completely user configurable but I'm not
 opposed
 to a default layer color/transparency configuration that looks
 more like
 the legacy canvas.




 On 31 Dec 2017, at 10:09, Clemens Koller > wrote:

 On 2017-12-31 03:53, Jon Evans wrote:

 I know this would be work for someone to do and maybe I'd
 offer to do it if the project leaders approve...
 What about a one-time pop-up when first installing a release
 5.0 that appears if the config says the user was using legacy
 

Re: [Kicad-developers] Default Canvas for v5

[Kristoffer Ödmark]

My personal preference would be to show the nag-dialog only if the user 
has upgraded from a previous version of kicad, and only once.


New users wouldnt have to be informed, and if possible fallback a 
fallback to the cairo solution instead of falling back to legacy might 
be tempting.


Could maybe the configuration files be used for this, maybe insert a 
kicad version or something?


-Kristoffer

On 12/31/2017 02:48 PM, Wayne Stambaugh wrote:

I spite of my disdain for nagware, I'll tolerate this under the
following conditions:

The current canvas is not already on one of the gal canvases.  If the
user is already using a gal canvas, a dialog to inform the user about
the gal canvas is silly.

It's a one shot dialog that never appears again.

If the gal canvas crashes, the user isn't going to have to manually edit
a configuration file to restore the legacy canvas.  This requirement may
prevent us from setting the opengl canvas as the default so the solution
may not be as easy as it seems.

On 12/31/2017 07:34 AM, Jeff Young wrote:

+1 to the startup dialog idea.

I think we also need to set reasonable transparencies in the layers so that it 
looks more like the default legacy canvas.


I don' think this is necessary given that the gal canvas layer colors
and transparencies are completely user configurable but I'm not opposed
to a default layer color/transparency configuration that looks more like
the legacy canvas.




On 31 Dec 2017, at 10:09, Clemens Koller  wrote:

On 2017-12-31 03:53, Jon Evans wrote:

I know this would be work for someone to do and maybe I'd offer to do it if the 
project leaders approve...
What about a one-time pop-up when first installing a release 5.0 that appears 
if the config says the user was using legacy canvas, telling them about how to 
switch and that they should check it out?

-Jon


+1
An initial start-up dialog to setup the "users default" after a first install or after a 
"reset Kicad to defaults, as I messed something up I don't remember" seems very helpful 
to me. If OpenGL might still crash in rare cases, warn the user in advance and explain, how he can 
safely step back from using OpenGL in case it doesn't work and how to file a bug report...

Regards,

Clemens

___
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] Default Canvas for v5

[Kristoffer Ödmark]

The power of defaults ;)

This is also something I have encountered has turned a lot of users 
away, because when they try it, they dont really like the setup. So even 
if they can change it, they give up before they realize they can.


-Kristoffer

On 12/30/2017 10:30 PM, Chris Pavlina wrote:

On Sat, Dec 30, 2017 at 09:27:46PM +, Jeff Young wrote:

+1.

(I used legacy for 6 months because I thought the only difference was in 
rendering.  I didn’t realise all the tools were different too….)


I hear this a _lot_ from beginners. We're shipping so many cool new
features that a surprising number of people don't know exist because we
hide them.



Cheers,
Jeff.


On 30 Dec 2017, at 21:13, Chris Pavlina  wrote:

Pleeease!

It makes no sense to use a canvas we call "legacy" as default. GAL may
still not have 100% feature parity to allow _removing_ legacy but it's
totally ready to be the default.

On Sat, Dec 30, 2017 at 08:51:53PM +, José Ignacio wrote:

Since the GAL is pretty much feature complete (I have used it exclusively
for the last year and a half) and the Cairo canvas has much improved
performance (it is *significantly* faster than legacy on my systems),
should pcbnew make the switch to have Cairo as the default canvas?

I understand OpenGL may still be undesirable because some defective or
misconfigured systems may have crashing issues with kicad preventing the
user to switch away from OpenGL, but that may even not be the case anymore.



___
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] Intel video drivers on linux

[Kristoffer Ödmark]

Honestly I am using the intel driver more often than the built in nvidia 
in my ux302 zenbook. Mostly to get better battery time from it. I find 
it very stable.


I have a friend who recently got a Xiaomi pro 15.6 inch laptop and runs 
linux on it, it comes with both nvidia and intel drivers and also a 
quite speedy processor and build quality for a reasonable price.


I will let him test his out a bit before I myself am thinking about 
doing an upgrade to the xiaomi. The build quality truly feels amazing.


 -Kristoffer

On 12/28/2017 08:30 PM, Wayne Stambaugh wrote:

I know this is not specifically a kicad development question but I am in
the market for a new laptop before the end of the year and figured this
might be the best place to ask.  I was wondering if anyone has any
experience with intel graphics chips (namely the 630) drivers on linux.
I prefer nvidia graphics chips on linux because the proprietary nvidia
drivers on linux are typically hassle free but I would rather spend my
hard earned money on ram and nmve drive than graphics hardware which I
really don't need and already have on my desktop system.  Thanks in
advance for the help.

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



___
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] [RFC] Eeschema bus upgrades and new connectivity algorithm

[kristoffer Ödmark]

On 2017-12-20 16:58, Jon Evans wrote:


For user experience, it might be a bit annoying to have to remember to 
insert a separator character if you want one to appear.
So I guess one question would be: do we want to support no separator 
character at all?  Or default to a dot if the user doesn't end their 
name in a different non-alpha character?
Well, for a user that does not want the dots in the bus-names, having no 
way to not use them will also be annoying :) But then again, I do not 
know how much depends on the buses and nets to have a separator.


As Wayne said, I am suggesting that DATA[0..7] beccomes DATA0, DATA1 
etc. Maybe this could be an option, not for configurable bus separators, 
but to have the option of no bus separator. If it is okay and feasible, 
I am willing to help code a solution to have this.




-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


___
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] [RFC] Eeschema bus upgrades and new connectivity algorithm

[kristoffer Ödmark]

I see no value in adding a forced separator, I am not talking about a 
configurable, maybe this has been unclear. I am talking about no 
separator. So that I can put a dot or whatever i feel like anyway.



On 2017-12-20 14:47, Maciej Sumiński wrote:

Hi Kristoffer,

No offence, but is there any added value in using a configurable
separator character or is it just your preference? It seems to me that
adding such feature will complicate the code a lot for a small benefit,
but I may not see the full picture. Perhaps it is just a convention that
we could live with.

Regards,
Orson

On 12/20/2017 02:29 PM, kristoffer Ödmark wrote:

Then dont use a underscore? If the dot is not inserted, nothing hinders
you from not putting a underscore there?


On 2017-12-20 13:32, Wayne Stambaugh wrote:

Using an underscore as a replacement for the period will add another
reserved character which will add complexity to the parser and/or
require quoting when saving to the file which makes the file format less
readable.

On 12/19/2017 4:52 PM, kristoffer Ödmark wrote:

Why would this be problematic for users like you to be able to chose
whichever character you fancy instead?


On 2017-12-19 22:03, Wayne Stambaugh wrote:

This would be problematic for users like me who use the underscore
character in names for readability.

On 12/19/2017 3:57 PM, kristoffer Ödmark wrote:

Another thing, maybe not force the usage of the dot ".", I would
rather
like to force the dot myself, or be able to use "_" or whatever i
fancy.
So instead putting CH0.{ADC}, or CH0_{ADC}.

- Kristoffer


On 2017-12-19 21:28, Jon Evans wrote:

Hi Marco,

Thanks a lot for your feedback.

I agree with you and others who have commented on the desire for
there
to be some way to know what is going on if you make a PDF or printout
from a schematic using the alias feature.
I'll think about this, and if anyone else has ideas on this, please
let me know.
(Andy's point is another one that I failed to note previously --
anywhere you use a bus entry to lay out a wire exiting a bus, you
will
see the full net name, so you can tell what is in the bus that way
already)

I see this feature as a thing that would be used in very complicated
designs in order to make them simpler to follow, so making a simple
example to demonstrate where you might use it is kind of a challenge
-- if I use an example that is very simple so that it is quick to
make
and quick to explain, then it is not obvious what the benefit is.  I
will work on some more "real world" examples of where this feature
could be most powerful.

Without taking the time to actually make up some fake schematics
(which I can also do when I have more time), here are some more
examples:

1) Complicated bus goes many places in a hierarchical design

Let's say you have some kind of definition for a complicated bus --
some combination of various net vectors and nets that results in a
long label.
For example "A[12..0] D[15..0] OE WE RESET"

You use this bus in a hierarchical design where it connects a FPGA
(on
one sheet) to multiple memory devices (on other sheets).
You can create an alias to rename this bus to just "MEMORY" and then
in your top level sheet, you'll see a pin on the FPGA sheet called
"MEMORY", connecting to pins also called "MEMORY" on the other
sheets.
On the sub-sheets, the bus will be broken out into its components, so
you can see OE running to some chip, RESET running to another pin on
the chip, etc.

Benefit: your hierarchical sheet port/pins don't have huge labels for
the buses, just "MEMORY".

2) Design needs multiple copies of a similar bus with distinct net
names

Say you are designing a big data collection device.  It has a large
FPGA and 8 channels of ADC.  Each ADC needs its own set of signals
going straight back to the FPGA (i.e. no shared signals between the
ADC)
You could define buses going to each ADC like this:

"CH0{D[15..0] CLK_P CLK_N}"
"CH1{D[15..0] CLK_P CLK_N}"
and so on.

This would leave you with nets for each ADC like "CH0.D15",
"CH0.CLK_P", etc

Now you could *optionally* also define an alias for the signals each
ADC needs:

"ADC" => "D[15..0] CLK_P CLK_N"

Then, you could name your ports/pins/buses like:

"CH0{ADC}"
"CH1{ADC}"
and so on.

Benefit 1: Even if you don't use aliases, putting a name in front of
the bus group means that each channel will get its nets automatically
prefixed with "CH0" etc.
Benefit 2: If you use aliases, your port/pin/label names get much
shorter, the same as in the first example.

Hope this helps!

Best,
Jon

On Tue, Dec 19, 2017 at 2:06 AM, Marco Ciampa <ciam...@libero.it
<mailto:ciam...@libero.it>> wrote:

   Hi Jon,
   first of all, thanks for listening my thoughts.

   I waited to send this letter a few days to wait for things to
   clear up to me.
   

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

[kristoffer Ödmark]

Then dont use a underscore? If the dot is not inserted, nothing hinders 
you from not putting a underscore there?



On 2017-12-20 13:32, Wayne Stambaugh wrote:

Using an underscore as a replacement for the period will add another
reserved character which will add complexity to the parser and/or
require quoting when saving to the file which makes the file format less
readable.

On 12/19/2017 4:52 PM, kristoffer Ödmark wrote:

Why would this be problematic for users like you to be able to chose
whichever character you fancy instead?


On 2017-12-19 22:03, Wayne Stambaugh wrote:

This would be problematic for users like me who use the underscore
character in names for readability.

On 12/19/2017 3:57 PM, kristoffer Ödmark wrote:

Another thing, maybe not force the usage of the dot ".", I would rather
like to force the dot myself, or be able to use "_" or whatever i fancy.
So instead putting CH0.{ADC}, or CH0_{ADC}.

- Kristoffer


On 2017-12-19 21:28, Jon Evans wrote:

Hi Marco,

Thanks a lot for your feedback.

I agree with you and others who have commented on the desire for there
to be some way to know what is going on if you make a PDF or printout
from a schematic using the alias feature.
I'll think about this, and if anyone else has ideas on this, please
let me know.
(Andy's point is another one that I failed to note previously --
anywhere you use a bus entry to lay out a wire exiting a bus, you will
see the full net name, so you can tell what is in the bus that way
already)

I see this feature as a thing that would be used in very complicated
designs in order to make them simpler to follow, so making a simple
example to demonstrate where you might use it is kind of a challenge
-- if I use an example that is very simple so that it is quick to make
and quick to explain, then it is not obvious what the benefit is.  I
will work on some more "real world" examples of where this feature
could be most powerful.

Without taking the time to actually make up some fake schematics
(which I can also do when I have more time), here are some more
examples:

1) Complicated bus goes many places in a hierarchical design

Let's say you have some kind of definition for a complicated bus --
some combination of various net vectors and nets that results in a
long label.
For example "A[12..0] D[15..0] OE WE RESET"

You use this bus in a hierarchical design where it connects a FPGA (on
one sheet) to multiple memory devices (on other sheets).
You can create an alias to rename this bus to just "MEMORY" and then
in your top level sheet, you'll see a pin on the FPGA sheet called
"MEMORY", connecting to pins also called "MEMORY" on the other sheets.
On the sub-sheets, the bus will be broken out into its components, so
you can see OE running to some chip, RESET running to another pin on
the chip, etc.

Benefit: your hierarchical sheet port/pins don't have huge labels for
the buses, just "MEMORY".

2) Design needs multiple copies of a similar bus with distinct net
names

Say you are designing a big data collection device.  It has a large
FPGA and 8 channels of ADC.  Each ADC needs its own set of signals
going straight back to the FPGA (i.e. no shared signals between the
ADC)
You could define buses going to each ADC like this:

"CH0{D[15..0] CLK_P CLK_N}"
"CH1{D[15..0] CLK_P CLK_N}"
and so on.

This would leave you with nets for each ADC like "CH0.D15",
"CH0.CLK_P", etc

Now you could *optionally* also define an alias for the signals each
ADC needs:

"ADC" => "D[15..0] CLK_P CLK_N"

Then, you could name your ports/pins/buses like:

"CH0{ADC}"
"CH1{ADC}"
and so on.

Benefit 1: Even if you don't use aliases, putting a name in front of
the bus group means that each channel will get its nets automatically
prefixed with "CH0" etc.
Benefit 2: If you use aliases, your port/pin/label names get much
shorter, the same as in the first example.

Hope this helps!

Best,
Jon

On Tue, Dec 19, 2017 at 2:06 AM, Marco Ciampa <ciam...@libero.it
<mailto:ciam...@libero.it>> wrote:

  Hi Jon,
  first of all, thanks for listening my thoughts.

  I waited to send this letter a few days to wait for things to
  clear up to me.
  I think that this still apply although some things might be a
  little clearer
  now, so, in a way it is a little obsolete. I am sending it the
  same because
  I do not want to kill its spirit...

  ...but please continue to keep in mind that these are my
  0.02
  cents humble opinions...and really nothing more...

  On Thu, Dec 14, 2017 at 08:21:29AM -0500, Jon Evans wrote:
  > Hi Marco,
  >
  > The idea of aliases is to be "templates" for buses when you also
  give names
  > to a bus.

  Ok clear.

  Let's call them templates then beca

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

[kristoffer Ödmark]

Why would this be problematic for users like you to be able to chose 
whichever character you fancy instead?



On 2017-12-19 22:03, Wayne Stambaugh wrote:

This would be problematic for users like me who use the underscore
character in names for readability.

On 12/19/2017 3:57 PM, kristoffer Ödmark wrote:

Another thing, maybe not force the usage of the dot ".", I would rather
like to force the dot myself, or be able to use "_" or whatever i fancy.
So instead putting CH0.{ADC}, or CH0_{ADC}.

- Kristoffer


On 2017-12-19 21:28, Jon Evans wrote:

Hi Marco,

Thanks a lot for your feedback.

I agree with you and others who have commented on the desire for there
to be some way to know what is going on if you make a PDF or printout
from a schematic using the alias feature.
I'll think about this, and if anyone else has ideas on this, please
let me know.
(Andy's point is another one that I failed to note previously --
anywhere you use a bus entry to lay out a wire exiting a bus, you will
see the full net name, so you can tell what is in the bus that way
already)

I see this feature as a thing that would be used in very complicated
designs in order to make them simpler to follow, so making a simple
example to demonstrate where you might use it is kind of a challenge
-- if I use an example that is very simple so that it is quick to make
and quick to explain, then it is not obvious what the benefit is.  I
will work on some more "real world" examples of where this feature
could be most powerful.

Without taking the time to actually make up some fake schematics
(which I can also do when I have more time), here are some more examples:

1) Complicated bus goes many places in a hierarchical design

Let's say you have some kind of definition for a complicated bus --
some combination of various net vectors and nets that results in a
long label.
For example "A[12..0] D[15..0] OE WE RESET"

You use this bus in a hierarchical design where it connects a FPGA (on
one sheet) to multiple memory devices (on other sheets).
You can create an alias to rename this bus to just "MEMORY" and then
in your top level sheet, you'll see a pin on the FPGA sheet called
"MEMORY", connecting to pins also called "MEMORY" on the other sheets.
On the sub-sheets, the bus will be broken out into its components, so
you can see OE running to some chip, RESET running to another pin on
the chip, etc.

Benefit: your hierarchical sheet port/pins don't have huge labels for
the buses, just "MEMORY".

2) Design needs multiple copies of a similar bus with distinct net names

Say you are designing a big data collection device.  It has a large
FPGA and 8 channels of ADC.  Each ADC needs its own set of signals
going straight back to the FPGA (i.e. no shared signals between the ADC)
You could define buses going to each ADC like this:

"CH0{D[15..0] CLK_P CLK_N}"
"CH1{D[15..0] CLK_P CLK_N}"
and so on.

This would leave you with nets for each ADC like "CH0.D15",
"CH0.CLK_P", etc

Now you could *optionally* also define an alias for the signals each
ADC needs:

"ADC" => "D[15..0] CLK_P CLK_N"

Then, you could name your ports/pins/buses like:

"CH0{ADC}"
"CH1{ADC}"
and so on.

Benefit 1: Even if you don't use aliases, putting a name in front of
the bus group means that each channel will get its nets automatically
prefixed with "CH0" etc.
Benefit 2: If you use aliases, your port/pin/label names get much
shorter, the same as in the first example.

Hope this helps!

Best,
Jon

On Tue, Dec 19, 2017 at 2:06 AM, Marco Ciampa <ciam...@libero.it
<mailto:ciam...@libero.it>> wrote:

 Hi Jon,
 first of all, thanks for listening my thoughts.

 I waited to send this letter a few days to wait for things to
 clear up to me.
 I think that this still apply although some things might be a
 little clearer
 now, so, in a way it is a little obsolete. I am sending it the
 same because
 I do not want to kill its spirit...

 ...but please continue to keep in mind that these are my
 0.02
 cents humble opinions...and really nothing more...

 On Thu, Dec 14, 2017 at 08:21:29AM -0500, Jon Evans wrote:
 > Hi Marco,
 >
 > The idea of aliases is to be "templates" for buses when you also
 give names
 > to a bus.

 Ok clear.

 Let's call them templates then because for me an alias is just an
 alias.

 > This is a little different than you describe, and I think is a
 > powerful feature.

 I do not want to be unrespectful and ungrateful especially since I
 am not
 a dev but... there are many powerful features that we (actually
 you devs)
 can concoct but not all of them would probably turn out to be of such
 usefulness even if very powerful and feasible.

 

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

[kristoffer Ödmark]

Another thing, maybe not force the usage of the dot ".", I would rather 
like to force the dot myself, or be able to use "_" or whatever i fancy.

So instead putting CH0.{ADC}, or CH0_{ADC}.

- Kristoffer


On 2017-12-19 21:28, Jon Evans wrote:

Hi Marco,

Thanks a lot for your feedback.

I agree with you and others who have commented on the desire for there 
to be some way to know what is going on if you make a PDF or printout 
from a schematic using the alias feature.
I'll think about this, and if anyone else has ideas on this, please 
let me know.
(Andy's point is another one that I failed to note previously -- 
anywhere you use a bus entry to lay out a wire exiting a bus, you will 
see the full net name, so you can tell what is in the bus that way 
already)


I see this feature as a thing that would be used in very complicated 
designs in order to make them simpler to follow, so making a simple 
example to demonstrate where you might use it is kind of a challenge 
-- if I use an example that is very simple so that it is quick to make 
and quick to explain, then it is not obvious what the benefit is.  I 
will work on some more "real world" examples of where this feature 
could be most powerful.


Without taking the time to actually make up some fake schematics 
(which I can also do when I have more time), here are some more examples:


1) Complicated bus goes many places in a hierarchical design

Let's say you have some kind of definition for a complicated bus -- 
some combination of various net vectors and nets that results in a 
long label.

For example "A[12..0] D[15..0] OE WE RESET"

You use this bus in a hierarchical design where it connects a FPGA (on 
one sheet) to multiple memory devices (on other sheets).
You can create an alias to rename this bus to just "MEMORY" and then 
in your top level sheet, you'll see a pin on the FPGA sheet called 
"MEMORY", connecting to pins also called "MEMORY" on the other sheets.
On the sub-sheets, the bus will be broken out into its components, so 
you can see OE running to some chip, RESET running to another pin on 
the chip, etc.


Benefit: your hierarchical sheet port/pins don't have huge labels for 
the buses, just "MEMORY".


2) Design needs multiple copies of a similar bus with distinct net names

Say you are designing a big data collection device.  It has a large 
FPGA and 8 channels of ADC.  Each ADC needs its own set of signals 
going straight back to the FPGA (i.e. no shared signals between the ADC)

You could define buses going to each ADC like this:

"CH0{D[15..0] CLK_P CLK_N}"
"CH1{D[15..0] CLK_P CLK_N}"
and so on.

This would leave you with nets for each ADC like "CH0.D15", 
"CH0.CLK_P", etc


Now you could *optionally* also define an alias for the signals each 
ADC needs:


"ADC" => "D[15..0] CLK_P CLK_N"

Then, you could name your ports/pins/buses like:

"CH0{ADC}"
"CH1{ADC}"
and so on.

Benefit 1: Even if you don't use aliases, putting a name in front of 
the bus group means that each channel will get its nets automatically 
prefixed with "CH0" etc.
Benefit 2: If you use aliases, your port/pin/label names get much 
shorter, the same as in the first example.


Hope this helps!

Best,
Jon

On Tue, Dec 19, 2017 at 2:06 AM, Marco Ciampa > wrote:


Hi Jon,
first of all, thanks for listening my thoughts.

I waited to send this letter a few days to wait for things to
clear up to me.
I think that this still apply although some things might be a
little clearer
now, so, in a way it is a little obsolete. I am sending it the
same because
I do not want to kill its spirit...

...but please continue to keep in mind that these are my
0.02
cents humble opinions...and really nothing more...

On Thu, Dec 14, 2017 at 08:21:29AM -0500, Jon Evans wrote:
> Hi Marco,
>
> The idea of aliases is to be "templates" for buses when you also
give names
> to a bus.

Ok clear.

Let's call them templates then because for me an alias is just an
alias.

> This is a little different than you describe, and I think is a
> powerful feature.

I do not want to be unrespectful and ungrateful especially since I
am not
a dev but... there are many powerful features that we (actually
you devs)
can concoct but not all of them would probably turn out to be of such
usefulness even if very powerful and feasible.

I think that we should always keep in mind a need to be fulfilled and
some cases of use in witch such a feature turns out to be useful.

And even if it turns out to be of some usefulness, there is always a
trade-off between an increase in complexity of the design process
and benefits to the designer and in the complexity of the schematics.

If we are not able to find an example in witch this feature literally
kills a big deal of work, then I am afraid that we are introducing
some

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

[Kristoffer Ödmark]

Personally I think this feature would be huge boost for readability. 
Most people who will review a schematic knows what nets are on a USB 
connection, or a SPI connection or similar. I see them as an 
abbreviation, just the same as everyone knows what USB is, even though 
it stands for Universal Serial Bus.


I do agree that they will need to be shown different, so that an 
exported PDF can differentiate between what is a net, and what is a 
template of nets. Maybe just have the text be bold.


For the documentation part, when someone has a large enough itch with 
with templates not being clear enough when printed, I think a list of 
abbreviations will be developed by that person. ;)


I know I will be one of the first testers as soon as Jon thinks it is time!

Thank you Jon for working on this! :D

 -Kristoffer

On 12/19/2017 08:06 AM, Marco Ciampa wrote:

Hi Jon,
first of all, thanks for listening my thoughts.

I waited to send this letter a few days to wait for things to clear up to me.
I think that this still apply although some things might be a little clearer
now, so, in a way it is a little obsolete. I am sending it the same because
I do not want to kill its spirit...

...but please continue to keep in mind that these are my 0.02
cents humble opinions...and really nothing more...

On Thu, Dec 14, 2017 at 08:21:29AM -0500, Jon Evans wrote:

Hi Marco,

The idea of aliases is to be "templates" for buses when you also give names
to a bus.


Ok clear.

Let's call them templates then because for me an alias is just an alias.


This is a little different than you describe, and I think is a
powerful feature.


I do not want to be unrespectful and ungrateful especially since I am not
a dev but... there are many powerful features that we (actually you devs)
can concoct but not all of them would probably turn out to be of such
usefulness even if very powerful and feasible.

I think that we should always keep in mind a need to be fulfilled and
some cases of use in witch such a feature turns out to be useful.

And even if it turns out to be of some usefulness, there is always a
trade-off between an increase in complexity of the design process
and benefits to the designer and in the complexity of the schematics.

If we are not able to find an example in witch this feature literally
kills a big deal of work, then I am afraid that we are introducing some
rarely used, obscure to grasp and difficult to document feature.

I mean that schematics are to be understood in printed form. The meaning
(of the syntax) of the drawings should as of immediate comprehension as
possible. Every template/macro/alias that we add to the schematics should
probably:

1) be documented in printed form (no, a pop-up window is not enough) on
the design sheets
2) must be easy to read (as in a paper print) even if you do not know
KiCad at all

because this feature, if I got it right, seems to me more a kind of
"programming" than "describing" a circuit design


If you define an alias called MEMORY, you can then define *multiple
different* memory buses, so they have to have different prefix names. But
you can also choose to use aliases *without* a prefix name, and then
everywhere you use that alias will be part of the same set of nets.

So, a more realistic and simple example would be:

Define alias "USB" containing "DP", "DM"


Ok

If I do not see this definition somewhere on the sheet, am I still able
to understand the schematics just looking at a print on paper of it?

If I need to see also the "alias" definition to understand the
schematics, where can I look at this template definition on the sheets?


Now in one sheet you have a USB hub. You can define four different buses
with names and the alias, and get nets like "PORT1.DP" and so on.

But on a simpler design, you might not need four ports, so you can just use
"{USB}" in your bus name and get nets without any prefix.


But it seems to me that this is the same name of a net on the bus with
name "USB"...


I think both options of how to use buses are valid and useful, and I also
understand your confusion when presented with all these options at once.


Would you be so kind to continue with this example and show how could be
represented, for instance, a 4 USB bus schematic? Or other examples that
could benefit from this feature?

I do not really "see" it if I haven't a real example to look at... it's
my lack of imagination, I know...


With that in mind, do you have any thoughts on how we could preserve the
power of this feature while making it easier to understand?


If we (you devs) find really worth, my suggestion is to:

1) clearly divide the template/class definition from the istances syntax
(but I do not know how though...).
The confusion to me arises from this "all in one" approach.

2) find a way to describe it "on paper" to make schematic sheets readable
to non KiCad users (normal elect. engineers)

My suggestion here is to keep it as simple, and 

[Kicad-developers] Information regarding unit tests.

[kristoffer Ödmark]

Hello!

I just went through the ML and the docs. I found some tests in the qa 
folder that seemed related to the python scripting interface and some 
different documentation regarding testability from tomasz and the thread 
"simple C++ tests". Has there been added anything for doing tests in cpp 
code? If so how do I activate it?


Merry Christmas!
Kristoffer


___
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] [RFC] Eeschema bus upgrades and new connectivity algorithm

[kristoffer Ödmark]

Hmm okay, we seem to differ in opinions once again. But you are right, 
nothing stops me from naming my aliases like that anyway.


I have checked schematics for students, and I know that I  would be very 
confused if the aliases they have used did not immediatly pop up for me 
somehow. Be it syntax, colors or even text-style, maybe making aliases 
appear in *bold *text, indicating they are more than meets the eye, or 
cursive text, or a grey background color?


- Kristoffer


On 2017-12-14 13:17, Maciej Suminski wrote:

If I recall correctly, you are allowed to name an alias using 
format, so there is nothing preventing you from doing so. I would rather
not impose such constraint on aliases, but I am interested in other
opinions.

Regards,
Orson

On 12/14/2017 01:09 PM, kristoffer Ödmark wrote:

Maybe we could adapt from c++ here? having the notation  instead
of {ALIAS}, the same way c++ uses templates.

one could do MEMORY{ D[15..0]}. And get MEMORY.OE MEMORY.WE and
MEMORY D15 etc. Just to be more clear that it is an alias and not a
net-name.

- Kristoffer


On 2017-12-14 12:43, Clemens Koller wrote:

Hello, Jon!

Thank you for your work! I just watched your video and want to give
you some feedback:

I would prefer not to use the term "Bus Vector". A bus is simply a
list (or a collection) of arbitrarily named nets. A bus group would be
- in my understanding - a group of (different) busses.

I like your syntax to represent the list (or collection) {} as well as
an array of nets [].
You first had a bus containing arbitrary nets: MEMORY{A{7..0] D[15..0]
OE WE} and you refer to single nets as i.e. MEMORY.A3 or MEMORY.OE -
fine.

But when you add aliases I run into troubles to keep things
separate/clear:
{RAM} appears to me as an unnamed bus containing the net RAM. WTF is
that?

MEMORY{RAM} appears as a bus named MEMORY containing the single net RAM.
I would expect to access that net via MEMORY.RAM - Oops.

I am definitely irritated by a net MEMORY.OE pulled out of an bus
named MEMORY{RAM}. 8-(
It's impossible to distinguish bus aliases from nets of a bus.

Idea: It might be nice to virtually allow folding/unfolding of the net
collection contained in a bus, i.e. by showing MEMORY{*} or MEMORY{..}
or MEMORY{+}, whereas the '*' or '..' or '+' is shown in a different
colour. If that's still to long, I would not mind renaming the bus to
MEM{..} or even M{..}.
A simple mouseover M{..} could pop-up to show all nets and arrays the
bus contains.

Side note: For big designs, table-based design entry (as well as
design entry by importing tons of generated connections) seems to get
more and more important. It might be wise to consider how busses (and
collections of ) are represented there as well.

Just my five cents,

Clemens

On 2017-12-14 05:15, Jon Evans wrote:

Hi all,

As some of you know, I've been working on some new features for
Eeschema that expand the capabilities of buses.
These features are not yet complete, but I wanted to share my
progress to get early feedback.

Since there are a number of things, I have made a ~4 minute demo
video, in which I walk through them and discuss:

https://youtu.be/z6x0xiKgDIc

In case you don't want to watch the video, here are the new features:

    * The existing style of bus is now referred to as a Bus Vector
(for example: "A[7..0]")
    * New concept: Bus Groups, for adding arbitrary nets to a bus
    o Defined in a list, separated by spaces, enclosed in curly
braces. For example: "{DP DM}"
    o Can contain bus vectors as well as plain nets, for example
"{A[7..0] D[7..0] OE WE}"
    o Can have an optional name in front, like "MEMORY{A[7..0]
D[7..0]}"
    o If you add a name, the resulting nets will have the name
prefixed on the front, like "MEMORY.A7"
    * New concept: Bus Aliases
    o You can use aliases to define shortcuts for bus groups.
    o For example, you could create an alias called "USB" that
refers to the nets "DP" and "DM"
    o Then, you can define a bus group as "{USB}" which will
contain both of those nets.
    o You can also add a label, like "USB1{USB}" which will result
in nets "USB1.DP" and "USB1.DM <http://USB1.DM>"
    o Bus Aliases are editable through a new dialog, and saved
with the schematic file.
    * New tool: Bus Unfolding
    o Right click on a bus, and you can easily break out any of
its members into a bus entry, label, and wire.
    o You place the label (and set the bus entry orientation) with
the first click, and then can continue wiring.

In order to support this work, I am also working on a new
connectivity algorithm for Eeschema.
This algorithm stores the resulting connectivity information with the
graphical objects on the schematic, meaning that it's quite easy to
look up what net any particular object is part of.  The new algorithm
is also

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

[kristoffer Ödmark]

Maybe we could adapt from c++ here? having the notation  instead 
of {ALIAS}, the same way c++ uses templates.


one could do MEMORY{ D[15..0]}. And get MEMORY.OE MEMORY.WE and 
MEMORY D15 etc. Just to be more clear that it is an alias and not a 
net-name.


- Kristoffer


On 2017-12-14 12:43, Clemens Koller wrote:

Hello, Jon!

Thank you for your work! I just watched your video and want to give you some 
feedback:

I would prefer not to use the term "Bus Vector". A bus is simply a list (or a 
collection) of arbitrarily named nets. A bus group would be - in my understanding - a 
group of (different) busses.

I like your syntax to represent the list (or collection) {} as well as an array 
of nets [].
You first had a bus containing arbitrary nets: MEMORY{A{7..0] D[15..0] OE WE} 
and you refer to single nets as i.e. MEMORY.A3 or MEMORY.OE - fine.

But when you add aliases I run into troubles to keep things separate/clear:
{RAM} appears to me as an unnamed bus containing the net RAM. WTF is that?

MEMORY{RAM} appears as a bus named MEMORY containing the single net RAM.
I would expect to access that net via MEMORY.RAM - Oops.

I am definitely irritated by a net MEMORY.OE pulled out of an bus named 
MEMORY{RAM}. 8-(
It's impossible to distinguish bus aliases from nets of a bus.

Idea: It might be nice to virtually allow folding/unfolding of the net 
collection contained in a bus, i.e. by showing MEMORY{*} or MEMORY{..} or 
MEMORY{+}, whereas the '*' or '..' or '+' is shown in a different colour. If 
that's still to long, I would not mind renaming the bus to MEM{..} or even 
M{..}.
A simple mouseover M{..} could pop-up to show all nets and arrays the bus 
contains.

Side note: For big designs, table-based design entry (as well as design entry by 
importing tons of generated connections) seems to get more and more important. It 
might be wise to consider how busses (and collections of ) are 
represented there as well.

Just my five cents,

Clemens

On 2017-12-14 05:15, Jon Evans wrote:

Hi all,

As some of you know, I've been working on some new features for Eeschema that 
expand the capabilities of buses.
These features are not yet complete, but I wanted to share my progress to get 
early feedback.

Since there are a number of things, I have made a ~4 minute demo video, in 
which I walk through them and discuss:

https://youtu.be/z6x0xiKgDIc

In case you don't want to watch the video, here are the new features:

   * The existing style of bus is now referred to as a Bus Vector (for example: 
"A[7..0]")
   * New concept: Bus Groups, for adding arbitrary nets to a bus
   o Defined in a list, separated by spaces, enclosed in curly braces. For example: 
"{DP DM}"
   o Can contain bus vectors as well as plain nets, for example "{A[7..0] 
D[7..0] OE WE}"
   o Can have an optional name in front, like "MEMORY{A[7..0] D[7..0]}"
   o If you add a name, the resulting nets will have the name prefixed on the front, 
like "MEMORY.A7"
   * New concept: Bus Aliases
   o You can use aliases to define shortcuts for bus groups.
   o For example, you could create an alias called "USB" that refers to the nets "DP" 
and "DM"
   o Then, you can define a bus group as "{USB}" which will contain both of 
those nets.
   o You can also add a label, like "USB1{USB}" which will result in nets "USB1.DP" and 
"USB1.DM "
   o Bus Aliases are editable through a new dialog, and saved with the 
schematic file.
   * New tool: Bus Unfolding
   o Right click on a bus, and you can easily break out any of its members 
into a bus entry, label, and wire.
   o You place the label (and set the bus entry orientation) with the first 
click, and then can continue wiring.

In order to support this work, I am also working on a new connectivity 
algorithm for Eeschema.
This algorithm stores the resulting connectivity information with the graphical 
objects on the schematic, meaning that it's quite easy to look up what net any 
particular object is part of.  The new algorithm is also significantly (i.e. an 
order of magnitude) faster at generating connectivity than the current 
netlisting algorithm in my testing so far.  It will support partial updates of 
the connectivity when editing the schematic, so the net information will always 
be in sync when adding/removing/editing items in the schematic.

The combination of a faster algorithm and caching of the connectivity results 
in dramatic speedups when working with large designs.
For example, Chris' motherboard project (which is a great benchmark, by the 
way!) takes several seconds to highlight nets in the current master branch, and 
with my changes, you can highlight any net instantaneously.

Although it is not yet far enough along to demonstrate this, I plan to use this 
new connectivity algorithm to generate netlists for export, and replace the 
existing algorithm entirely.

You can check out the code in my branch here, but be warned that it is not 

Re: [Kicad-developers] Simulator towards 5.0

[Kristoffer Ödmark]

I think that this message is important, and I feel a decision on this 
matter features has to be done by the project manager, basically give a 
pointer to what should be used to as far extent as possible.


Wayne, this is a package dev that wants to know this and while I do not 
know who are package devs, the only package dev has expressed a need for 
this decision. Please dont just ignore it.


And yes, the coming patch submissions is dependent on what features are 
deemed "standard"


 -Kristoffer

On 12/07/2017 08:58 PM, Simon Richter wrote:

Hi,

On 07.12.2017 19:08, Wayne Stambaugh wrote:


Yes, that is exactly what I'm saying.  it is possible kicad could have
different feature sets depending on the availability of dependencies on
the target platform.  The kicad project has no control over this.  If a
platform doesn't have dependency support for spice, they can still
provide a kicad package without spice support.  That's better than no kicad.


Right, but we still need to give some guidance on the status of
features. As it is now, new features are introduced as default-off
"experimental" stuff that is only to be used by a select few, then at
some point we enable it for nightlies, mostly driven by availability of
dependencies and a vague feeling that features should be tested, and at
some point the feature has become something that should have been
enabled by default a long time ago (but nobody can tell the exact date
when).

We need a bit of a process here to promote feature status, e.g.

experimentalnew stuff, not for general use
optional=> add to nightlies
standard=> enable by default
required=> remove option

I think all the new features for v5 have reached "optional" status, and
they have been enabled in nightlies as far as possible. The next
question is whether they are "standard" and should be part of the stable
release, including questions by users and a commitment to file
compatibility. Probably yes, but this is a project management decision
that will affect requirements for patch submissions in the next release
cycle, so it needs to be an explicit decision.

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



___
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] Simulator towards 5.0

[kristoffer Ödmark]

I still think this is strange reasoning, so the version 5 will be built 
differently on every system? I thought v5 should include the spice 
simulator?


Are you saying there is no recommended way to deliver kicad? So when I 
send a file to my friend on windows, he might not be able to do the same 
things as I can on ubuntu, or on arch or whatever?


I understand that there are optional dependencies, but basically having 
the option to turn them off still seems better than having the option to 
turn them on. At least when turning them off I will understand why they 
are not in kicad. And a new developer might find this easier as well.


Can we at least have an update to the build docs that reflects what is 
deemed non-experimental or a line stating that everything should be 
turned on?


- Kristoffer

On 2017-12-07 16:53, Wayne Stambaugh wrote:

I hope users are no longer building kicad from source.  We tried that
already and it was a disaster.  The build options should reflect the
dependencies available on the platform it's being built on.  Whether or
not an optional feature is ready for release is not relevant.  For
example if ngspice was not built with the --with-libngspice option
(which apparently on arch linux it is not), setting KICAD_SPICE=ON will
fail during build config.  It is up to the system package developer to
determine if kicad should be built with spice support.

On 12/6/2017 9:04 AM, Kristoffer Ödmark wrote:

Are we not in feature freeze, the features that I enabled by default is
from my understanding the ones that will be built into the official
ones. And yes, the people that are compiling a non-standard install
shuld be savvy enough to be change the compilation settings. That is why
i think the default build should reflect the ones being run by the less
savvy users.

  -Kristoffer

On 12/06/2017 11:31 AM, Simon Richter wrote:

Hi,

On 06.12.2017 11:12, Kristoffer Ödmark wrote:


I do not see why anyone is even objecting to this? Where is the logic at
having a default build that does not correspond to any of the official
packages?!

That usually happens because the nightly builds enable all the
experimental features to allow people to test them, but the default is
still "disabled" because they introduce extra dependencies and make life
difficult for people compiling from source.

The default for new options needs to be decided before the release, I
think, and "release" packages should go with that.

     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


___
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] Simulator towards 5.0

[kristoffer Ödmark]

I am still lacking a clear documentation about which options are inte 
official releases, or planned to be.



On 2017-12-07 09:27, Maciej Sumiński wrote:

The attached patch lists options that have "KICAD" in their name when
calling CMake:

-- Build configuration:
-- KICAD_BIN=bin
-- KICAD_BRANCH_NAME=
-- KICAD_DATA=share/kicad
-- KICAD_DEMOS=share/kicad/demos
-- KICAD_DOCS=share/doc/kicad
-- KICAD_INSTALL_DEMOS=ON
-- KICAD_LIB=lib64
-- KICAD_PLUGINS=lib64/kicad/plugins
-- KICAD_SCRIPTING=OFF
-- KICAD_SCRIPTING_ACTION_MENU=OFF
-- KICAD_SCRIPTING_MODULES=OFF
-- KICAD_SCRIPTING_WXPYTHON=OFF
-- KICAD_SPICE=OFF
-- KICAD_TEMPLATE=share/kicad/template
-- KICAD_USER_CONFIG_DIR=/home/orson
-- KICAD_USER_PLUGIN=lib64/kicad/plugins
-- KICAD_USE_OCE=OFF
-- KICAD_VERSION_EXTRA=

Perhaps that would be sufficient to inform the user about the flags he
may change.

Cheers,
Orson

On 12/07/2017 12:25 AM, Wayne Stambaugh wrote:

ccmake is only useful when you aren't interested in scripting builds.
It is a decent tool to discover the options but I would much prefer

cmake --show-options

to having to open up a GUI app.

On 12/06/2017 06:13 PM, Jacob Schmidt wrote:

I got frustrated a while back because people were talking about the
spice integration like it was a real thing, but I had never seen it.
That lead me to google how to list cmake options, and I found ccmake.

ccmake is a wrapper around cmake that was useful to me. Maybe it will be
for someone reading this.


On 12/6/2017 8:04 AM, Wayne Stambaugh wrote:

source.  Unfortunately, cmake does not have a command line switch that
allows you to view the build options and their default settings.
Autotools is far superior in this instance.  This is one of my pet
peeves with cmake.  Most of the software I have built over the years
typically only has the build options enabled for the features that will
build on all platforms.


___
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] Simulator towards 5.0

[Kristoffer Ödmark]

Are we not in feature freeze, the features that I enabled by default is 
from my understanding the ones that will be built into the official 
ones. And yes, the people that are compiling a non-standard install 
shuld be savvy enough to be change the compilation settings. That is why 
i think the default build should reflect the ones being run by the less 
savvy users.


 -Kristoffer

On 12/06/2017 11:31 AM, Simon Richter wrote:

Hi,

On 06.12.2017 11:12, Kristoffer Ödmark wrote:


I do not see why anyone is even objecting to this? Where is the logic at
having a default build that does not correspond to any of the official
packages?!


That usually happens because the nightly builds enable all the
experimental features to allow people to test them, but the default is
still "disabled" because they introduce extra dependencies and make life
difficult for people compiling from source.

The default for new options needs to be decided before the release, I
think, and "release" packages should go with that.

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



___
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] Simulator towards 5.0

[Kristoffer Ödmark]

I sent the wrong patch before attached the correct now. Silently 
compiling something else then what was expected is much much worse than 
failing.


I do not see why anyone is even objecting to this? Where is the logic at 
having a default build that does not correspond to any of the official 
packages?!


If i build a software I expect to get the same as the official version, 
unless i specify some custom options, currently I am not even getting 
the same version as the official by reading the compilation steps in the 
docs currently.


The error message for spice even details how to get the correct spice 
library and with this even tells how to disable it if you wish to build 
without it.


 -Kristoffer

On 12/05/2017 06:31 PM, Simon Richter wrote:

Hi,

On 05.12.2017 17:30, Maciej Sumiński wrote:


When you build a program, do you always go through its build manual or
do you start with 'cmake .. && make'? I think there is no point
enforcing an optional dependency. Another good solution would be to
autodetect libngspice and enable the simulator if it is available.


With my packaging hat on: please don't. It is really annoying to find
out that a build dependency changed when users complain about entire
features going missing.

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

>From c993c2df02b1402099cc2999c75f554f860da91a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= 
Date: Tue, 5 Dec 2017 14:33:10 +0100
Subject: [PATCH] Changed default compile-flags to match released packages This
 makes it easier to build like in the the official packages added a message on
 how to compile without spice support if needed

---
 CMakeLists.txt | 28 +---
 Documentation/development/compiling.md | 18 +++---
 2 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index c70a34237..90dd8f99d 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -54,24 +54,24 @@ option( USE_WX_OVERLAY
 "Use wxOverlay: Always ON for MAC (default OFF).  Warning, this is experimental" )
 
 option( KICAD_SCRIPTING
-"Build the Python scripting support inside KiCad binaries (default OFF)."
-)
+"Build the Python scripting support inside KiCad binaries (default ON)."
+ON )
 
 option( KICAD_SCRIPTING_MODULES
 "Build native portion of the pcbnew Python module: _pcbnew.{pyd,so} for OS command line use of Python."
-)
+ON )
 
 option( KICAD_SCRIPTING_WXPYTHON
-"Build wxPython implementation for wx interface building in Python and py.shell (default OFF)."
-)
+"Build wxPython implementation for wx interface building in Python and py.shell (default ON)."
+ON )
 
 option( KICAD_SCRIPTING_ACTION_MENU
-"Build a tools menu with registred python plugins: actions plugins (default OFF)."
-)
+"Build a tools menu with registred python plugins: actions plugins (default ON)."
+ON )
 
 option( KICAD_USE_OCE
-"Build tools and plugins related to OpenCascade Community Edition (default OFF)"
-)
+"Build tools and plugins related to OpenCascade Community Edition (default ON)"
+ON )
 
 option( KICAD_INSTALL_DEMOS
 "Install kicad demos and examples (default ON)"
@@ -97,7 +97,7 @@ endif()
 
 option( BUILD_GITHUB_PLUGIN "Build the GITHUB_PLUGIN for pcbnew." ON )
 
-option( KICAD_SPICE "Build Kicad with internal Spice simulator." OFF )
+option( KICAD_SPICE "Build Kicad with internal Spice simulator." ON )
 
 # Global setting: exports are explicit
 set( CMAKE_CXX_VISIBILITY_PRESET "hidden" )
@@ -554,7 +554,13 @@ endif()
 
 # Find ngspice library, required for integrated circuit simulator
 if( KICAD_SPICE )
-find_package( ngspice REQUIRED )
+find_package( ngspice )
+
+if( NOT NGSPICE_FOUND )
+message( FATAL_ERROR "Required ngspice library not found, to \
+compile kicad without integrated circuit simulator, run cmake with \
+-DKICAD_SPICE=OFF" )
+endif()
 endif()
 
 # Find OpenCascade Community Edition, required for STEP plugin and tools
diff --git a/Documentation/development/compiling.md b/Documentation/development/compiling.md
index 43d388235..2646eb5e6 100644
--- a/Documentation/development/compiling.md
+++ b/Documentation/development/compiling.md
@@ -132,17 +132,17 @@ on macOS.  This is enabled on macOS by default and disabled on all other platfor
 ## Scripting Support ## {#scripting_opt}
 
 The KICAD_SCRIPTING option is used to enable building the Python scripting support into Pcbnew.
-This options is disabled by default.
+This options is enabled by default.
 
 ## Scripting Module Support ## {#scripting_mod_opt}
 
 The KICAD_SCRIPTING_MODULES option is used to enable building and installing 

Re: [Kicad-developers] Simulator towards 5.0

[Kristoffer Ödmark]

This patch changes the default build values in cmake, and adds an 
instruction on how to disable the the spice simulator in the cmake error.


 -Kristoffer

On 12/05/2017 05:30 PM, Maciej Sumiński wrote:

When you build a program, do you always go through its build manual or
do you start with 'cmake .. && make'? I think there is no point
enforcing an optional dependency. Another good solution would be to
autodetect libngspice and enable the simulator if it is available.

On 12/05/2017 05:18 PM, Nick Østergaard wrote:

Isn't it good enough to mention it under the KiCad Build Configuration
Options in the devdocs as it is already?


2017-12-05 16:56 GMT+01:00 Maciej Sumiński <maciej.sumin...@cern.ch>:


If everyone agrees that Spice simulator should be enabled by default,
then please display a note saying it is optional and might be disabled
for cases when it is not found by CMake.

Regards,
Orson

On 12/05/2017 03:47 PM, Nick Østergaard wrote:

If they are not available for some reason the packager for that platform
can disable the feature until he figures out how to support the feature.

I don't really see the rationale in having supported features be enabled
explicitly.

2017-12-05 15:33 GMT+01:00 Wayne Stambaugh <stambau...@gmail.com>:


Can we guarantee that these build dependencies are available on all
platforms?  I'm primarily think of BSD devs.  For the windows, macos,
and linux devs there are no issues.

On 12/5/2017 9:28 AM, Nick Østergaard wrote:

I would personally also like to see these options enabled by default.

It

makes it easier for a packager to be convinced what options to

enable...

:)


2017-12-05 15:05 GMT+01:00 Kristoffer Ödmark
<kristofferodmar...@gmail.com <mailto:kristofferodmar...@gmail.com>>:

 I checked the default package in Ubuntu ppa through a friend.

Indeed

 all of this is enabled.

 Here I attach a small patch that changes the default compile-flags
 to the ones in the released packages. Its a small fix and it doesnt
 add or remove anything really, just a changes how a default build
 for a novice will look, maybe it will reduce some initial confusion
 for someone.

 - Kristoffer

 On 12/04/2017 10:19 PM, Nick Østergaard wrote:



 Den 4. dec. 2017 18.50 <tel:2017%2018.50> skrev "kristoffer
 Ödmark" <kristofferodmar...@gmail.com
 <mailto:kristofferodmar...@gmail.com>
 <mailto:kristofferodmar...@gmail.com
 <mailto:kristofferodmar...@gmail.com>>>:



 On 2017-12-04 15:22, Tomasz Wlostowski wrote:

 Kristoffer,

 You're very welcome to specify how you'd like to have

the

 Spice-related
 fields organized - but remember it's not only the
 integrated ngspice
 simulator that relies on them. People have been
 exporting PSpice
 netlists from Kicad for a while and AFAIR netlist

export

 depends on
 these particular fields.

 Okay, My suggestions:

 1. Enable the spice simulator by default and start shipping
 it with
 windows nightlies. This way we will find much more bugs.
 Because I
 doubt everyone is running with the simulator on even on
 nightlies.
 Same goes for the OCE and step stuff. This I see as a must
 to get a
 smoother v5 transition for most users, even those moving

from v4

 stable to v5 stable without ever trying nightlies.


 Everything should be enabled for the windows nightlies. It has
 been when the OCE stuff and ngspice stuff was merged. If it not
 it is a bug.


 2. Parse the "value" field and reference in the simulator

to

 get the
 basic primitives. like Resistor and Capactiors, inductors
 etc, based
 on the first Letter in the Reference. We already have
 name-dependent
 functions for the differential-pair so having this here,

and


 3. Move the Spice_Netlist_Enabled field to a new right-side
 toggle
 menu to select between "Spice and PCB, Spice Only, PCB
 only", so one
 can specify if the item should be added to both the PCB and

the

 Spice netlist, or only one of them, by default I guess both
 should
 be enabled.

 4. When the Spice_Model field is selected, the button "Edit
 Spice
 Model" should be shown under there, instead of always on

the

 left
 side. Just to be more like the other fields.

 5. Add context-menu entries and toolbar buttons for the
 simulator
 interface.

 This would make the simulator seem like its a part of kica

Re: [Kicad-developers] Simulator towards 5.0

[Kristoffer Ödmark]

I always try to build the package that everyone else is running, and no 
I do not consult the build manual until i have to. That is also why I 
have only tested the simulator that will now be inside v5.


Since we are in feature freeze, and the simulator will be part of kicad. 
I think that the standard build should reflect the packaged kicad.


I do agree that a message that it can be disabled is ok though.

-Kristoffer

On 12/05/2017 05:30 PM, Maciej Sumiński wrote:

When you build a program, do you always go through its build manual or
do you start with 'cmake .. && make'? I think there is no point
enforcing an optional dependency. Another good solution would be to
autodetect libngspice and enable the simulator if it is available.

On 12/05/2017 05:18 PM, Nick Østergaard wrote:

Isn't it good enough to mention it under the KiCad Build Configuration
Options in the devdocs as it is already?


2017-12-05 16:56 GMT+01:00 Maciej Sumiński <maciej.sumin...@cern.ch>:


If everyone agrees that Spice simulator should be enabled by default,
then please display a note saying it is optional and might be disabled
for cases when it is not found by CMake.

Regards,
Orson

On 12/05/2017 03:47 PM, Nick Østergaard wrote:

If they are not available for some reason the packager for that platform
can disable the feature until he figures out how to support the feature.

I don't really see the rationale in having supported features be enabled
explicitly.

2017-12-05 15:33 GMT+01:00 Wayne Stambaugh <stambau...@gmail.com>:


Can we guarantee that these build dependencies are available on all
platforms?  I'm primarily think of BSD devs.  For the windows, macos,
and linux devs there are no issues.

On 12/5/2017 9:28 AM, Nick Østergaard wrote:

I would personally also like to see these options enabled by default.

It

makes it easier for a packager to be convinced what options to

enable...

:)


2017-12-05 15:05 GMT+01:00 Kristoffer Ödmark
<kristofferodmar...@gmail.com <mailto:kristofferodmar...@gmail.com>>:

 I checked the default package in Ubuntu ppa through a friend.

Indeed

 all of this is enabled.

 Here I attach a small patch that changes the default compile-flags
 to the ones in the released packages. Its a small fix and it doesnt
 add or remove anything really, just a changes how a default build
 for a novice will look, maybe it will reduce some initial confusion
 for someone.

 - Kristoffer

 On 12/04/2017 10:19 PM, Nick Østergaard wrote:



 Den 4. dec. 2017 18.50 <tel:2017%2018.50> skrev "kristoffer
 Ödmark" <kristofferodmar...@gmail.com
 <mailto:kristofferodmar...@gmail.com>
 <mailto:kristofferodmar...@gmail.com
 <mailto:kristofferodmar...@gmail.com>>>:



 On 2017-12-04 15:22, Tomasz Wlostowski wrote:

 Kristoffer,

 You're very welcome to specify how you'd like to have

the

 Spice-related
 fields organized - but remember it's not only the
 integrated ngspice
 simulator that relies on them. People have been
 exporting PSpice
 netlists from Kicad for a while and AFAIR netlist

export

 depends on
 these particular fields.

 Okay, My suggestions:

 1. Enable the spice simulator by default and start shipping
 it with
 windows nightlies. This way we will find much more bugs.
 Because I
 doubt everyone is running with the simulator on even on
 nightlies.
 Same goes for the OCE and step stuff. This I see as a must
 to get a
 smoother v5 transition for most users, even those moving

from v4

 stable to v5 stable without ever trying nightlies.


 Everything should be enabled for the windows nightlies. It has
 been when the OCE stuff and ngspice stuff was merged. If it not
 it is a bug.


 2. Parse the "value" field and reference in the simulator

to

 get the
 basic primitives. like Resistor and Capactiors, inductors
 etc, based
 on the first Letter in the Reference. We already have
 name-dependent
 functions for the differential-pair so having this here,

and


 3. Move the Spice_Netlist_Enabled field to a new right-side
 toggle
 menu to select between "Spice and PCB, Spice Only, PCB
 only", so one
 can specify if the item should be added to both the PCB and

the

 Spice netlist, or only one of them, by default I guess both
 should
 be enabled.

 4. When the Spice_Model field is selected, the button "Edit
 Spice
 Model" should be shown under there, instead of always on

the

   

Re: [Kicad-developers] Simulator towards 5.0

[Kristoffer Ödmark]

I dont see why they should not be able to disable these options in that 
case, I dont think we should adapt our builds for the majority to suit 
the needs of the minority.


- Kristoffer

On 12/05/2017 03:33 PM, Wayne Stambaugh wrote:

Can we guarantee that these build dependencies are available on all
platforms?  I'm primarily think of BSD devs.  For the windows, macos,
and linux devs there are no issues.

On 12/5/2017 9:28 AM, Nick Østergaard wrote:

I would personally also like to see these options enabled by default. It
makes it easier for a packager to be convinced what options to enable... :)

2017-12-05 15:05 GMT+01:00 Kristoffer Ödmark
<kristofferodmar...@gmail.com <mailto:kristofferodmar...@gmail.com>>:

 I checked the default package in Ubuntu ppa through a friend. Indeed
 all of this is enabled.

 Here I attach a small patch that changes the default compile-flags
 to the ones in the released packages. Its a small fix and it doesnt
 add or remove anything really, just a changes how a default build
 for a novice will look, maybe it will reduce some initial confusion
 for someone.

 - Kristoffer

 On 12/04/2017 10:19 PM, Nick Østergaard wrote:



 Den 4. dec. 2017 18.50 <tel:2017%2018.50> skrev "kristoffer
 Ödmark" <kristofferodmar...@gmail.com
 <mailto:kristofferodmar...@gmail.com>
 <mailto:kristofferodmar...@gmail.com
 <mailto:kristofferodmar...@gmail.com>>>:



     On 2017-12-04 15:22, Tomasz Wlostowski wrote:

         Kristoffer,

         You're very welcome to specify how you'd like to have the
         Spice-related
         fields organized - but remember it's not only the
 integrated ngspice
         simulator that relies on them. People have been
 exporting PSpice
         netlists from Kicad for a while and AFAIR netlist export
 depends on
         these particular fields.

     Okay, My suggestions:

     1. Enable the spice simulator by default and start shipping
 it with
     windows nightlies. This way we will find much more bugs.
 Because I
     doubt everyone is running with the simulator on even on
 nightlies.
     Same goes for the OCE and step stuff. This I see as a must
 to get a
     smoother v5 transition for most users, even those moving from v4
     stable to v5 stable without ever trying nightlies.


 Everything should be enabled for the windows nightlies. It has
 been when the OCE stuff and ngspice stuff was merged. If it not
 it is a bug.


     2. Parse the "value" field and reference in the simulator to
 get the
     basic primitives. like Resistor and Capactiors, inductors
 etc, based
     on the first Letter in the Reference. We already have
 name-dependent
     functions for the differential-pair so having this here, and

     3. Move the Spice_Netlist_Enabled field to a new right-side
 toggle
     menu to select between "Spice and PCB, Spice Only, PCB
 only", so one
     can specify if the item should be added to both the PCB and the
     Spice netlist, or only one of them, by default I guess both
 should
     be enabled.

     4. When the Spice_Model field is selected, the button "Edit
 Spice
     Model" should be shown under there, instead of always on the
 left
     side. Just to be more like the other fields.

     5. Add context-menu entries and toolbar buttons for the
 simulator
     interface.

     This would make the simulator seem like its a part of kicad
 and not
     only a strange addon that is just hackishly attached to
 kicad with
     duct-tape. Dont get me wrong, Its an awesome feature, and
 works well
     it just looks like an outsider when using it currently.



         As for the polishing up before the V5, there's several
 tasks to do:
         - update the pspice.lib library (it doesn't follow the
 KLC) and make
         sure all Spice devices are in there.
         - fix quirks in the plot component (wxMathPlot).
         - document and make a few example designs (I can help
 with this
         point).

         Cheers,
         Tom



     ___
     Mailing list: https://launchpad.net/~kicad-developers
 <https://launchpad.net/~kicad-developers>
     <https://launchpad.net/~kicad-developers
 <https://launchpad.net/~kicad-developers>>
     Post

Re: [Kicad-developers] Simulator towards 5.0

[Kristoffer Ödmark]

I checked the default package in Ubuntu ppa through a friend. Indeed all 
of this is enabled.


Here I attach a small patch that changes the default compile-flags to 
the ones in the released packages. Its a small fix and it doesnt add or 
remove anything really, just a changes how a default build for a novice 
will look, maybe it will reduce some initial confusion for someone.


- Kristoffer

On 12/04/2017 10:19 PM, Nick Østergaard wrote:



Den 4. dec. 2017 18.50 skrev "kristoffer Ödmark" 
<kristofferodmar...@gmail.com <mailto:kristofferodmar...@gmail.com>>:




On 2017-12-04 15:22, Tomasz Wlostowski wrote:

Kristoffer,

You're very welcome to specify how you'd like to have the
Spice-related
fields organized - but remember it's not only the integrated ngspice
simulator that relies on them. People have been exporting PSpice
netlists from Kicad for a while and AFAIR netlist export depends on
these particular fields.

Okay, My suggestions:

1. Enable the spice simulator by default and start shipping it with
windows nightlies. This way we will find much more bugs. Because I
doubt everyone is running with the simulator on even on nightlies.
Same goes for the OCE and step stuff. This I see as a must to get a
smoother v5 transition for most users, even those moving from v4
stable to v5 stable without ever trying nightlies.


Everything should be enabled for the windows nightlies. It has been when 
the OCE stuff and ngspice stuff was merged. If it not it is a bug.



2. Parse the "value" field and reference in the simulator to get the
basic primitives. like Resistor and Capactiors, inductors etc, based
on the first Letter in the Reference. We already have name-dependent
functions for the differential-pair so having this here, and

3. Move the Spice_Netlist_Enabled field to a new right-side toggle
menu to select between "Spice and PCB, Spice Only, PCB only", so one
can specify if the item should be added to both the PCB and the
Spice netlist, or only one of them, by default I guess both should
be enabled.

4. When the Spice_Model field is selected, the button "Edit Spice
Model" should be shown under there, instead of always on the left
side. Just to be more like the other fields.

5. Add context-menu entries and toolbar buttons for the simulator
interface.

This would make the simulator seem like its a part of kicad and not
only a strange addon that is just hackishly attached to kicad with
duct-tape. Dont get me wrong, Its an awesome feature, and works well
it just looks like an outsider when using it currently.



As for the polishing up before the V5, there's several tasks to do:
- update the pspice.lib library (it doesn't follow the KLC) and make
sure all Spice devices are in there.
- fix quirks in the plot component (wxMathPlot).
- document and make a few example designs (I can help with this
point).

Cheers,
Tom



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


>From ec962a3bb445573b546b90e539643d1f328d016e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= <kristoffer.odmar...@gmail.com>
Date: Tue, 5 Dec 2017 14:33:10 +0100
Subject: [PATCH] Changed default compile-flags to match released packages

---
 CMakeLists.txt | 20 ++--
 Documentation/development/compiling.md | 12 ++--
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index c70a34237..bff065eb0 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -54,24 +54,24 @@ option( USE_WX_OVERLAY
 "Use wxOverlay: Always ON for MAC (default OFF).  Warning, this is experimental" )
 
 option( KICAD_SCRIPTING
-"Build the Python scripting support inside KiCad binaries (default OFF)."
-)
+"Build the Python scripting support inside KiCad binaries (default ON)."
+ON )
 
 option( KICAD_SCRIPTING_MODULES
 "Build native portion of the pcbnew Python module: _pcbnew.{pyd,so} for OS command line use of Python."
-)
+ON )
 
 option( KICAD_SCRIPTING_WXPYTHON
-"Build wxPython implementation for wx interface building in Python and py.shell (default OFF)."
-)
+"Build wxPython implementation for wx interface building in Python and py.shell (default

Re: [Kicad-developers] Simulator towards 5.0

[kristoffer Ödmark]

Hi!

On 2017-12-04 21:33, Maciej Suminski wrote:

As far as I remember the simulator is enabled in Windows nightlies since
October last year. Does not it work for you?
To be honest, I havent tested the windows version, I dont really run a 
windows installation anywhere. I just falsely assumed If i do:


cmake ..
make
make install

That is the default package build, since it sets all the build flags to 
the default values, and if I do this the simulator is not running. At 
least I think the default values for what is going to be in v5 should be 
changed to reflect that, otherwise if a beginning dev does not specify 
those specific flags, the build will not reflect the user experience, 
its an uneccesary mismatch IMO. I have run the nightly with the debug 
flag set for a long time now, but newer seen the simulator until I 
actively decided to give it a whirl. There might be others.

It works for me. When I draw circuits for simulations I never edit Spice
models for passive components. Let me know if you find cases where it is
broken.
I always get a Spice_Model field as well for the passives, I havent 
really investigated what it does for the passives as of yet or how they 
relate or sync. But I do find it a bit strange that there are two fields 
describing the value of the passives, and it does confuse me a bit. Just 
thought I might bring it up before it becomes just a "quirk" with a 
good-enough work-around. ( like the stitch via that stuck around for 
very long ).

Regards,
Orson

___
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] Hierarchical Schematic to contain link to pcb

[kristoffer Ödmark]

Could someone respond to this with the original conversation, I remember 
a few more responses, but I cannot find them. Would be much appreciated!


- Kristoffer


On 2017-11-14 02:55, Strontium wrote:
My 2c, something like this would be useful for fanout of chips, 
especially BGA.  You could have a standard fan out, which included the 
main chip, all its fan out vias, tracks and bypass capacitors.  It 
would then be imported as a module, the schematic represents 
everything in that module.  Its placed on the PCB as a "multipart" 
component.


But it sounds like a lot of work to implement.

Steven


On 13/11/17 23:11, Kristoffer Ödmark wrote:

Hello!

I suspect this has been discussed before in different formats. But 
anyway.


What would be the major problems or concerns with allowing a 
schematic to have a pcb as file to include? What I mean is that the 
same way we let a symbol have a footprint in eeschema, we let a 
schematic point to a pcb file that is included before footprints are 
added to the pcb.


Every subschematic has a unique timestamp that could be added to 
every existing footprint in the schematic and should prove a 
sufficient way fix every designator number in the schematic in case a 
pcb is included multiple times.


I guess this would mean that at a later date the pcb-items would need 
to be able to be added to a group of some sort, so that one could 
easily move the newly included pcb as one.


Thinking about it this grouping is actually required, otherwise 
updating the pcb from the schematic might be impossible due to the 
fact that a board may contain items such as segments, which do not 
contain any unique id.


There is a huge gain from this, since it would allow multiple users 
to work on the same pcb in a different manner, allocating a space for 
their subschematic / subpcb etc, and also it would allow design reuse 
much easier.


Problems i see:

When parts of an imported pcb is updated how to handle it?
    - ( Propose to have a toggle to update all from imported pcb, or 
to ignore those coming from an imported pcb )



How should the grouping be available?
    -  ( Propose only let kicad group based on imported pcb and 
therefore every item can only have one group belonging or none group 
belonging, not changeable by the user )



If a subscheet has a subscheet, and both have an assigned pcb, how do 
we add this?

    -  ( Propose that only the highest level pcb be used )

How can one move all the parts of one imported pcb as a group, and 
how to change only a single item of the imported pcb?
    -  ( Have the disambiguation of meny show both the component and 
the group when selecting a component belonging to a group, toggle 
this behaviour on/off in a button from the toolbar, similar to the 
allow drc toggle )


How will this be managed by kicad?
    -  ( Assume that each subpcb and subschematic is a standalone 
project and therefore let the user worry about this, but add a demo 
showcasing this hierarchy with a ./main.{pro,sch,kicad_pcb} and a 
./subpcb/subpcb.{pro,sch,kicad_pcb} )






___
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] COMPONENT_TREE performance

[kristoffer Ödmark]

What are the roadblocks besides the huge amount of programming effort 
required for this? Im on linux and I would like this as well.


- Kristoffer


On 2017-12-04 19:09, Bernhard Stegmaier wrote:

On 4. Dec 2017, at 18:55, Chris Pavlina  wrote:

On Mon, Dec 04, 2017 at 05:53:12PM +, Tomasz Wlostowski wrote:

On 04/12/17 18:48, Chris Pavlina wrote:

Hey, just a comment because I see people are wrestling with
COMPONENT_TREE performance as I did when writing it. TEST ON MACOS. The
performance of the widget there has a really different profile from on
other systems. I had to do things in really unobvious ways to make it
perform reasonably there.


I've noticed spending more and more time fixing wxWidgets bugs instead
of Kicad bugs. Maybe we should have a serious look at Qt or Electron
(Webkit/JS-based UI) as a possible future alternative for wx...

YES. I try not to bring it up too much because I know the lead devs
aren't fond of the idea of changing the GUI toolkit, but I strongly
believe we could benefit from that. Obviously it can't really happen
until we ditch wxDC.

 From a macOS perspective I’d really love to see this.
There are many small/big usability/GUI problems that just don’t work on macOS.
The ones I tried to fix always ended up being some wx problem… and I gave up 
hope that they will get fixed any time soon or late (I am watching/using wx 
master for that reason, but didn’t see any improvements).


Regards,
Bernhard
___
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] Simulator towards 5.0

[kristoffer Ödmark]

I would ofcourse, Might have to ask some questions though since I am a 
bit unfamiliar with this code and well, kicad code in general :)


Without having had a look, A few of them looks quite trivial at first 
glance. I would start with 1, then then 4, then 3.


The others requres a bit more thought I believe to make stuff better and 
not worse, especially 2.


I dont believe I am adding features in most of them, more like 
reordering of the UI for a better experience, maybe 5 could be 
considered a feature.


- Kristoffer

On 2017-12-04 18:54, Tomasz Wlostowski wrote:

On 04/12/17 18:50, kristoffer Ödmark wrote:

Okay, My suggestions:

1. Enable the spice simulator by default and start shipping it with
windows nightlies. This way we will find much more bugs. Because I doubt
everyone is running with the simulator on even on nightlies. Same goes
for the OCE and step stuff. This I see as a must to get a smoother v5
transition for most users, even those moving from v4 stable to v5 stable
without ever trying nightlies.

2. Parse the "value" field and reference in the simulator to get the
basic primitives. like Resistor and Capactiors, inductors etc, based on
the first Letter in the Reference. We already have name-dependent
functions for the differential-pair so having this here, and

3. Move the Spice_Netlist_Enabled field to a new right-side toggle menu
to select between "Spice and PCB, Spice Only, PCB only", so one can
specify if the item should be added to both the PCB and the Spice
netlist, or only one of them, by default I guess both should be enabled.

4. When the Spice_Model field is selected, the button "Edit Spice Model"
should be shown under there, instead of always on the left side. Just to
be more like the other fields.

5. Add context-menu entries and toolbar buttons for the simulator
interface.

This would make the simulator seem like its a part of kicad and not only
a strange addon that is just hackishly attached to kicad with duct-tape.
Dont get me wrong, Its an awesome feature, and works well it just looks
like an outsider when using it currently.

Hey Kristoffer,

Would you be willing (if Wayne agrees - we're in feature freeze right
now) to code some of your suggestions?

Tom




___
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] Simulator towards 5.0

[kristoffer Ödmark]

On 2017-12-04 15:22, Tomasz Wlostowski wrote:

Kristoffer,

You're very welcome to specify how you'd like to have the Spice-related
fields organized - but remember it's not only the integrated ngspice
simulator that relies on them. People have been exporting PSpice
netlists from Kicad for a while and AFAIR netlist export depends on
these particular fields.

Okay, My suggestions:

1. Enable the spice simulator by default and start shipping it with 
windows nightlies. This way we will find much more bugs. Because I doubt 
everyone is running with the simulator on even on nightlies. Same goes 
for the OCE and step stuff. This I see as a must to get a smoother v5 
transition for most users, even those moving from v4 stable to v5 stable 
without ever trying nightlies.


2. Parse the "value" field and reference in the simulator to get the 
basic primitives. like Resistor and Capactiors, inductors etc, based on 
the first Letter in the Reference. We already have name-dependent 
functions for the differential-pair so having this here, and


3. Move the Spice_Netlist_Enabled field to a new right-side toggle menu 
to select between "Spice and PCB, Spice Only, PCB only", so one can 
specify if the item should be added to both the PCB and the Spice 
netlist, or only one of them, by default I guess both should be enabled.


4. When the Spice_Model field is selected, the button "Edit Spice Model" 
should be shown under there, instead of always on the left side. Just to 
be more like the other fields.


5. Add context-menu entries and toolbar buttons for the simulator interface.

This would make the simulator seem like its a part of kicad and not only 
a strange addon that is just hackishly attached to kicad with duct-tape. 
Dont get me wrong, Its an awesome feature, and works well it just looks 
like an outsider when using it currently.




As for the polishing up before the V5, there's several tasks to do:
- update the pspice.lib library (it doesn't follow the KLC) and make
sure all Spice devices are in there.
- fix quirks in the plot component (wxMathPlot).
- document and make a few example designs (I can help with this point).

Cheers,
Tom



___
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] Simulator towards 5.0

[Kristoffer Ödmark]

Hello!

What is the official status on the simulator part going towards v5? Will 
it be included or not. I just tried it and I really like the features in 
it, its basically ready to be used as a simulator and compete and 
conquer ltspice.


What i do not like is the way it stores information, in mulitple defined 
fields in the schematic symbols. Its a bit messy and feels very hackish. 
If it should be included I think this part should be discussed and 
further polished, one field for all of the spice information I think is 
decent, without having to set two different value fields for a resistor 
etc.


It doesnt feel like a natural part of kicad quite yet. But i feel that 
making it enabled by default after V5 is a step in the right direction.


--
 -Kristoffer

___
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] Signal integrity simulation within Kicad

[Kristoffer Ödmark]

This is very interesting indeed! Would you keep us updated of your 
progress? :D


- Kristoffer

On 11/29/2017 10:55 PM, Andreas Buhr wrote:

On 11/29/2017 08:07 PM, Tomasz Wlostowski wrote:

On 29/11/17 19:09, Andreas Buhr wrote:


[snip]


The input which my solver needs would be an array of polygons,
representing the copper-filled areas on each layer.
I then want to create a 2D triangle mesh and based on that a 3D prism
mesh for finite element analysis.


I've made a quick test program that prints most of the board's geometry
as bare polygons. It's here:

https://github.com/twlostow/kicad-dev/tree/tom-polygon-gen/qa/polygon_generator

Hope it can serve you as a starting point.


Hi Tom,

wow, that's absolutely amazing. Thank you so much. I just generated 20
megabytes of polygons, running your test program on the A64 OLinuxino
board by Olimex :-)
I hope I can do some SI simulations of its DDR3 memory channel. :-)


Cheers,
Andreas



___
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



--
 -Kristoffer

___
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] Some tests.

[Kristoffer Ödmark]

Heikki, That is not blackmailing, it is the exact same rules everyone 
else that is a kicad developer or wants to be is expected to follow.

It makes working on the same project easier.

Tom did not mean to kick you out of the mailing list, he meant that your 
code is not going to be put into Kicad if you do not make it readable 
and understandable to everyone else.


- Kristoffer

On 11/29/2017 02:57 PM, Heikki Pulkkinen wrote:

Hi Wayne,

Thanks Wayne for answering me.

"if you want to be a member of Kicad developers," that is blackmailing.

And I am not going to argue with those rules.

Heikki


On Wed, Nov 29, 2017 at 3:22 PM, Wayne Stambaugh > wrote:


On 11/29/2017 8:08 AM, Heikki Pulkkinen wrote:
>
> Hi
>
>
> On Wed, Nov 29, 2017 at 1:32 AM, Tomasz Wlostowski
 > 
>> wrote:
 >
 >     On 28/11/17 18:25, Heikki Pulkkinen wrote:
 >     >
 >     > Zones filling new record with new connectivity algo with
A64-Olinuxino
 >     > board. 13s.
 >
 >     Heikki,
 >
 >     I would be very glad to include your improvements in the zone
filling,
 >     but the code you've sent to me (your Github) does not meet
the quality
 >     standard we expect:
 >     - It's a mix of object and non-object oriented code which is
diffucult
 >     to understand.
 >
 >
 > Can you specify what part is object and what are not?
 >
 >     - It doesn't follow Kicad coding style rules.
 >
 >
 > Maybe, but can you specify that too? I can not see.
 >
 >     - It contains much more than faster zone filling, everything
is mixed
 >     with your via stitching/thermal code that we did not accept
for the
 >     reasons we had already explained to you.
 >
 >
 > Yes of course, it is my developed and going to use it in that way.
 >
 >
 >     I also investigated why the zones are filled slowly - the
major reason
 >     was a bug in the GAL zone filling algorithm, which was
filling all zones
 >     by performing N independent fills of every zone causing the
isolated
 >     copper islands to be checked N times (where N=number of zones
in the
 >     design) instead of just once. The branch [1] contains this
bug fixed. It
 >     also introduces quite a speedup in zone loading/rendering and
 >     parallelizes all zone filling operations using OpenMP. It
refills all
 >     zones on the "A64-Olinuxino
 >     board" in less than 3 seconds and something around 10s for
the "wrs"
 >     board on a Core i7-4700MQ, 16GB RAM machine.
 >
 >
 >
 >
 >     Please, if you want to be a member of Kicad developers,
follow some
 >     rules:
 >
 >
 > Of course you want that!
 > Wayne, do you accept this kind of blackmailing and all these rules?

I see no blackmailing here.  Tomasz is just pointing out the rules that
all KiCad developers are expected to follow when making contributions to
the project.  These rules apply to everyone including the project leader
so you are not being singled out.  You are being asked to help make life
easier for the lead developers so that they can possibly merge your code
into KiCad.  If your code does not conform to the coding policy[1], your
repo cannot be easily merged into the main kicad repo, or your code is
difficult to follow then you cannot expect someone else to fix this for
you.  The lead kicad developers are busy and do not have the time to do
this.

Cheers,

Wayne

[1]:

http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html



 >
 >     - Ask before making heavy changes. Connectivity algorithm is
an example
 >     of a heavy change.
 >
 >
 >     - Don't introduce large or risky changes in your first
patches. Changing
 >     the file format is an example of a potentially risky change
that should
 >     be consulted with other developers.
 >
 >
 >     - Announce you're working on something before you start
writing the
 >     code. Someone else may be already working on this part -
which is what
 >     exactly happened with the connectivity algorithm
 >
 >
 >     I'll be very happy to have a look at your teardrops and
automatic zone
 >     stitching code - which IMHO is an very valuable addition to
Kicad -
 >     after the V5 stable release is out.
 >
 >
 >     Cheers,
 >     Tom
 >
 >     [1]
https://github.com/twlostow/kicad-dev/tree/tom-faster-zones

Re: [Kicad-developers] Polygons: should have outline mode to draw Edge.Cuts

[Kristoffer Ödmark]

Could not a quick fix for this be to attach the "magnetic" functionality 
that exists when routing to the endpoints of a Edge.Cuts line?


On 11/21/2017 04:00 PM, Thomas Pointhuber wrote:

Hi,

as librarian I would also note that an improved Edge:Cuts behaviour
should take in account footprints which define Edge Connectors or cutouts.

At the moment, cutouts are incorrectly rendered in the 3d-viewer when
showing a single footprint, because there is no difference to a board
outline
in the actual file representation. Edge Connectors are especially
tricky, because KiCad requires the Edge.Cuts primitives to match
exactly. I think it
would make sense to add such connectors to the library as well in the
future, but using them would be to tortuous at the moment.

Regards,
Thomas

Am 2017-11-21 um 15:48 schrieb easyw:

Hi Henner,

I know this is outside the KiCad branch, but if you want to manage
complex board edges including arcs, ellipses or bsplines, you may
consider useful KiCad StepUp...
Recently I've added a feature to allow the user to design the pcb edge
in FreeCAD and push it to KiCad_pcb board file.

The collaboration between FreeCAD and KiCad is bi-directional, then
revisions are possible...
You may have a look at a small tutorial here
https://youtu.be/n44iBpu_YjY
and at the KiCad info forum page
https://forum.kicad.info/t/kicad-stepup-the-sketcher-for-getting-to-blinky/7826


The idea is to manage complex board edges in a mechanical environment
to be able to check collisions and dimension constraints.

Regards
Maurice

On 11/21/2017 6:42 AM, Henner Zeller wrote:

Hi,
So polygons are very neat as they employ the nice polygon drawing
features we are used to from zone drawing [*1].

A missing feature here is to _not_ have them filled but simply an
outline. Why ? This would be _very_ useful to draw Edge.Cuts.
Currently, the only way is to draw single lines, which are then hard
to adjust later, as they all fall apart into separate lines, and have
to be edited manually.

Now, if that could be drawn with the polygon tool, that would remove a
hge pain having to deal with outlines (and yes, I know the usual
advice to draw that separately and import as DXF. But what if I could
just do simple polygons directly ?).

Also what we could get for almost free then: Chamfers and Fillets. I
like to have boards with rounded corners [*2], but currently this is
of course a torture to do manually and and dread it every time it
comes to that part of the project: draw a rectangle with the line
tool. Do circles in the corners and manually calculate where the
center and the start point is, shorten the lines accordingly to match
the length shorter the radius. Do that on all four corners. That
easily takes several minutes and high concentration. And god forbid
one wants to change that again later ...

Now how wounderful that would be if that could be done with the
Polygon tool and I just choose to have a fillet or camfer. If this is
something nobody is working on yet and if people think this is a good
idea, I might have a look over the Thanksgiving days.

Cheers,
    Henner.


[*1] also see my mail before [All kinds of glitches], Polygons as-is
are currently broken and maybe the concept should be merged with the
zone ?

[*2]
https://raw.githubusercontent.com/hzeller/quadrigotion/master/img/tmc2660-quad-render.jpg

___
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



--
 -Kristoffer

___
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] Hierarchical Schematic to contain link to pcb

[Kristoffer Ödmark]

Hello!

I suspect this has been discussed before in different formats. But anyway.

What would be the major problems or concerns with allowing a schematic 
to have a pcb as file to include? What I mean is that the same way we 
let a symbol have a footprint in eeschema, we let a schematic point to a 
pcb file that is included before footprints are added to the pcb.


Every subschematic has a unique timestamp that could be added to every 
existing footprint in the schematic and should prove a sufficient way 
fix every designator number in the schematic in case a pcb is included 
multiple times.


I guess this would mean that at a later date the pcb-items would need to 
be able to be added to a group of some sort, so that one could easily 
move the newly included pcb as one.


Thinking about it this grouping is actually required, otherwise updating 
the pcb from the schematic might be impossible due to the fact that a 
board may contain items such as segments, which do not contain any 
unique id.


There is a huge gain from this, since it would allow multiple users to 
work on the same pcb in a different manner, allocating a space for their 
subschematic / subpcb etc, and also it would allow design reuse much easier.


Problems i see:

When parts of an imported pcb is updated how to handle it?
- ( Propose to have a toggle to update all from imported pcb, or to 
ignore those coming from an imported pcb )



How should the grouping be available?
-  ( Propose only let kicad group based on imported pcb and 
therefore every item can only have one group belonging or none group 
belonging, not changeable by the user )



If a subscheet has a subscheet, and both have an assigned pcb, how do we 
add this?

-  ( Propose that only the highest level pcb be used )

How can one move all the parts of one imported pcb as a group, and how 
to change only a single item of the imported pcb?
-  ( Have the disambiguation of meny show both the component and 
the group when selecting a component belonging to a group, toggle this 
behaviour on/off in a button from the toolbar, similar to the allow drc 
toggle )


How will this be managed by kicad?
-  ( Assume that each subpcb and subschematic is a standalone 
project and therefore let the user worry about this, but add a demo 
showcasing this hierarchy with a ./main.{pro,sch,kicad_pcb} and a 
./subpcb/subpcb.{pro,sch,kicad_pcb} )



--
 -Kristoffer

___
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] Fix for 3D model offset

[Kristoffer Ödmark]

The short time i have been reading the ML I have seen this issue a few
times, I have been fooled myself and I know that a patch was issued and
later retracted.

Storing every value except one in mm is just confusing. The proposed
solution will not break  *any* existing library.

The file format is already not consistent with old versions of kicad.
Please do not be afraid of moving towards something more consistent and
please stop defending having bad design decision just because it has always
been that way.


On Nov 10, 2017 22:11, "Cirilo Bernardo" <cirilo.berna...@gmail.com> wrote:

I would also prefer the option to simply store 3D units in inches;
we just need to document this. Truncation will not be a problem
for 3D models; if the models move by 0,01mm no one will care
(or if someone does care then they need to go back to engineering
school). I think this is a case where history has set restrictions
on what we can do and there's no value in making a change since
it has terrible implications on the footprint libraries.

- Cirilo


On Thu, Nov 9, 2017 at 8:48 PM, Oliver Walters
<oliver.henry.walt...@gmail.com> wrote:
> JP,
>
> I think that 3) is the better option, because it preservers PCB file
> compatibility (as long as the offset is zero). Any time the PCB is saved,
> the (at (xyz 0 0 0)) gets written.
>
> You are also correct that none of the official library footprints have a
> defined offset. This is why i have never encountered this before.
>
> On Fri, Nov 10, 2017 at 7:09 AM, Oliver Walters
> <oliver.henry.walt...@gmail.com> wrote:
>>
>> I like 2) or 3) - I think that a major release is a good time to fix such
>> a bug.
>>
>> Would you like me to add a patch implementing one of these options JP?
>>
>> On 9 Nov 2017 23:33, "Kristoffer Ödmark" <kristofferodmar...@gmail.com>
>> wrote:
>>>
>>> Currently the footprints arent compatible anyway i guess, they support
>>> more than 4.07 footprints do. So option 2 is my preferred solution.
>>>
>>> On 11/09/2017 12:51 PM, jp charras wrote:
>>>>
>>>> Le 09/11/2017 à 11:12, Kristoffer Ödmark a écrit :
>>>>>
>>>>> My 2 cents is that the headaches of storing values in mixed units,
>>>>> without indication of which unit
>>>>> they are stored as is a huge drawback for readability of the saved
>>>>> files and for maintainability.
>>>>>
>>>>> Also I think the proposed new tag offset is a good idea, since the
>>>>> libraries can be gradually
>>>>> updated then. That the files cannot be opened by previous versions is
a
>>>>> minor problem, since the
>>>>> files cannot be opened by kicad 4.07 anyway already.
>>>>
>>>>
>>>> In fact, footprint files can be opened by 4.07 version, as long as they
>>>> contain no round rect or
>>>> custom pads (should be most of files)
>>>>>
>>>>>
>>>>> On 11/09/2017 12:55 AM, Wayne Stambaugh wrote:
>>>>>>
>>>>>> This requires a file version bump and code that tests for prior
>>>>>> versions
>>>>>> before converting the units on read.  At that point, the file will no
>>>>>> longer be compatible with prior version of KiCad.  I'm not opposed to
>>>>>> this but I'm not sure it's worth the headaches it will cause.
>>>>>>
>>>>>> On 11/08/2017 03:33 PM, Oliver Walters wrote:
>>>>>>>
>>>>>>> What about a controversial idea:
>>>>>>>
>>>>>>> Read "at" dimensions as inches, but new files write "offset" in mm.
>>>>>>>
>>>>>>> This preserves read compatibility but fixes the units issue going
>>>>>>> forward.
>>>>>>>
>>>> <...>
>>>>
>>>> There are 3 different things related to the anchor coordinate 3D shapes
>>>> in Oliver's patch:
>>>>
>>>> 1 - coordinate units inside Kicad: they should be in internal units
>>>> (I do not remember if it is currently the case).
>>>> no problem.
>>>>
>>>> 2 - Display unit name in dialog: good enhancement.
>>>>
>>>> 3 - how to store this anchor coordinate in .kicad_pcb files.
>>>> There are 2 options:
>>>> opt 1 - use keyword "at" and store it in inches (current case).
>>>> Certainly annoying because all other
>>>> coordinates

Re: [Kicad-developers] [REQUEST] Default library install location

[Kristoffer Ödmark]

Personally I think this is a nice solution

http://1.bp.blogspot.com/-3u-eixTrMbI/VDWb25kPNkI/A-g/0qn7ehRq4Mo/s1600/ReadOnly.PNG

Very helpful, instead of the "Edit document" button, there could be 
something such as "Copy to user-library for edit".


- Kristoffer

On 11/09/2017 02:02 AM, Wayne Stambaugh wrote:

Would a dialog asking if you want to save a modified library that is
read only to a new folder be an acceptable solution?  If so, please file
a bug report and set its status to wish list.  I'm not sure when someone
will get around to it but at least we will have a record of it.

On 11/8/2017 7:07 PM, Simon Wells wrote:

i wouldn't particularly call it handholding but i do believe its something that 
should be automatically done by kicad if we are to continue bundling such a 
number of libraries. The extra command in the toolbar is not particularly 
obvious unless you already know about it or it is pointed out to you, i would 
almost prefer it to be something that is not a specific command and the code is 
only used when you go to save to a system library. although it should 
notify/warn that it is a system library and due to this will be copied into 
your local user library/dir



On 9/11/2017, at 13:04, Wayne Stambaugh  wrote:

Exactly how much hand holding is KiCad expected to do?  There is already
a "save the current library as" command in the file menu of both the
symbol and footprint library editors.  There is a small bug in that
grays out the command until you load a symbol but it allows you to save
any library to a folder that the user has write access to and modify it
at will without changing the originally installed libraries which IMO is
a good thing.  Of course you could do a good old fashion file copy or
git clone or ...  How many ways to we really need to perform this one
simple task or am I completely missing something.

On 11/08/2017 06:15 PM, Simon Wells wrote:

ideally if someone tried to save to a bundled library there should be something 
that pops up and says you can't/shouldn't and then offers to do most if not all 
of that for you, however i would prefer to see it only saving the footprint to 
userdir, i think you will find this is how most other software would handle a 
similar circumstance


On 9/11/2017, at 12:12, easyw  wrote:


I think it's a far more risky that a user makes accidental changes to the
bundled library. Simple users should not need to touch it, and should
rather copy or make a new part.


so if a user wants to add a missing parts to his/her library he/her needs to 
save it to a different location, close the i.e. fp editor, copy with 
administrative privileges the fp to the Admin folder and restart the sw to use 
it?
I don't think other sw are using this procedure...
This is just my opinion...


___
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



___
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] Fix for 3D model offset

[Kristoffer Ödmark]

Currently the footprints arent compatible anyway i guess, they support 
more than 4.07 footprints do. So option 2 is my preferred solution.


On 11/09/2017 12:51 PM, jp charras wrote:

Le 09/11/2017 à 11:12, Kristoffer Ödmark a écrit :

My 2 cents is that the headaches of storing values in mixed units, without 
indication of which unit
they are stored as is a huge drawback for readability of the saved files and 
for maintainability.

Also I think the proposed new tag offset is a good idea, since the libraries 
can be gradually
updated then. That the files cannot be opened by previous versions is a minor 
problem, since the
files cannot be opened by kicad 4.07 anyway already.


In fact, footprint files can be opened by 4.07 version, as long as they contain 
no round rect or
custom pads (should be most of files)


On 11/09/2017 12:55 AM, Wayne Stambaugh wrote:

This requires a file version bump and code that tests for prior versions
before converting the units on read.  At that point, the file will no
longer be compatible with prior version of KiCad.  I'm not opposed to
this but I'm not sure it's worth the headaches it will cause.

On 11/08/2017 03:33 PM, Oliver Walters wrote:

What about a controversial idea:

Read "at" dimensions as inches, but new files write "offset" in mm.

This preserves read compatibility but fixes the units issue going forward.


<...>

There are 3 different things related to the anchor coordinate 3D shapes in 
Oliver's patch:

1 - coordinate units inside Kicad: they should be in internal units
(I do not remember if it is currently the case).
no problem.

2 - Display unit name in dialog: good enhancement.

3 - how to store this anchor coordinate in .kicad_pcb files.
There are 2 options:
opt 1 - use keyword "at" and store it in inches (current case). Certainly 
annoying because all other
coordinates use mm, but this is not a major issue.
opt 2 - be able to read "at" (inches) and "offset" (or perhaps "anchor") (in 
mm) and use offset as
new keyword: but it breaks compatibility with old (namely the recent 4.07) 
kicad version.
opt 3 - same as 2, but stores "offset" (or "anchor") *only* if it is not the 
default value (0 0 0).
AFAIK, the default value is the case of most (perhaps all) footprint files in 
our official repo.

in case of option 2, the parser should be (obviously) able to understand the keyword  
"offset" (or
"anchor") to prepare the future.



___
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] Update of KiCad documentation?

[Kristoffer Ödmark]

That doesnt sound like a good idea, when adding patches, just having to 
add a line or two to the commit message seems best, and I imagine the 
news or changelog file is just there to later help the kicad-doc repo to 
do a proper changelog. Having to go to a new repo seems a bit more annoying.


Or skip the file totally this time, and just enfore the commit messages. 
This way this will not be such a hassle next time one wonders what have 
changed between versions.


On 11/09/2017 11:05 AM, Nick Østergaard wrote:
I think this might be better handled as bugs on the kicad-doc repo. Then 
everyone can contribute easily and we can track it for the 
documentation, where the info is to be used anyways. For now label 
them new_kicad_feature if it is.


2017-11-09 10:54 GMT+01:00 Kristoffer Ödmark 
<kristofferodmar...@gmail.com <mailto:kristofferodmar...@gmail.com>>:


I think for this to start happen, a decision has to be made, and
enforced by everyone with commit access to the repo.

Bugfixes need not be tagged like this. Major changes only.

I still think a we should start collect a list in the repo with
changes from kicad 4 up to the point this commit message policy is
set. I for one love reading changelogs when upgrading, and I think
the users are expecting this as well, and it probably will be useful
in the FOSDEM presentation :)


On 11/04/2017 01:53 AM, Wayne Stambaugh wrote:

On 11/3/2017 8:54 AM, Maciej Sumiński wrote:

On 11/03/2017 11:30 AM, Kristoffer Ödmark wrote:

I think starting small would be best in this case. The
least needed
would be a "News" File, that is always refering to kicad
stable.

I propose the same way that patches with policy errors
are rejected,
patches that introduces new functionality or change of
existing
functionality are required to add to the News file, max
one line. Just
something like this, I would like markdown formatting.


Changes from Kicad 4
=

NEW: Pcbnew now supports clipboard copy/paste
CHANGE: Delete button now removes entire trace, not just
a segment
CHANGE: Icons in toolbar are improved
REMOVED: Autorouter no longer exists


This style could also be applied in the git commit
message, making it
easy to compile by something such as 'git log | grep "NEW:"'

But since that is lacking, I think starting a new file
is best.


I vote for git commit messages following a specific format
(could be
NEW:/CHANGE:/REMOVE: lines) to easily create change logs. It
is much
easier to see with git what has changed in a specific period
of time.
With NEWS file you would need at least put dates there to be
able to do
that (or see with git when a specific line has been added).

I know that ideally the user documentation should be updated
together
with the code, but on the other KiCad changes so fast, so
there might be
a lot of wasted time spent on changing the documentation and
updating
screens that might be invalid in a week or two. For sure the
documentation should be refreshed for a stable release.

Regards,
Orson


I'm not opposed to this idea but it should be used sensibly. 
Not all

new, changed, or removed code will require documentation changes.  I
would also prefer it not be in the first line of the commit message
unless the commit message is only one line.  It's already
difficult to
fit a descriptive commit title with only 72 characters.

Cheers,

Wayne

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


-- 
  -Kristoffer



___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
 

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

[Kristoffer Ödmark]

My 2 cents is that the headaches of storing values in mixed units, 
without indication of which unit they are stored as is a huge drawback 
for readability of the saved files and for maintainability.


Also I think the proposed new tag offset is a good idea, since the 
libraries can be gradually updated then. That the files cannot be opened 
by previous versions is a minor problem, since the files cannot be 
opened by kicad 4.07 anyway already.


On 11/09/2017 12:55 AM, Wayne Stambaugh wrote:

This requires a file version bump and code that tests for prior versions
before converting the units on read.  At that point, the file will no
longer be compatible with prior version of KiCad.  I'm not opposed to
this but I'm not sure it's worth the headaches it will cause.

On 11/08/2017 03:33 PM, Oliver Walters wrote:

What about a controversial idea:

Read "at" dimensions as inches, but new files write "offset" in mm.

This preserves read compatibility but fixes the units issue going forward.

On 9 Nov 2017 03:15, "jp charras" > wrote:

 Le 08/11/2017 à 11:05, Oliver Walters a écrit :
 > Attached is a patch that fixes the problems I found in my 3D model
 array investigation. As
 > discussion on that is stalled for now, this patch simply fixes the
 model offset issues.
 >
 > 1. Display offset units in 3D preview window
 >
 > - Offset units are displayed (either inches or mm)
 >
 > 2. Fix offset in 3D rendering
 >
 > - It appears that the internal units for 3D model offset (mm) were
 being multiplied by 25.4 incorrectly
 > - Fixed rendering in OGL and Raytracing
 >
 > 3. Fix offset in 3D export
 >
 > - VRML export
 > - STEP export
 >
 > Oliver

 Hi Oliver,

 Looks like currently, Pcbnew stores 3D offset in inches, unlike any
 other value.
 This is very annoying, but we have to leave with that.

 Therefore the patch breaks compatibility with any other Pcbnew
 version, if 3D offset is not 0.


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



___
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



--
 -Kristoffer

___
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] Update of KiCad documentation?

[Kristoffer Ödmark]

I think for this to start happen, a decision has to be made, and 
enforced by everyone with commit access to the repo.


Bugfixes need not be tagged like this. Major changes only.

I still think a we should start collect a list in the repo with changes 
from kicad 4 up to the point this commit message policy is set. I for 
one love reading changelogs when upgrading, and I think the users are 
expecting this as well, and it probably will be useful in the FOSDEM 
presentation :)


On 11/04/2017 01:53 AM, Wayne Stambaugh wrote:

On 11/3/2017 8:54 AM, Maciej Sumiński wrote:

On 11/03/2017 11:30 AM, Kristoffer Ödmark wrote:

I think starting small would be best in this case. The least needed
would be a "News" File, that is always refering to kicad stable.

I propose the same way that patches with policy errors are rejected,
patches that introduces new functionality or change of existing
functionality are required to add to the News file, max one line. Just
something like this, I would like markdown formatting.


Changes from Kicad 4
=

NEW: Pcbnew now supports clipboard copy/paste
CHANGE: Delete button now removes entire trace, not just a segment
CHANGE: Icons in toolbar are improved
REMOVED: Autorouter no longer exists


This style could also be applied in the git commit message, making it
easy to compile by something such as 'git log | grep "NEW:"'

But since that is lacking, I think starting a new file is best.


I vote for git commit messages following a specific format (could be
NEW:/CHANGE:/REMOVE: lines) to easily create change logs. It is much
easier to see with git what has changed in a specific period of time.
With NEWS file you would need at least put dates there to be able to do
that (or see with git when a specific line has been added).

I know that ideally the user documentation should be updated together
with the code, but on the other KiCad changes so fast, so there might be
a lot of wasted time spent on changing the documentation and updating
screens that might be invalid in a week or two. For sure the
documentation should be refreshed for a stable release.

Regards,
Orson



I'm not opposed to this idea but it should be used sensibly.  Not all
new, changed, or removed code will require documentation changes.  I
would also prefer it not be in the first line of the commit message
unless the commit message is only one line.  It's already difficult to
fit a descriptive commit title with only 72 characters.

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



--
 -Kristoffer

___
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] [FEATURE] Array 3D models

[Kristoffer Ödmark]

To be fair, as it stands now, even if it is "only" for the pin headers, 
this is close to half of the 3d library size as of now.


The pin headers can now be of an arbitrary size as well. Someone can now 
create a 4x6 pin header for example, and the current footprints can be 
converted to this array system, thus reducing the size.


Arbitrary pin headers are a step up anyway.

This being said, I have not tested the patch yet, but even if it is 
"only" for pin headers, the idea is sound to me.



On 11/06/2017 04:22 PM, easyw wrote:

Hi Oliver,

I'm sorry not to be on your side for this option...

1) for which kind of modules this array is applicable?
I see only pin-headers straight and angled...
for example box headers are not easily done unless you consider to 
manage by the code the box for each model
2) the problem related to the big 3D library dimension will not be 
covered unless for some little family that can be managed by this on the 
fly generator


As I already suggested, the issue with the huge 3D github library can be 
managed in a different way:
1) give the kicad users only a basic 3D library (i.e. most used smd and 
th families)
2) give an option to pcbnew to automatically create a list of the 
missing models needed for a project and collecting only them through a 
wget process...


This will give a very low downloading band need and will not increase 
the need of disk space for having all the 3D library locally, full of 
unwanted models.


Here a conversation of this issue:
https://github.com/KiCad/kicad-library/issues/1532#issuecomment-341707706

my two-cents
Maurice

On 11/06/2017 3:01 PM, Oliver Walters wrote:
To provide an option to reduce the size of the 3D model library, I 
have implemented an "array" feature for 3D models. A module 
(footprint) can reference a single model multiple times, with a 
dimensional offset between each copy.


(Note - just the PinHeader models are currently over 1GB! This feature 
lets you use a single 3D model for all pin headers or similar 
repetitive footprints within a certain series).


Features:

1. Specify repeat count and repeat step in x/y/z axes
2. Save / load implemented. (If no repeat option used, no extra output 
is generated - old files are not touched)

3. Render in 3D viewer
4. Render in raytracing viewer
5. Export to VRML (multiple references to single file)
6. Export to STEP

Notes:

a. An exported STEP file will now be (possibly) much smaller as it 
references a single small object multiple times
b. There were a couple of bugs I found where model offset units were 
incorrectly translated between INCHES and MM


A couple of screenshots:

https://imgur.com/a/EOwPh


Testing:

Wayne verified that the file units for 3D model data are in mm - I 
*think* this means that there was previously a bug regarding 3D model 
offset, where the scaling factor in the file was interpreted as inches 
when exporting (e.g. to STEP)


I believe I have fixed this bug - confirmation would be great.

Cheers,
Oliver


___
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


--
 -Kristoffer

___
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] Update of KiCad documentation?

[Kristoffer Ödmark]

I think starting small would be best in this case. The least needed 
would be a "News" File, that is always refering to kicad stable.


I propose the same way that patches with policy errors are rejected, 
patches that introduces new functionality or change of existing 
functionality are required to add to the News file, max one line. Just 
something like this, I would like markdown formatting.



Changes from Kicad 4
=

NEW: Pcbnew now supports clipboard copy/paste
CHANGE: Delete button now removes entire trace, not just a segment
CHANGE: Icons in toolbar are improved
REMOVED: Autorouter no longer exists


This style could also be applied in the git commit message, making it 
easy to compile by something such as 'git log | grep "NEW:"'


But since that is lacking, I think starting a new file is best.


On 11/03/2017 09:50 AM, Marco Ciampa wrote:

On Fri, Nov 03, 2017 at 08:55:54AM +0100, Carsten Schoenert wrote:

Hello Wayne,

Am 03.11.2017 um 00:58 schrieb Wayne Stambaugh:

No one is going to argue that our documentation could be improved.  I'm
not really sure what the best approach would be to do that.  I would
prefer that we work with the tools and infrastructure we already have in
place rather than create a new dependency if at all possible.


nobody want's to introduce new tools or dependencies as long as there is
no body that will do the work. And I agree with you, I see no need for
something like that. The existing structure and tool-sets is working
well so far.


  What
about creating a documentation todo list asciidoc file in the
documentation repo.  The list would be broken down into two sections,
undocumented features and out of date/obsolete features.  Each section
can be broken down by application.  This would give folks looking to
help an idea of what needs to be done.


Yes and no, for existing topics that are poorly documented or need some
refreshing due passed time with upstream changes this may work. And
there are some kind of list already due some issues that are raised in
the issue tracker on the repo site.


agree 100%


But my starting posting was more about the currently new but completely
undocumented features that come with version 5 of KiCad. I can't see any
possible effort on that based on your proposal due "external" people
mostly doesn't know what to document at all. At least within the last
year there is no one single addition in progress here.


agree 100% see my previous post


But the main English documentation needs to be ready before any
translators should start.


In an ideal world yes.

1) or at least if someone fixies some spelling errors in the English
language, he/she must also/is responsible to un-fuzzy the corrispondant
strings in all the other languages .po files

and

2) must do this after asking all translators to do commit their
translations to avoid nasty conflicts and race conditions. Merge works
only using some special filters that do not diff comments in translation
files (.po) for example...

The problem here is that to avoid loss of locally updated translations
during a merge, each translator should use a specific merge tool for .po
files. Perhaps this can be resolved with some scripting inserted in the
cmake files. Some operation like this:

make manualname_languagecode_update #contains a git pull ...
mkdir build; cd build; cmake ..; etc... #for check
git commit -a -m "Updated translation of MANUALNAME in LANGUAGE"



I can remember some discussion there I wanted
to change some spelling and formatting of the files in the master branch
(not the 4.0 branch!) which wasn't accepted due the impact in every PO
file down in the various languages. So I don't really want to put again
some energy on that before things are clear.


Right see previous comment...


We need some agreement first what needs or should be added to the
documentation of KiCad5. If there is something like that existing we
than need people who take care on that.


Agree again...



--
 -Kristoffer

___
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] Update of KiCad documentation? (when to release kicad-5.0)

[Kristoffer Ödmark]

How does the documentation work now? Do we have any standardisation on 
how to document?


On 11/01/2017 09:53 AM, Maciej Sumiński wrote:

On 11/01/2017 09:40 AM, Carsten Schoenert wrote:

Hello Wayne,

Am 31.10.2017 um 13:06 schrieb Wayne Stambaugh:

We are very close to a feature freeze and creating a 5 stable branch.
Once that is done, it typically takes a few months to make sure there
are no critical or major bugs before we can release.  The goal is to
have it released before FOSDEM 2018 so I have some good news to deliver
during the KiCad presentation.


I guess we are all happy to see the incredible and amazing evolving of
KiCad within a new version 5. I'm thankful to all people and companies
who have contributed in the past year!

As one of the persons which tries to keep the German translations
up2date I'm a bit concerned if this targeted timeline is possible
especially for KiCad documentation!?
Given that most of all the new features are not made it into kicad-doc
yet and the mess that every change in the master PO files brings for the
updates of the specific languages I think it would be at least a big
issue if with releasing of KiCad5 no actual documentation even in en_US
is available. Missing documentation is one of the major annoying things
for users!

I'm not a native English speaking person so even if I had time (and the
correct knowledge about the new features) I can't help much here. But I
wanted to raise my concerns about this missing thing.

Is here something planned or someone has started to work in this corner
and/or is there a place this is tracked? There are only about three
months left until FOSDEM.


Hi Carsten,

I share your concerns about the documentation. Nevertheless, before we
start working on the docs, I think we need to reach the feature freeze
stage, otherwise documentation would have to be updated too frequently
during the development cycle.

We are going to need at least a few more weeks after the feature freeze
starts to iron out bugs. During this period the user interface and
functionality should not change, so it would be the best time to update
the documentation. I suppose we should start updating the manuals early,
so the translators have the time to react as well.

Regards,
Orson



___
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



--
 -Kristoffer

___
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] Nest level error, causes problems with git

[Kristoffer Ödmark]

Whoops, managed to mess upp the coding style while only changing 3 
lines.. not very good


Updated

On 10/27/2017 11:03 AM, Kristoffer Ödmark wrote:
Hi! I found that the nest level when saving stuff is wrong ( error from 
the clipboard plugin ).


This patch fixes that so that version control systems doesnt generate 
large diffs when saving.





--
 -Kristoffer
>From 2a873579a1140c5fbbb98bb2e1a74b958acb49a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= <kristoffer.odmar...@gmail.com>
Date: Fri, 27 Oct 2017 10:59:49 +0200
Subject: [PATCH] Fixed nest level when saving to not get giant diffs with
 version control software such as git

---
 pcbnew/kicad_plugin.cpp | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/pcbnew/kicad_plugin.cpp b/pcbnew/kicad_plugin.cpp
index ad1a5a021..c26599bd3 100644
--- a/pcbnew/kicad_plugin.cpp
+++ b/pcbnew/kicad_plugin.cpp
@@ -532,8 +532,6 @@ void PCB_IO::formatSetup( BOARD* aBoard, int aNestLevel ) const
 {
 const BOARD_DESIGN_SETTINGS& dsnSettings = aBoard->GetDesignSettings();
 
-m_out->Print( 0, "\n" );
-
 // Setup
 m_out->Print( aNestLevel, "(setup\n" );
 
@@ -764,9 +762,9 @@ void PCB_IO::formatNetInformation( BOARD* aBoard, int aNestLevel ) const
 
 void PCB_IO::formatHeader( BOARD* aBoard, int aNestLevel ) const
 {
-formatGeneral( aBoard );
+formatGeneral( aBoard, aNestLevel );
 // Layers.
-formatBoardLayers( aBoard );
+formatBoardLayers( aBoard, aNestLevel );
 // Setup
 formatSetup( aBoard, aNestLevel );
 // Save net codes and names
@@ -775,7 +773,7 @@ void PCB_IO::formatHeader( BOARD* aBoard, int aNestLevel ) const
 
 void PCB_IO::format( BOARD* aBoard, int aNestLevel ) const
 {
-formatHeader( aBoard );
+formatHeader( aBoard, aNestLevel );
 
 // Save the modules.
 for( MODULE* module = aBoard->m_Modules;  module;  module = module->Next() )
-- 
2.14.3

___
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] [PATCH] Nest level error, causes problems with git

[Kristoffer Ödmark]

Hi! I found that the nest level when saving stuff is wrong ( error from 
the clipboard plugin ).


This patch fixes that so that version control systems doesnt generate 
large diffs when saving.



--
 -Kristoffer
>From d07b38f27509533de087a089febfe68dd8fb58db Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= 
Date: Fri, 27 Oct 2017 10:59:49 +0200
Subject: [PATCH] Fixed nest level when saving to not get giant diffs with
 version control software such as git

---
 pcbnew/kicad_plugin.cpp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/pcbnew/kicad_plugin.cpp b/pcbnew/kicad_plugin.cpp
index ad1a5a021..1edb48d08 100644
--- a/pcbnew/kicad_plugin.cpp
+++ b/pcbnew/kicad_plugin.cpp
@@ -764,9 +764,9 @@ void PCB_IO::formatNetInformation( BOARD* aBoard, int aNestLevel ) const
 
 void PCB_IO::formatHeader( BOARD* aBoard, int aNestLevel ) const
 {
-formatGeneral( aBoard );
+formatGeneral( aBoard ,aNestLevel );
 // Layers.
-formatBoardLayers( aBoard );
+formatBoardLayers( aBoard ,aNestLevel );
 // Setup
 formatSetup( aBoard, aNestLevel );
 // Save net codes and names
@@ -775,7 +775,7 @@ void PCB_IO::formatHeader( BOARD* aBoard, int aNestLevel ) const
 
 void PCB_IO::format( BOARD* aBoard, int aNestLevel ) const
 {
-formatHeader( aBoard );
+formatHeader( aBoard , aNestLevel);
 
 // Save the modules.
 for( MODULE* module = aBoard->m_Modules;  module;  module = module->Next() )
-- 
2.14.2

___
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] Datasheet confusion

[Kristoffer Ödmark]

Seems there are no major objections :) Bumping this so it doesnt get 
lost in history :)


On 10/19/2017 09:57 PM, Wayne Stambaugh wrote:

Looks good to me.  If there are no major objections I will merge this patch.

On 10/19/2017 11:53 AM, Kristoffer Ödmark wrote:

I tested the GetAssociatedDocument, works much better and has more
features so i took the freedom of updating the dialog windows to use
that instead of the wxLaunchDefaultBrowser as well

attaching patch :)

- Kristoffer

On 10/19/2017 02:07 PM, Wayne Stambaugh wrote:

On 10/19/2017 7:09 AM, Kristoffer Ödmark wrote:

Yes indeed it breaks that, I would argue that having an "invisible"
field opened when using the context field is the source of the
confusion. So I am aware it breaks the context menu for old schematics
but think it is necessary anyway.


I'm OK with this change.  I'm not sure why we would use the document
field from the library symbol rather the schematic symbol.  AFAIK, we
don't do that for any other schematic symbol fields.



I can of course use GetAssociatedDocument instead.

On Oct 19, 2017 12:54 PM, "jp charras" <jp.char...@wanadoo.fr
<mailto:jp.char...@wanadoo.fr>> wrote:

  Le 18/10/2017 à 20:20, Kristoffer Ödmark a écrit :
  > Glad to hear it, I fixed a patch up that will highlight the
  differences a bit better than I explain it.
  >
  > Basically it will fill the field from the properties if the field
  is empty when adding components to
  > the schematic.
  >
  > It will also use the Field to determine when to show the context
  menu instead of relying on the
  > library.
  >
  > - Kristoffer
  >

  Unfortunately, it breaks access to the associated document for
  existing schematics, that can have a
  datasheet name set in library, but not in schematic.

  and calling:
  ::wxLaunchDefaultBrowser( text ); is incorrect
  (text is not always a .pdf doc with a full absolute path or URI)
  see:
  GetAssociatedDocument()

  --
  Jean-Pierre CHARRAS

  ___
  Mailing list: https://launchpad.net/~kicad-developers
  <https://launchpad.net/~kicad-developers>
  Post to     : kicad-developers@lists.launchpad.net
  <mailto:kicad-developers@lists.launchpad.net>
  Unsubscribe : https://launchpad.net/~kicad-developers
  <https://launchpad.net/~kicad-developers>
  More help   : https://help.launchpad.net/ListHelp
  <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



___
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



--
 -Kristoffer

___
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