+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 th
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 w
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 f
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 KiCad.
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
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 use
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
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 foun
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 thro
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 for
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 e
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 t
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 befo
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 ar
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.
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 a
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 an
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 12:02 PM, Nick Østerga
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.
>
>
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, I want to discuss a so
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
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 if
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 Linux
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 my
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 aga
I think another stop gap measure is to have the ERC handle this, but
otherwise I am for Orsons patch.
Better a defined bad behavior than an undefined random behavior is my
opinion :)
On Fri, May 18, 2018, 16:53 Maciej Sumiński wrote:
> How about my patch? I do not dare to go for the ultimate so
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, the
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 ambigui
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 get
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 b
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 d
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 05/18/20
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 no
Hi Orson,
The problem should become less prevalent over time: for 6.0 I plan on fixing
the multi-sheet undo issues so that we can update all units in unison. (Of
course that still fails if you edit before annotating as we then don’t know
which units go with which.)
But I agree that anytime we
On 18.05.2018 11:14, Maciej Sumiński wrote:
Hi,
Recently I have found out that the netlist exporter uses an algorithm
that for multiunit components uses non empty field values from the last
processed unit [1]. The problem is that the processing order depends on
the order of the units in the item
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 automati
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 propo
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: https://launchpad.net/~kicad-develope
38 matches
Mail list logo
