Re: [Kicad-developers] V7 Python API Development
Is there anything to make public already? I have been playing with the current SWIG API, I would like to see the new API even if it's not ready yet. I could for example look at the pcbnew API to see how it compares with the current one, and see if I can do some documentation or a small tutorial. Eeli Kaikkonen On Fri, May 20, 2022 at 6:59 PM Seth Hillbrand wrote: > Hi Oliver- > > I'm still working on backend stuff to synchronize eeschema/pcbnew. > > Is there something in particular that you'd like to work on? Maybe I can > spin off a section for you. > > Seth > > On Fri, May 20, 2022 at 5:55 AM Oliver Holt wrote: > >> Hello all, >> >> I have seen a few posts regarding progress on implementing the new Python >> API (moving away from SWIG) on the forum and here on the mailing list but I >> cannot find anything formal about it on Gitlab. It sounds like there is >> some kind of, currently private, specification and there is (or at least >> was in December) intent to have it ready to include in v7.0 so I presume >> the necessary dev work is ongoing? >> >> Please see: >> https://lists.launchpad.net/kicad-developers/msg44066.html >> https://forum.kicad.info/t/python-api-development-discussion/23604/6 >> https://forum.kicad.info/t/python-api-status-in-v6/31929/ >> >> I am interested in getting involved in development in this area, in >> Python and/or C++, I just need an entry point. Can anyone point me in the >> direction of relevant issues, branches, documentation etc? >> >> Thanks, >> >> Oliver >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > > -- > [image: KiCad Services Corporation Logo] > Seth Hillbrand > *Lead Developer* > +1-530-302-5483 > Long Beach, CA > www.kipro-pcb.comi...@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
Re: [Kicad-developers] V6 documentation
It looks like this is a sensitive topic, and I now understand the packagers feel pressure and that they aren't appreciated enough. That wasn't my intention and I didn't want to hint or imply anything negative towards anyone. On the contrary, I know packaging isn't easy (I have looked at the packaging systems and given up) and appreciate the work. There seems to be more than one subjects going on, packaging is only one. The more fundamental is the need or lack of need for offline documentation, and if there is need, how is that solved. This also seems to be a sensitive topic. Personally I don't see why documentation should be packaged at all for distros if it can be downloaded anyway. I mentioned PCM, not because I would think it would be the best solution, but just for brainstorming (however, this topic seems to be too sensitive for brainstorming). It would just be a natural way to download KiCad documentation because other content is downloaded with it, too, and it would be readily available to the end users. An extra benefit would be that it would automatically go to a location known to KiCad, so if KiCad tries to find local documentation, it would be in the right place. Eeli Kaikkonen On Thu, Jan 20, 2022 at 5:59 PM Carsten Schoenert wrote: > > Hi, > > Am 19.01.22 um 23:18 schrieb Eeli Kaikkonen: > > > I don't understand why this discussion is so difficult to understand. > > sorry but I don't understand what problem you are trying to solve! > There is no problem within the Linux world and their distros to provide > packaged documentation, there is no need to develop another new way for > distributing documentation. > > > I agree with Jon and don't see any problem for distros. As far as I > > can see the point is that the documentation package version shouldn't > > be logically dependent on the KiCad packages or vice versa. You can > > have package kicad-v6.0-documentation version, say, 20222001 [date], > > can't you? You don't have to give it the version number 6.0.x. If a > > git tag is needed for technical reasons, let's have automatic tagging > > which adds a tag each day. > > To use the words from Marco... > > "Are you serious?" > > I'm getting a bit disappointed because I become the feeling that you are > somehow ignorant about the arguments of at least two main packagers of > KiCad within Linux. And I really think that you want to solve problems > on the wrong corner. > > THE MAIN PROBLEM ARE THE OUTDATED DOCUMENTS! > NOT THE WAY THEY ARE DISTRIBUTED. > > So it's better to think about how the documentation can be updated and > how a ongoing process can be introduced to make contributions easier > with a low barrier for one time contributors. > > And as Marco did explain, we need to fix the tools if there is something > missed at the end. Be friendly to the distributions, please do not try > to ignore them. They are part of the FOSS ecosystem KiCad is depending on. > Do not try to "solve" things were distributions already have a process > for and established rules for that. > > I stop now reading any new post on this topic. > > -- > Regards > Carsten > > ___ > Mailing list: https://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] V6 documentation
On Wed, Jan 19, 2022 at 9:13 PM Steven A. Falco wrote: > It would still be helpful if the doc repo could be tagged at the same point > that everything else is tagged, because every single Fedora package needs a > correct version in its name. For example, it would be very strange (perhaps > "illegal") to package something called the 6.0.1 doc that came from some > random SHA in an untagged tree. I don't understand why this discussion is so difficult to understand. I agree with Jon and don't see any problem for distros. As far as I can see the point is that the documentation package version shouldn't be logically dependent on the KiCad packages or vice versa. You can have package kicad-v6.0-documentation version, say, 20222001 [date], can't you? You don't have to give it the version number 6.0.x. If a git tag is needed for technical reasons, let's have automatic tagging which adds a tag each day. 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
Re: [Kicad-developers] V6 documentation
On Wed, Jan 19, 2022 at 6:38 PM Jon Evans wrote: > > What I would propose to improve the situation is: Here's a wild idea: why not make the documentation bundle(s) downloadable with the PCM? 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
Re: [Kicad-developers] New lead developer announcement
Congratulations and thank you very much to Mikolaj! And also to those who have joined earlier who I haven't congratulated. There have been some between v5 and v6. On Fri, Nov 19, 2021 at 4:15 PM Wayne Stambaugh wrote: > > I am happy to announce that Mikolaj Wielgus has accepted an invitation > to become a member of the KiCad lead development team. Mikolaj has made > some significant contributions to the KiCad project and I look forward > to his contributions as lead developer. Please join me in > congratulating Mikolaj in his new role. 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
Re: [Kicad-developers] Question about attributes and complex hierarchies
On Wed, Nov 17, 2021 at 10:40 AM Lorenzo Marcantonio
wrote:
> Since there is no population variation for schematics (hint hint :D)
https://gitlab.com/kicad/code/kicad/-/issues/2131 (hint hint :D)
> Is there already some plan or idea to handle this?
I wonder if you could utilize sheet variables (text/string replacement
variables) which is a new feature. You can add a Field to sheet
instance Properties and then use it with ${} syntax in symbol fields.
It resolves the variable for the generated BOM, too.
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
Re: [Kicad-developers] Python 3 now required
On Mon, Jun 14, 2021 at 11:59 PM Kevin Cozens wrote: > Not that simple. I tried passing -DPYTHON_EXECUTABLE=python3 and it still > only finds 2.7. I tried it without the -D part. I have also tried it with > and without a full path to python3. I even tried putting PYTHON_EXECUTABLE > before 'cmake' on the line. > That's where cmake UIs come handy. Try ccmake or cmake-gui (they are both official user interfaces for cmake). You don't need to know the variables beforehand, you can see them all in the UI. I already forgot what those problematic variables were but it was easy to find them because they pointed to python 2. 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
Re: [Kicad-developers] Python 3 now required
Great work, thanks! It's also a big relief that plugin developers don't need to try to support 2 and 3. On Fri, Jun 4, 2021 at 8:36 PM Seth Hillbrand wrote: > > The current minimum Python version is 3.7 (due to a module test call we > use) but we are looking at potentially supporting Python 3.6 if we can > handle dynamic reloads. > > CMake test is for >= 3.6, so this is a problem when someone has 3.6 (as already happened at least once; see https://forum.kicad.info/t/kicad-build-error-netlist/29597/12?u=eelik). Should the requirement be changed? 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
Re: [Kicad-developers] OCE vs. OCC default build flag
See https://gitlab.com/eelik-kicad/kicad/-/wikis/How-to-build-KiCad-on-Ubuntu-(the-easy-way) The reason I started this thread was that I saw that practically all packages were using OCC already, so it's available. On Tue, May 18, 2021 at 6:04 PM Kevin Cozens wrote: > > How will this affect those of us who build KiCad from source? I have liboce > packages installed which provide OCE. If you change to OCC what package(s) > will I need then? The distro I use (Linux Mint) has libocct (Open CASCADE > Technology) packages. Is that what I will need or will I have to find > another source (ie. a PPA) for the support libraries? > 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
Re: [Kicad-developers] OCE vs. OCC default build flag
On Mon, May 17, 2021 at 5:14 PM Carsten Schoenert wrote: > I'm using mostly the explicit set up of build options and do not rely on > used default values, so the Debian packages using OCC for more than a > year. And this also for backported versions. I was unsure about Debian because I didn't document my failure to build KiCad (with phoenix) on it. For other distros, I'm 100% sure about Ubuntu (and Kubuntu), Mint, Fedora, Arch and Manjaro, the latest release versions of those distros. Also openSUSE Tumbleweed (the rolling release). None of them drew OCE as a dependency for the available KiCad 5.99 (or 5.1 if 5.99 wasn't available) package, they all use OCC. This covers all of the supported distros. Also all of the distros in the Download page except gentoo. Flatpak seems to use explicit cmake flags and also dowloads and compiles the used OCC/OCE version explicitly, so it's not affected. > I've configured the build of the current 5.99 version for experimental > since a few weeks, and wxpython 4.0 is used here also like done for the > current stable version since a long time. Or I miss your point. I already forgot the details, but it was Buster for which I couldn't install the build dependencies which would make it possible to compile 5.99 with wxPhoenix. There was something strange about it. But that's offtopic. 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
Re: [Kicad-developers] OCE vs. OCC default build flag
As far as I can tell, Ubuntu and all derivatives, Fedora, openSUSE, Debian (if I remember correctly), Arch and Manjaro already use OCC so that the latest available KiCad 5.99 (and even 5.1) packages for the latest available distro versions use OCC. Only gentoo KiCad 5.1 seems to use OCE. Because the flags themselves aren't changed by this, only the default, most of the packages don't necessarily need any changes. Changing the python flags (soon, I hope?) will have bigger consequences. I couldn't even find a way to compile 5.99 for Debian testing with phoenix. On Mon, May 17, 2021 at 3:19 PM Wayne Stambaugh wrote: > > How does this change affect our package devs? I'm guessing they would > have to make some package dependencies changes if OCC is going to be the > default. I would like to hear from them before we make OCC the default. > > We will also have to update the developer docs to reflect this change. > > 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
[Kicad-developers] OCE vs. OCC default build flag
While I was writing Linux and several distro specific build instructions ( https://gitlab.com/eelik-kicad/kicad/-/wikis/How-to-build-KiCad-on-Linux-(the-easy-way) , discussion in https://forum.kicad.info/t/build-from-source-simple-instructions-to-compile-kicad-for-some-linux-distributions/28982 ) I noticed that all distros I tried have OCC instead of OCE. Should the default build flag be changed to be OCC instead of OCE? 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
Re: [Kicad-developers] Compiling KiCAD 5.99 on Raspberry Pi (400)
On Thu, Apr 29, 2021 at 1:05 AM Knochi.de wrote: > > I’m using the standard Raspberry OS which is “raspian buster” > libcurl4-gnutls-dev was the correct pick. So continuing with resolving > dependencies for now. Nick reminded us that on .deb based systems there are often library packages with -dev in their name which are needed for building. They aren't visible in the binary package dependencies, but you can actually see all build time dependencies for KiCad in http://deb.debian.org/debian/pool/main/k/kicad/kicad_5.0.2+dfsg1-1.dsc (or http://deb.debian.org/debian/pool/main/k/kicad/kicad_5.1.9+dfsg1-1~bpo10+1.dsc in backports) so there's no need to guess. Whether all of them are available for the raspberry version of Debian, I don't know. These sources are authoritative because the Debian packaging system builds the KiCad packages using these dependencies. At least no build time dependency can be missing from them, although it's theoretically possible that some of them can't be satisfied on some port of the distro. > Next is how to apply patches. From my understanding I need to apply patches > to certain files, plus the documentation says “platform dependent patches” so > e.g. for boost I don’t need the “mingw” stuff. > Do I need to apply them at all? They are very old. I really don't know how these patches work or how they are applied, but there shouldn't be need to apply them manually. I have built KiCad on about 6 different Linux distros recently and haven't needed to patch anything. 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
Re: [Kicad-developers] Compiling KiCAD 5.99 on Raspberry Pi (400)
You can also check the dependencies in https://packages.debian.org/buster/kicad (or https://packages.debian.org/buster-backports/kicad.) On Wed, Apr 28, 2021 at 6:27 PM David Knochenhauer wrote: > > Now I'm struggling with CURL.. I'm not sure which library to install. > Libcurl4 and libcurl3-gnutls are preinstalled but obviously neither of them > is the needed. 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
[Kicad-developers] schematic.cpp includes sim/ngspice.h and consequently sharedspice.h
I have disabled ngspice in cmake settings but in a recent commit by Wayne #include , which in turn includes ngspice/sharedspice.h, was added to schematic.cpp which makes compilation fail apparently because I don't have ngspice at all. 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
[Kicad-developers] canvas_type configuration in different subprograms in 5.99?
I quickly tried to set the canvas type to Accelerated on all subprograms. Then when I grep the configuration files I get: gerbview.json:"canvas_type": 1, libedit.json:"canvas_type": 2, pcb_calculator.json:"canvas_type": 2, 3d_viewer.json:"canvas_type": 2, bitmap2component.json:"canvas_type": 2, eeschema.json:"canvas_type": 1, cvpcb.json:"canvas_type": 2, kicad.json:"canvas_type": 2, pcbnew.json:"canvas_type": 1, symbol_editor.json:"canvas_type": 2, fpedit.json:"canvas_type": 2, pl_editor.json: "canvas_type": 1, Does it actually mean the same thing in all these files, and why the inconsistency? 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
Re: [Kicad-developers] Nightly Ubuntu packages - 3d models path problem
I think the situation is in flux, see
https://forum.kicad.info/t/system-variables-and-windows-nightly-installer-change/26735/17?u=eelik
.
On Tue, Jan 5, 2021 at 6:34 PM Mark Robson wrote:
> Hi,
>
> I've been testing the amazing nightly builds on Ubuntu 20 for some time
> now - but now the 3d models are gone on newly placed footprints.
>
> I think this is probably due to the model path changing, for example
>
> A previously placed 0603 capacitor has 3d model path:
>
> ${KISYS3DMOD}/Capacitor_SMD.3dshapes/C_0603_1608Metric.wrl
>
> Which works ok, but a newly placed 0603 has
>
> ${KICAD6_3DMODEL_DIR}/Capacitor_SMD.3dshapes/C_0603_1608Metric.wrl
>
> So it seems it's a change to this variable name KICAD6_3DMODEL_DIR
>
> Is this a packaging problem? Or do I need to reset some settings in my
> setup?
>
> I didn't report this as a bug because I don't think it's the Kicad code's
> fault.
>
> Any idea how I can fix it or who I need to tell?
>
> 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
Re: [Kicad-developers] 3D-Viewer: limit scale to positive values?
On Tue, Sep 29, 2020 at 9:54 PM Jon Evans wrote: > Note Altium's solution to the use case of needing "easy basic models": it > can actually generate the models built-in. > > You just specify some parameters and it will generate cylinders, spheres, > or extruded shapes from a 2D contour. > > If we could add this kind of feature in the future, maybe we would not > need to support "stretching" generic models, as we could just generate the > right generic model parametrically (without "stretching" a source model) > > It has already been marked as opinion :) https://gitlab.com/kicad/code/kicad/-/issues/3453 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
[Kicad-developers] Some linker errors, and question about qa
I get some linker errors:
[3/3] Linking CXX executable qa/drc_proto/drc_proto
FAILED: qa/drc_proto/drc_proto
...
/usr/bin/ld:
qa/drc_proto/CMakeFiles/drc_proto.dir/__/pcbnew_utils/board_file_utils.cpp.o:
in function `KI_TEST::DumpBoardToFile(BOARD&,
std::__cxx11::basic_string,
std::allocator > const&)':
/work/ohjelmointi/kicad/kicad-master/qa/pcbnew_utils/board_file_utils.cpp:40:
undefined reference to `PCB_IO::PCB_IO(int)'
/usr/bin/ld:
/work/ohjelmointi/kicad/kicad-master/qa/pcbnew_utils/board_file_utils.cpp:41:
undefined reference to `PCB_IO::Save(wxString const&, BOARD*, PROPERTIES
const*)'
/usr/bin/ld:
/work/ohjelmointi/kicad/kicad-master/qa/pcbnew_utils/board_file_utils.cpp:40:
undefined reference to `PCB_IO::~PCB_IO()'
/usr/bin/ld:
/work/ohjelmointi/kicad/kicad-master/qa/pcbnew_utils/board_file_utils.cpp:40:
undefined reference to `PCB_IO::~PCB_IO()'
/usr/bin/ld: common/libpcbcommon.a(io_mgr.cpp.o): in function
`{lambda()#2}::operator()() const':
/work/ohjelmointi/kicad/kicad-master/pcbnew/io_mgr.cpp:209: undefined
reference to `PCB_IO::PCB_IO(int)'
What might be the reason?
BTW, why does it link anything under qa at all while I don't have
KICAD_BUILD_QA_TESTS enabled? I'm not sure what the qa subdir should do,
but I don't think I need or want it.
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
Re: [Kicad-developers] eeschema unusable for two or three days
On Sat, Sep 12, 2020 at 2:00 PM BERTRAND Joël wrote: > > Recently, I have seen that wire tool in eeschema is unusable. > Start and > end point of wires are automatically connected to objects (other lines, > other wires...). > Actually the same bugs pcbnew, too. Try drawing some graphic lines. 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
[Kicad-developers] Compilation doesn't find class_via.h
Compilation fails today: [4/14] Building CXX object qa/drc_proto/CMakeFiles/drc_proto.dir/drc_test_provider_annulus.cpp.o FAILED: qa/drc_proto/CMakeFiles/drc_proto.dir/drc_test_provider_annulus.cpp.o /work/ohjelmointi/kicad/kicad-master/qa/drc_proto/drc_test_provider_annulus.cpp:26:10: fatal error: class_via.h: No such file or directory 26 | #include | ^ 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
Re: [Kicad-developers] Something wrong with Windows nightly builds (1 Aug)?
Nah... Application: KiCad Version: (5.99.0-2477-g0c774aa16-dirty), release build Libraries: wxWidgets 3.0.4 libcurl/7.66.0 OpenSSL/1.1.1d (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.39.2 Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW Build Info: *Date: Jul 30 2020 08:59:53* On Sun, Aug 2, 2020 at 1:21 AM Ian McInerney wrote: > No, it isn't a build error that is causing it. If you look at the status > page showing the pipeline results ( > https://jenkins.simonrichter.eu/view/KiCad%20Status/job/windows-kicad-msys2-pipeline/), > you'll see the builds finish successfully. > > Eeli, can you try downloading the most recent lite build and see which > version string is being reported by the program itself? I downloaded the > log from one of the runs on July 31, and it seems to have downloaded the > most recent commit as of that time and was supposed to have built a package > with "r16610.61c817377". Perhaps that is just contained in the most > recently uploaded package for some reason? > > My guess is the packaging script can't handle the "-dirty" being appended > to the KiCad build string. It is being marked as dirty right now due to > https://gitlab.com/kicad/code/kicad/-/issues/5013, and the fix for it is > in https://gitlab.com/kicad/code/kicad/-/merge_requests/318, but I can't > apply the fix until all packaging setups are updated to contain lemon (so I > now know that Windows has it, but OSX and many Linux ones don't). > > -Ian > > On Sat, Aug 1, 2020 at 9:40 PM Roberto Fernández Bautista < > roberto.fer@gmail.com> wrote: > >> Hi Eeli, >> >> I assume this was due to what I highlighted in my previous email ( >> https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg38706.html). >> The build was broken for Windows. >> >> I submitted a merge request ( >> https://gitlab.com/kicad/code/kicad/-/merge_requests/322) which was >> merged last night, hence you are only seeing it today. >> >> Thanks. >> >> Roberto. >> >> >> On Sat, 1 Aug 2020, 14:04 Eeli Kaikkonen, >> wrote: >> >>> [image: image.png] >>> >>> Something wrong with the Windows nightly builds? >>> >>> The commit 0c77 is from 30 July, I remember seeing that same commit >>> dated to 30 and I downloaded it then (the link has different color) and I >>> have it installed, but now the date is 1 Aug. There seems to be no newer >>> nightly build available, I think there should be one or two of them. >>> >>> 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 >> > ___ Mailing list: https://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] Something wrong with Windows nightly builds (1 Aug)?
[image: image.png] Something wrong with the Windows nightly builds? The commit 0c77 is from 30 July, I remember seeing that same commit dated to 30 and I downloaded it then (the link has different color) and I have it installed, but now the date is 1 Aug. There seems to be no newer nightly build available, I think there should be one or two of them. 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
Re: [Kicad-developers] Castellated edge support in v5.99
On Thu, Jul 23, 2020 at 3:42 PM jp charras wrote: > There is (since 6 months) some pad fabrication properties (see pad > properties dialog), only enabled by the advanced config. > > I just enabled this option (removed from the advanced config option.) > > Castellated pad is one of these abrication properties. > > These properties are stored in Gerber files, so they need to be a pad > property. > > Currently, DRC does not use these properties (in fact only Castellated > pad can be used in DRC). > This being the case, would it be reasonable to make it used in DRC? Ignoring pad/edge clearance would probably be easy, but I would like to see it made even better for the user. [image: image.png] I want to be able to route tracks and fill zones. Basically there should be no violation as long as the copper is completely inside the pad, even though it's close to the edge which is outside the pad. 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
[Kicad-developers] Castellated edge support in v5.99
KiCad doesn't have any specific support for castellations, and doesn't need anything special because it's basically PTH pad on the edge. It works so-and-so in 5.1: it doesn't complain about pad copper which is too close to the edge, and it's even possible to add SMD pads to the footprint so that it's possible to route without DRC problems. (See https://forum.kicad.info/t/how-to-design-castellated-pins/23945 .) However, this doesn't work so well in 5.99. DRC check handles pads like other copper and the only way to turn off errors is to ignore "Board edge clearance violations" altogether. We could of course have some specific support for castellation, like marking footprints as castellation and then allowing copper and routing there. But I doubt this is what the team wants because it's a special case which can be solved otherwise (like local neckdown for tight IC's). It' not clear to me how the local rules is going to be implemented. Will there be some kind of graphical polygon where I can define the rules with the DRC Rules editor? That would work for me if it's made easy enough. I thought about being able to add certain kind of predefined rules without a need to write them. For example * Add a box around the area * Open the context menu on the box * It reveals menu item "Add Rules" * -> "Castellation" Then it would allow the pads on the edge, and also routing and zone filling fully without caring about the edge line inside the pad boundaries (the rule system must of course support this!). On the other hand, castellation is pretty much a de facto standard and it wouldn't hurt to support it as a special case. Even allowing THT pads on an edge where the hole is on the edge, too, would be enough to allow the same workflow than in 5.1. Splitting board edge violations into two, pad and other, would also work. I never want to violate with traces, but sometimes in a tight design I have placed pads very near to the edge and trusted that the manufacturer removes copper if they want and there's still enough room for the component. This would also allow non-castellated edge plating with a footprint (which must otherwise be handled with local rules, like castellation). Finally, being able to select a bunch of violation markers - for example for one footprint - and excluding them permanently could also work. 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
Re: [Kicad-developers] DRC ladybug symbol origin
Do an image google search for "debug icon ladybug" and you'll see quite many debugging related ladybugs. I think it has been used as a symbol because it's easily recognizable and cute. See https://en.wikipedia.org/wiki/Bug_(engineering). On Fri, Jul 17, 2020 at 6:16 AM Brian Piccioni wrote: > > I'm guessing because it finds bugs? > > On 2020-07-16 11:14 p.m., Ben Ellis wrote: > > Hi all, > > Does anyone know why the DRC symbol is a ladybug? Asking for a friend > > Best, > Ben > > ___ > Mailing list: https://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] Scripting hooks
On Wed, Jul 1, 2020 at 10:12 AM mitjan696-ubu...@yahoo.co.uk wrote: > > While I like the idea of hooks I think there are a couple of things that > should be implemented before and they should enable part of the workflow that > you envision. > > To be specific, implementing action plugin interface in Project manager. Once > this is in place a lot of hook actions could be implemented semi-automatic as > an action plugins. I have many times wondered why plugins can't be run from the project manager. There's even no need to add any API; it would be enough if an action plugin could be defined as "generic", not pcbnew specific, and would be visible in the Tools menu of the project manager. There are many tasks which don't need to use KiCad python API. Anyways, I don't think that a better API is a prerequisite for the hook system. There are do difference between the current plugins and the envisioned hooks: 1) Hooks don't need to use KiCad API. Many tasks could be done with the standard python libraries, for example string manipulation and file system manipulation. The hook call could give the necessary data as arguments and the function could return a string or a string list or numerical value. A hook could of course be also more generic without arguments, for example when it manipulates the project folders. And the full KiCad python API would of course be available if needed. 2) Calling hooks is "event based", while calling an action script is done explicitly by the user. Some hook use cases could be replaced by a better action script system (namely implementing free hotkey assignment to call action scripts so that e.g. Save could be replaced by an action script which then calls Save), but not all (like the window title example mentioned in a previous post). 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
Re: [Kicad-developers] Scripting hooks
On Tue, Jun 30, 2020 at 9:17 PM Mark Roszko wrote: > While more extensibility is great. I can only say expecting the user to > use python exclusively for adding the new behavior like for issue #2339 is > very crude. > I'm not saying any possible feature which can be replaced with a script should be replaced. It must be decided case by case. I don't even say that these examples are something where an internal feature should be replaced with a hook. They are just possible examples to show what could be possible. Just think about it this way: 1. Which one is better, just let the users wait for the feature to be implemented, or add a hook which makes it possible to implement it right away in a simple way in a script and then let the users wait for it to be implemented in KiCad proper later? 2. Each hook makes it possible to add any imaginable functionality, not just one feature wish. 3. Adding a hook doesn't take anything away, it just adds possibilities. 4. Any developer is still free to implement anything in C++. Like now they are free to implement a functionality which has existed only in an action script before. 5. Adding a hook doesn't change the UI or the behavior in any way. They wouldn't cause any bugs if the backend for the hook system is good. Hooks could be added even for bugfix releases. It may be much better than waiting for one or two years for the next feature release. > Not everyone is a programmer > Sure. But big problems with scripting have been 1) the unstable API and 2) the lack of asset infrastructure. Both are being worked on. When KiCad scripting gets more traction and the scripts are easier to share and install, not everyone needs to be a programmer and still can easily benefit from the work from others. The potential number of python developers for simple scripts like string handling and generic file manipulation is certainly larger than the amount of potential C++ developers. And if we take that #2339 as an example, it would require a real GUI in KiCad proper (because it would need a way to manipulate the list of folders). A python script would be one a couple of python functions and a list of text strings. If someone writes the script, anyone can change the list of strings, there's no need to be a programmer to change the names of the folders. So, which one would be the better option: 1) add a simple hook to make it possible and implement the GUI later, or 2) not make it possible until someone implements the GUI? 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
[Kicad-developers] Scripting hooks
This post is partly inspired by "Auto-generated backup files: are they useful?" but I have been thinking about this for a longer time. KiCad could benefit from a scripting hook system. There could be pre-hooks and post-hooks for certain actions. Let's take this backup file discussion as an example. One system of backups or file history may not make everyone happy. What if KiCad had hooks for Save etc.? It would call, let's say pcbnew_save_pre() and pcbnew_save_post() python functions which could do anything they want to do with the project. In this case it could create backup files. The script writer would decide how it would be done. It could even use a third-party git or svn python library or external program and make a commit every time the user Saves the document. Let's take another example which was problematic in the past. I don't remember the details, but I think an attempt to enhance the window titles was abandoned because it was somehow problematic. What if there was pcbnew_mainwindow_printwindowtitle_pre(arg1, arg2...) hook which would return a string from the python function? It would take possible parts of the window title as arguments. The python function could form the title as it likes. Third example: pcbnew_plot_gerber_post() could rename and zip the plotted gerber files. See https://gitlab.com/kicad/code/kicad/-/issues/2076. Fourth example: https://gitlab.com/kicad/code/kicad/-/issues/2339. This is obviously something which is impossible to make to satisfy all use cases, but create_new_project_post() hook could create any folders the user wants. It's easy to see that only imagination is the limit, and this would take some needless responsibilities and decisions from the developers and would give freedom to the users. There could and often should be some reasonable default behavior, but the user could decide if it's enough. If the proper infrastructure (asset installer and repository) will be made, the users could share what they have. 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
Re: [Kicad-developers] GitLab milestone cleanup
On Fri, Jun 26, 2020 at 8:46 AM Nick Østergaard wrote: > What about feature requests / wishes from users that are very unlikely to > realise quickly? Should they still be assigned the new milestone? > > I just worry they may clutter the overview too much, but I guess when we > will see how it goes. :) My concern may not be a real problem afterall. > > Nick > > Could there be a milestone "Future" for features which are wanted but not planned for the next release? For example, some things were in the v6 roadmap but were moved to the future roadmap, and even more can(?) be moved later. It would be better to have them in Future milestone than keep them in v6 milestone or remove the milestone completely. 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
Re: [Kicad-developers] Poll: how does autocomplete filter?
Definitely leaving only matching items and removing others. Eeli Kaikkonen On Sat, May 30, 2020 at 5:50 PM Jeff Young wrote: > One strategy is to highlight the first match as you type, but leave the > menu entries unchanged. > > Another strategy is to remove the un-matched entries (so the selected on > is always at the top). > > I’m used to CLion, which removes, but the Scintilla Editor’s default is to > just highlight. > > Which is more common? Which are you used to? Which do you like better? > > Cheers, > Jeff. > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 5.1.6 Release Update
On Fri, May 15, 2020 at 5:35 PM Ian McInerney wrote: > Considering that there are also changes to the library in the releases, > does it make sense to package the light releases for the versioned > (non-testing/nightly) releases. I would think that in this case users would > want the updated libraries. > > -Ian > > The lite installers are are very important for nightly and testing packages which users may download daily. Not as much for stable releases which are downloaded usually once in a couple of months or so. 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
Re: [Kicad-developers] Eeschema annotate block / specific component types proposal
On Thu, May 7, 2020 at 4:20 PM James Jackson wrote: > I would really have liked the ability to only automatically annotate > either a selected block of components, and/or only a subset of the > component types. > For reference, see https://gitlab.com/kicad/code/kicad/-/issues/2209. 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
[Kicad-developers] Separate download server directory for each Windows nightly build installer version?
I keep the Windows nightly build download server page ( https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/nightly/) open in a browser tab to download the latest nightly build, often daily. It's slightly annoying to have four files for each nightly build: 64 and 32 bit, and lite and full. Could it be possible to have four directories under the main directory: * full_installer_with_libraries_64bit * full_installer_with_libraries_32bit * lite_installer_downloadable_libraries_64bit * lite_installer_downloadable_libraries_32bit Then I could just refresh the tab and click on the last file. Now I have to check every time which one is what I want so that I don't download a wrong one by accident (which has happened). (The same is of course true for the 5.1 testing builds.) 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
Re: [Kicad-developers] Duplicates in the issue database
On Fri, Mar 20, 2020 at 1:07 PM Ian McInerney wrote: > There already is a label `status::duplicate` that can be used if someone > wants to (I occasionally use that on more critical issues as well as > marking as a duplicate so it is obvious to me in the issues list that > something is duplicated). It is just not required to be used. > Wow, how didn't I notice it! Is it OK if I start using it for all duplicates? 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
Re: [Kicad-developers] Duplicates in the issue database
On Fri, Mar 20, 2020 at 1:20 AM Seth Hillbrand wrote: > I'd really like to avoid recreating the GitLab > functionality with labels. > I'm not sure if we have understood each other correctly. I didn't suggest replacing the current gitlab functionality. Only adding a label to duplicates (which already are duplicates in gitlab) which would make searching and detecting easier and explicit because gitlab doesn't have that functionality. For example searching only for duplicates or non-duplicates, and seeing the reason for closing right in the list of issues. 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
Re: [Kicad-developers] Duplicates in the issue database
On Fri, Mar 20, 2020 at 1:20 AM Seth Hillbrand wrote: > Hi Eeli- > > It looks like the example you noted was a mistake. If it is marked a > duplicate, you can click the "Closed (duplicate)" blue button at the top > to follow to the base issue. > > Yes, I can follow to the base issue by a couple of means (also by following the status change messages amongst the comments), and I knew it already. You can search for duplicate issues by selecting the "All" or "Closed" > when you search. I'd really like to avoid recreating the GitLab > functionality with labels. No, I can't search for duplicate issues. I can see the closed issues, but I can't search for duplicate issues or see that an issue is duplicated unless I open that specific issue first. That's what I said. On the other hand labels can be searched for or explicitly left off from the results, and are directly visible in the issue list without opening each issue. > There are more features in GitLab that link > to the "duplicate" mark that are useful. Specifically, in the base > issue, we get a list of the duplicates that a developer can look over > when creating their work package. The features involved in the work > package are reviewed by the rest of the development team, which helps to > ensure we catch the parts of the issue that are important to address. That answers my one question. It's OK if this is part of the normal workflow. I just haven't seen any discussion or mention about this until now, and it can't be seen in the issues (which are what the reporters and other end users read). Now when you have said this and if the other developers agree and do that, I can know what happens to duplicates. This is still valid: > > I would suggest that if an issue is marked as a duplicate but it's not > > an exact duplicate or isn't self-evident - like exactly the same > > clearly defined bug reported by several users - the one who marks it as > > a duplicate would give an explanation. > You reacted to the example by changing the report to a duplicate. OK, but it doesn't help a user who reads the issue chain and wonders why a seemingly or possibly unrelated issue was marked as duplicate. It would help if a short explanation would be given. Jon gave an explanation <https://forum.kicad.info/t/does-kicad-have-the-features-i-use-in-altium/21467/59?u=eelik> in the forum thread which I linked to: It is not explicitly mentioned, but once KiCad can keep track of pad stacks > for every hole, it is possible to modify pad stacks for individual holes > easily. Pad stacks include all layers that are relevant to holes, including > masks. > In this case a shorter explanation would suffice: "mask layer should be included in padstack". Then a careful reader can know that the duplicate status isn't a mistake and that the developers consider the issue as part of the larger issue or feature. This is, of course, only one example. I have seen others, and that's why I wrote my mail. In the forum I once gave a link to https://gitlab.com/kicad/code/kicad/-/issues/2295. In the forum a user sceptically commented <https://forum.kicad.info/t/configuring-the-grid-sizes/19709/24?u=eelik>: The bug report was deleted after it was marked as a duplicate of another > vaguely related issue… > In this case "vaguely related" is an accurate description indeed. How these reports are related and how this report is a duplicate of another could have been epxlained in a comment. I.e. how implementing the other feature would either implement this feature, too, or would make it needless or superfluous. It's easy to see those two bugs "related", much more difficult to see them as duplicates. Also in this case the point is NOT this one report, but the general problem of not seeing the exact relationship of two reports of which one is closed as being a duplicate. It would help if the reason for duplicate status would be explained. It may be obvious to a developer who changes the status, but not to those who later read the reports. 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
[Kicad-developers] Duplicates in the issue database
I have some questions and suggestions regarding duplicate issues in the gitlab issue database. First, gitlab can mark issues as "duplicate". It will become " Closed (duplicated)". However, 1) there's no way to search for that status AFAIK, and 2) it can't be seen in the issues list (it's just Closed) and I have to open the issue to see if it was a duplicate or not. Could it be possible to add a new label, "duplicate". It should then be added manually to the issues which are marked as duplicates. That way both 1) and 2) would be fixed. Second, some larger questions. What are the requirements for an issue to be marked as duplicate? Let's take a chain of issues as an example. (See https://forum.kicad.info/t/does-kicad-have-the-features-i-use-in-altium/21467/59?u=eelik where Jon's comment etc. was written after I drafted this mailing list message.) In issue https://gitlab.com/kicad/code/kicad/-/issues/2163 Jeff says " Closing in favour of #2014 (closed)." However, this issue 2163 isn't marked as a duplicate. The main thrust of this report is a wish to add tenting (mask) option for each via. In https://gitlab.com/kicad/code/kicad/-/issues/2014 we have "full stack for each via". This, in turn, was marked by Seth as a duplicate of https://gitlab.com/kicad/code/kicad/-/issues/2402. This 2402 is milestoned for v6 but is in the "future" roadmap and doesn't have an assignee. I see some problems with this kind of issue chain. 1) It's difficult for the users (and the developers) to follow this chain and find related issues. An end user may want to find "via tenting" but it's closed (without actually being marked as a duplicate). Via tenting isn't mentioned at all in the final issue and not even in the middle issue.The intent of the original report has been lost in the issue chain. 2) If issues are closed and/or marked duplicates like this and they are difficult to track down, how can reporters know that their issues are actually being considered and remembered? 3) Can we be sure that when the final issue is fixed and closed that the original (closed as duplicate) issue has been solved? When the final issue is finally assigned to someone, can we know that this someone browses carefully through the issue chain and all related issues of all related issues to see if all the issues are really fixed, and the remaining issues are possibly re-opened? Can we be sure that in this example case Jeff, Seth and whoever will implement it in the future have understood it in the same way? There's no explicit information about the intentions of those who have made changes to the statuses of the reports. (People's names are mentioned strictly only because they are real world examples, no further implications should be made about assumptions about anyone's intentions or working habits or anything else. Everyone has been doing good job.) Does anyone else see these as problems? I would suggest that if an issue is marked as a duplicate but it's not an exact duplicate or isn't self-evident - like exactly the same clearly defined bug reported by several users - the one who marks it as a duplicate would give an explanation. Then the developer who fixes an issue or closes it would be responsible for going back through all issue chains and carefully read all reports to see if they are actually fixed. It would also help if gitlab had a way to mark relationships of issues in a more fine-grained way than just "related to". For example "supersedes" and "is superseded by". That could of course be done with a label and explanation comment. If an issue isn't actually a duplicate of another, but implementing another feature would include fixing this one or would make this one unnecessary, the bug could be marked as "superseded". IMO "duplicate" isn't a good label for an issue which is related but isn't actually a duplicate - duplicate would mean "this issue covers everything but nothing more than that other one", or at least so much that it's self-evident to whoever reads them. The main point is that even the ordinary end users should be able to feel confident about the status of each issue when they read it. 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
[Kicad-developers] Who has access to confidential issues?
On Fri, Feb 28, 2020 at 1:55 PM jp charras wrote: > Unfortunately, issue 3955 does not exist on Gitlab: latest is 3954. > > > -- > Jean-Pierre CHARRAS > > That issue exists but is confidential. I have access to it ( I'm a maintainer in the bugsquad group) . But don't the developers have access to confidential issues? Obviously it shouldn't be so. 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
Re: [Kicad-developers] [5.1.5] i965: Failed to submit batchbuffer
Have you tried an internet search? https://bugs.freedesktop.org/show_bug.cgi?id=107147 On Thu, Feb 27, 2020 at 11:13 AM BERTRAND Joël wrote: > Hello, > > I'm trying to use pcbnew to route a huge PCB and pcbnew randomly > aborts > with following error : > > "i965: Failed to submit batchbuffer: Aucun espace disponible sur le > périphérique > Erreur de segmentation" > > I have seen this error comes from Xorg but I don't know if htere > is a > workaround. > > No more information in log files. I run : > > Application: KiCad > Version: (5.1.5-94-gd62fde0d7), release build > Libraries: > wxWidgets 3.0.4 > libcurl/7.67.0 GnuTLS/3.6.12 zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 > libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.40.0 librtmp/2.3 > Platform: Linux 5.4.0-4-amd64 x86_64, 64 bit, Little endian, wxGTK > Build Info: > wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24 > Boost: 1.67.0 > OpenCASCADE Technology: 7.3.0 > Curl: 7.67.0 > Compiler: GCC 9.2.1 with C++ ABI 1013 > Build settings: > USE_WX_GRAPHICS_CONTEXT=OFF > USE_WX_OVERLAY=ON > KICAD_SCRIPTING=ON > KICAD_SCRIPTING_MODULES=ON > KICAD_SCRIPTING_PYTHON3=ON > KICAD_SCRIPTING_WXPYTHON=ON > KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON > KICAD_SCRIPTING_ACTION_MENU=ON > BUILD_GITHUB_PLUGIN=ON > KICAD_USE_OCE=OFF > KICAD_USE_OCC=ON > KICAD_SPICE=ON > > Best regards, > > JKB > > ___ > Mailing list: https://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] DRC reports
On Wed, Feb 26, 2020 at 1:29 AM Jon Evans wrote: > > The problem with tabs is that they can only expand so far before you have > to start scrolling (and so some tabs are not visible). > > Yes, that's why I thought a combination of tabs and a tree (or grid as you said) may be good. There's still free space for a tab or two. Indeed, post-v5 the footprint warnings have got their own. I have always thought that the messages about non-continous edge cut don't belong with the rest, so I would move them to their own tab. 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
Re: [Kicad-developers] Proposal to update eeSchema annotation?
Alexander, I filed a bug report https://gitlab.com/kicad/code/kicad/issues/3933 "No Undo for Annotate dialog annotation". Could you copy your text there as a comment? Eeli Kaikkonen On Mon, Feb 24, 2020 at 10:43 AM Alexander Shuklin wrote: > Hi anybody! > Sorry if there too much mistakes, I write from phone. When I looked into > undo stuff in schematic editor last time, it worked that way: > Every schematic sheet has its own undo/redo history and when you apply > undo, only components in the opened sheet are affected. > From my point of view just remind people that they cannot undone > annotation and back annotation is less evil. Otherwise somebody will face > up situation when he undone some annotation in one sheet but some annotated > components are still in other sheets. > I would say, that eeschema undo behaviour has to be changed. I thought > about 2 ways: > - make undo changes with all sheets, not the currently opened > - Prompt warning when you want to undo the action which was done with all > sheets in the project (such as annotations) > Just for information: that will be pretty easy to add undo feature in the > backannotation because it generates changelist which can be pushed to undo > stack. But it is useless with current schematic undo algorithm. > > ___ Mailing list: https://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] Proposal to update eeSchema annotation?
On Sat, Feb 22, 2020 at 4:48 PM Brian Piccioni wrote: > Hello > > Now that Geographic Reannotation is a WIP I was thinking it might make > sense to update eeSchema's Annotate dialog. > I created an epic for annotation related issues. You should probably file each proposition as a report if there's no report already. https://gitlab.com/groups/kicad/code/-/epics/19 > Incorporate undo > There's an existing issue for "Back annotation changes unable to be undone in schematic", but there are more problems with Annotation. With one simple component open the annotation dialog, annotate and close. The component is annotated, but: 1) "Save" is not activated in the toolbar. It's activated in the File menu. But when I click on the canvas, the button is activated. 2) There's no undo. If I annotate manually by editing the refdes, Undo works. IIRC Undo has worked previously. These must be reported separately, right? (I'm asking from the senior developers.) 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
Re: [Kicad-developers] What does /path do in PCBNew files?
On Sun, Feb 16, 2020 at 1:47 AM Jeff Young wrote: > Pasting creates new timestamps. So copy/paste works fine, there’s just no > way to do a unified copy/paste between eeschema *and* pcbnew. > Yes, copy/paste in pcbnew works, there's no bug there. But the question is: is it really useful that the "path" is copied, too. As you said, if the user wants to keep the schematic and the layout in sync after copying a footprint, they must: 1. reannotate the footprints 2. add symbols to the schematic 3. reannotate the symbols 4. and reassociate by reference. That would work as well if the copies of the footprints wouldn't have "path" at all, i.e. if they were like newly added footprints. What do users except whey they copy and paste footprints? Do they expect them to be tied to the same symbol as the original footprint, or do they except them to be like newly added footprints? I would say the latter is more natural expectation. I have falled into that trap myself. I thought that copypasting a footprint is a handy way add a new footprint to the board without going through the "Add new footprint" function. Then I changed the refdes on the board. At some point I noticed that somehow the refdes was changed back. Only later I realized that now there were two footprints tied to the same symbol and normal updating PCB from schematic changed the refdes back. 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
Re: [Kicad-developers] What does /path do in PCBNew files?
On Sun, Feb 16, 2020 at 1:20 AM Brian Piccioni wrote: > I think optionally removing the path might be a good idea - or, simply > removing it from duplicated/pasted footprints. Of course I am probably > missing something. > > Brian > You can't backannotate something which doesn't have the "path". But those footprints can of course be re-annotated. I don't think it's possible to cleanly copypaste groups of footprints to create "duplicated design elements" as you say. Either they point to one group of symbols while they should point to hierarchical sheet instances (each of which have different path), or they don't have corresponding symbols at all. If you have two footprints with identical "paths" you can reannotate from eeshcema (with a warning IIRC) and both footprints will have the same refdes. But it doesn't make sense to have two footprints with different refdes to point to one symbol because the symbol has only one refdes. Having identical paths in more than one footprints is problematic anyways. I have used it but I don't recommend it. 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
Re: [Kicad-developers] What does /path do in PCBNew files?
It's the symbol ID from the schematic. This defines the connection between the symbol in the schematic file and the footprint in the layout file. Indeed I have intended to ask about copying this in pcbnew. There's no way to change (remove) it in pcbnew. Once a footprint is pasted or duplicated it's bind to the same symbol as it's originator footprint. As far as I can see there's one use case for this when copying from the same board: having several alternative physical components for one functional component (symbol). But this isn't obvious nor is it clean IMO. It's probably useful if the corresponding components are copied from another project to both eeschema and pcbnew. But inside one project this may be more confusing than useful. Maybe it should be handled like copying/pasting symbols and reference designators is handled now in 5.99: with Paste Special options, trying to find the best alternative for the default paste. And/or there should be a way to reset this field. The footprints added by the "Add a footprint" function don't have "path". On Sun, Feb 16, 2020 at 12:30 AM Brian Piccioni wrote: > Hello > > In the "Kicad File Formats" PDF (and in KicadPCB files) there is (path > /5127A011) where the number after the slash usually changes. I don't see > any where this field is described in the documentation. > > It seems that if I copy and past a symbol in PCBNew the "(path /" field is > duplicated so I end up with two components with the same "(path /" causes, > for example "Error: Pcb footprints R100 and R8 linked to same symbol" error > on back annotation. > > This, in turn, causes problems with geographic reannotation. > > So, can somebody explain what (path / is? > > Thanks > > > Brian Piccioni > ___ > Mailing list: https://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] Status of improved drawing tools?
As early as in the fundraising video https://www.youtube.com/watch?v=uhcMGQ32Xw0 for v6 (before the plans for 5.1 existed) "improved drawing tools" were introduced and apparently some work was already done by then. I don't find this anywhere in the roadmaps. Has it been cancelled or just forgotten from the roadmap? I also think there haven't been an issue for that. 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
[Kicad-developers] File format specifications, again (broken link)
Wayne gave this link recently: https://bazaar.launchpad.net/~stambaughw/kicad/doc-read-only/view/head:/doc/help/file_formats/file_formats.pdf But it leads to a broken download - the file seems to be there because it's previewed as plain text, but can't be downloaded properly. I suggest moving all file format and other possible specs to gitlab if at all possible. 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
Re: [Kicad-developers] Creating new icons
On Sun, Feb 2, 2020 at 7:09 PM Brian Piccioni wrote: > > Currently I select re-annotation direction by a text box "top to bottom, > left to right", etc.. It would probably be best if these were icons > associated with radio buttons. > > Have you already looked at the Annotate Schematic dialog in eeschema? It has similar icons, maybe they are reusable. 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
Re: [Kicad-developers] [PATCH] Implement auto annotation on component/symbol placement.
Zficani, are you still working on this? It came up in https://gitlab.com/kicad/code/kicad/issues/1973#note_277712551. You could fork in gitlab and make it a merge request. Eeli Kaikkonen On Sat, Oct 26, 2019 at 3:58 AM Zficani Zficani wrote: > Hi, > I'm sorry for the delay but I finally got everything sorted out. I > formatted the code and fixed a few bugs I found. > Regarding `git format-patch`, I used it originally but my commits contain > many TODOs and temporary code so I was told to just squash everything > together and send in a single patch. I will send both this time and let you > see which one you actually want to use. I tried my best to clean up my > commit history but it's still not really perfect. > > ___ Mailing list: https://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] Advice on merge request
I have already added Alexander's fork as a "remote" for my local clone of kicad. When I'm back home, I can add yours. You have already forked from Alexander - if you have a local branch based on Alexander's "backannotate" which you want to publish for testing, just push it to your remote, i.e. to your gitlab fork. Then I can see it and fetch, compile and test it, just like I did for Alexander's backannotate. Jon told you what happens after Alexander's is merged to the kicad master (I don't have experience to give you advice about that). I hope everyone - including the lead developers - follow this workflow when they want their code tested: add a clearly named branch to their gitlab fork of kicad. It can be found easily by following the "Fork" number link from the official kicad repo and won't get lost in a mailing list or something like that. Merge requests are even easier to find. You can add "WIP:" to the name of a merge request - it means "work in progress" and prevents merging before you remove "WIP:" from the name, so you can work on your merge request and get feedback before it's ready to be merged. But I suppose a WIP merge request is recommended only for code which is actually expected to be actually merged later, not for all experiments. Eeli Kaikkonen On Sat, Jan 4, 2020 at 7:00 PM Jon Evans wrote: I see no problem directing people to your fork/testing branch to compile and test on their own. > > On Sat, Jan 4, 2020 at 11:43 AM Brian Piccioni < > br...@documenteddesigns.com> wrote: > >> Hello >> >> I have been working on Geographical reannotation. It uses the code >> Alexander Shuklin created for back annotation. I understand Alexander's >> merge request has been pending (yes, I know it is holidays) but now I >> don't know how to proceed because my code depends on his code. >> >> Any suggestions would be welcomed. >> > ___ Mailing list: https://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] Better handling of bugs which affect two versions
There are some problems with bug reports which affect both the stable branch and the development branch (ATM 5.1.x and 5.99). It's not possible to see from the main list of bugs if both versions are affected. Milestone is only for one. It's not possible to handle versions for bug fixes. It's either closed or opened but if the bug affects both versions, IMO it should remain open until both have received the fix. And as far as I can see it's not possible to see which version was fixed. It can be seen only by going to a commit which fixed it. I don't know if it's even theoretically possible to handle versioning for bugs in gitlab, but it should at least possible to use tags which would make the states visible. Would that be a good idea? (One specific issue is https://gitlab.com/kicad/code/kicad/issues/3711, see the discussion in https://forum.kicad.info/t/5-1-5-another-annoying-pcbnew-bug/20407/13 .) 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
Re: [Kicad-developers] Why is -Wno-deprecated-declarations defined
On Sat, Dec 28, 2019 at 5:52 PM Ian McInerney wrote: > The commit that did it is this one from 2014: > https://gitlab.com/kicad/code/kicad/commit/a3211b2b9e57a36c79f4ba2b00d0ac1aa30dceb3, > but the log is literally just: "disable deprecation warnings in Debug > build, change message in fp_lib_table.cpp," so I don't know what the actual > reasoning behind the change was. > > A tongue-in-cheeck suggestion: don't let any commit go to the repo if the commit message doesn't have the word "because" at least once. 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
Re: [Kicad-developers] thoughts on hierarchical schematics
I don't understand all of this, but some kind of parametrization of values
of components in hierarchical sheets has been wished for in some bug report.
I would like to see full utilization of user definable variables with
capability of overriding, not only for hierarchical sheets, but all of
KiCad (at least eeschema and pcbnew, i.e. schematics and layouts).
There would be a table for freely named variables which could be defined or
overriden in each level: user, project, main level schematic sheet, 1st
level hierarchical sheet etc.
For example I could define a variable named ${WRITER} with value "Eeli" in
user level, then use it in all my projects in any place where text can be
entered. Each file or other comparable entity like a hierarchical sheet
instance would have a table of variable names and values where values could
be overriden. Probably there should be a way to do the overriding vice
versa: if the value for a variable is given in upper level, it will be
used, otherwise the local default value is used. So, there could be a third
column in the table: "prefer this" or "override this".
This is quite complicated, but it would be invisible if a user doesn't want
to use it, and it would give as much freedom and new possibilities as
possible with one unified generalized approach. It can be applied to more
problems than just parametrized sheets.
Would that satisfy your needs?
Eeli Kaikkonen (not a KiCad developer)
On Fri, Dec 27, 2019 at 6:38 PM Tjeerd Pinkert <
t.j.pink...@alumnus.utwente.nl> wrote:
> Dear list,
>
> some has probably already been discussed here. I'm diving a bit further
> into hierarchical schematics at present. I'm trying to creating "module"
> schematics that are version controlled in Git, only schematics at this
> moment, and I'm missing some things that would be nice to have in that
> area. Currently also some behaviour of Kicad is a bit counter intuitive
> at that point with regard to where stuff is stored in the files.
>
> The attached file contains some thoughts on this from a user
> perspective. Basically some use cases that, I hope, become possible in
> the future... (no, not expecting this in 6 or even 7, but some day...)
>
> Any comments are welcome, also on how to formulate this such that it
> could become points on the roadmap?
>
> Best regards,
>
>
> Tjeerd Pinkert
> ___
> Mailing list: https://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] Project manager: Recurse into dirs added via fs watcher handlers
On Fri, Dec 20, 2019 at 4:06 PM Mikołaj Wielgus wrote: > I'm unable to submit a merge request, probably because I'm not a member of > the KiCad Gitlab group. I've submitted an access request. > You can fork the project and send a merge request from your fork. I have done that, it works even though I don't belong to the group. 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
Re: [Kicad-developers] FOSDEM 2020
su 15. jouluk. 2019 klo 19.59 Carsten Schoenert (c.schoen...@t-online.de) kirjoitti: > > > What about an Etherpad site (as KiCad currently has no Wiki) to keep all > the information and news on one place? > > > The gitlab project has wiki. I think this kind of non-permanent information would be a good opportunity to test the wiki. It's very easy to use. 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
Re: [Kicad-developers] "copy default global footprint library table"
https://forum.kicad.info/t/global-libraries-recommended-choice-not-checkable/19929 Do you hang out in the forum? If something looks like a packaging issue in Mac you could be "summoned" by mentioning your name there. And I just did :) ti 10. jouluk. 2019 klo 21.42 Adam Wolf (adamw...@feelslikeburning.com) kirjoitti: > Hi folks! > > I decided to make a PCB today :) something I don't get to do very > often anymore. I installed the latest stable on macOS, and opened up > PCBNew, and got a dialog that asked me to configure the global > footprint library table. > > It shows 3 options, effectively "copy the default (recommended)", copy > custom, and create an empty one. > > Copy the default is grayed out! > > I'm filing a bug against myself here. I'll look into this, but if > anyone else knows of issues like this with the macOS build please let > me know. > > Adam > > ___ > Mailing list: https://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] Replace "affects me" of launchpad in gitlab?
Which feature of gitlab issues replaces voting "affects me" in launchpad? Thumb up? I dislike the "thumb up" cliche because it's overused everywhere and has become almost meaningless or can be interpreted in many ways. Also it wouldn't match with thumb down here - would that mean "doesn't affect me"? BTW, how are "weight" and "popularity" calculated, what do they mean? 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
Re: [Kicad-developers] v6 roadmap and schedule (was Re: 5.1.5 released.)
It might be good to add links to relevant issues (bug/wishlist reports) to the roadmap. Readers would find more details and take part into discussions. Now when the document is in gitlab it's easy to add some and make a merge request. Is it OK if I do that? Eeli Kaikkonen ma 2. jouluk. 2019 klo 20.56 Wayne Stambaugh (stambau...@gmail.com) kirjoitti: > Hi Ruth, > > Feedback is always welcome. For V6, I'm trying to keep us on track for > the road map items as they stand. Rehashing these goals at the moment > would be counter productive but I'm certainly willing to entertain your > suggestion once we've released V6. For future reference, please post > one email per topic. I know this is more work from your perspective but > there is no way to manage an email thread covering every topic you > mentioned. > > Thanks, > > Wayne > > > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Eeschema: Add option for selection highlight thickness
You can try with a merge request which I just made. It's a very simple non-code change. Eeli Kaikkonen ma 2. jouluk. 2019 klo 17.03 Seth Hillbrand (s...@kipro-pcb.com) kirjoitti: > On 2019-12-02 04:30, Jonatan Liljedahl wrote: > > ADDED new option to set selection highlight thickness. > > Also change selection shadow width constants to > > make the selection thickness change less drastically > > with the zoom level. > > > > Hi Jonatan- > > I need to test out the new GitLab Merge Request for people who are not > yet members of the lead development team. Would you mind submitting > this as a merge request on GitLab and let me know how the process goes > for you? > > Thanks- > Seth > > Seth Hillbrand > KiCad Services Corporation > https://www.kipro-pcb.com > +1 530 302 5483 | +1 212 603 9372 > > ___ > Mailing list: https://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] Back annotate references from PCB
su 1. jouluk. 2019 klo 0.27 Alexander Shuklin (jasura...@gmail.com) kirjoitti: > Hi Eeli, > first of all sorry for problems with compilation. > No need to apology. I ran "git rebase origin/master" as Jon told, it worked. With this Core 2 Duo I know how you feel about compilation time. It just makes unsuccessful compilations quite annoying. 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
Re: [Kicad-developers] Back annotate references from PCB
I noticed one problem. It's possible to add a footprint to PCB without schematic. Some people might want to do that (e.g. mounting holes or fiducials), yet back-annotate. It's not possible now. Greying out unused options is a good idea, polite towards the user, better usability. Annotation is changing reference designators, right? If changing values and footprints is implemented it's not annotation and clearly shouldn't be in the annotation dialog. Even if they aren't implemented, I find having this back-annotation option in the eeschema annotation dialog cumbersome or strange for some reason, I don't know why. Maybe I just expect symmetric update possibilities, i.e. Tools->Update PCB from schematic / Tools->Update schematic from PCB. In that case the dialogs must be different, of course. But maybe it's just my workflow: I use eeschema Tools->Update PCB. So I expect to have the ability to push the changes instead of pulling. BTW, about the possibility of changing the footprint - I have always found being able to change footprints in pcbnew strange because then it's out of sync with the schematic and it has to be changed in the schematic manually and updated to layout anyways. Being able to update it from the layout to the schematic looks like an obvious missing feature. Eeli Kaikkonen la 30. marrask. 2019 klo 9.54 Alexander Shuklin (jasura...@gmail.com) kirjoitti: > Dear all! > Thanks for your helpful comments. I want to show you draft of what > I've done for just now. > I know, that sometimes people don't like if somebody change their > code, I just rearranged some. In existing algorithms I divide method > to 2 parts for I could reuse it in my patch(made > checkForDuplicatedElements from SCH_REFERENCE_LIST::CheckAnnotation). > I just cannot find better solution to do that. And I added some helper > functions to the SCH_REFERENCE with witch you can get data about > component faster. I would say that changes should be in separate > commit. If them acceptable, should I divide my patch when it will be > ready? > In old pieces where I touched the code, I tried to leave code > formatting like it was. I'm not sure if I had to. Git checks suggest > to reformat it, but I feel it looks better like it's done already. > I almost haven't done anything with design. I just added "Back > annotate from PCB" option to the annotation dialog (see in the > screenshot) and I had a plan to grey out some not useful(for back > annoation) dialog options when you chose that option and enable them > back when you moved to another one. > But... Eeli came with idea that if PCB holds not only references, but > also footprints and values, we can back-annotate them to the schematic > as well. I would say, you need to have checkboxes then with options > "references, values, footprints" and probably that's better to make a > new dialog for that. I don't like to create new dialog, but if I will > add them to existing annotation dialog, I believe that will look > messy. What would you think? > Can you advice me with some code design? In my primary job I usually > want to split functions on small pieces, but in that case it will be > too much methods in the class. So, normally I'm trying to split > classes as well. Now I see that SCH_EDIT_FRAME is already very big. So > I don't want to have more than one method for back-annotation. Is it > ok to use some independent function, (which is not member of > SCH_EDIT_FRAME) like I did in annotate.cpp (int > getPcbModulesFromCPTREE) ? > And if you have any other code suggestions please, don't hesitate to tell. > Wayne, I've checked my code behavior with multi components, with > components re-used in schematics in one project or separate projects, > with PCB which is not up to date with schematic and it don't break it. > If it found any errors it opens "Update PCB from Schematic" dialog > Another thing is: I was looking for undo/redo feature and now it holds > different changes for different sheets. Basically if you back annotate > more than one sch files, you can run undo only for one sheet. I would > say in that case there's no point to implement undo/redo feature now, > as it will confuse a lot. Or undo behavior has to be changed somehow. > You don't have undo feature in annotation either, probably for same > reason. > > Many thanks, I hope my patch is not very bad. > You can find that patch in my fork: > > https://github.com/jasuramme/kicad-source-mirror/commit/64dc222de6149cc789158db80bbe0696cf47dc3d > > ___ Mailing list: https://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] Back annotate references from PCB
la 30. marrask. 2019 klo 9.54 Alexander Shuklin (jasura...@gmail.com) kirjoitti: > > Many thanks, I hope my patch is not very bad. > You can find that patch in my fork: > > https://github.com/jasuramme/kicad-source-mirror/commit/64dc222de6149cc789158db80bbe0696cf47dc3d > > I've got error when compiling (on Linux): eeschema/netlist_object.cpp:254:47: error: no match for ‘operator=’ (operand types are ‘std::vector’ and ‘wxArrayString’) bus_contents_vec = alias->Members(); I just made a fresh clone from https://gitlab.com/kicad/code/kicad and compiled it successfully. Then I added your fork as remote, checked out to backanno and tried to compile. Can you fork from the new kicad gitlab repo? 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
Re: [Kicad-developers] v6 roadmap and schedule (was Re: 5.1.5 released.)
pe 29. marrask. 2019 klo 20.28 Ruth Ivimey-Cook (r...@ivimey.org) kirjoitti: > > I'm not sure if it's been dealt with already but one of the issues I > struggle with is that component boundaries are the enclosing box, and > components cannot (AFAIK) be marked as not selectable. For example, I have > a "component" which is the outline of a daughterboard (for a BB Black). The > component ensures the relation between the edge cuts and the connector > footprint is maintained. However, on more than one occasion I have messed > up the board badly by moving the board component without realizing it. > > I have two requests from this situation: > > 1. I would *really* like to be able to lock components in place, > preventing them from being moved (or even selected) until unlocked. Lock = > select and "Lock", Unlocking might be done with a separate list of locked > items, or with a UI action that unlocks anything in a drawn area, or by an > Unlock All action. > > 2. I would like the selection code to prefer selecting items by visible > artefact, e.g. a line or some text, and only if there is no such artefact > under the cursor to consider things nearby. I'm particularly thinking here > of clicking on an component placed beside e.g. an IC footprint, though not > on it. If the component is under the cursor then that should be selected > directly even if the cursor is also within the bounding box of the IC. > > https://bugs.launchpad.net/kicad/+bug/1832986 https://bugs.launchpad.net/kicad/+bug/1745627 ___ Mailing list: https://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] v6 roadmap and schedule (was Re: 5.1.5 released.)
pe 29. marrask. 2019 klo 20.28 Ruth Ivimey-Cook (r...@ivimey.org) kirjoitti: > I would be interested to know why it is not possible/good to use "normal" > outline fonts (ttf, otf et al) on a PCB what are the issues? > That's an easy one to answer, at least partially. PCB needs graphics which can be exported to gerber graphics. In practice this means that font characters (I think the correct word is "glyph") should be converted to polygonal outlines. It wouldn't be impossible, but would require writing a conversion library (or finding an existing one) and integrating into KiCad. I guess it would be quite resource heavy run time because each character would be one or several complex polygons. Using a simple font like Arial would be most realistic - it has lots of straight lines instead of curves. Serif fonts like Times aren't so fitting for a PCB board anyways because they wouldn't be so clear in small sizes and because of bad resolution (I mean the resolution of the physical board, especially silk). Another option would be to pre-convert some font to polygons and use them, a bit like the current font system in pcbnew. It now has a font where each character is a bunch of segments. Only handling polygons instead of segments would be required. However, it's not quite that simple. For good results the characters must be kerned, i.e. the space between any two characters must be decided case by case bases. Otherwise non-monospace fonts don't look good. That's one reason why complex font engines are needed in the first place. Just drawing characters would be relatively easy (except for antialiasing etc. but KiCad doesn't need to worry about that). So, either the characters should be drawn without kerning or there should be some way to do the kerning. Maybe adding kerning to text handling code wouldn't be impossible. I don't know how the font engines work, but maybe it could be possible to let an external font engine do the layout to a dummy backend without it knowing about the actual visual output and then find the locations of characters. Another thing to think of is the physical quality of the manufactured board which should be the greatest concern. Silk screen resolution is bad. That means that the text would look decent only in large size, especially when made by cheap technologies. Text in copper or mask is better. But in any case it would be much work which would benefit little. Still I think it would great to have it in KiCad. Maybe someone could write a python plugin? It would be possible to create text as graphic polygons, although it wouldn't be possible to handle it as normal native text. But it would help if someone needs nice text for end users of a board. 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
Re: [Kicad-developers] v6 roadmap and schedule (was: Re: 5.1.5 released.)
pe 29. marrask. 2019 klo 16.41 Wayne Stambaugh (stambau...@gmail.com) kirjoitti: > > There is no way I would attempt to determine or mandate the order which > features get merged. They will get merged based on their readiness to > be merged. > I thought there might be something else, like waiting for some other large features (like the new file formats) getting in first. But this being the case, we'll just wait. Maybe some of the developers (at CERN or others) may want to share some information about their work if it's getting closer - it would just be nice to hear. 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
[Kicad-developers] v6 roadmap and schedule (was: Re: 5.1.5 released.)
pe 29. marrask. 2019 klo 15.56 Wayne Stambaugh (stambau...@gmail.com) kirjoitti: > > It's not as up to date as it should be but it's pretty close > > https://docs.kicad-pcb.org/doxygen/v6_road_map.html As you surely know, everybody is very interested about not only the features but also the schedule. In the recent interview you said: "With Version 6 – due next year – it aims to close the feature parity gap with the most popular commercial tools in the market." How realistic this schedule looks right now? I expect you meant the end of the year. It would be also interesting to know the order in which the major features are coming in, and what is coming for sure and what is less sure. For example, the donation campaign video showed that there are some major parts more or less ready, waiting to be included. But there has been complete silence since then. I have been anxiously waiting to be able to test them in action :) 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
Re: [Kicad-developers] windows 32-bit builds
Based on this poll: https://forum.kicad.info/t/which-windows-version-you-are-using-kicad-v5-or-newer-on/15618 there really have been some 32bit KiCad users. What do the download statistics say? The situation will change considerably when Win7 support will end. Most of the 32bit installations have probably been Win7. Eeli Kaikkonen ke 27. marrask. 2019 klo 20.37 Mark Roszko (mark.ros...@gmail.com) kirjoitti: > Just throwing it out there. > > Is there any point in continuing 32-bit builds for Windows? 64-bit has > been the default arch for over a decade on Windows now. Linux distros are > in the process of purging 32-bit. macOS threw 32-bit into a deep dark hole > this year. > > Pros: > 1. Don't need to package twice > 2. Reduced bug footprint, in case there are 32-bit vs 64-bit variances > 3. Potentially some tiny performance improvements > > Cons: > 1. Somebody out there is using a Window 32-bit install in the year 2019 > and they'll be affected. > > -- > 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
Re: [Kicad-developers] Plugin/3rd party content manager
ke 27. marrask. 2019 klo 1.51 Seth Hillbrand (s...@kipro-pcb.com) kirjoitti: > After the initial > ideas and implementation are documented, it will go to the lead > developers first to ensure everyone agrees with the plan and course of > action. After that, it will be published on the list for open comments. > This ensures we conserve time and effort. > > OK, let's see. I'm just not sure about what can be an "initial" idea or implementation and what is such a detail which should be discussed only afterwards. After all, I have done some experimentetation and have noticed both high-level principles and lower level implementation related things. Sometimes it's difficult to separate them. > If there are any python developers who would like to contribute code to > the KiCad codebase and are looking for how to do that, please contact > me. There's lots of Python work to be done. I'm happy to help provide > an introduction to that code and some structure for how to address a > number of existing wishlist items that require Python. > > Feel free to contact me through email or otherwise. Although I'm not really a python developer any more than a C++ developer (I have done some of both), in this context I'm personally more interested in getting the python part of KiCad forward. 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
Re: [Kicad-developers] Plugin/3rd party content manager
ti 26. marrask. 2019 klo 22.23 Seth Hillbrand (s...@kipro-pcb.com) kirjoitti: > > We need to start with the API definition and file format changes. The > API definition should include end points and returns. The file format > changes should include the files and specific configuration lines > needed. > > Please do not go down the road of an entirely public infrastructure > manager. We can include an option for additional servers that return > the API calls, but this needs to be centralized to fit into the KiCad > roadmap. > I don't understand either of these points, could you open up them a bit? When I played with my plugin manager I realized that the manager can be completely agnostic about the content. It can also be mostly separate from KiCad C++ code, it doesn't need to know the internals of KiCad, and there's definitely no need for file format changes. Unless you talk about having for example some repository URLs or desired installation locations in main KiCad configuration file. KiCad should have API for refreshing the libraries and plugins after installing new ones, not much else. Possibly KiCad should be aware of the changing file system while installing/removing/updating. I don't see why these should be known first. I hoped that the content manager could be developed mostly separately from KiCad and in python - that would be a great strength, hopefully saving time and effort from the main developers while drawing in new volunteers. It could indeed be a plugin (as a proof of concept my plugin can install and update itself). It could easily be modified afterwards to plug it into KiCad, after finding out what it needs from KiCad and what KiCad needs from it. What do you mean by completely public infrastructure manager? There probably should be something preconfigured for this to be as user friendly as possible and to fully integrate with KiCad and the official libraries and other official content. But as for other, 3rd party, content, the only reason to have a content manager is to allow people to add content freely, so that a plugin writer (or anyone else) can publish an installable plugin and the end user can install it. What is "additional servers that return the API calls"? There's no need for any servers apart from existing ones around the world, any server in internet or even local hard disk which has files which can be downloaded or copied. There's no need for any additional protocol or API for a server. BTW, here's a link to bobc's introduction to kipi, his idea of a content installer: https://forum.kicad.info/t/announcing-kicad-package-installer-kipi/10193. It follows roughly the same ideas than mine, although mine introduced the idea of a metadata repository from the beginning. 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
Re: [Kicad-developers] Plugin/3rd party content manager
I think the differences expressed are about problems in communication, not differences in actual opinions. I agree with myself (obviously), with what Andrew said and with Ian. We are just talking past each other, about different things. Me said (meant): the content manager should be generic enough and have a reusable (within reason, considering KiCad's needs) backend with a clear API, then KiCad specific parts and UI built upon that. Just normal good architecture, nothing more. Andrew said: it should be integrated into KiCad for easy user experience and targeted for KiCad end users, and be safe to use. Ian said: it should be flexible and allow different use cases and configurations. As we can see, there's no real conflict. The backend could be developed independently from the UI and KiCad specific parts. Eeli Kaikkonen ti 26. marrask. 2019 klo 17.20 Ian McInerney (ian.s.mciner...@ieee.org) kirjoitti: > We should not limit the end points available to users to be only the KiCad > systems we decide, and also should not constrain plugins to be open source. > Doing this would constrain independent companies from developing plugins to > interface KiCad with their systems if they so choose (for instance, if a > company wanted to create a plugin to use an EM simulation package from > KiCad to simulate the board and sell it as an extension to their product, > baring other licensing concerns). > > Any plugins we provide through a KiCad official repositories could have > the open source requirement, but the idea of a centralized repository that > should be scoped out and discussed. > > -Ian > > On Tue, Nov 26, 2019 at 12:34 PM Andrew Lutsenko > wrote: > >> HI Eeli, >> >> I've seen that thread earlier and reread it again. >> >> Some of your ideas have merit but I think built-in content manager should: >> 1. Be at least somewhat coupled to KiCad needs and not be super generic. >> We are not building apt-get repository here that has to handle arbitrarily >> complex packaging//installing/dependency resolution behavior. >> 2. Have some sort of central managed repository so that some rules can be >> enforced like proper licensing and author attribution, as well as enforcing >> open source requirement for plugins. >> >> Good chunk of reasoning for the above comes from security considerations. >> For example when I download a library with built-in kicad manager I trust >> that no arbitrary non-kicad code will be executed because there is no need >> for library to have any code. Generic plugin manager knows nothing about >> what files are symbol libraries and where to put them and what are 3d >> models/footprints. Kicad plugin manager can automatically suggest to add >> libraries to your lib tables. >> Enforcing open source requirement for plugins is also important so that >> any user can check what are they downloading before they do. And users >> without the technical ability to do so will rely on community feedback >> and/or rating system to build some degree of trust that code is not >> malicious. >> >> That's not to say that "side loading" a plugin from your own >> manifest/metadata file would not be possible. Of course it should be, even >> just for development purposes, but then you are on your own. Being able to >> use custom repository should also be possible. >> >> Of course all of the above are just my opinions and will be open for >> discussion but it's easier to do in the google doc. I'm happy to capture >> alternative options with their pros/cons in the doc as well. >> >> Regards, >> Andrew >> >> >> On Tue, Nov 26, 2019 at 2:25 AM Eeli Kaikkonen >> wrote: >> >>> >>> >>> ti 26. marrask. 2019 klo 11.27 Nick Østergaard (oe.n...@gmail.com) >>> kirjoitti: >>> >>>> I don't know if you use freecad, if you do you probably used the addon >>>> manager. It is quite helpful in installing python plugins. >>>> >>>> It is probably worth reviewing how it works conceptually. >>>> >>> >>> Yes, I know about it. For me it was easier to start from scratch. And >>> I'm a bit more ambitious than the FreeCAD plugin manager, although my >>> skills don't always follow :) >>> >>> Here's a forum discussion: >>> https://forum.kicad.info/t/one-script-to-rule-them-all/8935. Try to >>> skip the unpleasant parts. >>> >>> I don't remember all the details anymore, but I think I already >>> envisioned and maybe partly implemented more generic purpose features than >>> I ori
Re: [Kicad-developers] Plugin/3rd party content manager
ti 26. marrask. 2019 klo 11.27 Nick Østergaard (oe.n...@gmail.com) kirjoitti: > I don't know if you use freecad, if you do you probably used the addon > manager. It is quite helpful in installing python plugins. > > It is probably worth reviewing how it works conceptually. > Yes, I know about it. For me it was easier to start from scratch. And I'm a bit more ambitious than the FreeCAD plugin manager, although my skills don't always follow :) Here's a forum discussion: https://forum.kicad.info/t/one-script-to-rule-them-all/8935. Try to skip the unpleasant parts. I don't remember all the details anymore, but I think I already envisioned and maybe partly implemented more generic purpose features than I originally intended. Of course bobc was right and the manager should manage all kinds of downloadable content. One misunderstanding I would like to remove in the very beginning. This is not tied to any one central repository. It's just a matter of configuration and implementation details. The end user could configure different repositories or single package description sources. A "repository" is just one URL where several package descriptions can be found. Of course that URL should be configurable, chosen from a list etc. 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
Re: [Kicad-developers] Plugin/3rd party content manager
OK, I refreshed my memory. I have a group in github (not gitlab): https://github.com/kc-plugin-publishers. You can check out there what I have written. There are three things: the manager script (plugin), example dummy plugins to be installed, and the description files (.plugininfo files). Now when I look back, the instructions aren't super clear. But you should be able to see what's going on. Notice that the script was written with KiCad python plugins in mind at first, but also for more generic use. There's nothing which prevents applying this to any file content. You can see in the description file template that any files can be installed. If I remember correctly the limitation right now is that you can't install to any location. That should be changed so that the destination directory is configurable by the end user (but not by the content description file) so that e.g. KiCad libraries can be installed to their own directories. It should be needless to say that nothing is set in stone - names, architecture, file format, language etc. This was just a proof of concept. The number one lesson is that you can use the existing infrastructures (downloadable files in net or even local files) to create a simple content manager where anyone can write a content description file and publish it (without being a developer or having any special priviledges or skills), and the content manager can download, install and uninstall those packages. There's no need to "package" anything. The upstream developers of content don't have to know anything about this. You can test this by writing a .plugininfo file for an existing plugin. Eeli Kaikkonen ti 26. marrask. 2019 klo 10.23 Eeli Kaikkonen (eeli.kaikko...@gmail.com) kirjoitti: > I'm in a hurry right now, so I just give few points. You can find some > discussions in the forum (I'll find them later). What I learned when I did > some coding is this: > > - Ideal content manager is a separate backend and frontend and reusable > for other projects, too. > - It's really general purpose and actually not tied to KiCad, at least the > backend. > - It doesn't need (and shouldn't) be tied to KiCad even with code, except > minimally. It can be a plugin or separate application - there's no need to > change KiCad. > - It can use existing infrastructures like github, gitlab or any zip files. > - Anyone can easily write a description file for a package and publish it. > There's no need for actual packages (a zip file of the content is enough, > or even any downloadable files). > - It's difficult to decide what it should and should not do so that it > doesn't become a full fledged package management system, is simple enough > but also powerful and flexible enough. (Think about versioning of content > and automatic handling of dependencies.) > - I suggest using python so that it can be a plugin. > - Technically the most difficult part is probably networking (needs all > the boring stuff like error handling and should be asyncronous to be good; > that's where I left off). > > I already coded a command line script which can work as plugin. It can > install itself from gitlab when I click the KiCad plugin menu item, so it > basically shows how the infrastructure works. Actually it's possible to > write a package description file for any KiCad plugin and it will install > it. I already did some. > > Eeli Kaikkonen > > > ti 26. marrask. 2019 klo 3.46 Andrew Lutsenko (anlutse...@gmail.com) > kirjoitti: > >> Hi Seth, >> >> Yes, I planned to write up my design in google doc and open it to >> comments. I think that works best for public discussion, even though it >> requires having a google account. >> >> Design I'm thinking about requires 0 custom backend work. It will rely >> entirely on publicly available infra such as github/gitlab hosting and >> ci/cd pipelines. Admittedly that imposes some limitations on what we can do >> (and I will outline them in my doc) but we can always add custom backend >> system later to complement free infra. >> Assuming design is accepted I am interested in doing at least a minimally >> functional implementation. I have a lot of ideas but some of them will have >> to be implemented later because it's not a trivial task. >> >> Ok, I'll start working on it and will hopefully share the doc by end of >> this week. >> >> Andrew >> >> On Mon, Nov 25, 2019 at 4:16 PM Seth Hillbrand >> wrote: >> >>> On 11/25/19 3:21 PM, Andrew Lutsenko wrote: >>> >>> Hi all, >>> >>> Is anyone currently working on some sort of plugin manager or 3rd party >>> library manager? >
Re: [Kicad-developers] Plugin/3rd party content manager
I'm in a hurry right now, so I just give few points. You can find some discussions in the forum (I'll find them later). What I learned when I did some coding is this: - Ideal content manager is a separate backend and frontend and reusable for other projects, too. - It's really general purpose and actually not tied to KiCad, at least the backend. - It doesn't need (and shouldn't) be tied to KiCad even with code, except minimally. It can be a plugin or separate application - there's no need to change KiCad. - It can use existing infrastructures like github, gitlab or any zip files. - Anyone can easily write a description file for a package and publish it. There's no need for actual packages (a zip file of the content is enough, or even any downloadable files). - It's difficult to decide what it should and should not do so that it doesn't become a full fledged package management system, is simple enough but also powerful and flexible enough. (Think about versioning of content and automatic handling of dependencies.) - I suggest using python so that it can be a plugin. - Technically the most difficult part is probably networking (needs all the boring stuff like error handling and should be asyncronous to be good; that's where I left off). I already coded a command line script which can work as plugin. It can install itself from gitlab when I click the KiCad plugin menu item, so it basically shows how the infrastructure works. Actually it's possible to write a package description file for any KiCad plugin and it will install it. I already did some. Eeli Kaikkonen ti 26. marrask. 2019 klo 3.46 Andrew Lutsenko (anlutse...@gmail.com) kirjoitti: > Hi Seth, > > Yes, I planned to write up my design in google doc and open it to > comments. I think that works best for public discussion, even though it > requires having a google account. > > Design I'm thinking about requires 0 custom backend work. It will rely > entirely on publicly available infra such as github/gitlab hosting and > ci/cd pipelines. Admittedly that imposes some limitations on what we can do > (and I will outline them in my doc) but we can always add custom backend > system later to complement free infra. > Assuming design is accepted I am interested in doing at least a minimally > functional implementation. I have a lot of ideas but some of them will have > to be implemented later because it's not a trivial task. > > Ok, I'll start working on it and will hopefully share the doc by end of > this week. > > Andrew > > On Mon, Nov 25, 2019 at 4:16 PM Seth Hillbrand wrote: > >> On 11/25/19 3:21 PM, Andrew Lutsenko wrote: >> >> Hi all, >> >> Is anyone currently working on some sort of plugin manager or 3rd party >> library manager? >> https://bugs.launchpad.net/kicad/+bug/1823733 >> >> I have some ideas that I want to write down in a form of high level >> design document and share with the group for discussion. If there is >> already some work done in that direction I'd like to avoid duplication of >> efforts. >> >> Regards, >> Andrew >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> >> Hi Andrew- >> >> There are a few ongoing discussions about what needs to be included and >> the backend server design needed in addition to how the software would >> interact with the data. >> >> I'd be interested to see the design document you come up with. If you >> are interested in doing the full implementation, it would be good to see >> your thoughts in the design document. If you do write this up, please >> include it in a format/locate that allows for content-level suggestions >> such as Google Documents or markdown document on GitLab/GitHub. >> >> Thanks! >> -Seth >> >> -- >> KiCad Services Corporation [image: KiCad Services Corporation Logo] >> Seth Hillbrand >> *Lead Developer* >> +1-530-302-5483 <+12126039372> >> Davis, CA >> www.kipro-pcb.comi...@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 >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : http
Re: [Kicad-developers] GitLab migration
ma 25. marrask. 2019 klo 20.11 Mark Roszko (mark.ros...@gmail.com) kirjoitti: > > I don't have, or want, a cell phone (or any Google account). > You do not need a cell phone. You can use a computer based TOTP supporting > authentication app such as Authy or FOSS KeePassXC ( > https://keepassxc.org/screenshots/) > It's also possible to use a USB dongle. A handy KiCad hacker makes one him/herself, of course :) https://support.google.com/accounts/answer/185839?co=GENIE.Platform%3DDesktop&hl=en https://www.tomsguide.com/us/make-2fa-key-shmoocon,news-24282.html https://hackaday.com/tag/two-factor-authentication/ How about designing, making and selling KiCad 2fa dongles to support the development? Releasing it as OSHW of course, like the one mentioned in the tomsguide article. 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
Re: [Kicad-developers] Using OPT types
A good IDE should be able to open up auto and typedef in a tooltip. Clang library helps here, for example Qt Creator uses it and shows the actual type when I hover over auto. Eeli Kaikkonen su 24. marrask. 2019 klo 19.10 Wayne Stambaugh (stambau...@gmail.com) kirjoitti: > On 11/24/19 7:12 AM, Jeff Young wrote: > > Personally I hate OPT (because it’s somewhat harder to read and > more-than-somewhat harder to debug). > > I tend to agree with Jeff. The older I get, the less I like having to > dig around the code base to figure out what is going on because > templated code does tend to be less fun to debug. > > > > I also dislike auto, except in the case of stl::’s overly-verbose > iterators. Again, they make the code harder to read more often than not. > > I'm seriously rethinking typedefs as well. I can never seem to remember > the type they represent so I have to dig around the source to figure out > the actual type. I'm thinking just typing out the full type is easier > in the shortened typedefed version which was most likely only created to > save some typing. > > > > > Maybe I’m just showing my age…. > > Funny how age changes your perspective. > > > > >> On 24 Nov 2019, at 11:13, Ian McInerney > wrote: > >> > >> What is the current consensus on using OPT types in the code? I know > there are some instances where we are already using them from the Boost > library (since our C++ version isn't high enough to include them), but is > that considered a good type to use more of? > >> > >> I am curious, because I am thinking of replumbing the position storage > in the tool events to use OPTs for the position, because that will allow > for cleaner handling of the position in the tools, and also because I need > to pass the positions into the selection routines, and being able to pass > an OPT will greatly simplify things (I think). > >> > >> -Ian > >> ___ > >> Mailing list: https://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] Back annotate references from PCB
I probably don't understand everything which has been said, but as far as I can see there are actually two things going on which could and should be independent. 1. Doing geographical reannotation in pcb. 2. Propagating changes made in the pcb back to the schematic. I believe they should be completely different, and number 2 should be generic, taking care of all changes which reasonably can be propagated from the board to the schematic. Basically Update PCB from Schematic backwards, i.e. Update Schematic from Board. With a similar UI dialog, of course. Undo could also be similar. Or do I just think it's so "simple" and can't see something? It's easy to see that number 1 isn't difficult and could be done with a python script (although many people would like to see it in the main KiCad, I think). Eeli Kaikkonen su 24. marrask. 2019 klo 8.57 Alexander Shuklin (jasura...@gmail.com) kirjoitti: > Hi Eeli and Brian, > Sorry for delay, unfortunately I cannot answer too often. > > > It has occurred to me (Alexander please chime in) that once back > annotation has been solved subject to all the issues raised by Wayne and > others that it would be a general solution. > > Unfortunately no. All stuff mentioned by Wayne is has to be > implemented in back-annotation, that's situations which back > annotation will have to care about, otherwise it will be crap. I meant > I see some general tool as geometrical (geographical?) re-annotation > in pcbnew, which do left->right top->down or opposite directions being > in C++ GUI, but if you want re-annotate in some different manner, you > are free to use python scripts, as you could easily back annotate > after that. > > > Can this do other kinds of changes than just annotation? I'm thinking of > changing the footprint or value > > Of course that's possible, and not a big deal to add this into > back-annotation algorithm. I just think how to do it better. I would > say we will need to have some GUI for that then. I mean, you probably > want to choose what do you want to back-annotate... or maybe not. And > unfortunately at this point you cannot do that with python, as there > no python scripts in schematic editor. If it will be useful, I can do > that of course. Eeli, what I would suggest, I believe in few days I > will make draft commit and mark it (Work In Progress) to show how It > works, and we could discuss how it's gonna work with values and > footprints it will not be a big deal to change it. > > On Sat, 23 Nov 2019 at 21:03, Brian Piccioni > wrote: > > > > It has occurred to me (Alexander please chime in) that once back > annotation has been solved subject to all the issues raised by Wayne and > others that it would be a general solution. > > > > > > > > Of course, this would end up being a sizeable change to Kicad since the > various edit functions, etc., who have to be modified to incorporate the > feature. > > > > > > > > Like you I often fiddle with different packages and values and I > typically switch to eeSchema, make the change, then hit F8 to update the > PCB. It seems to me it would be easier for the appropriate changes to > simply be reflected back to the schematic. > > > > > > > > Brian > > > > > > > > From: Eeli Kaikkonen > > Sent: November 23, 2019 12:56 PM > > To: kicad-developers > > Subject: Re: [Kicad-developers] Back annotate references from PCB > > > > > > > > > > > > > > > > la 23. marrask. 2019 klo 14.52 Brian Piccioni ( > br...@documenteddesigns.com) kirjoitti: > > > > By having a single integrated tool analogous to “Update PCB From > Schematic” can ensure coherency. > > > > Can this do other kinds of changes than just annotation? I'm thinking of > changing the footprint or value. For example I could use Change Footprint > feature in pcbnew and propagate that change to eeschema. That's not so > difficult to do in eeshcema and update the board, but often it would feel > much more natural to e.g. test if 0402 R package would be physically better > for some situation than 0603 and then update the shcematic based on the > board if it fits. > > > > > > > > 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] Back annotate references from PCB
la 23. marrask. 2019 klo 14.52 Brian Piccioni (br...@documenteddesigns.com) kirjoitti: > By having a single integrated tool analogous to “Update PCB From > Schematic” can ensure coherency. > Can this do other kinds of changes than just annotation? I'm thinking of changing the footprint or value. For example I could use Change Footprint feature in pcbnew and propagate that change to eeschema. That's not so difficult to do in eeshcema and update the board, but often it would feel much more natural to e.g. test if 0402 R package would be physically better for some situation than 0603 and then update the shcematic based on the board if it fits. 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
Re: [Kicad-developers] Building Kicad on Windows 10/Eclipse/Msys2
la 23. marrask. 2019 klo 11.11 Carsten Schoenert (c.schoen...@t-online.de) kirjoitti: > Hello Eli, > > Am 23.11.19 um 10:03 schrieb Eeli Kaikkonen: > > BTW, it's unnecessarily verbose to say "git pull origin master". Just > > "git pull" is enough when you are in the local master branch. > > no it's not. > Your statement is only true if the user hasn't added one ore more > remotes. If you have only one remote configured git tries to be smart > and is substitute the rest for the command by the obviously logical value. > > So, if you want to be safe than the full command line is correct. > > > Oh yeah. I took a shortcut and thought about my normal situation when I have checked out a branch (master), although I added " when you are in the local master branch". Anyways it's best to give as simple instructions for getting the source code as possible and leave everything else for homework for the user. Eeli (with 2 e's) ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Building Kicad on Windows 10/Eclipse/Msys2
la 23. marrask. 2019 klo 4.05 Brian Piccioni (br...@documenteddesigns.com) kirjoitti: > Can Simon or somebody who understands such things verify that the > following is correct so I can update my recipe? > > > > Thanks > > > > == > > > > In Mingw64 > > > > git clone https://github.com/KiCad/kicad-source-mirror.git > > > > This will create a local repository directory called kicad-source-mirror > > > > At any time you can update the repository by > > > > cd kicad-source-mirror > > git pull origin master > > > > Note that this will leave files which are in kicad-source-mirror but not > in the kicad source repository unaffected. > > *** However *** they will over write your versions of those files! So if > you edit cmakelists.txt or any other Kicad source file those edits will be > lost. > > > Git pull tries to merge the upstream changes to your files. If there are no conflicts the upstream changes and your own changes will both be in your local files. I don't think it's necessary to teach people how to use git in these instructions. Just simple "download the source zip package and unzip it or use git clone so that the sources are in such and such directory, for example:..." and the simple unzip command line and the simple git clone command line. You don't give further instructions about using unzip, either. BTW, it's unnecessarily verbose to say "git pull origin master". Just "git pull" is enough when you are in the local master branch. It's a shortcut for "git fetch" + "git merge"; for details see e.g. https://stackoverflow.com/questions/292357/what-is-the-difference-between-git-pull-and-git-fetch or a git tutorial. (Now you can see why you shouldn't try to give extra information about git in these instructions. Those who want to use git can read a git tutorial.) 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
Re: [Kicad-developers] suggestion: draw text selection as simple rectangle
Jonatan, have you read this forum discussion: https://forum.kicad.info/t/selection-highlighting-in-development-version/18694 ? Eeli Kaikkonen ke 20. marrask. 2019 klo 21.37 Jonatan Liljedahl (li...@kymatica.com) kirjoitti: > Hi list, > Here's another suggestion, to draw the boundary box of selected text > instead of drawing the text itself with the thick selection shadow. > See attached screenshot. > > Is this a good idea? If yes, does it need to be configurable? > Personally I find it a lot easier and visually less tiresome. > > -- > /Jonatan > http://kymatica.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] Project save as
ti 12. marrask. 2019 klo 17.43 Jeff Young (j...@rokeby.ie) kirjoitti: > FWIW, the old generated files are not outdated — the paths in them are > updated. > > I was thinking for example gerbers which often (usually?) have project name and revision as graphics in some layer. Whatever the reason of using Save As was, at least some layers are probably outdated and can't be used without being regenerated after modifying the board file. 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
Re: [Kicad-developers] GitLab migration
ti 12. marrask. 2019 klo 11.04 Andrew Lutsenko (anlutse...@gmail.com) kirjoitti: > I think there is value in having all the history in one place. Add to that > much more efficient search utilities and looking up history a year later > will be a lot easier if all of it is in gitlab and not split. > > Just my 2c. > > Andrew > Every now and then I try to search for old reports which have been fixed and released. I may not remember if something has been reported and fixed, or remember vaguely something related to some new bug. But not very far back in time because I didn't live when 4.0.0 was released :) I can see value in having for example all fixes for 5.1 series in the same place than the active reports, but definitely not old v4 bugs and probably not v5.0. 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
Re: [Kicad-developers] Project save as
ti 12. marrask. 2019 klo 0.02 Jon Evans (j...@craftyjon.com) kirjoitti: > I question the value of creating this amount of complex UI around "save > as". > In that case I personally would prefer minimal functionality, copying only the necessary project files. More likely than not the generated files aren't needed or are outdated because of the name change (for example having the old project name inside them). But if a large amount of files is renamed and copied I would like to have control over it when it's done. Going though the files afterwards is more difficult. Anyways, renaming the necessary files of the project to form a new functional project is the really needed feature and it's great to have it, with or without complex additions. 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
Re: [Kicad-developers] Project save as
Here's a rough idea of what a confirmation dialog could do: [image: image.png] I think something like that would be flexible enough to help the user with most workflows and left the responsibility to the user while being simple and easy enough to use (although a bit more work to implement, of course). Eeli Kaikkonen ma 11. marrask. 2019 klo 23.20 Jeff Young (j...@rokeby.ie) kirjoitti: > Limiting it to a dash is just because that’s all Kicad generates. The > user could indeed use anything. > > So should we rename any file that starts with the old project name? I did > have a version that did that, but it seemed too aggressive to me. > > On 11 Nov 2019, at 20:56, Eeli Kaikkonen wrote: > > > > ma 11. marrask. 2019 klo 22.41 Jeff Young (j...@rokeby.ie) kirjoitti: > >> Yes, the current algorithm renames files that either match the project >> name (with any extension), or start with the project name followed by a >> dash. >> > > Limiting the following character to dash seems arbitrary. Underscore is > used often, and why it should be limited at all? > > Here's one more possible solution. The current file dialog is kept, but if > any generated or unknown files which begin with the project name are found, > a new dialog asks if the user wants to rename and copy them or not to copy > them at all, or maybe copy them as is. > > On the other hand, what to do with other files which don't begin with the > project name? Should they be confirmed and copied (as is), too? > > What about the backup files? > > I can see two use cases: rename the project (replace the old one); and > copy the project to be a base for a new one. In the former case renaming > and keeping about everything could be desired. In the latter case all but > the basic project files would probably be ditched. > > In the case of renaming I'm also interested in knowing how it affects > version control, for example git, if the project is a repository. That must > be tested, I think. > > 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] Project save as
ma 11. marrask. 2019 klo 22.41 Jeff Young (j...@rokeby.ie) kirjoitti: > Yes, the current algorithm renames files that either match the project > name (with any extension), or start with the project name followed by a > dash. > Limiting the following character to dash seems arbitrary. Underscore is used often, and why it should be limited at all? Here's one more possible solution. The current file dialog is kept, but if any generated or unknown files which begin with the project name are found, a new dialog asks if the user wants to rename and copy them or not to copy them at all, or maybe copy them as is. On the other hand, what to do with other files which don't begin with the project name? Should they be confirmed and copied (as is), too? What about the backup files? I can see two use cases: rename the project (replace the old one); and copy the project to be a base for a new one. In the former case renaming and keeping about everything could be desired. In the latter case all but the basic project files would probably be ditched. In the case of renaming I'm also interested in knowing how it affects version control, for example git, if the project is a repository. That must be tested, I think. 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
Re: [Kicad-developers] Project save as
ma 11. marrask. 2019 klo 18.07 Wayne Stambaugh (stambau...@gmail.com) kirjoitti: > Isn't this this the same behavior as File->New? We should keep the path > creation behavior consistent. > It should be possible to use the same customized dialog then, right? Now it's different. 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
Re: [Kicad-developers] Project save as
I hope you don't mind I give some first impressions here. I can move these to bug database if needed. Before trying it's unclear what the file dialog selects. I created a new directory (with the name of the new project), went inside it and gave the project name in the dialog. "All files *.*" filter was available there. That is a hint that we are talking about a file. However, KiCad created a new directory inside the selected one and placed the renamed files there. I would like to see unambiguous information about what KiCad is going to do. In my opinion a dedicated dialog would be better. It would have: - A textbox and folder selection icon for the folder path. - A textbox for the new project name (only the name, no path, no file extensions). - Checkbox for "create a new folder with the project name". This would create a new folder inside the folder which was selected above. Maybe it would be best to have checkboxes for "copy and rename generated and unknown files". My use case this time is that I'm going to reuse part of the old project as a template. None of the generated files, backups etc. are used there. The current result is here (embedded picture). As you can see, it's uneven. Some gerber files were renamed, some not. (...Handle_Mainboard is the original name, ...TOF is the new). [image: image.png] Eeli Kaikkonen su 10. marrask. 2019 klo 0.31 Jeff Young (j...@rokeby.ie) kirjoitti: > He he… I know our users. I can be sure of a bug report even if I get it > right. ;) > > I never make reports about something which is done right :) > > This is exactly why I never tackled this one. Anytime your are trying > > to deal with complex relative path changes, the code gets rather messy. > > I doubt this will affect many users but you can be rest assured of a > > bug report if you get it wrong. > > > > > ___ > Mailing list: https://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
Now the example bug report ("Implicit 4-way junction" etc.) is correctly
attributed to "eelik".
Eeli Kaikkonen
su 10. marrask. 2019 klo 19.44 Maciej Suminski (maciej.sumin...@cern.ch)
kirjoitti:
> On 11/10/19 5:54 PM, Seth Hillbrand wrote:
> > On 2019-11-10 08:43, Seth Hillbrand wrote:
> >
> >> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
> >>
> >>> OK. Would it be worth re-importing everything even for this test
> database to avoid false impressions?
> >>>
> >>> Eeli Kaikkonen
> >>
> >> What false impression? Is there a report that is listed as being
> created by different people in launchpad vs. GitLab?
> >
> > Oops. Disregard. I see a broken report here:
> > https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367
> >
> > Looks like the Launchpad API doesn't handle users who have since deleted
> > their accounts nicely and the script is falling back on Fabien's
> > account, probably because his is index 0.
>
> Good catch, thanks! I think I have already found the bug, I will let you
> know after the next run is finished.
>
> Cheers,
> Orson
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GitLab migration
To make sure that we are talking about the same thing, here is indeed a bug report originally written by me in launchpad but attributed to some Fabien in this new database: https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7600 (screenshot attached in case you see it differently). su 10. marrask. 2019 klo 18.52 Eeli Kaikkonen (eeli.kaikko...@gmail.com) kirjoitti: > I got a false impression that importing the bug database currently has > some problem because those reports which I opened seemed to be written > originally by some mysterious username, while the subsequent comments were > correctly attributed. This led to me asking about it here. These kinds of > false impressions of bugs in the importing process could be avoided if it > was re-imported from scratch to create correct data (supposing that it was > a bug which orson fixed and now works correctly). > > Eeli Kaikkonen > > su 10. marrask. 2019 klo 18.43 Seth Hillbrand (s...@kipro-pcb.com) > kirjoitti: > >> On 2019-11-10 08:33, Eeli Kaikkonen wrote: >> >> OK. Would it be worth re-importing everything even for this test database >> to avoid false impressions? >> >> Eeli Kaikkonen >> >> >> What false impression? Is there a report that is listed as being created >> by different people in launchpad vs. GitLab? >> >> >> KiCad Services Corporation [image: KiCad Services Corporation Logo] >> Seth Hillbrand >> *Lead Developer* >> +1-530-302-5483 <+12126039372> >> Davis, CA >> www.kipro-pcb.comi...@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 Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GitLab migration
I got a false impression that importing the bug database currently has some problem because those reports which I opened seemed to be written originally by some mysterious username, while the subsequent comments were correctly attributed. This led to me asking about it here. These kinds of false impressions of bugs in the importing process could be avoided if it was re-imported from scratch to create correct data (supposing that it was a bug which orson fixed and now works correctly). Eeli Kaikkonen su 10. marrask. 2019 klo 18.43 Seth Hillbrand (s...@kipro-pcb.com) kirjoitti: > On 2019-11-10 08:33, Eeli Kaikkonen wrote: > > OK. Would it be worth re-importing everything even for this test database > to avoid false impressions? > > Eeli Kaikkonen > > > What false impression? Is there a report that is listed as being created > by different people in launchpad vs. GitLab? > > > KiCad Services Corporation [image: KiCad Services Corporation Logo] > Seth Hillbrand > *Lead Developer* > +1-530-302-5483 <+12126039372> > Davis, CA > www.kipro-pcb.comi...@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 Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GitLab migration
OK. Would it be worth re-importing everything even for this test database to avoid false impressions? Eeli Kaikkonen su 10. marrask. 2019 klo 18.27 Seth Hillbrand (s...@kipro-pcb.com) kirjoitti: > On 2019-11-10 08:17, Eeli Kaikkonen wrote: > > Who is this original reporter "Fabien Corona (drinasaur)" who created all > the reports? > > Eeli Kaikkonen > > > > Not all of the reports. Just a bunch of the recent ones prior to this > import. Here is one you created > <https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7100>. > > Click on the "Original Report" to see the reporter information in > launchpad. > > -Seth > > > KiCad Services Corporation [image: KiCad Services Corporation Logo] > Seth Hillbrand > *Lead Developer* > +1-530-302-5483 <+12126039372> > Davis, CA > www.kipro-pcb.comi...@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 Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GitLab migration
Who is this original reporter "Fabien Corona (drinasaur)" who created all the reports? Eeli Kaikkonen su 10. marrask. 2019 klo 0.08 Maciej Suminski (maciej.sumin...@cern.ch) kirjoitti: > I have fixed all issues, taking into account the ones reported on the > mailing list and Ian's 'Gitlab Issue Tracker Guidelines' [1]. In my > opinion, the bug tracker is ready to be moved to Gitlab. You can check > out the latest bug tracker migration in my test project [2]. > > Cheers, > Orson > > 1. > > https://docs.google.com/document/d/1GRFO6tIfecpg8tDjIJW8qHxv7cvp13t2GAgQf2zN254/edit?usp=sharing > 2. https://gitlab.com/orsonmmz/kicad-bug-tracker/issues > ___ Mailing list: https://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] Minimum Boost version
It should also be noted that 20.04 will be the next LTS release of Ubuntu. This means that there will be two post-16.04 LTS releases out there before KiCad 6 will be released (I'm not *that* optimistic :) ). Is it really worth it to actively support 3 different LTS releases? It doesn't sound very realistic. How many users would actually be affected if KiCad 6 wouldn't be available for 16.04? 1000s? 100s? 10? And if they continue with 16.04 until 2021, why would they need to switch to KiCad 6 before that? Eeli Kaikkonen ke 23. lokak. 2019 klo 3.05 Seth Hillbrand (s...@kipro-pcb.com) kirjoitti: > On 2019-10-22 16:06, Ian McInerney wrote: > > I dug into the website history and apparently the original intent should > have been to support 16.04 LTS until its standard support ends in 2021 ( > https://github.com/KiCad/kicad-website/commit/007fb582a316fa513778a393e2696d17c0031cea#r33487782). > Since we haven't actually used any code from the newer Boost version (that > we weren't already using), we should probably back out the change and also > update the website with the correct Ubuntu LTS support date. It looks like > that will make it so we can't update to 1.59 until 2021 then. > > > > Hi Ian- > > I did write that. In retrospect, I'm not sure that the sentiment is > correct. One of the things we are attempting to do is focus our primary > efforts where they will have the largest impact for our users. Toward that > end, we were attempting (in the post KiCon meeting) to define where that > cut off should be. We kind of arbitrary picked "vendor supported" as it > seemed reasonable. > > I now think we should tighten that a bit more for the Linux > distributions. Under MSW/Mac, we compile or have rolling updates for most > of our own dependencies. This allows us to ensure system compatibility but > not worry about library compatibility. The Linux library system is > different and holds back updates. > > So, why would we want to update the boost libraries and what does it gain > us? The original bump was to allow unit tests. During v6, I would also > like to utilize the UUID library from 1.60 as many of the feature we plan > will require GUID at least. > > This doesn't preclude using KiCad on 16.04. It just requires someone to > package a boost ppa. There are a few out there that could be used as > baselines for this. > > -Seth > > > KiCad Services Corporation [image: KiCad Services Corporation Logo] > Seth Hillbrand > *Lead Developer* > +1-530-302-5483 <+12126039372> > Davis, CA > www.kipro-pcb.comi...@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 > 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
to 17. lokak. 2019 klo 13.49 Marco Ciampa (ciam...@posteo.net) kirjoitti: > Are you aware of this?: > > https://www.theregister.co.uk/2019/10/16/gitlab_employees_gagged/ > > Those kind of disputes, negative and positive discrimination and the current global mindset of even mass-harrassing people and organizations who don't take a stance in those disputes make me tired. Would you like to see this list to turn into a political forum? Would you say "no" to people who would start talking politics here? Or should the KiCad licence have an exclusive exception for the users who you deem to be immoral? (Open Source or Free licences can't have such exceptions.) I'm interested in KiCad, not second-degree separation. ( “Second-degree separation means that if you find someone whom you think is theologically or ethically compromised, you must separate from that person, as well as from other people who have not separated from the first individual.” —John Woodbridge ) I'll stop here (otherwise I would contradict myself, if I haven't contradicted already). 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
Re: [Kicad-developers] GitLab migration
su 13. lokak. 2019 klo 4.10 Strontium (strnty...@gmail.com) kirjoitti: > My 2c > > "As Designed" should be the only answer. [...] > "Invalid" and "Not a Bug" cut off continued dialogue > and look dogmatic/arrogant. > On the other hand I have reported situations which I couldn't reproduce later. The "bug" description didn't actually describe KiCad's behavior. In that case Not a Bug would be more accurate. "As Designed" would be accurate where the bug description actually descibes the behavior, but it's intented. "Triaged" really isn't good. Launchpad explanation list have these descriptions: - > Confirmed: Verified by someone other than the reporter. - > Triaged: Verified by the bug supervisor. But "verified" isn't a good word for wishlist items, and who is a "bug supervisor"? Instead there could be something like "accepted, but not planned" for wishlist items which would mean that the (core) developers or people who can otherwise decide what is basically acceptable have accepted the basic idea and if someone - possibly a new developer - wants to implement it, it could be done (at least after further detailed discussion). It would imply that it has so low priority that it probably won't be implemented by the current development team, although anyone can take it under work later. That would give positive and meaningful signal for the reporter and for potential implementors: yes, a good idea, and if you want to implement it, it's safe to go on. 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
Re: [Kicad-developers] [RFC] Comments for a Layer Stack Manager in Pcbnew
ti 3. syysk. 2019 klo 21.48 Evan Shultz (evan.shu...@gmail.com) kirjoitti: > > 4. The "X" column is not salient. It is the only column header with a > popup, and that's required because the function is opaque. Along with the > comment above about expanding the table, using a more verbose term (or an > icon?) for this column would be nice. > 6. I don't see the value of the "Board thickness" textbox at the top left. > It changes the dielectric layer thicknesses when clicking the Set > Dielectric Thickness button, but it sets the thickness of all dielectric > layers equal. I have rarely seen this done in practice and never for an > impedance-controlled board. This button seems to be mainly of value for > simple boards with low layer counts. For a 2- or 4-layer board it's not > much of a burden for the user to set the dielectric thickness manually to > whatever they want, or leave it alone as the user probably doesn't care, > and I can't imagine a high layer count board using controlled impedances > having all dieletric layers with the same thickness. So this button doesn't > seem useful to me. It's likely I'm daft and just don't get it. > I don't know if you're daft or not, but likely you just didn't get it :) You already saw the X column. It locks the thickness. When you calculate automatically the space left after adding locked thicknesses together is used evenly for non-locked items. You can for example lock the thin layers in a 4-layer board and let KiCad calculate the core up to the user defined total thickness. I agree with your comments about visuals and usability. I can't say about the technical aspects, other than it would be cool to have layer thicknesses in the 3D view (as was suggested in the forum). 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
Re: [Kicad-developers] [RFC] Comments for a Layer Stack Manager in Pcbnew
Found it and it works. ti 3. syysk. 2019 klo 15.21 Simon Richter (simon.rich...@hogyros.de) kirjoitti: > Hi, > > > Are the binaries downloadable? I downloaded > > kicad-patched-495-762dabd75-x86_64.exe from > > > https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/testing/patched/ > > but pcbnew crashes before it opens. > > The binaries on the download server and on the Jenkins host (found under > "Artifacts") should be identical. > > The only thing that could explain a crash would be that I built with > Python3 enabled. I'm trying again with Python2, that will be #497. > >Simon > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [RFC] Comments for a Layer Stack Manager in Pcbnew
Are the binaries downloadable? I downloaded kicad-patched-495-762dabd75-x86_64.exe from https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/testing/patched/ but pcbnew crashes before it opens. Eeli Kaikkonen ma 2. syysk. 2019 klo 15.06 Simon Richter (simon.rich...@hogyros.de) kirjoitti: > Hi, > > > Please test and comment. > > I want to commit this feature soon. > > Builds on msys2 and msvc are on the way: > > https://jenkins.simonrichter.eu/job/windows-kicad-msys2-patch/495/ > https://jenkins.simonrichter.eu/job/windows-kicad-msvc-patch/142/ > > There should be binaries there for easier testing soon. > >Simon > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Selection Highlighting
For everone's information - there was user discussion in the forum: https://forum.kicad.info/t/selection-highlighting-in-development-version/18694 . Eeli Kaikkonen su 1. syysk. 2019 klo 6.32 Seth Hillbrand (s...@hillbrand.org) kirjoitti: > Hi Jeff (and others interested)- > > I pushed a proposal for blurring the eeschema selection highlighting to > my personal repo at [1]. Currently, I'm only blurring the Cairo > selections, so don't run this branch with OpenGL yet. > > I really like the new eeschema halo-for-selection paradigm but it does > suffer for legibility issues on small text. The blur of the halo fixes > this somewhat and gives the selection a smoother feel (imo). If folks > like it, I'll write up some shaders for OpenGL to do the same. The > performance doesn't seem bad on my machine, but I'd love additional > opinions/comments > > Best- > Seth > > [1] > https://code.launchpad.net/~sethh/kicad/+git/kicad/+ref/blur_highlight > > ___ > Mailing list: https://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
