Re: [Kicad-developers] Initial rc6 development.

[Wayne Stambaugh]

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 work on this early in the v6 development cycle is that the
more v6 deviates from the v5 branch, the more difficult it becomes to
cherry pick changes.  The last few commits I cherry picked into the v4
branch were painful so I would like to avoid that as much as possible.

Cheers,

Wayne

On 05/20/2018 07:55 PM, Seth Hillbrand wrote:
> ​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 during 5.x releases.
> 
> -S
> 
> 
> 
> Am So., 20. Mai 2018 um 16:41 Uhr schrieb Wayne Stambaugh
> mailto:stambau...@gmail.com>>:
> 
> 
> 
> 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.  Anyone else have any
> >> thoughts on this?
> >
> > We could make that official, and just announce that the next release
> > after 5.0 will be 5.1, for which only GTK3 changes and bugfixes
> will be
> > accepted.
> 
> I would hope that the development team understands the issue.  I don't
> want KiCad to be unusable in a large number of modern Linux distros nor
> do a want the distro packagers to have to jump through a lot of hoops to
> get KiCad to build.  I would rather not have to drop the hammer but I
> could if it came to that.
> 
> Cheers,
> 
> Wayne
> 
> >
> >    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
> 

___
Mailing list: https://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] Initial rc6 development.

[Jeff Young]

+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 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 during 
> 5.x releases.
> 
> -S
> 
> 
> 
> Am So., 20. Mai 2018 um 16:41 Uhr schrieb Wayne Stambaugh 
> mailto:stambau...@gmail.com>>:
> 
> 
> 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.  Anyone else have any
> >> thoughts on this?
> > 
> > We could make that official, and just announce that the next release
> > after 5.0 will be 5.1, for which only GTK3 changes and bugfixes will be
> > accepted.
> 
> I would hope that the development team understands the issue.  I don't
> want KiCad to be unusable in a large number of modern Linux distros nor
> do a want the distro packagers to have to jump through a lot of hoops to
> get KiCad to build.  I would rather not have to drop the hammer but I
> could if it came to that.
> 
> Cheers,
> 
> Wayne
> 
> > 
> >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 
> 
> ___
> Mailing list: https://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] Initial rc6 development.

[Seth Hillbrand]

​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 during 5.x releases.

-S



Am So., 20. Mai 2018 um 16:41 Uhr schrieb Wayne Stambaugh <
stambau...@gmail.com>:

>
>
> 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.  Anyone else have any
> >> thoughts on this?
> >
> > We could make that official, and just announce that the next release
> > after 5.0 will be 5.1, for which only GTK3 changes and bugfixes will be
> > accepted.
>
> I would hope that the development team understands the issue.  I don't
> want KiCad to be unusable in a large number of modern Linux distros nor
> do a want the distro packagers to have to jump through a lot of hoops to
> get KiCad to build.  I would rather not have to drop the hammer but I
> could if it came to that.
>
> Cheers,
>
> Wayne
>
> >
> >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
>
___
Mailing list: https://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] Initial rc6 development.

[Wayne Stambaugh]

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.  Anyone else have any
>> thoughts on this?
> 
> We could make that official, and just announce that the next release
> after 5.0 will be 5.1, for which only GTK3 changes and bugfixes will be
> accepted.

I would hope that the development team understands the issue.  I don't
want KiCad to be unusable in a large number of modern Linux distros nor
do a want the distro packagers to have to jump through a lot of hoops to
get KiCad to build.  I would rather not have to drop the hammer but I
could if it came to that.

Cheers,

Wayne

> 
>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] Initial rc6 development.

[Simon Richter]

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 official, and just announce that the next release
after 5.0 will be 5.1, for which only GTK3 changes and bugfixes will be
accepted.

   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

Re: [Kicad-developers] Initial rc6 development.

[Strontium]

+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 their distro doesn't 
package the required libraries.  Bug reports on GTK3 could then be 
redirected to the AppImage download link.


-Seth

[1] https://appimage.org/


Am Fr., 18. Mai 2018 um 08:51 Uhr schrieb Tomasz Wlostowski 
mailto:tomasz.wlostow...@cern.ch>>:


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.  Given that most distros
are now
> building wx against gtk3, we really should work towards fixing
this at
> the beginning of v6 and back porting it as soon as possible so
that we
> can better support the current Linux distros. Fortunately, most
distros
> have thankfully provided a gtk2 build version of wx in order to
build
> kicad.  However, they have not done the same thing for wxpython
so for
> most new distro releases, we have to build kicad without wxpython
> support.  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?
>

Wayne,

I would put most of the effort on developing the GAL version of
eeschema. It's not our fault that Linux distros change the APIs of
essential system libraries every 2 years. As a short term solution, I
would propose distributing a distro-agnostic binary Kicad package that
includes all dependencies, including wx and gtk2 libraries. In the
longer run, GALified schematic editor is IMHO the way to go.

Best,
Tom



> Cheers,
>
> Wayne
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers

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

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

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


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

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

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

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



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



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

Re: [Kicad-developers] Initial rc6 development.

[Carsten Schoenert]

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.
> 
> Ubuntu 18.04, on the other hand is less pleasant.  If we want v5.0 users
> to have wxPython, we need either delay v5 in order to translate SWIG to
> SIP or make an AppImage/Flatpack thing.  Is there another option that
> I'm missing, apart from just ditching wxPython altogether?

Ubuntu is typically pulling packages from Debian testing and modifying
them if needed. So also happen to the KiCad packages from Debian testing
for Bionic. But Kicad on Debian testing is currently broken due the
symbol issues libwxgtk3.0-dev vs. libwxgtk3.0-gtk3-dev. Jeremy Bicha has
tried to fix this by doing a version 4.0.7+dfsg1-1ubuntu2 and has cherry
picked some changes from my current build setup for 5.0.0+rc1. But these
changes are pulling in the GTK+3 library libwxgtk3.0-gtk3 as dependency
for the kicad package. This itself isn't the problem as the root of the
problem is the wxpython package which is only available linked against
GTK+3.

I already would have uploaded the current 5.0.0+rc1 based packages
rebuild against GTK+2 libraries and disabled wxpython usage but right
now I can't build the documentation successfully so I can't upload
anything. The issue isn't the Kicad documentation itself but the current
set of texlive packages in Debian unstable. Ubuntu Bionic has already
disabled the build of documentation in version 4.0.7+dfsg1-1ubuntu1. But
I can't do this for Debian as this is a RC issue.

If someone wants to dig into the issue I posted the current problem on
kicad-doc-devs. I appreciate any help to solve the current build issue.

https://lists.launchpad.net/kicad-doc-devs/msg00128.html

-- 
Regards
Carsten Schoenert

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

Re: [Kicad-developers] Initial rc6 development.

[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.

Ubuntu 18.04, on the other hand is less pleasant.  If we want v5.0 users to
have wxPython, we need either delay v5 in order to translate SWIG to SIP or
make an AppImage/Flatpack thing.  Is there another option that I'm missing,
apart from just ditching wxPython altogether?

-S

Am Fr., 18. Mai 2018 um 12:51 Uhr schrieb Carsten Schoenert <
c.schoen...@t-online.de>:

> 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 run KiCad even if their distro doesn't package the required
> > libraries.  Bug reports on GTK3 could then be redirected to the AppImage
> > download link.
>
> please don't try to be clever that way and think twice before KiCad
> upstream will ignoring the decisions that are made by the Linux
> distributions. Such a behavior wouldn't be really distro friendly as
> proposed.
>
> GTK3+ was introduced in 2011 which is seven years from now, so it's not
> that this was changing every two years. And now we have already GTK4+
> available.
>
> Linux distributions are not really amused about shipped releases of
> software which are including embedded libraries as such things are a
> nightmare for supporting such software in a long term because they need
> to do then security fixes not only on the mainly shipped libraries
> packages but also in all package that are included a embedded copy. This
> isn't working really well and costs a lot of energy.
>
> From a Debian view the current state isn't that problematic as maybe
> someone is imagine. It's currently not clear if the dropping of GTK2+ is
> possible for the next release Buster (about one year from now). The
> freeze for the packages is in January 2019, this isn't that far away
> from now. My personal impression is that we will still have GTK2+
> related packages in Buster.
> The current stable release Stretch isn't a problem as the packages and
> versions are frozen.
>
> --
> Regards
> Carsten Schoenert
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Initial rc6 development.

[Carsten Schoenert]

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 run KiCad even if their distro doesn't package the required
> libraries.  Bug reports on GTK3 could then be redirected to the AppImage
> download link.

please don't try to be clever that way and think twice before KiCad
upstream will ignoring the decisions that are made by the Linux
distributions. Such a behavior wouldn't be really distro friendly as
proposed.

GTK3+ was introduced in 2011 which is seven years from now, so it's not
that this was changing every two years. And now we have already GTK4+
available.

Linux distributions are not really amused about shipped releases of
software which are including embedded libraries as such things are a
nightmare for supporting such software in a long term because they need
to do then security fixes not only on the mainly shipped libraries
packages but also in all package that are included a embedded copy. This
isn't working really well and costs a lot of energy.

From a Debian view the current state isn't that problematic as maybe
someone is imagine. It's currently not clear if the dropping of GTK2+ is
possible for the next release Buster (about one year from now). The
freeze for the packages is in January 2019, this isn't that far away
from now. My personal impression is that we will still have GTK2+
related packages in Buster.
The current stable release Stretch isn't a problem as the packages and
versions are frozen.

-- 
Regards
Carsten Schoenert

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

Re: [Kicad-developers] Initial rc6 development.

[Jeff Young]

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 eeschema and page layout editor (although the 
>> graphics in pl_editor
>> are so basic we can redraw the full screen without any optimization each 
>> time a object is moving).
> 
> Hi JP,
> 
> Yes, it should be possible with some modifications to the current event
> handling code (mostly removing XOR draw calls). I have partly written a
> GAL canvas renderer for eeschema some time ago, let me dig it up and
> post it on Github.
> 
> Tom
> 
>> 
>>> 
>>> Best,
>>> Tom
>>> 
>>> 
>>> 
 Cheers,
 
 Wayne
>> 
>> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Initial rc6 development.

[Wayne Stambaugh]

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 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.  Bug reports on GTK3 could then be redirected to the AppImage
> download link.
> 
> -Seth
> 
> [1] https://appimage.org/
> 
> 
> Am Fr., 18. Mai 2018 um 08:51 Uhr schrieb Tomasz Wlostowski
> mailto:tomasz.wlostow...@cern.ch>>:
> 
> 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.  Given that most distros are now
> > building wx against gtk3, we really should work towards fixing this at
> > the beginning of v6 and back porting it as soon as possible so that we
> > can better support the current Linux distros.  Fortunately, most
> distros
> > have thankfully provided a gtk2 build version of wx in order to build
> > kicad.  However, they have not done the same thing for wxpython so for
> > most new distro releases, we have to build kicad without wxpython
> > support.  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?
> >
> 
> Wayne,
> 
> I would put most of the effort on developing the GAL version of
> eeschema. It's not our fault that Linux distros change the APIs of
> essential system libraries every 2 years. As a short term solution, I
> would propose distributing a distro-agnostic binary Kicad package that
> includes all dependencies, including wx and gtk2 libraries. In the
> longer run, GALified schematic editor is IMHO the way to go.
> 
> Best,
> Tom
> 
> 
> 
> > Cheers,
> >
> > Wayne
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@lists.launchpad.net
> 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] Initial rc6 development.

[Wayne Stambaugh]

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 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 against gtk3, we really should work towards fixing this at
 the beginning of v6 and back porting it as soon as possible so that we
 can better support the current Linux distros.  Fortunately, most distros
 have thankfully provided a gtk2 build version of wx in order to build
 kicad.  However, they have not done the same thing for wxpython so for
 most new distro releases, we have to build kicad without wxpython
 support.  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?

>>>
>>> Wayne,
>>>
>>> I would put most of the effort on developing the GAL version of
>>> eeschema. It's not our fault that Linux distros change the APIs of
>>> essential system libraries every 2 years. As a short term solution, I
>>> would propose distributing a distro-agnostic binary Kicad package that
>>> includes all dependencies, including wx and gtk2 libraries. In the
>>> longer run, GALified schematic editor is IMHO the way to go.
>>
>> Hi Tom,
>>
>> When we are talking about GAL, we are actually talking about 2 different 
>> things:
>> 1 - the GAL itself, that is the graphic part of "GAL"
>> 2 - the new event management, that has nothing to do with the graphic layer 
>> itself.
>>
>> Using the new event management could be a much more amount of work than 
>> writing the  graphic layer
>> code only.
>>
>> 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 eeschema and page layout editor (although the 
>> graphics in pl_editor
>> are so basic we can redraw the full screen without any optimization each 
>> time a object is moving).
> 
> Hi JP,
> 
> Yes, it should be possible with some modifications to the current event
> handling code (mostly removing XOR draw calls). I have partly written a
> GAL canvas renderer for eeschema some time ago, let me dig it up and
> post it on Github.
> 
> Tom

How did you did code this?  I would think that it would be possible to
use a wxBitmapDC to draw upon and then blit it to the actual hardware
device context without any changes to drawing code (any thing derived
from wxDC can be passed to the drawing code).  This certainly would be
faster than drawing directly to the hardware device context.  The tricky
part with this in the past was getting the viewable area correct.  This
is how the legacy canvas in gerbview works (or at least it used to work
that way because rendering directly to the hardware device context was
too slow).

> 
>>
>>>
>>> Best,
>>> Tom
>>>
>>>
>>>
 Cheers,

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

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

Re: [Kicad-developers] Initial rc6 development.

[Wayne Stambaugh]

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 are already shipping gtk3
builds of wx and I don't see them supporting gtk2 forever.  I don't want
to be in a place where we are spending time maintaining a gtk2 build
just so we can have a workable solution on linux.  In the end, we will
have to support gtk3 even without the rendering issues.  I'm not sure
these wont be more problematic than the rendering.

> 
>>> …
> 
>>> 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 eeschema and page layout editor
>>> (although the graphics in pl_editor
>>> are so basic we can redraw the full screen without any optimization
>>> each time a object is moving).
>>
>> Hi JP,
>>
>> Yes, it should be possible with some modifications to the current event
>> handling code (mostly removing XOR draw calls). I have partly written a
>> GAL canvas renderer for eeschema some time ago, let me dig it up and
>> post it on Github.
>>
>> Tom
>>
>>>

 Best,
 Tom



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

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

Re: [Kicad-developers] Initial rc6 development.

[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 run KiCad even if their distro doesn't package the required
libraries.  Bug reports on GTK3 could then be redirected to the AppImage
download link.

-Seth

[1] https://appimage.org/


Am Fr., 18. Mai 2018 um 08:51 Uhr schrieb Tomasz Wlostowski <
tomasz.wlostow...@cern.ch>:

> 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.  Given that most distros are now
> > building wx against gtk3, we really should work towards fixing this at
> > the beginning of v6 and back porting it as soon as possible so that we
> > can better support the current Linux distros.  Fortunately, most distros
> > have thankfully provided a gtk2 build version of wx in order to build
> > kicad.  However, they have not done the same thing for wxpython so for
> > most new distro releases, we have to build kicad without wxpython
> > support.  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?
> >
>
> Wayne,
>
> I would put most of the effort on developing the GAL version of
> eeschema. It's not our fault that Linux distros change the APIs of
> essential system libraries every 2 years. As a short term solution, I
> would propose distributing a distro-agnostic binary Kicad package that
> includes all dependencies, including wx and gtk2 libraries. In the
> longer run, GALified schematic editor is IMHO the way to go.
>
> Best,
> Tom
>
>
>
> > Cheers,
> >
> > Wayne
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Initial rc6 development.

[Tomasz Wlostowski]

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 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 against gtk3, we really should work towards fixing this at
>>> the beginning of v6 and back porting it as soon as possible so that we
>>> can better support the current Linux distros.  Fortunately, most distros
>>> have thankfully provided a gtk2 build version of wx in order to build
>>> kicad.  However, they have not done the same thing for wxpython so for
>>> most new distro releases, we have to build kicad without wxpython
>>> support.  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?
>>>
>>
>> Wayne,
>>
>> I would put most of the effort on developing the GAL version of
>> eeschema. It's not our fault that Linux distros change the APIs of
>> essential system libraries every 2 years. As a short term solution, I
>> would propose distributing a distro-agnostic binary Kicad package that
>> includes all dependencies, including wx and gtk2 libraries. In the
>> longer run, GALified schematic editor is IMHO the way to go.
> 
> Hi Tom,
> 
> When we are talking about GAL, we are actually talking about 2 different 
> things:
> 1 - the GAL itself, that is the graphic part of "GAL"
> 2 - the new event management, that has nothing to do with the graphic layer 
> itself.
> 
> Using the new event management could be a much more amount of work than 
> writing the  graphic layer
> code only.
> 
> 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 eeschema and page layout editor (although the 
> graphics in pl_editor
> are so basic we can redraw the full screen without any optimization each time 
> a object is moving).

Hi JP,

Yes, it should be possible with some modifications to the current event
handling code (mostly removing XOR draw calls). I have partly written a
GAL canvas renderer for eeschema some time ago, let me dig it up and
post it on Github.

Tom

> 
>>
>> Best,
>> Tom
>>
>>
>>
>>> Cheers,
>>>
>>> Wayne
> 
> 


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

Re: [Kicad-developers] Initial rc6 development.

[jp charras]

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 awkward position
>> with regards to gtk3 builds on Linux.  Given that most distros are now
>> building wx against gtk3, we really should work towards fixing this at
>> the beginning of v6 and back porting it as soon as possible so that we
>> can better support the current Linux distros.  Fortunately, most distros
>> have thankfully provided a gtk2 build version of wx in order to build
>> kicad.  However, they have not done the same thing for wxpython so for
>> most new distro releases, we have to build kicad without wxpython
>> support.  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?
>>
> 
> Wayne,
> 
> I would put most of the effort on developing the GAL version of
> eeschema. It's not our fault that Linux distros change the APIs of
> essential system libraries every 2 years. As a short term solution, I
> would propose distributing a distro-agnostic binary Kicad package that
> includes all dependencies, including wx and gtk2 libraries. In the
> longer run, GALified schematic editor is IMHO the way to go.

Hi Tom,

When we are talking about GAL, we are actually talking about 2 different things:
1 - the GAL itself, that is the graphic part of "GAL"
2 - the new event management, that has nothing to do with the graphic layer 
itself.

Using the new event management could be a much more amount of work than writing 
the  graphic layer
code only.

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 eeschema and page layout editor (although the 
graphics in pl_editor
are so basic we can redraw the full screen without any optimization each time a 
object is moving).

> 
> Best,
> Tom
> 
> 
> 
>> Cheers,
>>
>> Wayne


-- 
Jean-Pierre CHARRAS

___
Mailing list: https://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] Initial rc6 development.

[Nick Østergaard]

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 Ø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.
>
> >
> > 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
> > 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 against gtk3, we really should work towards
> > fixing this at
> > the beginning of v6 and back porting it as soon as possible
> > so that we
> > can better support the current Linux distros.  Fortunately,
> > most distros
> > have thankfully provided a gtk2 build version of wx in order
> > to build
> > kicad.  However, they have not done the same thing for
> > wxpython so for
> > most new distro releases, we have to build kicad without
> > wxpython
> > support.  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?
> >
> >
> > Wayne,
> >
> > I would put most of the effort on developing the GAL version of
> > eeschema. It's not our fault that Linux distros change the APIs
> of
> > essential system libraries every 2 years. As a short term
> > solution, I
> > would propose distributing a distro-agnostic binary Kicad
> > package that
> > includes all dependencies, including wx and gtk2 libraries. In
> the
> > longer run, GALified schematic editor is IMHO the way to go.
> >
> > Best,
> > Tom
> >
> >
> > This still doesn't address the wxpython issue or the fact that v5
> > will always have to support gtk2.  Given our current stable release
> > turnover, it could (will?) be a few years before v6 is released.  It
> > also doesn't address the fact that the legacy canvas in eeschema
> > which will be part of v6 will require gtk2.  While a agree that this
> > is going to be a PITA, I just don't see how we can avoid it.
> >
> >
> >
> >
> >
> > Cheers,
> >
> > Wayne
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > 
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > More help   : https://help.launchpad.net/ListHelp
> > 
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > 
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > More help   : https://help.launchpad.net/ListHelp
> > 
> >
> >
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Initial rc6 development.

[Wayne Stambaugh]

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.

> 
> 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
> 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 against gtk3, we really should work towards
> fixing this at
> the beginning of v6 and back porting it as soon as possible
> so that we
> can better support the current Linux distros.  Fortunately,
> most distros
> have thankfully provided a gtk2 build version of wx in order
> to build
> kicad.  However, they have not done the same thing for
> wxpython so for
> most new distro releases, we have to build kicad without
> wxpython
> support.  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?
> 
> 
> Wayne,
> 
> I would put most of the effort on developing the GAL version of
> eeschema. It's not our fault that Linux distros change the APIs of
> essential system libraries every 2 years. As a short term
> solution, I
> would propose distributing a distro-agnostic binary Kicad
> package that
> includes all dependencies, including wx and gtk2 libraries. In the
> longer run, GALified schematic editor is IMHO the way to go.
> 
> Best,
> Tom
> 
> 
> This still doesn't address the wxpython issue or the fact that v5
> will always have to support gtk2.  Given our current stable release
> turnover, it could (will?) be a few years before v6 is released.  It
> also doesn't address the fact that the legacy canvas in eeschema
> which will be part of v6 will require gtk2.  While a agree that this
> is going to be a PITA, I just don't see how we can avoid it.
> 
> 
> 
> 
> 
> Cheers,
> 
> Wayne
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 

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

Re: [Kicad-developers] Initial rc6 development.

[Nick Østergaard]

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 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 against gtk3, we really should work towards fixing this at
>>> the beginning of v6 and back porting it as soon as possible so that we
>>> can better support the current Linux distros.  Fortunately, most distros
>>> have thankfully provided a gtk2 build version of wx in order to build
>>> kicad.  However, they have not done the same thing for wxpython so for
>>> most new distro releases, we have to build kicad without wxpython
>>> support.  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?
>>>
>>>
>> Wayne,
>>
>> I would put most of the effort on developing the GAL version of
>> eeschema. It's not our fault that Linux distros change the APIs of
>> essential system libraries every 2 years. As a short term solution, I
>> would propose distributing a distro-agnostic binary Kicad package that
>> includes all dependencies, including wx and gtk2 libraries. In the
>> longer run, GALified schematic editor is IMHO the way to go.
>>
>> Best,
>> Tom
>>
>
> This still doesn't address the wxpython issue or the fact that v5 will
> always have to support gtk2.  Given our current stable release turnover, it
> could (will?) be a few years before v6 is released.  It also doesn't
> address the fact that the legacy canvas in eeschema which will be part of
> v6 will require gtk2.  While a agree that this is going to be a PITA, I
> just don't see how we can avoid it.
>
>
>
>>
>>
>> Cheers,
>>>
>>> Wayne
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Initial rc6 development.

[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 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 against gtk3, we really should work towards fixing this at
the beginning of v6 and back porting it as soon as possible so that we
can better support the current Linux distros.  Fortunately, most distros
have thankfully provided a gtk2 build version of wx in order to build
kicad.  However, they have not done the same thing for wxpython so for
most new distro releases, we have to build kicad without wxpython
support.  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?



Wayne,

I would put most of the effort on developing the GAL version of
eeschema. It's not our fault that Linux distros change the APIs of
essential system libraries every 2 years. As a short term solution, I
would propose distributing a distro-agnostic binary Kicad package that
includes all dependencies, including wx and gtk2 libraries. In the
longer run, GALified schematic editor is IMHO the way to go.

Best,
Tom


This still doesn't address the wxpython issue or the fact that v5 will 
always have to support gtk2.  Given our current stable release turnover, 
it could (will?) be a few years before v6 is released.  It also doesn't 
address the fact that the legacy canvas in eeschema which will be part 
of v6 will require gtk2.  While a agree that this is going to be a PITA, 
I just don't see how we can avoid it.







Cheers,

Wayne


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





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

Re: [Kicad-developers] Initial rc6 development.

[Tomasz Wlostowski]

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.  Given that most distros are now
> building wx against gtk3, we really should work towards fixing this at
> the beginning of v6 and back porting it as soon as possible so that we
> can better support the current Linux distros.  Fortunately, most distros
> have thankfully provided a gtk2 build version of wx in order to build
> kicad.  However, they have not done the same thing for wxpython so for
> most new distro releases, we have to build kicad without wxpython
> support.  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?
> 

Wayne,

I would put most of the effort on developing the GAL version of
eeschema. It's not our fault that Linux distros change the APIs of
essential system libraries every 2 years. As a short term solution, I
would propose distributing a distro-agnostic binary Kicad package that
includes all dependencies, including wx and gtk2 libraries. In the
longer run, GALified schematic editor is IMHO the way to go.

Best,
Tom



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


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

[Kicad-developers] Initial rc6 development.

[Wayne Stambaugh]

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 against gtk3, we really should work towards fixing this at
the beginning of v6 and back porting it as soon as possible so that we
can better support the current Linux distros.  Fortunately, most distros
have thankfully provided a gtk2 build version of wx in order to build
kicad.  However, they have not done the same thing for wxpython so for
most new distro releases, we have to build kicad without wxpython
support.  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?

Cheers,

Wayne


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