Re: [Kicad-developers] idea for post-release file manipulations

2015-07-08 Thread jp charras
Le 07/07/2015 21:41, Garth Corral a écrit :
> 
>> On Jul 7, 2015, at 12:39 PM, jp charras 
>> wrote:
>> 
>> Le 07/07/2015 21:26, Garth Corral a écrit :
>>> 
 On Jul 7, 2015, at 12:10 PM, Garth Corral 
 wrote:
 
 
> On Jul 7, 2015, at 10:53 AM, jp charras
>  wrote:
> 
> Le 05/07/2015 23:39, Garth Corral a écrit :
>> 
>>> On Jun 22, 2015, at 10:54 AM, Andy Peters
>>>  wrote:
>>> 
>>> 
 On Jun 22, 2015, at 5:00 AM, Johannes Maibaum
  wrote:
 
 Hey OSX devs,
 
 And I just came across another minor UI glitch in
 pcbnew: When running the DRC, the dialog window loses
 focus to the main window after the checks are finished.
 Since the main window is usually bigger than the DRC
 dialog window this results in the dialog suddenly
 vanishing from the screen. An unexperienced user might
 think that the checks failed and might try to click the
 DRC button again. But since the dialog is still lurking
 behind the main window, nothing happens.
 
 I think that there are two issues here, that both
 should be easy to fix:
 
 - DRC dialog window should keep focus after checks are
 finished. - If the dialog has somehow lost focus
 (perhaps the user deliberately gave focus back to the 
 main window, leaving the dialog open), the next click
 on the DRC button/icon should bring the dialog back to
 focus.
 
 However, with the DRC issue I am not sure, if this is
 OSX only and I have no Linux machine near me now to
 verify.
>>> 
>>> I have noticed this, too, and it’s been a long-standing
>>> annoyance. Is this an OS X-only issue or does it affect
>>> all platforms.
>>> 
>> Here’s my craptastic workaround for these issues.  I’ve
>> ifdef’d some of this but it’s probably harmless on other
>> platforms.
>> 
>> It should come as a s surprise to no one that these are the
>> result of OS X wxWidgets issues.  The wxWidgets bug tracker
>> is littered with variants of these, some of which were
>> ostensibly fixed, while others have languished for years.
>> I have a minimal repro for both so I’ll file bugs there.  I
>> wouldn’t expect to see a fix on the 3.0 branch any time
>> soon.  I have a wxWidgets patch that is slightly less lame,
>> but it still just works around the real issue so it’s
>> probably not worth maintaining a yet another wxWidgets
>> patch for that.
>> 
>> 
>> Garth
>> 
> 
> Garth,
> 
> Can you test the rev 5892, and mainly the DRC dialog. It does
> not include exactly your patch, because I found and fixed an 
> issue in DRC dialog on other platforms during tests. These
> changes perhaps have fixed the OSX issues.
> 
 The part of my patch that you applied to dialog_shim.cpp fixes
 the second issue, but the rest is still the same as before.
 
 Garth


Committed. Thanks.

-- 
Jean-Pierre CHARRAS

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


Re: [Kicad-developers] idea for post-release file manipulations

2015-07-07 Thread Garth Corral

> On Jul 7, 2015, at 12:58 PM, Garth Corral  wrote:
> 
>> 
>> On Jul 7, 2015, at 12:41 PM, Garth Corral > > wrote:
>> 
>>> 
>>> On Jul 7, 2015, at 12:39 PM, jp charras >> > wrote:
>>> 
>>> Le 07/07/2015 21:26, Garth Corral a écrit :
 
> On Jul 7, 2015, at 12:10 PM, Garth Corral  > wrote:
> 
> 
>> On Jul 7, 2015, at 10:53 AM, jp charras > > wrote:
>> 
>> Le 05/07/2015 23:39, Garth Corral a écrit :
>>> 
 On Jun 22, 2015, at 10:54 AM, Andy Peters >>> > wrote:
 
 
> On Jun 22, 2015, at 5:00 AM, Johannes Maibaum  > wrote:
> 
> Hey OSX devs,
> 
> And I just came across another minor UI glitch in pcbnew: When 
> running the DRC, the dialog
> window loses focus to the main window after the checks are finished. 
> Since the main window is
> usually bigger than the DRC dialog window this results in the dialog 
> suddenly vanishing from
> the screen. An unexperienced user might think that the checks failed 
> and might try to click
> the DRC button again. But since the dialog is still lurking behind 
> the main window, nothing
> happens.
> 
> I think that there are two issues here, that both should be easy to 
> fix:
> 
> - DRC dialog window should keep focus after checks are finished.
> - If the dialog has somehow lost focus (perhaps the user deliberately 
> gave focus back to the
> main window, leaving the dialog open), the next click on the DRC 
> button/icon should bring the
> dialog back to focus.
> 
> However, with the DRC issue I am not sure, if this is OSX only and I 
> have no Linux machine
> near me now to verify.
 
 I have noticed this, too, and it’s been a long-standing annoyance. Is 
 this an OS X-only issue or does it affect all platforms.
 
>>> Here’s my craptastic workaround for these issues.  I’ve ifdef’d some of 
>>> this but it’s probably harmless on other platforms.
>>> 
>>> It should come as a s surprise to no one that these are the result of 
>>> OS X wxWidgets issues.  The wxWidgets bug tracker is littered with 
>>> variants of these, some of which were ostensibly fixed, while others 
>>> have languished for years.  I have a minimal repro for both so I’ll 
>>> file bugs there.  I wouldn’t expect to see a fix on the 3.0 branch any 
>>> time soon.  I have a wxWidgets patch that is slightly less lame, but it 
>>> still just works around the real issue so it’s probably not worth 
>>> maintaining a yet another wxWidgets patch for that.
>>> 
>>> 
>>> Garth
>>> 
>> 
>> Garth,
>> 
>> Can you test the rev 5892, and mainly the DRC dialog.
>> It does not include exactly your patch, because I found and fixed an
>> issue in DRC dialog on other platforms during tests.
>> These changes perhaps have fixed the OSX issues.
>> 
> The part of my patch that you applied to dialog_shim.cpp fixes the second 
> issue, but the rest is still the same as before.
> 
> Garth
> 
> 
 Here’s the patch again against head.
 
>>> 
>>> Where is the patch ?
>> 
>> Sorry, let’s try that again.
>> 
>> 
> 
> Might want to hold off on that for a bit.  I’ve just notice a change in 
> behavior of the patch applied previously to the patch applied against the 
> latest.  I can no longer close the pcbnew window without quitting kicad 
> entirely.  This is definitely a change from before.  Not sure what introduced 
> this as the patch is basically unchanged.
> 
Okay, all clear.  Not sure why but a clean build resolved the issue for me.

Garth

smime.p7s
Description: S/MIME cryptographic 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] idea for post-release file manipulations

2015-07-07 Thread Garth Corral

> On Jul 7, 2015, at 12:41 PM, Garth Corral  wrote:
> 
>> 
>> On Jul 7, 2015, at 12:39 PM, jp charras  wrote:
>> 
>> Le 07/07/2015 21:26, Garth Corral a écrit :
>>> 
 On Jul 7, 2015, at 12:10 PM, Garth Corral  wrote:
 
 
> On Jul 7, 2015, at 10:53 AM, jp charras  wrote:
> 
> Le 05/07/2015 23:39, Garth Corral a écrit :
>> 
>>> On Jun 22, 2015, at 10:54 AM, Andy Peters  wrote:
>>> 
>>> 
 On Jun 22, 2015, at 5:00 AM, Johannes Maibaum  
 wrote:
 
 Hey OSX devs,
 
 And I just came across another minor UI glitch in pcbnew: When running 
 the DRC, the dialog
 window loses focus to the main window after the checks are finished. 
 Since the main window is
 usually bigger than the DRC dialog window this results in the dialog 
 suddenly vanishing from
 the screen. An unexperienced user might think that the checks failed 
 and might try to click
 the DRC button again. But since the dialog is still lurking behind the 
 main window, nothing
 happens.
 
 I think that there are two issues here, that both should be easy to 
 fix:
 
 - DRC dialog window should keep focus after checks are finished.
 - If the dialog has somehow lost focus (perhaps the user deliberately 
 gave focus back to the
 main window, leaving the dialog open), the next click on the DRC 
 button/icon should bring the
 dialog back to focus.
 
 However, with the DRC issue I am not sure, if this is OSX only and I 
 have no Linux machine
 near me now to verify.
>>> 
>>> I have noticed this, too, and it’s been a long-standing annoyance. Is 
>>> this an OS X-only issue or does it affect all platforms.
>>> 
>> Here’s my craptastic workaround for these issues.  I’ve ifdef’d some of 
>> this but it’s probably harmless on other platforms.
>> 
>> It should come as a s surprise to no one that these are the result of OS 
>> X wxWidgets issues.  The wxWidgets bug tracker is littered with variants 
>> of these, some of which were ostensibly fixed, while others have 
>> languished for years.  I have a minimal repro for both so I’ll file bugs 
>> there.  I wouldn’t expect to see a fix on the 3.0 branch any time soon.  
>> I have a wxWidgets patch that is slightly less lame, but it still just 
>> works around the real issue so it’s probably not worth maintaining a yet 
>> another wxWidgets patch for that.
>> 
>> 
>> Garth
>> 
> 
> Garth,
> 
> Can you test the rev 5892, and mainly the DRC dialog.
> It does not include exactly your patch, because I found and fixed an
> issue in DRC dialog on other platforms during tests.
> These changes perhaps have fixed the OSX issues.
> 
 The part of my patch that you applied to dialog_shim.cpp fixes the second 
 issue, but the rest is still the same as before.
 
 Garth
 
 
>>> Here’s the patch again against head.
>>> 
>> 
>> Where is the patch ?
> 
> Sorry, let’s try that again.
> 
> 

Might want to hold off on that for a bit.  I’ve just notice a change in 
behavior of the patch applied previously to the patch applied against the 
latest.  I can no longer close the pcbnew window without quitting kicad 
entirely.  This is definitely a change from before.  Not sure what introduced 
this as the patch is basically unchanged.

Garth



smime.p7s
Description: S/MIME cryptographic 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] idea for post-release file manipulations

2015-07-07 Thread Garth Corral

> On Jul 7, 2015, at 12:39 PM, jp charras  wrote:
> 
> Le 07/07/2015 21:26, Garth Corral a écrit :
>> 
>>> On Jul 7, 2015, at 12:10 PM, Garth Corral  wrote:
>>> 
>>> 
 On Jul 7, 2015, at 10:53 AM, jp charras  wrote:
 
 Le 05/07/2015 23:39, Garth Corral a écrit :
> 
>> On Jun 22, 2015, at 10:54 AM, Andy Peters  wrote:
>> 
>> 
>>> On Jun 22, 2015, at 5:00 AM, Johannes Maibaum  
>>> wrote:
>>> 
>>> Hey OSX devs,
>>> 
>>> And I just came across another minor UI glitch in pcbnew: When running 
>>> the DRC, the dialog
>>> window loses focus to the main window after the checks are finished. 
>>> Since the main window is
>>> usually bigger than the DRC dialog window this results in the dialog 
>>> suddenly vanishing from
>>> the screen. An unexperienced user might think that the checks failed 
>>> and might try to click
>>> the DRC button again. But since the dialog is still lurking behind the 
>>> main window, nothing
>>> happens.
>>> 
>>> I think that there are two issues here, that both should be easy to fix:
>>> 
>>> - DRC dialog window should keep focus after checks are finished.
>>> - If the dialog has somehow lost focus (perhaps the user deliberately 
>>> gave focus back to the
>>> main window, leaving the dialog open), the next click on the DRC 
>>> button/icon should bring the
>>> dialog back to focus.
>>> 
>>> However, with the DRC issue I am not sure, if this is OSX only and I 
>>> have no Linux machine
>>> near me now to verify.
>> 
>> I have noticed this, too, and it’s been a long-standing annoyance. Is 
>> this an OS X-only issue or does it affect all platforms.
>> 
> Here’s my craptastic workaround for these issues.  I’ve ifdef’d some of 
> this but it’s probably harmless on other platforms.
> 
> It should come as a s surprise to no one that these are the result of OS 
> X wxWidgets issues.  The wxWidgets bug tracker is littered with variants 
> of these, some of which were ostensibly fixed, while others have 
> languished for years.  I have a minimal repro for both so I’ll file bugs 
> there.  I wouldn’t expect to see a fix on the 3.0 branch any time soon.  
> I have a wxWidgets patch that is slightly less lame, but it still just 
> works around the real issue so it’s probably not worth maintaining a yet 
> another wxWidgets patch for that.
> 
> 
> Garth
> 
 
 Garth,
 
 Can you test the rev 5892, and mainly the DRC dialog.
 It does not include exactly your patch, because I found and fixed an
 issue in DRC dialog on other platforms during tests.
 These changes perhaps have fixed the OSX issues.
 
>>> The part of my patch that you applied to dialog_shim.cpp fixes the second 
>>> issue, but the rest is still the same as before.
>>> 
>>> Garth
>>> 
>>> 
>> Here’s the patch again against head.
>> 
> 
> Where is the patch ?

Sorry, let’s try that again.



osx_dialog_z-order.patch
Description: Binary data


smime.p7s
Description: S/MIME cryptographic 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] idea for post-release file manipulations

2015-07-07 Thread Garth Corral

> On Jul 7, 2015, at 12:10 PM, Garth Corral  wrote:
> 
> 
>> On Jul 7, 2015, at 10:53 AM, jp charras  wrote:
>> 
>> Le 05/07/2015 23:39, Garth Corral a écrit :
>>> 
 On Jun 22, 2015, at 10:54 AM, Andy Peters  wrote:
 
 
> On Jun 22, 2015, at 5:00 AM, Johannes Maibaum  wrote:
> 
> Hey OSX devs,
> 
> And I just came across another minor UI glitch in pcbnew: When running 
> the DRC, the dialog
> window loses focus to the main window after the checks are finished. 
> Since the main window is
> usually bigger than the DRC dialog window this results in the dialog 
> suddenly vanishing from
> the screen. An unexperienced user might think that the checks failed and 
> might try to click
> the DRC button again. But since the dialog is still lurking behind the 
> main window, nothing
> happens.
> 
> I think that there are two issues here, that both should be easy to fix:
> 
> - DRC dialog window should keep focus after checks are finished.
> - If the dialog has somehow lost focus (perhaps the user deliberately 
> gave focus back to the
> main window, leaving the dialog open), the next click on the DRC 
> button/icon should bring the
> dialog back to focus.
> 
> However, with the DRC issue I am not sure, if this is OSX only and I have 
> no Linux machine
> near me now to verify.
 
 I have noticed this, too, and it’s been a long-standing annoyance. Is this 
 an OS X-only issue or does it affect all platforms.
 
>>> Here’s my craptastic workaround for these issues.  I’ve ifdef’d some of 
>>> this but it’s probably harmless on other platforms.
>>> 
>>> It should come as a s surprise to no one that these are the result of OS X 
>>> wxWidgets issues.  The wxWidgets bug tracker is littered with variants of 
>>> these, some of which were ostensibly fixed, while others have languished 
>>> for years.  I have a minimal repro for both so I’ll file bugs there.  I 
>>> wouldn’t expect to see a fix on the 3.0 branch any time soon.  I have a 
>>> wxWidgets patch that is slightly less lame, but it still just works around 
>>> the real issue so it’s probably not worth maintaining a yet another 
>>> wxWidgets patch for that.
>>> 
>>> 
>>> Garth
>>> 
>> 
>> Garth,
>> 
>> Can you test the rev 5892, and mainly the DRC dialog.
>> It does not include exactly your patch, because I found and fixed an
>> issue in DRC dialog on other platforms during tests.
>> These changes perhaps have fixed the OSX issues.
>> 
> The part of my patch that you applied to dialog_shim.cpp fixes the second 
> issue, but the rest is still the same as before.
> 
> Garth
> 
> 
Here’s the patch again against head.



smime.p7s
Description: S/MIME cryptographic 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] idea for post-release file manipulations

2015-07-07 Thread Garth Corral

> On Jul 7, 2015, at 10:53 AM, jp charras  wrote:
> 
> Le 05/07/2015 23:39, Garth Corral a écrit :
>> 
>>> On Jun 22, 2015, at 10:54 AM, Andy Peters  wrote:
>>> 
>>> 
 On Jun 22, 2015, at 5:00 AM, Johannes Maibaum  wrote:
 
 Hey OSX devs,
 
 And I just came across another minor UI glitch in pcbnew: When running the 
 DRC, the dialog
 window loses focus to the main window after the checks are finished. Since 
 the main window is
 usually bigger than the DRC dialog window this results in the dialog 
 suddenly vanishing from
 the screen. An unexperienced user might think that the checks failed and 
 might try to click
 the DRC button again. But since the dialog is still lurking behind the 
 main window, nothing
 happens.
 
 I think that there are two issues here, that both should be easy to fix:
 
 - DRC dialog window should keep focus after checks are finished.
 - If the dialog has somehow lost focus (perhaps the user deliberately gave 
 focus back to the
 main window, leaving the dialog open), the next click on the DRC 
 button/icon should bring the
 dialog back to focus.
 
 However, with the DRC issue I am not sure, if this is OSX only and I have 
 no Linux machine
 near me now to verify.
>>> 
>>> I have noticed this, too, and it’s been a long-standing annoyance. Is this 
>>> an OS X-only issue or does it affect all platforms.
>>> 
>> Here’s my craptastic workaround for these issues.  I’ve ifdef’d some of this 
>> but it’s probably harmless on other platforms.
>> 
>> It should come as a s surprise to no one that these are the result of OS X 
>> wxWidgets issues.  The wxWidgets bug tracker is littered with variants of 
>> these, some of which were ostensibly fixed, while others have languished for 
>> years.  I have a minimal repro for both so I’ll file bugs there.  I wouldn’t 
>> expect to see a fix on the 3.0 branch any time soon.  I have a wxWidgets 
>> patch that is slightly less lame, but it still just works around the real 
>> issue so it’s probably not worth maintaining a yet another wxWidgets patch 
>> for that.
>> 
>> 
>> Garth
>> 
> 
> Garth,
> 
> Can you test the rev 5892, and mainly the DRC dialog.
> It does not include exactly your patch, because I found and fixed an
> issue in DRC dialog on other platforms during tests.
> These changes perhaps have fixed the OSX issues.
> 
The part of my patch that you applied to dialog_shim.cpp fixes the second 
issue, but the rest is still the same as before.

Garth




smime.p7s
Description: S/MIME cryptographic 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] idea for post-release file manipulations

2015-07-07 Thread jp charras
Le 05/07/2015 23:39, Garth Corral a écrit :
> 
>> On Jun 22, 2015, at 10:54 AM, Andy Peters  wrote:
>>
>>
>>> On Jun 22, 2015, at 5:00 AM, Johannes Maibaum  wrote:
>>>
>>> Hey OSX devs,
>>>
>>> And I just came across another minor UI glitch in pcbnew: When running the 
>>> DRC, the dialog
>>> window loses focus to the main window after the checks are finished. Since 
>>> the main window is
>>> usually bigger than the DRC dialog window this results in the dialog 
>>> suddenly vanishing from
>>> the screen. An unexperienced user might think that the checks failed and 
>>> might try to click
>>> the DRC button again. But since the dialog is still lurking behind the main 
>>> window, nothing
>>> happens.
>>>
>>> I think that there are two issues here, that both should be easy to fix:
>>>
>>> - DRC dialog window should keep focus after checks are finished.
>>> - If the dialog has somehow lost focus (perhaps the user deliberately gave 
>>> focus back to the
>>> main window, leaving the dialog open), the next click on the DRC 
>>> button/icon should bring the
>>> dialog back to focus.
>>>
>>> However, with the DRC issue I am not sure, if this is OSX only and I have 
>>> no Linux machine
>>> near me now to verify.
>>
>> I have noticed this, too, and it’s been a long-standing annoyance. Is this 
>> an OS X-only issue or does it affect all platforms.
>>
> Here’s my craptastic workaround for these issues.  I’ve ifdef’d some of this 
> but it’s probably harmless on other platforms.
> 
> It should come as a s surprise to no one that these are the result of OS X 
> wxWidgets issues.  The wxWidgets bug tracker is littered with variants of 
> these, some of which were ostensibly fixed, while others have languished for 
> years.  I have a minimal repro for both so I’ll file bugs there.  I wouldn’t 
> expect to see a fix on the 3.0 branch any time soon.  I have a wxWidgets 
> patch that is slightly less lame, but it still just works around the real 
> issue so it’s probably not worth maintaining a yet another wxWidgets patch 
> for that.
> 
> 
> Garth
> 

Garth,

Can you test the rev 5892, and mainly the DRC dialog.
It does not include exactly your patch, because I found and fixed an
issue in DRC dialog on other platforms during tests.
These changes perhaps have fixed the OSX issues.

If this is not the case, please submit an other patch.

Thanks.


-- 
Jean-Pierre CHARRAS

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


Re: [Kicad-developers] idea for post-release file manipulations

2015-07-05 Thread Garth Corral

> On Jun 22, 2015, at 10:54 AM, Andy Peters  wrote:
> 
> 
>> On Jun 22, 2015, at 5:00 AM, Johannes Maibaum  wrote:
>> 
>> Hey OSX devs,
>> 
>> And I just came across another minor UI glitch in pcbnew: When running the 
>> DRC, the dialog
>> window loses focus to the main window after the checks are finished. Since 
>> the main window is
>> usually bigger than the DRC dialog window this results in the dialog 
>> suddenly vanishing from
>> the screen. An unexperienced user might think that the checks failed and 
>> might try to click
>> the DRC button again. But since the dialog is still lurking behind the main 
>> window, nothing
>> happens.
>> 
>> I think that there are two issues here, that both should be easy to fix:
>> 
>> - DRC dialog window should keep focus after checks are finished.
>> - If the dialog has somehow lost focus (perhaps the user deliberately gave 
>> focus back to the
>> main window, leaving the dialog open), the next click on the DRC button/icon 
>> should bring the
>> dialog back to focus.
>> 
>> However, with the DRC issue I am not sure, if this is OSX only and I have no 
>> Linux machine
>> near me now to verify.
> 
> I have noticed this, too, and it’s been a long-standing annoyance. Is this an 
> OS X-only issue or does it affect all platforms.
> 
Here’s my craptastic workaround for these issues.  I’ve ifdef’d some of this 
but it’s probably harmless on other platforms.

It should come as a s surprise to no one that these are the result of OS X 
wxWidgets issues.  The wxWidgets bug tracker is littered with variants of 
these, some of which were ostensibly fixed, while others have languished for 
years.  I have a minimal repro for both so I’ll file bugs there.  I wouldn’t 
expect to see a fix on the 3.0 branch any time soon.  I have a wxWidgets patch 
that is slightly less lame, but it still just works around the real issue so 
it’s probably not worth maintaining a yet another wxWidgets patch for that.


Garth



osx_dialog_z-order.patch
Description: Binary data





smime.p7s
Description: S/MIME cryptographic 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] idea for post-release file manipulations

2015-06-22 Thread Andy Peters

> On Jun 22, 2015, at 5:00 AM, Johannes Maibaum  wrote:
> 
> Hey OSX devs,
> 
> And I just came across another minor UI glitch in pcbnew: When running the 
> DRC, the dialog
> window loses focus to the main window after the checks are finished. Since 
> the main window is
> usually bigger than the DRC dialog window this results in the dialog suddenly 
> vanishing from
> the screen. An unexperienced user might think that the checks failed and 
> might try to click
> the DRC button again. But since the dialog is still lurking behind the main 
> window, nothing
> happens.
> 
> I think that there are two issues here, that both should be easy to fix:
> 
> - DRC dialog window should keep focus after checks are finished.
> - If the dialog has somehow lost focus (perhaps the user deliberately gave 
> focus back to the
> main window, leaving the dialog open), the next click on the DRC button/icon 
> should bring the
> dialog back to focus.
> 
> However, with the DRC issue I am not sure, if this is OSX only and I have no 
> Linux machine
> near me now to verify.

I have noticed this, too, and it’s been a long-standing annoyance. Is this an 
OS X-only issue or does it affect all platforms.

-a


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


Re: [Kicad-developers] idea for post-release file manipulations

2015-06-22 Thread Johannes Maibaum
Hey OSX devs,

great to hear that some of those UI issues will possibly be addressed before 
the stable
release!

As far as I can tell the combo box/drop-down menu bug in pcbnew only affects 
the menus listed
by Jean-Paul: Track Width, Via Diameter, Grid Size, Zoom Size. The Active Layer 
Switch drop
down menu in the toolbar above for example works as expected.

There seems to be no bug report for this. I would open one if this helps the 
devs?

And I just came across another minor UI glitch in pcbnew: When running the DRC, 
the dialog
window loses focus to the main window after the checks are finished. Since the 
main window is
usually bigger than the DRC dialog window this results in the dialog suddenly 
vanishing from
the screen. An unexperienced user might think that the checks failed and might 
try to click
the DRC button again. But since the dialog is still lurking behind the main 
window, nothing
happens.

I think that there are two issues here, that both should be easy to fix:

- DRC dialog window should keep focus after checks are finished.
- If the dialog has somehow lost focus (perhaps the user deliberately gave 
focus back to the
main window, leaving the dialog open), the next click on the DRC button/icon 
should bring the
dialog back to focus.

However, with the DRC issue I am not sure, if this is OSX only and I have no 
Linux machine
near me now to verify.

I could open a bug report for this, too, if you want.


Best,

Johannes

> Am 22.06.2015 um 07:33 schrieb Bernhard Stegmaier :
> 
> It is only about the comboboxes in the main window, right?
> Does anybody know any other comboboxes not working?
> 
> I played around with that already some while back, but didn’t find anything 
> wrong wrt how those are created.
> I can try again over the upcoming weekend…
> 
> 
> Regards,
> Bernhard
> 
>> On 22 Jun 2015, at 01:57, louijp  wrote:
>> 
>> I agree with Adam, this has been on and off for at least a year. But nobody 
>> came up with a plan to fix it. Now it seems that we have more OS X 
>> developers, so I hope someone will take the ball and run with it.
>> 
>> Jean-Paul
>> AC9GH
>> 
>> 
>> 
>> Sent from my Verizon Wireless 4G LTE smartphone
>> 
>> 
>>  Original message 
>> From: Adam Wolf 
>> Date: 2015/06/21 2:38 PM (GMT-05:00)
>> To: Nick Østergaard 
>> Cc: kicad-developers@lists.launchpad.net, Jean-Paul Louis 
>> Subject: Re: [Kicad-developers] idea for post-release file manipulations
>> 
>> That is a legitimate bug.  Not sure if it is on the tracker yet, but it has 
>> been discussed on the list.
>> 
>> There are plenty of OS X UI issues that should be evaluated before the 
>> stable release.  I suspect moat of then are wxwidgets issues.  *sigh*
>> 
>> Adam Wolf
>> 
>> Adam Wolf
>> 
>> On Jun 21, 2015 1:07 PM, "Nick Østergaard"  wrote:
>> Where is the bug listed in the bug tracker Jean-Paul?
>> 
>> 2015-06-21 19:46 GMT+02:00 Jean-Paul Louis :
>> > Are we going to the stable release with all the drop-down items broken on 
>> > pcbnew OSX?
>> >
>> > I cannot use the mouse or the track-pad to select any of the items on the 
>> > four drop-down menus for Track size, Via size, Grid size and Zoom 
>> > selection.
>> >
>> > I reported this several times, but nobody seems to acknowledge it. Is it 
>> > an issue with my setting? or it is a real issue?
>> >
>> > Thanks for letting me know.
>> >
>> > A very frustrated Jean-Paul
>> > AC9GH
>> >
>> >> On Jun 21, 2015, at 1:22 PM, Adam Wolf  
>> >> wrote:
>> >>
>> >> Simon,
>> >>
>> >> A group of us have talked about making a git plugin that will be 
>> >> compatible w the github plugin, but will use git on the user's system and 
>> >> won't do network io on its own.
>> >>
>> >> We have basically always pushed it off until after the stable release, 
>> >> but as soon as things quiet down i think we should see who is interested 
>> >> and make a roadmap and get buy-in from the lead team.
>> >>
>> >> Adam Wolf
>> >>
>> >> On Jun 21, 2015 11:46 AM, "Wayne Stambaugh"  wrote:
>> >> See include/richio.h
>> >>
>> >> Our I/O objects already support wxInputStream and wxOutputStream.
>> >> Although there is no reason you couldn't add objects that use
>> >> std::istream and std::ostream or the boost::iostreams.  I believe the
>> >> wxIoStreams already support support archives so

Re: [Kicad-developers] idea for post-release file manipulations

2015-06-21 Thread Bernhard Stegmaier
It is only about the comboboxes in the main window, right?
Does anybody know any other comboboxes not working?

I played around with that already some while back, but didn’t find anything 
wrong wrt how those are created.
I can try again over the upcoming weekend…


Regards,
Bernhard

> On 22 Jun 2015, at 01:57, louijp  wrote:
> 
> I agree with Adam, this has been on and off for at least a year. But nobody 
> came up with a plan to fix it. Now it seems that we have more OS X 
> developers, so I hope someone will take the ball and run with it.
> 
> Jean-Paul
> AC9GH
> 
> 
> 
> Sent from my Verizon Wireless 4G LTE smartphone
> 
> 
>  Original message 
> From: Adam Wolf  
> Date: 2015/06/21 2:38 PM (GMT-05:00) 
> To: Nick Østergaard  
> Cc: kicad-developers@lists.launchpad.net, Jean-Paul Louis  
> Subject: Re: [Kicad-developers] idea for post-release file manipulations 
> 
> That is a legitimate bug.  Not sure if it is on the tracker yet, but it has 
> been discussed on the list.
> 
> There are plenty of OS X UI issues that should be evaluated before the stable 
> release.  I suspect moat of then are wxwidgets issues.  *sigh*
> 
> Adam Wolf
> 
> Adam Wolf
> 
> On Jun 21, 2015 1:07 PM, "Nick Østergaard"  <mailto:oe.n...@gmail.com>> wrote:
> Where is the bug listed in the bug tracker Jean-Paul?
> 
> 2015-06-21 19:46 GMT+02:00 Jean-Paul Louis  <mailto:lou...@yahoo.com>>:
> > Are we going to the stable release with all the drop-down items broken on 
> > pcbnew OSX?
> >
> > I cannot use the mouse or the track-pad to select any of the items on the 
> > four drop-down menus for Track size, Via size, Grid size and Zoom selection.
> >
> > I reported this several times, but nobody seems to acknowledge it. Is it an 
> > issue with my setting? or it is a real issue?
> >
> > Thanks for letting me know.
> >
> > A very frustrated Jean-Paul
> > AC9GH
> >
> >> On Jun 21, 2015, at 1:22 PM, Adam Wolf  >> <mailto:adamw...@feelslikeburning.com>> wrote:
> >>
> >> Simon,
> >>
> >> A group of us have talked about making a git plugin that will be 
> >> compatible w the github plugin, but will use git on the user's system and 
> >> won't do network io on its own.
> >>
> >> We have basically always pushed it off until after the stable release, but 
> >> as soon as things quiet down i think we should see who is interested and 
> >> make a roadmap and get buy-in from the lead team.
> >>
> >> Adam Wolf
> >>
> >> On Jun 21, 2015 11:46 AM, "Wayne Stambaugh"  >> <mailto:stambau...@gmail.com>> wrote:
> >> See include/richio.h
> >>
> >> Our I/O objects already support wxInputStream and wxOutputStream.
> >> Although there is no reason you couldn't add objects that use
> >> std::istream and std::ostream or the boost::iostreams.  I believe the
> >> wxIoStreams already support support archives so all you would have to do
> >> is create the stream and pass it too the proper LINE_READER or
> >> OUTPUT_FORMATTER object.  You would automagically have archive stream
> >> support for board file and footprint libraries.
> >>
> >> On 6/21/2015 8:55 AM, Simon Richter wrote:
> >> > Hi,
> >> >
> >> > Am 21.06.2015 um 03:06 schrieb Cirilo Bernardo:
> >> >
> >> >> a. Abstracting a stream class which can magically support
> >> >> file retrieval by http, local files, and perhaps github (I know
> >> >> next to nothing about how github works) and local file
> >> >> writing.
> >> >
> >> > std::istream?
> >> >
> >> >> b. The stream class can automatically inflate *.gz files
> >> >> (basically files compressed by zlib and with .gz at the end).
> >> >
> >> > boost::iostreams::gzip?
> >> >
> >> >> Supporting *.gz can typically shrink footprint files to 30-40%
> >> >> of the uncompressed size and VRML files can often
> >> >> compress to <15% of the original size and large STEP
> >> >> and IGES files can compress to 10% of the original.
> >> >
> >> > Is that actually a problem for users, though?
> >> >
> >> > I'd probably even want to see the opposite -- network operations removed
> >> > from the rest of the program. Right now, if I have github footprints in
> >> &

Re: [Kicad-developers] idea for post-release file manipulations

2015-06-21 Thread louijp


I agree with Adam, this has been on and off for at least a year. But nobody 
came up with a plan to fix it. Now it seems that we have more OS X developers, 
so I hope someone will take the ball and run with it.
Jean-PaulAC9GH


Sent from my Verizon Wireless 4G LTE smartphone

 Original message 
From: Adam Wolf  
Date: 2015/06/21  2:38 PM  (GMT-05:00) 
To: Nick Østergaard  
Cc: kicad-developers@lists.launchpad.net, Jean-Paul Louis  
Subject: Re: [Kicad-developers] idea for post-release file manipulations 

That is a legitimate bug.  Not sure if it is on the tracker yet, but it has 
been discussed on the list.
There are plenty of OS X UI issues that should be evaluated before the stable 
release.  I suspect moat of then are wxwidgets issues.  *sigh*
Adam Wolf
Adam Wolf
On Jun 21, 2015 1:07 PM, "Nick Østergaard"  wrote:
Where is the bug listed in the bug tracker Jean-Paul?



2015-06-21 19:46 GMT+02:00 Jean-Paul Louis :

> Are we going to the stable release with all the drop-down items broken on 
> pcbnew OSX?

>

> I cannot use the mouse or the track-pad to select any of the items on the 
> four drop-down menus for Track size, Via size, Grid size and Zoom selection.

>

> I reported this several times, but nobody seems to acknowledge it. Is it an 
> issue with my setting? or it is a real issue?

>

> Thanks for letting me know.

>

> A very frustrated Jean-Paul

> AC9GH

>

>> On Jun 21, 2015, at 1:22 PM, Adam Wolf  wrote:

>>

>> Simon,

>>

>> A group of us have talked about making a git plugin that will be compatible 
>> w the github plugin, but will use git on the user's system and won't do 
>> network io on its own.

>>

>> We have basically always pushed it off until after the stable release, but 
>> as soon as things quiet down i think we should see who is interested and 
>> make a roadmap and get buy-in from the lead team.

>>

>> Adam Wolf

>>

>> On Jun 21, 2015 11:46 AM, "Wayne Stambaugh"  wrote:

>> See include/richio.h

>>

>> Our I/O objects already support wxInputStream and wxOutputStream.

>> Although there is no reason you couldn't add objects that use

>> std::istream and std::ostream or the boost::iostreams.  I believe the

>> wxIoStreams already support support archives so all you would have to do

>> is create the stream and pass it too the proper LINE_READER or

>> OUTPUT_FORMATTER object.  You would automagically have archive stream

>> support for board file and footprint libraries.

>>

>> On 6/21/2015 8:55 AM, Simon Richter wrote:

>> > Hi,

>> >

>> > Am 21.06.2015 um 03:06 schrieb Cirilo Bernardo:

>> >

>> >> a. Abstracting a stream class which can magically support

>> >> file retrieval by http, local files, and perhaps github (I know

>> >> next to nothing about how github works) and local file

>> >> writing.

>> >

>> > std::istream?

>> >

>> >> b. The stream class can automatically inflate *.gz files

>> >> (basically files compressed by zlib and with .gz at the end).

>> >

>> > boost::iostreams::gzip?

>> >

>> >> Supporting *.gz can typically shrink footprint files to 30-40%

>> >> of the uncompressed size and VRML files can often

>> >> compress to <15% of the original size and large STEP

>> >> and IGES files can compress to 10% of the original.

>> >

>> > Is that actually a problem for users, though?

>> >

>> > I'd probably even want to see the opposite -- network operations removed

>> > from the rest of the program. Right now, if I have github footprints in

>> > my list, entering cvpcb or pcbnew always takes a while because the

>> > libraries are updated everytime.

>> >

>> > I'd rather have an explicit mechanism to update the libraries, giving me

>> > local files that are instantly and always available, with no new failure

>> > modes to handle for the application.

>> >

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

Re: [Kicad-developers] idea for post-release file manipulations

2015-06-21 Thread Simon Richter
Hi,

> That is a legitimate bug.  Not sure if it is on the tracker yet, but
it has been discussed on the list.

Can you create bugs on the bug tracker, so these don't get dropped again?

We definitely need extensive testing on MacOS. On reasonably modern
MacBooks, OpenGL is the only canvas with close to acceptable performance.

   Simon



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


Re: [Kicad-developers] idea for post-release file manipulations

2015-06-21 Thread Adam Wolf
That is a legitimate bug.  Not sure if it is on the tracker yet, but it has
been discussed on the list.

There are plenty of OS X UI issues that should be evaluated before the
stable release.  I suspect moat of then are wxwidgets issues.  *sigh*

Adam Wolf

Adam Wolf
On Jun 21, 2015 1:07 PM, "Nick Østergaard"  wrote:

> Where is the bug listed in the bug tracker Jean-Paul?
>
> 2015-06-21 19:46 GMT+02:00 Jean-Paul Louis :
> > Are we going to the stable release with all the drop-down items broken
> on pcbnew OSX?
> >
> > I cannot use the mouse or the track-pad to select any of the items on
> the four drop-down menus for Track size, Via size, Grid size and Zoom
> selection.
> >
> > I reported this several times, but nobody seems to acknowledge it. Is it
> an issue with my setting? or it is a real issue?
> >
> > Thanks for letting me know.
> >
> > A very frustrated Jean-Paul
> > AC9GH
> >
> >> On Jun 21, 2015, at 1:22 PM, Adam Wolf 
> wrote:
> >>
> >> Simon,
> >>
> >> A group of us have talked about making a git plugin that will be
> compatible w the github plugin, but will use git on the user's system and
> won't do network io on its own.
> >>
> >> We have basically always pushed it off until after the stable release,
> but as soon as things quiet down i think we should see who is interested
> and make a roadmap and get buy-in from the lead team.
> >>
> >> Adam Wolf
> >>
> >> On Jun 21, 2015 11:46 AM, "Wayne Stambaugh" 
> wrote:
> >> See include/richio.h
> >>
> >> Our I/O objects already support wxInputStream and wxOutputStream.
> >> Although there is no reason you couldn't add objects that use
> >> std::istream and std::ostream or the boost::iostreams.  I believe the
> >> wxIoStreams already support support archives so all you would have to do
> >> is create the stream and pass it too the proper LINE_READER or
> >> OUTPUT_FORMATTER object.  You would automagically have archive stream
> >> support for board file and footprint libraries.
> >>
> >> On 6/21/2015 8:55 AM, Simon Richter wrote:
> >> > Hi,
> >> >
> >> > Am 21.06.2015 um 03:06 schrieb Cirilo Bernardo:
> >> >
> >> >> a. Abstracting a stream class which can magically support
> >> >> file retrieval by http, local files, and perhaps github (I know
> >> >> next to nothing about how github works) and local file
> >> >> writing.
> >> >
> >> > std::istream?
> >> >
> >> >> b. The stream class can automatically inflate *.gz files
> >> >> (basically files compressed by zlib and with .gz at the end).
> >> >
> >> > boost::iostreams::gzip?
> >> >
> >> >> Supporting *.gz can typically shrink footprint files to 30-40%
> >> >> of the uncompressed size and VRML files can often
> >> >> compress to <15% of the original size and large STEP
> >> >> and IGES files can compress to 10% of the original.
> >> >
> >> > Is that actually a problem for users, though?
> >> >
> >> > I'd probably even want to see the opposite -- network operations
> removed
> >> > from the rest of the program. Right now, if I have github footprints
> in
> >> > my list, entering cvpcb or pcbnew always takes a while because the
> >> > libraries are updated everytime.
> >> >
> >> > I'd rather have an explicit mechanism to update the libraries, giving
> me
> >> > local files that are instantly and always available, with no new
> failure
> >> > modes to handle for the application.
> >> >
> >> >Simon
> >> >
> >> >
> >> >
> >> > ___
> >> > Mailing list: https://launchpad.net/~kicad-developers
> >> > Post to : kicad-developers@lists.launchpad.net
> >> > Unsubscribe : https://launchpad.net/~kicad-developers
> >> > More help   : https://help.launchpad.net/ListHelp
> >> >
> >>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
___
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] idea for post-release file manipulations

2015-06-21 Thread Nick Østergaard
Where is the bug listed in the bug tracker Jean-Paul?

2015-06-21 19:46 GMT+02:00 Jean-Paul Louis :
> Are we going to the stable release with all the drop-down items broken on 
> pcbnew OSX?
>
> I cannot use the mouse or the track-pad to select any of the items on the 
> four drop-down menus for Track size, Via size, Grid size and Zoom selection.
>
> I reported this several times, but nobody seems to acknowledge it. Is it an 
> issue with my setting? or it is a real issue?
>
> Thanks for letting me know.
>
> A very frustrated Jean-Paul
> AC9GH
>
>> On Jun 21, 2015, at 1:22 PM, Adam Wolf  wrote:
>>
>> Simon,
>>
>> A group of us have talked about making a git plugin that will be compatible 
>> w the github plugin, but will use git on the user's system and won't do 
>> network io on its own.
>>
>> We have basically always pushed it off until after the stable release, but 
>> as soon as things quiet down i think we should see who is interested and 
>> make a roadmap and get buy-in from the lead team.
>>
>> Adam Wolf
>>
>> On Jun 21, 2015 11:46 AM, "Wayne Stambaugh"  wrote:
>> See include/richio.h
>>
>> Our I/O objects already support wxInputStream and wxOutputStream.
>> Although there is no reason you couldn't add objects that use
>> std::istream and std::ostream or the boost::iostreams.  I believe the
>> wxIoStreams already support support archives so all you would have to do
>> is create the stream and pass it too the proper LINE_READER or
>> OUTPUT_FORMATTER object.  You would automagically have archive stream
>> support for board file and footprint libraries.
>>
>> On 6/21/2015 8:55 AM, Simon Richter wrote:
>> > Hi,
>> >
>> > Am 21.06.2015 um 03:06 schrieb Cirilo Bernardo:
>> >
>> >> a. Abstracting a stream class which can magically support
>> >> file retrieval by http, local files, and perhaps github (I know
>> >> next to nothing about how github works) and local file
>> >> writing.
>> >
>> > std::istream?
>> >
>> >> b. The stream class can automatically inflate *.gz files
>> >> (basically files compressed by zlib and with .gz at the end).
>> >
>> > boost::iostreams::gzip?
>> >
>> >> Supporting *.gz can typically shrink footprint files to 30-40%
>> >> of the uncompressed size and VRML files can often
>> >> compress to <15% of the original size and large STEP
>> >> and IGES files can compress to 10% of the original.
>> >
>> > Is that actually a problem for users, though?
>> >
>> > I'd probably even want to see the opposite -- network operations removed
>> > from the rest of the program. Right now, if I have github footprints in
>> > my list, entering cvpcb or pcbnew always takes a while because the
>> > libraries are updated everytime.
>> >
>> > I'd rather have an explicit mechanism to update the libraries, giving me
>> > local files that are instantly and always available, with no new failure
>> > modes to handle for the application.
>> >
>> >Simon
>> >
>> >
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
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] idea for post-release file manipulations

2015-06-21 Thread Jean-Paul Louis
Are we going to the stable release with all the drop-down items broken on 
pcbnew OSX?

I cannot use the mouse or the track-pad to select any of the items on the four 
drop-down menus for Track size, Via size, Grid size and Zoom selection.

I reported this several times, but nobody seems to acknowledge it. Is it an 
issue with my setting? or it is a real issue?

Thanks for letting me know.

A very frustrated Jean-Paul
AC9GH

> On Jun 21, 2015, at 1:22 PM, Adam Wolf  wrote:
> 
> Simon,
> 
> A group of us have talked about making a git plugin that will be compatible w 
> the github plugin, but will use git on the user's system and won't do network 
> io on its own.
> 
> We have basically always pushed it off until after the stable release, but as 
> soon as things quiet down i think we should see who is interested and make a 
> roadmap and get buy-in from the lead team.
> 
> Adam Wolf
> 
> On Jun 21, 2015 11:46 AM, "Wayne Stambaugh"  wrote:
> See include/richio.h
> 
> Our I/O objects already support wxInputStream and wxOutputStream.
> Although there is no reason you couldn't add objects that use
> std::istream and std::ostream or the boost::iostreams.  I believe the
> wxIoStreams already support support archives so all you would have to do
> is create the stream and pass it too the proper LINE_READER or
> OUTPUT_FORMATTER object.  You would automagically have archive stream
> support for board file and footprint libraries.
> 
> On 6/21/2015 8:55 AM, Simon Richter wrote:
> > Hi,
> >
> > Am 21.06.2015 um 03:06 schrieb Cirilo Bernardo:
> >
> >> a. Abstracting a stream class which can magically support
> >> file retrieval by http, local files, and perhaps github (I know
> >> next to nothing about how github works) and local file
> >> writing.
> >
> > std::istream?
> >
> >> b. The stream class can automatically inflate *.gz files
> >> (basically files compressed by zlib and with .gz at the end).
> >
> > boost::iostreams::gzip?
> >
> >> Supporting *.gz can typically shrink footprint files to 30-40%
> >> of the uncompressed size and VRML files can often
> >> compress to <15% of the original size and large STEP
> >> and IGES files can compress to 10% of the original.
> >
> > Is that actually a problem for users, though?
> >
> > I'd probably even want to see the opposite -- network operations removed
> > from the rest of the program. Right now, if I have github footprints in
> > my list, entering cvpcb or pcbnew always takes a while because the
> > libraries are updated everytime.
> >
> > I'd rather have an explicit mechanism to update the libraries, giving me
> > local files that are instantly and always available, with no new failure
> > modes to handle for the application.
> >
> >Simon
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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


Re: [Kicad-developers] idea for post-release file manipulations

2015-06-21 Thread Adam Wolf
Simon,

A group of us have talked about making a git plugin that will be compatible
w the github plugin, but will use git on the user's system and won't do
network io on its own.

We have basically always pushed it off until after the stable release, but
as soon as things quiet down i think we should see who is interested and
make a roadmap and get buy-in from the lead team.

Adam Wolf
On Jun 21, 2015 11:46 AM, "Wayne Stambaugh"  wrote:

> See include/richio.h
>
> Our I/O objects already support wxInputStream and wxOutputStream.
> Although there is no reason you couldn't add objects that use
> std::istream and std::ostream or the boost::iostreams.  I believe the
> wxIoStreams already support support archives so all you would have to do
> is create the stream and pass it too the proper LINE_READER or
> OUTPUT_FORMATTER object.  You would automagically have archive stream
> support for board file and footprint libraries.
>
> On 6/21/2015 8:55 AM, Simon Richter wrote:
> > Hi,
> >
> > Am 21.06.2015 um 03:06 schrieb Cirilo Bernardo:
> >
> >> a. Abstracting a stream class which can magically support
> >> file retrieval by http, local files, and perhaps github (I know
> >> next to nothing about how github works) and local file
> >> writing.
> >
> > std::istream?
> >
> >> b. The stream class can automatically inflate *.gz files
> >> (basically files compressed by zlib and with .gz at the end).
> >
> > boost::iostreams::gzip?
> >
> >> Supporting *.gz can typically shrink footprint files to 30-40%
> >> of the uncompressed size and VRML files can often
> >> compress to <15% of the original size and large STEP
> >> and IGES files can compress to 10% of the original.
> >
> > Is that actually a problem for users, though?
> >
> > I'd probably even want to see the opposite -- network operations removed
> > from the rest of the program. Right now, if I have github footprints in
> > my list, entering cvpcb or pcbnew always takes a while because the
> > libraries are updated everytime.
> >
> > I'd rather have an explicit mechanism to update the libraries, giving me
> > local files that are instantly and always available, with no new failure
> > modes to handle for the application.
> >
> >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] idea for post-release file manipulations

2015-06-21 Thread Wayne Stambaugh
See include/richio.h

Our I/O objects already support wxInputStream and wxOutputStream.
Although there is no reason you couldn't add objects that use
std::istream and std::ostream or the boost::iostreams.  I believe the
wxIoStreams already support support archives so all you would have to do
is create the stream and pass it too the proper LINE_READER or
OUTPUT_FORMATTER object.  You would automagically have archive stream
support for board file and footprint libraries.

On 6/21/2015 8:55 AM, Simon Richter wrote:
> Hi,
> 
> Am 21.06.2015 um 03:06 schrieb Cirilo Bernardo:
> 
>> a. Abstracting a stream class which can magically support
>> file retrieval by http, local files, and perhaps github (I know
>> next to nothing about how github works) and local file
>> writing.
> 
> std::istream?
> 
>> b. The stream class can automatically inflate *.gz files
>> (basically files compressed by zlib and with .gz at the end).
> 
> boost::iostreams::gzip?
> 
>> Supporting *.gz can typically shrink footprint files to 30-40%
>> of the uncompressed size and VRML files can often
>> compress to <15% of the original size and large STEP
>> and IGES files can compress to 10% of the original.
> 
> Is that actually a problem for users, though?
> 
> I'd probably even want to see the opposite -- network operations removed
> from the rest of the program. Right now, if I have github footprints in
> my list, entering cvpcb or pcbnew always takes a while because the
> libraries are updated everytime.
> 
> I'd rather have an explicit mechanism to update the libraries, giving me
> local files that are instantly and always available, with no new failure
> modes to handle for the application.
> 
>Simon
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


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


Re: [Kicad-developers] idea for post-release file manipulations

2015-06-21 Thread Simon Richter
Hi,

Am 21.06.2015 um 03:06 schrieb Cirilo Bernardo:

> a. Abstracting a stream class which can magically support
> file retrieval by http, local files, and perhaps github (I know
> next to nothing about how github works) and local file
> writing.

std::istream?

> b. The stream class can automatically inflate *.gz files
> (basically files compressed by zlib and with .gz at the end).

boost::iostreams::gzip?

> Supporting *.gz can typically shrink footprint files to 30-40%
> of the uncompressed size and VRML files can often
> compress to <15% of the original size and large STEP
> and IGES files can compress to 10% of the original.

Is that actually a problem for users, though?

I'd probably even want to see the opposite -- network operations removed
from the rest of the program. Right now, if I have github footprints in
my list, entering cvpcb or pcbnew always takes a while because the
libraries are updated everytime.

I'd rather have an explicit mechanism to update the libraries, giving me
local files that are instantly and always available, with no new failure
modes to handle for the application.

   Simon



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