Re: [Kicad-developers] 5.1 UI feedback

[José Ignacio]

I like the button idea, the same thing should be done in the schematic
field editor, that would basically replace cvpcb for most usecases.

On Thu, Jul 19, 2018 at 2:53 PM, Jeff Young  wrote:

> I thought there was already a bug for this (reported by Gabriel perhaps?),
> but I can’t seem to find it.
>
>
> On 19 Jul 2018, at 20:40, Wayne Stambaugh  wrote:
>
> I second this motion.  I didn't find the right click trick so I fell
> back to cvpcb which is overkill to change the footprint of a single
> symbol.  A tooltip might be useful here as well.
>
> On 7/19/2018 3:19 PM, Diego Herranz wrote:
>
> Hi,
>
> I've started to test these changes and, on the Symbol properties dialog,
> I found it hard to assign a footprint.
> Before, there used to be a button to open the Footprint selector window.
> Now you seem to need right click on the footprint field and "select
> footprint" and that only works if you're not editing the text of that
> field. It took me a while to find out.
> I don't find it straightforward.
>
> Maybe a double-click on that field should open the Footprint selector?
> Maybe a button like attached? (Mind my poor mock-up)
> Any other suggestions?
>
> Thanks for all the work on this.
>
> Diego
>
>
>
>
>
> On Wed, Jul 18, 2018 at 6:00 PM Jeff Young  > wrote:
>
>Changes in.  Could Kevin or Wayne please post the following dialogs
>one more time:
>
>1) Change Footprints
>2) CvPCB (with footprint selected from right column)
>3) Footprint Properties
>4) Edit Track & Via Properties
>
>Thanks,
>Jeff.
>
> On 18 Jul 2018, at 15:28, Jeff Young 
>> wrote:
>
>
> Yeah, the “Show” label of the Output Messages checkboxes is
>
>misplaced too.
>
>
> I’ll have another build along shortly….
>
> Cheers,
> Jeff.
>
>
> On 18 Jul 2018, at 15:05, Kevin Cozens 
>> wrote:
>
>
> On 2018-07-18 08:32 AM, Wayne Stambaugh wrote:
>
> Attached are the updated screen shots.
>
>
> One minor point. In the first screen shot the icon with the books
>
>and magnifying glass is on the right side of the dialog the first
>time it appears but is just after the end of the entry field the
>second time it appears.
>
>
> It would look a little better if they were in the same relative
>
>horizontal position.
>
>
> --
> Cheers!
>
> Kevin.
>
> http://www.ve3syb.ca/   | "Nerds make the shiny
>
>things that
>
> https://www.patreon.com/KevinCozens | distract the
>
>mouth-breathers, and
>
>| that's why we're powerful"
> Owner of Elecraft K2 #2172  |
> #include  | --Chris Hardwick
>
> ___
> 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   : 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 : 

Re: [Kicad-developers] [PATCH 1 / 2] Add check to use std::optional

[Thomas Figueroa]

Ah, you’re totally right. That escaped my mind (hard to track bug w.r.t. std vs 
boost). I wasn’t sure how things like that were handled (std vs boost variant 
also comes to mind).


From: Seth Hillbrand 
Sent: Thursday, July 19, 2018 3:28:43 PM
To: Thomas Figueroa
Cc: KiCad Developers
Subject: Re: [Kicad-developers] [PATCH 1 / 2] Add check to use std::optional

Hi Thomas-

Thank you for the contribution!  Right now KiCad only uses C++11.  But once we 
move up to C++17, we will want to minimize code paths so that everyone sees the 
same result.  Otherwise we risk introducing bugs that _really_ hard to track 
down.  In other words, replacing boost:: with std:: in this case with no #if 
clause will make sense once the call is made to change up to C++17.  Maybe we 
can do that during v6 development?

-S

Am Do., 19. Juli 2018 um 12:58 Uhr schrieb Thomas Figueroa 
mailto:tom_figue...@hotmail.com>>:
Hello everyone, my name is Thomas. I’ve posted a few times on here to submit 
some feedback, but
now I have finally mustered the courage to submit stuff for development.
This first pair of patches is really just to get a feel for things and get 
feedback on any issues with
my process or potential problems.
I look forward to contributing to KiCad as much as it has contributed to me 
having it for my job 


___
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] Stable 5 release.

[Nick Østergaard]

Awesome, thanks for the update!
Den fre. 20. jul. 2018 kl. 00.48 skrev Rene Pöschl :
>
> The library repos should now all be tagged. (Github had some server
> problems so it all took quite some time. I hope nothing got damaged
> because of that.)
>
> On 19/07/18 10:49, Nick Østergaard wrote:
> > This sounds good. Thank you.
> > Den tor. 19. jul. 2018 kl. 10.43 skrev Rene Pöschl :
> >> On 18/07/18 19:59, Carsten Schoenert wrote:
> >>> Am 18.07.18 um 19:55 schrieb Rene Pöschl:
> > I'm traveling the whole Saturday and Sunday to Debian DebCamp and
> > DebConf in Taiwan and working on packaging kicad-packages3d on a laptop
> > is PITA. So I'd like to this at home on a more powerful machine at home
> > latest on Friday afternoon.
> >
> > Thanks!
> >
>  By the way when giving deadlines stating your timezone might be
>  required. As you did not state one i choose to use CET summer time ;)
> >>> Argh, yes, a damn phone call has interrupted me while writing ...
> >>> But yes, CEST is the timezone I currently live. :-)
> >>>
>  But if everything goes to plan i will tag the libs in a few hours anyway
>  giving you guys ample time.
> >>> Thanks!
> >>>
> >> Sadly i worked too long yesterday so i have been too tired to fully
> >> check the libs.
> >>
> >> I also have one or two PRs open that i want to check if they are correct
> >> as they would fix some more minor issues. (Not a holdup but if they are
> >> ready i would like to include them.)
> >>
> >>
> >> So i will create the tags today in the evening. (Thursday 23:59 CEST
> >> plus or minus two hours) Sorry about the delay.
> >>
> >>
> >> ___
> >> 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] Stable 5 release.

[Rene Pöschl]

The library repos should now all be tagged. (Github had some server 
problems so it all took quite some time. I hope nothing got damaged 
because of that.)


On 19/07/18 10:49, Nick Østergaard wrote:

This sounds good. Thank you.
Den tor. 19. jul. 2018 kl. 10.43 skrev Rene Pöschl :

On 18/07/18 19:59, Carsten Schoenert wrote:

Am 18.07.18 um 19:55 schrieb Rene Pöschl:

I'm traveling the whole Saturday and Sunday to Debian DebCamp and
DebConf in Taiwan and working on packaging kicad-packages3d on a laptop
is PITA. So I'd like to this at home on a more powerful machine at home
latest on Friday afternoon.

Thanks!


By the way when giving deadlines stating your timezone might be
required. As you did not state one i choose to use CET summer time ;)

Argh, yes, a damn phone call has interrupted me while writing ...
But yes, CEST is the timezone I currently live. :-)


But if everything goes to plan i will tag the libs in a few hours anyway
giving you guys ample time.

Thanks!


Sadly i worked too long yesterday so i have been too tired to fully
check the libs.

I also have one or two PRs open that i want to check if they are correct
as they would fix some more minor issues. (Not a holdup but if they are
ready i would like to include them.)


So i will create the tags today in the evening. (Thursday 23:59 CEST
plus or minus two hours) Sorry about the delay.


___
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

[Jeff Young]

Cool.  Thanks, Tom.

> On 19 Jul 2018, at 16:28, Tomasz Wlostowski  wrote:
> 
> On 18/07/18 13:06, Jeff Young wrote:
>> Hi Tom, et al,
>> 
>> I assume we just need to drop wxDC for the canvas, but that UI constructs 
>> (such as colour swatches, etc.) would continue to use wxDC?
> 
> To clarify: SCH/PCB preview widgets will also use GAL.
> 
> Tom
> 
>> 
>> Thanks,
>> Jeff.
>> 
>> 
>>> On 17 Jul 2018, at 15:44, Tomasz Wlostowski  
>>> wrote:
>>> 
>>> On 16/07/18 17:54, Wayne Stambaugh wrote:
 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.
 
>>> Hi Wayne,
>>> 
>>> The sooner we drop wxDC, the better for Kicad. I wouldn't do it because
>>> of the GTK3/Python issues (since it's a neverending Linux problem of
>>> changing APIs and libraries), but for performance reasons - on OSX for
>>> instance, eeschema is sometimes barely usable because of slow drawing.
>>> 
>>> I hope I'll be able to devote some time to cleaning up the eeschema-gal
>>> code in the coming weeks. So far, the main canvas and the library editor
>>> are implemented, with the symbol preview widgets & library browser
>>> remaining.
>>> 
>>> 
 I'm assuming the printing is a v6 goal.
>>> 
>>> Orson made quite a lot of progress with Cairo printing. IIRC it can make
>>> it to the 5.1.
>>> 
>>> Cheers,
>>> Tom
>>> 
 
 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
 
>>> 
>>> 
>>> ___
>>> 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] Column label "Qty" of the symbol fields editor is not translatable.

[Jeff Young]

Thanks for your contribution, Konstantin!  

I’ve applied your patch to the 5.1 and 6.0 branches.

Cheers,
Jeff.


> On 15 Jul 2018, at 06:36, Константин Барановский 
>  wrote:
> 
> 
> <0001-Fix-untranslatable-label.patch>___
> 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] Eeschema plot dialog issue.

[Jeff Young]

I’ve merged code that I think will fix the issue on non-double-buffered 
platforms.  I you could double-check that would be great.

Cheers,
Jeff.


> On 19 Jul 2018, at 21:07, Jeff Young  wrote:
> 
> Actually I think it happens on OSX too, you just don’t notice because of 
> double-buffering.  Appears I failed to put hysteresis into OnUpdateUI. 
> 
>> On 19 Jul 2018, at 18:19, Wayne Stambaugh  wrote:
>> 
>> Jeff,
>> 
>> Please take a look at the attached video of the eeschema plot dialog.
>> Notice the page size control be refreshed (flckering).  The makes
>> selecting a page size impossible although the plotting still works.  The
>> same thing happens with the fillet radius static text in the zone
>> properties dialog in pcbnew.  This looks suspiciously like an infinite
>> event loop possibly caused by your macos focus fix.
>> 
>> Cheers,
>> 
>> Wayne
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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

Re: [Kicad-developers] [PATCH 1 / 2] Add check to use std::optional

[Seth Hillbrand]

Hi Thomas-

Thank you for the contribution!  Right now KiCad only uses C++11.  But once
we move up to C++17, we will want to minimize code paths so that everyone
sees the same result.  Otherwise we risk introducing bugs that _really_
hard to track down.  In other words, replacing boost:: with std:: in this
case with no #if clause will make sense once the call is made to change up
to C++17.  Maybe we can do that during v6 development?

-S

Am Do., 19. Juli 2018 um 12:58 Uhr schrieb Thomas Figueroa <
tom_figue...@hotmail.com>:

> Hello everyone, my name is Thomas. I’ve posted a few times on here to
> submit some feedback, but
>
> now I have finally mustered the courage to submit stuff for development.
>
> This first pair of patches is really just to get a feel for things and get
> feedback on any issues with
>
> my process or potential problems.
>
> I look forward to contributing to KiCad as much as it has contributed to
> me having it for my job 
>
>
>
>
> ___
> 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] Eeschema plot dialog issue.

[Jeff Young]

Actually I think it happens on OSX too, you just don’t notice because of 
double-buffering.  Appears I failed to put hysteresis into OnUpdateUI. 

> On 19 Jul 2018, at 18:19, Wayne Stambaugh  wrote:
> 
> Jeff,
> 
> Please take a look at the attached video of the eeschema plot dialog.
> Notice the page size control be refreshed (flckering).  The makes
> selecting a page size impossible although the plotting still works.  The
> same thing happens with the fillet radius static text in the zone
> properties dialog in pcbnew.  This looks suspiciously like an infinite
> event loop possibly caused by your macos focus fix.
> 
> Cheers,
> 
> Wayne
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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

Re: [Kicad-developers] [PATCH 2 / 2] Remove deprecated binary/unary function usages

[Thomas Figueroa]

deprecated_functionality.patch
Description: deprecated_functionality.patch
___
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] [PATCH 1 / 2] Add check to use std::optional

[Thomas Figueroa]

Hello everyone, my name is Thomas. I’ve posted a few times on here to submit 
some feedback, but
now I have finally mustered the courage to submit stuff for development.
This first pair of patches is really just to get a feel for things and get 
feedback on any issues with
my process or potential problems.
I look forward to contributing to KiCad as much as it has contributed to me 
having it for my job 




std_optional_option.patch
Description: std_optional_option.patch
___
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

[Jeff Young]

I thought there was already a bug for this (reported by Gabriel perhaps?), but 
I can’t seem to find it.

> On 19 Jul 2018, at 20:40, Wayne Stambaugh  wrote:
> 
> I second this motion.  I didn't find the right click trick so I fell
> back to cvpcb which is overkill to change the footprint of a single
> symbol.  A tooltip might be useful here as well.
> 
> On 7/19/2018 3:19 PM, Diego Herranz wrote:
>> Hi,
>> 
>> I've started to test these changes and, on the Symbol properties dialog,
>> I found it hard to assign a footprint.
>> Before, there used to be a button to open the Footprint selector window.
>> Now you seem to need right click on the footprint field and "select
>> footprint" and that only works if you're not editing the text of that
>> field. It took me a while to find out.
>> I don't find it straightforward.
>> 
>> Maybe a double-click on that field should open the Footprint selector?
>> Maybe a button like attached? (Mind my poor mock-up)
>> Any other suggestions?
>> 
>> Thanks for all the work on this.
>> 
>> Diego
>> 
>> 
>> 
>> 
>> 
>> On Wed, Jul 18, 2018 at 6:00 PM Jeff Young > >> wrote:
>> 
>>Changes in.  Could Kevin or Wayne please post the following dialogs
>>one more time:
>> 
>>1) Change Footprints
>>2) CvPCB (with footprint selected from right column)
>>3) Footprint Properties
>>4) Edit Track & Via Properties
>> 
>>Thanks,
>>Jeff.
>> 
>>> On 18 Jul 2018, at 15:28, Jeff Young mailto:j...@rokeby.ie>
>>>> wrote:
>>> 
>>> Yeah, the “Show” label of the Output Messages checkboxes is
>>misplaced too.
>>> 
>>> I’ll have another build along shortly….
>>> 
>>> Cheers,
>>> Jeff.
>>> 
>>> 
 On 18 Jul 2018, at 15:05, Kevin Cozens >>> 
>>>> wrote:
 
 On 2018-07-18 08:32 AM, Wayne Stambaugh wrote:
> Attached are the updated screen shots.
 
 One minor point. In the first screen shot the icon with the books
>>and magnifying glass is on the right side of the dialog the first
>>time it appears but is just after the end of the entry field the
>>second time it appears.
 
 It would look a little better if they were in the same relative
>>horizontal position.
 
 --
 Cheers!
 
 Kevin.
 
 http://www.ve3syb.ca/   | "Nerds make the shiny
>>things that
 https://www.patreon.com/KevinCozens | distract the
>>mouth-breathers, and
| that's why we're powerful"
 Owner of Elecraft K2 #2172  |
 #include  | --Chris Hardwick
 
 ___
 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 UI feedback

[Wayne Stambaugh]

I second this motion.  I didn't find the right click trick so I fell
back to cvpcb which is overkill to change the footprint of a single
symbol.  A tooltip might be useful here as well.

On 7/19/2018 3:19 PM, Diego Herranz wrote:
> Hi,
> 
> I've started to test these changes and, on the Symbol properties dialog,
> I found it hard to assign a footprint.
> Before, there used to be a button to open the Footprint selector window.
> Now you seem to need right click on the footprint field and "select
> footprint" and that only works if you're not editing the text of that
> field. It took me a while to find out.
> I don't find it straightforward.
> 
> Maybe a double-click on that field should open the Footprint selector?
> Maybe a button like attached? (Mind my poor mock-up)
> Any other suggestions?
> 
> Thanks for all the work on this.
> 
> Diego
> 
> 
> 
> 
> 
> On Wed, Jul 18, 2018 at 6:00 PM Jeff Young  > wrote:
> 
> Changes in.  Could Kevin or Wayne please post the following dialogs
> one more time:
> 
> 1) Change Footprints
> 2) CvPCB (with footprint selected from right column)
> 3) Footprint Properties
> 4) Edit Track & Via Properties
> 
> Thanks,
> Jeff.
> 
> > On 18 Jul 2018, at 15:28, Jeff Young  > wrote:
> >
> > Yeah, the “Show” label of the Output Messages checkboxes is
> misplaced too.
> >
> > I’ll have another build along shortly….
> >
> > Cheers,
> > Jeff.
> >
> >
> >> On 18 Jul 2018, at 15:05, Kevin Cozens  > wrote:
> >>
> >> On 2018-07-18 08:32 AM, Wayne Stambaugh wrote:
> >>> Attached are the updated screen shots.
> >>
> >> One minor point. In the first screen shot the icon with the books
> and magnifying glass is on the right side of the dialog the first
> time it appears but is just after the end of the entry field the
> second time it appears.
> >>
> >> It would look a little better if they were in the same relative
> horizontal position.
> >>
> >> --
> >> Cheers!
> >>
> >> Kevin.
> >>
> >> http://www.ve3syb.ca/               | "Nerds make the shiny
> things that
> >> https://www.patreon.com/KevinCozens | distract the
> mouth-breathers, and
> >>                                   | that's why we're powerful"
> >> Owner of Elecraft K2 #2172          |
> >> #include      |             --Chris Hardwick
> >>
> >> ___
> >> 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   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 5.1 UI feedback

[Diego Herranz]

Hi,

I've started to test these changes and, on the Symbol properties dialog, I
found it hard to assign a footprint.
Before, there used to be a button to open the Footprint selector window.
Now you seem to need right click on the footprint field and "select
footprint" and that only works if you're not editing the text of that
field. It took me a while to find out.
I don't find it straightforward.

Maybe a double-click on that field should open the Footprint selector?
Maybe a button like attached? (Mind my poor mock-up)
Any other suggestions?

Thanks for all the work on this.

Diego





On Wed, Jul 18, 2018 at 6:00 PM Jeff Young  wrote:

> Changes in.  Could Kevin or Wayne please post the following dialogs one
> more time:
>
> 1) Change Footprints
> 2) CvPCB (with footprint selected from right column)
> 3) Footprint Properties
> 4) Edit Track & Via Properties
>
> Thanks,
> Jeff.
>
> > On 18 Jul 2018, at 15:28, Jeff Young  wrote:
> >
> > Yeah, the “Show” label of the Output Messages checkboxes is misplaced
> too.
> >
> > I’ll have another build along shortly….
> >
> > Cheers,
> > Jeff.
> >
> >
> >> On 18 Jul 2018, at 15:05, Kevin Cozens  wrote:
> >>
> >> On 2018-07-18 08:32 AM, Wayne Stambaugh wrote:
> >>> Attached are the updated screen shots.
> >>
> >> One minor point. In the first screen shot the icon with the books and
> magnifying glass is on the right side of the dialog the first time it
> appears but is just after the end of the entry field the second time it
> appears.
> >>
> >> It would look a little better if they were in the same relative
> horizontal position.
> >>
> >> --
> >> Cheers!
> >>
> >> Kevin.
> >>
> >> http://www.ve3syb.ca/   | "Nerds make the shiny things that
> >> https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
> >>   | that's why we're powerful"
> >> Owner of Elecraft K2 #2172  |
> >> #include  | --Chris Hardwick
> >>
> >> ___
> >> 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 testing

[Wayne Stambaugh]

Windows.  I can test linux after I get home from work this evening.

On 7/19/2018 2:14 PM, Jeff Young wrote:
> Windows or Linux?
> 
> It should highlight to two footnotes, although I’m not sure I’ve tested 
> courtyard errors.
> 
> Try a track too close to a pad, and it should highlight the track and the pad.
> 
> (But probably not on Windows, as it’s based on the same code we use for 
> selection disambiguation highlighting.)
> 
> 
>> On 19 Jul 2018, at 18:28, Wayne Stambaugh  wrote:
>>
>> What exactly is supposed to get highlighted?  I have board I'm working
>> on with some overlapped courtyard errors and I don't see any
>> highlighting when I select a error in the drc dialog or hover over the
>> drc markers.  I do see the board pan to show the drc marker when it is
>> underneath the dialog.
>>
>> Wayne
>>
>> On 7/19/2018 12:03 PM, Jeff Young wrote:
>>> Could someone test the DRC highlighting on Linux and Windows.  (Since it 
>>> uses the same selection highlighting code my guess is that it doesn’t work 
>>> on Windows.)
>>>
>>> Run a DRC on a board that has some errors.
>>> Right click on an error in the DRC errors list.
>>> Hover back and forth over the two entries in the context menu.  The items 
>>> on the board should highlight.
>>>
>>> Thanks,
>>> Jeff.
>>> ___
>>> 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 testing

[Jeff Young]

Windows or Linux?

It should highlight to two footnotes, although I’m not sure I’ve tested 
courtyard errors.

Try a track too close to a pad, and it should highlight the track and the pad.

(But probably not on Windows, as it’s based on the same code we use for 
selection disambiguation highlighting.)


> On 19 Jul 2018, at 18:28, Wayne Stambaugh  wrote:
> 
> What exactly is supposed to get highlighted?  I have board I'm working
> on with some overlapped courtyard errors and I don't see any
> highlighting when I select a error in the drc dialog or hover over the
> drc markers.  I do see the board pan to show the drc marker when it is
> underneath the dialog.
> 
> Wayne
> 
> On 7/19/2018 12:03 PM, Jeff Young wrote:
>> Could someone test the DRC highlighting on Linux and Windows.  (Since it 
>> uses the same selection highlighting code my guess is that it doesn’t work 
>> on Windows.)
>> 
>> Run a DRC on a board that has some errors.
>> Right click on an error in the DRC errors list.
>> Hover back and forth over the two entries in the context menu.  The items on 
>> the board should highlight.
>> 
>> Thanks,
>> Jeff.
>> ___
>> 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 testing

[Wayne Stambaugh]

What exactly is supposed to get highlighted?  I have board I'm working
on with some overlapped courtyard errors and I don't see any
highlighting when I select a error in the drc dialog or hover over the
drc markers.  I do see the board pan to show the drc marker when it is
underneath the dialog.

Wayne

On 7/19/2018 12:03 PM, Jeff Young wrote:
> Could someone test the DRC highlighting on Linux and Windows.  (Since it uses 
> the same selection highlighting code my guess is that it doesn’t work on 
> Windows.)
> 
> Run a DRC on a board that has some errors.
> Right click on an error in the DRC errors list.
> Hover back and forth over the two entries in the context menu.  The items on 
> the board should highlight.
> 
> Thanks,
> Jeff.
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

[Kicad-developers] Eeschema plot dialog issue.

[Wayne Stambaugh]

Jeff,

Please take a look at the attached video of the eeschema plot dialog.
Notice the page size control be refreshed (flckering).  The makes
selecting a page size impossible although the plotting still works.  The
same thing happens with the fillet radius static text in the zone
properties dialog in pcbnew.  This looks suspiciously like an infinite
event loop possibly caused by your macos focus fix.

Cheers,

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

Re: [Kicad-developers] Branches

[Wayne Stambaugh]

This was pretty much how I saw the development working which is why I
created a separate 5.1 branch.  However, if we are not going to allow
new features to be merged into the master branch (6.0-dev) (and it seems
that is the consensus) then I propose that we do all of the 5.1
development in the master branch.  I would rather not delete the 5.1
branch because the tags and version strings are already in place and
reverting all the changes thus far would be painful.  Assuming 5.1 and
master are currently the same, we can either merge from master to 5.1 as
we go or one big merge when we are ready to start creating 5.1 release
candidates.  I would prefer that we merge as we go which will keep the
two branches synced an minimize issues.  Is this acceptable to everyone?

On 7/19/2018 12:15 PM, Carsten Schoenert wrote:
> Hi,
> 
> for me as a person which doesn't do any active source code development
> on KiCad it looks like there is some confusion in the wild what will or
> should happen in which branch.
> 
> Sorry if I haven't get it until now, what are the goals of the branch
> 5.1 the project wanted to archive?
> 
> And what is 6.0, master or $(what else) are for?
> 
> If these questions can be answered it will be much more clear what
> development should happen in which branch and what should be merged into
> which other branch.
> 
> KiCad has now more active developers than ever I think, but I can't
> really see a branch model that is fitting the current and future
> situations. Out there are various branching models and the KiCad project
> needs to decide which will work best for the project. The classical
> master plus release branches isn't working great anymore if you want to
> work on multiple parts in parallel.
> 
> I suggest to have a look at the following website.
> 
> https://nvie.com/posts/a-successful-git-branching-model/
> 
> It describes what options are count and how a workflow would look like,
> I think it would be also usable for KiCad (not in a full blown version).
> 
> In the long term you wont do cherry-picking for the plain development as
> this wont work smoothly at one point anymore (as Wayne already
> mentioned). Single cherry-picking is fine, but in the end you will come
> to merge commits as you mostly want to have all the new code in a later
> release. Every upstream project I know is working this way.
> 
> Backporting security or hot fixes are slightly different and require
> often cherry-picking with small or much modifications as you wont
> introduce new features into old code by merges. But also this can be
> done in a local feature branch which gets merged then into the stable
> release branch. Depends mostly on the amount of the needed backport.
> 
> So to call it again, what is the branch 5.1 intended for? Only for the
> GTK+3 fixes? If yes it's fine to do it here and merged these changes
> (which will be needed also in the current ongoing nightly development)
> into master, develop, 6.0 or what ever named branch. Just renaming
> master into something different without a common and required workflow
> is nothing, then it's really just another name.
> 
> So I would propose the following as there are already some branches out
> there which we all need to know and to handle.
> 
> 5.0 will get all the fixes which will reflect in versions 5.0.x, commits
> will mostly get cherry-picked from master. Hopefully not that much.
> 
> 5.1 will get at least the GTK+3 adjustments and will finally cover all
> versions 5.1.x (like 5.0 for 5.0.x). The GTK stuff is developed in this
> branch and will be merged into master. Any other changes than GTK+3
> which should be released with versions 5.1.x are also made here and get
> merged into master.
> 
> master is and will be the main nightly development channel. All changes
> here are mainly for any releases greater than 5.x.x.
> 
> This all are just my thoughts as I would like to see it, the above
> suggestion is based on some experiences I have made with other projects
> and work. Please remember that also the l10n and documentation trees are
> related to this! The base for all future work for all side needs to be
> clear early as possible.
> 
> Anyhow ...
> 
> (Hmm, I don't wanted to a top posting but my answer wasn't fitting to
> any made statement.)
> 
> Am 19.07.2018 um 17:19 schrieb Wayne Stambaugh:
>> You are preaching to the choir.  I did most of the maintenance on the
>> 4.0 branch.  Initially it was easy but it didn't take long for it to
>> become a PITA.  If no one else objects, I would be more than happy to
>> make that the policy.  If that is indeed what we want to do, I would
>> delete the 5.1 branch.  It will push v6 development back significantly.
>>
>> On 7/19/2018 11:10 AM, Jon Evans wrote:
>>> FWIW, as someone who is also maintaining parallel feature branches, I
>>> agree with Orson and John.  Now that we have committed to this 5.1 idea,
>>> we should just make it happen in master.  I think if we keep both master
>>> and 5.1 

Re: [Kicad-developers] Tesselation Ideas

[Seth Hillbrand]

Am Do., 19. Juli 2018 um 00:49 Uhr schrieb Tomasz Wlostowski <
tomasz.wlostow...@cern.ch>:

> On 19/07/18 06:15, Seth Hillbrand wrote:
> > ​Hi All-
> >
> > Our current triangulation caching is based on the poly2tri codebase and
> > has a number of constraints.  Most notably, it does not allow touching
> > holes, holes on the boundary or duplicate vertices.  In these cases, we
> > do not cache the triangulation and instead use the OpenGL single-thread
> > triangulation routine each time we draw a complicated polygon.  This has
> > the side-effect of making some boards much slower in Accelerated mode
> > than in Fallback.​
> >
> > I've been noodling with an idea for how to better cache our
> > triangulation and I think it's ready for some wider testing.  It
> > combines the Sloan ear-cutting algorithm with a plane division and
> > simplication approach to address difficult polygons.  It generally
> > follows the approach of Lamot and Zalik
> > (https://www.sciencedirect.com/science/article/pii/S0097849302002819)
> > but implements some of the shortcuts from the mapbox earcut library
> > (https://github.com/mapbox/earcut)
> >
> > The code is located in my GitHub
> > (https://github.com/sethhillbrand/kicad-source-mirror/tree/tesselation).
> If
> > you clone the tree, be sure to check out the branch "tesselation".
> >
> > Comments/feedback greatly appreciated.
>
> Wow, just tried the code, it's quite fast :) Good job. I've been trying
> to use TTL/HalfEdge or poly2tri for such triangulations but without much
> success.
>
> Tom
>
> PS. Does your algorithm support arbitrary Steiner points (i.e. adding a
> regular grid inside the polygon area to obtain more regularly shaped
> triangles which can be efficiently indexed using an R-Tree)?
>
>
​Thanks for testing.  I had similar experiences with TTL.  SGI's libtess
worked for me but is exceptionally slow.

Steiner points is an excellent idea.  I'd been struggling with overlapping
bounding boxes making solutions to lp:1718831 excessively slow.  I think
that might be helpful there.  The code doesn't currently support steiner
points (they are removed during the updateList() stage as NULL triangles).
I use your FractureSingle routine to eliminate holes, so I think I'd need
to mark the steiner points there to avoid removing them later.
Alternatively, maybe we could just allow NULL triangles when forming the
list but not allow them to be an ear and drop them during the last pass if
the polygon can't be triangulated.  That might be the best approach.

-Seth
___
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] Branches

[Carsten Schoenert]

Hi,

for me as a person which doesn't do any active source code development
on KiCad it looks like there is some confusion in the wild what will or
should happen in which branch.

Sorry if I haven't get it until now, what are the goals of the branch
5.1 the project wanted to archive?

And what is 6.0, master or $(what else) are for?

If these questions can be answered it will be much more clear what
development should happen in which branch and what should be merged into
which other branch.

KiCad has now more active developers than ever I think, but I can't
really see a branch model that is fitting the current and future
situations. Out there are various branching models and the KiCad project
needs to decide which will work best for the project. The classical
master plus release branches isn't working great anymore if you want to
work on multiple parts in parallel.

I suggest to have a look at the following website.

https://nvie.com/posts/a-successful-git-branching-model/

It describes what options are count and how a workflow would look like,
I think it would be also usable for KiCad (not in a full blown version).

In the long term you wont do cherry-picking for the plain development as
this wont work smoothly at one point anymore (as Wayne already
mentioned). Single cherry-picking is fine, but in the end you will come
to merge commits as you mostly want to have all the new code in a later
release. Every upstream project I know is working this way.

Backporting security or hot fixes are slightly different and require
often cherry-picking with small or much modifications as you wont
introduce new features into old code by merges. But also this can be
done in a local feature branch which gets merged then into the stable
release branch. Depends mostly on the amount of the needed backport.

So to call it again, what is the branch 5.1 intended for? Only for the
GTK+3 fixes? If yes it's fine to do it here and merged these changes
(which will be needed also in the current ongoing nightly development)
into master, develop, 6.0 or what ever named branch. Just renaming
master into something different without a common and required workflow
is nothing, then it's really just another name.

So I would propose the following as there are already some branches out
there which we all need to know and to handle.

5.0 will get all the fixes which will reflect in versions 5.0.x, commits
will mostly get cherry-picked from master. Hopefully not that much.

5.1 will get at least the GTK+3 adjustments and will finally cover all
versions 5.1.x (like 5.0 for 5.0.x). The GTK stuff is developed in this
branch and will be merged into master. Any other changes than GTK+3
which should be released with versions 5.1.x are also made here and get
merged into master.

master is and will be the main nightly development channel. All changes
here are mainly for any releases greater than 5.x.x.

This all are just my thoughts as I would like to see it, the above
suggestion is based on some experiences I have made with other projects
and work. Please remember that also the l10n and documentation trees are
related to this! The base for all future work for all side needs to be
clear early as possible.

Anyhow ...

(Hmm, I don't wanted to a top posting but my answer wasn't fitting to
any made statement.)

Am 19.07.2018 um 17:19 schrieb Wayne Stambaugh:
> You are preaching to the choir.  I did most of the maintenance on the
> 4.0 branch.  Initially it was easy but it didn't take long for it to
> become a PITA.  If no one else objects, I would be more than happy to
> make that the policy.  If that is indeed what we want to do, I would
> delete the 5.1 branch.  It will push v6 development back significantly.
> 
> On 7/19/2018 11:10 AM, Jon Evans wrote:
>> FWIW, as someone who is also maintaining parallel feature branches, I
>> agree with Orson and John.  Now that we have committed to this 5.1 idea,
>> we should just make it happen in master.  I think if we keep both master
>> and 5.1 branch running in parallel, inevitably one or the other of them
>> will be less tested / more broken unless people spend a bunch of time
>> doing the work of keeping them synchronized manually.  The cost of this
>> doesn't seem to outweigh the benefit of being able to merge some 6.0
>> features into master sooner.
>>
>> On Thu, Jul 19, 2018 at 11:03 AM John Beard > > wrote:
>>
>> On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh
>> mailto:stambau...@gmail.com>> wrote:
>> > Unless we are going to prohibit new features (new file formats,
>> new tool
>> > framework for eeschema, etc.) from being merged into the dev branch
>> > until 5.1 is released, I disagree.  If we want to only work on 5.1 in
>> > the dev branch, then I'm OK with this proposal.
>>
>> This is essentially my proposal - limit dev branch changes to 5.1
>> features, uncontroversial maintenance and bugfixes.
>>
>> If people want to work on 

Re: [Kicad-developers] Branches

[Jeff Young]

+1

> On 19 Jul 2018, at 16:57, Seth Hillbrand  wrote:
> 
> I'd be in favor of this but if we're going to focus exclusively on v5.1 GTK3 
> migration, can we push the current state, warts and all to the master?  We 
> have a bunch of bugs tagged to 5.1 but only one is GTK3-related.  I suspect 
> we have a number of things to work on here but without bug assignment, we'll 
> be stepping on each other's toes.
> 
> -S
> 
> Am Do., 19. Juli 2018 um 08:35 Uhr schrieb Wayne Stambaugh 
> mailto:stambau...@gmail.com>>:
> You are preaching to the choir.  I did most of the maintenance on the
> 4.0 branch.  Initially it was easy but it didn't take long for it to
> become a PITA.  If no one else objects, I would be more than happy to
> make that the policy.  If that is indeed what we want to do, I would
> delete the 5.1 branch.  It will push v6 development back significantly.
> 
> On 7/19/2018 11:10 AM, Jon Evans wrote:
> > FWIW, as someone who is also maintaining parallel feature branches, I
> > agree with Orson and John.  Now that we have committed to this 5.1 idea,
> > we should just make it happen in master.  I think if we keep both master
> > and 5.1 branch running in parallel, inevitably one or the other of them
> > will be less tested / more broken unless people spend a bunch of time
> > doing the work of keeping them synchronized manually.  The cost of this
> > doesn't seem to outweigh the benefit of being able to merge some 6.0
> > features into master sooner.
> > 
> > On Thu, Jul 19, 2018 at 11:03 AM John Beard  > 
> > >> wrote:
> > 
> > On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh
> > mailto:stambau...@gmail.com> 
> > >> wrote:
> > > Unless we are going to prohibit new features (new file formats,
> > new tool
> > > framework for eeschema, etc.) from being merged into the dev branch
> > > until 5.1 is released, I disagree.  If we want to only work on 5.1 in
> > > the dev branch, then I'm OK with this proposal.
> > 
> > This is essentially my proposal - limit dev branch changes to 5.1
> > features, uncontroversial maintenance and bugfixes.
> > 
> > If people want to work on features for 6 now, that can be done in
> > separate branches, and the onus for keeping it rebased onto the 5.1
> > changes is on them, rather than forcing the 5.1 workers to deal with
> > conflicts. Otherwise, whoever is working on 5.1 features like the
> > GTK3/GAL stuff and printing, will have to continually port their work
> > between the two branches.
> > 
> > If 5.1 changes are unlikely to be substantially affected by 6.0-facing
> > changes, then perhaps this limitation is not useful.
> > 
> > > There should be nothing in the 5.1 branch that is not also in the dev
> > > branch so everything in the 5.1 branch should be tested in the dev
> > > branch builds.
> > 
> > In theory, yes, but if fixes need to be manually ported as the
> > branches diverge, it's possible to fail to fix, or break in new ways,
> > one branch or the other. If a 5.1 branch exists in parallel to 6.0,
> > someone will have to take responsibility to ensure the appropriate
> > fixes are identified, ported and tested as needed. In the Linux world,
> > this is the unglamorous, arduous (and vital) job of the stable branch
> > maintainers.
> > 
> > I'm not against parallel branches if someone is willing to step up to
> > be a stable branch maintainer for 5.1. In fact, I'd be thrilled to get
> > nice new stuff dropping into the dev branch. However, changes that
> > need to be in both branches are not trivially rebasable, that job will
> > soon become decidedly not-fun.
> > 
> > Cheers,
> > 
> > John
> > 
> > ___
> > 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 : 

[Kicad-developers] 5.1 testing

[Jeff Young]

Could someone test the DRC highlighting on Linux and Windows.  (Since it uses 
the same selection highlighting code my guess is that it doesn’t work on 
Windows.)

Run a DRC on a board that has some errors.
Right click on an error in the DRC errors list.
Hover back and forth over the two entries in the context menu.  The items on 
the board should highlight.

Thanks,
Jeff.
___
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] Branches

[Seth Hillbrand]

I'd be in favor of this but if we're going to focus exclusively on v5.1
GTK3 migration, can we push the current state, warts and all to the
master?  We have a bunch of bugs tagged to 5.1 but only one is
GTK3-related.  I suspect we have a number of things to work on here but
without bug assignment, we'll be stepping on each other's toes.

-S

Am Do., 19. Juli 2018 um 08:35 Uhr schrieb Wayne Stambaugh <
stambau...@gmail.com>:

> You are preaching to the choir.  I did most of the maintenance on the
> 4.0 branch.  Initially it was easy but it didn't take long for it to
> become a PITA.  If no one else objects, I would be more than happy to
> make that the policy.  If that is indeed what we want to do, I would
> delete the 5.1 branch.  It will push v6 development back significantly.
>
> On 7/19/2018 11:10 AM, Jon Evans wrote:
> > FWIW, as someone who is also maintaining parallel feature branches, I
> > agree with Orson and John.  Now that we have committed to this 5.1 idea,
> > we should just make it happen in master.  I think if we keep both master
> > and 5.1 branch running in parallel, inevitably one or the other of them
> > will be less tested / more broken unless people spend a bunch of time
> > doing the work of keeping them synchronized manually.  The cost of this
> > doesn't seem to outweigh the benefit of being able to merge some 6.0
> > features into master sooner.
> >
> > On Thu, Jul 19, 2018 at 11:03 AM John Beard  > > wrote:
> >
> > On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh
> > mailto:stambau...@gmail.com>> wrote:
> > > Unless we are going to prohibit new features (new file formats,
> > new tool
> > > framework for eeschema, etc.) from being merged into the dev branch
> > > until 5.1 is released, I disagree.  If we want to only work on 5.1
> in
> > > the dev branch, then I'm OK with this proposal.
> >
> > This is essentially my proposal - limit dev branch changes to 5.1
> > features, uncontroversial maintenance and bugfixes.
> >
> > If people want to work on features for 6 now, that can be done in
> > separate branches, and the onus for keeping it rebased onto the 5.1
> > changes is on them, rather than forcing the 5.1 workers to deal with
> > conflicts. Otherwise, whoever is working on 5.1 features like the
> > GTK3/GAL stuff and printing, will have to continually port their work
> > between the two branches.
> >
> > If 5.1 changes are unlikely to be substantially affected by
> 6.0-facing
> > changes, then perhaps this limitation is not useful.
> >
> > > There should be nothing in the 5.1 branch that is not also in the
> dev
> > > branch so everything in the 5.1 branch should be tested in the dev
> > > branch builds.
> >
> > In theory, yes, but if fixes need to be manually ported as the
> > branches diverge, it's possible to fail to fix, or break in new ways,
> > one branch or the other. If a 5.1 branch exists in parallel to 6.0,
> > someone will have to take responsibility to ensure the appropriate
> > fixes are identified, ported and tested as needed. In the Linux
> world,
> > this is the unglamorous, arduous (and vital) job of the stable branch
> > maintainers.
> >
> > I'm not against parallel branches if someone is willing to step up to
> > be a stable branch maintainer for 5.1. In fact, I'd be thrilled to
> get
> > nice new stuff dropping into the dev branch. However, changes that
> > need to be in both branches are not trivially rebasable, that job
> will
> > soon become decidedly not-fun.
> >
> > Cheers,
> >
> > John
> >
> > ___
> > 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] Branches

[Jeff Young]

I’m fine with it either way (my stuff is currently equivalent between the two).

> On 19 Jul 2018, at 16:28, Maciej Sumiński  wrote:
> 
> It will be a huge motivation for us to fix GTK3 problems as soon as
> possible. I assume you mean to drop the current master branch (or rename
> to 6.0?) and make 5.1 the new master branch?
> 
> On 07/19/2018 05:19 PM, Wayne Stambaugh wrote:
>> You are preaching to the choir.  I did most of the maintenance on the
>> 4.0 branch.  Initially it was easy but it didn't take long for it to
>> become a PITA.  If no one else objects, I would be more than happy to
>> make that the policy.  If that is indeed what we want to do, I would
>> delete the 5.1 branch.  It will push v6 development back significantly.
>> 
>> On 7/19/2018 11:10 AM, Jon Evans wrote:
>>> FWIW, as someone who is also maintaining parallel feature branches, I
>>> agree with Orson and John.  Now that we have committed to this 5.1 idea,
>>> we should just make it happen in master.  I think if we keep both master
>>> and 5.1 branch running in parallel, inevitably one or the other of them
>>> will be less tested / more broken unless people spend a bunch of time
>>> doing the work of keeping them synchronized manually.  The cost of this
>>> doesn't seem to outweigh the benefit of being able to merge some 6.0
>>> features into master sooner.
>>> 
>>> On Thu, Jul 19, 2018 at 11:03 AM John Beard >> > wrote:
>>> 
>>>On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh
>>>mailto:stambau...@gmail.com>> wrote:
 Unless we are going to prohibit new features (new file formats,
>>>new tool
 framework for eeschema, etc.) from being merged into the dev branch
 until 5.1 is released, I disagree.  If we want to only work on 5.1 in
 the dev branch, then I'm OK with this proposal.
>>> 
>>>This is essentially my proposal - limit dev branch changes to 5.1
>>>features, uncontroversial maintenance and bugfixes.
>>> 
>>>If people want to work on features for 6 now, that can be done in
>>>separate branches, and the onus for keeping it rebased onto the 5.1
>>>changes is on them, rather than forcing the 5.1 workers to deal with
>>>conflicts. Otherwise, whoever is working on 5.1 features like the
>>>GTK3/GAL stuff and printing, will have to continually port their work
>>>between the two branches.
>>> 
>>>If 5.1 changes are unlikely to be substantially affected by 6.0-facing
>>>changes, then perhaps this limitation is not useful.
>>> 
 There should be nothing in the 5.1 branch that is not also in the dev
 branch so everything in the 5.1 branch should be tested in the dev
 branch builds.
>>> 
>>>In theory, yes, but if fixes need to be manually ported as the
>>>branches diverge, it's possible to fail to fix, or break in new ways,
>>>one branch or the other. If a 5.1 branch exists in parallel to 6.0,
>>>someone will have to take responsibility to ensure the appropriate
>>>fixes are identified, ported and tested as needed. In the Linux world,
>>>this is the unglamorous, arduous (and vital) job of the stable branch
>>>maintainers.
>>> 
>>>I'm not against parallel branches if someone is willing to step up to
>>>be a stable branch maintainer for 5.1. In fact, I'd be thrilled to get
>>>nice new stuff dropping into the dev branch. However, changes that
>>>need to be in both branches are not trivially rebasable, that job will
>>>soon become decidedly not-fun.
>>> 
>>>Cheers,
>>> 
>>>John
>>> 
>>>___
>>>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

[Tomasz Wlostowski]

On 18/07/18 13:06, Jeff Young wrote:
> Hi Tom, et al,
> 
> I assume we just need to drop wxDC for the canvas, but that UI constructs 
> (such as colour swatches, etc.) would continue to use wxDC?

To clarify: SCH/PCB preview widgets will also use GAL.

Tom

> 
> Thanks,
> Jeff.
> 
> 
>> On 17 Jul 2018, at 15:44, Tomasz Wlostowski  
>> wrote:
>>
>> On 16/07/18 17:54, Wayne Stambaugh wrote:
>>> 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.
>>>
>> Hi Wayne,
>>
>> The sooner we drop wxDC, the better for Kicad. I wouldn't do it because
>> of the GTK3/Python issues (since it's a neverending Linux problem of
>> changing APIs and libraries), but for performance reasons - on OSX for
>> instance, eeschema is sometimes barely usable because of slow drawing.
>>
>> I hope I'll be able to devote some time to cleaning up the eeschema-gal
>> code in the coming weeks. So far, the main canvas and the library editor
>> are implemented, with the symbol preview widgets & library browser
>> remaining.
>>
>>
>>> I'm assuming the printing is a v6 goal.
>>
>> Orson made quite a lot of progress with Cairo printing. IIRC it can make
>> it to the 5.1.
>>
>> Cheers,
>> Tom
>>
>>>
>>> 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
>>>
>>
>>
>> ___
>> 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] Branches

[Maciej Sumiński]

It will be a huge motivation for us to fix GTK3 problems as soon as
possible. I assume you mean to drop the current master branch (or rename
to 6.0?) and make 5.1 the new master branch?

On 07/19/2018 05:19 PM, Wayne Stambaugh wrote:
> You are preaching to the choir.  I did most of the maintenance on the
> 4.0 branch.  Initially it was easy but it didn't take long for it to
> become a PITA.  If no one else objects, I would be more than happy to
> make that the policy.  If that is indeed what we want to do, I would
> delete the 5.1 branch.  It will push v6 development back significantly.
> 
> On 7/19/2018 11:10 AM, Jon Evans wrote:
>> FWIW, as someone who is also maintaining parallel feature branches, I
>> agree with Orson and John.  Now that we have committed to this 5.1 idea,
>> we should just make it happen in master.  I think if we keep both master
>> and 5.1 branch running in parallel, inevitably one or the other of them
>> will be less tested / more broken unless people spend a bunch of time
>> doing the work of keeping them synchronized manually.  The cost of this
>> doesn't seem to outweigh the benefit of being able to merge some 6.0
>> features into master sooner.
>>
>> On Thu, Jul 19, 2018 at 11:03 AM John Beard > > wrote:
>>
>> On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh
>> mailto:stambau...@gmail.com>> wrote:
>> > Unless we are going to prohibit new features (new file formats,
>> new tool
>> > framework for eeschema, etc.) from being merged into the dev branch
>> > until 5.1 is released, I disagree.  If we want to only work on 5.1 in
>> > the dev branch, then I'm OK with this proposal.
>>
>> This is essentially my proposal - limit dev branch changes to 5.1
>> features, uncontroversial maintenance and bugfixes.
>>
>> If people want to work on features for 6 now, that can be done in
>> separate branches, and the onus for keeping it rebased onto the 5.1
>> changes is on them, rather than forcing the 5.1 workers to deal with
>> conflicts. Otherwise, whoever is working on 5.1 features like the
>> GTK3/GAL stuff and printing, will have to continually port their work
>> between the two branches.
>>
>> If 5.1 changes are unlikely to be substantially affected by 6.0-facing
>> changes, then perhaps this limitation is not useful.
>>
>> > There should be nothing in the 5.1 branch that is not also in the dev
>> > branch so everything in the 5.1 branch should be tested in the dev
>> > branch builds.
>>
>> In theory, yes, but if fixes need to be manually ported as the
>> branches diverge, it's possible to fail to fix, or break in new ways,
>> one branch or the other. If a 5.1 branch exists in parallel to 6.0,
>> someone will have to take responsibility to ensure the appropriate
>> fixes are identified, ported and tested as needed. In the Linux world,
>> this is the unglamorous, arduous (and vital) job of the stable branch
>> maintainers.
>>
>> I'm not against parallel branches if someone is willing to step up to
>> be a stable branch maintainer for 5.1. In fact, I'd be thrilled to get
>> nice new stuff dropping into the dev branch. However, changes that
>> need to be in both branches are not trivially rebasable, that job will
>> soon become decidedly not-fun.
>>
>> Cheers,
>>
>> John
>>
>> ___
>> 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

[Maciej Sumiński]

Hi Jeff,

Yes, for the moment we work to replace wxDC only in places that really
need it. So far it was necessary in pcbnew to boost performance, now
eeschema suffers the same problem with GTK3.

Cheers,
Orson

On 07/18/2018 01:06 PM, Jeff Young wrote:
> Hi Tom, et al,
> 
> I assume we just need to drop wxDC for the canvas, but that UI constructs 
> (such as colour swatches, etc.) would continue to use wxDC?
> 
> Thanks,
> Jeff.
> 
> 
>> On 17 Jul 2018, at 15:44, Tomasz Wlostowski  
>> wrote:
>>
>> On 16/07/18 17:54, Wayne Stambaugh wrote:
>>> 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.
>>>
>> Hi Wayne,
>>
>> The sooner we drop wxDC, the better for Kicad. I wouldn't do it because
>> of the GTK3/Python issues (since it's a neverending Linux problem of
>> changing APIs and libraries), but for performance reasons - on OSX for
>> instance, eeschema is sometimes barely usable because of slow drawing.
>>
>> I hope I'll be able to devote some time to cleaning up the eeschema-gal
>> code in the coming weeks. So far, the main canvas and the library editor
>> are implemented, with the symbol preview widgets & library browser
>> remaining.
>>
>>
>>> I'm assuming the printing is a v6 goal.
>>
>> Orson made quite a lot of progress with Cairo printing. IIRC it can make
>> it to the 5.1.
>>
>> Cheers,
>> Tom
>>
>>>
>>> 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
>>>
>>
>>
>> ___
>> 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] Branches

[Wayne Stambaugh]

You are preaching to the choir.  I did most of the maintenance on the
4.0 branch.  Initially it was easy but it didn't take long for it to
become a PITA.  If no one else objects, I would be more than happy to
make that the policy.  If that is indeed what we want to do, I would
delete the 5.1 branch.  It will push v6 development back significantly.

On 7/19/2018 11:10 AM, Jon Evans wrote:
> FWIW, as someone who is also maintaining parallel feature branches, I
> agree with Orson and John.  Now that we have committed to this 5.1 idea,
> we should just make it happen in master.  I think if we keep both master
> and 5.1 branch running in parallel, inevitably one or the other of them
> will be less tested / more broken unless people spend a bunch of time
> doing the work of keeping them synchronized manually.  The cost of this
> doesn't seem to outweigh the benefit of being able to merge some 6.0
> features into master sooner.
> 
> On Thu, Jul 19, 2018 at 11:03 AM John Beard  > wrote:
> 
> On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh
> mailto:stambau...@gmail.com>> wrote:
> > Unless we are going to prohibit new features (new file formats,
> new tool
> > framework for eeschema, etc.) from being merged into the dev branch
> > until 5.1 is released, I disagree.  If we want to only work on 5.1 in
> > the dev branch, then I'm OK with this proposal.
> 
> This is essentially my proposal - limit dev branch changes to 5.1
> features, uncontroversial maintenance and bugfixes.
> 
> If people want to work on features for 6 now, that can be done in
> separate branches, and the onus for keeping it rebased onto the 5.1
> changes is on them, rather than forcing the 5.1 workers to deal with
> conflicts. Otherwise, whoever is working on 5.1 features like the
> GTK3/GAL stuff and printing, will have to continually port their work
> between the two branches.
> 
> If 5.1 changes are unlikely to be substantially affected by 6.0-facing
> changes, then perhaps this limitation is not useful.
> 
> > There should be nothing in the 5.1 branch that is not also in the dev
> > branch so everything in the 5.1 branch should be tested in the dev
> > branch builds.
> 
> In theory, yes, but if fixes need to be manually ported as the
> branches diverge, it's possible to fail to fix, or break in new ways,
> one branch or the other. If a 5.1 branch exists in parallel to 6.0,
> someone will have to take responsibility to ensure the appropriate
> fixes are identified, ported and tested as needed. In the Linux world,
> this is the unglamorous, arduous (and vital) job of the stable branch
> maintainers.
> 
> I'm not against parallel branches if someone is willing to step up to
> be a stable branch maintainer for 5.1. In fact, I'd be thrilled to get
> nice new stuff dropping into the dev branch. However, changes that
> need to be in both branches are not trivially rebasable, that job will
> soon become decidedly not-fun.
> 
> Cheers,
> 
> John
> 
> ___
> 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] Branches

[Jon Evans]

FWIW, as someone who is also maintaining parallel feature branches, I agree
with Orson and John.  Now that we have committed to this 5.1 idea, we
should just make it happen in master.  I think if we keep both master and
5.1 branch running in parallel, inevitably one or the other of them will be
less tested / more broken unless people spend a bunch of time doing the
work of keeping them synchronized manually.  The cost of this doesn't seem
to outweigh the benefit of being able to merge some 6.0 features into
master sooner.

On Thu, Jul 19, 2018 at 11:03 AM John Beard  wrote:

> On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh 
> wrote:
> > Unless we are going to prohibit new features (new file formats, new tool
> > framework for eeschema, etc.) from being merged into the dev branch
> > until 5.1 is released, I disagree.  If we want to only work on 5.1 in
> > the dev branch, then I'm OK with this proposal.
>
> This is essentially my proposal - limit dev branch changes to 5.1
> features, uncontroversial maintenance and bugfixes.
>
> If people want to work on features for 6 now, that can be done in
> separate branches, and the onus for keeping it rebased onto the 5.1
> changes is on them, rather than forcing the 5.1 workers to deal with
> conflicts. Otherwise, whoever is working on 5.1 features like the
> GTK3/GAL stuff and printing, will have to continually port their work
> between the two branches.
>
> If 5.1 changes are unlikely to be substantially affected by 6.0-facing
> changes, then perhaps this limitation is not useful.
>
> > There should be nothing in the 5.1 branch that is not also in the dev
> > branch so everything in the 5.1 branch should be tested in the dev
> > branch builds.
>
> In theory, yes, but if fixes need to be manually ported as the
> branches diverge, it's possible to fail to fix, or break in new ways,
> one branch or the other. If a 5.1 branch exists in parallel to 6.0,
> someone will have to take responsibility to ensure the appropriate
> fixes are identified, ported and tested as needed. In the Linux world,
> this is the unglamorous, arduous (and vital) job of the stable branch
> maintainers.
>
> I'm not against parallel branches if someone is willing to step up to
> be a stable branch maintainer for 5.1. In fact, I'd be thrilled to get
> nice new stuff dropping into the dev branch. However, changes that
> need to be in both branches are not trivially rebasable, that job will
> soon become decidedly not-fun.
>
> Cheers,
>
> John
>
> ___
> 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 logo author

[Wayne Stambaugh]

Hey Fabrizio,

I thought you were the author I just wasn't sure.

Thanks,

Wayne

On 7/18/2018 6:15 PM, Fabrizio Tappero wrote:
> Hi Wayne,
> How are you? I'm the author of the kicad logo and everything is of
> course fine with me. 
> 
> Cheers
> Fabrizio
> 
> 
> On Jul 18, 2018 7:36 PM, "Wayne Stambaugh"  > wrote:
> 
> I've been getting a few requests recently about using the KiCad logo[1]
> for merchandising and other uses that benefit the project.  I just want
> to be sure the author of the logo (please refresh my memory who this is)
> is OK with the project using the logo in this manner.  Thanks in advance
> for the update.
> 
> Cheers,
> 
> Wayne
> 
> [1]:
> 
> https://github.com/KiCad/kicad-website/blob/master/static/img/kicad_logo_paths.svg
> 
> 
> 
> ___
> 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] Branches

[John Beard]

On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh  wrote:
> Unless we are going to prohibit new features (new file formats, new tool
> framework for eeschema, etc.) from being merged into the dev branch
> until 5.1 is released, I disagree.  If we want to only work on 5.1 in
> the dev branch, then I'm OK with this proposal.

This is essentially my proposal - limit dev branch changes to 5.1
features, uncontroversial maintenance and bugfixes.

If people want to work on features for 6 now, that can be done in
separate branches, and the onus for keeping it rebased onto the 5.1
changes is on them, rather than forcing the 5.1 workers to deal with
conflicts. Otherwise, whoever is working on 5.1 features like the
GTK3/GAL stuff and printing, will have to continually port their work
between the two branches.

If 5.1 changes are unlikely to be substantially affected by 6.0-facing
changes, then perhaps this limitation is not useful.

> There should be nothing in the 5.1 branch that is not also in the dev
> branch so everything in the 5.1 branch should be tested in the dev
> branch builds.

In theory, yes, but if fixes need to be manually ported as the
branches diverge, it's possible to fail to fix, or break in new ways,
one branch or the other. If a 5.1 branch exists in parallel to 6.0,
someone will have to take responsibility to ensure the appropriate
fixes are identified, ported and tested as needed. In the Linux world,
this is the unglamorous, arduous (and vital) job of the stable branch
maintainers.

I'm not against parallel branches if someone is willing to step up to
be a stable branch maintainer for 5.1. In fact, I'd be thrilled to get
nice new stuff dropping into the dev branch. However, changes that
need to be in both branches are not trivially rebasable, that job will
soon become decidedly not-fun.

Cheers,

John

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

[Wayne Stambaugh]

Unless we are going to prohibit new features (new file formats, new tool
framework for eeschema, etc.) from being merged into the dev branch
until 5.1 is released, I disagree.  If we want to only work on 5.1 in
the dev branch, then I'm OK with this proposal.

On 7/19/2018 8:39 AM, John Beard wrote:
> I agree with Orson. It's unfortunate for people to not be able to dump
> new features onto master after such a long freeze. However, if 5.1 and
> master/6-dev diverge, there will be a lot of pain in porting bugs,
> especially if one branch has work that very is invasive and touches a
> lot of code, and one does not.
> 
> Moreover, testing efforts will be split, with some people only on
> 5.1-dev and some only using master. This can easily allow bugs to slip
> by into one branch or the other.

There should be nothing in the 5.1 branch that is not also in the dev
branch so everything in the 5.1 branch should be tested in the dev
branch builds.

> 
> I think there should only be master, which is the 5.1-dev branch. When
> that splits to become a release, 6.0-dev can start.
> 
> Big features that don't suit 5.1 will just have to wait for the start
> of 6, being maintained in separate branches if necessary, either under
> the KiCad aegis in the main repo, or less formally in any other Git
> repo. A list of ongoing known dev branches somewhere would be helpful
> (eeschema GAL and Cairo printing being two I can think would be useful
> to document).
> 
> Of course, people with new features can always petition the project
> lead for permission to put stuff into 5.1! Otherwise, focussing on 5.1
> issues now will get both 5.1 done and out of the way sooner (important
> to fix Python), and also get us to the state where 6.0-dev can receive
> the full attention from devs, lead and interested users.
> 
> Cheers,
> 
> John
> 
> 
> On Thu, Jul 19, 2018 at 10:25 AM, Maciej Sumiński
>  wrote:
>> I wonder if there is a point in keeping 5.1 and master branches
>> separated. In 5.1 there is a lot of new code that will need patches, and
>> they need to be applied to both branches now. If we keep adding more
>> features to the master branch, then at one point the branch may diverge
>> significantly enough to make patch porting non trivial.
>>
>> What do you think about replacing the current master branch with 5.1?
>> This way we can focus on the wxGTK3 problem, fix issues that we discover
>> and once 5.1 is out - keep adding new features to 6.0-dev? For the time
>> being new features might be developed in private branches.
>>
>> BTW. I really like 5.1 UI improvements, good job Jeff!
>>
>> Cheers,
>> Orson
>>
>>
>> ___
>> 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] Branches

[John Beard]

I agree with Orson. It's unfortunate for people to not be able to dump
new features onto master after such a long freeze. However, if 5.1 and
master/6-dev diverge, there will be a lot of pain in porting bugs,
especially if one branch has work that very is invasive and touches a
lot of code, and one does not.

Moreover, testing efforts will be split, with some people only on
5.1-dev and some only using master. This can easily allow bugs to slip
by into one branch or the other.

I think there should only be master, which is the 5.1-dev branch. When
that splits to become a release, 6.0-dev can start.

Big features that don't suit 5.1 will just have to wait for the start
of 6, being maintained in separate branches if necessary, either under
the KiCad aegis in the main repo, or less formally in any other Git
repo. A list of ongoing known dev branches somewhere would be helpful
(eeschema GAL and Cairo printing being two I can think would be useful
to document).

Of course, people with new features can always petition the project
lead for permission to put stuff into 5.1! Otherwise, focussing on 5.1
issues now will get both 5.1 done and out of the way sooner (important
to fix Python), and also get us to the state where 6.0-dev can receive
the full attention from devs, lead and interested users.

Cheers,

John


On Thu, Jul 19, 2018 at 10:25 AM, Maciej Sumiński
 wrote:
> I wonder if there is a point in keeping 5.1 and master branches
> separated. In 5.1 there is a lot of new code that will need patches, and
> they need to be applied to both branches now. If we keep adding more
> features to the master branch, then at one point the branch may diverge
> significantly enough to make patch porting non trivial.
>
> What do you think about replacing the current master branch with 5.1?
> This way we can focus on the wxGTK3 problem, fix issues that we discover
> and once 5.1 is out - keep adding new features to 6.0-dev? For the time
> being new features might be developed in private branches.
>
> BTW. I really like 5.1 UI improvements, good job Jeff!
>
> Cheers,
> Orson
>
>
> ___
> 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

[Wayne Stambaugh]

Keep in mind that as long as there is a shared user configuration
between versions, there is the potential for issues due to the storage
of environment variables in the user config.  The only way to ensure
there will be no version issues is to ensure each new version has a
separate user config.  Installing versions in separate paths will not be
enough.

On 7/19/2018 12:35 AM, Adam Wolf wrote:
> It's definitely technically possible for macOS--but as I'm continuing
> to think about it, even if I whipped this patch up and tested it,
> *and* I convinced enough people it worked, just thinking about all the
> places in the docs where the macOS paths would have to change, I'm
> thinking we *have* to wait.
> 
> Please let's get this in before V6...
> 
> Adam
> On Wed, Jul 18, 2018 at 11:25 PM Seth Hillbrand  wrote:
>>
>> It's a good idea but it's coming after we've already tagged v5.  Are we 
>> thinking of a patch on the packaging?  I don't quite follow the proposal for 
>> how this gets implemented.  For debian, we could place a patch in the build 
>> package.  I assume that there is something similar for rpms but I'd be 
>> curious to know how this would be implemented for Mac/Windows.
>>
>> -Seth
>>
>> Am Mi., 18. Juli 2018 um 21:08 Uhr schrieb Adam Wolf 
>> :
>>>
>>> On Mac, we have the advantage of users not setting environment variables.  
>>> This makes me think this *could* potentially be feasible for 5.0, for MacOS.
>>>
>>> However, I do not know if we would want this feature on one platform and 
>>> not the others. Thoughts?
>>>
>>> On Mon, Jul 16, 2018, 12:40 PM Andy Peters  wrote:

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

[Adam Wolf]

Alright.  Thanks Bernhard.  I still suspect that it's very rare compared to
users with custom environment variables on Windows and Linux.

This is yet another reason that this can't get done by Friday.

Adam

On Thu, Jul 19, 2018, 1:06 AM Bernhard Stegmaier 
wrote:

> I wouldn’t rely on that.
> You can set paths on macOS and at least I needed it to do in my setup
> before Wayne made the path configuration dialog.
> So, I wouldn’t bet that there are no such macOS installs out there… :)
>
>
> Regards,
> Bernhard
>
> On 19. Jul 2018, at 06:07, Adam Wolf 
> wrote:
>
> On Mac, we have the advantage of users not setting environment variables.
> This makes me think this *could* potentially be feasible for 5.0, for MacOS.
>
> However, I do not know if we would want this feature on one platform and
> not the others. Thoughts?
>
> On Mon, Jul 16, 2018, 12:40 PM Andy Peters  wrote:
>
>> 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
>
>
>
___
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] Branches

[Maciej Sumiński]

I wonder if there is a point in keeping 5.1 and master branches
separated. In 5.1 there is a lot of new code that will need patches, and
they need to be applied to both branches now. If we keep adding more
features to the master branch, then at one point the branch may diverge
significantly enough to make patch porting non trivial.

What do you think about replacing the current master branch with 5.1?
This way we can focus on the wxGTK3 problem, fix issues that we discover
and once 5.1 is out - keep adding new features to 6.0-dev? For the time
being new features might be developed in private branches.

BTW. I really like 5.1 UI improvements, good job Jeff!

Cheers,
Orson



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] Signed Installers

[Nick Østergaard]

If you need it for something, then I made this build of the 5.0 branch
with only kicad and libs.

http://downloads.kicad-pcb.org/windows/testing/patched/kicad-patched-58-5.0.1-dev-4-g3dcf04fdb-x86_64.exe

It should be suitable to install on top of a rc3 or nightly. Please do
install and test it if possible.

Nick
Den tor. 19. jul. 2018 kl. 10.49 skrev Nick Østergaard :
>
> As the installer package everything we can not make a proper 5.0.0
> stable before it has been tagged.
> Den tor. 19. jul. 2018 kl. 10.21 skrev Maciej Sumiński
> :
> >
> > Hi Simon,
> >
> > The installer works well, no warnings observed here. Do you think you
> > could create one for 5.0.0 stable and upload it to windows/stable directory?
> >
> > Cheers,
> > Orson
> >
> > On 07/19/2018 01:17 AM, Simon Richter wrote:
> > > Hi,
> > >
> > > I've just rebuilt the latest MSYS2 nightly and the rc3 package in
> > > /windows/testing with signing enabled, so these should now install with
> > > fewer complaints.
> > >
> > >Simon
> > >
> > >
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@lists.launchpad.net
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help   : https://help.launchpad.net/ListHelp
> > >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Signed Installers

[Nick Østergaard]

As the installer package everything we can not make a proper 5.0.0
stable before it has been tagged.
Den tor. 19. jul. 2018 kl. 10.21 skrev Maciej Sumiński
:
>
> Hi Simon,
>
> The installer works well, no warnings observed here. Do you think you
> could create one for 5.0.0 stable and upload it to windows/stable directory?
>
> Cheers,
> Orson
>
> On 07/19/2018 01:17 AM, Simon Richter wrote:
> > Hi,
> >
> > I've just rebuilt the latest MSYS2 nightly and the rc3 package in
> > /windows/testing with signing enabled, so these should now install with
> > fewer complaints.
> >
> >Simon
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Stable 5 release.

[Nick Østergaard]

This sounds good. Thank you.
Den tor. 19. jul. 2018 kl. 10.43 skrev Rene Pöschl :
>
> On 18/07/18 19:59, Carsten Schoenert wrote:
> > Am 18.07.18 um 19:55 schrieb Rene Pöschl:
> >>> I'm traveling the whole Saturday and Sunday to Debian DebCamp and
> >>> DebConf in Taiwan and working on packaging kicad-packages3d on a laptop
> >>> is PITA. So I'd like to this at home on a more powerful machine at home
> >>> latest on Friday afternoon.
> >>>
> >>> Thanks!
> >>>
> >> By the way when giving deadlines stating your timezone might be
> >> required. As you did not state one i choose to use CET summer time ;)
> > Argh, yes, a damn phone call has interrupted me while writing ...
> > But yes, CEST is the timezone I currently live. :-)
> >
> >> But if everything goes to plan i will tag the libs in a few hours anyway
> >> giving you guys ample time.
> > Thanks!
> >
>
> Sadly i worked too long yesterday so i have been too tired to fully
> check the libs.
>
> I also have one or two PRs open that i want to check if they are correct
> as they would fix some more minor issues. (Not a holdup but if they are
> ready i would like to include them.)
>
>
> So i will create the tags today in the evening. (Thursday 23:59 CEST
> plus or minus two hours) Sorry about the delay.
>
>
> ___
> 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] Stable 5 release.

[Rene Pöschl]

On 18/07/18 19:59, Carsten Schoenert wrote:

Am 18.07.18 um 19:55 schrieb Rene Pöschl:

I'm traveling the whole Saturday and Sunday to Debian DebCamp and
DebConf in Taiwan and working on packaging kicad-packages3d on a laptop
is PITA. So I'd like to this at home on a more powerful machine at home
latest on Friday afternoon.

Thanks!


By the way when giving deadlines stating your timezone might be
required. As you did not state one i choose to use CET summer time ;)

Argh, yes, a damn phone call has interrupted me while writing ...
But yes, CEST is the timezone I currently live. :-)


But if everything goes to plan i will tag the libs in a few hours anyway
giving you guys ample time.

Thanks!



Sadly i worked too long yesterday so i have been too tired to fully 
check the libs.


I also have one or two PRs open that i want to check if they are correct 
as they would fix some more minor issues. (Not a holdup but if they are 
ready i would like to include them.)



So i will create the tags today in the evening. (Thursday 23:59 CEST 
plus or minus two hours) Sorry about the delay.



___
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] Signed Installers

[Maciej Sumiński]

Hi Simon,

The installer works well, no warnings observed here. Do you think you
could create one for 5.0.0 stable and upload it to windows/stable directory?

Cheers,
Orson

On 07/19/2018 01:17 AM, Simon Richter wrote:
> Hi,
> 
> I've just rebuilt the latest MSYS2 nightly and the rc3 package in
> /windows/testing with signing enabled, so these should now install with
> fewer complaints.
> 
>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
> 




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] Tesselation Ideas

[Tomasz Wlostowski]

On 19/07/18 06:15, Seth Hillbrand wrote:
> ​Hi All-
> 
> Our current triangulation caching is based on the poly2tri codebase and
> has a number of constraints.  Most notably, it does not allow touching
> holes, holes on the boundary or duplicate vertices.  In these cases, we
> do not cache the triangulation and instead use the OpenGL single-thread
> triangulation routine each time we draw a complicated polygon.  This has
> the side-effect of making some boards much slower in Accelerated mode
> than in Fallback.​
> 
> I've been noodling with an idea for how to better cache our
> triangulation and I think it's ready for some wider testing.  It
> combines the Sloan ear-cutting algorithm with a plane division and
> simplication approach to address difficult polygons.  It generally
> follows the approach of Lamot and Zalik
> (https://www.sciencedirect.com/science/article/pii/S0097849302002819)
> but implements some of the shortcuts from the mapbox earcut library
> (https://github.com/mapbox/earcut)
> 
> The code is located in my GitHub
> (https://github.com/sethhillbrand/kicad-source-mirror/tree/tesselation).  If
> you clone the tree, be sure to check out the branch "tesselation".
> 
> Comments/feedback greatly appreciated.

Wow, just tried the code, it's quite fast :) Good job. I've been trying
to use TTL/HalfEdge or poly2tri for such triangulations but without much
success.

Tom

PS. Does your algorithm support arbitrary Steiner points (i.e. adding a
regular grid inside the polygon area to obtain more regularly shaped
triangles which can be efficiently indexed using an R-Tree)?


___
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

[Bernhard Stegmaier]

I wouldn’t rely on that.
You can set paths on macOS and at least I needed it to do in my setup before 
Wayne made the path configuration dialog.
So, I wouldn’t bet that there are no such macOS installs out there… :)


Regards,
Bernhard

> On 19. Jul 2018, at 06:07, Adam Wolf  wrote:
> 
> On Mac, we have the advantage of users not setting environment variables.  
> This makes me think this *could* potentially be feasible for 5.0, for MacOS.
> 
> However, I do not know if we would want this feature on one platform and not 
> the others. Thoughts?
> 
> On Mon, Jul 16, 2018, 12:40 PM Andy Peters  > wrote:
> 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

___
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