date:20180716

This bug is annoying but not terribly important.  There is also bug in
one of the footprint editor dialogs that also needs fixed so we might as
well queue a few bug fixes up for a 5.0.1 release in a few weeks and get
the 5.0.0 release out on time.

On 7/16/2018 3:10 PM, Seth Hillbrand wrote:
> Should we just tag v5.0.1 right now then and ignore 5.0.0?
> 
> Is there any reason not to do that?
> 
> Am Mo., 16. Juli 2018 um 11:55 Uhr schrieb Wayne Stambaugh
> mailto:stambau...@gmail.com>>:
> 
> Hey Carsten,
> 
> On 7/16/2018 2:46 PM, Carsten Schoenert wrote:
> > Hello Wayne,
> >
> > Am 16.07.18 um 20:20 schrieb Wayne Stambaugh:
> >> There is a fix for a bug[1] that I thought we had taken care that
> >> slipped through the cracks.  This really should have been fixed
> as part
> >> of the v5 release.  If there are no objections, I'm going to
> revert the
> >> v5 tags and version string and add this patch to v5.  Until then,
> please
> >> do not merge anything into the development, 5.0, or 5.1 branches.
> >>
> >> Jeff, unfortunately this will mean that I will have to overwrite your
> >> 5.1 merge work so all of the branches are the same.  I don't
> think this
> >> will be a major issue other than the hassle of having to merge
> your work
> >> again.
> >>
> >> Sorry about the disruption.
> >
> > please don't do that, such things are a no go. Just do a new
> version tag
> > like 5.0.1. No serious OSS project does such things you are asking
> about.
> 
> I've never claimed that KiCad was a serious project ;)
> 
> >
> > You don't want to force other people to do work again once there is a
> > tagged version!
> 
> That's why I asked.  If other folks are already doing work based on the
> current 5.0.0 tag, then I will leave it as is and make this patch part
> of the 5.0.1 release.
> 
> >
> > Once a version is out, well it's out! And he, what's the problem
> with a
> > new micro/patch version, they are exactly made for such reasons.
> >
> > https://semver.org/
> >
> 
> ___
> 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 branch

2018-07-16 Thread Maciej Suminski

Whew, I think that was ~1200 bugs fixed/feature requests handled. Well
done, team! Now let's sweep our mailboxes..

Cheers,
Orson

On 07/16/2018 06:14 PM, Jeff Young wrote:
> I started doing some by hand and Orson is right: tedious isn’t the half of 
> it.  I’ll wait for his script. ;)
> 
> 
>> On 16 Jul 2018, at 16:59, Wayne Stambaugh  wrote:
>>
>> My finger is on the delete key.  Fire when ready!
>>
>> On 7/16/2018 11:48 AM, Maciej Sumiński wrote:
>>> I have the script ready to run. It will just change all KiCad bug
>>> statuses from 'Fix Committed' to 'Fix Release'. I assume there are no
>>> bugs that are marked as 'Fix Committed', but not actually in the master
>>> branch, right? Are you ready for an infinite stream of bug tracker
>>> notifications? :>
>>>
>>> Cheers,
>>> Orson
>>>
>>> On 07/16/2018 05:13 PM, Wayne Stambaugh wrote:
 That would probably be the easiest solution with the least amount of
 risk.  Although you could not run it for point releases because bugs
 that are only valid for the development branch would get set to fix
 released which would not be correct.

 On 7/16/2018 11:08 AM, Maciej Sumiński wrote:
> It is terribly tedious to go through the bug list and change statuses
> one by one, so I offer to help with the bug report status fiddling. We
> may employ Janitor, but I guess it would be better to execute a simple
> script to change Fix Committed->Fix Released whenever we release a new
> version.
>
> Cheers,
> Orson
>
> On 07/16/2018 03:30 PM, Wayne Stambaugh wrote:
>> Hey Jeff,
>>
>> We have been manually changing the bug status from fix committed to fix
>> released after a new stable release.  AFAIK, the janitor does not handle
>> this.  I suppose the janitor could be modified to test for a new release
>> and change the tag for all bugs associated with that release.  That
>> would not be 100% accurate because there are bugs that have not been
>> associated with a branch but that would probably be easier than changing
>> them all manually.  I don't have a strong preference one way or the 
>> other.
>>
>> Wayne
>>
>> On 7/16/2018 9:20 AM, Jeff Young wrote:
>>> Hi Wayne,
>>>
>>> The other issue is that the Janitor is going to mark my fixes as Fix 
>>> Committed, and I don’t know if the auto-bug-release facility is smart 
>>> enough to check the milestone before converting Fix Committed to Fix 
>>> Released.  So we may need to do that first too.
>>>
>>> Cheers,
>>> Jeff.
>>>
 On 16 Jul 2018, at 14:15, Wayne Stambaugh  wrote:

 Jeff,

 As a general rule, we merge changes into the development branch and 
 then
 merge them into the stable release branch after they have been tested.
 In the past this has only been bug fixes so your case is slightly
 different.  The problem I see with merging your changes into the 5.1
 branch first is that they will not get as much testing as they would if
 you merged your changes into the development branch.  I would prefer
 that we merge changes into the development branch so that nightly 
 builds
 can be used to get some good testing.  Any bug fixes to your changes 
 can
 then be merged into the 5.1 branch.  Does anyone see any reason not to
 do it this way?

 Please do not merge your changes into the development branch just yet.
 Orson just fixed a bug and I'm considering retagging v5 to include 
 this fix.

 Cheers,

 Wayne

 On 7/16/2018 5:05 AM, Jeff Young wrote:
> Thanks, JP!  I’ll make the fix.
>
>> On 16 Jul 2018, at 09:24, jp charras  wrote:
>>
>> Le 16/07/2018 à 10:10, Jeff Young a écrit :
>>> Well, rats.  I couldn’t figure out why "git rebase —interactive" 
>>> wasn’t showing me any of my
>>> commits, and it turns out that I somehow accidentally merged them 
>>> all to origin/5.1 sometime last
>>> night.  Anyway, you don’t have to fetch my private branch to test 
>>> it anymore; the kicad 5.1 branch
>>> will do nicely.
>>>
>>> Let me know if the paged dialog issues are keeping anyone from 
>>> getting work done and I’ll try to
>>> figure out how to revert those commits.
>>
>> Hi, Jeff
>> The paged dialog issue is due to the fact the panels (pages) have an 
>> incorrect parent.
>> Currently, these panels have the dialog itself as parent.
>> They should have m_treebook (the wxTreeBook similar to a wxNotebook) 
>> as parent.
>>
>> (This change fixes the issue on W7)
>>
>>>
>>> Cheers,
>>> Jeff.
>>
>> -- 
>> Jean-Pierre

Re: [Kicad-developers] Version 5 source update

2018-07-16 Thread Seth Hillbrand

Should we just tag v5.0.1 right now then and ignore 5.0.0?

Is there any reason not to do that?

Am Mo., 16. Juli 2018 um 11:55 Uhr schrieb Wayne Stambaugh <
stambau...@gmail.com>:

> Hey Carsten,
>
> On 7/16/2018 2:46 PM, Carsten Schoenert wrote:
> > Hello Wayne,
> >
> > Am 16.07.18 um 20:20 schrieb Wayne Stambaugh:
> >> There is a fix for a bug[1] that I thought we had taken care that
> >> slipped through the cracks.  This really should have been fixed as part
> >> of the v5 release.  If there are no objections, I'm going to revert the
> >> v5 tags and version string and add this patch to v5.  Until then, please
> >> do not merge anything into the development, 5.0, or 5.1 branches.
> >>
> >> Jeff, unfortunately this will mean that I will have to overwrite your
> >> 5.1 merge work so all of the branches are the same.  I don't think this
> >> will be a major issue other than the hassle of having to merge your work
> >> again.
> >>
> >> Sorry about the disruption.
> >
> > please don't do that, such things are a no go. Just do a new version tag
> > like 5.0.1. No serious OSS project does such things you are asking about.
>
> I've never claimed that KiCad was a serious project ;)
>
> >
> > You don't want to force other people to do work again once there is a
> > tagged version!
>
> That's why I asked.  If other folks are already doing work based on the
> current 5.0.0 tag, then I will leave it as is and make this patch part
> of the 5.0.1 release.
>
> >
> > Once a version is out, well it's out! And he, what's the problem with a
> > new micro/patch version, they are exactly made for such reasons.
> >
> > https://semver.org/
> >
>
> ___
> 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 UI feedback

Le 16/07/2018 à 18:25, Jeff Young a écrit :
> Hi JP,
> 
> Thanks for the feedback.
> 
>> On 16 Jul 2018, at 16:05, jp charras  wrote:
>>
>> Hi Jeff,
>>
>> I just played with a few of your 5.1 changes.
>>
>> Many are good, but the new netclass management is not as efficient as the 
>> current dialog:
>>
>> - Modifying the netclass of a lot of nets is very tedious: the change must 
>> be done for each net
>> (this is the major issue).
> 
> I’d like to see if there’s some other way to handle lots of nets.  The 
> double-list method was 
> very hard to figure out how to use (although admittedly very efficient once 
> you did).
> 
>> - we cannot see easily the list of nets, as the netclass filter was removed.
> 
> Interesting.  I had never used it for that, but I can see how it would be 
> helpful.
> 
>> However the net filter is a good idea.
>>
>> I am also thinking the "Board Setup" menu should be in the main menu bar, 
>> not in the file menu (this
>> is a very important setting, not related to a file management)
> 
> My thinking was it was sort of like Page Setup.  I’m not terribly attached to 
> the File menu, but 
> I'd rather avoid a stumpy menu with just a single item.  Preferences doesn’t 
> fit well either.  Edit 
> or Tools perhaps?

The main toolbar is for me the best choice.
Moreover if (or when) netclasses will take in account the layers and the 
netclass management is more
powerful, I am guessing this setup will be frequently modified, so it deserves 
a easy and fast access.

An other enhancement in this kind of dialog could be to reopen the paged dialog 
to the last opened
page during a session.

> 
> (I changed the subject line so this wouldn’t get drowned in the other 5.1 
> stuff.)
> 
>>
>>
>> Thanks for your work.
>>
>> -- 
>> Jean-Pierre CHARRAS


-- 
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] Version 5 source update

Hey Carsten,

On 7/16/2018 2:46 PM, Carsten Schoenert wrote:
> Hello Wayne,
> 
> Am 16.07.18 um 20:20 schrieb Wayne Stambaugh:
>> There is a fix for a bug[1] that I thought we had taken care that
>> slipped through the cracks.  This really should have been fixed as part
>> of the v5 release.  If there are no objections, I'm going to revert the
>> v5 tags and version string and add this patch to v5.  Until then, please
>> do not merge anything into the development, 5.0, or 5.1 branches.
>>
>> Jeff, unfortunately this will mean that I will have to overwrite your
>> 5.1 merge work so all of the branches are the same.  I don't think this
>> will be a major issue other than the hassle of having to merge your work
>> again.
>>
>> Sorry about the disruption.
> 
> please don't do that, such things are a no go. Just do a new version tag
> like 5.0.1. No serious OSS project does such things you are asking about.

I've never claimed that KiCad was a serious project ;)

> 
> You don't want to force other people to do work again once there is a
> tagged version!

That's why I asked.  If other folks are already doing work based on the
current 5.0.0 tag, then I will leave it as is and make this patch part
of the 5.0.1 release.

> 
> Once a version is out, well it's out! And he, what's the problem with a
> new micro/patch version, they are exactly made for such reasons.
> 
> https://semver.org/
> 

___
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] Version 5 source update

2018-07-16 Thread Carsten Schoenert

Hello Wayne,

Am 16.07.18 um 20:20 schrieb Wayne Stambaugh:
> There is a fix for a bug[1] that I thought we had taken care that
> slipped through the cracks.  This really should have been fixed as part
> of the v5 release.  If there are no objections, I'm going to revert the
> v5 tags and version string and add this patch to v5.  Until then, please
> do not merge anything into the development, 5.0, or 5.1 branches.
> 
> Jeff, unfortunately this will mean that I will have to overwrite your
> 5.1 merge work so all of the branches are the same.  I don't think this
> will be a major issue other than the hassle of having to merge your work
> again.
> 
> Sorry about the disruption.

please don't do that, such things are a no go. Just do a new version tag
like 5.0.1. No serious OSS project does such things you are asking about.

You don't want to force other people to do work again once there is a
tagged version!

Once a version is out, well it's out! And he, what's the problem with a
new micro/patch version, they are exactly made for such reasons.

https://semver.org/

-- 
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] Version 5 source update

No worries.  I can merge first to master this way and then pull back to 5.1.

> On 16 Jul 2018, at 19:20, Wayne Stambaugh  wrote:
> 
> There is a fix for a bug[1] that I thought we had taken care that
> slipped through the cracks.  This really should have been fixed as part
> of the v5 release.  If there are no objections, I'm going to revert the
> v5 tags and version string and add this patch to v5.  Until then, please
> do not merge anything into the development, 5.0, or 5.1 branches.
> 
> Jeff, unfortunately this will mean that I will have to overwrite your
> 5.1 merge work so all of the branches are the same.  I don't think this
> will be a major issue other than the hassle of having to merge your work
> again.
> 
> Sorry about the disruption.
> 
> 
> [1]: https://bugs.launchpad.net/kicad/+bug/1781761
> 
> ___
> 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 UI feedback

Le 16/07/2018 à 19:57, Jeff Young a écrit :
> 
> 
>> On 16 Jul 2018, at 17:56, jp charras > > wrote:
>>
>> Le 16/07/2018 à 18:25, Jeff Young a écrit :
>>> Hi JP,
>>>
>>> Thanks for the feedback.
>>>
 On 16 Jul 2018, at 16:05, jp charras >>> > wrote:

 Hi Jeff,

 I just played with a few of your 5.1 changes.

 Many are good, but the new netclass management is not as efficient as the 
 current dialog:

 - Modifying the netclass of a lot of nets is very tedious: the change must 
 be done for each net
 (this is the major issue).
>>>
>>> I’d like to see if there’s some other way to handle lots of nets.  The 
>>> double-list method was 
>>> very hard to figure out how to use (although admittedly very efficient once 
>>> you did).
>>>
 - we cannot see easily the list of nets, as the netclass filter was 
 removed.
>>>
>>> Interesting.  I had never used it for that, but I can see how it would be 
>>> helpful.
>>>
 However the net filter is a good idea.

 I am also thinking the "Board Setup" menu should be in the main menu bar, 
 not in the file menu (this
 is a very important setting, not related to a file management)
>>>
>>> My thinking was it was sort of like Page Setup.  I’m not terribly attached 
>>> to the File menu, but 
>>> I'd rather avoid a stumpy menu with just a single item.  Preferences 
>>> doesn’t fit well either.  Edit 
>>> or Tools perhaps?
>>
>> The main toolbar is for me the best choice.
> 
> I can definitely agree with main /tool/bar, but your first message mentioned 
> /menu/bar, so I’m not sure
> which is a typo.

Not really a typo, but "Board Setup..." is a menuitem, so I talked about the 
main menubar
(wxMenuBar) because a wxMenuItem lives is a wxMenuBar.
I am also fine with a tool in the main horizontal toolbar (wxToolBar), as long 
as the acces is very
easy and obvious.

> 
> In any case, the first item in a menu is actually the hardest to pick (with 
> the second being the
> easiest,
> then the third, fourth, etc.).
> 
>> Moreover if (or when) netclasses will take in account the layers and the 
>> netclass management is more
>> powerful, I am guessing this setup will be frequently modified, so it 
>> deserves a easy and fast access.
>>
>> An other enhancement in this kind of dialog could be to reopen the paged 
>> dialog to the last opened
>> page during a session.
> 
> Is this not working?  There’s code in there to do that….

Yes it works.
I don't understand why I was in the impression it was not working.
Sorry.


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

[Kicad-developers] Version 5 source update

There is a fix for a bug[1] that I thought we had taken care that
slipped through the cracks.  This really should have been fixed as part
of the v5 release.  If there are no objections, I'm going to revert the
v5 tags and version string and add this patch to v5.  Until then, please
do not merge anything into the development, 5.0, or 5.1 branches.

Jeff, unfortunately this will mean that I will have to overwrite your
5.1 merge work so all of the branches are the same.  I don't think this
will be a major issue other than the hassle of having to merge your work
again.

Sorry about the disruption.


[1]: https://bugs.launchpad.net/kicad/+bug/1781761

___
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 UI feedback



> On 16 Jul 2018, at 17:56, jp charras  wrote:
> 
> Le 16/07/2018 à 18:25, Jeff Young a écrit :
>> Hi JP,
>> 
>> Thanks for the feedback.
>> 
>>> On 16 Jul 2018, at 16:05, jp charras  wrote:
>>> 
>>> Hi Jeff,
>>> 
>>> I just played with a few of your 5.1 changes.
>>> 
>>> Many are good, but the new netclass management is not as efficient as the 
>>> current dialog:
>>> 
>>> - Modifying the netclass of a lot of nets is very tedious: the change must 
>>> be done for each net
>>> (this is the major issue).
>> 
>> I’d like to see if there’s some other way to handle lots of nets.  The 
>> double-list method was 
>> very hard to figure out how to use (although admittedly very efficient once 
>> you did).
>> 
>>> - we cannot see easily the list of nets, as the netclass filter was removed.
>> 
>> Interesting.  I had never used it for that, but I can see how it would be 
>> helpful.
>> 
>>> However the net filter is a good idea.
>>> 
>>> I am also thinking the "Board Setup" menu should be in the main menu bar, 
>>> not in the file menu (this
>>> is a very important setting, not related to a file management)
>> 
>> My thinking was it was sort of like Page Setup.  I’m not terribly attached 
>> to the File menu, but 
>> I'd rather avoid a stumpy menu with just a single item.  Preferences doesn’t 
>> fit well either.  Edit 
>> or Tools perhaps?
> 
> The main toolbar is for me the best choice.

I can definitely agree with main toolbar, but your first message mentioned 
menubar, so I’m not sure
which is a typo.

In any case, the first item in a menu is actually the hardest to pick (with the 
second being the easiest,
then the third, fourth, etc.).

> Moreover if (or when) netclasses will take in account the layers and the 
> netclass management is more
> powerful, I am guessing this setup will be frequently modified, so it 
> deserves a easy and fast access.
> 
> An other enhancement in this kind of dialog could be to reopen the paged 
> dialog to the last opened
> page during a session.

Is this not working?  There’s code in there to do that….

> 
>> 
>> (I changed the subject line so this wouldn’t get drowned in the other 5.1 
>> stuff.)
>> 
>>> 
>>> 
>>> Thanks for your work.
>>> 
>>> -- 
>>> Jean-Pierre CHARRAS
> 
> 
> -- 
> 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 
> 
___
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] kicad version and install location

2018-07-16 Thread Andy Peters

On Jul 16, 2018, at 10:22 AM, Mark Roszko  wrote:
> 
> Yeathats what I proposed too.
> 
> Every program on Windows that needs side-by-side installs just
> versions both the config and install locations. Thats it.
> 
> EAGLE does it.
> Visual Studio does.
> Altium does it.
> CLion does it.
> All of Jetbrains other product do it.
> Microsoft Word does it
> Adobe does it.
> Python does it.
> MSSQL does it.
> 
> 
> No need for crazy launcher args and extreme actions such as doing
> something like RVM does
> 
> All that needs to be done, is find all instances of wxStandardPaths
> being used for config location.
> Replace it with a standard static function helper. In the helper, it
> appends a version number to the location.
> 
> Thats it. Done. No need to require users to understand command line to
> use a program.
> 
> It works for linux too.
> /home/user/.kicad/
> becomes
> /home/user/.kicad/5.1/

And on the Mac that would be

/Users/andy/Library/Application Support/kicad 

becomes

/Users/andy/Library/Application Support/kicad/5.1

and /Users/andy/Library/Preferences/kicad 

becomes 

/Users/andy/Library/Preferences/kicad/5.1

-a

___
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 branch

I have the script ready to run. It will just change all KiCad bug
statuses from 'Fix Committed' to 'Fix Release'. I assume there are no
bugs that are marked as 'Fix Committed', but not actually in the master
branch, right? Are you ready for an infinite stream of bug tracker
notifications? :>

Cheers,
Orson

On 07/16/2018 05:13 PM, Wayne Stambaugh wrote:
> That would probably be the easiest solution with the least amount of
> risk.  Although you could not run it for point releases because bugs
> that are only valid for the development branch would get set to fix
> released which would not be correct.
> 
> On 7/16/2018 11:08 AM, Maciej Sumiński wrote:
>> It is terribly tedious to go through the bug list and change statuses
>> one by one, so I offer to help with the bug report status fiddling. We
>> may employ Janitor, but I guess it would be better to execute a simple
>> script to change Fix Committed->Fix Released whenever we release a new
>> version.
>>
>> Cheers,
>> Orson
>>
>> On 07/16/2018 03:30 PM, Wayne Stambaugh wrote:
>>> Hey Jeff,
>>>
>>> We have been manually changing the bug status from fix committed to fix
>>> released after a new stable release.  AFAIK, the janitor does not handle
>>> this.  I suppose the janitor could be modified to test for a new release
>>> and change the tag for all bugs associated with that release.  That
>>> would not be 100% accurate because there are bugs that have not been
>>> associated with a branch but that would probably be easier than changing
>>> them all manually.  I don't have a strong preference one way or the other.
>>>
>>> Wayne
>>>
>>> On 7/16/2018 9:20 AM, Jeff Young wrote:
 Hi Wayne,

 The other issue is that the Janitor is going to mark my fixes as Fix 
 Committed, and I don’t know if the auto-bug-release facility is smart 
 enough to check the milestone before converting Fix Committed to Fix 
 Released.  So we may need to do that first too.

 Cheers,
 Jeff.

> On 16 Jul 2018, at 14:15, Wayne Stambaugh  wrote:
>
> Jeff,
>
> As a general rule, we merge changes into the development branch and then
> merge them into the stable release branch after they have been tested.
> In the past this has only been bug fixes so your case is slightly
> different.  The problem I see with merging your changes into the 5.1
> branch first is that they will not get as much testing as they would if
> you merged your changes into the development branch.  I would prefer
> that we merge changes into the development branch so that nightly builds
> can be used to get some good testing.  Any bug fixes to your changes can
> then be merged into the 5.1 branch.  Does anyone see any reason not to
> do it this way?
>
> Please do not merge your changes into the development branch just yet.
> Orson just fixed a bug and I'm considering retagging v5 to include this 
> fix.
>
> Cheers,
>
> Wayne
>
> On 7/16/2018 5:05 AM, Jeff Young wrote:
>> Thanks, JP!  I’ll make the fix.
>>
>>> On 16 Jul 2018, at 09:24, jp charras  wrote:
>>>
>>> Le 16/07/2018 à 10:10, Jeff Young a écrit :
 Well, rats.  I couldn’t figure out why "git rebase —interactive" 
 wasn’t showing me any of my
 commits, and it turns out that I somehow accidentally merged them all 
 to origin/5.1 sometime last
 night.  Anyway, you don’t have to fetch my private branch to test it 
 anymore; the kicad 5.1 branch
 will do nicely.

 Let me know if the paged dialog issues are keeping anyone from getting 
 work done and I’ll try to
 figure out how to revert those commits.
>>>
>>> Hi, Jeff
>>> The paged dialog issue is due to the fact the panels (pages) have an 
>>> incorrect parent.
>>> Currently, these panels have the dialog itself as parent.
>>> They should have m_treebook (the wxTreeBook similar to a wxNotebook) as 
>>> parent.
>>>
>>> (This change fixes the issue on W7)
>>>

 Cheers,
 Jeff.
>>>
>>> -- 
>>> 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
>>
>>
>> ___
>> 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
>

Re: [Kicad-developers] kicad version and install location

2018-07-16 Thread Mark Roszko

Yeathats what I proposed too.

Every program on Windows that needs side-by-side installs just
versions both the config and install locations. Thats it.

EAGLE does it.
Visual Studio does.
Altium does it.
CLion does it.
All of Jetbrains other product do it.
Microsoft Word does it
Adobe does it.
Python does it.
MSSQL does it.


No need for crazy launcher args and extreme actions such as doing
something like RVM does

All that needs to be done, is find all instances of wxStandardPaths
being used for config location.
Replace it with a standard static function helper. In the helper, it
appends a version number to the location.

Thats it. Done. No need to require users to understand command line to
use a program.

It works for linux too.
/home/user/.kicad/
becomes
/home/user/.kicad/5.1/


On Mon, Jul 16, 2018 at 10:37 AM Adam Wolf
 wrote:
>
> Yup, that's what I proposed.
> On Mon, Jul 16, 2018 at 9:16 AM Nick Østergaard  wrote:
> >
> > Why does this need to be so complicated?
> >
> > I think we could just rename the kicad config folder created and
> > searched by kicad from "kicad" to "kicad5" and be happy in the 5.x
> > branches.
> > Den man. 16. jul. 2018 kl. 15.11 skrev Bob Gustafson :
> > >
> > > There is a tool which allows developers to quickly switch between 
> > > different versions of Ruby (and their associated gemsets).
> > >
> > > Perhaps it could be used for KiCad? Or perhaps just some of RVM's ideas 
> > > could be adapted for KiCad
> > >
> > > https://rvm.io/
> > >
> > >
> > > On 07/15/2018 09:52 AM, Adam Wolf wrote:
> > >
> > > I guess the fact that environment variables are tricky to set for 
> > > graphical applications for the Mac may be a blessing here :)
> > >
> > > Should we try to package a macOS version that installs to 
> > > /Applications/KiCad5 and /Library/Application Support/kicad?
> > >
> > > Adam
> > >
> > > On Sun, Jul 15, 2018, 2:41 AM Eeli Kaikkonen  
> > > wrote:
> > >>
> > >> There are some people in the user forum who have spent time with these 
> > >> v4->v5 problems, including me and Rene. The consensus about the 
> > >> environment variables seems to be what Rene already said, that they 
> > >> should not (without explicit user intervention) be set for the system, 
> > >> but from KiCad itself. Nick confirmed that the current v5 installer 
> > >> won't set them by default. They are still a problem if they have been 
> > >> set by v4 installer.
> > >>
> > >> su 15. heinäk. 2018 klo 5.04 Strontium (strnty...@gmail.com) kirjoitti:
> > >>>
> > >>> I honestly think each major revision of KiCad should be considered a NEW
> > >>> program, installs to a new place has its configuration and libraries all
> > >>> in a new location.  Only Incremental updates 5.0 -> 5.1 should be
> > >>> considered upgrades.
> > >>>
> > >>
> > >> I agree. It's probable that many users will want to continue with v4 for 
> > >> old projects but v5 for new, and in the future the same thing will be 
> > >> true for v5 vs. v6, because they break the file/project compatibility. 
> > >> But where the compatibility is kept it's more likely to be considered as 
> > >> just an upgrade.
> > >>
> > >>>
> > >>> Kicad configuration isn't complex or onerous so if a user wants to bring
> > >>> a Kicad4 config into Kicad5 or 6 or whatever, then they do that
> > >>> themselves, otherwise after install Kicad5 is a fresh blank sheet with
> > >>> no relationship to anything that happened on the users computer in
> > >>> Kicad4.  I am not familiar with the issues on Windows, but I would have
> > >>> thought now this is mostly a packaging issue only??
> > >>>
> > >>
> > >> I tried modifying the Windows installer, I only needed to replace some 
> > >> of "KiCad" strings with "KiCad5" and it can install v5 alongside v4 
> > >> independently. The only problem is the configuration and the environment 
> > >> variables set by v4. They can be handled with a startup script. See 
> > >> https://forum.kicad.info/t/does-v5-have-to-overwrite-on-install/11282 
> > >> for some details.
> > >>
> > >>> I also agree if it can't work this way now on Windows, then its all a
> > >>> bit late for V5, but maybe V6 can consider itself a new program distinct
> > >>> from V5.  This would also help with testing, because users could use V5
> > >>> for daily work, but also easily install a V6 daily side by side.
> > >>
> > >>
> > >> All this could be done with the Windows installer, provided that a 
> > >> startup script would be offered.
> > >>
> > >> To make this all, at least the startup script, as simple as possible I 
> > >> would suggest one (or three) small changes to KiCad (for 5.1, or even 
> > >> 5.0.1?). Add command line options --config=/path/to/config and 
> > >> --ignore-env-vars. The former is obvious and would override 
> > >> KICAD_CONFIG_HOME system environment variable. The latter would make 
> > >> KiCad ignore all system environment variables and use the current 
> > >> internal logic and the path settings UI instead. That

Re: [Kicad-developers] 5.1 branch

Le 16/07/2018 à 17:54, Wayne Stambaugh a écrit :
> I was really hoping just to fix the wxDC issues with GTK3 rather than
> implement GAL unless Tom implemented a wxDC GAL and that is all we
> expose for 5.1.  The primary goal here is to fix the GTK3 rendering
> issues so we can enable wxPython support again.  We need to limit our
> risk exposure for 5.1.
> 
> I'm assuming the printing is a v6 goal.

I am pretty sure wxDC on GTK3 is in fact just an interface with Cairo.

So a wxDC GAL is for me (but I can be wrong) is very near implementing GAL 
(using Cairo canvas) in
Eeschema, as long it uses the legacy tools.

Moreover, GAL in Eeschema will remove any specific code for OSX, at least in 
Eeschema (and page
layout editor).
This specific code creates also bugs and issues due to the very different 
behavior between OSX and
others OS.

So the risk exposure for 5.1 is high, but OTOH the benefit is high.
and the risk for 5.1 if nothing is done is higher.


> 
> On 7/16/2018 11:15 AM, Maciej Sumiński wrote:
>> Tom has already prepared a proof-of-concept eeschema with GAL rendering,
>> which still uses the legacy tools. I have some promising results
>> switching the printing system to Cairo GAL. Obviously we will face some
>> unexpected obstacles, but I have high hopes.
>>
>> Cheers,
>> Orson
>>
>> On 07/16/2018 03:40 PM, Wayne Stambaugh wrote:
>>> Yes, assuming we can get that to work without dragging in Phoenix.
>>>
>>> On 7/16/2018 9:27 AM, Jeff Young wrote:
 5.1 is also for the GTK3 fixes, right?

> On 16 Jul 2018, at 14:23, Wayne Stambaugh  wrote:
>
> On 7/16/2018 9:19 AM, Simon Richter wrote:
>> Hi,
>>
>> On 15.07.2018 13:39, Jeff Young wrote:
>>
>>> I renamed my 6.0 branch to 5.1, since most of what it contains goes 
>>> there.
>>
>> What is the difference between 5.1 and 6.0? What goes into which branch?
>>
>>   Simon
>>
>
> 5.1 is only for the UI refactoring Jeff is working on along with any bug
> fixes that get merged into the 5.0 branch.  Any new features such as the
> new schematic file formats or GALification of eeschema are v6 only.

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

[Kicad-developers] 5.1 UI feedback

Hi JP,

Thanks for the feedback.

> On 16 Jul 2018, at 16:05, jp charras  wrote:
> 
> Hi Jeff,
> 
> I just played with a few of your 5.1 changes.
> 
> Many are good, but the new netclass management is not as efficient as the 
> current dialog:
> 
> - Modifying the netclass of a lot of nets is very tedious: the change must be 
> done for each net
> (this is the major issue).

I’d like to see if there’s some other way to handle lots of nets.  The 
double-list method was 
very hard to figure out how to use (although admittedly very efficient once you 
did).

> - we cannot see easily the list of nets, as the netclass filter was removed.

Interesting.  I had never used it for that, but I can see how it would be 
helpful.

> However the net filter is a good idea.
> 
> I am also thinking the "Board Setup" menu should be in the main menu bar, not 
> in the file menu (this
> is a very important setting, not related to a file management)

My thinking was it was sort of like Page Setup.  I’m not terribly attached to 
the File menu, but 
I'd rather avoid a stumpy menu with just a single item.  Preferences doesn’t 
fit well either.  Edit 
or Tools perhaps?

(I changed the subject line so this wouldn’t get drowned in the other 5.1 
stuff.)

> 
> 
> Thanks for your work.
> 
> -- 
> 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


___
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 branch

I started doing some by hand and Orson is right: tedious isn’t the half of it.  
I’ll wait for his script. ;)


> On 16 Jul 2018, at 16:59, Wayne Stambaugh  wrote:
> 
> My finger is on the delete key.  Fire when ready!
> 
> On 7/16/2018 11:48 AM, Maciej Sumiński wrote:
>> I have the script ready to run. It will just change all KiCad bug
>> statuses from 'Fix Committed' to 'Fix Release'. I assume there are no
>> bugs that are marked as 'Fix Committed', but not actually in the master
>> branch, right? Are you ready for an infinite stream of bug tracker
>> notifications? :>
>> 
>> Cheers,
>> Orson
>> 
>> On 07/16/2018 05:13 PM, Wayne Stambaugh wrote:
>>> That would probably be the easiest solution with the least amount of
>>> risk.  Although you could not run it for point releases because bugs
>>> that are only valid for the development branch would get set to fix
>>> released which would not be correct.
>>> 
>>> On 7/16/2018 11:08 AM, Maciej Sumiński wrote:
 It is terribly tedious to go through the bug list and change statuses
 one by one, so I offer to help with the bug report status fiddling. We
 may employ Janitor, but I guess it would be better to execute a simple
 script to change Fix Committed->Fix Released whenever we release a new
 version.
 
 Cheers,
 Orson
 
 On 07/16/2018 03:30 PM, Wayne Stambaugh wrote:
> Hey Jeff,
> 
> We have been manually changing the bug status from fix committed to fix
> released after a new stable release.  AFAIK, the janitor does not handle
> this.  I suppose the janitor could be modified to test for a new release
> and change the tag for all bugs associated with that release.  That
> would not be 100% accurate because there are bugs that have not been
> associated with a branch but that would probably be easier than changing
> them all manually.  I don't have a strong preference one way or the other.
> 
> Wayne
> 
> On 7/16/2018 9:20 AM, Jeff Young wrote:
>> Hi Wayne,
>> 
>> The other issue is that the Janitor is going to mark my fixes as Fix 
>> Committed, and I don’t know if the auto-bug-release facility is smart 
>> enough to check the milestone before converting Fix Committed to Fix 
>> Released.  So we may need to do that first too.
>> 
>> Cheers,
>> Jeff.
>> 
>>> On 16 Jul 2018, at 14:15, Wayne Stambaugh  wrote:
>>> 
>>> Jeff,
>>> 
>>> As a general rule, we merge changes into the development branch and then
>>> merge them into the stable release branch after they have been tested.
>>> In the past this has only been bug fixes so your case is slightly
>>> different.  The problem I see with merging your changes into the 5.1
>>> branch first is that they will not get as much testing as they would if
>>> you merged your changes into the development branch.  I would prefer
>>> that we merge changes into the development branch so that nightly builds
>>> can be used to get some good testing.  Any bug fixes to your changes can
>>> then be merged into the 5.1 branch.  Does anyone see any reason not to
>>> do it this way?
>>> 
>>> Please do not merge your changes into the development branch just yet.
>>> Orson just fixed a bug and I'm considering retagging v5 to include this 
>>> fix.
>>> 
>>> Cheers,
>>> 
>>> Wayne
>>> 
>>> On 7/16/2018 5:05 AM, Jeff Young wrote:
 Thanks, JP!  I’ll make the fix.
 
> On 16 Jul 2018, at 09:24, jp charras  wrote:
> 
> Le 16/07/2018 à 10:10, Jeff Young a écrit :
>> Well, rats.  I couldn’t figure out why "git rebase —interactive" 
>> wasn’t showing me any of my
>> commits, and it turns out that I somehow accidentally merged them 
>> all to origin/5.1 sometime last
>> night.  Anyway, you don’t have to fetch my private branch to test it 
>> anymore; the kicad 5.1 branch
>> will do nicely.
>> 
>> Let me know if the paged dialog issues are keeping anyone from 
>> getting work done and I’ll try to
>> figure out how to revert those commits.
> 
> Hi, Jeff
> The paged dialog issue is due to the fact the panels (pages) have an 
> incorrect parent.
> Currently, these panels have the dialog itself as parent.
> They should have m_treebook (the wxTreeBook similar to a wxNotebook) 
> as parent.
> 
> (This change fixes the issue on W7)
> 
>> 
>> Cheers,
>> Jeff.
> 
> -- 
> 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   :

Re: [Kicad-developers] 5.1 branch

My finger is on the delete key.  Fire when ready!

On 7/16/2018 11:48 AM, Maciej Sumiński wrote:
> I have the script ready to run. It will just change all KiCad bug
> statuses from 'Fix Committed' to 'Fix Release'. I assume there are no
> bugs that are marked as 'Fix Committed', but not actually in the master
> branch, right? Are you ready for an infinite stream of bug tracker
> notifications? :>
> 
> Cheers,
> Orson
> 
> On 07/16/2018 05:13 PM, Wayne Stambaugh wrote:
>> That would probably be the easiest solution with the least amount of
>> risk.  Although you could not run it for point releases because bugs
>> that are only valid for the development branch would get set to fix
>> released which would not be correct.
>>
>> On 7/16/2018 11:08 AM, Maciej Sumiński wrote:
>>> It is terribly tedious to go through the bug list and change statuses
>>> one by one, so I offer to help with the bug report status fiddling. We
>>> may employ Janitor, but I guess it would be better to execute a simple
>>> script to change Fix Committed->Fix Released whenever we release a new
>>> version.
>>>
>>> Cheers,
>>> Orson
>>>
>>> On 07/16/2018 03:30 PM, Wayne Stambaugh wrote:
 Hey Jeff,

 We have been manually changing the bug status from fix committed to fix
 released after a new stable release.  AFAIK, the janitor does not handle
 this.  I suppose the janitor could be modified to test for a new release
 and change the tag for all bugs associated with that release.  That
 would not be 100% accurate because there are bugs that have not been
 associated with a branch but that would probably be easier than changing
 them all manually.  I don't have a strong preference one way or the other.

 Wayne

 On 7/16/2018 9:20 AM, Jeff Young wrote:
> Hi Wayne,
>
> The other issue is that the Janitor is going to mark my fixes as Fix 
> Committed, and I don’t know if the auto-bug-release facility is smart 
> enough to check the milestone before converting Fix Committed to Fix 
> Released.  So we may need to do that first too.
>
> Cheers,
> Jeff.
>
>> On 16 Jul 2018, at 14:15, Wayne Stambaugh  wrote:
>>
>> Jeff,
>>
>> As a general rule, we merge changes into the development branch and then
>> merge them into the stable release branch after they have been tested.
>> In the past this has only been bug fixes so your case is slightly
>> different.  The problem I see with merging your changes into the 5.1
>> branch first is that they will not get as much testing as they would if
>> you merged your changes into the development branch.  I would prefer
>> that we merge changes into the development branch so that nightly builds
>> can be used to get some good testing.  Any bug fixes to your changes can
>> then be merged into the 5.1 branch.  Does anyone see any reason not to
>> do it this way?
>>
>> Please do not merge your changes into the development branch just yet.
>> Orson just fixed a bug and I'm considering retagging v5 to include this 
>> fix.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 7/16/2018 5:05 AM, Jeff Young wrote:
>>> Thanks, JP!  I’ll make the fix.
>>>
 On 16 Jul 2018, at 09:24, jp charras  wrote:

 Le 16/07/2018 à 10:10, Jeff Young a écrit :
> Well, rats.  I couldn’t figure out why "git rebase —interactive" 
> wasn’t showing me any of my
> commits, and it turns out that I somehow accidentally merged them all 
> to origin/5.1 sometime last
> night.  Anyway, you don’t have to fetch my private branch to test it 
> anymore; the kicad 5.1 branch
> will do nicely.
>
> Let me know if the paged dialog issues are keeping anyone from 
> getting work done and I’ll try to
> figure out how to revert those commits.

 Hi, Jeff
 The paged dialog issue is due to the fact the panels (pages) have an 
 incorrect parent.
 Currently, these panels have the dialog itself as parent.
 They should have m_treebook (the wxTreeBook similar to a wxNotebook) 
 as parent.

 (This change fixes the issue on W7)

>
> Cheers,
> Jeff.

 -- 
 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
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   :

Re: [Kicad-developers] 5.1 branch

2018-07-16 Thread Seth Hillbrand

No time like the present!

-S

Am Mo., 16. Juli 2018 um 08:49 Uhr schrieb Maciej Sumiński <
maciej.sumin...@cern.ch>:

> I have the script ready to run. It will just change all KiCad bug
> statuses from 'Fix Committed' to 'Fix Release'. I assume there are no
> bugs that are marked as 'Fix Committed', but not actually in the master
> branch, right? Are you ready for an infinite stream of bug tracker
> notifications? :>
>
> Cheers,
> Orson
>
> On 07/16/2018 05:13 PM, Wayne Stambaugh wrote:
> > That would probably be the easiest solution with the least amount of
> > risk.  Although you could not run it for point releases because bugs
> > that are only valid for the development branch would get set to fix
> > released which would not be correct.
> >
> > On 7/16/2018 11:08 AM, Maciej Sumiński wrote:
> >> It is terribly tedious to go through the bug list and change statuses
> >> one by one, so I offer to help with the bug report status fiddling. We
> >> may employ Janitor, but I guess it would be better to execute a simple
> >> script to change Fix Committed->Fix Released whenever we release a new
> >> version.
> >>
> >> Cheers,
> >> Orson
> >>
> >> On 07/16/2018 03:30 PM, Wayne Stambaugh wrote:
> >>> Hey Jeff,
> >>>
> >>> We have been manually changing the bug status from fix committed to fix
> >>> released after a new stable release.  AFAIK, the janitor does not
> handle
> >>> this.  I suppose the janitor could be modified to test for a new
> release
> >>> and change the tag for all bugs associated with that release.  That
> >>> would not be 100% accurate because there are bugs that have not been
> >>> associated with a branch but that would probably be easier than
> changing
> >>> them all manually.  I don't have a strong preference one way or the
> other.
> >>>
> >>> Wayne
> >>>
> >>> On 7/16/2018 9:20 AM, Jeff Young wrote:
>  Hi Wayne,
> 
>  The other issue is that the Janitor is going to mark my fixes as Fix
> Committed, and I don’t know if the auto-bug-release facility is smart
> enough to check the milestone before converting Fix Committed to Fix
> Released.  So we may need to do that first too.
> 
>  Cheers,
>  Jeff.
> 
> > On 16 Jul 2018, at 14:15, Wayne Stambaugh 
> wrote:
> >
> > Jeff,
> >
> > As a general rule, we merge changes into the development branch and
> then
> > merge them into the stable release branch after they have been
> tested.
> > In the past this has only been bug fixes so your case is slightly
> > different.  The problem I see with merging your changes into the 5.1
> > branch first is that they will not get as much testing as they would
> if
> > you merged your changes into the development branch.  I would prefer
> > that we merge changes into the development branch so that nightly
> builds
> > can be used to get some good testing.  Any bug fixes to your changes
> can
> > then be merged into the 5.1 branch.  Does anyone see any reason not
> to
> > do it this way?
> >
> > Please do not merge your changes into the development branch just
> yet.
> > Orson just fixed a bug and I'm considering retagging v5 to include
> this fix.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 7/16/2018 5:05 AM, Jeff Young wrote:
> >> Thanks, JP!  I’ll make the fix.
> >>
> >>> On 16 Jul 2018, at 09:24, jp charras 
> wrote:
> >>>
> >>> Le 16/07/2018 à 10:10, Jeff Young a écrit :
>  Well, rats.  I couldn’t figure out why "git rebase —interactive"
> wasn’t showing me any of my
>  commits, and it turns out that I somehow accidentally merged them
> all to origin/5.1 sometime last
>  night.  Anyway, you don’t have to fetch my private branch to test
> it anymore; the kicad 5.1 branch
>  will do nicely.
> 
>  Let me know if the paged dialog issues are keeping anyone from
> getting work done and I’ll try to
>  figure out how to revert those commits.
> >>>
> >>> Hi, Jeff
> >>> The paged dialog issue is due to the fact the panels (pages) have
> an incorrect parent.
> >>> Currently, these panels have the dialog itself as parent.
> >>> They should have m_treebook (the wxTreeBook similar to a
> wxNotebook) as parent.
> >>>
> >>> (This change fixes the issue on W7)
> >>>
> 
>  Cheers,
>  Jeff.
> >>>
> >>> --
> >>> 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
> >>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe :

Re: [Kicad-developers] 5.1 branch

I was really hoping just to fix the wxDC issues with GTK3 rather than
implement GAL unless Tom implemented a wxDC GAL and that is all we
expose for 5.1.  The primary goal here is to fix the GTK3 rendering
issues so we can enable wxPython support again.  We need to limit our
risk exposure for 5.1.

I'm assuming the printing is a v6 goal.

On 7/16/2018 11:15 AM, Maciej Sumiński wrote:
> Tom has already prepared a proof-of-concept eeschema with GAL rendering,
> which still uses the legacy tools. I have some promising results
> switching the printing system to Cairo GAL. Obviously we will face some
> unexpected obstacles, but I have high hopes.
> 
> Cheers,
> Orson
> 
> On 07/16/2018 03:40 PM, Wayne Stambaugh wrote:
>> Yes, assuming we can get that to work without dragging in Phoenix.
>>
>> On 7/16/2018 9:27 AM, Jeff Young wrote:
>>> 5.1 is also for the GTK3 fixes, right?
>>>
 On 16 Jul 2018, at 14:23, Wayne Stambaugh  wrote:

 On 7/16/2018 9:19 AM, Simon Richter wrote:
> Hi,
>
> On 15.07.2018 13:39, Jeff Young wrote:
>
>> I renamed my 6.0 branch to 5.1, since most of what it contains goes 
>> there.
>
> What is the difference between 5.1 and 6.0? What goes into which branch?
>
>   Simon
>

 5.1 is only for the UI refactoring Jeff is working on along with any bug
 fixes that get merged into the 5.0 branch.  Any new features such as the
 new schematic file formats or GALification of eeschema are v6 only.

 ___
 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] 5.1 branch

Tom has already prepared a proof-of-concept eeschema with GAL rendering,
which still uses the legacy tools. I have some promising results
switching the printing system to Cairo GAL. Obviously we will face some
unexpected obstacles, but I have high hopes.

Cheers,
Orson

On 07/16/2018 03:40 PM, Wayne Stambaugh wrote:
> Yes, assuming we can get that to work without dragging in Phoenix.
> 
> On 7/16/2018 9:27 AM, Jeff Young wrote:
>> 5.1 is also for the GTK3 fixes, right?
>>
>>> On 16 Jul 2018, at 14:23, Wayne Stambaugh  wrote:
>>>
>>> On 7/16/2018 9:19 AM, Simon Richter wrote:
 Hi,

 On 15.07.2018 13:39, Jeff Young wrote:

> I renamed my 6.0 branch to 5.1, since most of what it contains goes there.

 What is the difference between 5.1 and 6.0? What goes into which branch?

   Simon

>>>
>>> 5.1 is only for the UI refactoring Jeff is working on along with any bug
>>> fixes that get merged into the 5.0 branch.  Any new features such as the
>>> new schematic file formats or GALification of eeschema are v6 only.
>>>
>>> ___
>>> 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
> 




signature.asc
Description: OpenPGP digital signature
___
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 branch

That would probably be the easiest solution with the least amount of
risk.  Although you could not run it for point releases because bugs
that are only valid for the development branch would get set to fix
released which would not be correct.

On 7/16/2018 11:08 AM, Maciej Sumiński wrote:
> It is terribly tedious to go through the bug list and change statuses
> one by one, so I offer to help with the bug report status fiddling. We
> may employ Janitor, but I guess it would be better to execute a simple
> script to change Fix Committed->Fix Released whenever we release a new
> version.
> 
> Cheers,
> Orson
> 
> On 07/16/2018 03:30 PM, Wayne Stambaugh wrote:
>> Hey Jeff,
>>
>> We have been manually changing the bug status from fix committed to fix
>> released after a new stable release.  AFAIK, the janitor does not handle
>> this.  I suppose the janitor could be modified to test for a new release
>> and change the tag for all bugs associated with that release.  That
>> would not be 100% accurate because there are bugs that have not been
>> associated with a branch but that would probably be easier than changing
>> them all manually.  I don't have a strong preference one way or the other.
>>
>> Wayne
>>
>> On 7/16/2018 9:20 AM, Jeff Young wrote:
>>> Hi Wayne,
>>>
>>> The other issue is that the Janitor is going to mark my fixes as Fix 
>>> Committed, and I don’t know if the auto-bug-release facility is smart 
>>> enough to check the milestone before converting Fix Committed to Fix 
>>> Released.  So we may need to do that first too.
>>>
>>> Cheers,
>>> Jeff.
>>>
 On 16 Jul 2018, at 14:15, Wayne Stambaugh  wrote:

 Jeff,

 As a general rule, we merge changes into the development branch and then
 merge them into the stable release branch after they have been tested.
 In the past this has only been bug fixes so your case is slightly
 different.  The problem I see with merging your changes into the 5.1
 branch first is that they will not get as much testing as they would if
 you merged your changes into the development branch.  I would prefer
 that we merge changes into the development branch so that nightly builds
 can be used to get some good testing.  Any bug fixes to your changes can
 then be merged into the 5.1 branch.  Does anyone see any reason not to
 do it this way?

 Please do not merge your changes into the development branch just yet.
 Orson just fixed a bug and I'm considering retagging v5 to include this 
 fix.

 Cheers,

 Wayne

 On 7/16/2018 5:05 AM, Jeff Young wrote:
> Thanks, JP!  I’ll make the fix.
>
>> On 16 Jul 2018, at 09:24, jp charras  wrote:
>>
>> Le 16/07/2018 à 10:10, Jeff Young a écrit :
>>> Well, rats.  I couldn’t figure out why "git rebase —interactive" wasn’t 
>>> showing me any of my
>>> commits, and it turns out that I somehow accidentally merged them all 
>>> to origin/5.1 sometime last
>>> night.  Anyway, you don’t have to fetch my private branch to test it 
>>> anymore; the kicad 5.1 branch
>>> will do nicely.
>>>
>>> Let me know if the paged dialog issues are keeping anyone from getting 
>>> work done and I’ll try to
>>> figure out how to revert those commits.
>>
>> Hi, Jeff
>> The paged dialog issue is due to the fact the panels (pages) have an 
>> incorrect parent.
>> Currently, these panels have the dialog itself as parent.
>> They should have m_treebook (the wxTreeBook similar to a wxNotebook) as 
>> parent.
>>
>> (This change fixes the issue on W7)
>>
>>>
>>> Cheers,
>>> Jeff.
>>
>> -- 
>> 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
>
>
> ___
> 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:

Re: [Kicad-developers] 5.1 branch

It is terribly tedious to go through the bug list and change statuses
one by one, so I offer to help with the bug report status fiddling. We
may employ Janitor, but I guess it would be better to execute a simple
script to change Fix Committed->Fix Released whenever we release a new
version.

Cheers,
Orson

On 07/16/2018 03:30 PM, Wayne Stambaugh wrote:
> Hey Jeff,
> 
> We have been manually changing the bug status from fix committed to fix
> released after a new stable release.  AFAIK, the janitor does not handle
> this.  I suppose the janitor could be modified to test for a new release
> and change the tag for all bugs associated with that release.  That
> would not be 100% accurate because there are bugs that have not been
> associated with a branch but that would probably be easier than changing
> them all manually.  I don't have a strong preference one way or the other.
> 
> Wayne
> 
> On 7/16/2018 9:20 AM, Jeff Young wrote:
>> Hi Wayne,
>>
>> The other issue is that the Janitor is going to mark my fixes as Fix 
>> Committed, and I don’t know if the auto-bug-release facility is smart enough 
>> to check the milestone before converting Fix Committed to Fix Released.  So 
>> we may need to do that first too.
>>
>> Cheers,
>> Jeff.
>>
>>> On 16 Jul 2018, at 14:15, Wayne Stambaugh  wrote:
>>>
>>> Jeff,
>>>
>>> As a general rule, we merge changes into the development branch and then
>>> merge them into the stable release branch after they have been tested.
>>> In the past this has only been bug fixes so your case is slightly
>>> different.  The problem I see with merging your changes into the 5.1
>>> branch first is that they will not get as much testing as they would if
>>> you merged your changes into the development branch.  I would prefer
>>> that we merge changes into the development branch so that nightly builds
>>> can be used to get some good testing.  Any bug fixes to your changes can
>>> then be merged into the 5.1 branch.  Does anyone see any reason not to
>>> do it this way?
>>>
>>> Please do not merge your changes into the development branch just yet.
>>> Orson just fixed a bug and I'm considering retagging v5 to include this fix.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 7/16/2018 5:05 AM, Jeff Young wrote:
 Thanks, JP!  I’ll make the fix.

> On 16 Jul 2018, at 09:24, jp charras  wrote:
>
> Le 16/07/2018 à 10:10, Jeff Young a écrit :
>> Well, rats.  I couldn’t figure out why "git rebase —interactive" wasn’t 
>> showing me any of my
>> commits, and it turns out that I somehow accidentally merged them all to 
>> origin/5.1 sometime last
>> night.  Anyway, you don’t have to fetch my private branch to test it 
>> anymore; the kicad 5.1 branch
>> will do nicely.
>>
>> Let me know if the paged dialog issues are keeping anyone from getting 
>> work done and I’ll try to
>> figure out how to revert those commits.
>
> Hi, Jeff
> The paged dialog issue is due to the fact the panels (pages) have an 
> incorrect parent.
> Currently, these panels have the dialog itself as parent.
> They should have m_treebook (the wxTreeBook similar to a wxNotebook) as 
> parent.
>
> (This change fixes the issue on W7)
>
>>
>> Cheers,
>> Jeff.
>
> -- 
> 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


 ___
 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
> 




signature.asc
Description: OpenPGP digital signature
___
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] Questions on 6.0 eeschema file format

Even though I'm not quite ready to start discussing the new file formats
just yet, here a few of my thoughts on inheritance:

Inheritance will be implemented in a second phase during the development
of the new file formats and possibly pushed into the version 7 release.
The reason is that there is currently no support for inheritance in the
schematic object code so that would have to be written first.

Existing symbol libraries would be converted as flat symbols (no
inheritance).  I'm not interested in trying to write code to analyze
existing symbol libraries and try to map them to a coherent inheritance
model.  It would be too much work for too little gain.  Only new symbol
libraries could be created using inheritance.

Inheritance would make for cleaner symbol libraries but not so much for
the schematic object code.  It may turn out the inheritance concept is
not worth the effort it takes to implement it and we abandon the idea.
Nothing is set it stone at the moment.

Inherited symbols would have to be flattened before they could be
embedded into the schematic file.  Otherwise, modifying an inherited
symbol would change all of the inherited symbols in a schematic which
may not be what the user expects or wants.  Having to flatten inherited
symbols is a potential argument for not implementing them.

I expect the implementation of the new schematic file formats to be a
bumpy ride.  We are making a fundamental paradigm shift (embedding
symbols in schematic files), adding a lot of new functionality (gate/pin
swapping, netclasses, etc.) and changing the internal units to metric.
I don't think the for one second that the new schematic file formats are
going to be a slam dunk.  On the contrary, I think it's going to be more
difficult than the effort required to rewrite the footprint and board
file formats.  Those of use who were around for that remember just how
much work was involved.

Cheers,

Wayne

On 7/16/2018 10:28 AM, Rene Pöschl wrote:
> My guess would be maintainability.
> Having some way of sharing parts of different symbols with each other
> makes it way easier to manage large libs. (Nobody would be forced to use
> these features but they can make live easier for library maintainers. We
> could then for example provide a single nmos graphic that is then used
> in all nmos symbols of the official lib. Reducing the work for both
> contributors and maintainers.)
> 
> On 16/07/18 16:24, Tomasz Wlostowski wrote:
>> On 16/07/18 16:04, Jeff Young wrote:
>>> Thinking more about it, we could probably auto-convert existing
>>> aliases to inheritance when we read them in.
>> Why do we need any inheritance at all? My only guess is to make Kicad
>> even more hackerish and difficult to understand.
>>
>> Tom
>>
>> ___
>> 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] 5.1 branch

Hi Jeff,

I just played with a few of your 5.1 changes.

Many are good, but the new netclass management is not as efficient as the 
current dialog:

- Modifying the netclass of a lot of nets is very tedious: the change must be 
done for each net
(this is the major issue).
- we cannot see easily the list of nets, as the netclass filter was removed.
However the net filter is a good idea.

I am also thinking the "Board Setup" menu should be in the main menu bar, not 
in the file menu (this
is a very important setting, not related to a file management)


Thanks for your work.

-- 
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] 5.1 branch

On 7/16/2018 10:37 AM, jp charras wrote:
> Le 16/07/2018 à 16:09, Jeff Young a écrit :
>> I keep seeing issues with “incorrect” ratsnests on the kicad.info 
>>  forums.  Can
>> we put the curved ratsnests into 5.1?
> 
> This artifact exists only in Legacy mode, due to the XOR mode used to draw 
> them.
> curved ratsnests (it can be a good idea) need to be seriously tested, 
> especially considering
> calculation time on large boards.

If it seems to work well enough during development, I could give it the
nod for inclusion in 5.1 one but I don't want anyone to get their hopes
set on it for now.

> 
>>
>>
>>> On 16 Jul 2018, at 14:54, Jeff Young >> > wrote:
>>>
>>> Cool.  I’ll wait a few more days to make sure everything is settled down 
>>> and then merge the 5.1
>>> stuff to master.
>>>
>>> Should we go ahead and start making the Fix Committed bugs Fix Released, or 
>>> do we want to wait for
>>> the release announcement?
>>>
 On 16 Jul 2018, at 14:30, Wayne Stambaugh >>> > wrote:

 Hey Jeff,

 We have been manually changing the bug status from fix committed to fix
 released after a new stable release.  AFAIK, the janitor does not handle
 this.  I suppose the janitor could be modified to test for a new release
 and change the tag for all bugs associated with that release.  That
 would not be 100% accurate because there are bugs that have not been
 associated with a branch but that would probably be easier than changing
 them all manually.  I don't have a strong preference one way or the other.

 Wayne

 On 7/16/2018 9:20 AM, Jeff Young wrote:
> Hi Wayne,
>
> The other issue is that the Janitor is going to mark my fixes as Fix 
> Committed, and I don’t know
> if the auto-bug-release facility is smart enough to check the milestone 
> before converting Fix
> Committed to Fix Released.  So we may need to do that first too.
>
> Cheers,
> Jeff.
>
>> On 16 Jul 2018, at 14:15, Wayne Stambaugh > >
>> wrote:
>>
>> Jeff,
>>
>> As a general rule, we merge changes into the development branch and then
>> merge them into the stable release branch after they have been tested.
>> In the past this has only been bug fixes so your case is slightly
>> different.  The problem I see with merging your changes into the 5.1
>> branch first is that they will not get as much testing as they would if
>> you merged your changes into the development branch.  I would prefer
>> that we merge changes into the development branch so that nightly builds
>> can be used to get some good testing.  Any bug fixes to your changes can
>> then be merged into the 5.1 branch.  Does anyone see any reason not to
>> do it this way?
>>
>> Please do not merge your changes into the development branch just yet.
>> Orson just fixed a bug and I'm considering retagging v5 to include this 
>> fix.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 7/16/2018 5:05 AM, Jeff Young wrote:
>>> Thanks, JP!  I’ll make the fix.
>>>
 On 16 Jul 2018, at 09:24, jp charras >>> >
 wrote:

 Le 16/07/2018 à 10:10, Jeff Young a écrit :
> Well, rats.  I couldn’t figure out why "git rebase —interactive" 
> wasn’t showing me any of my
> commits, and it turns out that I somehow accidentally merged them all 
> to origin/5.1 sometime
> last
> night.  Anyway, you don’t have to fetch my private branch to test it 
> anymore; the kicad 5.1
> branch
> will do nicely.
>
> Let me know if the paged dialog issues are keeping anyone from 
> getting work done and I’ll try to
> figure out how to revert those commits.

 Hi, Jeff
 The paged dialog issue is due to the fact the panels (pages) have an 
 incorrect parent.
 Currently, these panels have the dialog itself as parent.
 They should have m_treebook (the wxTreeBook similar to a wxNotebook) 
 as parent.

 (This change fixes the issue on W7)

>
> Cheers,
> Jeff.

 -- 
 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] 5.1 branch

Le 16/07/2018 à 16:09, Jeff Young a écrit :
> I keep seeing issues with “incorrect” ratsnests on the kicad.info 
>  forums.  Can
> we put the curved ratsnests into 5.1?

This artifact exists only in Legacy mode, due to the XOR mode used to draw them.
curved ratsnests (it can be a good idea) need to be seriously tested, 
especially considering
calculation time on large boards.

> 
> 
>> On 16 Jul 2018, at 14:54, Jeff Young > > wrote:
>>
>> Cool.  I’ll wait a few more days to make sure everything is settled down and 
>> then merge the 5.1
>> stuff to master.
>>
>> Should we go ahead and start making the Fix Committed bugs Fix Released, or 
>> do we want to wait for
>> the release announcement?
>>
>>> On 16 Jul 2018, at 14:30, Wayne Stambaugh >> > wrote:
>>>
>>> Hey Jeff,
>>>
>>> We have been manually changing the bug status from fix committed to fix
>>> released after a new stable release.  AFAIK, the janitor does not handle
>>> this.  I suppose the janitor could be modified to test for a new release
>>> and change the tag for all bugs associated with that release.  That
>>> would not be 100% accurate because there are bugs that have not been
>>> associated with a branch but that would probably be easier than changing
>>> them all manually.  I don't have a strong preference one way or the other.
>>>
>>> Wayne
>>>
>>> On 7/16/2018 9:20 AM, Jeff Young wrote:
 Hi Wayne,

 The other issue is that the Janitor is going to mark my fixes as Fix 
 Committed, and I don’t know
 if the auto-bug-release facility is smart enough to check the milestone 
 before converting Fix
 Committed to Fix Released.  So we may need to do that first too.

 Cheers,
 Jeff.

> On 16 Jul 2018, at 14:15, Wayne Stambaugh  >
> wrote:
>
> Jeff,
>
> As a general rule, we merge changes into the development branch and then
> merge them into the stable release branch after they have been tested.
> In the past this has only been bug fixes so your case is slightly
> different.  The problem I see with merging your changes into the 5.1
> branch first is that they will not get as much testing as they would if
> you merged your changes into the development branch.  I would prefer
> that we merge changes into the development branch so that nightly builds
> can be used to get some good testing.  Any bug fixes to your changes can
> then be merged into the 5.1 branch.  Does anyone see any reason not to
> do it this way?
>
> Please do not merge your changes into the development branch just yet.
> Orson just fixed a bug and I'm considering retagging v5 to include this 
> fix.
>
> Cheers,
>
> Wayne
>
> On 7/16/2018 5:05 AM, Jeff Young wrote:
>> Thanks, JP!  I’ll make the fix.
>>
>>> On 16 Jul 2018, at 09:24, jp charras >> >
>>> wrote:
>>>
>>> Le 16/07/2018 à 10:10, Jeff Young a écrit :
 Well, rats.  I couldn’t figure out why "git rebase —interactive" 
 wasn’t showing me any of my
 commits, and it turns out that I somehow accidentally merged them all 
 to origin/5.1 sometime
 last
 night.  Anyway, you don’t have to fetch my private branch to test it 
 anymore; the kicad 5.1
 branch
 will do nicely.

 Let me know if the paged dialog issues are keeping anyone from getting 
 work done and I’ll try to
 figure out how to revert those commits.
>>>
>>> Hi, Jeff
>>> The paged dialog issue is due to the fact the panels (pages) have an 
>>> incorrect parent.
>>> Currently, these panels have the dialog itself as parent.
>>> They should have m_treebook (the wxTreeBook similar to a wxNotebook) as 
>>> parent.
>>>
>>> (This change fixes the issue on W7)
>>>

 Cheers,
 Jeff.
>>>
>>> -- 
>>> Jean-Pierre CHARRAS



-- 
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] kicad version and install location

This also doesn't help user with environment variables set in their
config files.  Installing kicad in a different folder will not resolve
this issue.  We have the rather posix like method of setting
XDG_USER_CONFIG variable to point to a different user config path but
that isn't really windows friendly.  That would require some coding to
match the install version with version specific config folders on windows.

On 7/16/2018 10:22 AM, Rene Pöschl wrote:
> This only helps users who never had system environment variables set.
> They overwrite the settings coming from the config folders. (So all
> default windows installation are not helped with this.)
> 
> On 16/07/18 16:16, Nick Østergaard wrote:
>> Why does this need to be so complicated?
>>
>> I think we could just rename the kicad config folder created and
>> searched by kicad from "kicad" to "kicad5" and be happy in the 5.x
>> branches.
>> Den man. 16. jul. 2018 kl. 15.11 skrev Bob Gustafson :
>>> There is a tool which allows developers to quickly switch between
>>> different versions of Ruby (and their associated gemsets).
>>>
>>> Perhaps it could be used for KiCad? Or perhaps just some of RVM's
>>> ideas could be adapted for KiCad
>>>
>>> https://rvm.io/
>>>
>>>
>>> On 07/15/2018 09:52 AM, Adam Wolf wrote:
>>>
>>> I guess the fact that environment variables are tricky to set for
>>> graphical applications for the Mac may be a blessing here :)
>>>
>>> Should we try to package a macOS version that installs to
>>> /Applications/KiCad5 and /Library/Application Support/kicad?
>>>
>>> Adam
>>>
>>> On Sun, Jul 15, 2018, 2:41 AM Eeli Kaikkonen
>>>  wrote:
 There are some people in the user forum who have spent time with
 these v4->v5 problems, including me and Rene. The consensus about
 the environment variables seems to be what Rene already said, that
 they should not (without explicit user intervention) be set for the
 system, but from KiCad itself. Nick confirmed that the current v5
 installer won't set them by default. They are still a problem if
 they have been set by v4 installer.

 su 15. heinäk. 2018 klo 5.04 Strontium (strnty...@gmail.com) kirjoitti:
> I honestly think each major revision of KiCad should be considered
> a NEW
> program, installs to a new place has its configuration and
> libraries all
> in a new location.  Only Incremental updates 5.0 -> 5.1 should be
> considered upgrades.
>
 I agree. It's probable that many users will want to continue with v4
 for old projects but v5 for new, and in the future the same thing
 will be true for v5 vs. v6, because they break the file/project
 compatibility. But where the compatibility is kept it's more likely
 to be considered as just an upgrade.

> Kicad configuration isn't complex or onerous so if a user wants to
> bring
> a Kicad4 config into Kicad5 or 6 or whatever, then they do that
> themselves, otherwise after install Kicad5 is a fresh blank sheet with
> no relationship to anything that happened on the users computer in
> Kicad4.  I am not familiar with the issues on Windows, but I would
> have
> thought now this is mostly a packaging issue only??
>
 I tried modifying the Windows installer, I only needed to replace
 some of "KiCad" strings with "KiCad5" and it can install v5
 alongside v4 independently. The only problem is the configuration
 and the environment variables set by v4. They can be handled with a
 startup script. See
 https://forum.kicad.info/t/does-v5-have-to-overwrite-on-install/11282 for
 some details.

> I also agree if it can't work this way now on Windows, then its all a
> bit late for V5, but maybe V6 can consider itself a new program
> distinct
> from V5.  This would also help with testing, because users could
> use V5
> for daily work, but also easily install a V6 daily side by side.

 All this could be done with the Windows installer, provided that a
 startup script would be offered.

 To make this all, at least the startup script, as simple as possible
 I would suggest one (or three) small changes to KiCad (for 5.1, or
 even 5.0.1?). Add command line options --config=/path/to/config and
 --ignore-env-vars. The former is obvious and would override
 KICAD_CONFIG_HOME system environment variable. The latter would make
 KiCad ignore all system environment variables and use the current
 internal logic and the path settings UI instead. That way the old
 variables could be left for v4 and the newer versions would be
 completely independent if the command line switches were used. The
 command line switch for the config path would be mostly for
 convenience. In Windows starting a program with custom environment
 variables is tedious and error prone to write (see the above
 mentioned thread). Command line switches are much easier.

Re: [Kicad-developers] Questions on 6.0 eeschema file format

2018-07-16 Thread Rene Pöschl


My guess would be maintainability.
Having some way of sharing parts of different symbols with each other 
makes it way easier to manage large libs. (Nobody would be forced to use 
these features but they can make live easier for library maintainers. We 
could then for example provide a single nmos graphic that is then used 
in all nmos symbols of the official lib. Reducing the work for both 
contributors and maintainers.)


On 16/07/18 16:24, Tomasz Wlostowski wrote:

On 16/07/18 16:04, Jeff Young wrote:

Thinking more about it, we could probably auto-convert existing aliases to 
inheritance when we read them in.

Why do we need any inheritance at all? My only guess is to make Kicad
even more hackerish and difficult to understand.

Tom

___
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 branch

I can't think of any reason not to change the fix committed bug reports
to fix released so if you have the time, have at it.

On 7/16/2018 9:54 AM, Jeff Young wrote:
> Cool.  I’ll wait a few more days to make sure everything is settled down and 
> then merge the 5.1 stuff to master.
> 
> Should we go ahead and start making the Fix Committed bugs Fix Released, or 
> do we want to wait for the release announcement?
> 
>> On 16 Jul 2018, at 14:30, Wayne Stambaugh  wrote:
>>
>> Hey Jeff,
>>
>> We have been manually changing the bug status from fix committed to fix
>> released after a new stable release.  AFAIK, the janitor does not handle
>> this.  I suppose the janitor could be modified to test for a new release
>> and change the tag for all bugs associated with that release.  That
>> would not be 100% accurate because there are bugs that have not been
>> associated with a branch but that would probably be easier than changing
>> them all manually.  I don't have a strong preference one way or the other.
>>
>> Wayne
>>
>> On 7/16/2018 9:20 AM, Jeff Young wrote:
>>> Hi Wayne,
>>>
>>> The other issue is that the Janitor is going to mark my fixes as Fix 
>>> Committed, and I don’t know if the auto-bug-release facility is smart 
>>> enough to check the milestone before converting Fix Committed to Fix 
>>> Released.  So we may need to do that first too.
>>>
>>> Cheers,
>>> Jeff.
>>>
 On 16 Jul 2018, at 14:15, Wayne Stambaugh  wrote:

 Jeff,

 As a general rule, we merge changes into the development branch and then
 merge them into the stable release branch after they have been tested.
 In the past this has only been bug fixes so your case is slightly
 different.  The problem I see with merging your changes into the 5.1
 branch first is that they will not get as much testing as they would if
 you merged your changes into the development branch.  I would prefer
 that we merge changes into the development branch so that nightly builds
 can be used to get some good testing.  Any bug fixes to your changes can
 then be merged into the 5.1 branch.  Does anyone see any reason not to
 do it this way?

 Please do not merge your changes into the development branch just yet.
 Orson just fixed a bug and I'm considering retagging v5 to include this 
 fix.

 Cheers,

 Wayne

 On 7/16/2018 5:05 AM, Jeff Young wrote:
> Thanks, JP!  I’ll make the fix.
>
>> On 16 Jul 2018, at 09:24, jp charras  wrote:
>>
>> Le 16/07/2018 à 10:10, Jeff Young a écrit :
>>> Well, rats.  I couldn’t figure out why "git rebase —interactive" wasn’t 
>>> showing me any of my
>>> commits, and it turns out that I somehow accidentally merged them all 
>>> to origin/5.1 sometime last
>>> night.  Anyway, you don’t have to fetch my private branch to test it 
>>> anymore; the kicad 5.1 branch
>>> will do nicely.
>>>
>>> Let me know if the paged dialog issues are keeping anyone from getting 
>>> work done and I’ll try to
>>> figure out how to revert those commits.
>>
>> Hi, Jeff
>> The paged dialog issue is due to the fact the panels (pages) have an 
>> incorrect parent.
>> Currently, these panels have the dialog itself as parent.
>> They should have m_treebook (the wxTreeBook similar to a wxNotebook) as 
>> parent.
>>
>> (This change fixes the issue on W7)
>>
>>>
>>> Cheers,
>>> Jeff.
>>
>> -- 
>> 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
>
>
> ___
> 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] Questions on 6.0 eeschema file format

2018-07-16 Thread Tomasz Wlostowski

On 16/07/18 16:04, Jeff Young wrote:
> Thinking more about it, we could probably auto-convert existing aliases to 
> inheritance when we read them in. 

Why do we need any inheritance at all? My only guess is to make Kicad
even more hackerish and difficult to understand.

Tom

___
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] kicad version and install location

2018-07-16 Thread Rene Pöschl

This only helps users who never had system environment variables set.
They overwrite the settings coming from the config folders. (So all
default windows installation are not helped with this.)

On 16/07/18 16:16, Nick Østergaard wrote:

Why does this need to be so complicated?

I think we could just rename the kicad config folder created and
searched by kicad from "kicad" to "kicad5" and be happy in the 5.x
branches.
Den man. 16. jul. 2018 kl. 15.11 skrev Bob Gustafson :

There is a tool which allows developers to quickly switch between different
versions of Ruby (and their associated gemsets).

Perhaps it could be used for KiCad? Or perhaps just some of RVM's ideas could
be adapted for KiCad

https://rvm.io/

On 07/15/2018 09:52 AM, Adam Wolf wrote:

I guess the fact that environment variables are tricky to set for graphical
applications for the Mac may be a blessing here :)

Should we try to package a macOS version that installs to /Applications/KiCad5
and /Library/Application Support/kicad?

Adam

On Sun, Jul 15, 2018, 2:41 AM Eeli Kaikkonen wrote:

There are some people in the user forum who have spent time with these v4->v5
problems, including me and Rene. The consensus about the environment variables
seems to be what Rene already said, that they should not (without explicit user
intervention) be set for the system, but from KiCad itself. Nick confirmed that
the current v5 installer won't set them by default. They are still a problem if
they have been set by v4 installer.

su 15. heinäk. 2018 klo 5.04 Strontium (strnty...@gmail.com) kirjoitti:

I honestly think each major revision of KiCad should be considered a NEW
program, installs to a new place has its configuration and libraries all
in a new location. Only Incremental updates 5.0 -> 5.1 should be
considered upgrades.

I agree. It's probable that many users will want to continue with v4 for old
projects but v5 for new, and in the future the same thing will be true for v5
vs. v6, because they break the file/project compatibility. But where the
compatibility is kept it's more likely to be considered as just an upgrade.

Kicad configuration isn't complex or onerous so if a user wants to bring
a Kicad4 config into Kicad5 or 6 or whatever, then they do that
themselves, otherwise after install Kicad5 is a fresh blank sheet with
no relationship to anything that happened on the users computer in
Kicad4. I am not familiar with the issues on Windows, but I would have
thought now this is mostly a packaging issue only??

I tried modifying the Windows installer, I only needed to replace some of "KiCad" strings
with "KiCad5" and it can install v5 alongside v4 independently. The only problem is the
configuration and the environment variables set by v4. They can be handled with a startup script.
See https://forum.kicad.info/t/does-v5-have-to-overwrite-on-install/11282 for some details.

I also agree if it can't work this way now on Windows, then its all a
bit late for V5, but maybe V6 can consider itself a new program distinct
from V5. This would also help with testing, because users could use V5
for daily work, but also easily install a V6 daily side by side.

All this could be done with the Windows installer, provided that a startup
script would be offered.

To make this all, at least the startup script, as simple as possible I would
suggest one (or three) small changes to KiCad (for 5.1, or even 5.0.1?). Add
command line options --config=/path/to/config and --ignore-env-vars. The former
is obvious and would override KICAD_CONFIG_HOME system environment variable.
The latter would make KiCad ignore all system environment variables and use the
current internal logic and the path settings UI instead. That way the old
variables could be left for v4 and the newer versions would be completely
independent if the command line switches were used. The command line switch for
the config path would be mostly for convenience. In Windows starting a program
with custom environment variables is tedious and error prone to write (see the
above mentioned thread). Command line switches are much easier.

It could also be possible to make --ignore-env-vars=true by default. Sharing
the environment variables would be a special case if the user wants that.

The general problem with using system environment variables is that they are
good for situations when there's only one version of a program on the system,
and/or several processes share the same variable values. Neither of them is
true for parallel installations of KiCad.

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 :

Re: [Kicad-developers] kicad version and install location

2018-07-16 Thread Nick Østergaard

Why does this need to be so complicated?

I think we could just rename the kicad config folder created and
searched by kicad from "kicad" to "kicad5" and be happy in the 5.x
branches.
Den man. 16. jul. 2018 kl. 15.11 skrev Bob Gustafson :
>
> There is a tool which allows developers to quickly switch between different 
> versions of Ruby (and their associated gemsets).
>
> Perhaps it could be used for KiCad? Or perhaps just some of RVM's ideas could 
> be adapted for KiCad
>
> https://rvm.io/
>
>
> On 07/15/2018 09:52 AM, Adam Wolf wrote:
>
> I guess the fact that environment variables are tricky to set for graphical 
> applications for the Mac may be a blessing here :)
>
> Should we try to package a macOS version that installs to 
> /Applications/KiCad5 and /Library/Application Support/kicad?
>
> Adam
>
> On Sun, Jul 15, 2018, 2:41 AM Eeli Kaikkonen  wrote:
>>
>> There are some people in the user forum who have spent time with these 
>> v4->v5 problems, including me and Rene. The consensus about the environment 
>> variables seems to be what Rene already said, that they should not (without 
>> explicit user intervention) be set for the system, but from KiCad itself. 
>> Nick confirmed that the current v5 installer won't set them by default. They 
>> are still a problem if they have been set by v4 installer.
>>
>> su 15. heinäk. 2018 klo 5.04 Strontium (strnty...@gmail.com) kirjoitti:
>>>
>>> I honestly think each major revision of KiCad should be considered a NEW
>>> program, installs to a new place has its configuration and libraries all
>>> in a new location.  Only Incremental updates 5.0 -> 5.1 should be
>>> considered upgrades.
>>>
>>
>> I agree. It's probable that many users will want to continue with v4 for old 
>> projects but v5 for new, and in the future the same thing will be true for 
>> v5 vs. v6, because they break the file/project compatibility. But where the 
>> compatibility is kept it's more likely to be considered as just an upgrade.
>>
>>>
>>> Kicad configuration isn't complex or onerous so if a user wants to bring
>>> a Kicad4 config into Kicad5 or 6 or whatever, then they do that
>>> themselves, otherwise after install Kicad5 is a fresh blank sheet with
>>> no relationship to anything that happened on the users computer in
>>> Kicad4.  I am not familiar with the issues on Windows, but I would have
>>> thought now this is mostly a packaging issue only??
>>>
>>
>> I tried modifying the Windows installer, I only needed to replace some of 
>> "KiCad" strings with "KiCad5" and it can install v5 alongside v4 
>> independently. The only problem is the configuration and the environment 
>> variables set by v4. They can be handled with a startup script. See 
>> https://forum.kicad.info/t/does-v5-have-to-overwrite-on-install/11282 for 
>> some details.
>>
>>> I also agree if it can't work this way now on Windows, then its all a
>>> bit late for V5, but maybe V6 can consider itself a new program distinct
>>> from V5.  This would also help with testing, because users could use V5
>>> for daily work, but also easily install a V6 daily side by side.
>>
>>
>> All this could be done with the Windows installer, provided that a startup 
>> script would be offered.
>>
>> To make this all, at least the startup script, as simple as possible I would 
>> suggest one (or three) small changes to KiCad (for 5.1, or even 5.0.1?). Add 
>> command line options --config=/path/to/config and --ignore-env-vars. The 
>> former is obvious and would override KICAD_CONFIG_HOME system environment 
>> variable. The latter would make KiCad ignore all system environment 
>> variables and use the current internal logic and the path settings UI 
>> instead. That way the old variables could be left for v4 and the newer 
>> versions would be completely independent if the command line switches were 
>> used. The command line switch for the config path would be mostly for 
>> convenience. In Windows starting a program with custom environment variables 
>> is tedious and error prone to write (see the above mentioned thread). 
>> Command line switches are much easier.
>>
>> It could also be possible to make --ignore-env-vars=true by default. Sharing 
>> the environment variables would be a special case if the user wants that.
>>
>> The general problem with using system environment variables is that they are 
>> good for situations when there's only one version of a program on the 
>> system, and/or several processes share the same variable values. Neither of 
>> them is true for parallel installations of KiCad.
>>
>> 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 :

Re: [Kicad-developers] 5.1 branch

I keep seeing issues with “incorrect” ratsnests on the kicad.info 
 forums.  Can we put the curved ratsnests into 5.1?


> On 16 Jul 2018, at 14:54, Jeff Young  wrote:
> 
> Cool.  I’ll wait a few more days to make sure everything is settled down and 
> then merge the 5.1 stuff to master.
> 
> Should we go ahead and start making the Fix Committed bugs Fix Released, or 
> do we want to wait for the release announcement?
> 
>> On 16 Jul 2018, at 14:30, Wayne Stambaugh  wrote:
>> 
>> Hey Jeff,
>> 
>> We have been manually changing the bug status from fix committed to fix
>> released after a new stable release.  AFAIK, the janitor does not handle
>> this.  I suppose the janitor could be modified to test for a new release
>> and change the tag for all bugs associated with that release.  That
>> would not be 100% accurate because there are bugs that have not been
>> associated with a branch but that would probably be easier than changing
>> them all manually.  I don't have a strong preference one way or the other.
>> 
>> Wayne
>> 
>> On 7/16/2018 9:20 AM, Jeff Young wrote:
>>> Hi Wayne,
>>> 
>>> The other issue is that the Janitor is going to mark my fixes as Fix 
>>> Committed, and I don’t know if the auto-bug-release facility is smart 
>>> enough to check the milestone before converting Fix Committed to Fix 
>>> Released.  So we may need to do that first too.
>>> 
>>> Cheers,
>>> Jeff.
>>> 
 On 16 Jul 2018, at 14:15, Wayne Stambaugh  wrote:
 
 Jeff,
 
 As a general rule, we merge changes into the development branch and then
 merge them into the stable release branch after they have been tested.
 In the past this has only been bug fixes so your case is slightly
 different.  The problem I see with merging your changes into the 5.1
 branch first is that they will not get as much testing as they would if
 you merged your changes into the development branch.  I would prefer
 that we merge changes into the development branch so that nightly builds
 can be used to get some good testing.  Any bug fixes to your changes can
 then be merged into the 5.1 branch.  Does anyone see any reason not to
 do it this way?
 
 Please do not merge your changes into the development branch just yet.
 Orson just fixed a bug and I'm considering retagging v5 to include this 
 fix.
 
 Cheers,
 
 Wayne
 
 On 7/16/2018 5:05 AM, Jeff Young wrote:
> Thanks, JP!  I’ll make the fix.
> 
>> On 16 Jul 2018, at 09:24, jp charras  wrote:
>> 
>> Le 16/07/2018 à 10:10, Jeff Young a écrit :
>>> Well, rats.  I couldn’t figure out why "git rebase —interactive" wasn’t 
>>> showing me any of my
>>> commits, and it turns out that I somehow accidentally merged them all 
>>> to origin/5.1 sometime last
>>> night.  Anyway, you don’t have to fetch my private branch to test it 
>>> anymore; the kicad 5.1 branch
>>> will do nicely.
>>> 
>>> Let me know if the paged dialog issues are keeping anyone from getting 
>>> work done and I’ll try to
>>> figure out how to revert those commits.
>> 
>> Hi, Jeff
>> The paged dialog issue is due to the fact the panels (pages) have an 
>> incorrect parent.
>> Currently, these panels have the dialog itself as parent.
>> They should have m_treebook (the wxTreeBook similar to a wxNotebook) as 
>> parent.
>> 
>> (This change fixes the issue on W7)
>> 
>>> 
>>> Cheers,
>>> Jeff.
>> 
>> -- 
>> 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
> 
> 
> ___
> 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   :

Re: [Kicad-developers] Questions on 6.0 eeschema file format

Thinking more about it, we could probably auto-convert existing aliases to 
inheritance when we read them in.  It would certainly be easier to support only 
one UI (and the alias UI is problematic anyway).

Wayne sent out a proposal on the dev list a while back.  I know I read them so 
they must have been sent out as PDF or Word or something, but the only links I 
could find are for OpenDocument: 
https://lists.launchpad.net/kicad-developers/msg35233.html

> On 16 Jul 2018, at 14:28, Simon Richter  wrote:
> 
> Hi,
> 
> On 16.07.2018 11:19, Jeff Young wrote:
> 
>> Do we plan on having inheritance replace aliases?
> 
> I do, but you might have noticed that with all my other commitments that
> isn't worth much.
> 
> Do we have a spec document beyond what was discussed on IRC?
> 
>> If so, what do we do with old symbols?  (Will we have to support both 
>> paradigms?)
> 
> It should be possible to keep them usable, except that they won't be
> part of the hierarchy. If we have special rules for replacement inside
> the hierarchy, e.g. two transistor symbols that have inherited the same
> SPICE type and graphics are obviously exchangeable, while symbols
> outside the hierarchy are more difficult.
> 
>   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] 5.1 branch

Yes, assuming we can get that to work without dragging in Phoenix.

On 7/16/2018 9:27 AM, Jeff Young wrote:
> 5.1 is also for the GTK3 fixes, right?
> 
>> On 16 Jul 2018, at 14:23, Wayne Stambaugh  wrote:
>>
>> On 7/16/2018 9:19 AM, Simon Richter wrote:
>>> Hi,
>>>
>>> On 15.07.2018 13:39, Jeff Young wrote:
>>>
 I renamed my 6.0 branch to 5.1, since most of what it contains goes there.
>>>
>>> What is the difference between 5.1 and 6.0? What goes into which branch?
>>>
>>>   Simon
>>>
>>
>> 5.1 is only for the UI refactoring Jeff is working on along with any bug
>> fixes that get merged into the 5.0 branch.  Any new features such as the
>> new schematic file formats or GALification of eeschema are v6 only.
>>
>> ___
>> 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 branch

Cool.  I’ll wait a few more days to make sure everything is settled down and 
then merge the 5.1 stuff to master.

Should we go ahead and start making the Fix Committed bugs Fix Released, or do 
we want to wait for the release announcement?

> On 16 Jul 2018, at 14:30, Wayne Stambaugh  wrote:
> 
> Hey Jeff,
> 
> We have been manually changing the bug status from fix committed to fix
> released after a new stable release.  AFAIK, the janitor does not handle
> this.  I suppose the janitor could be modified to test for a new release
> and change the tag for all bugs associated with that release.  That
> would not be 100% accurate because there are bugs that have not been
> associated with a branch but that would probably be easier than changing
> them all manually.  I don't have a strong preference one way or the other.
> 
> Wayne
> 
> On 7/16/2018 9:20 AM, Jeff Young wrote:
>> Hi Wayne,
>> 
>> The other issue is that the Janitor is going to mark my fixes as Fix 
>> Committed, and I don’t know if the auto-bug-release facility is smart enough 
>> to check the milestone before converting Fix Committed to Fix Released.  So 
>> we may need to do that first too.
>> 
>> Cheers,
>> Jeff.
>> 
>>> On 16 Jul 2018, at 14:15, Wayne Stambaugh  wrote:
>>> 
>>> Jeff,
>>> 
>>> As a general rule, we merge changes into the development branch and then
>>> merge them into the stable release branch after they have been tested.
>>> In the past this has only been bug fixes so your case is slightly
>>> different.  The problem I see with merging your changes into the 5.1
>>> branch first is that they will not get as much testing as they would if
>>> you merged your changes into the development branch.  I would prefer
>>> that we merge changes into the development branch so that nightly builds
>>> can be used to get some good testing.  Any bug fixes to your changes can
>>> then be merged into the 5.1 branch.  Does anyone see any reason not to
>>> do it this way?
>>> 
>>> Please do not merge your changes into the development branch just yet.
>>> Orson just fixed a bug and I'm considering retagging v5 to include this fix.
>>> 
>>> Cheers,
>>> 
>>> Wayne
>>> 
>>> On 7/16/2018 5:05 AM, Jeff Young wrote:
 Thanks, JP!  I’ll make the fix.
 
> On 16 Jul 2018, at 09:24, jp charras  wrote:
> 
> Le 16/07/2018 à 10:10, Jeff Young a écrit :
>> Well, rats.  I couldn’t figure out why "git rebase —interactive" wasn’t 
>> showing me any of my
>> commits, and it turns out that I somehow accidentally merged them all to 
>> origin/5.1 sometime last
>> night.  Anyway, you don’t have to fetch my private branch to test it 
>> anymore; the kicad 5.1 branch
>> will do nicely.
>> 
>> Let me know if the paged dialog issues are keeping anyone from getting 
>> work done and I’ll try to
>> figure out how to revert those commits.
> 
> Hi, Jeff
> The paged dialog issue is due to the fact the panels (pages) have an 
> incorrect parent.
> Currently, these panels have the dialog itself as parent.
> They should have m_treebook (the wxTreeBook similar to a wxNotebook) as 
> parent.
> 
> (This change fixes the issue on W7)
> 
>> 
>> Cheers,
>> Jeff.
> 
> -- 
> 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
 
 
 ___
 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] 5.1 branch

Hey Jeff,

We have been manually changing the bug status from fix committed to fix
released after a new stable release.  AFAIK, the janitor does not handle
this.  I suppose the janitor could be modified to test for a new release
and change the tag for all bugs associated with that release.  That
would not be 100% accurate because there are bugs that have not been
associated with a branch but that would probably be easier than changing
them all manually.  I don't have a strong preference one way or the other.

Wayne

On 7/16/2018 9:20 AM, Jeff Young wrote:
> Hi Wayne,
> 
> The other issue is that the Janitor is going to mark my fixes as Fix 
> Committed, and I don’t know if the auto-bug-release facility is smart enough 
> to check the milestone before converting Fix Committed to Fix Released.  So 
> we may need to do that first too.
> 
> Cheers,
> Jeff.
> 
>> On 16 Jul 2018, at 14:15, Wayne Stambaugh  wrote:
>>
>> Jeff,
>>
>> As a general rule, we merge changes into the development branch and then
>> merge them into the stable release branch after they have been tested.
>> In the past this has only been bug fixes so your case is slightly
>> different.  The problem I see with merging your changes into the 5.1
>> branch first is that they will not get as much testing as they would if
>> you merged your changes into the development branch.  I would prefer
>> that we merge changes into the development branch so that nightly builds
>> can be used to get some good testing.  Any bug fixes to your changes can
>> then be merged into the 5.1 branch.  Does anyone see any reason not to
>> do it this way?
>>
>> Please do not merge your changes into the development branch just yet.
>> Orson just fixed a bug and I'm considering retagging v5 to include this fix.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 7/16/2018 5:05 AM, Jeff Young wrote:
>>> Thanks, JP!  I’ll make the fix.
>>>
 On 16 Jul 2018, at 09:24, jp charras  wrote:

 Le 16/07/2018 à 10:10, Jeff Young a écrit :
> Well, rats.  I couldn’t figure out why "git rebase —interactive" wasn’t 
> showing me any of my
> commits, and it turns out that I somehow accidentally merged them all to 
> origin/5.1 sometime last
> night.  Anyway, you don’t have to fetch my private branch to test it 
> anymore; the kicad 5.1 branch
> will do nicely.
>
> Let me know if the paged dialog issues are keeping anyone from getting 
> work done and I’ll try to
> figure out how to revert those commits.

 Hi, Jeff
 The paged dialog issue is due to the fact the panels (pages) have an 
 incorrect parent.
 Currently, these panels have the dialog itself as parent.
 They should have m_treebook (the wxTreeBook similar to a wxNotebook) as 
 parent.

 (This change fixes the issue on W7)

>
> Cheers,
> Jeff.

 -- 
 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
>>>
>>>
>>> ___
>>> 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] Questions on 6.0 eeschema file format

2018-07-16 Thread Simon Richter

Hi,

On 16.07.2018 11:19, Jeff Young wrote:

> Do we plan on having inheritance replace aliases?

I do, but you might have noticed that with all my other commitments that
isn't worth much.

Do we have a spec document beyond what was discussed on IRC?

> If so, what do we do with old symbols?  (Will we have to support both 
> paradigms?)

It should be possible to keep them usable, except that they won't be
part of the hierarchy. If we have special rules for replacement inside
the hierarchy, e.g. two transistor symbols that have inherited the same
SPICE type and graphics are obviously exchangeable, while symbols
outside the hierarchy are more difficult.

   Simon

signature.asc
Description: OpenPGP digital signature
___
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 branch

5.1 is also for the GTK3 fixes, right?

> On 16 Jul 2018, at 14:23, Wayne Stambaugh  wrote:
> 
> On 7/16/2018 9:19 AM, Simon Richter wrote:
>> Hi,
>> 
>> On 15.07.2018 13:39, Jeff Young wrote:
>> 
>>> I renamed my 6.0 branch to 5.1, since most of what it contains goes there.
>> 
>> What is the difference between 5.1 and 6.0? What goes into which branch?
>> 
>>   Simon
>> 
> 
> 5.1 is only for the UI refactoring Jeff is working on along with any bug
> fixes that get merged into the 5.0 branch.  Any new features such as the
> new schematic file formats or GALification of eeschema are v6 only.
> 
> ___
> 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 branch

On 7/16/2018 9:19 AM, Simon Richter wrote:
> Hi,
> 
> On 15.07.2018 13:39, Jeff Young wrote:
> 
>> I renamed my 6.0 branch to 5.1, since most of what it contains goes there.
> 
> What is the difference between 5.1 and 6.0? What goes into which branch?
> 
>Simon
> 

5.1 is only for the UI refactoring Jeff is working on along with any bug
fixes that get merged into the 5.0 branch.  Any new features such as the
new schematic file formats or GALification of eeschema are v6 only.

___
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 branch

Hi Wayne,

The other issue is that the Janitor is going to mark my fixes as Fix Committed, 
and I don’t know if the auto-bug-release facility is smart enough to check the 
milestone before converting Fix Committed to Fix Released.  So we may need to 
do that first too.

Cheers,
Jeff.

> On 16 Jul 2018, at 14:15, Wayne Stambaugh  wrote:
> 
> Jeff,
> 
> As a general rule, we merge changes into the development branch and then
> merge them into the stable release branch after they have been tested.
> In the past this has only been bug fixes so your case is slightly
> different.  The problem I see with merging your changes into the 5.1
> branch first is that they will not get as much testing as they would if
> you merged your changes into the development branch.  I would prefer
> that we merge changes into the development branch so that nightly builds
> can be used to get some good testing.  Any bug fixes to your changes can
> then be merged into the 5.1 branch.  Does anyone see any reason not to
> do it this way?
> 
> Please do not merge your changes into the development branch just yet.
> Orson just fixed a bug and I'm considering retagging v5 to include this fix.
> 
> Cheers,
> 
> Wayne
> 
> On 7/16/2018 5:05 AM, Jeff Young wrote:
>> Thanks, JP!  I’ll make the fix.
>> 
>>> On 16 Jul 2018, at 09:24, jp charras  wrote:
>>> 
>>> Le 16/07/2018 à 10:10, Jeff Young a écrit :
 Well, rats.  I couldn’t figure out why "git rebase —interactive" wasn’t 
 showing me any of my
 commits, and it turns out that I somehow accidentally merged them all to 
 origin/5.1 sometime last
 night.  Anyway, you don’t have to fetch my private branch to test it 
 anymore; the kicad 5.1 branch
 will do nicely.
 
 Let me know if the paged dialog issues are keeping anyone from getting 
 work done and I’ll try to
 figure out how to revert those commits.
>>> 
>>> Hi, Jeff
>>> The paged dialog issue is due to the fact the panels (pages) have an 
>>> incorrect parent.
>>> Currently, these panels have the dialog itself as parent.
>>> They should have m_treebook (the wxTreeBook similar to a wxNotebook) as 
>>> parent.
>>> 
>>> (This change fixes the issue on W7)
>>> 
 
 Cheers,
 Jeff.
>>> 
>>> -- 
>>> 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
>> 
>> 
>> ___
>> 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] 5.1 branch

2018-07-16 Thread Simon Richter

Hi,

On 15.07.2018 13:39, Jeff Young wrote:

> I renamed my 6.0 branch to 5.1, since most of what it contains goes there.

What is the difference between 5.1 and 6.0? What goes into which branch?

   Simon




signature.asc
Description: OpenPGP digital signature
___
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 branch

Jeff,

As a general rule, we merge changes into the development branch and then
merge them into the stable release branch after they have been tested.
In the past this has only been bug fixes so your case is slightly
different.  The problem I see with merging your changes into the 5.1
branch first is that they will not get as much testing as they would if
you merged your changes into the development branch.  I would prefer
that we merge changes into the development branch so that nightly builds
can be used to get some good testing.  Any bug fixes to your changes can
then be merged into the 5.1 branch.  Does anyone see any reason not to
do it this way?

Please do not merge your changes into the development branch just yet.
Orson just fixed a bug and I'm considering retagging v5 to include this fix.

Cheers,

Wayne

On 7/16/2018 5:05 AM, Jeff Young wrote:
> Thanks, JP!  I’ll make the fix.
> 
>> On 16 Jul 2018, at 09:24, jp charras  wrote:
>>
>> Le 16/07/2018 à 10:10, Jeff Young a écrit :
>>> Well, rats.  I couldn’t figure out why "git rebase —interactive" wasn’t 
>>> showing me any of my
>>> commits, and it turns out that I somehow accidentally merged them all to 
>>> origin/5.1 sometime last
>>> night.  Anyway, you don’t have to fetch my private branch to test it 
>>> anymore; the kicad 5.1 branch
>>> will do nicely.
>>>
>>> Let me know if the paged dialog issues are keeping anyone from getting work 
>>> done and I’ll try to
>>> figure out how to revert those commits.
>>
>> Hi, Jeff
>> The paged dialog issue is due to the fact the panels (pages) have an 
>> incorrect parent.
>> Currently, these panels have the dialog itself as parent.
>> They should have m_treebook (the wxTreeBook similar to a wxNotebook) as 
>> parent.
>>
>> (This change fixes the issue on W7)
>>
>>>
>>> Cheers,
>>> Jeff.
>>
>> -- 
>> 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
> 
> 
> ___
> 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] kicad version and install location

2018-07-16 Thread Bob Gustafson

There is a tool which allows developers to quickly switch between 
different versions of Ruby (and their associated gemsets).


Perhaps it could be used for KiCad? Or perhaps just some of RVM's ideas 
could be adapted for KiCad


https://rvm.io/


On 07/15/2018 09:52 AM, Adam Wolf wrote:
I guess the fact that environment variables are tricky to set for 
graphical applications for the Mac may be a blessing here :)


Should we try to package a macOS version that installs to 
/Applications/KiCad5 and /Library/Application Support/kicad?


Adam

On Sun, Jul 15, 2018, 2:41 AM Eeli Kaikkonen > wrote:


There are some people in the user forum who have spent time with
these v4->v5 problems, including me and Rene. The consensus about
the environment variables seems to be what Rene already said, that
they should not (without explicit user intervention) be set for
the system, but from KiCad itself. Nick confirmed that the current
v5 installer won't set them by default. They are still a problem
if they have been set by v4 installer.

su 15. heinäk. 2018 klo 5.04 Strontium (strnty...@gmail.com
) kirjoitti:

I honestly think each major revision of KiCad should be
considered a NEW
program, installs to a new place has its configuration and
libraries all
in a new location.  Only Incremental updates 5.0 -> 5.1 should be
considered upgrades.


I agree. It's probable that many users will want to continue with
v4 for old projects but v5 for new, and in the future the same
thing will be true for v5 vs. v6, because they break the
file/project compatibility. But where the compatibility is kept
it's more likely to be considered as just an upgrade.

Kicad configuration isn't complex or onerous so if a user
wants to bring
a Kicad4 config into Kicad5 or 6 or whatever, then they do that
themselves, otherwise after install Kicad5 is a fresh blank
sheet with
no relationship to anything that happened on the users
computer in
Kicad4.  I am not familiar with the issues on Windows, but I
would have
thought now this is mostly a packaging issue only??


I tried modifying the Windows installer, I only needed to replace
some of "KiCad" strings with "KiCad5" and it can install v5
alongside v4 independently. The only problem is the configuration
and the environment variables set by v4. They can be handled with
a startup script. See
https://forum.kicad.info/t/does-v5-have-to-overwrite-on-install/11282
for some details.

I also agree if it can't work this way now on Windows, then
its all a
bit late for V5, but maybe V6 can consider itself a new
program distinct
from V5.  This would also help with testing, because users
could use V5
for daily work, but also easily install a V6 daily side by side.


All this could be done with the Windows installer, provided that a
startup script would be offered.

To make this all, at least the startup script, as simple as
possible I would suggest one (or three) small changes to KiCad
(for 5.1, or even 5.0.1?). Add command line options
--config=/path/to/config and --ignore-env-vars. The former is
obvious and would override KICAD_CONFIG_HOME system environment
variable. The latter would make KiCad ignore all system
environment variables and use the current internal logic and the
path settings UI instead. That way the old variables could be left
for v4 and the newer versions would be completely independent if
the command line switches were used. The command line switch for
the config path would be mostly for convenience. In Windows
starting a program with custom environment variables is tedious
and error prone to write (see the above mentioned thread). Command
line switches are much easier.

It could also be possible to make --ignore-env-vars=true by
default. Sharing the environment variables would be a special case
if the user wants that.

The general problem with using system environment variables is
that they are good for situations when there's only one version of
a program on the system, and/or several processes share the same
variable values. Neither of them is true for parallel
installations of KiCad.

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

Re: [Kicad-developers] kicad version and install location

2018-07-16 Thread Adam Wolf

Hi Wayne,

I'll see what I can do. It's possible this is a really quick change,
to change the macos basename from kicad to kicad5, and that would even
have it read different config files, I think!

There are only 2 remaining macOS changes to make this week, and
they're both documentation changes in a README.  I'll handle all other
issues first, and then I'll take a stab at it, and see if it works
out--unless someone else has some bandwidth and then please say
something and we can do some planning together.

Adam
On Mon, Jul 16, 2018 at 8:01 AM Wayne Stambaugh  wrote:
>
> As long as we are not pushing the b5 release schedule back I'm fine with
> this.
>
> On 7/15/2018 10:52 AM, Adam Wolf wrote:
> > I guess the fact that environment variables are tricky to set for
> > graphical applications for the Mac may be a blessing here :)
> >
> > Should we try to package a macOS version that installs to
> > /Applications/KiCad5 and /Library/Application Support/kicad?
> >
> > Adam
> >
> > On Sun, Jul 15, 2018, 2:41 AM Eeli Kaikkonen  > > wrote:
> >
> > There are some people in the user forum who have spent time with
> > these v4->v5 problems, including me and Rene. The consensus about
> > the environment variables seems to be what Rene already said, that
> > they should not (without explicit user intervention) be set for the
> > system, but from KiCad itself. Nick confirmed that the current v5
> > installer won't set them by default. They are still a problem if
> > they have been set by v4 installer.
> >
> > su 15. heinäk. 2018 klo 5.04 Strontium (strnty...@gmail.com
> > ) kirjoitti:
> >
> > I honestly think each major revision of KiCad should be
> > considered a NEW
> > program, installs to a new place has its configuration and
> > libraries all
> > in a new location.  Only Incremental updates 5.0 -> 5.1 should be
> > considered upgrades.
> >
> >
> > I agree. It's probable that many users will want to continue with v4
> > for old projects but v5 for new, and in the future the same thing
> > will be true for v5 vs. v6, because they break the file/project
> > compatibility. But where the compatibility is kept it's more likely
> > to be considered as just an upgrade.
> >
> >
> > Kicad configuration isn't complex or onerous so if a user wants
> > to bring
> > a Kicad4 config into Kicad5 or 6 or whatever, then they do that
> > themselves, otherwise after install Kicad5 is a fresh blank
> > sheet with
> > no relationship to anything that happened on the users computer in
> > Kicad4.  I am not familiar with the issues on Windows, but I
> > would have
> > thought now this is mostly a packaging issue only??
> >
> >
> > I tried modifying the Windows installer, I only needed to replace
> > some of "KiCad" strings with "KiCad5" and it can install v5
> > alongside v4 independently. The only problem is the configuration
> > and the environment variables set by v4. They can be handled with a
> > startup script. See
> > https://forum.kicad.info/t/does-v5-have-to-overwrite-on-install/11282 
> > for
> > some details.
> >
> > I also agree if it can't work this way now on Windows, then its
> > all a
> > bit late for V5, but maybe V6 can consider itself a new program
> > distinct
> > from V5.  This would also help with testing, because users could
> > use V5
> > for daily work, but also easily install a V6 daily side by side.
> >
> >
> > All this could be done with the Windows installer, provided that a
> > startup script would be offered.
> >
> > To make this all, at least the startup script, as simple as possible
> > I would suggest one (or three) small changes to KiCad (for 5.1, or
> > even 5.0.1?). Add command line options --config=/path/to/config and
> > --ignore-env-vars. The former is obvious and would override
> > KICAD_CONFIG_HOME system environment variable. The latter would make
> > KiCad ignore all system environment variables and use the current
> > internal logic and the path settings UI instead. That way the old
> > variables could be left for v4 and the newer versions would be
> > completely independent if the command line switches were used. The
> > command line switch for the config path would be mostly for
> > convenience. In Windows starting a program with custom environment
> > variables is tedious and error prone to write (see the above
> > mentioned thread). Command line switches are much easier.
> >
> > It could also be possible to make --ignore-env-vars=true by default.
> > Sharing the environment variables would be a special case if the
> > user wants that.
> >
> > The general problem with using system environment variables

Re: [Kicad-developers] kicad version and install location

2018-07-16 Thread Константин Барановский

As long as we are not pushing the b5 release schedule back I'm fine with
this.

On 7/15/2018 10:52 AM, Adam Wolf wrote:
> I guess the fact that environment variables are tricky to set for
> graphical applications for the Mac may be a blessing here :)
> 
> Should we try to package a macOS version that installs to
> /Applications/KiCad5 and /Library/Application Support/kicad?
> 
> Adam
> 
> On Sun, Jul 15, 2018, 2:41 AM Eeli Kaikkonen  > wrote:
> 
> There are some people in the user forum who have spent time with
> these v4->v5 problems, including me and Rene. The consensus about
> the environment variables seems to be what Rene already said, that
> they should not (without explicit user intervention) be set for the
> system, but from KiCad itself. Nick confirmed that the current v5
> installer won't set them by default. They are still a problem if
> they have been set by v4 installer.
> 
> su 15. heinäk. 2018 klo 5.04 Strontium (strnty...@gmail.com
> ) kirjoitti:
> 
> I honestly think each major revision of KiCad should be
> considered a NEW
> program, installs to a new place has its configuration and
> libraries all
> in a new location.  Only Incremental updates 5.0 -> 5.1 should be
> considered upgrades.
> 
> 
> I agree. It's probable that many users will want to continue with v4
> for old projects but v5 for new, and in the future the same thing
> will be true for v5 vs. v6, because they break the file/project
> compatibility. But where the compatibility is kept it's more likely
> to be considered as just an upgrade.
>  
> 
> Kicad configuration isn't complex or onerous so if a user wants
> to bring
> a Kicad4 config into Kicad5 or 6 or whatever, then they do that
> themselves, otherwise after install Kicad5 is a fresh blank
> sheet with
> no relationship to anything that happened on the users computer in
> Kicad4.  I am not familiar with the issues on Windows, but I
> would have
> thought now this is mostly a packaging issue only??
> 
> 
> I tried modifying the Windows installer, I only needed to replace
> some of "KiCad" strings with "KiCad5" and it can install v5
> alongside v4 independently. The only problem is the configuration
> and the environment variables set by v4. They can be handled with a
> startup script. See
> https://forum.kicad.info/t/does-v5-have-to-overwrite-on-install/11282 for
> some details.
> 
> I also agree if it can't work this way now on Windows, then its
> all a
> bit late for V5, but maybe V6 can consider itself a new program
> distinct
> from V5.  This would also help with testing, because users could
> use V5
> for daily work, but also easily install a V6 daily side by side.
> 
> 
> All this could be done with the Windows installer, provided that a
> startup script would be offered.
> 
> To make this all, at least the startup script, as simple as possible
> I would suggest one (or three) small changes to KiCad (for 5.1, or
> even 5.0.1?). Add command line options --config=/path/to/config and
> --ignore-env-vars. The former is obvious and would override
> KICAD_CONFIG_HOME system environment variable. The latter would make
> KiCad ignore all system environment variables and use the current
> internal logic and the path settings UI instead. That way the old
> variables could be left for v4 and the newer versions would be
> completely independent if the command line switches were used. The
> command line switch for the config path would be mostly for
> convenience. In Windows starting a program with custom environment
> variables is tedious and error prone to write (see the above
> mentioned thread). Command line switches are much easier.
> 
> It could also be possible to make --ignore-env-vars=true by default.
> Sharing the environment variables would be a special case if the
> user wants that.
> 
> The general problem with using system environment variables is that
> they are good for situations when there's only one version of a
> program on the system, and/or several processes share the same
> variable values. Neither of them is true for parallel installations
> of KiCad.
> 
> 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] Translation of dialog_bom_help.html

I noticed that the environment variables config dialog also has html-based
help message. So I changed eeschema/dialogs/dialog_bom.cpp in the same
manear as it done in common/dialogs/dialog_env_var_config.cpp.

сб, 14 июл. 2018 г. в 10:01, jp charras :

> Le 12/07/2018 à 14:59, Simon Richter a écrit :
> > Hi,
> >
> > On 11.07.2018 21:51, Wayne Stambaugh wrote:
> >
> >> This probably should have been done as a cpp string wrapped with the
> >> translation macro _().  I'm not sure there is anything we can do to make
> >> this translatable.  Anyone else have any ideas?
> >
> > We could move the entire text to the user documentation, and make the
> > dialog point at it.
> >
> > If the dialog is unusable without the documentation, then that is a
> > separate problem, but I doubt it's that bad.
> >
> >Simon
>
> It is already in doc:
>
> http://docs.kicad-pcb.org/stable/en/eeschema.html#creating-customized-netlists-and-bom-files
> Of course, this doc could be enhanced (if there is a volunteer to do that)
>
> I am thinking this kind of doc must be in the dialog, because the command
> line needs explanations.
> The user cannot know without help how to create/modify this command line.
>
> In dialog, it can be a basic ASCII text (or using very basic html
> controls) (like in some other
> dialogs).
>
> --
> 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
>
From dd900dfc3f1081048d544a5cf8997785858f999a Mon Sep 17 00:00:00 2001
From: Baranovskiy Konstantin 
Date: Mon, 16 Jul 2018 12:58:49 +0300
Subject: [PATCH] Help message of BOM dialog is translatable now.

---
 eeschema/CMakeLists.txt   |  17 --
 eeschema/dialogs/dialog_bom.cpp   | 214 ++-
 eeschema/dialogs/dialog_bom_help.html | 286 --
 3 files changed, 208 insertions(+), 309 deletions(-)
 delete mode 100644 eeschema/dialogs/dialog_bom_help.html

diff --git a/eeschema/CMakeLists.txt b/eeschema/CMakeLists.txt
index 819812d07..e1e86ccb5 100644
--- a/eeschema/CMakeLists.txt
+++ b/eeschema/CMakeLists.txt
@@ -253,23 +253,6 @@ else()
 set( EESCHEMA_RESOURCES eeschema.rc )
 endif()
 
-# Create a C++ compilable string initializer containing html text into a *.h file:
-add_custom_command(
-OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/dialogs/dialog_bom_help_html.h
-COMMAND ${CMAKE_COMMAND}
--DinputFile=${CMAKE_CURRENT_SOURCE_DIR}/dialogs/dialog_bom_help.html
--DoutputFile=${CMAKE_CURRENT_SOURCE_DIR}/dialogs/dialog_bom_help_html.h
--P ${CMAKE_MODULE_PATH}/Html2C.cmake
-DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/dialogs/dialog_bom_help.html
-COMMENT "creating ${CMAKE_CURRENT_SOURCE_DIR}/dialogs/dialog_bom_help_html.h
-   from ${CMAKE_CURRENT_SOURCE_DIR}/dialogs/dialog_bom_help.html"
-)
-
-set_source_files_properties( dialogs/dialog_bom.cpp
-PROPERTIES
-OBJECT_DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/dialogs/dialog_bom_help_html.h
-)
-
 if( APPLE )
 # setup bundle
 set( EESCHEMA_RESOURCES eeschema.icns eeschema_doc.icns )
diff --git a/eeschema/dialogs/dialog_bom.cpp b/eeschema/dialogs/dialog_bom.cpp
index 106f4751b..4855ec940 100644
--- a/eeschema/dialogs/dialog_bom.cpp
+++ b/eeschema/dialogs/dialog_bom.cpp
@@ -48,10 +48,6 @@
 #define BOM_PLUGINS_KEY wxT("bom_plugins")
 #define BOM_PLUGIN_SELECTED_KEY wxT("bom_plugin_selected")
 
-const char * s_bomHelpInfo =
-#include 
-;
-
 #include 
 
 using namespace T_BOMCFG_T;
@@ -658,11 +654,217 @@ void DIALOG_BOM::OnEditPlugin( wxCommandEvent& event )
 
 void DIALOG_BOM::OnHelp( wxCommandEvent& event )
 {
+wxString msg = _( "1 - Full documentation:" );
+msg << wxT( "" );
+msg << _( "The Eeschema documentation describes this "
+  "intermediate netlist and gives examples." );
+msg << wxT( "" );
+msg << _( "See also " );
+msg << wxT( "https://answers.launchpad.net/kicad/+faq/2265" );
+msg << wxT( "" );
+
+msg << _( "2 - The intermediate Netlist File" );
+msg << wxT( "" );
+msg << _( "BOM files (and netlist files) can be created from an "
+  "Intermediate netlist file created by Eeschema." );
+msg << wxT( "" );
+msg << _( "This file uses XML syntax and is called the intermediate "
+  "netlist. The intermediate netlist includes a large amount of "
+  "data about your board and because of this, it can be used with "
+  "post-processing to create a BOM or other reports." );
+msg << wxT( "" );
+msg << _( "Depending on the output (BOM or netlist), different subsets of "
+  "the complete Intermediate Netlist file will be used in the "
+  "post-processing." );
+msg << wxT( "" );
+
+msg << _( "3 - Conversion to a new format" );
+msg << wxT( "" );
+

[Kicad-developers] Questions on 6.0 eeschema file format

Do we plan on having inheritance replace aliases?

If so, what do we do with old symbols?  (Will we have to support both 
paradigms?)
___
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 branch

Thanks, JP!  I’ll make the fix.

> On 16 Jul 2018, at 09:24, jp charras  wrote:
> 
> Le 16/07/2018 à 10:10, Jeff Young a écrit :
>> Well, rats.  I couldn’t figure out why "git rebase —interactive" wasn’t 
>> showing me any of my
>> commits, and it turns out that I somehow accidentally merged them all to 
>> origin/5.1 sometime last
>> night.  Anyway, you don’t have to fetch my private branch to test it 
>> anymore; the kicad 5.1 branch
>> will do nicely.
>> 
>> Let me know if the paged dialog issues are keeping anyone from getting work 
>> done and I’ll try to
>> figure out how to revert those commits.
> 
> Hi, Jeff
> The paged dialog issue is due to the fact the panels (pages) have an 
> incorrect parent.
> Currently, these panels have the dialog itself as parent.
> They should have m_treebook (the wxTreeBook similar to a wxNotebook) as 
> parent.
> 
> (This change fixes the issue on W7)
> 
>> 
>> Cheers,
>> Jeff.
> 
> -- 
> 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


___
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 branch

Le 16/07/2018 à 10:10, Jeff Young a écrit :
> Well, rats.  I couldn’t figure out why "git rebase —interactive" wasn’t 
> showing me any of my
> commits, and it turns out that I somehow accidentally merged them all to 
> origin/5.1 sometime last
> night.  Anyway, you don’t have to fetch my private branch to test it anymore; 
> the kicad 5.1 branch
> will do nicely.
> 
> Let me know if the paged dialog issues are keeping anyone from getting work 
> done and I’ll try to
> figure out how to revert those commits.

Hi, Jeff
The paged dialog issue is due to the fact the panels (pages) have an incorrect 
parent.
Currently, these panels have the dialog itself as parent.
They should have m_treebook (the wxTreeBook similar to a wxNotebook) as parent.

(This change fixes the issue on W7)

> 
> Cheers,
> Jeff.

-- 
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] 5.1 branch

Well, rats.  I couldn’t figure out why "git rebase —interactive" wasn’t showing 
me any of my commits, and it turns out that I somehow accidentally merged them 
all to origin/5.1 sometime last night.  Anyway, you don’t have to fetch my 
private branch to test it anymore; the kicad 5.1 branch will do nicely.

Let me know if the paged dialog issues are keeping anyone from getting work 
done and I’ll try to figure out how to revert those commits.

Cheers,
Jeff.

> On 16 Jul 2018, at 08:45, Eeli Kaikkonen  wrote:
> 
> 
> 
> ma 16. heinäk. 2018 klo 8.48 Nick Østergaard (oe.n...@gmail.com 
> ) kirjoitti:
> Can you edit anything on them? Can you provide a screenshot of the 
> preferences dialog?
> 
> 
> https://drive.google.com/file/d/1eq26OWT7TDeBTnbyAfUpUckT5V6MuwU8/view?usp=sharing
>  
> 
>  

___
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 Kicad Features