Re: [Kicad-developers] Initial rc6 development.

+1 On 19/05/18 01:27, Seth Hillbrand wrote: ​I'll second Tom's suggestion here.  Distros are free to package KiCad how they like, but we can create an AppImage[1] with GTK2 and wxpython​ that users can download from the website.  This would provide a way for all users to run KiCad even if

Re: [Kicad-developers] Some speed up patches

OK thanks for the input. I'll push 1, 2 and 5. On 4), I didn't think it eliminated checks that were needed. If the zone updated, everything was checked as before. If only a track changed, it still checks zone->track but doesn't check zone->zone, zone->via or zone->pad. Is there a reason that

Re: [Kicad-developers] Some speed up patches

On 18/05/18 20:49, Seth Hillbrand wrote: > Gentle ping here.  If this doesn't interfere with your connectivity > algorithm work Tom, I'd like to merge these as they make routing the > board I'm working on now manageable (at least on my old machine). Hi Seth, I'm OK with patches 1, 2 and 5, feel

Re: [Kicad-developers] Initial rc6 development.

Hello Seth, Am 18.05.2018 um 22:27 schrieb Seth Hillbrand: > ​Carsten- > > I understand your concern and I think that this is valid.  I am not > proposing that we ignore distribution decisions (that would be very > counter-productive!)  And you are right, Debian works extremely well > with

Re: [Kicad-developers] 5.0 RC2 / release status

Hi Rene, On 05/18/2018 11:53 AM, Rene Pöschl wrote: > On 18/05/18 16:44, Wayne Stambaugh wrote: >> If any of our doc and library devs are on this mailing list, please >> forward this information so we aren't making major changes to the docs >> and libraries at the last minute. >> > > We have one

Re: [Kicad-developers] Initial rc6 development.

​Carsten- I understand your concern and I think that this is valid. I am not proposing that we ignore distribution decisions (that would be very counter-productive!) And you are right, Debian works extremely well with KiCad. Ubuntu 18.04, on the other hand is less pleasant. If we want v5.0

Re: [Kicad-developers] Initial rc6 development.

Hello Seth, Am 18.05.2018 um 19:27 schrieb Seth Hillbrand: > > ​I'll second Tom's suggestion here.  Distros are free to package KiCad > how they like, but we can create an AppImage[1] with GTK2 and wxpython​ > that users can download from the website.  This would provide a way for > all users to

Re: [Kicad-developers] Some speed up patches

Hey Seth, I had an issue where the zone wouldn’t refill at all after modification, leaving a zone that was visible in outline but not being connected to or filled in any way. I’ll try to replicate it tonight, as I’ve since removed the patches, and give a more detailed overview of what I’ve

Re: [Kicad-developers] Some speed up patches

Gentle ping here. If this doesn't interfere with your connectivity algorithm work Tom, I'd like to merge these as they make routing the board I'm working on now manageable (at least on my old machine). If you need more time to look it over, no worries. Just want to make sure it doesn't slip

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

You patch seems like a reasonable approach as an interim fix. Go ahead and merge it when you get a chance. Cheers, Wayne On 05/18/2018 10:52 AM, Maciej Sumiński wrote: > How about my patch? I do not dare to go for the ultimate solution right > now, but is it acceptable as a stop gap measure

Re: [Kicad-developers] Initial rc6 development.

I still think we should do the full canvas + toolset for 6.0… … or are we thinking we might port just the canvas change back to 5.0.1? >> … >> So my question is: >> It is possible to use the GAL itself (restricted to the graphic layer), and >> keep the current >> wxWidget management events in

Re: [Kicad-developers] Initial rc6 development.

For stable releases, I am not thrilled about steering users towards appimage, flatpak, snap, etc type solutions. They are fine for nightly builds for users who want to run multiple versions. On 05/18/2018 01:27 PM, Seth Hillbrand wrote: > > ​I'll second Tom's suggestion here.  Distros are free

Re: [Kicad-developers] Initial rc6 development.

On 05/18/2018 12:49 PM, Tomasz Wlostowski wrote: > On 18/05/18 18:42, jp charras wrote: >> Le 18/05/2018 à 17:51, Tomasz Wlostowski a écrit : >>> On 18/05/18 17:38, Wayne Stambaugh wrote: As we approach the v5 stable release, I want to discuss a something we should seriously consider

Re: [Kicad-developers] Initial rc6 development.

On 05/18/2018 01:13 PM, Jeff Young wrote: > I still think we should do the full canvas + toolset for 6.0… > > … or are we thinking we might port just the canvas change back to 5.0.1? I think back porting the gtk3 fixes to v5 is going to become more important pretty quickly. Most linux distros

Re: [Kicad-developers] Initial rc6 development.

​I'll second Tom's suggestion here. Distros are free to package KiCad how they like, but we can create an AppImage[1] with GTK2 and wxpython​ that users can download from the website. This would provide a way for all users to run KiCad even if their distro doesn't package the required libraries.

Re: [Kicad-developers] Initial rc6 development.

On 18/05/18 18:42, jp charras wrote: > Le 18/05/2018 à 17:51, Tomasz Wlostowski a écrit : >> On 18/05/18 17:38, Wayne Stambaugh wrote: >>> As we approach the v5 stable release, I want to discuss a something we >>> should seriously consider before we open the flood gates for new feature >>> merges

Re: [Kicad-developers] Initial rc6 development.

Le 18/05/2018 à 17:51, Tomasz Wlostowski a écrit : > On 18/05/18 17:38, Wayne Stambaugh wrote: >> As we approach the v5 stable release, I want to discuss a something we >> should seriously consider before we open the flood gates for new feature >> merges after the v5 branch. We are currently in

Re: [Kicad-developers] Initial rc6 development.

As far ad I understand it SWIG and SIP are not compatible, so sonethung is needed to transition to SIP, but given wxpython is pushing phoenix thay is what we need to do, and with that we also gain gtk3 support. fre. 18. maj 2018 18.13 skrev Wayne Stambaugh : > On 05/18/2018

Re: [Kicad-developers] Initial rc6 development.

On 05/18/2018 12:02 PM, Nick Østergaard wrote: > For wxpython, we "just" need to upgrade to phoenix, which supports gtk3. Has this been verified on all platforms? I thought there were issues with our use of swig and the use of sip by the phoenix project. If it's a drop in, all the better. > >

Re: [Kicad-developers] Initial rc6 development.

For wxpython, we "just" need to upgrade to phoenix, which supports gtk3. 2018-05-18 18:01 GMT+02:00 Wayne Stambaugh : > Hi Tom, > > > On 05/18/2018 11:51 AM, Tomasz Wlostowski wrote: > >> On 18/05/18 17:38, Wayne Stambaugh wrote: >> >>> As we approach the v5 stable release,

Re: [Kicad-developers] Initial rc6 development.

Hi Tom, On 05/18/2018 11:51 AM, Tomasz Wlostowski wrote: On 18/05/18 17:38, Wayne Stambaugh wrote: As we approach the v5 stable release, I want to discuss a something we should seriously consider before we open the flood gates for new feature merges after the v5 branch. We are currently in an

Re: [Kicad-developers] 5.0 RC2 / release status

On 18/05/18 16:44, Wayne Stambaugh wrote: If any of our doc and library devs are on this mailing list, please forward this information so we aren't making major changes to the docs and libraries at the last minute. We have one important pull request open that i will fix up my self tomorrow

Re: [Kicad-developers] Initial rc6 development.

On 18/05/18 17:38, Wayne Stambaugh wrote: > As we approach the v5 stable release, I want to discuss a something we > should seriously consider before we open the flood gates for new feature > merges after the v5 branch. We are currently in an awkward position > with regards to gtk3 builds on

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

Le 18/05/2018 à 17:35, Kristoffer Ödmark a écrit : > I think another stop gap measure is to have the ERC handle this, but > otherwise I am for Orson's patch. This is also my opinion. And Orson's patch is very acceptable. > > Better a defined bad behavior than an undefined random behavior is

[Kicad-developers] Initial rc6 development.

As we approach the v5 stable release, I want to discuss a something we should seriously consider before we open the flood gates for new feature merges after the v5 branch. We are currently in an awkward position with regards to gtk3 builds on Linux. Given that most distros are now building wx

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

I think another stop gap measure is to have the ERC handle this, but otherwise I am for Orsons patch. Better a defined bad behavior than an undefined random behavior is my opinion :) On Fri, May 18, 2018, 16:53 Maciej Sumiński wrote: > How about my patch? I do not dare

Re: [Kicad-developers] 5.0 RC2 / release status

MacOS is not 100% ready to go, but the large technical hurdles appear to be past us. Today I am working on adding OCE, which is a bit of a pain, but the massive Python packaging rework is building solidly and ngspice was just added. If anyone is interested in helping with the macOS packaging,

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

How about my patch? I do not dare to go for the ultimate solution right now, but is it acceptable as a stop gap measure for v5? Cheers, Orson On 05/18/2018 03:28 PM, Wayne Stambaugh wrote: > The suggestions made are all good and valid but I think to some extent > there will always be some

Re: [Kicad-developers] 5.0 RC2 / release status

Hey Jon, A really nasty bug[1] was putting rc2 on hold. The commit to fix it was just made yesterday. I was just getting ready to make a last call so hear goes. I plan on tagging rc2 on Sunday evening barring any more show stoppers. I have one last bug to fix (template paths) which I should

Re: [Kicad-developers] 5.0 RC2 / release status

Hi Jon, Welcome back! There was one very serious issue [1] blocking RC2, but fortunately it was fixed yesterday. Looking at the to-do list for v5 [2], there are three minor issues and two more serious bugs that may need some extra data from the reporters. It would be great to have the former two

[Kicad-developers] 5.0 RC2 / release status

Hi all, I've been mostly away from KiCad recently due to other things going on in life, but I have been trying to follow the mailing list at least. Seems like progress towards a RC2 release may have stalled, but it's not clear why. Meanwhile lots of small changes continue to go in to master (I

Re: [Kicad-developers] Another dialog preview

Nice work. This looks great! I wouldn't worry too much about the out of process apps. I suppose you could set up a file watcher in both kicad and the out of process app to update the preferences when the configuration or hotkey files change but that may be more work than it's worth. On

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

The suggestions made are all good and valid but I think to some extent there will always be some ambiguity. Users being users will make mistakes filling in field data which will cause issues when annotating and generating the netlist. In complex designs with lots of multiple units symbols it's

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

Hi Orson, The problem should become less prevalent over time: for 6.0 I plan on fixing the multi-sheet undo issues so that we can update all units in unison. (Of course that still fails if you edit before annotating as we then don’t know which units go with which.) But I agree that anytime

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

On 18.05.2018 11:14, Maciej Sumiński wrote: Hi, Recently I have found out that the netlist exporter uses an algorithm that for multiunit components uses non empty field values from the last processed unit [1]. The problem is that the processing order depends on the order of the units in the

Re: [Kicad-developers] Another dialog preview

I should mention one caveat: there’s a lot of preferences-specific code for getting/setting the various properties (they’re not all tied directly to wxConfigBase items), which means the panel implementations depend on application-specific code. When the preferences dialog is opened it

[Kicad-developers] Indeterministic netlist export for multiunit components

Hi, Recently I have found out that the netlist exporter uses an algorithm that for multiunit components uses non empty field values from the last processed unit [1]. The problem is that the processing order depends on the order of the units in the item list, so completely random. Instead, I

Re: [Kicad-developers] Another dialog preview

Nice, this is how a modern settings dialog should look like! Cheers, Orson On 05/17/2018 04:41 PM, Jeff Young wrote: > Just thought I’d share something from my 6.0 tree: > > > > > > > > > ___ > Mailing list: