No file formats will be harmed during any v5 point releases. ;) I'm
fine with rolling out a 5.1 with the gtk3 changes. I'm even willing to
include some of Jeff's dialog work. Any functional changes such as the
new file formats or the GALification of eeschema is all v6. The reason
we need to wor
+1.
If we do a 5.1 (and I think we should), file format changes would be a better
metric for ancillary additions.
This is of course self-serving: I have a bunch of great dialog changes that
could go in. ;)
Cheers,
Jeff.
> On 21 May 2018, at 00:55, Seth Hillbrand wrote:
>
> The discussion
The discussion of 5.x releases was delayed but perhaps seems relevant
again. Should we plan for a 5.1 release as Simon suggests with a goal of
working GTK3? I'm not sure that I agree with his preference for banning
non-GTK3 patches but I do have a preference for avoiding file format
changes dur
On 05/19/2018 09:36 AM, Simon Richter wrote:
> Hi,
>
> On 18.05.2018 17:38, Wayne Stambaugh wrote:
>
>> I propose we spend some time immediately after the v5 release
>> and fix the gtk3 issues before we start making major changes to the code
>> base so that it is not difficult to back port. An
Hi,
On 18.05.2018 17:38, Wayne Stambaugh wrote:
> I propose we spend some time immediately after the v5 release
> and fix the gtk3 issues before we start making major changes to the code
> base so that it is not difficult to back port. Anyone else have any
> thoughts on this?
We could make that
+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
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.
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
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 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
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
22 matches
Mail list logo
