from:"Rene Pöschl"

Re: [Kicad-developers] 3D-Viewer: limit scale to positive values?

2020-09-29 Thread Rene Pöschl


Hi,

just to clarify: the 3d models of the official library must be created 
such that the scaling factor in the footprint is set to 1. We are 
currently rewording the whole section to be clearer 
https://gitlab.com/kicad/services/kicad-website/-/merge_requests/502


On 29/09/2020 18:30, Ian McInerney wrote:
We can't remove the scaling option until we make the VRML importer 
handle proper unit selection. I have routinely run into the case where 
I go OpenSCAD -> Wings3D -> KiCad and design a model using mm in 
OpenSCAD because it makes for easier computations (all the datasheet 
values are nicely given in mm) and then have to apply a scaling factor 
of 0.3937 to all the axes in KiCad to make it the proper size because 
we seem to have a hardcoded assumption about what unit system the VRML 
file is in.


In fact, the KLC says: WRL files do not specify absolute dimensions. 
KiCad normalizes model parameters to units of inches and the internal 
units (dimensionless) of the WRL model must be scaled accordingly.


-Ian

On Tue, Sep 29, 2020 at 4:50 PM Seth Hillbrand > wrote:


There has been some discussion to removing the scale option here
altogether.  The logic being that if you need the model scaled,
you should be doing this in your solid CAD not in your electronic
CAD.  I have come around to this idea and it might be worth
implementing rather than doing the scale limiting.

-Seth

On Tue, Sep 29, 2020 at 4:52 AM Mário Luzeiro mailto:mrluze...@ua.pt>> wrote:

Hi all,

I'm wondering if it is safe to limit the scale of shapes to be
positive values?

Applying negative scales will cause inverted shapes and render
issues on the models.

Could be that anyone in the world is using negative scale values?
or should be safe to limit it?

This is related with this issues:
https://gitlab.com/kicad/code/kicad/-/issues/5817

Mario
___
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 Services Corporation Logo

Seth Hillbrand
*Lead Developer*
+1-530-302-5483‬ 
Davis, CA
www.kipro-pcb.com  i...@kipro-pcb.com


___
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] Change in Library Team Leadership

2020-08-26 Thread Rene Pöschl


Hi all,


the bad news up front, I no longer have the time to properly handle 
leading the library team as i am now working full time and still have my 
education to finish (Covid isn't much help either as it makes me lose a 
bit of time as i try to avoid public transport at peak hours).



And now the good news. Christian Schlüter has volunteered to take over 
as the team leader. I personally plan to be around and help as much as i 
can with reviews but simply feel that i should give somebody a chance to 
grow who has more time on their hand. To be honest i think he already 
took on part of my roles as i had been absent for quite some time 
(partly hoping i will find more time and partly just not wanting to 
admit that i don't have it anymore).



Kind regards Rene


___
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] How do we envision Pad Stacks?

2020-06-11 Thread Rene Pöschl

Hi, my answers below

On 11/06/2020 16:54, Jeff Young wrote:
I had been assuming that you could define a separate shape for each
layer. Full flexibility, but time-consuming to edit (even with
commands such as “push current layer to other layers”).

One could have a simple mode and advanced mode. The simple mode allows
defining your typical run of the mill stuff and the advanced mode gives
full flexibility. In this case the simple mode could be the same shape
on all layers and advanced mode would allow defining differing shapes on
all layers.

Most users are looking to route traces on inner layers between tight
pads. This is commonly done with the definition of a “capture pad”.
The constraint on inner layers that have connecting tracks is simply
not to have a butt joint between the track and the plated hole. A
capture pad is therefore a circular pad with an annulus width of the
drill wander plus 1 or 2 mils; other capture pad shapes get you
nothing more.

This sounds like a good idea in general. But especially for vias.

There were also a few requests for SMD pads on a single inner layer
(or perhaps multiple) — but importantly not for different shapes on
different layers.

SMD pads on a inner layer (or lets call them a "pad on the inside
without a hole") make sense for some usecases. However currently they
are mostly requested as a workaround for missing features. Like a lack
of support of area defined layer differences (for example in rigid flex
or 2.5D technology where some components are inset into the board) and
even for net-ties. I suspect a lot of these workarounds will be made
obsolete as kicad develops further.

So one could imagine allowing the pad shape to be placed on any number
of layers, and a capture annulus width for any other connected layers.
While it doesn’t have same flexibility, it would be a /lot/ easier to
edit.

This really only works if your base shape is circular. All current kicad
THT footprints however have at least one non circular pad as we mark pad
1 that way. (We use rounded rect or rect for this purpose)

And footprints meant for handsoldering are often made with elongated
pads (oval pads).

Another possible complication is wanting a different shape for mask
(or paste) layers. Is this ever required?

Paste and mask layers can already be made different by having paste or
mask only pads placed and removing these layers from the normal pad. I
am not sure we win much by having this as part of a single pad but can
see the appeal.

There is however something that would be awesome. If such a feature
could also create split paste pads and allow specifying the amount of
paste coverage then this feature would make a lot of sense especially if
the user can then easily change the coverage during the layout phase.
Even better would be if it could also add "vias" in some limited grid
patterns and have paste avoid being placed on top of them (or have every
paste section be influenced in the same manner by vias created that way
for consistency) then this would be even more powerful. However i would
assume this is more than a simple pad stack feature.

As an inspration take a look at the exposed pad class of our footprint
generator:
https://github.com/pointhi/kicad-footprint-generator/blob/master/KicadModTree/nodes/specialized/ExposedPad.py
and for resulting footprints take any QFN footprint generated. One good
example from the official lib is
QFN-76-1EP_9x9mm_P0.4mm_EP3.8x3.8mm_ThermalVias

And regarding mask. well in most cases clearance specification is
enough. But especially for mask defined pads clearance is not really the
setting one cares about. So a way to enter the requested final size
would help a lot here (right now we workaround here by making a mask
only pad that allows us to enter the required final size).

Where true mask control could come in handy would be a top tenting
option for vias inside a center (or exposed) pad (i think cypress still
suggests top tenting in their application notes).

___
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] no broken default fp-lib-table, removed footprint library

2020-05-19 Thread Rene Pöschl


On 17/05/2020 11:24, Carsten Schoenert wrote:

The main point is that projects simply should provide as much
information and communication as possible about the new versions they
provide. Distributions need always to think about how intrusive
modifications are, that's mainly a simple risk analysis.


A risk analysis as a first step requires understanding the requirements 
of the system in question! You being only worried about renamed library 
assets shows you don't understand what is important to the library (yes 
renamed libs can be annoying to our users which is why we typically 
avoid it without good reason).


The reason why a renamed library asset is basically irrelevant to our 
user is that KiCAd will tell them there is a problem and 99% will carry 
on as normal (especially the professional users). The real danger are 
certain changes to assets without them being renamed. Examples are any 
change to pin numbers or positions, any change in pad numbers or 
positions. Which is why we avoid these changes except to fix a bug 
(massively higher requirement for such changes to be allowed than any 
asset renaming). We have scripts that check for these dangerous changes 
helping us to avid them (the changes that are still in are documented in 
the log files on the release page as well as analyzed in detail in the 
release discussion that was linked in my release announcement).




What do you think if a contributor is providing a 1000 line patch for
KiCad and you have no further information than that pure diff?
That's mainly the situation for me regarding to symbols and footprints.



Again: learn what the library represents. It is not sourcecode. It makes 
no sense to talk about a diff! (Not a text based one at least. Graphical 
explanations of differences AS CONTAINED IN THE PULL REQUESTS linked to 
by the commit messages are what is important.)


Really i suggest you make a few boards with kicad, let me introduce a 
few changes to your personal copy of the library of after you assigned 
footprints but before you imported it to pcbnew (worst case time 
instance for a software update) and come back to me which changes you 
will care about in the future (I bet my life that the last thing you 
will worry about is changes to file names. Maybe after this experience 
will you finally understand why our priorities are where they are.)



___
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] no broken default fp-lib-table, removed footprint library

2020-05-14 Thread Rene Pöschl


On 14/05/2020 18:43, Wayne Stambaugh wrote:

Rene,

I wonder if we should implement a library commit message policy similar
to the one we use for the source repo[1] and tailor the changelog tags
for how library commits (or any other kicad repo) are made?  It's pretty
painless from a committers point of view since you already have to
provide a commit message with git.  Maybe a "PACKAGING" tag that could
easily be extracted would be helpful.  It probably wouldn't hurt to have
this tag in the source repo as well so we don't blindside package devs
with new dependencies and folder layout changes.

Cheers,

Wayne

[1]: https://docs.kicad-pcb.org/doxygen/commit_messages.html
.

I am against rejecting any library contributions because of git to be 
honest. Most of our contributors are complete novices with git. I kind 
of supect they are mostly electrical engineers not software engineers so 
quite unlikely to need git knowledge in their career. We might already 
filter out a lot of potentially good contributors with the very small 
git knowledge that we need to require and i don't want to increase the 
negative impact of git.



Right now we librarians write new messages for our contributors during 
the merge process (we use githubs squash feature). Because of that we 
can not use CI and not even a manual review to ensure following of some 
commit message rules. A fully manual workflow is extremely error prone 
so i doubt we will ever get a full changelog from git.



To be honest something similar to our changelog script that analyzes 
symbols might in the end be a better fit for the whole lib. Even better 
would be a graphical diff tool to be honest. And all of that build into 
kicad itself for example as part of the "update footprint/update symbol" 
tools. After all the library assets are graphical things. Describing 
changes to them using text is really not helpful at all.



___
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] no broken default fp-lib-table, removed footprint library

2020-05-14 Thread Rene Pöschl

The kicad library team does not have the resources to properly handle 
even our main tasks (see the number of open pull requests awaiting 
review, hint it is >300 with >600 open over all) let alone handling 
additional docu. Plus we are not working with sourcecode. The skills of 
the librarieans are in checking electrical constrains not git, not 
packaging, ...


Also consider that 90% of changes are additions of new assets which can 
only be documented in a graphical way (screenshots of the asset, 
dimensioned drawings, ...) so really the documentation is in the pull 
requests not in git (git links to the pull requests) again completely 
different to software!


See the kicad library more akin to optional binary assets instead of 
sourcecode (similar example would be the clipart library of a word 
processor)


---

I did not fully read your previous message so i do not quote it either 
;) (Another thing that is strange to at least me is a mailing list. I 
would be much more conferrable on a forum or even the issue tracker.)


lg Rene

___
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.6 Release Update

2020-05-13 Thread Rene Pöschl


On 13/05/2020 19:18, Kevin Cozens wrote:

On 2020-05-12 10:36 a.m., Nick Østergaard wrote:

The library is till on github:
https://github.com/KiCad/kicad-templates
https://github.com/KiCad/kicad-symbols
https://github.com/KiCad/kicad-footprints
https://github.com/KiCad/kicad-packages3D

The code, translation and docs are on gitlab:
https://gitlab.com/kicad/code/kicad
https://gitlab.com/kicad/code/kicad-i18n
https://gitlab.com/kicad/services/kicad-doc

Are those links valid for both the 5.x and 6.x libraries as long as we pull
from the right branch?


You must pull the tagged commit otherwise you get whatever got merged last.


___
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] Broken default fp-lib-table, removed footprint library

2020-05-12 Thread Rene Pöschl


On 12/05/2020 09:40, Carsten Schoenert wrote:

Hi,

I started to package the updated packages due the tagged KiCad 5.1.6
release and started alphabetically with the footprints as this is the
first directory locally.

More by an accident I noticed that the directory
Connector_Multicomp.pretty is now empty. Digging into the reason behind
that I can see that the whole content of this folder has moved into
Connector_IDC.pretty.

I see there multiple issues here.

1. For me this is a breakage (again) of the rule no changes within the
stable release cycle on the user side that can break user projects and
workflows.
Compared to a classical C/C++ library would this be a removal of a
public symbol without an wrapper for backward compatibility, means an
API/ABI break which requires a increasing of the ABI version.
What is broken here? The old library folder is still there to ensure 
users do not get an error message. Footprints are embedded in the design 
files so no negative impact on old designs. The new footprints are 
vastly superior to the old ones so the tradeoff is simply worth it!

2. The default footprint table (fp-lib-table) within the tagged 5.1.6
tree is still referencing the old folder so user get this installed as
the default base for their footprint library table if they install a new
KiCad version or enforce a new default table.


$ git grep -n Multicomp fp-lib-table
fp-lib-table:28: (lib (name Connector_Multicomp)(type KiCad)(uri 
${KISYSMOD}/Connector_Multicomp.pretty)(options "")(descr "Multicomp 
connector foottprints"))

Keeping that entry makes no sense to me if the folder is now empty.
Yes we could remove the entry but our CI script would complain -> so we 
decided to just have the empty lib it does not hurt anyone.

3. KiCad still has no internal mechanism to handle such removals within
the user space to adjust the local footptint table. Package
installations / removal doesn't touch or modify any user specific
configuration files so manual interaction from the user is needed to
adjust such cases.
Adding such an feature is not the responsibility of the library
maintainers of course, but makes such changes more difficult and
problematic within a stable release cycle. (And of course I don't want
to blame any one here!)
Well now you know why we keep the empty folder. (At least v5 does no 
longer crash with a missing lib.)


4. I haven't found a README or otherwise announcement about this change.
Also the commit message f764afb in kicad-footprints is rather short and
not explaining to me.

This all did already happen previously in 2017 in the releases of 4.0.5
and 4.0.7. At least two bug reports within Debian did happen due these
changes as this was leading to a breakage on the user side and also
leading to bad user experience.

https://bugs.debian.org/859409
https://bugs.debian.org/860093

In the past "we" solved the issues by adding symlinks from the old to
the new containing folder. Currently I'm undecided what to do here in
this new case.

Anyhow, please don't do such changes within a stable release cycle! It's
o.k. to do such things within major version bumps (as at some time it
must happen) but not within an increased *micro* version!
People do not expect such changes. And the majority of user isn't
following the development of KiCad itself or the libraries in deep! Keep
that in mind please. Thanks.

The two bug reports you list again clearly show why we now keep the 
libraries as empty instead of removing them.


___
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.6 Release Update

2020-05-11 Thread Rene Pöschl


Hi,

library is tagged. Some bugfixes on the symbol lib again result in 
changes that would break an existing schematic.


See details in issue comment:
https://github.com/KiCad/kicad-symbols/issues/2656#issuecomment-626880880

On 10/05/2020 18:07, Wayne Stambaugh wrote:

Since we are only a week away (Friday) from the proposed 5.1.6 release
date and none of the critical bugs seem to be reproducible,  I would
like to tag the 5.1 branch tomorrow along with the other repos so we
have time to allow the package builders to complete and website download
page to be updated by Friday so I can make the official announcement.
Is there anything else holding us back from this before I tag 5.1.6 in
the repo?

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] Is it really the case that installing KiCad on a Mac requires manually copying files around?

2020-04-25 Thread Rene Pöschl

s won't be able to open up due to macOS quarantining.
> """
>
> If someone wants to write a homebrew cask for using the mac DMG, I
> suspect it would only be an hour or so total, and then users could
> install with a single command in just a few minutes (however long it
> takes to download the DMG).  Previously, another developer made a
> homebrew recipe but it did not have a bottle, so it took hours to
> install on a user's computers.  This was before homebrew casks which
> should solve this problem.
>
> On Fri, Apr 24, 2020 at 9:35 AM Jon Evans mailto:j...@craftyjon.com>> wrote:
> >
> > I believe these users are talking about the normal MacOS
method of installing software,
> > which does typically involve copying files.
> >
> > Normally MacOS software is packaged as a disk image that is
mounted when you double click it.
> >
> > The mounted image then normally contains the software to be
installed, and shortcuts
> > that are used as drop targets for a "drag and drop" copy.
> >
> > Most software only has one "file" (the .app file, which is
actually a directory)
> > That file is copied to the Applications folder on the user's
system.
> >
> > KiCad's installation also involves copying a second folder to
a privileged location (Application Support),
> > so the user will be prompted for authentication when they do
this step.
> >
> > This part of the approach is not very common for commercial
MacOS software.
> > Software that must install to privileged locations typically
ships as a binary installer with a wizard,
> > more like what you would typically see on a Windows machine.
> >
> > I am not familiar enough with the MacOS packaging to know if
there is any potential for KiCad
> > to have a single app file that just gets copied to
Applications in the future.
> >
> > If we want to do fancy things such as write-protecting certain
parts,
> > probably the best bet would be to build a MacOS installer
wizard (a PKG file).
> > But, I don't know the details there either or if there are
reasons we cannot / should not.
> >
> > -Jon
> >
> > On Fri, Apr 24, 2020 at 10:22 AM Rene Pöschl
mailto:poesc...@gmail.com>> wrote:
> >>
> >> Hi all but especially adam,
> >>
> >>
> >> lately there where a few threads on the forum where
installation on Mac
> >> came up. The users reported that they installed KiCad by manually
> >> copying files around which sounded wrong to me. But as a lot
of users
> >> seem to be under the impression that this is indeed the right
way i am
> >> now starting to believe them.
> >>
> >> If these users are really correct then maybe this should be
documented
> >> very clearly on our download page. Or if there is any option
to automate
> >> this process (reducing human error) then maybe this would be
the better
> >> way to go long term but until then it should still be
documented what
> >> needs to be copied.
> >>
> >> One problem i see is if users can copy KiCad files then the
libs might
> >> not be write protected which would be a problem as KiCad
relies on the
> >> operating system write protection to avoid users modifying
the shipped
> >> libraries.
> >>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to     : kicad-developers@lists.launchpad.net
<mailto: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
<mailto: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
<mailto: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] Is it really the case that installing KiCad on a Mac requires manually copying files around?

2020-04-25 Thread Rene Pöschl


And again,

Sorry forgot to add this. There seem to be some problems for some users 
on Catalina. I am not sure if what got suggested on the forum [1] is the 
correct way to install KiCad on Catalina. Would be great if somebody 
knowledgeable would double check the proposed solutions and possibly 
clarify the exact workflow. I think it would then be beneficial if that 
cleaned up info would also be found on the Mac download page.


[1]: https://forum.kicad.info/t/solved-kicad-on-catalina/22189

On 25/04/2020 08:50, Rene Pöschl wrote:

Hi again,

might it be a good idea to add the content of the Readme to the download
page? That way it would bring the Mac download page to the standard of
the ubuntu one. (That page also explains the "normal" way to install
from a third party source.) Even better would be if screenshots are
included as the process is done in a graphical interface.

My reasoning here would be that having this info clearly visible without
needing to download anything would help anyone that needs to help others
install software on any platform. So the forum users, teachers and
possibly even the IT guys in companies might benefit from such detailed
explanations.

I would assume there might be differences depending on Mac version which
is why i first ask here instead of just copying the content of adams
mail into a pull request on the website repo.

On 24/04/2020 17:31, Adam Wolf wrote:

Hi folks,

Thanks for bringing this to my attention, Rene.

I have attached two images, one showing what "normal" macOS
installation looks like, and what ours looks like.

Our situation is not very far from normal and I would hesitate to call
it "manual" copying.  I do not know what they're talking about, but it
is not correct that you need to use a terminal or something to run
commands to install KiCad on macOS.

When we surveyed users ~5 years ago when I revamped the macOS
packaging, users were overwhelmingly in favor of this method vs a pkg.
Pkgs have a bad reputation for doing bad stuff to your system--like
Zoom just did.

There is also a README right when you open the DMG that explains step
by step what to do:

"""
To install KiCad, click and drag the two directory icons to the
targets pointed at by the arrows.

After dropping kicad onto Application Support, you may be asked to
authenticate with an administrator username and password.  This
installs the support files for KiCad for all users on the system.

KiCad is now installed!  Inside of /Applications will be a directory
called KiCad, and inside of that are all the programs in KiCad.  The
project manager is the one labeled kicad, and is probably where you
want to start.

When you open the KiCad apps the first time, you must right-click on
them and select Open.  You only need to do this once.  You must open
KiCad first before opening the standalone apps, or else the standalone
apps won't be able to open up due to macOS quarantining.
"""

If someone wants to write a homebrew cask for using the mac DMG, I
suspect it would only be an hour or so total, and then users could
install with a single command in just a few minutes (however long it
takes to download the DMG).  Previously, another developer made a
homebrew recipe but it did not have a bottle, so it took hours to
install on a user's computers.  This was before homebrew casks which
should solve this problem.

On Fri, Apr 24, 2020 at 9:35 AM Jon Evans  wrote:

I believe these users are talking about the normal MacOS method of installing 
software,
which does typically involve copying files.

Normally MacOS software is packaged as a disk image that is mounted when you 
double click it.

The mounted image then normally contains the software to be installed, and 
shortcuts
that are used as drop targets for a "drag and drop" copy.

Most software only has one "file" (the .app file, which is actually a directory)
That file is copied to the Applications folder on the user's system.

KiCad's installation also involves copying a second folder to a privileged 
location (Application Support),
so the user will be prompted for authentication when they do this step.

This part of the approach is not very common for commercial MacOS software.
Software that must install to privileged locations typically ships as a binary 
installer with a wizard,
more like what you would typically see on a Windows machine.

I am not familiar enough with the MacOS packaging to know if there is any 
potential for KiCad
to have a single app file that just gets copied to Applications in the future.

If we want to do fancy things such as write-protecting certain parts,
probably the best bet would be to build a MacOS installer wizard (a PKG file).
But, I don't know the details there either or if there are reasons we cannot / 
should not.

-Jon

On Fri, Apr 24, 2020 at 10:22 AM Rene Pöschl  wrote:

Hi all but especially adam,


lately there where

Re: [Kicad-developers] Is it really the case that installing KiCad on a Mac requires manually copying files around?

2020-04-25 Thread Rene Pöschl


Hi again,

might it be a good idea to add the content of the Readme to the download 
page? That way it would bring the Mac download page to the standard of 
the ubuntu one. (That page also explains the "normal" way to install 
from a third party source.) Even better would be if screenshots are 
included as the process is done in a graphical interface.


My reasoning here would be that having this info clearly visible without 
needing to download anything would help anyone that needs to help others 
install software on any platform. So the forum users, teachers and 
possibly even the IT guys in companies might benefit from such detailed 
explanations.


I would assume there might be differences depending on Mac version which 
is why i first ask here instead of just copying the content of adams 
mail into a pull request on the website repo.


On 24/04/2020 17:31, Adam Wolf wrote:

Hi folks,

Thanks for bringing this to my attention, Rene.

I have attached two images, one showing what "normal" macOS
installation looks like, and what ours looks like.

Our situation is not very far from normal and I would hesitate to call
it "manual" copying.  I do not know what they're talking about, but it
is not correct that you need to use a terminal or something to run
commands to install KiCad on macOS.

When we surveyed users ~5 years ago when I revamped the macOS
packaging, users were overwhelmingly in favor of this method vs a pkg.
Pkgs have a bad reputation for doing bad stuff to your system--like
Zoom just did.

There is also a README right when you open the DMG that explains step
by step what to do:

"""
To install KiCad, click and drag the two directory icons to the
targets pointed at by the arrows.

After dropping kicad onto Application Support, you may be asked to
authenticate with an administrator username and password.  This
installs the support files for KiCad for all users on the system.

KiCad is now installed!  Inside of /Applications will be a directory
called KiCad, and inside of that are all the programs in KiCad.  The
project manager is the one labeled kicad, and is probably where you
want to start.

When you open the KiCad apps the first time, you must right-click on
them and select Open.  You only need to do this once.  You must open
KiCad first before opening the standalone apps, or else the standalone
apps won't be able to open up due to macOS quarantining.
"""

If someone wants to write a homebrew cask for using the mac DMG, I
suspect it would only be an hour or so total, and then users could
install with a single command in just a few minutes (however long it
takes to download the DMG).  Previously, another developer made a
homebrew recipe but it did not have a bottle, so it took hours to
install on a user's computers.  This was before homebrew casks which
should solve this problem.

On Fri, Apr 24, 2020 at 9:35 AM Jon Evans  wrote:

I believe these users are talking about the normal MacOS method of installing 
software,
which does typically involve copying files.

Normally MacOS software is packaged as a disk image that is mounted when you 
double click it.

The mounted image then normally contains the software to be installed, and 
shortcuts
that are used as drop targets for a "drag and drop" copy.

Most software only has one "file" (the .app file, which is actually a directory)
That file is copied to the Applications folder on the user's system.

KiCad's installation also involves copying a second folder to a privileged 
location (Application Support),
so the user will be prompted for authentication when they do this step.

This part of the approach is not very common for commercial MacOS software.
Software that must install to privileged locations typically ships as a binary 
installer with a wizard,
more like what you would typically see on a Windows machine.

I am not familiar enough with the MacOS packaging to know if there is any 
potential for KiCad
to have a single app file that just gets copied to Applications in the future.

If we want to do fancy things such as write-protecting certain parts,
probably the best bet would be to build a MacOS installer wizard (a PKG file).
But, I don't know the details there either or if there are reasons we cannot / 
should not.

-Jon

On Fri, Apr 24, 2020 at 10:22 AM Rene Pöschl  wrote:

Hi all but especially adam,


lately there where a few threads on the forum where installation on Mac
came up. The users reported that they installed KiCad by manually
copying files around which sounded wrong to me. But as a lot of users
seem to be under the impression that this is indeed the right way i am
now starting to believe them.

If these users are really correct then maybe this should be documented
very clearly on our download page. Or if there is any option to automate
this process (reducing human error) then maybe this would be the better
way to go long term but unti

[Kicad-developers] Is it really the case that installing KiCad on a Mac requires manually copying files around?

2020-04-24 Thread Rene Pöschl


Hi all but especially adam,


lately there where a few threads on the forum where installation on Mac 
came up. The users reported that they installed KiCad by manually 
copying files around which sounded wrong to me. But as a lot of users 
seem to be under the impression that this is indeed the right way i am 
now starting to believe them.


If these users are really correct then maybe this should be documented 
very clearly on our download page. Or if there is any option to automate 
this process (reducing human error) then maybe this would be the better 
way to go long term but until then it should still be documented what 
needs to be copied.


One problem i see is if users can copy KiCad files then the libs might 
not be write protected which would be a problem as KiCad relies on the 
operating system write protection to avoid users modifying the shipped 
libraries.



___
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] auto conversion of sch file not working

2020-01-21 Thread Rene Pöschl


Hi,

I made a tutorial quite some time ago explaining step by step how to 
prepare your project for remapping and how you can fix any errors that 
might ocour. See 
https://forum.kicad.info/t/converting-kicad-version-4-projects-to-version-5-remap-a-project/13767


I hope this is of help to you or anybody. If there is something unclear 
or missing in the tutorial then drop me a short comment over on the 
forum. (Best make it a public topic such that others can chime in)


lg Rene

On 20/01/2020 17:24, Dick Hollenbeck wrote:

I want to use standalone EESCHEMA (standalone =: run from command line not 
project
manager) to load an old schematic.

In the project *.pro file corresponding to the old schematic I see this line:

LibDir=/i/pcbs/kicad_parts;/usr/local/share/kicad/library

In /i/pcbs/kicad_parts is a library that I made called mylib:

/i/pcbs/kicad_parts$ ll mylib*
-rw-rw 1 dick develop 286715 Apr 16  2018 mylib.bak
-rw-rw 1 dick develop785 Sep 27 16:12 mylib.bck
-rw-rw 1 dick develop785 Sep 27 16:12 mylib.dcm
-rw-rw 1 dick develop 300397 Sep 27 16:12 mylib.lib


$ eeschema old-board.sch

leads to a well-known dialog :

Remap Symbols

Whether I choose to remap or not, I don't see the *ANY* properly rendered parts 
in the
subsequently drawn schematic.  Regardless of which library they may be in.

(I thought the *.pro file's LibDir was supposed to establish a "search path" 
for the old
libraries?)


At this point, I don't now how to load an old schematic using this version:


Application: Eeschema
Version: (5.99.0-635-ga5c7d452c), debug build
Libraries:
 wxWidgets 3.0.4
 libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 
(+libidn2/2.0.4)
nghttp2/1.30.0 librtmp/2.3
Platform: Linux 4.15.0-74-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
 Build date: Jan  4 2020 19:45:12
 wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
 Boost: 1.65.1
 Curl: 7.58.0
 Compiler: GCC 7.4.0 with C++ ABI 1011

Build settings:
 KICAD_SCRIPTING=OFF
 KICAD_SCRIPTING_MODULES=OFF
 KICAD_SCRIPTING_PYTHON3=OFF
 KICAD_SCRIPTING_WXPYTHON=OFF
 KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
 KICAD_SCRIPTING_ACTION_MENU=OFF
 BUILD_GITHUB_PLUGIN=ON
 KICAD_USE_OCE=OFF
 KICAD_USE_OCC=OFF
 KICAD_SPICE=OFF
 KICAD_STDLIB_DEBUG=OFF
 KICAD_STDLIB_LIGHT_DEBUG=OFF
 KICAD_SANITIZE=OFF

___
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] GitLab migration

2020-01-04 Thread Rene Pöschl

What gave you the impression we were keen on moving shop? Github does 
everything we need it to do (unlike launchpad). My guess is that you 
chose gitlab over github because it can be installed on your own servers 
so is more future proof. (Nobody really explained why gitlab was chosen 
so i could be wrong.)


Also see https://gitlab.com/kicad/kicad_migration/issues/20

TlDr: Move will happen after the v6 file format is useable enough for us 
to close down the symbol side for contributions and convert. This will 
hide the negative effects of moving shop at least for half the open pull 
requests. Unless somebody gets a full syncroniszation of pull request going.



Plus lack of manpower. If somebody other than be gets our travis scripts 
to run then that would already be a massive help. (The move will still 
happen after the v6 format change unless we get a massive boost in 
manpower that allows us to handle two platforms during the transition.)



On 03/01/2020 23:31, Nick Østergaard wrote:

What is the blocker for the libs to move to gitlab.
I was under the impression that the librarians where the people most 
keen on moving to gitlab.


On Wed, 27 Nov 2019 at 21:39, Seth Hillbrand <mailto:s...@kipro-pcb.com>> wrote:


On 11/27/19 11:42 AM, Rene Pöschl wrote:

On 26/11/2019 21:54, Seth Hillbrand wrote:

On 2019-11-26 12:41, Jeff Young wrote:

OK, I’ve enabled 2FA.  Do I need to do something to get added
back to
the project?  (When I go to members, all I see are the bot,
Seth and
Wayne.)

Cheers,
Jeff.

Hi Jeff-

Wayne and the bot have permissions for the entire project.  I'm
there
while sorting out the transition work.  Coding permissions are
specific
to https://gitlab.com/kicad/code/ .  Library permissions are
specific to
https://gitlab.com/kicad/libraries/ , etc.

If you'd like push permissions in libraries, you'll want to
check with
Rene.  I think Nick or Marek will be managing the website section
(someone fill me in).  I'll also need to know who to assign to
managing
the documentation section (Nick also?).  Once I get the packaging
section set up, we'll have folks in charge of their relative
builds that
we can run through the GitLab CI runner interface.

-Seth



Hi,

well it seems i do not have access to the group either.


Hi Rene-

I've added you to the top-level group.  There is a sub-group
called librarians where everyone goes but group permissions can
only be assigned to repositories and not other groups (missed that
part).

Let me know if anything else looks amiss.

I'm going to re-sync the repositories this weekend to see if we
pick up any additional folks who are creating GitLab accounts.

-Seth


-- 
KiCad Services Corporation KiCad Services Corporation Logo

Seth Hillbrand
*Lead Developer*
+1-530-302-5483‬ 
Davis, CA
www.kipro-pcb.com <https://www.kipro-pcb.com/> i...@kipro-pcb.com
<mailto:i...@kipro-pcb.com>
https://twitter.com/KiProEDA <https://twitter.com/KiProEDA>
https://www.linkedin.com/company/kicad
<https://www.linkedin.com/company/kicad>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net
<mailto: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] GitLab migration

2019-11-27 Thread Rene Pöschl


On 26/11/2019 21:54, Seth Hillbrand wrote:

On 2019-11-26 12:41, Jeff Young wrote:

OK, I’ve enabled 2FA.  Do I need to do something to get added back to
the project?  (When I go to members, all I see are the bot, Seth and
Wayne.)

Cheers,
Jeff.

Hi Jeff-

Wayne and the bot have permissions for the entire project.  I'm there
while sorting out the transition work.  Coding permissions are specific
to https://gitlab.com/kicad/code/ .  Library permissions are specific to
https://gitlab.com/kicad/libraries/ , etc.

If you'd like push permissions in libraries, you'll want to check with
Rene.  I think Nick or Marek will be managing the website section
(someone fill me in).  I'll also need to know who to assign to managing
the documentation section (Nick also?).  Once I get the packaging
section set up, we'll have folks in charge of their relative builds that
we can run through the GitLab CI runner interface.

-Seth



Hi,

well it seems i do not have access to the group either.


As a sidenote, i am unable to use 2FA with my current phone (too old).

So i hope this is not a requirement for continuing to work for the kicad 
team.



___
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] What does "when in doubt do it opposite than certain other pcb tool" stand for?

2019-11-22 Thread Rene Pöschl


Hi guys,


the roadmap has the following section:

> Study ergonomics of various commercial/proprietary PCB 
 applications (when 
in doubt about any particular UI solution, check how it has been done in 
a certain proprietary app that is very popular among OSHW folks and do 
exactly opposite).



I would assume this is referencing version 6 of eagle. The current 
versions of eagle are actually something that can (in some aspects) be 
used as a good example. I would therefore assume that this sentence is 
simply out of date and could be removed or at least reworded.



___
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.5 release tag

2019-11-17 Thread Rene Pöschl


Libraries have been tagged.

On 14/11/2019 18:36, Wayne Stambaugh wrote:

The 5.1 branch has been tagged for 5.1.5 and the source archive has be
uploaded to launchpad.  Please tag the library, doc, and translation
repos so we can fire up those packages builders.

Thanks,

Wayne

On 11/13/19 3:55 PM, Wayne Stambaugh wrote:

It's been a couple of weeks since 5.1.5-rc1 was tagged and everything
seems to have stabilized nicely.  I'm going to tag 5.1.5 tomorrow around
noon EST unless something comes up.  I'm assuming the libraries,
documentation, and translations are ready to go and that it shouldn't
take too long to get most of the installer packages build and uploaded
to the KiCad website.  I would like to make the release announcement on
Wednesday, November 27th.  It would be something to be thankful for
leading into the US Thanksgiving Holiday.  If there are any issues with
this date, please let me know.  Thank you everyone for your continued
support of the KiCad project.

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] Website question

2019-11-05 Thread Rene Pöschl


Hi,

something similar is discussed in this github issue.
https://github.com/KiCad/kicad-website/issues/447

On 05/11/2019 18:41, Wayne Stambaugh wrote:

Is there any technical reason why our website is not using secure
hosting via https://?  I noticed that our download site uses https://.
I'm guessing at some point we are going to have to change this.  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] GitLab migration

2019-10-09 Thread Rene Pöschl


Hi, this is welcome news.

I would suggest we do the library transfer as soon as the new
file format is somewhat stable as we will need to make a hard
cut for transfering the symbol libs to the new file format
anyway.
(We would avoid needing to do doulbe work this way.)

Would then of course mean that the v5 development will
stay at github and only v6 will be found at gitlab.
(The v5 development will be halted as soon as we start with
v6 as we simply do not have the resources to handle two
releases. And i assume the move will take us quite a while
so we need to start early with it anyways.)

On 09/10/2019 18:36, Wayne Stambaugh wrote:

The lead development team has been discussing migrating the KiCad
project to GitLab[1].  Given the issues with Launchpad, I think this is
a good move.  I've applied for an open source GitLab license.  Assuming
we get accepted, I would like to start this process after the 5.1.5
release.  Here is a short list of action items that need to be done for
the source repo transition:

* Freeze the Launchpad source repo.
* Push the frozen repo to GitLab.
* Disable the Launcpad bug tracker.
* Add a note and link to the Launcpad project page that the project is
now hosted on GitLab.
* Create blog announcement once the transition is complete.

There are a few unknowns:

Would it be possible to migrate open bug reports to GitLab?  I suspect
we could come up with a script like we did when we migrated from
SourceForge.

What to do about the mailing list?  GitLab doesn't support mailing lists
yet so I'm thinking we leave the mailing list on Launchpad for the short
term.  We can always migrate the mailing list at a later date or use
some other communication tool such as discourse.

Further down the road, I would like to see all of the KiCad source repos
including the library, documentation, website, and translation repos
migrated to GitLab as well.  It would make my life a lot easier from a
project management perspective if they were all in the same place.  I
expect there to be some resistance to using a source code version tool
but I'm hoping folks will see this as a beneficial move.  I'm not
terribly familiar with GitLab but I suspect it's not that much different
than GitHub as a hosting platform so I don't expect there to be a very
steep learning curve.  If you have any concerns, now is the time to
speak up or forever hold your peace.

Cheers,

Wayne

[1]: https://gitlab.com/

___
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.3 release

2019-08-04 Thread Rene Pöschl


On 04/08/2019 19:03, Wayne Stambaugh wrote:

Please tag the doc, translation,
and library repos to 5.1.4 using the same commit as 5.1.3.  I'll update
the release announcement and there will be no official 5.1.3 release.
Thank you everyone for your cooperation and patience.

Cheers,

Wayne



The library is tagged


___
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.3 tagged

2019-07-23 Thread Rene Pöschl


Libraries are tagged.

On 23/07/19 14:32, Wayne Stambaugh wrote:

I just tagged 5.1.3 and uploaded the source archive to launchpad.
Please tag the doc, translation, and library repos so we can get the
package builders going.  Thank you everyone for your continued support
of the KiCad project.

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] fp-info-cache question

2019-07-23 Thread Rene Pöschl

Is there a reason why this file is even part of the project directory? I 
kind of assume it holds the info of all footprints. (If i am misinformed 
about that then ignore my inquiry.) Meaning for most users will most 
likely be mostly system libs that can easily change while one does not 
work on the project for a longer time. Might it be better to have a 
global cache for the global libs and a local one for the local ones?


On 23/07/19 01:03, Seth Hillbrand wrote:

Hi Folks,

Odd question here but why do we have fp-info-cache?  Was there a bug
report for these or just speed improvements?

On my system, it is the difference between 1 second vs. 3 seconds during
the first footprint list load (full standard + personal libraries).
Does it make a bigger difference on other systems?  I assume so but I
was wondering if we have some data here?

I'd like to make storing it an option.  I've been working on templates
recently and keep needing to delete the extra files from the directory
(caches should not be valid for templates).

Thanks-
Seth

___
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] Ratsnest options

2019-06-13 Thread Rene Pöschl


On 13/06/2019 16:26, Jeff Young wrote:

So how about removing in/mm and polar/cartesian from Preferences (and leaving 
them and ratsnest on/off in the options toolbar), rather than moving ratsnest 
on/off to Preferences?

Cheers,
Jeff.



If one sees the coordinate settings as the default starting option then 
it should stay. If it is only for the current project then you are right 
it should probably not be in the preferences. (As a metric eagle user i 
can tell you there is nothing more annoying than having no easy way to 
set the default unit system.)



___
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] Atomic Libraries Proposal

2019-05-24 Thread Rene Pöschl


Hi,

the symbols mentioned by simon are the generic ones. Sadly not all 
manufacturers use the same mapping not even for the same package. 
(especially not for to-92 and sot-23)


Right now the best option is to have one symbol per possible arrangement 
in the generic lib. We also have a full transistor lib that of course 
does not contain every possible part. The intention is that the user 
then copies the correct generic symbol, assign the footprint and saves 
it under the part name (plus add BOM info to their liking.)


This would not go away with the proposed solution. One would need these 
6 symbols and select the correct one for the atomic part. If the pin 
mapping is however moved to the atomic definition then it would be 
possible to have one symbol (that only has pin names instead of numbers) 
and connect them to the pads as needed. (Similar to how eagle does it.)


The problem with adding this would be that it is a bit counter to how 
kicad works now. If we add it in addition to the definition in the 
symbol then it will be quite confusing. (This is my general fear about 
this suggestion. It will add another option on top of the already 
possible ones. One of the reason why i would suggest to move some of the 
responsibility currently in the symbol into it. Or think about how the 
same result can be achieved within the symbol file format. The 
inheritance stuff seems to be a perfect fit.)


On 25/05/19 04:57, Andy Peters wrote:



On May 24, 2019, at 2:54 AM, Simon Richter  wrote:

Hi,
   transistor symbols (BCE, BEC, CBE, CEB, EBC, ECB) into one and allow
   switching mappings during PCB design?

Why is that even necessary? The footprints (TO-92, SOT-23, etc etc) all have 
standard pin numbers. The symbol for the transistor should map the E, C and B 
to the proper pin number 1, 2, 3. If you place transistor MBTA on your 
schematic, the correct footprint and correct pin mapping should automatically 
follow.


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




___
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] Atomic Libraries Proposal

2019-05-24 Thread Rene Pöschl

Hi,

just a possibly stupid idea. Maybe it could be an option to move part of
the ideas of the new library system into your third entity. Particularly
the inheritance stuff might not really be required if your atomic entity
is used.

I seem to remember there was talk that this would be quite hard to
implement anyways. So if that would make implementation easier then this
might be a good way to go.
(But maybe i simply missed the point of why inheritance or your system
is useful as i kind of thought the inheritance stuff was in there to
fulfill exactly what your third file would now do.)

---

You state in the format definition that you do not intent to change
anything regarding 3d models. Maybe your file could really go a bit
further than you first envisioned and could take care of all possible
connections in one system. So lets say it includes not only symbol
footprint and bom information but also an optional overwrite for the 3d
model as well as a way to define spice models. And possibly also a way
to define the symbol pin to footprint and spice model pin mappings. (I
would assume that this might be a bit too far so feel free to reject
this outright as i must admit i have not yet fully convinced even myself
that this would be a good idea. This could even be something that is
moved to a second iteration.)

On 24/05/19 18:25, Seth Hillbrand wrote:

Hi Rene-

These are good points, thanks for helping me clean this proposal.

One design goal of this system was to make it transparent for both
librarians and users who do not want to use it. To that end, the
existing design of both the current and new formats is not affected.
Users who do not enable this option would see no change in their
workflow.

This does mean that there are potentially two different places where the
same key can be defined. As envisioned, no fields from the symbol
library will be used when an atomic part is placed on the schematic.
All properties from the symbol library are cleared and the atomic
library fields are populated.

I will clarify this in the usage section.

Best-
Seth

Am 2019-05-24 09:42, schrieb Rene Pöschl:

Hi again,

A few clarification questions:

Would your proposed solution replace the way of defining footprints in
the symbol file format of the future or would this be in parallel to
it. (I lean towards the fact that it should replace it as i fear we
otherwise end up with something similar to what we had with the
datasheet being stored in either dcm or lib files. But i can also
imagine that this would not be very well liked by the community)
Similarly with footprint filters. In the official lib we use it for
fully specified symbols to allow adding manufacturing specific
variations. (Inclusion of thermal vias, hand soldering alternative,
...) How would that come into play?

Your system would take care of adding bom info via properties. Right
now such fields can already be added to a symbol directly or via
eeschema. Again something where we might want to either limit it to
one place in the library or have clear rules which place takes
precedence. (An interesting case is if there are different fields in
the symbol compared to the new part specifier. Should the result be a
union of both sets of properties or should only the part properties be
used?)

On 23/05/19 21:41, Seth Hillbrand wrote:

Hi All-

After some discussion, we are trying to decide whether implementing a
basic atomic library support would be useful during v6 or would cause
more headache than worth while trying to work with the solution.

Background: "Atomic" libraries are ones that have unique names for
symbol+footprint+properties combinations. These are also referred to
as
"Fully-specified" libraries or sometimes "house libraries".

The paradigm is outlined in a google document[1]. This is meant to
provide an explicit option for users to create/utilize atomic library
components without affecting the symbol or footprint formats. It is
also meant to be zero impact to the current, official KiCad libraries.

The major limitations of the specification are:
- No editing of the atomic library file within KiCad
- The atomic library does not contain symbol or footprint data

Folks are welcomed to weigh in on whether this approach presents a
viable work flow for them. I'm happy to take suggestions on the
approach, I may ask you offline for some additional details of how you
use KiCad and/or other tools with libraries at the moment.

Best-
Seth

[1]
https://docs.google.com/document/d/1FNPmUAkNVt7r9oz32OznDrqL8RHdGHpO-eiBVEzHCOs/edit?usp=sharing

___
Mailing list: https://launchpad.net/~kicad-developers

Re: [Kicad-developers] Atomic Libraries Proposal

2019-05-24 Thread Rene Pöschl

Hi again,

A few clarification questions:

Would your proposed solution replace the way of defining footprints in
the symbol file format of the future or would this be in parallel to it.
(I lean towards the fact that it should replace it as i fear we
otherwise end up with something similar to what we had with the
datasheet being stored in either dcm or lib files. But i can also
imagine that this would not be very well liked by the community)
Similarly with footprint filters. In the official lib we use it for
fully specified symbols to allow adding manufacturing specific
variations. (Inclusion of thermal vias, hand soldering alternative, ...)
How would that come into play?

Your system would take care of adding bom info via properties. Right now
such fields can already be added to a symbol directly or via eeschema.
Again something where we might want to either limit it to one place in
the library or have clear rules which place takes precedence. (An
interesting case is if there are different fields in the symbol compared
to the new part specifier. Should the result be a union of both sets of
properties or should only the part properties be used?)

On 23/05/19 21:41, Seth Hillbrand wrote:

Hi All-

Background: "Atomic" libraries are ones that have unique names for
symbol+footprint+properties combinations. These are also referred to as
"Fully-specified" libraries or sometimes "house libraries".

The major limitations of the specification are:
- No editing of the atomic library file within KiCad
- The atomic library does not contain symbol or footprint data

Best-
Seth

[1]
https://docs.google.com/document/d/1FNPmUAkNVt7r9oz32OznDrqL8RHdGHpO-eiBVEzHCOs/edit?usp=sharing

Re: [Kicad-developers] Atomic Libraries Proposal

2019-05-23 Thread Rene Pöschl

I still do not see that to be honest. Why would introducing a third 
element make anything saver? (Why would a verified triplet be superior 
to a verified fully specified symbol?)

Don't get me wrong the current (version 5) system has its weaknesses but 
i simply do not see how the proposed solution would be superior to what 
is already included in the new symbol file format (of version 6). Other 
than maybe making it more familiar to people coming from tools that went 
a similar way. But to users really care about the files or could this 
familiarity be better created with an improved GUI? I personally am kind 
of against doing something just because it is familiar. There should be 
a really good technical reason for it.

By the way i really do not understand why even the current v5 system 
would not allow for your use case. Make a library of fully specified and 
verified symbols. The only thing that i see it improving is that one can 
assign differing bom info or footprint connections to similar parts 
without duplicating symbols. But i kind of assumed the inheritance stuff 
of the new file format will do the same.

On 23/05/19 23:18, Drew Van Zandt wrote:
The benefit is that once you have verified a triplet works on a board, 
you can use it again without fear of error.  The current system is not 
ideal for re-use/production engineering.

On Thu, May 23, 2019, 4:06 PM Rene Pöschl <mailto:poesc...@gmail.com>> wrote:

Hi Seth

What is the benefit compared to having lets say a more powerful
aliasing
system that allows bom specific things to be more easily included
in the
kicad internal library without introducing something different?
(especially as i assume the new file format will provide a more
powerful
option in this regard anyways.)

On 23/05/19 21:41, Seth Hillbrand wrote:
> Hi All-
>
> After some discussion, we are trying to decide whether
implementing a
> basic atomic library support would be useful during v6 or would
cause
> more headache than worth while trying to work with the solution.
>
> Background: "Atomic" libraries are ones that have unique names for
> symbol+footprint+properties combinations.  These are also
referred to as
> "Fully-specified" libraries or sometimes "house libraries".
>
> The paradigm is outlined in a google document[1].  This is meant to
> provide an explicit option for users to create/utilize atomic
library
> components without affecting the symbol or footprint formats.  It is
> also meant to be zero impact to the current, official KiCad
libraries.
>
> The major limitations of the specification are:
> - No editing of the atomic library file within KiCad
> - The atomic library does not contain symbol or footprint data
>
> Folks are welcomed to weigh in on whether this approach presents a
> viable work flow for them.  I'm happy to take suggestions on the
> approach, I may ask you offline for some additional details of
how you
> use KiCad and/or other tools with libraries at the moment.
>
> Best-
> Seth
>
>
> [1]
>

https://docs.google.com/document/d/1FNPmUAkNVt7r9oz32OznDrqL8RHdGHpO-eiBVEzHCOs/edit?usp=sharing
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
> Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-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] Atomic Libraries Proposal

2019-05-23 Thread Rene Pöschl


Hi Seth

What is the benefit compared to having lets say a more powerful aliasing
system that allows bom specific things to be more easily included in the
kicad internal library without introducing something different?
(especially as i assume the new file format will provide a more powerful
option in this regard anyways.)

On 23/05/19 21:41, Seth Hillbrand wrote:

Hi All-

After some discussion, we are trying to decide whether implementing a
basic atomic library support would be useful during v6 or would cause
more headache than worth while trying to work with the solution.

Background: "Atomic" libraries are ones that have unique names for
symbol+footprint+properties combinations.  These are also referred to as
"Fully-specified" libraries or sometimes "house libraries".

The paradigm is outlined in a google document[1].  This is meant to
provide an explicit option for users to create/utilize atomic library
components without affecting the symbol or footprint formats.  It is
also meant to be zero impact to the current, official KiCad libraries.

The major limitations of the specification are:
- No editing of the atomic library file within KiCad
- The atomic library does not contain symbol or footprint data

Folks are welcomed to weigh in on whether this approach presents a
viable work flow for them.  I'm happy to take suggestions on the
approach, I may ask you offline for some additional details of how you
use KiCad and/or other tools with libraries at the moment.

Best-
Seth


[1]
https://docs.google.com/document/d/1FNPmUAkNVt7r9oz32OznDrqL8RHdGHpO-eiBVEzHCOs/edit?usp=sharing

___
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] kicad_pcb, kicad_mod format change for daily build?

2019-05-05 Thread Rene Pöschl

Even if the current kicad versions can read it it still makes problems
with version control.

For that reason i would request a file format verion update on any
change to the file generation at least for library assets as it has
direct impact on the library maintainance!
It makes it near to impossible to easily identify changes made by the
contributor compared to changes made by the new file format algorithm.

The reason for my report is:
https://github.com/KiCad/kicad-footprints/pull/815/commits/624037c1ca388506fca4d1d5b6b42e9f68157470
Now tell me which changes where made by the user on purpose and which
where introduced by the algorithm change.

I would simply suggest the following rule to be added to the release
policy: Have a set of reference files. Save them without doing actual
changes. If git detects a change in the resulting files than a file
format change did happen and needs to be clearly indicated.

On 21/04/19 18:46, Jeff Young wrote:

Hi Kevin,

KiCad will read them in either way (quoted or un-quoted).

KiCad has always written them out with quotes if they had spaces in them (so
other tools have always needed to handle quotes).

We’re just being more consistent now as there’s no justification for “saving a
few characters” in this day and age (and going forward it will make things
easier).

Cheers,
Jeff.

On 21 Apr 2019, at 17:25, Kevin Cozens wrote:

On 15 Apr 2019, at 13:56, easyw wrote:
recently I have noticed that both kicad_pcb and kicad_mod seems to have changed
their format.
It have been introduced double quotes for layers pads etc.

[snip]

(layers
(0 F.Cu signal)
(31 B.Cu signal)

(layers
(0 "F.Cu" signal)
(31 "B.Cu" signal)

When I was asking about an updated file format document I was told "There have been
virtually no changes to the file format other than how symbol library links are defined
for a very long time."

I consider it a file format change if quotes weren't needed before but they are
now. It is the type of information I need to be sure I'm generating files in
the proper format to avoid possibly having to go through the migration process.

There may be other change(s) I may need to know about because the version
number in the files has been bumped since the current file format doc was
written. The files I'm generating are a version behind and have to go through a
migration process when I try and open them. I don't fully trust the migration
process.

I hope someone can update the docs after KiCon, or perhaps someone can point me
to which file(s) generate the schematic files used by eeschema.

--
Cheers!

Kevin.

Re: [Kicad-developers] In response to KiCon panel question "atomic" vs "CvPcb" answer

2019-05-03 Thread Rene Pöschl


On 03/05/19 23:14, Wayne Stambaugh wrote:


On 5/3/2019 4:59 PM, Rene Pöschl wrote:

On 03/05/19 22:48, Eeli Kaikkonen wrote:

I was just trying to find this discussion in the video, can you give
the time?

The link to the video is here, for the future generations of internet
search engine users who find this thread:
https://www.youtube.com/watch?v=NRwTyBX2BFk



Around 4 minutes in.


And i think a single remark made towards the end of that answer spawned
this hellfire:
https://forum.kicad.info/t/more-fully-specified-symbol-library-discussion/16701
(Fair warning the poster took a small remark way too seriously and
assumed that the fully specified symbol workflow might go away. Which i
do not belive was the intended message at all. The reason i even made
this post was that i knew that thread quite well and immediately
realized where the user got the ideas from just by hearing that answer.
I just wanted to give you guys my interpretation of the 2 or 3 possible
workflows as a possible reference and in part to ensure users that all
workflows are seen as equally viable depending on exact circumstance.)


Feel free to engage this if you want to but please don't drag me into
it.  Honestly, I really don't care how users define their symbols or
what work flow users prefer.  KiCad places no restrictions on this
regard nor do I plan to change that.  I don't understood what the big
deal is.  Are they upset that we are not providing fully defined
symbols?  That's not even a reasonable request since there is no way to
meet everyone's individual needs but that doesn't mean that they cannot
do this.  I really don't know what else can be said about this issue
that hasn't been said over and over again.

Wayne



I did not intent to drag anybody into anything. (yes i am now aware that 
i kind of did by posting here. Sorry about that. Just wanted to provide 
some information that i think could be useful. And wanted to provide the 
context behind it.)



___
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] In response to KiCon panel question "atomic" vs "CvPcb" answer

2019-05-03 Thread Rene Pöschl


On 03/05/19 22:48, Eeli Kaikkonen wrote:
I was just trying to find this discussion in the video, can you give 
the time?


The link to the video is here, for the future generations of internet 
search engine users who find this thread: 
https://www.youtube.com/watch?v=NRwTyBX2BFk




Around 4 minutes in.


And i think a single remark made towards the end of that answer spawned 
this hellfire: 
https://forum.kicad.info/t/more-fully-specified-symbol-library-discussion/16701 
(Fair warning the poster took a small remark way too seriously and 
assumed that the fully specified symbol workflow might go away. Which i 
do not belive was the intended message at all. The reason i even made 
this post was that i knew that thread quite well and immediately 
realized where the user got the ideas from just by hearing that answer. 
I just wanted to give you guys my interpretation of the 2 or 3 possible 
workflows as a possible reference and in part to ensure users that all 
workflows are seen as equally viable depending on exact circumstance.)



___
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] In response to KiCon panel question "atomic" vs "CvPcb" answer

2019-05-03 Thread Rene Pöschl


Hi,


I hope i do not step out of line but i think there might be small 
misconceptions about the two major library workflows and i just wanted 
to give my insight of it.



Generally speaking there are two time instances as to when a footprint 
is assigned to a symbol. One is at the end of the design process and one 
is already in the library.



---


I do not really like the name "atomic" library to describe the later. 
Atomic to me would imply a much closer coupling between symbol and 
footprint possibly even within the same file. This would of course not 
make much sense for kicad. (I for me define an "atomic pair" as 
something where both the symbol and footprint are highly specialized to 
one part. Some MEMS sensors and RF parts and also modules like an RFID 
or bluetooth all in one system fall under this category.)



---


Everything that has a generic package and can therefore use a generic 
footprint (possibly designed using IPC rules instead of after on 
manufacturers suggestion.) can at most be a "fully specified symbol". 
And the symbol part is very important here. It is only the symbol that 
is specialized to the part. To make a symbol fully specified it must 
have a footprint assigned in the library and be named to represent 
either exactly one part or a very small family of closely related parts. 
(For the official lib we for example do not include separate symbols for 
different temperature ranges.)


If users talk about fully specified they often mean that these symbols 
also include BOM information like ordering information or a house part 
number or similar key for connecting it to their in house material 
management system. This is something the official library team can not 
provide. We can by definition not provide a house part number as it is 
user defined. And we can also not include ordering information as doing 
so would in the first instance mean that we will need to show some bias 
towards a particular distributor which is a bit against the general idea 
of being open and impartial. And in the long run it would also massively 
increase the maintenance effort as order number can easily change over time.



---


I would call the other type of symbol a generic symbol. This is a symbol 
that represents all parts that are pin compatible and provide the same 
function. It has no footprint assigned but can reduce the number of 
suggested footprints via the footprint filters. Such filters of course 
rely on a well thought out footprint naming convention which i hope the 
official lib now has.


Some of these symbols also require deviating from using pin numbers as 
that kind of limits what can be done here. Named pins are a way to make 
this more generic but also depends on footprints being specialized 
enough as to not increase maintenance effort elsewhere. (examples here 
are audio connectors, relays and similar things where a small number of 
symbols can represent a large amount of footprints if the pin naming 
scheme is standardized.)



---


You might have noticed that i strongly believe that neither of these 
workflows is truly superior. I think most of the users and i would 
assume also most of you developers are aware of that. Every workflow has 
its place, its strengths and weaknesses. KiCad is better than other 
tools exactly because it allows for all three workflows (and even some 
things in between) to coexist in the same ecosystem allowing the user to 
use the right workflow for their particular application.





___
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.1 issue

2019-04-22 Thread Rene Pöschl

The library is tagged with 5.1.2 (I also converted the library releases 
named 5.1.1 as pre release on github and added a note that that release 
got retracted.)


On 22/04/19 14:43, Wayne Stambaugh wrote:

I will tag the source repo to 5.1.2 this evening when I get home from
work so please tag the other repos for 5.1.2 at the same commit as
5.1.1.  Hopefully we can get this version released.

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] Best practice for multi-gate symbols ? (74LVC2G14 has hidden pins)

2019-04-22 Thread Rene Pöschl


On 21/04/19 22:58, Henner Zeller wrote:

On Sun, 21 Apr 2019 at 13:28, Nick Østergaard  wrote:

Hello Henner,

I think the Librarians more or less communicate exclusively via github issues. 
So it may be worth to post this as an issue on the kicad-symbols repo over on 
github.

Thanks Nick; looks like this is
https://github.com/KiCad/kicad-symbols/issues/756 and is decided to be
pushed to v6.

-h

___
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



TlDr: The library team decided to move power pins to a separate unit for 
all such components.


We planned to get everything done in time for v5 but where lacking 
manpower to fix every lib (I think only the lib listed in this report 
and the ieee style libs are still using hidden power pins)



---


Yes it meant that these symbols no longer support the "interchangable 
units" feature as well as limiting spice support for these.


Another issue is that right now ERC does not check for not placed units 
as there is no "this unit is mandatory" flag in the current file format 
(i requested it for the new one but think never got an answer on that)



The alternative would have been to use visible power pins copied over 
all units. This however had a lot of issues during v4 (No ERC check for 
connecting such a pin multiple times) and still had issues with the 
nightlies at the time we made that decision (I think some of them are 
still in.) Examples that comes to mind immediately (without needing to 
search the bugtracker): unconnected copies are reported as unconnected.


The main reason however was that we feel it is very confusing to use a 
symbol that has the same pin multiple times. For everyone involved in 
reading a schematic that uses such a symbol (Give such a symbol to your 
boss without explaining this specialty first. See how long it takes them 
to ask why ICx is not connected to supply.)  The increased clarity and 
flexibility of using a separate power unit simply was worth the 
downsides we knew at that time. (We did not know about the simulation 
issue when we made our decission. I feew we would have decided the same 
way if we would as i feel simulation is an extensions that is not 
allowed to limit the core function of kicad which is making pcbs. We 
have specialized symbols for simulation added in the meantime to support 
this usecase as well. Interchangeable units are not that much of a help 
anyways and manual unit switch is possible even with the current symbols.)



___
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.1 issue

2019-04-21 Thread Rene Pöschl

Is this the official decision because i can tag the libraries with 5.1.2 
at any time. (On the same commit as 5.1.1.)


On 22/04/19 00:03, Nick Østergaard wrote:
Yes, just retag the 5.1.1 tags as 5.1.2 as well. We have done that 
before and is probably what will have the least workload. :)


On Sun, 21 Apr 2019 at 23:44, Steven A. Falco > wrote:


On 4/21/19 5:18 PM, Wayne Stambaugh wrote:
> It's looks like 5.1.1 has a serious issue which was fixed and
will be
> released in 5.1.2.  Since folks have already started downloading
5.1.1,
> I don't think changing the 5.1.1 tag is a good idea.  How much
trouble
> would it be to spin 5.1.2 and skip formally releasing 5.1.1? 
I'm fine
> if we use the 5.1.1 libraries, documentation, and translations as
> nothing has change since 5.1.1 that would effect anything.  I figure
> this will give Adam some more time to get the macos release out.  I
> apologize in advance for dropping the ball on this.

My preference would be to tag all seven repositories with 5.1.2,
even if the 5.1.2 and 5.1.1 tags are on the same commit.  That
way, the intent is very clear in the history of each repo.

Changing / reusing a tag once it has been pushed is never a good
idea, IMO.

        Steve


___
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.1 release reminder.

2019-04-14 Thread Rene Pöschl


Hi all,

I just tagged the library.

Some small design breaking changes are included in the symbol libs. 
(There was a minor miscommunication as some maintainers thought there 
will not be another version 5 release. I needed to revert one change 
because of that the other 3 where ok in my mind.)


Everything is detailed in the github issue 
https://github.com/KiCad/kicad-symbols/issues/1724


On 12/04/19 22:23, Wayne Stambaugh wrote:

Just a reminder.  I will be tagging 5.1.1 Sunday afternoon so any last
minute bug fixes should probably be in by tomorrow so I can do a build
check and some quick testing to make sure nothing went sideways.  Also,
please no translatable string changes until we start 5.1.2.  Hopefully
the library, doc, and translation repos will get tagged on Sunday so we
can get the back builders fired up.  Thanks again everyone for your
tireless efforts.

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] 5.1.1

2019-04-08 Thread Rene Pöschl


On 07/04/19 18:59, Wayne Stambaugh wrote:

Do we need any more than
three weeks to get the translations updated, the libraries tag, and
packages built?  Please let me know if this is an issue.



I hope i will be able to take a look at the library this weekend (The 
last few weeks where a bit busy for me.) I suspect i will therefore 
either tag it this weekend or know what needs to be done by then. (We 
typically do not have any deal breakers. Worst case would be too many 
design breaking changes on the symbol lib prompting me to revert some 
stuff.)



___
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] Option to not render 3D models for footprints

2019-03-25 Thread Rene Pöschl

Maybe a better option would be to have footprint variations similar to 
aliases.
Something with a new name, new 3d model path and new description but the 
same land pattern.

This could be useful not only for having specialized 3d models but also 
when the manufacturer uses a very strange part naming scheme where it 
gets hard to define a footprint name well such that it tells the user 
which parts it exactly fits. (Example is if the part number code has for 
example a place that is either a,b.e for fp1 but c,d for fp2. right now 
we would need at least 3 possibly 5 footprints to properly do this.)

The individual visibility stuff could also be useful for usecases that 
do not fit the one handled by my suggestion. One example would be a 
battery holder where you have the battery as a separate model. You might 
be interested in seeiing how it looks without a battery. Maybe even have 
a model where the battery is in the process of being inserted to see the 
space required for that task.

Or a shield that covers some other parts. Might be useful to just hide 
this alone.

On 25/03/19 19:46, Jeff Young wrote:

Multiple models is an existing feature (for building up parts).  There’s just 
no individual control over visibility.

Cheers,
Jeff.

On 25 Mar 2019, at 18:38, Wayne Stambaugh  wrote:

Sorry it took so long to get back to this but I've been really busy.
The the capacitor example makes sense although I'm not sure this is a
significant enough feature to warrant a file format change.  I'm not
terribly opposed to this idea either.  I do have a few questions.  Can
multiple models be visible at the same time?  If so, have the STEP and
VRML exporters been tested to work under this case?

Cheers,

Wayne

On 3/14/2019 10:26 AM, Jeff Young wrote:

Hi Wayne,

No, it would need to be saved in the file.  Think of it as Units for 3D
models: for instance you might have 30mm, 35mm and 40mm tall capacitors
all assigned to the single 20mm diameter 7.5mm pitch footprint.

Cheers,
Jeff.

On 14 Mar 2019, at 13:38, Wayne Stambaugh mailto:stambau...@gmail.com>> wrote:

Jeff,

I haven't looked at Oliver's patch so I'm flying blind here.  My
question is why does this require a board change.  Is this a state we
really need to save in the board file or could it be some 3D viewer
visibility state option saved in a config file?  I would prefer the
latter if possible.  I guess I don't understand the purpose of this.

Cheers,

Wayne

On 3/14/2019 6:44 AM, Jeff Young wrote:

@Wayne, this builds on top of my m_Preview addition so I’m happy to
review it and merge it after Oliver re-bases.  But where do we stand on
PCBNew file format changes for 6.0?  (There are also some hold-overs I
have from 5.1; namely storing defined diff pair dimensions and the
courtyard DRC settings in the files.

On 14 Mar 2019, at 08:30, Oliver Walters
mailto:oliver.henry.walt...@gmail.com>
> wrote:

This has gone unresolved for a while now - if I put in some effort to
rebase this, is there any likelihood it will be accepted?

This patchset does involve a file format change to the PCB file but it
is backwards compatible and introduces a useful new feature.

On Tue, Oct 30, 2018 at 11:27 PM Oliver Walters
mailto:oliver.henry.walt...@gmail.com>
> wrote:

The attached patchset expands on the "Preview" checkbox in the 3D
model tab in the footprint editor.

This "Preview" option currently only applies to the preview
window. However if the user wishes to disable display of a given
3D model in the PCB renderer they must delete the 3D model from
the footprint entirely.

The new patchset does the following:

1) The state of the m_Preview parameter for each 3D model is
observed in the various 3D renderers and exporters

2) The m_Preview parameter is saved to file (both .kicad_mod and
.kicad_pcb)

With regard to file saving, if the 3D model is "enabled" (default
state) then the file is unchanged making this change largely
backwards compatible. If the 3D model is disabled, then the
keyword "(disabled)" is added to the file.

You can now quickly toggle 3D models on/off on an individual basis
and this is statefully saved between sessions.

Patch-set is rebased and compiled
from b445b0fab28f7dd41273801d06d7705215c57c0f

Regards,

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

Re: [Kicad-developers] Feedback on 5.1

2019-03-12 Thread Rene Pöschl

Some more answers to what andy wrote.
Disclaimer not a dev only the main lib maintainer and very active on the 
user forum.

In general: Make bug reports for feature requests. Your requests will be 
forgotten by being only here on the mailing list. But check first if 
what you request has already been requested. If it has mark the bug as 
affects me as well plus maybe add clarifications in the bug comments if 
you feel your particular usecase is not presented well enough.

Oh and don't take me too seriously i already worked 10 hours today and 
english is not my first language.

---

On 12/03/19 18:21, Ruth Ivimey-Cook wrote:
Common: I am still frustrated that the key combinations for similar 
tasks are not the same. For example, to place a wire in schema, it's 
shift-W while in pcb it's shift-X.

Well in eeschema you place wires. But in pcb_new you place traces using 
the interactive router. (And you can change the assignment. And you do 
not even need the shift key, only w or x work fine.)

> I am still frustrated that some task combinations aren't possible: 
duplicate doesn't work on wires

You can dublicate wires by using group selection. (But there is no 
hotkey for that. So i suggest crtl+c -> crtl+v)

This was always the case. To be honest i see no usecase for duplicating 
single wire segments as i feel it is faster to press w and lay down a 
new wire than to duplicate one.

> duplicate does not work on connectors

What do you mean with connectors in this case? Do you possibly mean the 
junction dot or bus connectors? See my answer regarding wires.

Or do you mean symbols for connectors? In this case i can tell you that 
i do not have a problem duplicating them like any other symbol. (shortcut c)

> I am still frustrated that some task combinations aren't possible: 
drag doesn't work on graphic lines or components, etc.

Footprint drag is not trivial as you would need a kind of powerful semi 
autorouter to get anything sensible out if it. (I am not sure how much 
work it would be to get the interactive router to the point where this 
is possible.) To be honest this is one of the few things that i kind of 
like in eagle.

For symbols drag already works but i would guess you want it to result 
in nicer looking schematics (or was the common title of this section not 
quite correct?)

> I would love to see a setup kicad libraries action (probably not 
limited to an installer) which configures the library settings and 
installs libraries to match.

How should kicad know which libraries to "install"?

In general library assets are included in the project (In the pcb file 
and in the cache library, the later will hopefully also be embedded in 
the future.)

Meaning it is not as bad as you think if the person opening the project 
does not have the same library setup. (Worst thing right now is that the 
rescue dialog opens. Yes this will result in changes to the schematic 
but this will hopefully be a thing of the past with version 6)

> The reason is that my understanding is that because the library files 
are being updated (great) that can make a given project dependent on a 
given issue of library

KiCad v5 no longer automatically updates any library assets. Such an 
action must be triggered by the user. (Yes it was a stupid idea for 
version 4 to use on demand online libraries. We learned from that mistake.)

Also we have a rule that no design breaking changes are allowed (within 
reson) during a minor release series. This means you should not run into 
too much trouble updating the library from v5.0.2 to 5.1.0 for example. 
(Some changes are still necessary as we will discover bugs. And some 
simply get through on accident. We have after all ~100 contributions per 
week to deal with.)

> witness recent change of location of pin headers

Ähm? Do you mean going from v4 to v5? If so then yes the library 
reorganization was part of the release notes. There where no such 
changes during the minor releases!

My suggestion is to have v4 libs locally in a separate location to deal 
with v4 projects. This is possible right now using project local library 
setups. Only trouble are 3d models but if you want them to work then you 
simply need to change the KISYS3DMOD path variable to point to version 4 
models. (And yes i would wish for a better solution here. I think v5.1 
introduced 3d model search paths which should allow for this usecase. 
However the original footprints are setup to directly use the path 
variable as this was necessary in the past. So the search path thing 
will only help for future updates not for past ones.)

> In this case, relying on a "system" library (as is true for 
/Libraries/Application Support/kicad on mac) makes no sense.

You know you can personally clone the library repos to any place on your 
system right? You really do not need to rely on the system provided 
ones. (Simply point the path variables to your local setup.)

More details for such a

Re: [Kicad-developers] Idea: Merging libraries along the search path

2019-03-12 Thread Rene Pöschl

Hi again, I thought about it a bit more. I am less and less convinced this
will make it easier for users to understand the library setup overall.

But i understand where this comes from. After all many users say library
management is hard in kicad. (It is always listed as a downside when kicad
is compared to for example eagle.)

I am however not really convinced users mean "management" when they say
library management. (TlDr: they want it made easy to add assets anywhere
without needing to think about proper library organization. Your suggestion
would indeed help here. Details why i do not really like that are below.)

---

I think v5.1 adds a lot of powerful tools for proper centralized library
management. (the tree view is extremely powerful especially the right click
context menu.)  Please to not introduce new features that make these tools
no longer viable. (Make sure they are replaced with some that are as
powerful if you really must replace them.)
This also brings up the question how would you integrate merged parts into
the treeview. I think this will be one of the hardest things to decide with
your suggestion. (But maybe i am completely blind here.)

---

Right now kicad kind of favors a centralized library setup (the global
library) filled with generic footprints (and arguably generic symbols as
well.) I might be biased but this is a good thing in my opinion. (and i
would guess larger organizations would also like a tool that favors a
centralized library setup. Small organizations that do not have the
manpower to properly manage a centralized lib might in fact favor a project
central setup "managed" by every engineer.)

I think your suggestion in general would move kicad more towards project
specific libraries. (It will highly depend on the interface and the exact
implementation details.)
I would suggest that it is ensured that a centralized setup is as easy or
maybe even easier to handle than a distributed project local one.

This means it should always be possible to update assets in the central lib
and have these changes be pushed (with user interaction like it is now on
the pcb side of things) into old projects. It also means that it should be
easy to import assets into existing libs and it should also be easy to edit
the central library. (Unless it is write protected.) The later one is kind
of ensured if a single library asset is a single file.
For this to be fulfilled there must be an easy way to open the central
asset even if there is a conflict with a local one.

---

The current implementation of kicad kind of forces users to think about
their library setup in a way that eagle as an example does not. (I use
eagle as an example here as i am sadly forced to use it right now. So i
have a bit more insight into the differences between these two tools than i
would like to be honest. I also have an insight into what happens if you do
not have a central library management team made worse by the fact that
nobody in the company seems to really understand or care about proper
library management. You can say this is a bit of a culture shock for me in
particular.)

With eagle it is exceedingly easy to download a library (most likely
containing assets representing one component) and have it up and running
without needing to do anything in eagle itself (simply download to one
directory in the searchpath) On the surface this sounds like a great idea
right?

Sadly the fact that it is way harder to add an asset to an existing lib
results in users being at least tempted into having a directory full of
single component libs. (I would argue this is an unintended consequence of
making adding libs from the web easier than importing parts into an
existing library.)

Eagle makes it even worse as one can not link symbols to generic footprints
outside of the same library. Meaning i am also opposed to consolidating the
symbol and footprint libs into a single file (Not part of your suggestion
but lets put this out there as it fits the general theme of things. And
might even be kind of a logical conclusion if we take your suggestion too
far. After all if global libs are made harder to use compared to project
libs why would generic footprint libs make any sense?)

Why am i in favor of generic footprints? Well most components come in
standardized (JEDEC) packages. It makes sense to use standardized (IPC)
footprints for these.

---

The idea about copying the global assets into the project as a separate
local library is another thing that sounds good on the surface but again
comes with consequences. The problem with that is that you will most likely
end up with users being confused as the same asset now exists in multiple
libs. (The interface must be very well defined here. And very well
documented.)


Am Mo., 11. März 2019 um 16:13 Uhr schrieb Simon Richter <
simon.rich...@hogyros.de>:

> Hi,
>
> since the topic of library management came up: Would it make sense to
> collect library contents along the library search

Re: [Kicad-developers] Idea: Merging libraries along the search path

2019-03-11 Thread Rene Pöschl


On 11/03/19 16:13, Simon Richter wrote:


This would solve the problem where users modify parts from shipped
libraries and cannot save back because they are read-only

I am not sure about that one to be honest. But i can see reason behind it

and would also
ensure that projects contain all parts required (so we don't have to
embed them into the files).
Please embed them. Users now always forget to include the cache lib in 
backups or archives all the time. What makes you think this will be 
different in the future?
(You would need a project local lib with the asset in the state of the 
project anyways. This is to ensure against changes in the library. So 
you do not save on storage space in any way and only increase the danger 
that users do not include these additional files in backups.)




___
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] Download speeds for nightly builds seem a bit slow to a lot of people over at the forum

2019-03-09 Thread Rene Pöschl


On 09/03/19 14:36, Mark Roszko wrote:
Honestly, problems on a timescale of just 10 hours of reporting so far 
can just be some backhaul operator screwing up their peering or even 
having hardware failing and causing performance issues with certain 
routes.

/
/One needs to wait and see if they persist for more than day./
/


Even if that is the case i would still argue that it points to a general
problem. Having only a single download point might simply not be viable
any more. (KiCad might just have become too popular to be distributed by
one central server.)


___
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] Download speeds for nightly builds seem a bit slow to a lot of people over at the forum

2019-03-09 Thread Rene Pöschl


On 09/03/19 14:36, Mark Roszko wrote:
Honestly, problems on a timescale of just 10 hours of reporting so far 
can just be some backhaul operator screwing up their peering or even 
having hardware failing and causing performance issues with certain 
routes.

/
/One needs to wait and see if they persist for more than day./
/


Even if that is the case i would still argue that it points to a general 
problem. Having only a single download point might simply not be viable 
any more. (KiCad might just have become too popular to be distributed by 
one central server.)


___
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] Download speeds for nightly builds seem a bit slow to a lot of people over at the forum

2019-03-09 Thread Rene Pöschl




On 09/03/19 16:56, Clemens Koller wrote:

On 09/03/2019 14.27, Rene Pöschl wrote:

It might help if you could state where on this planet you are. The
problem seems to either be location or time dependent.

Germany, Munich.
Regardless of that, the problem is likely not server-side.

Clemens


Users don't really care where the problem is. The complaint stays valid. 
(Adding a "works for me" without including crucial information only adds 
noise to the conversation.)



___
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] Download speeds for nightly builds seem a bit slow to a lot of people over at the forum

2019-03-09 Thread Rene Pöschl

We are talking about the download speed for nightly builds right now. 
(At least that was the problem i reported)
I doubt torrents would help here as i highly doubt nightly builds will 
ever reach the critical mass required for torrents to be effective.

On 10/03/19 04:09, Andrew Lutsenko wrote:
If you have to choose just one method of distribution, then sure, 
torrents are not the best.
But there is absolutely no reason to stay away from them since there 
is no such limitation, we can have both mirrors and magnet links. Good 
portion of tech savy people will choose p2p download because it is 
guaranteed to saturate your connection for any reasonably popular 
torrent. And it works well on release day.

On Sat, Mar 9, 2019 at 6:33 PM Andrey Kuznetsov > wrote:

Mirrors are better. Torrents are either not allowed on some
networks or people don't know how to use them or don't care to
install the required software, some of which is not malware/ad-free.
So my suggestion is to stay away from torrents.

On Sat, Mar 9, 2019 at 3:23 PM Andrew Lutsenko
mailto:anlutse...@gmail.com>> wrote:

I think torrents are the best solution.
Even when servers function normally on each release there is a
stampede to download new binary and things slow down to a
crawl. I don't know if moving to CERN servers (AWS
servers?) will help but torrents certainly would.

It's as simple as creating a torrent with openbittorrent.com
 tracker or even just a magnet link
relying on DHT.
I can help script this if needed.

On Sat, Mar 9, 2019 at 10:32 AM Marco Ciampa
mailto:ciam...@posteo.net>> wrote:

On Sat, Mar 09, 2019 at 01:22:39PM -0500, Wayne Stambaugh
wrote:
> Thanks.  If we are having issues with the CERN download
speeds (although
> it is not entirely evident that is the issue) it would
be good to have
> alternate mirrors for users to try if they are having
issues with the
> main download server.

Why not adding torrent seeds like done for the Ubuntu iso
images or
Libreoffice binary files? We must have a torrent tracker
somewhere and
that should offload servers and should solve the peak
download problems
if any...

-- 

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

Unsubscribe : https://launchpad.net/~kicad-developers

More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers

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

Unsubscribe : https://launchpad.net/~kicad-developers

More help   : https://help.launchpad.net/ListHelp

-- 
Remember The Past, Live The Present, Change The Future

Those who look only to the past or the present are certain to miss
the future [JFK]

kandre...@gmail.com 
Live Long and Prosper,
Andrey

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

___
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] Download speeds for nightly builds seem a bit slow to a lot of people over at the forum

2019-03-09 Thread Rene Pöschl

It might help if you could state where on this planet you are. The 
problem seems to either be location or time dependent.


On 09/03/19 14:21, Clemens Koller wrote:

I cannot confirm such a slow download.
I get 23MBytes/s speed from https://kicad-downloads.s3.cern.ch which is the max 
I can get here.

Regards,

Clemens

On 09/03/2019 12.38, Rene Pöschl wrote:

Hi,


it seems that some of our users struggle to download nightly builds for
windows from the cern servers right now.

Is this an expected sideeffect of the server move or is there currently
a problem?


The original report was made over here:
https://forum.kicad.info/t/window-nightlies-download-speed/15633/

Some of the guys report download speeds in the low kB/s range and even
experience total download failures. (It might be noteworthy that all the
guys reporting problems are outside of europe.)


___
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] Download speeds for nightly builds seem a bit slow to a lot of people over at the forum

2019-03-09 Thread Rene Pöschl


Hi,


it seems that some of our users struggle to download nightly builds for 
windows from the cern servers right now.


Is this an expected sideeffect of the server move or is there currently 
a problem?



The original report was made over here: 
https://forum.kicad.info/t/window-nightlies-download-speed/15633/


Some of the guys report download speeds in the low kB/s range and even 
experience total download failures. (It might be noteworthy that all the 
guys reporting problems are outside of europe.)



___
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.0-rc2 tag

2019-02-28 Thread Rene Pöschl


The libraries have been tagged.

On 25/02/19 20:02, Wayne Stambaugh wrote:

It looks like we are ready to tag 5.1.0-rc2.  I plan on tagging it this
evening after I get home from work at ~6PM EST.  If you have any other
bug fixes to merge for rc2, now would be a good time.  If nothing
critical shows up by the weekend, I will tag 5.1.0 on Saturday and
create the 5.1 branch.  Hopefully it wont take more than a week after
that to get the libraries, documentation, and translations tagged and
most the package builds completed and uploaded.  If there are any issues
with this schedule, please let me know so I can plan for the release
announcement.

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

[Kicad-developers] kicad-pcb.org not reachable

2019-02-05 Thread Rene Pöschl


It seems the kicad website is currently down.


___
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] What is the difference between the use of 3d model search path entries and normal path variables (environment variables)?

2019-01-15 Thread Rene Pöschl


Sadly these do not really answer my questions.

On 15/01/19 17:25, Mário Luzeiro wrote:

Hi Rene,

Not sure if it is documented.
Cirilo was the main person on the development of the 3D searching paths.
Searching the mailing list there may be some hints to this questions, but it 
may not be totally true or updated at this moment:

https://lists.launchpad.net/kicad-developers/msg24138.html
https://lists.launchpad.net/kicad-developers/msg14225.html
https://lists.launchpad.net/kicad-developers/msg24232.html

Regards,
Mario Luzeiro


From: Kicad-developers  
on behalf of Rene Pöschl 
Sent: 11 January 2019 17:25
To: KiCad Developers
Subject: [Kicad-developers] What is the difference between the use of 3d model 
search path entries and normal path variables (environment variables)?

Hi,

I noticed that the configure path tool in the footprint editor has a new
part added to it. This part seems to manage 3d model search directories.
Such a search directory consists of the path, an alias, and a description.
As there is a way to change the order of search path entries i would
guess that there is also prioritization at play.

Could someone detail how this would be used? Would it clash with the use
of normal path variables (after all our official footprints all use the
KISYS3DMOD path variable)? Which of the two is preferred assuming these
two are meant to serve the same usecase?

___
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] What is the difference between the use of 3d model search path entries and normal path variables (environment variables)?

2019-01-11 Thread Rene Pöschl


Hi,

I noticed that the configure path tool in the footprint editor has a new 
part added to it. This part seems to manage 3d model search directories. 
Such a search directory consists of the path, an alias, and a description.
As there is a way to change the order of search path entries i would 
guess that there is also prioritization at play.


Could someone detail how this would be used? Would it clash with the use 
of normal path variables (after all our official footprints all use the 
KISYS3DMOD path variable)? Which of the two is preferred assuming these 
two are meant to serve the same usecase?


___
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

2019-01-07 Thread Rene Pöschl


On 04/01/19 15:10, Wayne Stambaugh wrote:


Is there a way to mark a unit as "power unit" (I think you mentioned
sometime back that this might be required to properly make simulation
for multi unit symbols possible while still allowing the power unit to
be separate. A power unit would also be a "must be placed unit" but i
feel separating these two might add more flexibility.)


See definition above.  I'm not sure having a "required" keyword is
useful.  Do you have an example in mind.



There are many parts that not only have power connections but also some
control connections that are necessary for the function of the part.
A lot of these have the control pins shared between many units so it
makes sense to move them to a specialized unit. That unit would then be
required but does not fulfill the "this is a power unit" thing. Hence my
suggestion for a more general "this unit must be placed" vs. "This unit
is optional" field. (The "This is a power unit" thing is not really
necessary for ERC. At least not if there is a "this is a required unit"
flag. The only reason i suggested that is because you mentioned that it
might be required for simulation purposes.)


___
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

2019-01-04 Thread Rene Pöschl


Something else that i remembered now.

Would it be a good idea to prepare for alternative function handling for 
pins?
Meaning an alternative pin name connected to an alternative type (or a 
number of these)


That would allow better symbols for micro controllers.

I do not expect this to be implemented for v6 but maybe this is 
something that should be integrated in the file format spec such that a 
future implementation is comparably easy.


On 01/01/19 20:59, 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 format document
so things like constraints belong in the schematic file format.  I will
be posting the schematic file format as soon as I finish updating it.

Cheers,

Wayne

[1]:
https://docs.google.com/document/d/1lyL_8FWZRouMkwqLiIt84rd2Htg4v1vz8_2MzRKHRkc/edit


___
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

2019-01-04 Thread Rene Pöschl


On 04/01/19 15:10, Wayne Stambaugh wrote:

Is there a way to mark a unit as "power unit" (I think you mentioned
sometime back that this might be required to properly make simulation
for multi unit symbols possible while still allowing the power unit to
be separate. A power unit would also be a "must be placed unit" but i
feel separating these two might add more flexibility.)

See definition above.  I'm not sure having a "required" keyword is
useful.  Do you have an example in mind.



There are many parts that not only have power connections but also some 
control connections that are necessary for the function of the part. A 
lot of these have the control pins shared between many units so it makes 
sense to move them to a specialized unit. That unit would then be 
required but does not fulfill the "this is a power unit" thing. Hence my 
suggestion for a more general "this unit must be placed" vs. "This unit 
is optional" field. (The "This is a power unit" thing is not really 
necessary for ERC. At least not if there is a "this is a required unit" 
flag. The only reason i suggested that is because you mentioned that it 
might be required for simulation purposes.)


___
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

2019-01-02 Thread Rene Pöschl

I have a few questions regarding multi part (or multi unit) symbols. (I 
do not really see a clear indication for these features in your document.)


Is there a definition for having only some units exchangeable?
Is there a way to define a unit as "must be placed" or "optional"?
Is there a way to mark a unit as "power unit" (I think you mentioned 
sometime back that this might be required to properly make simulation 
for multi unit symbols possible while still allowing the power unit to 
be separate. A power unit would also be a "must be placed unit" but i 
feel separating these two might add more flexibility.)


On 01/01/19 20:59, 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 format document
so things like constraints belong in the schematic file format.  I will
be posting the schematic file format as soon as I finish updating it.

Cheers,

Wayne

[1]:
https://docs.google.com/document/d/1lyL_8FWZRouMkwqLiIt84rd2Htg4v1vz8_2MzRKHRkc/edit


___
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] Cost of different courtyard elements for the closed outline and DRC algorithms

2019-01-01 Thread Rene Pöschl




On 01/01/19 23:53, John Beard wrote:


@Rene: can you give some examples of "extensive" arc use on the
courtyard layers that you are thinking of?

Cheers,

John



The two pull requests i linked should give you an idea of what i right
now consider as most extensive use. Maybe also some battery holders that
are already in the lib.

Right now only parts that are used in low numbers on a board have
rounded courtyards. These are also the parts that benefit the most from
using close fitting courtyards. (A battery holder as a rectangle would
waste a lot more space than thinking about what to do with a 0402
(imperial) resistor.)

What i gather from this discussion is that we should be ok with using
arcs in such cases but we should not go overboard and do it for every
part. (Especially not ones where there is very little to gain.)


___
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] Cost of different courtyard elements for the closed outline and DRC algorithms

2019-01-01 Thread Rene Pöschl


Hi,

Right now we have a few contributions for the library that use arcs 
quite extensively on the courtyard layer.


I would therefore like a bit of input.

Are arc generally more expensive than lines?

Is there a difference if the arc is a multiple of 90 degree compared to 
any other angle.



Is there a difference if the endpoints of two neighboring endpoints meed 
exactly vs they being within the tolerance range for counting as a 
closed outline (If i remember correctly then the tolerance was 0.01mm. I 
assume this is the radius of the tolerance circle.)


Regarding tolerance: How stable will the currently chosen value be? (If 
we allow arcs on the courtyard layer then we will need to fix a 
tolerance in the KLC. This is especially the case for arcs that are not 
90 degrees.)



The two pull requests that are responsible for this question:

- https://github.com/KiCad/kicad-footprints/pull/1040

- https://github.com/KiCad/kicad-footprints/pull/1159


___
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.0.2 stable release.

2018-12-04 Thread Rene Pöschl

How does a package get karma? Can the community perhaps help out in some 
way?


On 04/12/18 19:57, Steven A. Falco wrote:

My build of kicad-5.0.2-1.fc29 has completed in the Fedora buildsystem, and 
I've submitted it for testing.  Thus, the build should show up in the 
updates-testing repo as soon as a release engineer pushes it along - usually 
that takes a day or two.

After that, if it receives enough (positive) karma, it will move into the 
updates repo.

I'll note that last time (for 5.0.1), there was insufficient karma, so the 
5.0.1 build had to sit for an extra week in the updates-testing repo before it 
became eligible for promotion to the updates repo.

Steve


___
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.0.2 stable release.

2018-12-03 Thread Rene Pöschl

The libs are now tagged.

On 03/12/18 13:49, Wayne Stambaugh wrote:

I saw that the translation and doc repos were tagged for 5.0.2.  Where
do we stand on the library repos?

On 11/26/2018 6:49 PM, Evan Shultz wrote:

I should have also mentioned that the outstanding items milestoned for
5.0.2 are actual fixes which we would like to include. We've been
careful not to pushing breaking changes flippantly so tagging the head
of each library should be safe and an improvement. Breaking changes
haven't been intentionally made since 5.0.0 unless it was to fix an
issue that might ruin a design (wrong pinout, footprint pins swapped, etc.).

On Mon, Nov 26, 2018 at 3:08 PM Evan Shultz mailto:evan.shu...@gmail.com>> wrote:

 Yay!

 We (librarians) have a few outstanding items in the library we want
 to close before 5.0.2, but it should only be a couple of days and
 well within the one week timeline you requested. Thanks mostly to
 Antonio, we're now using the milestone feature of GH so you can see
 what's left at https://github.com/KiCad/kicad-symbols/milestone/6
 and https://github.com/KiCad/kicad-footprints/milestone/1 (for
 symbols and footprints, at least).

 On Mon, Nov 26, 2018 at 3:05 PM Wayne Stambaugh
 mailto:stambau...@gmail.com>> wrote:

 I just tagged and pushed 5.0.2 so we need to decide what we want
 to do
 about tagging the library and translation repos.  Rene, any
 thoughts on
 the library repos.  I know there have been a lot of changes
 since 5.0.1
 but as long as the existing symbols have changed too
 significantly, I'm
 fine with tagging the current head of each library.

 On 11/26/2018 5:55 PM, Nick Østergaard wrote:
 > Are we expecting to tag 5.0.1 as 5.0.2 for the libraries or are we
 > getting a minor library update as well?
 > On Mon, 26 Nov 2018 at 20:32, Wayne Stambaugh
 mailto:stambau...@gmail.com>> wrote:
 >>
 >> I just noticed a few last minute changes were made to the 5.0
 branch.
 >> Is there anything else pending or am I good to go with
 tagging 5.0.2?
 >>
 >> Cheers,
 >>
 >> Wayne
 >>
 >> On 11/25/2018 2:01 PM, Wayne Stambaugh wrote:
 >>> I plan on tagging 5.0.2 tomorrow unless is a show stopper
 bug that I am
 >>> not aware of.  My goal is to give the library, doc, and
 translations a
 >>> week to get tagged for 5.0.2 and another week for the
 installers to get
 >>> built so I can make the release announcement on 12/9.
 Please let me
 >>> know if this doesn't fit into your schedule so we can make
 other plans.
 >>>
 >>> Once 5.0.2 is released, I would like to string freeze the
 development
 >>> branch to start getting ready of 5.1 release candidates by
 the beginning
 >>> of the year.  If you have any UI string changes that you are
 planning to
 >>> make, now would be a good time.
 >>>
 >>> Thank you again everyone for your hard work.  KiCad continues to
 >>> steadily improve due to your efforts.
 >>>
 >>> 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] 5.0.2 stable release.

2018-12-03 Thread Rene Pöschl

I am a bit out of the loop sadly as i had quite a busy month behind me 
(new job plus some old responsibilities)

I created an issue over at the symbol repo. [1] Both to ask the other 
librarians and for a place to report design breaking changes. (A few 
symbols have been changed since 5.0.1 it seems.)
If there are no objections then i will tag tomorrow morning before i go 
to work (~06:45 CET)
A word of warning: My internet seems to be a bit unstable. If i do not 
tag tomorrow then it might have been broken completely.

[1]: https://github.com/KiCad/kicad-symbols/issues/1213

On 03/12/18 13:49, Wayne Stambaugh wrote:

I saw that the translation and doc repos were tagged for 5.0.2.  Where
do we stand on the library repos?

On 11/26/2018 6:49 PM, Evan Shultz wrote:

I should have also mentioned that the outstanding items milestoned for
5.0.2 are actual fixes which we would like to include. We've been
careful not to pushing breaking changes flippantly so tagging the head
of each library should be safe and an improvement. Breaking changes
haven't been intentionally made since 5.0.0 unless it was to fix an
issue that might ruin a design (wrong pinout, footprint pins swapped, etc.).

On Mon, Nov 26, 2018 at 3:08 PM Evan Shultz mailto:evan.shu...@gmail.com>> wrote:

 Yay!

 We (librarians) have a few outstanding items in the library we want
 to close before 5.0.2, but it should only be a couple of days and
 well within the one week timeline you requested. Thanks mostly to
 Antonio, we're now using the milestone feature of GH so you can see
 what's left at https://github.com/KiCad/kicad-symbols/milestone/6
 and https://github.com/KiCad/kicad-footprints/milestone/1 (for
 symbols and footprints, at least).

 On Mon, Nov 26, 2018 at 3:05 PM Wayne Stambaugh
 mailto:stambau...@gmail.com>> wrote:

 I just tagged and pushed 5.0.2 so we need to decide what we want
 to do
 about tagging the library and translation repos.  Rene, any
 thoughts on
 the library repos.  I know there have been a lot of changes
 since 5.0.1
 but as long as the existing symbols have changed too
 significantly, I'm
 fine with tagging the current head of each library.

 On 11/26/2018 5:55 PM, Nick Østergaard wrote:
 > Are we expecting to tag 5.0.1 as 5.0.2 for the libraries or are we
 > getting a minor library update as well?
 > On Mon, 26 Nov 2018 at 20:32, Wayne Stambaugh
 mailto:stambau...@gmail.com>> wrote:
 >>
 >> I just noticed a few last minute changes were made to the 5.0
 branch.
 >> Is there anything else pending or am I good to go with
 tagging 5.0.2?
 >>
 >> Cheers,
 >>
 >> Wayne
 >>
 >> On 11/25/2018 2:01 PM, Wayne Stambaugh wrote:
 >>> I plan on tagging 5.0.2 tomorrow unless is a show stopper
 bug that I am
 >>> not aware of.  My goal is to give the library, doc, and
 translations a
 >>> week to get tagged for 5.0.2 and another week for the
 installers to get
 >>> built so I can make the release announcement on 12/9.
 Please let me
 >>> know if this doesn't fit into your schedule so we can make
 other plans.
 >>>
 >>> Once 5.0.2 is released, I would like to string freeze the
 development
 >>> branch to start getting ready of 5.1 release candidates by
 the beginning
 >>> of the year.  If you have any UI string changes that you are
 planning to
 >>> make, now would be a good time.
 >>>
 >>> Thank you again everyone for your hard work.  KiCad continues to
 >>> steadily improve due to your efforts.
 >>>
 >>> 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:

Re: [Kicad-developers] Has the handling of the datasheet field changed again?

2018-11-21 Thread Rene Pöschl


On 21/11/2018 18:38, Jeff Young wrote:

Version 5.0.x (and version 4.0.x) gave us the option to store the datasheets 
for both
aliases and main symbols in the dcm file.

Right; that hasn’t changed.  What’s changed (or should have changed) is that 
the above is the *only* option.

So is it not OK for that to be the only option, or is it just not working that 
way?

(Sorry for not testing it myself, but I’m knee-deep in the 
paste-symbol-twice-revert crash bug.)


We just need a way to set the datasheet stuff in the dcm file for non 
aliases. Right now there is only one input field that stores it in the 
lib file.


One option that comes to mind is that the current layout of one entry 
field is kept. But that there is some setting that controls if it is 
stored in the dcm or lib file. (If we simply say that the current entry 
field saves to the dcm file someone who currently uses only the lib file 
field will be unhappy.)



___
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] Has the handling of the datasheet field changed again?

2018-11-21 Thread Rene Pöschl


On 21/11/2018 17:41, Jeff Young wrote:

@Wayne,


This is a limitation of the current symbol file format but the root datasheet 
field
should be empty and the datasheet url should be stored in the document file
along with the description and keywords.  This way it's consistent with all of 
the
alias information and doesn't violate the KLC.

Are you sure that’s not backwards?  That’s the way I changed the internals to 
work.  (Perhaps we still have code to map it to the other way on output, but 
then that wouldn’t have changed.)



Version 5.0.x (and version 4.0.x) gave us the option to store the 
datasheets for both aliases and main symbols in the  dcm file. This 
means it is consistent no matter what type a symbol is. This makes our 
testscripts easy as we only need to check the dcm file for documentation 
information. For this reason we do not allow any symbol to have the 
datasheet field of the lib file filled in the official lib. (this is 
also where the noise would come from. With the current way of the 
implementation the datasheet field of symbols would move from one file 
to the other.)



The way it was in v5.0.1 is as follows: If the datasheet field of the 
lib file is empty it gets overwritten with the one from the dcm file 
when placing a symbol into the schematic.



For you this means that even if the documentation fields stay in the 
general tab they should still all be saved in the dcm file.



___
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] Has the handling of the datasheet field changed again?

2018-11-20 Thread Rene Pöschl

Is it possible that the datasheet field has been moved to the lib file 
in the current nightly builds? That would break our testscripts and 
create unnecessary noise on github. I thought the solution (for v5) has 
been that the field of the lib file is filled with the one from the dcm 
file if it is left empty. However it seems one can not fill the dcm file 
version for a symbol that is not an alias.



___
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 of our symbols currently still have invisible power pins. We want to fix this but want to give you guys a chance for input first.

2018-11-07 Thread Rene Pöschl

On 07/11/18 17:39, Kevin Cozens wrote:ons I was thinking that option 3 
might be the best

How will not hiding pins affect IC's with multiple parts (e.g. a 7400)? Will
each part have the power and ground pins?


Like we did with the 4xxx series parts. There will be a further unit 
added that only holds the power pins. (Meaning the symbol will no longer 
be one where the units are interchangeable.)

Adding the power pins to every unit is confusing and error prone.

___
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 of our symbols currently still have invisible power pins. We want to fix this but want to give you guys a chance for input first.

2018-11-06 Thread Rene Pöschl

Only logic family libs are affected. The 4xxx lib is already done. This 
leaves 4 libs at most. (I have no access to kicad right at this moment 
so i can not check.)


Only option 2 ends up with multiples of the lib. In option 3 we will 
rename the lib (meaning a new lib will be added and the original one is 
deleted)


On 06/11/18 23:24, Diego Herranz wrote:

Hi, Rene.

Thanks for bringing this up. I've never liked hidden power pins. In my 
opinion, the python philosophy applies here too: "Explicit is better 
than implicit."


How many libraries will need this?
I'm asking because, if we went for option 3 (or 2), will we end up 
with a lot of nearly identical duplicated libraries? That can be very 
confusing for users and for maintaining the GitHub libraries (e.g. 
getting pull requests for the old libraries instead of the new ones, 
etc.).
And at some point we would need to get rid of the old ones anyway not 
to carry them forever, won't we?


I'm wondering whether we can for option 1 if we evaluate what the 
behaviour would be regarding ERC, symbol rescue, etc.


Thanks,
Diego

On Tue, Nov 6, 2018 at 9:42 PM Rene Pöschl <mailto:poesc...@gmail.com>> wrote:


Hi all,


Sadly we did not come around to fix all symbols before the v5
release.
We now seem to have a volunteer who would be prepared to fix these
symbols.

There is a catch though. Whatever we do to fix this it will break
designs that use the old symbols right now.


So we have a few options:

- 1 - Change the symbols inside the library and inform the users
about
this fix. (Will break current designs as the power pins will no
longer
be connected automatically. This after all is the point of the
fix. Not
sure if rescue is reliable enought to chatch that. ERC might also not
complain if we put the power pins onto a separate unit.)

- 2 - Add a separate library that holds the fixed symbols, keep
the old
one but remove it from the template library table. This means no
designs
are borken as old users do not get the new lib added without an
explicit
action on their part.

- 3 - Rename the library before fixing it. add the new lib to the lib
table. This would still break designs. (But in a different way. In
this
case the symbol might simply not be found. This is something that the
rescue stuff should deal with.) In addition users will get an error
message when starting eeschema or the symbol editor that alerts them
about a missing file. (So if we make an announcement that includes
the
error message they should find it when they google for it.)


My personal vote would be for option 3.


___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-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] Some of our symbols currently still have invisible power pins. We want to fix this but want to give you guys a chance for input first.

2018-11-06 Thread Rene Pöschl


Hi all,


Sadly we did not come around to fix all symbols before the v5 release. 
We now seem to have a volunteer who would be prepared to fix these symbols.


There is a catch though. Whatever we do to fix this it will break 
designs that use the old symbols right now.



So we have a few options:

- 1 - Change the symbols inside the library and inform the users about 
this fix. (Will break current designs as the power pins will no longer 
be connected automatically. This after all is the point of the fix. Not 
sure if rescue is reliable enought to chatch that. ERC might also not 
complain if we put the power pins onto a separate unit.)


- 2 - Add a separate library that holds the fixed symbols, keep the old 
one but remove it from the template library table. This means no designs 
are borken as old users do not get the new lib added without an explicit 
action on their part.


- 3 - Rename the library before fixing it. add the new lib to the lib 
table. This would still break designs. (But in a different way. In this 
case the symbol might simply not be found. This is something that the 
rescue stuff should deal with.) In addition users will get an error 
message when starting eeschema or the symbol editor that alerts them 
about a missing file. (So if we make an announcement that includes the 
error message they should find it when they google for it.)



My personal vote would be for option 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

Re: [Kicad-developers] 5.0.1 status

2018-10-08 Thread Rene Pöschl


Libraries are tagged.

On 09/10/18 00:24, Wayne Stambaugh wrote:

Rene,

Looks good to me.  Tag it as soon as you are ready.

Thanks,

Wayne

On 10/08/2018 04:45 PM, Rene Pöschl wrote:

Hi all,

Updated list can now be found in comment
https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-427971380
(I tried to determine for every change where it comes from. Did not find
the pull request in question for the three removed symbols and for one
possible false positive.)



On 08/10/18 20:52, Wayne Stambaugh wrote:

Hi Rene,

I didn't see anything the the list you linked that I would consider a
show stopper.  I wait until you post the results of you test script
against the latest changes.

Thanks,

Wayne

On 10/8/2018 11:35 AM, Rene Pöschl wrote:

Regarding libs.

I would need to run the script testing for incompatible changes with the
current master. (I can do this as soon as i am home today. So in a few
hours.) I already ran it at the end of August the changes that occurred
until then are documented in [1]

As soon as i update that list somebody will need to decide if the
changes are acceptable for being included. If not then 5.0.1 should
continue to ship with the libs tagged as 5.0.0 (It would not make much
sense to add a new tag onto the same commit. I would even argue that
this might confuse users who would expect changes if a new tag is
created.)

[1]:
https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-417592514

On 08/10/2018 15:24, Wayne Stambaugh wrote:

I'm making a last call for any bug fixes that need to made to the 5.0
branch for the 5.0.1 release.  Please let me know if you have any
pending fixes before I tag 5.0.1.  I intend to tag this around 6PM EST
unless I hear otherwise.  How much time will our translators and
librarians need to tag 5.0.1?  Hopefully not too long so we can give
our
packagers time to get release packages built.  I would like to make the
release announcement this coming weekend if at all possible.

I also intend to leave the 5.0.1 tag as the revision and set the source
archive version to 5.0.1-unknown so the -dev suffix will no longer
be in
play moving forward which should make our packagers happy.

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

___
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.0.1 status

2018-10-08 Thread Rene Pöschl


Hi all,

Updated list can now be found in comment 
https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-427971380 
(I tried to determine for every change where it comes from. Did not find 
the pull request in question for the three removed symbols and for one 
possible false positive.)




On 08/10/18 20:52, Wayne Stambaugh wrote:

Hi Rene,

I didn't see anything the the list you linked that I would consider a
show stopper.  I wait until you post the results of you test script
against the latest changes.

Thanks,

Wayne

On 10/8/2018 11:35 AM, Rene Pöschl wrote:

Regarding libs.

I would need to run the script testing for incompatible changes with the
current master. (I can do this as soon as i am home today. So in a few
hours.) I already ran it at the end of August the changes that occurred
until then are documented in [1]

As soon as i update that list somebody will need to decide if the
changes are acceptable for being included. If not then 5.0.1 should
continue to ship with the libs tagged as 5.0.0 (It would not make much
sense to add a new tag onto the same commit. I would even argue that
this might confuse users who would expect changes if a new tag is created.)

[1]:
https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-417592514

On 08/10/2018 15:24, Wayne Stambaugh wrote:

I'm making a last call for any bug fixes that need to made to the 5.0
branch for the 5.0.1 release.  Please let me know if you have any
pending fixes before I tag 5.0.1.  I intend to tag this around 6PM EST
unless I hear otherwise.  How much time will our translators and
librarians need to tag 5.0.1?  Hopefully not too long so we can give our
packagers time to get release packages built.  I would like to make the
release announcement this coming weekend if at all possible.

I also intend to leave the 5.0.1 tag as the revision and set the source
archive version to 5.0.1-unknown so the -dev suffix will no longer be in
play moving forward which should make our packagers happy.

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] 5.0.1 status

2018-10-08 Thread Rene Pöschl


Regarding libs.

I would need to run the script testing for incompatible changes with the 
current master. (I can do this as soon as i am home today. So in a few 
hours.) I already ran it at the end of August the changes that occurred 
until then are documented in [1]


As soon as i update that list somebody will need to decide if the 
changes are acceptable for being included. If not then 5.0.1 should 
continue to ship with the libs tagged as 5.0.0 (It would not make much 
sense to add a new tag onto the same commit. I would even argue that 
this might confuse users who would expect changes if a new tag is created.)


[1]: 
https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-417592514


On 08/10/2018 15:24, Wayne Stambaugh wrote:

I'm making a last call for any bug fixes that need to made to the 5.0
branch for the 5.0.1 release.  Please let me know if you have any
pending fixes before I tag 5.0.1.  I intend to tag this around 6PM EST
unless I hear otherwise.  How much time will our translators and
librarians need to tag 5.0.1?  Hopefully not too long so we can give our
packagers time to get release packages built.  I would like to make the
release announcement this coming weekend if at all possible.

I also intend to leave the 5.0.1 tag as the revision and set the source
archive version to 5.0.1-unknown so the -dev suffix will no longer be in
play moving forward which should make our packagers happy.

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] Remind me why we have both filled polygons and non-copper zones

2018-10-02 Thread Rene Pöschl

Zones and polygons behave a bit differently when it comes to rounded 
corners.
For zones the minwidth setting controls the round radius, for polygons 
it is the line width.
This means polygons with rounded corners are always larger than drawn by 
the radius size (half line width). But zones are exactly as drawn 
(except around corners where they are rounded)


Additionally: zones have more editing support. (At least in 5.0.0 there 
is no way to add corners to polygons after it is first created. I assume 
this will be added at a later stage)


On 02/10/18 23:26, Seth Hillbrand wrote:

Hi Jeff-

Here's a relevant thread:
https://lists.launchpad.net/kicad-developers/msg34235.html

-S

Am Di., 2. Okt. 2018 um 05:16 Uhr schrieb Jeff Young >:


Was the intention that one of them was being replaced by the
other? Or do we need both for some reason?

Thanks,
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] GAL canvas strategy - testers needed!

2018-09-19 Thread Rene Pöschl


On 19/09/2018 11:54, jp charras wrote:

Le 19/09/2018 à 11:40, Rene Pöschl a écrit :

Ok i looked at the pot symbols. They are indeed strange. (ignore my last
message)

However, how does the new fill algorithm work with things like the logic
gates. (Example the symbol for 74LS00) It has an open polygon on purpose
as it consists of that polygon plus an arc. We still want the body do be
filled but do not want a visible line between the arc and the polygon body.

There is no problem with 74LS00 and 74LS02 shapes.

You could find an issue with a 74LS32, but the polygon used as a filled
shape is broken: its line width is set to -1000 mils, a bit strange.



The reason for that is that kicad did not (or does not) support filling 
shapes with concave arcs in it. So the outline was made with arcs and 
lines whereas the filled part was made with a single polygon that 
approximates the shape needed. To reduce the number of needed line 
segments the shape is approximated quite crudely. This works because the 
filled shape does not have an outline to it. (Meaning the errors in it 
are hidden by the true outline that is created from arcs) As setting 
line width to 0 does not result in a polygon of 0 width the trick with 
the large negative value was used to achieve 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] GAL canvas strategy - testers needed!

2018-09-19 Thread Rene Pöschl

Ok i looked at the pot symbols. They are indeed strange. (ignore my last 
message)


However, how does the new fill algorithm work with things like the logic 
gates. (Example the symbol for 74LS00) It has an open polygon on purpose 
as it consists of that polygon plus an arc. We still want the body do be 
filled but do not want a visible line between the arc and the polygon body.


On 19/09/2018 00:04, Jeff Young wrote:

I pushed John’s 3 patches along with one of my own which fixes the POT 
rendering.

(It is actually an error in the library item, but it’s not alone -- at least 
optocoupler IL300 has the same issue.)

Cheers,
Jeff.



On 18 Sep 2018, at 15:10, John Beard  wrote:

Hi,

The rendering of unclosed polyline in symbols is different in GAL.

See the attached (standard libs potentiometer symbol) - in the legacy
canvas, the arrow doesn't have a missing lower side.

Is this a bug in GAL, or is it actually intended and the symbol is
wrong (but happened to work before by accident)?

Cheers,

John
On Tue, Sep 18, 2018 at 12:35 AM Jeff Young  wrote:

There’s a setting for that (Always show crosshairs).  You probably have it on 
in Pcbnew/Display Options but not in Eeschema/Display Options.


On 18 Sep 2018, at 00:30, Wayne Stambaugh  wrote:

I don't know if this is intentional or not but I noticed (at least on
windows) that the cursor is no longer displayed when the select tool is
active.  This is different than the old canvas where the cursor always
tracked the mouse point for all tools.

Cheers,

Wayne

On 9/17/2018 7:21 PM, Jeff Young wrote:

I pushed fixes for sheet pins and the cursor.  (It also removes a bunch of 
legacy grid and cursor colour stuff that is no longer needed.)

Cheers,
Jeff.



On 17 Sep 2018, at 20:03, mdoes...@xs4all.nl wrote:

I don't think I mailed the list, but also found another issue.

I noticed the sheet text is the same color as "notes", and not "sheet
label".

The cursor cross-hair is always black.

Otherwise it works fine for me on a quick test.

regards,

Mark.


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


___
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

<2018-09-18_150628_607x389_screenshot.png>


___
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] GAL canvas strategy - testers needed!

2018-09-19 Thread Rene Pöschl

Could you go into detail in how the library item is at fault? Or at 
least how it should be fixed?


On 19/09/2018 00:04, Jeff Young wrote:

I pushed John’s 3 patches along with one of my own which fixes the POT 
rendering.

(It is actually an error in the library item, but it’s not alone -- at least 
optocoupler IL300 has the same issue.)

Cheers,
Jeff.



On 18 Sep 2018, at 15:10, John Beard  wrote:

Hi,

The rendering of unclosed polyline in symbols is different in GAL.

See the attached (standard libs potentiometer symbol) - in the legacy
canvas, the arrow doesn't have a missing lower side.

Is this a bug in GAL, or is it actually intended and the symbol is
wrong (but happened to work before by accident)?

Cheers,

John
On Tue, Sep 18, 2018 at 12:35 AM Jeff Young  wrote:

There’s a setting for that (Always show crosshairs).  You probably have it on 
in Pcbnew/Display Options but not in Eeschema/Display Options.


On 18 Sep 2018, at 00:30, Wayne Stambaugh  wrote:

I don't know if this is intentional or not but I noticed (at least on
windows) that the cursor is no longer displayed when the select tool is
active.  This is different than the old canvas where the cursor always
tracked the mouse point for all tools.

Cheers,

Wayne

On 9/17/2018 7:21 PM, Jeff Young wrote:

I pushed fixes for sheet pins and the cursor.  (It also removes a bunch of 
legacy grid and cursor colour stuff that is no longer needed.)

Cheers,
Jeff.



On 17 Sep 2018, at 20:03, mdoes...@xs4all.nl wrote:

I don't think I mailed the list, but also found another issue.

I noticed the sheet text is the same color as "notes", and not "sheet
label".

The cursor cross-hair is always black.

Otherwise it works fine for me on a quick test.

regards,

Mark.


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


___
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

<2018-09-18_150628_607x389_screenshot.png>


___
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.0.1 release

2018-08-31 Thread Rene Pöschl


Hi,

I doubt we need to rename the lib. It might be better to declare it as 
deprecated (remove it from the default library table and place a note in 
the readme file)


A new library can definitely be created that is build around the ngspice 
features that come with version 5 (the pspice lib is quite old and not 
really build for that implementation)

The library name is best discussed over at github.

On 30/08/18 04:41, Evan Shultz wrote:
There is one library name I'm concerned about. See 
https://github.com/KiCad/kicad-symbols/issues/451#issuecomment-378701973. 
This would be a breaking change, but if it's important enough to 
change it's likely to only affect a small subset of all KiCad users.


It is "correct" to have a library with symbols for simulation named 
"pspice"? Should the library just be named "spice" or something more 
generic?


On Tue, Aug 28, 2018 at 11:07 AM Rene Pöschl <mailto:poesc...@gmail.com>> wrote:


Just to be sure i will ask the other librarians how strict they where
with our policy. (Sadly on the symbol side git is not of much help
so i
really need to rely on their word. I will also make some manual
checks.)

For the future we might think about getting check scripts
developed that
check for changes that would go too far. (To reduce the chance of
human
errors. Some maintainers might be tempted to include one small change
that is slightly across the line. If this happens with enough
frequency
then the sum of all changes could be too much.)

On 28/08/18 19:16, Wayne Stambaugh wrote:
    > On 8/28/2018 12:48 PM, Rene Pöschl wrote:
>> Right now we have no changes made that would break projects.
(That is
>> what i meant with "backwards compatibility" I know it is not
quite the
>> right term)
>>
>> Also i thought the cache lib plus rescue dialog should take care of
>> minor changes to symbols if the user does not want to update a
symbol
>> should it be changed.
> Yes, but I do not like depending on the cache.  It's too
fragile.  Once
> the new schematic file format is in place, this will no be an issue.
> Until then, I prefer to error on the side of caution given the cache
> issues we've had in the past.
>
>> It should not even be necessary as we do not allow changes to
symbol pin
>> numbers or positions. (Unless there was a mistake in the symbol.)
>>
>> As we did not include any of the wrongly scaled or wrongly
aligned 3d
>> models in the version 5 library there is also no danger of
damaging the
>> 3d rendering side. (There is a reason why the version 5 3d
model library
>> is a lot smaller compared to the version 4 3d model lib)
>>
>> We do neither allow changing any library names nor do we change
symbol,
>> footprint or 3d model names unless the original name was wrong
enough to
>> be in danger of being confused with a part different to the one
that the
>> object really represents.
>>
>> If you do not intend to include the library then i will lift
the ban on
>> major changes as it does not make any sense in that case to
hold back.
>> (The only reason would be to allow including bugfixes into
future kicad
>> bugfix releases. I would include updating to newer industry
standards as
>> bugfix. The later is the main work being continued on the footprint
>> side. We simply where not done with it with the v5 release but
it was
>> not bad enough to postpone the release.)
> I didn't realize you were keeping tight control of the library
commits.
>   I'm fine with these changes being added to 5.0.1. I would like
to keep
> the libraries relatively stable during the entire 5 stable
series.  For
> version 6, you can make whatever changes you see fit.
>
>>
>> On 28/08/18 18:30, Wayne Stambaugh wrote:
>>> I would be careful with any library improvements during stable
bug fix
>>> releases, particularly for symbol and 3d model libraries which are
>>> linked rather than embedded.  My preference would be to just
use the
>>> same libraries tagged for the 5.0.0 release to keep changes to
user
>>> designs to a minimum.  Users can always download the latest
libraries if
>>> they prefer the bleeding edge.
>>>
>>> On 8/28/2018 12:18 PM, Rene Pöschl wrote:
>>>> Is it planned to include a new version of the libraries as well?
>>>> Right now we ensure that the library is relatively stable so
i think the
>>>

Re: [Kicad-developers] Round trace bends

2018-08-31 Thread Rene Pöschl


Hi,

right now there is a discussion ongoing on the forum about that. Might 
have some useful information for you in there:

https://forum.kicad.info/t/status-on-curved-smooth-corners-in-traces/12287

On 31/08/18 09:14, Martin Laabs wrote:

Hi,

is there is any development for chamfer trace edges ongoing? I use KiCAD
frequently for RF designs and strongly miss the functionality to change
45°/90° bends to round ones.
If there is no development planned I would try it on my own or try to find
a student implementing it for us.

Thank you,
   Martin Laabs

___
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] New pad primitive shape: Chamfered roundrectangle

2018-08-31 Thread Rene Pöschl


Hi,

From reading the patch it seems this is for cases where you have 
exactly one corner to chamfer. Which is a nice addition for qfn footprints.


It would however be a bit more flexible if every corner is toggleable 
independently (so one could make pads with 1,2,3 or even 4 corners 
chamfered.)
That would allow this pad to also be used as paste only pad for exposed 
pads with thermal vias if one wants to avoid placing paste over vias.


On 30/08/18 20:33, jp charras wrote:

Hi Alls,

Attached a patch (against latest master version) that add a new pad
shape:  chamfered round rectangle.

It is now frequently used in footprints.

Although this kind of pad shape can be created by custom pad shapes, a
primitive pad shape has some advantages:
- more easy to edit
- support of thermal reliefs.

This is a feature especially for our library maintainers.

Please test.
Thanks.



___
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.0.1 release

2018-08-28 Thread Rene Pöschl

Just to be sure i will ask the other librarians how strict they where 
with our policy. (Sadly on the symbol side git is not of much help so i 
really need to rely on their word. I will also make some manual checks.)


For the future we might think about getting check scripts developed that 
check for changes that would go too far. (To reduce the chance of human 
errors. Some maintainers might be tempted to include one small change 
that is slightly across the line. If this happens with enough frequency 
then the sum of all changes could be too much.)


On 28/08/18 19:16, Wayne Stambaugh wrote:

On 8/28/2018 12:48 PM, Rene Pöschl wrote:

Right now we have no changes made that would break projects. (That is
what i meant with "backwards compatibility" I know it is not quite the
right term)

Also i thought the cache lib plus rescue dialog should take care of
minor changes to symbols if the user does not want to update a symbol
should it be changed.

Yes, but I do not like depending on the cache.  It's too fragile.  Once
the new schematic file format is in place, this will no be an issue.
Until then, I prefer to error on the side of caution given the cache
issues we've had in the past.


It should not even be necessary as we do not allow changes to symbol pin
numbers or positions. (Unless there was a mistake in the symbol.)

As we did not include any of the wrongly scaled or wrongly aligned 3d
models in the version 5 library there is also no danger of damaging the
3d rendering side. (There is a reason why the version 5 3d model library
is a lot smaller compared to the version 4 3d model lib)

We do neither allow changing any library names nor do we change symbol,
footprint or 3d model names unless the original name was wrong enough to
be in danger of being confused with a part different to the one that the
object really represents.

If you do not intend to include the library then i will lift the ban on
major changes as it does not make any sense in that case to hold back.
(The only reason would be to allow including bugfixes into future kicad
bugfix releases. I would include updating to newer industry standards as
bugfix. The later is the main work being continued on the footprint
side. We simply where not done with it with the v5 release but it was
not bad enough to postpone the release.)

I didn't realize you were keeping tight control of the library commits.
  I'm fine with these changes being added to 5.0.1.  I would like to keep
the libraries relatively stable during the entire 5 stable series.  For
version 6, you can make whatever changes you see fit.



On 28/08/18 18:30, Wayne Stambaugh wrote:

I would be careful with any library improvements during stable bug fix
releases, particularly for symbol and 3d model libraries which are
linked rather than embedded.  My preference would be to just use the
same libraries tagged for the 5.0.0 release to keep changes to user
designs to a minimum.  Users can always download the latest libraries if
they prefer the bleeding edge.

On 8/28/2018 12:18 PM, Rene Pöschl wrote:

Is it planned to include a new version of the libraries as well?
Right now we ensure that the library is relatively stable so i think the
improvements made since the v5 release can easily be included.
(We do not allow major changes that would break backward compatibility.
My plan is to use this rule at least till after the 5.1 release. Maybe
even until the new file format is well enough implemented to play around
with it in the official library.)

On 27/08/18 21:38, Wayne Stambaugh wrote:

I would like to get the 5.0.1 release out by the end of September if at
all possible.  There are still a few open bug reports which need to be
fixed before we can release this so if you can fix any of the ones that
do not already have an assignee[1], any help would be appreciated.  My
goal is to have all of the bug reports closed by 9/15 and give the
package devs a few weeks before making the release announcement.

Cheers,

Wayne

[1]: https://launchpad.net/kicad/+milestone/5.0.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


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

Re: [Kicad-developers] 5.0.1 release

2018-08-28 Thread Rene Pöschl

Right now we have no changes made that would break projects. (That is 
what i meant with "backwards compatibility" I know it is not quite the 
right term)


Also i thought the cache lib plus rescue dialog should take care of 
minor changes to symbols if the user does not want to update a symbol 
should it be changed.
It should not even be necessary as we do not allow changes to symbol pin 
numbers or positions. (Unless there was a mistake in the symbol.)


As we did not include any of the wrongly scaled or wrongly aligned 3d 
models in the version 5 library there is also no danger of damaging the 
3d rendering side. (There is a reason why the version 5 3d model library 
is a lot smaller compared to the version 4 3d model lib)


We do neither allow changing any library names nor do we change symbol, 
footprint or 3d model names unless the original name was wrong enough to 
be in danger of being confused with a part different to the one that the 
object really represents.


If you do not intend to include the library then i will lift the ban on 
major changes as it does not make any sense in that case to hold back. 
(The only reason would be to allow including bugfixes into future kicad 
bugfix releases. I would include updating to newer industry standards as 
bugfix. The later is the main work being continued on the footprint 
side. We simply where not done with it with the v5 release but it was 
not bad enough to postpone the release.)



On 28/08/18 18:30, Wayne Stambaugh wrote:

I would be careful with any library improvements during stable bug fix
releases, particularly for symbol and 3d model libraries which are
linked rather than embedded.  My preference would be to just use the
same libraries tagged for the 5.0.0 release to keep changes to user
designs to a minimum.  Users can always download the latest libraries if
they prefer the bleeding edge.

On 8/28/2018 12:18 PM, Rene Pöschl wrote:

Is it planned to include a new version of the libraries as well?
Right now we ensure that the library is relatively stable so i think the
improvements made since the v5 release can easily be included.
(We do not allow major changes that would break backward compatibility.
My plan is to use this rule at least till after the 5.1 release. Maybe
even until the new file format is well enough implemented to play around
with it in the official library.)

On 27/08/18 21:38, Wayne Stambaugh wrote:

I would like to get the 5.0.1 release out by the end of September if at
all possible.  There are still a few open bug reports which need to be
fixed before we can release this so if you can fix any of the ones that
do not already have an assignee[1], any help would be appreciated.  My
goal is to have all of the bug reports closed by 9/15 and give the
package devs a few weeks before making the release announcement.

Cheers,

Wayne

[1]: https://launchpad.net/kicad/+milestone/5.0.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



___
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.0.1 release

2018-08-28 Thread Rene Pöschl


Is it planned to include a new version of the libraries as well?
Right now we ensure that the library is relatively stable so i think the 
improvements made since the v5 release can easily be included.
(We do not allow major changes that would break backward compatibility. 
My plan is to use this rule at least till after the 5.1 release. Maybe 
even until the new file format is well enough implemented to play around 
with it in the official library.)


On 27/08/18 21:38, Wayne Stambaugh wrote:

I would like to get the 5.0.1 release out by the end of September if at
all possible.  There are still a few open bug reports which need to be
fixed before we can release this so if you can fix any of the ones that
do not already have an assignee[1], any help would be appreciated.  My
goal is to have all of the bug reports closed by 9/15 and give the
package devs a few weeks before making the release announcement.

Cheers,

Wayne

[1]: https://launchpad.net/kicad/+milestone/5.0.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




___
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] RFC: toolbar button support for action plugins

2018-08-24 Thread Rene Pöschl

One can however archive a repo. (We did that with all the old library 
repos.)


I am not sure if the automatic synchronization with the lauchpad code 
would still work for archived repos.


On 23/08/18 20:31, José Ignacio wrote:

Pull requests cannot be disabled on Github

On Thu, Aug 23, 2018 at 1:26 PM, Carsten Schoenert 
wrote:


Hello Wayne,

Am 23.08.18 um 20:01 schrieb Wayne Stambaugh:

We do not use github for kicad source development.  It is merely a
mirror for user convenience.  Please do not open any issues on github
for the kicad source mirror.

I'd suggest to disable all these kind of features on GitHub then and
mention this circumstance more in detail in the project description on GH.

--
Regards
Carsten Schoenert

___
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] The version string in the master branch

2018-07-25 Thread Rene Pöschl


Why not just use the date at which the nightly was compiled?

So something like dev-snapshot--mm-dd_g23849572
This is sortable and it should confuse nobody.

On 24/07/18 23:58, Eeli Kaikkonen wrote:



ti 24. heinäk. 2018 klo 22.59 Wayne Stambaugh (stambau...@gmail.com 
) kirjoitti:


 5.1-dev will confuse the package version
sorting when 5.1.0 is released.


Why do development packages (nightly builds or self-compiled) need to 
be sorted with release builds?


The most misleading strings are in the window bar and in the About 
KiCad dialog, and those texts aren't sorted anyways. Can't they be 
different than package file names? Windows nightly build package names 
don't have the version, nor do the ubuntu nightly packages.


I'm fine with Simon's proposal but
users will be no less confused by 5.0.0-452-g23849572 than by
6.0.0-rc1-xxx-commithash.


Based on my experience with linux distros and applications for about 
20 years and as a former open source developer I would like to 
disagree. But I know it doesn't count... I just want this sorted out 
because people will be confused for the next couple of years, and we 
who answer questions in the user forum have to clarify the situation 
every time.


Eeli Kaikkonen


___
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] Windows Builds

2018-07-23 Thread Rene Pöschl


On 23/07/18 05:27, Mark Roszko wrote:

Is it because the installer exe is huge?

That's because the footprint libraries are now part of the installers
and they are absolutely massive. (4GB uncompressed)


The whole repo (including git history) only has ~90MB
If any libs are to blame then it will be the 3d models. (6.5 GB 
including git history)


the installed files look fine to me though? The kiface files would be
hundreds of megs themselves if they had debug symbols but they are at
"normal" levels.
On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand  wrote:

Hi Devs-

I'm seeing some reports (lp:1783037) that indicate the Windows build may be 
compiled CMAKE_BUILD_TYPE=RelWithDebInfo instead of Release.

Can anyone confirm this?  Is there a reason to do this for Windows?

-Seth

___
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] KiCad 5 release announcement update

2018-07-22 Thread Rene Pöschl

I just noticed you sometimes use opengl/cairo and sometimes modern to 
reference the "modern toolset".


On 22/07/18 18:44, Wayne Stambaugh wrote:

I just pushed the updated version of the v5 release announcement[1].
Please let me know if you find any missing features.

Cheers,

Wayne

[1]:
https://github.com/KiCad/kicad-website/blob/master/content/blog/release-5.0.0.adoc

___
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] Stable 5 release.

2018-07-19 Thread Rene Pöschl

The library repos should now all be tagged. (Github had some server 
problems so it all took quite some time. I hope nothing got damaged 
because of that.)


On 19/07/18 10:49, Nick Østergaard wrote:

This sounds good. Thank you.
Den tor. 19. jul. 2018 kl. 10.43 skrev Rene Pöschl :

On 18/07/18 19:59, Carsten Schoenert wrote:

Am 18.07.18 um 19:55 schrieb Rene Pöschl:

I'm traveling the whole Saturday and Sunday to Debian DebCamp and
DebConf in Taiwan and working on packaging kicad-packages3d on a laptop
is PITA. So I'd like to this at home on a more powerful machine at home
latest on Friday afternoon.

Thanks!


By the way when giving deadlines stating your timezone might be
required. As you did not state one i choose to use CET summer time ;)

Argh, yes, a damn phone call has interrupted me while writing ...
But yes, CEST is the timezone I currently live. :-)


But if everything goes to plan i will tag the libs in a few hours anyway
giving you guys ample time.

Thanks!


Sadly i worked too long yesterday so i have been too tired to fully
check the libs.

I also have one or two PRs open that i want to check if they are correct
as they would fix some more minor issues. (Not a holdup but if they are
ready i would like to include them.)


So i will create the tags today in the evening. (Thursday 23:59 CEST
plus or minus two hours) Sorry about the delay.


___
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] Stable 5 release.

2018-07-19 Thread Rene Pöschl


On 18/07/18 19:59, Carsten Schoenert wrote:

Am 18.07.18 um 19:55 schrieb Rene Pöschl:

I'm traveling the whole Saturday and Sunday to Debian DebCamp and
DebConf in Taiwan and working on packaging kicad-packages3d on a laptop
is PITA. So I'd like to this at home on a more powerful machine at home
latest on Friday afternoon.

Thanks!


By the way when giving deadlines stating your timezone might be
required. As you did not state one i choose to use CET summer time ;)

Argh, yes, a damn phone call has interrupted me while writing ...
But yes, CEST is the timezone I currently live. :-)


But if everything goes to plan i will tag the libs in a few hours anyway
giving you guys ample time.

Thanks!



Sadly i worked too long yesterday so i have been too tired to fully 
check the libs.


I also have one or two PRs open that i want to check if they are correct 
as they would fix some more minor issues. (Not a holdup but if they are 
ready i would like to include them.)



So i will create the tags today in the evening. (Thursday 23:59 CEST 
plus or minus two hours) Sorry about the delay.



___
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] Stable 5 release.

2018-07-18 Thread Rene Pöschl


On 18/07/18 18:09, Carsten Schoenert wrote:

Hi,

Am 18.07.18 um 16:23 schrieb Nick Østergaard:

I probably didn't mention this clearly. It is also good for me if
everything is tagged on friday, I guess that is mostly about the libs,
as I will probably tag i18n and doc myself.

I'd like to see at least the packages3D repository is tagged latest on
Friday 11AM to 12PM so packagers could start here, the reason is simple ...


I am on vacation next week with no connectivity.

I'm traveling the whole Saturday and Sunday to Debian DebCamp and
DebConf in Taiwan and working on packaging kicad-packages3d on a laptop
is PITA. So I'd like to this at home on a more powerful machine at home
latest on Friday afternoon.

Thanks!



By the way when giving deadlines stating your timezone might be 
required. As you did not state one i choose to use CET summer time ;)



But if everything goes to plan i will tag the libs in a few hours anyway 
giving you guys ample time.



___
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] Questions on 6.0 eeschema file format

2018-07-16 Thread Rene Pöschl


My guess would be maintainability.
Having some way of sharing parts of different symbols with each other 
makes it way easier to manage large libs. (Nobody would be forced to use 
these features but they can make live easier for library maintainers. We 
could then for example provide a single nmos graphic that is then used 
in all nmos symbols of the official lib. Reducing the work for both 
contributors and maintainers.)


On 16/07/18 16:24, Tomasz Wlostowski wrote:

On 16/07/18 16:04, Jeff Young wrote:

Thinking more about it, we could probably auto-convert existing aliases to 
inheritance when we read them in.

Why do we need any inheritance at all? My only guess is to make Kicad
even more hackerish and difficult to understand.

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




___
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] kicad version and install location

2018-07-16 Thread Rene Pöschl

This only helps users who never had system environment variables set.
They overwrite the settings coming from the config folders. (So all
default windows installation are not helped with this.)

On 16/07/18 16:16, Nick Østergaard wrote:

Why does this need to be so complicated?

I think we could just rename the kicad config folder created and
searched by kicad from "kicad" to "kicad5" and be happy in the 5.x
branches.
Den man. 16. jul. 2018 kl. 15.11 skrev Bob Gustafson :

There is a tool which allows developers to quickly switch between different
versions of Ruby (and their associated gemsets).

Perhaps it could be used for KiCad? Or perhaps just some of RVM's ideas could
be adapted for KiCad

https://rvm.io/

On 07/15/2018 09:52 AM, Adam Wolf wrote:

I guess the fact that environment variables are tricky to set for graphical
applications for the Mac may be a blessing here :)

Should we try to package a macOS version that installs to /Applications/KiCad5
and /Library/Application Support/kicad?

Adam

On Sun, Jul 15, 2018, 2:41 AM Eeli Kaikkonen wrote:

There are some people in the user forum who have spent time with these v4->v5
problems, including me and Rene. The consensus about the environment variables
seems to be what Rene already said, that they should not (without explicit user
intervention) be set for the system, but from KiCad itself. Nick confirmed that
the current v5 installer won't set them by default. They are still a problem if
they have been set by v4 installer.

su 15. heinäk. 2018 klo 5.04 Strontium (strnty...@gmail.com) kirjoitti:

I honestly think each major revision of KiCad should be considered a NEW
program, installs to a new place has its configuration and libraries all
in a new location. Only Incremental updates 5.0 -> 5.1 should be
considered upgrades.

I agree. It's probable that many users will want to continue with v4 for old
projects but v5 for new, and in the future the same thing will be true for v5
vs. v6, because they break the file/project compatibility. But where the
compatibility is kept it's more likely to be considered as just an upgrade.

Kicad configuration isn't complex or onerous so if a user wants to bring
a Kicad4 config into Kicad5 or 6 or whatever, then they do that
themselves, otherwise after install Kicad5 is a fresh blank sheet with
no relationship to anything that happened on the users computer in
Kicad4. I am not familiar with the issues on Windows, but I would have
thought now this is mostly a packaging issue only??

I tried modifying the Windows installer, I only needed to replace some of "KiCad" strings
with "KiCad5" and it can install v5 alongside v4 independently. The only problem is the
configuration and the environment variables set by v4. They can be handled with a startup script.
See https://forum.kicad.info/t/does-v5-have-to-overwrite-on-install/11282 for some details.

I also agree if it can't work this way now on Windows, then its all a
bit late for V5, but maybe V6 can consider itself a new program distinct
from V5. This would also help with testing, because users could use V5
for daily work, but also easily install a V6 daily side by side.

All this could be done with the Windows installer, provided that a startup
script would be offered.

To make this all, at least the startup script, as simple as possible I would
suggest one (or three) small changes to KiCad (for 5.1, or even 5.0.1?). Add
command line options --config=/path/to/config and --ignore-env-vars. The former
is obvious and would override KICAD_CONFIG_HOME system environment variable.
The latter would make KiCad ignore all system environment variables and use the
current internal logic and the path settings UI instead. That way the old
variables could be left for v4 and the newer versions would be completely
independent if the command line switches were used. The command line switch for
the config path would be mostly for convenience. In Windows starting a program
with custom environment variables is tedious and error prone to write (see the
above mentioned thread). Command line switches are much easier.

It could also be possible to make --ignore-env-vars=true by default. Sharing
the environment variables would be a special case if the user wants that.

The general problem with using system environment variables is that they are
good for situations when there's only one version of a program on the system,
and/or several processes share the same variable values. Neither of them is
true for parallel installations of KiCad.

Eeli Kaikkonen
___
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 :

Re: [Kicad-developers] kicad version and install location

2018-07-14 Thread Rene Pöschl

Another idea would be to provide a package with version 4 libs. That way 
users can work with the new v5 features but do not need to worry about 
updating libraries.

On 14/07/18 09:29, Rene Pöschl wrote:

I get the feeling there is a bit more panic than need be.

One of the reasons is that the v4 installer on windows did set operating
system variables (environment variables) which can create problems when
updating. So it might be a good idea for the v5 installer to clean up
this mess. (or at least warn the user) These things should really be set
in the kicad config files via the kicad main window -> preferences ->
configure path. (If the reports on the forum are correct then
environment variables overwrite the settings of that dialog. And as the
v4 installer set them by default this can be a source of major confusion.)

Another reason for problems is that the sym lib table is created with a
new install and points to v5 libs but the fp-lib-table will still point
to the github v4 libraries. (The 3d models will be also from the v5
libs. Resulting in a mixed setup.) So an option to clean up the
fp-lib-table from within the installer or within kicad might help. Maybe
a "reset to factory settings" button within the library managers? (With
the warning that personal libs will need to be manually added after that
operation.)
Or at least some info for the user that if v4 was installed previously
the fp-lib-table needs updating. (Maybe a dialog with "do not show again
tickmak" that tells the user that if they had v4 previosly they need to
reset the fp-lib-table or they need to install the v4 lib and setup the
sym-lib-table accordingly.)

On 14/07/18 06:13, Adam Wolf wrote:

What options do we have?  Anything beyond "postpone V5" or "wait for
the next release"?

Could we rebrand the V5 release as a "technical preview" or something
that is suitable for experts (and new users, actually) and make V5.1 V5?

Adam

On Fri, Jul 13, 2018, 10:10 PM Mark Roszko mailto:mark.ros...@gmail.com>> wrote:

 Wayne,

 Guess going to suggest it should be a priority to version the config
 into folders.

 This is a user made chart on how to install kicad 5 which honestly is
 silly it has to even exist lol

https://kicad-info.s3-us-west-2.amazonaws.com/original/2X/d/d6143659e9237fc358588bed761ef3e557454cde.png

 On Wed, Jul 11, 2018 at 1:56 PM Wayne Stambaugh
 mailto:stambau...@gmail.com>> wrote:
 >
 > Mark,
 >
 > I agree with you in principal but this would require some major
 changes
 > to KiCad internally to handle the configuration data the
 "windows" way.
 > I really do not want to push the stable 5 release back any
 further than
 > it already has been.  I'm open to trying to accomplish this as
 part of
 > the 5.1 release if we can implement it soon enough to get some
 testing
 > on it.
 >
 > Cheers,
 >
 > Wayne
 >
 > On 7/8/2018 12:19 AM, Adam Wolf wrote:
 > > Let's postpone this discussion maybe until the 10th when Wayne
 is back
 > > at it.
 > >
 > > On Sat, Jul 7, 2018, 10:33 PM Mark Roszko
 mailto:mark.ros...@gmail.com>
 > > <mailto:mark.ros...@gmail.com <mailto:mark.ros...@gmail.com>>>
 wrote:
 > >
 > >     Hey guys,
 > >
 > >     So with 5.0 approaching theres something of an annoying
 problem on
 > >     windows (that many are complaining about). The install
 location!
 > >     Currently, even though you can install kicad into separate
 folders if
 > >     you wanted to, kicad still tries to write to the same
 appdata folder!
 > >
 > >     Why would you want both the new and old? Because if you
 want to tweak
 > >     a old design, you don't want to risk opening it in newer
 versions and
 > >     having unforseen bugs. New designs sure, you really want
 to use the
 > >     latest and greatest, but the old is a risk not worth taking,
 > >     especially in the commercial field ;)
 > >
 > >     Also there is a settings conflicts between 4.0 and 5.0
 sharing appdata.
 > >
 > >     I've seen some kicad forum "workarounds" where they use
 launcher
 > >     scripts that set KICAD_CONFIG_HOME each time. While it
 works, its
 > >     completely against the windows way :3
 > >
 > >
 > >     What I propose, is we patch KiCad a little to:
 > >
 > >     1. Write to appdata in a versioned manner (just minor and
 maybe
 > >     minor version)
 > >     C:\Users\%USERNAME%\AppData\Local\kicad 4.0\
 &g

Re: [Kicad-developers] kicad version and install location

2018-07-14 Thread Rene Pöschl

I get the feeling there is a bit more panic than need be.

One of the reasons is that the v4 installer on windows did set operating 
system variables (environment variables) which can create problems when 
updating. So it might be a good idea for the v5 installer to clean up 
this mess. (or at least warn the user) These things should really be set 
in the kicad config files via the kicad main window -> preferences -> 
configure path. (If the reports on the forum are correct then 
environment variables overwrite the settings of that dialog. And as the 
v4 installer set them by default this can be a source of major confusion.)

Another reason for problems is that the sym lib table is created with a 
new install and points to v5 libs but the fp-lib-table will still point 
to the github v4 libraries. (The 3d models will be also from the v5 
libs. Resulting in a mixed setup.) So an option to clean up the 
fp-lib-table from within the installer or within kicad might help. Maybe 
a "reset to factory settings" button within the library managers? (With 
the warning that personal libs will need to be manually added after that 
operation.)
Or at least some info for the user that if v4 was installed previously 
the fp-lib-table needs updating. (Maybe a dialog with "do not show again 
tickmak" that tells the user that if they had v4 previosly they need to 
reset the fp-lib-table or they need to install the v4 lib and setup the 
sym-lib-table accordingly.)

On 14/07/18 06:13, Adam Wolf wrote:
What options do we have?  Anything beyond "postpone V5" or "wait for 
the next release"?

Could we rebrand the V5 release as a "technical preview" or something 
that is suitable for experts (and new users, actually) and make V5.1 V5?

Adam

On Fri, Jul 13, 2018, 10:10 PM Mark Roszko > wrote:

Wayne,

Guess going to suggest it should be a priority to version the config
into folders.

This is a user made chart on how to install kicad 5 which honestly is
silly it has to even exist lol

https://kicad-info.s3-us-west-2.amazonaws.com/original/2X/d/d6143659e9237fc358588bed761ef3e557454cde.png

On Wed, Jul 11, 2018 at 1:56 PM Wayne Stambaugh
mailto:stambau...@gmail.com>> wrote:
>
> Mark,
>
> I agree with you in principal but this would require some major
changes
> to KiCad internally to handle the configuration data the
"windows" way.
> I really do not want to push the stable 5 release back any
further than
> it already has been.  I'm open to trying to accomplish this as
part of
> the 5.1 release if we can implement it soon enough to get some
testing
> on it.
>
> Cheers,
>
> Wayne
>
> On 7/8/2018 12:19 AM, Adam Wolf wrote:
> > Let's postpone this discussion maybe until the 10th when Wayne
is back
> > at it.
> >
> > On Sat, Jul 7, 2018, 10:33 PM Mark Roszko
mailto:mark.ros...@gmail.com>
> > >>
wrote:
> >
> >     Hey guys,
> >
> >     So with 5.0 approaching theres something of an annoying
problem on
> >     windows (that many are complaining about). The install
location!
> >     Currently, even though you can install kicad into separate
folders if
> >     you wanted to, kicad still tries to write to the same
appdata folder!
> >
> >     Why would you want both the new and old? Because if you
want to tweak
> >     a old design, you don't want to risk opening it in newer
versions and
> >     having unforseen bugs. New designs sure, you really want
to use the
> >     latest and greatest, but the old is a risk not worth taking,
> >     especially in the commercial field ;)
> >
> >     Also there is a settings conflicts between 4.0 and 5.0
sharing appdata.
> >
> >     I've seen some kicad forum "workarounds" where they use
launcher
> >     scripts that set KICAD_CONFIG_HOME each time. While it
works, its
> >     completely against the windows way :3
> >
> >
> >     What I propose, is we patch KiCad a little to:
> >
> >     1. Write to appdata in a versioned manner (just minor and
maybe
> >     minor version)
> >     C:\Users\%USERNAME%\AppData\Local\kicad 4.0\
> >     C:\Users\%USERNAME%\AppData\Local\kicad 5.0\
> >     C:\Users\%USERNAME%\AppData\Local\kicad 6.0\
> >
> >     2. Potentially prompt the user on first-start to copy
settings.
> >     (Maybe? Might be too much work for the final 5.0)
> >
> >     Then we patch the installer to follow the convention of:
> >     C:\Program Files\KiCad 4.0\
> >     C:\Program Files\KiCad 5.0\
> >     C:\Program Files\KiCad 6.0\
> >
> >     This would do what every other CAD and IDE does on Windows
> >     (versioned installs).
> >
> >     But what if people

Re: [Kicad-developers] Stable version 5 tagged.

2018-07-13 Thread Rene Pöschl

Now i am confused. Yesterday (or a bit before) you wrote something about 
the 20th of july.
I will look into tagging the library sometime tomorrow CET. (Too tired 
right now to check if everything is ok.)


On 13/07/18 16:15, Wayne Stambaugh wrote:

Queue up the Handel's "Hallelujah Chorus", the stable version 5 source
has been tagged and the source archive uploaded to Launchpad.  I see a
malted beverage in my immediate future.  Lets get the libraries, docs,
and translations tagged so our builders can start created release
packages.  Once most (all) of the packages are built, I will make the
official release announcement on the KiCad blog and the user forum.
Once again, I cannot thank all of you enough for your hard work and efforts.

I will create the 5.0 and 5.1 branches shortly.  Please refrain from
making any commits into the development branch until I create these
branches.  Also, keep in mind that bug fixes will have to be
cherry-picked from the development branch to the 5.0 and 5.1 branches so
it will be a bit of extra work to keep everything synced up.

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] Stable 5 release.

2018-07-12 Thread Rene Pöschl


On 12/07/18 16:20, jp charras wrote:

Le 12/07/2018 à 16:04, Rene Pöschl a écrit :

Sadly the old symbols are completely unusable in many modern circuits which use 
more then one power
supply for different parts of the circuit. Hidden power pins are not the way to 
go! The fix for this
bug must come from a different side then reintroducing hidden power pins.

These pins can be visible instead of hidden, just visible power and common to 
all units.


How well defined is the behavior of kicad if multiple of these 
duplicated pins are connected to different nets? (Is the behavior what 
users would expect?)


And additionally: A schematic just looks bad if you have unconnected 
pins on some units. (How can a user explain these unconnected pins their 
boss?)
Having the power pins as a separate unit is the way most other EDA tools 
go. This allows users to have power on a separate sheet and if the 
symbols are well defined one can even overlay the power unit with one of 
the other units. (Making this solution the most flexible option.)


That ERC does not check for non placed units is a drawback. As others 
already noticed most complex parts already suffer from this deficiency. 
(I am not prepared to make a hotfix on the symbol side to temporarily 
hide that deficiency in a limited subset of symbols.)


___
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] Stable 5 release.

2018-07-12 Thread Rene Pöschl

Sadly the old symbols are completely unusable in many modern circuits 
which use more then one power supply for different parts of the circuit. 
Hidden power pins are not the way to go! The fix for this bug must come 
from a different side then reintroducing hidden power pins.


On 12/07/18 13:46, Wayne Stambaugh wrote:

Rene,

Bug https://bugs.launchpad.net/kicad/+bug/1781290 may be an issue.  The
decision to separate symbol power pins as a separate symbol unit caused
this bug.  I didn't think about this when the changes to the symbol
libraries where made but it is going to cause issues for anyone trying
to create simulations.  I preferred the old symbols but it's not
something I feel strongly about but given that these changes caused this
issue we may need to rethink this decision or provide alternative
symbols for spice simulation.

Cheers,

Wayne

On 7/12/2018 5:36 AM, Rene Pöschl wrote:

The libs should be ready to go. We might still fix some minor things
till the release but we do not have any showstopper topics open.

On 11/07/18 20:49, Wayne Stambaugh wrote:

Are there any critical bugs remaining to be fixed for the stable 5
release?  I didn't see any thing outstanding but I may have missed
something while I was on vacation.  I'm going to create a 5.0.0
milestone for the last few remaining bugs and shoot for a 7/20 tag date
unless there are any more critical bugs lurking about.  I will also
create 5.0 and 5.1 branches.  If I tag on 7/20, I would like to make the
release announcement on 7/27.  Does anyone see any issues with these
dates

How do stand with our installers?  I saw the macos installer was making
some nice progress.

Are the doc devs, library devs, and translators (except for the recent
minor string changes) ready?

Is there anything else I'm missing?  I really would like to make these
dates.  I have an Olimex TERES laptop kit that I've been dying to play
around with but I know once I start on that, everything else will get
pushed to the back burner so I'm not going to start until version 5 is
released. :)

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] Stable 5 release.

2018-07-12 Thread Rene Pöschl

The libs should be ready to go. We might still fix some minor things 
till the release but we do not have any showstopper topics open.


On 11/07/18 20:49, Wayne Stambaugh wrote:

Are there any critical bugs remaining to be fixed for the stable 5
release?  I didn't see any thing outstanding but I may have missed
something while I was on vacation.  I'm going to create a 5.0.0
milestone for the last few remaining bugs and shoot for a 7/20 tag date
unless there are any more critical bugs lurking about.  I will also
create 5.0 and 5.1 branches.  If I tag on 7/20, I would like to make the
release announcement on 7/27.  Does anyone see any issues with these dates

How do stand with our installers?  I saw the macos installer was making
some nice progress.

Are the doc devs, library devs, and translators (except for the recent
minor string changes) ready?

Is there anything else I'm missing?  I really would like to make these
dates.  I have an Olimex TERES laptop kit that I've been dying to play
around with but I know once I start on that, everything else will get
pushed to the back burner so I'm not going to start until version 5 is
released. :)

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] rc3

2018-07-07 Thread Rene Pöschl

Strange i made the tag via the github web interface.

2018-07-04 17:45 GMT+01:00 Nick Østergaard :

> Hello Rene
>
> It looks like you didn't push the tag on templates, but I will just tag it
> then.
>
> Nick
>
> Den søn. 1. jul. 2018 kl. 00.34 skrev Rene Pöschl :
>
>> template repo is now tagged (sorry forgot about that one)
>>
>> On 30/06/18 23:56, Steven A. Falco wrote:
>> > Thank you!
>> >
>> > There are three repos not yet tagged with rc3 on github - two are
>> probably awaiting translation work: kicad-doc and kicad-i18n.  Also not
>> tagged: kicad-templates.  Once everything catches up to rc3, I will push
>> them to Fedora Rawhide.
>> >
>> >   Steve
>> >
>> > On 06/30/2018 08:50 AM, Wayne Stambaugh wrote:
>> >> I will do this when I tag rc3.  I think I have done it for every
>> release tag.
>> >>
>> >> On 06/30/2018 08:28 AM, Steven A. Falco wrote:
>> >>> If possible, it would also be great if a tar file for -rc3 could be
>> uploaded to launchpad, analogous to what was done for -rc2.
>> >>>
>> >>> We do have an -rc2 build in the official Fedora Rawhide now, and I'm
>> ready to step that up to -rc3 once available.
>> >>>
>> >>>  Thanks,
>> >>>  Steve
>> >>>
>> >>> On 06/29/2018 10:15 PM, Adam Wolf wrote:
>> >>>> Folks, enjoy your vacations.  We've all earned them! :)
>> >>>>
>> >>>> Wayne, if you could please announce on the list when you tag rc3,
>> that
>> >>>> would be awesome.
>> >>>>
>> >>>> Thanks!
>> >>>>
>> >>>> Adam
>> >>>> On Fri, Jun 29, 2018 at 7:27 PM Rene Pöschl 
>> wrote:
>> >>>>> What a coincidence. I will also be out of town for the next one and
>> a
>> >>>>> half weeks.
>> >>>>> As i can not guarantee that i will have internet access during this
>> time
>> >>>>> it might be necessary that somebody else tags the final kicad 5
>> library
>> >>>>> release.
>> >>>>> (I should be back at June the 10th late at night CET.)
>> >>>>>
>> >>>>> So i would suggest you make an issue one or two days before the
>> intended
>> >>>>> release date to notify the library team. (I already made one to warn
>> >>>>> them about this fact. See:
>> >>>>> https://github.com/KiCad/kicad-symbols/issues/712)
>> >>>>>
>> >>>>> On 30/06/18 01:59, Wayne Stambaugh wrote:
>> >>>>>> I think we are good to go with rc3.  I'm going to tag it tomorrow
>> unless
>> >>>>>> something comes up between now and then.  Once rc3 is tagged, I
>> would
>> >>>>>> like to hold off on any commits that are not critical bug fixes.
>> Since
>> >>>>>> I will be out of the country all next week for vacation, this will
>> give
>> >>>>>> users time to test rc3 builds.  If no critical issues arise during
>> this
>> >>>>>> week, I will tag 5.0.0 when I get back.  If this is an issue for
>> our
>> >>>>>> doc, library, or translation devs, please let me know.  Once our
>> 5.0.0
>> >>>>>> builds are ready to go, I will make the stable release
>> announcement and
>> >>>>>> proceed directly to the pub to celebrate.  We are getting close.
>> Thanks
>> >>>>>> again for all of your 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
&g

Re: [Kicad-developers] rc3

2018-06-30 Thread Rene Pöschl


template repo is now tagged (sorry forgot about that one)

On 30/06/18 23:56, Steven A. Falco wrote:

Thank you!

There are three repos not yet tagged with rc3 on github - two are probably 
awaiting translation work: kicad-doc and kicad-i18n.  Also not tagged: 
kicad-templates.  Once everything catches up to rc3, I will push them to Fedora 
Rawhide.

Steve

On 06/30/2018 08:50 AM, Wayne Stambaugh wrote:

I will do this when I tag rc3.  I think I have done it for every release tag.

On 06/30/2018 08:28 AM, Steven A. Falco wrote:

If possible, it would also be great if a tar file for -rc3 could be uploaded to 
launchpad, analogous to what was done for -rc2.

We do have an -rc2 build in the official Fedora Rawhide now, and I'm ready to 
step that up to -rc3 once available.

 Thanks,
 Steve

On 06/29/2018 10:15 PM, Adam Wolf wrote:

Folks, enjoy your vacations.  We've all earned them! :)

Wayne, if you could please announce on the list when you tag rc3, that
would be awesome.

Thanks!

Adam
On Fri, Jun 29, 2018 at 7:27 PM Rene Pöschl  wrote:

What a coincidence. I will also be out of town for the next one and a
half weeks.
As i can not guarantee that i will have internet access during this time
it might be necessary that somebody else tags the final kicad 5 library
release.
(I should be back at June the 10th late at night CET.)

So i would suggest you make an issue one or two days before the intended
release date to notify the library team. (I already made one to warn
them about this fact. See:
https://github.com/KiCad/kicad-symbols/issues/712)

On 30/06/18 01:59, Wayne Stambaugh wrote:

I think we are good to go with rc3.  I'm going to tag it tomorrow unless
something comes up between now and then.  Once rc3 is tagged, I would
like to hold off on any commits that are not critical bug fixes.  Since
I will be out of the country all next week for vacation, this will give
users time to test rc3 builds.  If no critical issues arise during this
week, I will tag 5.0.0 when I get back.  If this is an issue for our
doc, library, or translation devs, please let me know.  Once our 5.0.0
builds are ready to go, I will make the stable release announcement and
proceed directly to the pub to celebrate.  We are getting close.  Thanks
again for all of your 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


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

2018-06-29 Thread Rene Pöschl

What a coincidence. I will also be out of town for the next one and a 
half weeks.
As i can not guarantee that i will have internet access during this time 
it might be necessary that somebody else tags the final kicad 5 library 
release.

(I should be back at June the 10th late at night CET.)

So i would suggest you make an issue one or two days before the intended 
release date to notify the library team. (I already made one to warn 
them about this fact. See: 
https://github.com/KiCad/kicad-symbols/issues/712)


On 30/06/18 01:59, Wayne Stambaugh wrote:

I think we are good to go with rc3.  I'm going to tag it tomorrow unless
something comes up between now and then.  Once rc3 is tagged, I would
like to hold off on any commits that are not critical bug fixes.  Since
I will be out of the country all next week for vacation, this will give
users time to test rc3 builds.  If no critical issues arise during this
week, I will tag 5.0.0 when I get back.  If this is an issue for our
doc, library, or translation devs, please let me know.  Once our 5.0.0
builds are ready to go, I will make the stable release announcement and
proceed directly to the pub to celebrate.  We are getting close.  Thanks
again for all of your 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

Re: [Kicad-developers] rc3

2018-06-24 Thread Rene Pöschl

I just added the rc3 tag to the library. (A bit later than promised. 
Hope this is still ok.)


On 24/06/18 03:12, Rene Pöschl wrote:

I can add the rc3 tag to the library repos sometime Sunday afternoon.
(central European time)
A few minor corrections would still be nice to get into v5 but we do not
have any deal-breaker that would merit postponing v5 from our side.

On 23/06/18 17:15, Wayne Stambaugh wrote:

Let's try to get rc3 by tomorrow.  That will give us almost a week of
testing before the 30th.  If no major issues arise between now and then,
I will tag 5.0.0 on the 30th.  I will be traveling for vacation the
following week so this will give everyone time to get everything ready
for the stable 5 release.  I will make the release announcement after I
get back from vacation once everything is ready to go.  Thank you
everyone for your continued efforts and support of the KiCad project.

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] rc3

2018-06-23 Thread Rene Pöschl

I can add the rc3 tag to the library repos sometime Sunday afternoon. 
(central European time)
A few minor corrections would still be nice to get into v5 but we do not 
have any deal-breaker that would merit postponing v5 from our side.


On 23/06/18 17:15, Wayne Stambaugh wrote:

Let's try to get rc3 by tomorrow.  That will give us almost a week of
testing before the 30th.  If no major issues arise between now and then,
I will tag 5.0.0 on the 30th.  I will be traveling for vacation the
following week so this will give everyone time to get everything ready
for the stable 5 release.  I will make the release announcement after I
get back from vacation once everything is ready to go.  Thank you
everyone for your continued efforts and support of the KiCad project.

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

1 2 >

1 - 100 of 155 matches

Mail list logo