Re: [Kicad-developers] [PATCH] Dark Theme Fixups

[Wayne Stambaugh]

I just finished testing it on windows 7.  I don't know if it's better or
worse just different.  I'm don't have a strong opinion one way or
another but I would still like to hear from some osx devs to get their
input.

On 12/15/2015 9:33 AM, Chris Pavlina wrote:
> If it counts for anything, I vote for this patch too. It's not /just/ an 
> improvement for dark themes, I think it looks way nicer and more 
> professional for the light themes too. I'd love to clean up those lumpy 
> gradients :)
> 
> Unfortunately I don't have any other platforms at hand to test it on :(
> 
> On Tue, Dec 15, 2015 at 01:54:14PM +0100, Maciej Sumiński wrote:
>> Hi Windsor,
>>
>> Thank you for the patch, I like the results. Personally, I would love to
>> have it merged, but we need to check if it does not break anything on
>> other platforms first.
>>
>> Regards,
>> Orson
>>
>> On 12/14/2015 04:42 AM, Windsor Schmidt wrote:
>>> Hi everyone,
>>>
>>> This is my first post to the list, so please go easy on me. :D I have made 
>>> a couple of changes to improve the appearance of the GUI for users with 
>>> dark themes in Linux. A patch is attached.
>>>
>>> * Removed toolbar gradient by adding wxAUI_TB_PLAIN_BACKGROUND to
>>>   wxAuiToolBar style (gradient is the default).
>>>
>>> * Removed the white border from the main project tree view
>>>   by replacing style constant wxSW_3D with wxSW_3DSASH.
>>>
>>> * Removed the white border from wxAui panes in KiCad manager,
>>>   pcbnew, and eeschema by calling PaneBorder( false ) on AUI panes.
>>>
>>> Here are some screenshots from my Arch Linux desktop running bspwm (GTK2):
>>>
>>> Dark theme from trunk: http://i.imgur.com/o1ueuVm.png
>>> Dark theme after fixups: http://i.imgur.com/TMdu8TF.png
>>> Light theme from trunk: http://i.imgur.com/MohCz76.png
>>> Light theme after fixups: http://i.imgur.com/Oj6Bi0F.png
>>>
>>> NOTE: That third fixup involves a loop that runs before updating the wxAUI 
>>> manager. I duplicate this code in 3 places where the white border was most 
>>> prominent (toolbars in the manager, eeschema, and pcbnew). I assume this 
>>> routine could be centralized and called before any time the AUI manager is 
>>> updated, however I don't know the KiCad codebase well enough to approach 
>>> this.
>>>
>>> Thanks. KiCad rocks!
>>>
>>> -Windsor
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://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] FreeCAD StepUp tools Openfile dialog issue on OSX

[Jose A. Saumell]

Hi Maurice,

That worked for me on OSX 10.9.5 now with native dialog. Thanks!
Jose

On Tue, Dec 15, 2015 at 10:56 AM easyw  wrote:

> Hi Jose,
>
> here is the solution for OSX:
>
> 1) add
> import PySide
>just before (line 48 of StepUp tools 1.3.2.8)
> from PySide import QtGui, QtCore
> 2) and change
> name=QtGui.QFileDialog.getOpenFileName(self, "Open File...",
> last_file_path, "kicad module files (*.kicad_mod)")[0]
>(line 629,630 of StepUp tools 1.3.2.8)
>with
> name, Filter = PySide.QtGui.QFileDialog.getOpenFileName(None,
>  "Open File...", last_file_path, "*.kicad_mod")
>
> that should work on all platform with native dialog
>
> If you could confirm me that is fine, I will update the tool on
> repository :)
>
> thank you
> Maurice
>
> On 14/12/2015 20.56, Jose A. Saumell wrote:
> > No problem, thank you for the tools, I am working on a new board and
> > using the FreeCAD only workflow. Today created a PCB 3D model in step
> > which is really valuable!
> > Take care
> >
> > On Mon, Dec 14, 2015 at 4:43 PM easyw  > > wrote:
> >
> > Hi Jose,
> >
> > I can reproduce it in OSX Lion, so I can debug :)
> >
> > Thank you for reporting it and also for the solution-workaround you
> have
> > found!
> >
> > keep in touch
> > Maurice :)
> >
> > On 14/12/2015 16.43, Jose A. Saumell wrote:
> >  > Hi,
> >  >
> >  > I've ran into an issue whenever I had to use the StepUp tools on
> > Freecad
> >  > to open a footprint and do the alignment of 3D model.
> >  >
> >  > I would get an open file dialog but nothing would happen after
> > selecting
> >  > the .kicad_mod file.
> >  >
> >  > Inside kicad-StepUp-tools.FCMacro:
> >  > The name[0] variable would return an empty value.
> >  >
> >  > I worked around the problem by not using native OSX Open file
> dialog:
> >  > //
> >  >
> >  > name=QtGui.QFileDialog.getOpenFileName(self, 'Open file',
> >  > last_file_path,"kicad module files (*.kicad_mod)",
> >  > options=QtGui.QFileDialog.DontUseNativeDialog )[0]
> >  >
> >  > //
> >  >
> >  > This is working for me now, not sure exactly why it is not
> > working with
> >  > native OSX dialog.
> >  >
> >  >
> >  > Cheers, Jose
> >  >
> >  >
> >  >
> >  >
> >  >
> >  >
> >  > ___
> >  > Mailing list: https://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: To facilitate easier Via Curtain/Filling

[Tomasz Wlostowski]

On 15.12.2015 16:52, Wayne Stambaugh wrote:
> Sorry I didn't respond to this sooner but I've been busy.  I'm not
> thrilled with this idea.  I know it solves the immediate problem but it
> is an incomplete solution.

Hi Wayne,

I surely agree that changing just the net propagation algorithm is not
enough, but I'm not sure adding support for free vias needs to go as far
as changing the file format. Neither Eagle nor Altium (as far as I know)
have a special notion of a free via. In the latter, any via or trace (or
a free track) will retain its net unless:
- the net is removed from the netlist,
- new netcode is propagated from a pad through traces or vias and there
is no conflict (= more than 1 netcode hitting the item after propagation).
If the via is placed by the 'via' tool, it can also inherit its net from
the underlying zone, but only if there's no net conflict. I believe this
is more or less the behaviour of Steven's patch.

So IMHO, the minimum changes are:
- keep the file format unmodified.
- update the net propagation algorithm.
- update the DRC to always report tracks/vias not connected to any pad
(must take zone connections into account). Same for the 'cleanup' algorithm.
- update orphan filled area removal code to take stitching vias into
account.
- add a via placement tool (quite trivial, like MODULE_TOOLS::PlacePad
in the module editor)
- update the existing GAL track/via properties dialog to allow assigning
nets.
- add Ben's RF patches & update array tool ;)

None of these changes has impact on the file format/data model, so
hopefully they should not break anything and can be done incrementally.

Cheers,
Tom

  I would rather we do a complete free via
> implementation and not introduce a stop gap measure into Pcbnew.  We've
> discussed the idea of incorporating free vias many times in the past.
> Since we are in a new development cycle, now is the time to revisit
> this.  At a minimum this should include the following:
> 
> 1) Board file format support for free vias.  Do we need to add any new
> tokens to the board file format and where do we want to put the free
> vias in the board file?  We need to define what capabilities our free
> vias require and plan accordingly.  This will be a file format change so
> we need to consider this carefully.
> 
> 2) Editing tools (menu entries, toolbars, hot keys, dialogs, etc.) for
> adding and editing free vias.  Our array tool could come in handy here.
> 
> 3) Update DRC to handle free vias.
> 
> 4) Verify support code still works.  I'm guessing we wont need to change
> our plotting, printing, and/or export code since we already support
> through hole, micro, and blind/buried vias (are there any other types of
> vias?).
> 
> Please consider this instead of quick fixes.  This is one of the reasons
> the KiCad code base is so crufty.  We need to start doing a better job
> of looking at the big picture.
> 
> Cheers,
> 
> Wayne
> 
> On 12/14/2015 9:26 AM, Tomasz Wlostowski wrote:
>> On 14.12.2015 14:40, Strontium wrote:
>>> Hi Thomas,
>>>
>>> I considered this, but tracking zones is non trivial.
>>>
>>> For example, imagine the stackup:
>>>
>>> GND
>>> VCC
>>> GND
>>> VCC
>>>
>>> A Through Via, from top to bottom could be connected validly connected
>>> to either GND or VCC.
>>>
>>> Once the net is removed from the via by the reassignment pass, there is
>>> no longer any information left to tell kicad which pair of zones was
>>> connected by the via.
>>
>> Indeed, in case of such a conflict retaining the via's net is IMHO the
>> only good solution.
>>
>>>
>>> The approach I suggest will fix this problem, because it just wont
>>> change the net for those vias.  It wont consider if there is a zone or
>>> not, it just says "hey, you gave it the GND net, so i will leave it as
>>> GND."
>>
>> It also seems Altium is managing via's nets this way. I would vote for
>> merging the patch.
>>
>> Cheers,
>> Tom
>>
>>>
>>>
>>> On 14/12/15 21:21, Tomasz Wlostowski wrote:
 On 12.12.2015 02:41, Strontium wrote:
> This change should not break or modify any current behaviour, EXCEPT to
> retain the nets of tracks/vias which Kicad is otherwise incapable of
> determining automatically.
 Hi Steven,

 Thanks for the patch, it also (partially) fixes the via stitching issue
 many people have been complaining about. The origin of the problem is
 that the net propagation code does not take zones into account - so a
 via that is not connected to any pad with a chain of tracks is treated
 as disconnected.

 Adding zone support in the net calculation code should AFAIK fix this
 for good, but it may also require enhancing the DRC (so that it will
 report every object with no pad connection) and the 'clean tracks'
 tool code.

 Regards,
 Tom

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

Re: [Kicad-developers] FreeCAD StepUp tools Openfile dialog issue on OSX

[easyw]

Thank you for your positive feedback!
I'm going to update the repo :)

Maurice

On 15/12/2015 18.57, Jose A. Saumell wrote:

Hi Maurice,

That worked for me on OSX 10.9.5 now with native dialog. Thanks!
Jose

On Tue, Dec 15, 2015 at 10:56 AM easyw > wrote:

Hi Jose,

here is the solution for OSX:

1) add
import PySide
just before (line 48 of StepUp tools 1.3.2.8)
from PySide import QtGui, QtCore
2) and change
name=QtGui.QFileDialog.getOpenFileName(self, "Open File...",
last_file_path, "kicad module files (*.kicad_mod)")[0]
(line 629,630 of StepUp tools 1.3.2.8)
with
name, Filter = PySide.QtGui.QFileDialog.getOpenFileName(None,
  "Open File...", last_file_path, "*.kicad_mod")

that should work on all platform with native dialog

If you could confirm me that is fine, I will update the tool on
repository :)

thank you
Maurice

On 14/12/2015 20.56, Jose A. Saumell wrote:
 > No problem, thank you for the tools, I am working on a new board and
 > using the FreeCAD only workflow. Today created a PCB 3D model in step
 > which is really valuable!
 > Take care
 >
 > On Mon, Dec 14, 2015 at 4:43 PM easyw 
 > >> wrote:
 >
 > Hi Jose,
 >
 > I can reproduce it in OSX Lion, so I can debug :)
 >
 > Thank you for reporting it and also for the
solution-workaround you have
 > found!
 >
 > keep in touch
 > Maurice :)
 >
 > On 14/12/2015 16.43, Jose A. Saumell wrote:
 >  > Hi,
 >  >
 >  > I've ran into an issue whenever I had to use the StepUp
tools on
 > Freecad
 >  > to open a footprint and do the alignment of 3D model.
 >  >
 >  > I would get an open file dialog but nothing would happen after
 > selecting
 >  > the .kicad_mod file.
 >  >
 >  > Inside kicad-StepUp-tools.FCMacro:
 >  > The name[0] variable would return an empty value.
 >  >
 >  > I worked around the problem by not using native OSX Open
file dialog:
 >  > //
 >  >
 >  > name=QtGui.QFileDialog.getOpenFileName(self, 'Open file',
 >  > last_file_path,"kicad module files (*.kicad_mod)",
 >  > options=QtGui.QFileDialog.DontUseNativeDialog )[0]
 >  >
 >  > //
 >  >
 >  > This is working for me now, not sure exactly why it is not
 > working with
 >  > native OSX dialog.
 >  >
 >  >
 >  > Cheers, Jose
 >  >
 >  >
 >  >
 >  >
 >  >
 >  >
 >  > ___
 >  > Mailing list: https://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] Dark Theme Fixups

[Simon Wells]

I have tested it on OSX with before and after here

http://s14.postimg.org/gf0kty89t/Untitled_1.png

I would prefer to see the top toolbar no longer based on the AUI as i think
it is unnecessary for that particular toolbar as it is not really one that
needs to be docked and undocked.

It this was to occur it would be able to use the native toolkits on each
operating system rather than what it is currently using, including on OSX
using the titlebar colour for the toolbar which is more natural on OSX

thanks

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

Re: [Kicad-developers] PATCH: To facilitate easier Via Curtain/Filling

[Wayne Stambaugh]

Sorry I didn't respond to this sooner but I've been busy.  I'm not
thrilled with this idea.  I know it solves the immediate problem but it
is an incomplete solution.  I would rather we do a complete free via
implementation and not introduce a stop gap measure into Pcbnew.  We've
discussed the idea of incorporating free vias many times in the past.
Since we are in a new development cycle, now is the time to revisit
this.  At a minimum this should include the following:

1) Board file format support for free vias.  Do we need to add any new
tokens to the board file format and where do we want to put the free
vias in the board file?  We need to define what capabilities our free
vias require and plan accordingly.  This will be a file format change so
we need to consider this carefully.

2) Editing tools (menu entries, toolbars, hot keys, dialogs, etc.) for
adding and editing free vias.  Our array tool could come in handy here.

3) Update DRC to handle free vias.

4) Verify support code still works.  I'm guessing we wont need to change
our plotting, printing, and/or export code since we already support
through hole, micro, and blind/buried vias (are there any other types of
vias?).

Please consider this instead of quick fixes.  This is one of the reasons
the KiCad code base is so crufty.  We need to start doing a better job
of looking at the big picture.

Cheers,

Wayne

On 12/14/2015 9:26 AM, Tomasz Wlostowski wrote:
> On 14.12.2015 14:40, Strontium wrote:
>> Hi Thomas,
>>
>> I considered this, but tracking zones is non trivial.
>>
>> For example, imagine the stackup:
>>
>> GND
>> VCC
>> GND
>> VCC
>>
>> A Through Via, from top to bottom could be connected validly connected
>> to either GND or VCC.
>>
>> Once the net is removed from the via by the reassignment pass, there is
>> no longer any information left to tell kicad which pair of zones was
>> connected by the via.
> 
> Indeed, in case of such a conflict retaining the via's net is IMHO the
> only good solution.
> 
>>
>> The approach I suggest will fix this problem, because it just wont
>> change the net for those vias.  It wont consider if there is a zone or
>> not, it just says "hey, you gave it the GND net, so i will leave it as
>> GND."
> 
> It also seems Altium is managing via's nets this way. I would vote for
> merging the patch.
> 
> Cheers,
> Tom
> 
>>
>>
>> On 14/12/15 21:21, Tomasz Wlostowski wrote:
>>> On 12.12.2015 02:41, Strontium wrote:
 This change should not break or modify any current behaviour, EXCEPT to
 retain the nets of tracks/vias which Kicad is otherwise incapable of
 determining automatically.
>>> Hi Steven,
>>>
>>> Thanks for the patch, it also (partially) fixes the via stitching issue
>>> many people have been complaining about. The origin of the problem is
>>> that the net propagation code does not take zones into account - so a
>>> via that is not connected to any pad with a chain of tracks is treated
>>> as disconnected.
>>>
>>> Adding zone support in the net calculation code should AFAIK fix this
>>> for good, but it may also require enhancing the DRC (so that it will
>>> report every object with no pad connection) and the 'clean tracks'
>>> tool code.
>>>
>>> Regards,
>>> Tom
>>>
>>
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] PATCH: To facilitate easier Via Curtain/Filling

[jp charras]

Le 15/12/2015 18:44, Tomasz Wlostowski a écrit :
> On 15.12.2015 16:52, Wayne Stambaugh wrote:
>> Sorry I didn't respond to this sooner but I've been busy.  I'm not
>> thrilled with this idea.  I know it solves the immediate problem but it
>> is an incomplete solution.
> 
> Hi Wayne,
> 
> I surely agree that changing just the net propagation algorithm is not
> enough, but I'm not sure adding support for free vias needs to go as far
> as changing the file format. Neither Eagle nor Altium (as far as I know)
> have a special notion of a free via. In the latter, any via or trace (or
> a free track) will retain its net unless:
> - the net is removed from the netlist,
> - new netcode is propagated from a pad through traces or vias and there
> is no conflict (= more than 1 netcode hitting the item after propagation).
> If the via is placed by the 'via' tool, it can also inherit its net from
> the underlying zone, but only if there's no net conflict. I believe this
> is more or less the behaviour of Steven's patch.
> 
> So IMHO, the minimum changes are:
> - keep the file format unmodified.
> - update the net propagation algorithm.
> - update the DRC to always report tracks/vias not connected to any pad
> (must take zone connections into account). Same for the 'cleanup' algorithm.
> - update orphan filled area removal code to take stitching vias into
> account.
> - add a via placement tool (quite trivial, like MODULE_TOOLS::PlacePad
> in the module editor)
> - update the existing GAL track/via properties dialog to allow assigning
> nets.
> - add Ben's RF patches & update array tool ;)
> 
> None of these changes has impact on the file format/data model, so
> hopefully they should not break anything and can be done incrementally.
> 
> Cheers,
> Tom

Stitching vias must be added, but also removed and edited (size, drill,
net name..) all in once.
Therefore they need a "link" (for instance a time stamp) to be removed

A good via placement tool in not "quite trivial", but feasible, obvioulsy.

The first work is not write code, but define how vias stitching are
managed (are they a group, and/or items inside a parent polygon like a
zone ...)

> 
>   I would rather we do a complete free via
>> implementation and not introduce a stop gap measure into Pcbnew.  We've
>> discussed the idea of incorporating free vias many times in the past.
>> Since we are in a new development cycle, now is the time to revisit
>> this.  At a minimum this should include the following:
>>
>> 1) Board file format support for free vias.  Do we need to add any new
>> tokens to the board file format and where do we want to put the free
>> vias in the board file?  We need to define what capabilities our free
>> vias require and plan accordingly.  This will be a file format change so
>> we need to consider this carefully.
>>
>> 2) Editing tools (menu entries, toolbars, hot keys, dialogs, etc.) for
>> adding and editing free vias.  Our array tool could come in handy here.
>>
>> 3) Update DRC to handle free vias.
>>
>> 4) Verify support code still works.  I'm guessing we wont need to change
>> our plotting, printing, and/or export code since we already support
>> through hole, micro, and blind/buried vias (are there any other types of
>> vias?).
>>
>> Please consider this instead of quick fixes.  This is one of the reasons
>> the KiCad code base is so crufty.  We need to start doing a better job
>> of looking at the big picture.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 12/14/2015 9:26 AM, Tomasz Wlostowski wrote:
>>> On 14.12.2015 14:40, Strontium wrote:
 Hi Thomas,

 I considered this, but tracking zones is non trivial.

 For example, imagine the stackup:

 GND
 VCC
 GND
 VCC

 A Through Via, from top to bottom could be connected validly connected
 to either GND or VCC.

 Once the net is removed from the via by the reassignment pass, there is
 no longer any information left to tell kicad which pair of zones was
 connected by the via.
>>>
>>> Indeed, in case of such a conflict retaining the via's net is IMHO the
>>> only good solution.
>>>

 The approach I suggest will fix this problem, because it just wont
 change the net for those vias.  It wont consider if there is a zone or
 not, it just says "hey, you gave it the GND net, so i will leave it as
 GND."
>>>
>>> It also seems Altium is managing via's nets this way. I would vote for
>>> merging the patch.
>>>
>>> Cheers,
>>> Tom
>>>


 On 14/12/15 21:21, Tomasz Wlostowski wrote:
> On 12.12.2015 02:41, Strontium wrote:
>> This change should not break or modify any current behaviour, EXCEPT to
>> retain the nets of tracks/vias which Kicad is otherwise incapable of
>> determining automatically.
> Hi Steven,
>
> Thanks for the patch, it also (partially) fixes the via stitching issue
> many people have been complaining about. The origin of the problem is
> that the net propagation 

Re: [Kicad-developers] [PATCH] some spelling fix

[FabienM]

Hi,

Here, the new version of the patch without internationalization.

Regards,
Fabien M
>From ae21504d94ade99f5e6fe40930de8765cb54623d Mon Sep 17 00:00:00 2001
From: Fabien Marteau 
Date: Tue, 15 Dec 2015 09:55:00 +0100
Subject: [PATCH] Some spelling fixies in README.txt

Signed-off-by: Fabien Marteau 
---
 README.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.txt b/README.txt
index 5a7fe27..ab05f75 100644
--- a/README.txt
+++ b/README.txt
@@ -11,9 +11,9 @@ CMakeList.txt   - CMAKE build tool script
 COPYRIGHT.txt   - A copy of the GNU General Public License Version 2
 CTestConfig.cmake   - Support for CTest and CDash testing tools
 Doxyfile- Doxygen config file for Kicad
-INSTALL.txt - The release (binairy) installation instructions
+INSTALL.txt - The release (binary) installation instructions
 TODO.txt- Todo list
-uncrustify.cfg  - Uncrustify config file for uncrustify sorces formatting tool
+uncrustify.cfg  - Uncrustify config file for uncrustify sources formatting tool
 
 Subdirectories
 --
-- 
2.1.4

___
Mailing list: https://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 V2 : Enhanced Python Shell

[Strontium]

Hi,

Yes I do.  But its a bit beyond the scope of this enhancement. However 
with this base enhancement in place, doing that should be easier.


For me, one of the biggest problems with the python scripting in KiCad, 
isn't that its not powerful enough, its that its largely undocumented.  
My hope is with this enhanced shell, introspection of what is exposed by 
kicad to python will be easier, and so it will be easier to experiment 
and add those kinds of features.


Steven.

On 15/12/15 16:52, easyw wrote:

Hi Steven,

do you think it would be useful/possible to add a way to launch a 
macro like in FreeCAD, choosing from a list?

https://bugs.launchpad.net/kicad/+bug/1526064
"Ability to assign shortcuts to run a specific script or adding 
toolbar buttons would be great!"


thank you for your improvements
Maurice

On 15/12/2015 09.03, Strontium wrote:

I attach an enhanced patch to the python shell.

This one is a bigger change than the previous patch.  But it moves the
code to the point where the whole shell is contained as an external
python file, which makes it a lot easier to develop and enhance.

Explanation of the changes:
- I created a "pcbnew/scripting/kicad_pyshell" directory to contain the
shell python code.  So i added the required installer directives.

- I don't need or use "scripting/python_console_frame.h" so all
reference to its removed from the code, but the file still exists in the
source tree.

- I changed the Bundled search path to be "scripting" not
"scripting/plugins". "plugins" is only one type of possible scripting
and also common to all 3 platforms, so its handled lower down. This
means its possible to have other types of "scripting". The directory it
produces is therefore just the scripting "bundled" search path, and
doesn't need to be over-ridden by the end user, as far as i can tell. So
I removed the comments about that being desirable.

- I removed the TODO comments, the way the code works now, there are a
bunch of default search paths added, some referencing the kicad install
path, some from the KICAD_PATH environment variable and some from the
users root directory and users kicad config directory.  Its also easily
possible for a user to add their own include paths, all they need to do
is add python code to a module in the search path to do it, and the
python interpreter will load that and execute it in the process of
initialising the plugins.  Note, these search paths are only possible
search paths, they dont get added if they dont exist.

- I modified LoadPlugins in kicadplugins.i to properly add all the
scripting paths, including plugin paths.

The full list of possible default search paths is now:
+# The Scripts bundled with Kicad:
+#   
+#   /plugins
+#
+# The Scripts relative to the Kicad environment variable search 
path:

+#   /scripting
+#   /scripting/plugins
+#
+# The Scripts relative to the Kicad Users configuration:
+#   /scripting
+#   /scripting/plugins
+#
+# And on Linux, extra paths relative to the home directory:
+#   ~/.kicad_plugins
+#   ~/.kicad/scripting
+#   ~/.kicad/scripting/plugins

And i include that as a comment in the code.

- I changed some names from PluginsPath to ScriptingPath to
make the parameters reflect their current use.

- I reduced the python code embedded within CreatePythonShellWindow to
the bare minimum, which eases maintenance, as further changes or
enhancements to the python shell are all in pure python.  I also renamed
it from pycrust_panel to pcbnew_shell to better reflect what it is.  Its
possible in future the shell wont be based on pycrust, there is no need
to do it, except that currently its already a dependency of Kicad and
easy enough to leverage.

It also seemed to make sense to refer it to pcbnew, where it is embedded
because i could imagine a time when eeschema has python scripting and
its own shell.  And, at that time both programs could share a lot of the
same python shell code.

Steven


___
Mailing list: https://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 V2 : Enhanced Python Shell

[easyw]

Hi Steven,

do you think it would be useful/possible to add a way to launch a macro 
like in FreeCAD, choosing from a list?

https://bugs.launchpad.net/kicad/+bug/1526064
"Ability to assign shortcuts to run a specific script or adding toolbar 
buttons would be great!"


thank you for your improvements
Maurice

On 15/12/2015 09.03, Strontium wrote:

I attach an enhanced patch to the python shell.

This one is a bigger change than the previous patch.  But it moves the
code to the point where the whole shell is contained as an external
python file, which makes it a lot easier to develop and enhance.

Explanation of the changes:
- I created a "pcbnew/scripting/kicad_pyshell" directory to contain the
shell python code.  So i added the required installer directives.

- I don't need or use "scripting/python_console_frame.h" so all
reference to its removed from the code, but the file still exists in the
source tree.

- I changed the Bundled search path to be "scripting" not
"scripting/plugins". "plugins" is only one type of possible scripting
and also common to all 3 platforms, so its handled lower down.  This
means its possible to have other types of "scripting". The directory it
produces is therefore just the scripting "bundled" search path, and
doesn't need to be over-ridden by the end user, as far as i can tell. So
I removed the comments about that being desirable.

- I removed the TODO comments, the way the code works now, there are a
bunch of default search paths added, some referencing the kicad install
path, some from the KICAD_PATH environment variable and some from the
users root directory and users kicad config directory.  Its also easily
possible for a user to add their own include paths, all they need to do
is add python code to a module in the search path to do it, and the
python interpreter will load that and execute it in the process of
initialising the plugins.  Note, these search paths are only possible
search paths, they dont get added if they dont exist.

- I modified LoadPlugins in kicadplugins.i to properly add all the
scripting paths, including plugin paths.

The full list of possible default search paths is now:
+# The Scripts bundled with Kicad:
+#   
+#   /plugins
+#
+# The Scripts relative to the Kicad environment variable search path:
+#   /scripting
+#   /scripting/plugins
+#
+# The Scripts relative to the Kicad Users configuration:
+#   /scripting
+#   /scripting/plugins
+#
+# And on Linux, extra paths relative to the home directory:
+#   ~/.kicad_plugins
+#   ~/.kicad/scripting
+#   ~/.kicad/scripting/plugins

And i include that as a comment in the code.

- I changed some names from PluginsPath to ScriptingPath to
make the parameters reflect their current use.

- I reduced the python code embedded within CreatePythonShellWindow to
the bare minimum, which eases maintenance, as further changes or
enhancements to the python shell are all in pure python.  I also renamed
it from pycrust_panel to pcbnew_shell to better reflect what it is.  Its
possible in future the shell wont be based on pycrust, there is no need
to do it, except that currently its already a dependency of Kicad and
easy enough to leverage.

It also seemed to make sense to refer it to pcbnew, where it is embedded
because i could imagine a time when eeschema has python scripting and
its own shell.  And, at that time both programs could share a lot of the
same python shell code.

Steven


___
Mailing list: https://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 V2 : Enhanced Python Shell

[Strontium]

I attach an enhanced patch to the python shell.

This one is a bigger change than the previous patch.  But it moves the 
code to the point where the whole shell is contained as an external 
python file, which makes it a lot easier to develop and enhance.


Explanation of the changes:
- I created a "pcbnew/scripting/kicad_pyshell" directory to contain the 
shell python code.  So i added the required installer directives.


- I don't need or use "scripting/python_console_frame.h" so all 
reference to its removed from the code, but the file still exists in the 
source tree.


- I changed the Bundled search path to be "scripting" not 
"scripting/plugins". "plugins" is only one type of possible scripting 
and also common to all 3 platforms, so its handled lower down.  This 
means its possible to have other types of "scripting". The directory it 
produces is therefore just the scripting "bundled" search path, and 
doesn't need to be over-ridden by the end user, as far as i can tell.  
So I removed the comments about that being desirable.


- I removed the TODO comments, the way the code works now, there are a 
bunch of default search paths added, some referencing the kicad install 
path, some from the KICAD_PATH environment variable and some from the 
users root directory and users kicad config directory.  Its also easily 
possible for a user to add their own include paths, all they need to do 
is add python code to a module in the search path to do it, and the 
python interpreter will load that and execute it in the process of 
initialising the plugins.  Note, these search paths are only possible 
search paths, they dont get added if they dont exist.


- I modified LoadPlugins in kicadplugins.i to properly add all the 
scripting paths, including plugin paths.


The full list of possible default search paths is now:
+# The Scripts bundled with Kicad:
+#   
+#   /plugins
+#
+# The Scripts relative to the Kicad environment variable search path:
+#   /scripting
+#   /scripting/plugins
+#
+# The Scripts relative to the Kicad Users configuration:
+#   /scripting
+#   /scripting/plugins
+#
+# And on Linux, extra paths relative to the home directory:
+#   ~/.kicad_plugins
+#   ~/.kicad/scripting
+#   ~/.kicad/scripting/plugins

And i include that as a comment in the code.

- I changed some names from PluginsPath to ScriptingPath to 
make the parameters reflect their current use.


- I reduced the python code embedded within CreatePythonShellWindow to 
the bare minimum, which eases maintenance, as further changes or 
enhancements to the python shell are all in pure python.  I also renamed 
it from pycrust_panel to pcbnew_shell to better reflect what it is.  Its 
possible in future the shell wont be based on pycrust, there is no need 
to do it, except that currently its already a dependency of Kicad and 
easy enough to leverage.


It also seemed to make sense to refer it to pcbnew, where it is embedded 
because i could imagine a time when eeschema has python scripting and 
its own shell.  And, at that time both programs could share a lot of the 
same python shell code.


Steven
=== modified file 'pcbnew/CMakeLists.txt'
--- pcbnew/CMakeLists.txt	2015-12-10 19:20:35 +
+++ pcbnew/CMakeLists.txt	2015-12-15 07:31:41 +
@@ -678,6 +678,12 @@
 DESTINATION ${KICAD_DATA}/scripting/plugins
 FILE_PERMISSIONS OWNER_EXECUTE OWNER_READ OWNER_WRITE GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ
 )
+
+# scripting python shell
+install( DIRECTORY ${PROJECT_SOURCE_DIR}/pcbnew/scripting/kicad_pyshell/
+DESTINATION ${KICAD_DATA}/scripting/kicad_pyshell
+FILE_PERMISSIONS OWNER_EXECUTE OWNER_READ OWNER_WRITE GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ
+)
 endif()
 
 if( KICAD_SCRIPTING_MODULES )

=== modified file 'pcbnew/pcbframe.cpp'
--- pcbnew/pcbframe.cpp	2015-11-29 06:56:27 +
+++ pcbnew/pcbframe.cpp	2015-12-15 07:30:47 +
@@ -70,8 +70,6 @@
 #include 
 #include 
 
-#include 
-
 #if defined(KICAD_SCRIPTING) || defined(KICAD_SCRIPTING_WXPYTHON)
 #include 
 #endif
@@ -980,9 +978,6 @@
 }
 
 
-wxSize PYTHON_CONSOLE_FRAME::m_frameSize;   ///< The size of the PYTHON_CONSOLE_FRAME frame, stored during a session
-wxPoint PYTHON_CONSOLE_FRAME::m_framePos;   ///< The position ofPYTHON_CONSOLE_FRAME  the frame, stored during a session
-
 void PCB_EDIT_FRAME::ScriptingConsoleEnableDisable( wxCommandEvent& aEvent )
 {
 
@@ -990,7 +985,7 @@
 bool pythonPanelShown = true;
 
 if( pythonPanelFrame == NULL )
-pythonPanelFrame = new PYTHON_CONSOLE_FRAME( this, pythonConsoleNameId() );
+pythonPanelFrame = CreatePythonShellWindow( this, pythonConsoleNameId() );
 else
 pythonPanelShown = ! pythonPanelFrame->IsShown();
 

=== modified file 'pcbnew/pcbnew.cpp'
--- pcbnew/pcbnew.cpp	2015-11-04 08:48:34 +
+++ pcbnew/pcbnew.cpp	2015-12-15 07:32:00 +
@@ -241,36 +241,26 @@
 }
 }
 

[Kicad-developers] Wikipedia information update

[Murat Ursavaş]

Hi,

I've seen yesterday that the information about Kicad on Wikipedia was 
quite outdated (The EDA comparison page). I've updated the 4.0.0 release 
information but there could be space for some improvement. As I don't 
count myself as a KiCad expert, maybe you guys can update some 
information there. Since there are tons of new and updated features in 
4.0.0.


Just a friendly reminder ;)

Cheers,

/// Murat Ursavas
___
Mailing list: https://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] commit 6377

[Mário Luzeiro]

Thanks for the commit JP, it was also on my todo list for a long time!
___
Mailing list: https://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] Eeschema: make field autoplace grid flexible with field height

[Chris Pavlina]

#6377 changed a bit in the vicinity of this patch, so here's an updated one to 
preempt any merge conflicts.

On Sun, Dec 13, 2015 at 12:53:53PM -0500, Chris Pavlina wrote:
> Okay, here's a patch to make the autoplacement grid for fields flexible, 
> so fields are positioned sanely when they have different heights. Just 
> finished this an hour ago, as opposed to the main autoplacement patch 
> which got months of testing, so somebody else might want to try this 
> out.
> 
> I'm going to prepare one more patch, to handle a slightly quirky field 
> placement in a specific arrangement with a long component symbol 
> sandwiched between wires. That should be it.
> 
> --
> Chris

> commit b8fdf66034c0028ae33a3d372937279919427916
> Author: Chris Pavlina 
> Date:   Sat Dec 12 16:29:19 2015 -0500
> 
> Make vertical autoplacement grid flexible
> 
> diff --git a/eeschema/autoplace_fields.cpp b/eeschema/autoplace_fields.cpp
> index 001127a..5849309 100644
> --- a/eeschema/autoplace_fields.cpp
> +++ b/eeschema/autoplace_fields.cpp
> @@ -63,9 +63,11 @@
>  #include 
>  #include 
>  
> -#define FIELD_V_SPACING 100
> +#define FIELD_PADDING 10// arbitrarily chosen for aesthetics
> +#define FIELD_PADDING_ALIGNED 18// aligns 50 mil text to a 100 mil grid
> +#define WIRE_V_SPACING 100
>  #define HPADDING 25
> -#define VPADDING 50
> +#define VPADDING 25
>  
>  /**
>   * Function round_n
> @@ -127,7 +129,7 @@ public:
>  Kiface().KifaceSettings()->Read( AUTOPLACE_ALIGN_KEY, 
> _align_to_grid, false );
>  
>  m_comp_bbox = m_component->GetBodyBoundingBox();
> -m_fbox_size = ComputeFBoxSize();
> +m_fbox_size = ComputeFBoxSize( /* aDynamic */ true );
>  
>  m_power_symbol = ! m_component->IsInNetlist();
>  
> @@ -143,17 +145,16 @@ public:
>   */
>  void DoAutoplace( bool aManual )
>  {
> +bool force_wire_spacing = false;
>  SIDE field_side = choose_side_for_fields( aManual );
>  wxPoint fbox_pos = field_box_placement( field_side );
>  EDA_RECT field_box( fbox_pos, m_fbox_size );
>  
>  if( aManual )
> -{
> -fbox_pos = fit_fields_between_wires( field_box, field_side );
> -field_box.SetOrigin( fbox_pos );
> -}
> +force_wire_spacing = fit_fields_between_wires( _box, 
> field_side );
>  
>  // Move the fields
> +int last_y_coord = field_box.GetTop();
>  for( int field_idx = 0; field_idx < m_fields.size(); ++field_idx )
>  {
>  SCH_FIELD* field = m_fields[field_idx];
> @@ -163,7 +164,7 @@ public:
>  
>  wxPoint pos(
>  field_horiz_placement( field, field_box ),
> -field_box.GetY() + (FIELD_V_SPACING * field_idx) );
> +field_vert_placement( field, field_box, _y_coord, 
> !force_wire_spacing ) );
>  
>  if( m_align_to_grid )
>  {
> @@ -179,29 +180,40 @@ public:
>  protected:
>  /**
>   * Compute and return the size of the fields' bounding box.
> + * @param aDynamic - if true, use dynamic spacing
>   */
> -wxSize ComputeFBoxSize()
> +wxSize ComputeFBoxSize( bool aDynamic )
>  {
>  int max_field_width = 0;
> +int total_height = 0;
> +
>  BOOST_FOREACH( SCH_FIELD* field, m_fields )
>  {
>  int field_width;
> +int field_height;
>  
>  if( m_component->GetTransform().y1 )
>  {
>  field->SetOrientation( TEXT_ORIENT_VERT );
> -field_width = field->GetBoundingBox().GetHeight();
>  }
>  else
>  {
>  field->SetOrientation( TEXT_ORIENT_HORIZ );
> -field_width = field->GetBoundingBox().GetWidth();
>  }
>  
> +field_width = field->GetBoundingBox().GetWidth();
> +field_height = field->GetBoundingBox().GetHeight();
> +
>  max_field_width = std::max( max_field_width, field_width );
> +
> +if( aDynamic )
> +total_height += field_height + get_field_padding();
> +else
> +total_height += WIRE_V_SPACING;
> +
>  }
>  
> -return wxSize( max_field_width, int( FIELD_V_SPACING * 
> (m_fields.size() - 1) ) );
> +return wxSize( max_field_width, total_height );
>  }
>  
>  
> @@ -519,16 +531,16 @@ protected:
>  /**
>   * Function fit_fields_between_wires
>   * Shift a field box up or down a bit to make the fields fit between 
> some wires.
> - * Returns the new position of the field bounding box.
> + * Returns true if a shift was made.
>   */
> -wxPoint fit_fields_between_wires( const EDA_RECT& aBox, SIDE aSide )
> +bool fit_fields_between_wires( EDA_RECT* aBox, SIDE aSide )
>  {
>  if( aSide != SIDE_TOP && aSide != SIDE_BOTTOM )
> -return aBox.GetPosition();
> + 

Re: [Kicad-developers] PATCH: To facilitate easier Via Curtain/Filling

[Tomasz Wlostowski]

On 15.12.2015 19:09, jp charras wrote:
> Le 15/12/2015 18:44, Tomasz Wlostowski a écrit :
>> On 15.12.2015 16:52, Wayne Stambaugh wrote:
>>> Sorry I didn't respond to this sooner but I've been busy.  I'm not
>>> thrilled with this idea.  I know it solves the immediate problem but it
>>> is an incomplete solution.
>>
>> Hi Wayne,
>>
>> I surely agree that changing just the net propagation algorithm is not
>> enough, but I'm not sure adding support for free vias needs to go as far
>> as changing the file format. Neither Eagle nor Altium (as far as I know)
>> have a special notion of a free via. In the latter, any via or trace (or
>> a free track) will retain its net unless:
>> - the net is removed from the netlist,
>> - new netcode is propagated from a pad through traces or vias and there
>> is no conflict (= more than 1 netcode hitting the item after propagation).
>> If the via is placed by the 'via' tool, it can also inherit its net from
>> the underlying zone, but only if there's no net conflict. I believe this
>> is more or less the behaviour of Steven's patch.
>>
>> So IMHO, the minimum changes are:
>> - keep the file format unmodified.
>> - update the net propagation algorithm.
>> - update the DRC to always report tracks/vias not connected to any pad
>> (must take zone connections into account). Same for the 'cleanup' algorithm.
>> - update orphan filled area removal code to take stitching vias into
>> account.
>> - add a via placement tool (quite trivial, like MODULE_TOOLS::PlacePad
>> in the module editor)
>> - update the existing GAL track/via properties dialog to allow assigning
>> nets.
>> - add Ben's RF patches & update array tool ;)
>>
>> None of these changes has impact on the file format/data model, so
>> hopefully they should not break anything and can be done incrementally.
>>
>> Cheers,
>> Tom
> 
> Stitching vias must be added, but also removed and edited (size, drill,
> net name..) all in once.
> Therefore they need a "link" (for instance a time stamp) to be removed
> 
> A good via placement tool in not "quite trivial", but feasible, obvioulsy.
> 
> The first work is not write code, but define how vias stitching are
> managed (are they a group, and/or items inside a parent polygon like a
> zone ...)

Hi Jean-Pierre,

I didn't mean any special vias for stitching purposes, but simply
allowing the user to draw lone vias and make them retain their nets.
This is a feature many people have been asking for and currently use
workarounds like [1] to achieve it.

Cheers,
Tom

[1]. https://forum.kicad.info/t/protip-nicer-via-stitching/1103

> 
>>
>>   I would rather we do a complete free via
>>> implementation and not introduce a stop gap measure into Pcbnew.  We've
>>> discussed the idea of incorporating free vias many times in the past.
>>> Since we are in a new development cycle, now is the time to revisit
>>> this.  At a minimum this should include the following:
>>>
>>> 1) Board file format support for free vias.  Do we need to add any new
>>> tokens to the board file format and where do we want to put the free
>>> vias in the board file?  We need to define what capabilities our free
>>> vias require and plan accordingly.  This will be a file format change so
>>> we need to consider this carefully.
>>>
>>> 2) Editing tools (menu entries, toolbars, hot keys, dialogs, etc.) for
>>> adding and editing free vias.  Our array tool could come in handy here.
>>>
>>> 3) Update DRC to handle free vias.
>>>
>>> 4) Verify support code still works.  I'm guessing we wont need to change
>>> our plotting, printing, and/or export code since we already support
>>> through hole, micro, and blind/buried vias (are there any other types of
>>> vias?).
>>>
>>> Please consider this instead of quick fixes.  This is one of the reasons
>>> the KiCad code base is so crufty.  We need to start doing a better job
>>> of looking at the big picture.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 12/14/2015 9:26 AM, Tomasz Wlostowski wrote:
 On 14.12.2015 14:40, Strontium wrote:
> Hi Thomas,
>
> I considered this, but tracking zones is non trivial.
>
> For example, imagine the stackup:
>
> GND
> VCC
> GND
> VCC
>
> A Through Via, from top to bottom could be connected validly connected
> to either GND or VCC.
>
> Once the net is removed from the via by the reassignment pass, there is
> no longer any information left to tell kicad which pair of zones was
> connected by the via.

 Indeed, in case of such a conflict retaining the via's net is IMHO the
 only good solution.

>
> The approach I suggest will fix this problem, because it just wont
> change the net for those vias.  It wont consider if there is a zone or
> not, it just says "hey, you gave it the GND net, so i will leave it as
> GND."

 It also seems Altium is managing via's nets this way. I would vote for
 merging the patch.

 Cheers,
 Tom

Re: [Kicad-developers] [PATCH] Dark Theme Fixups

[Simon Wells]

http://s14.postimg.org/rnvw70sr5/Screen_Shot_2015_12_16_at_08_02_19.png

Here is the main toolbar not as AUI on osx, as can be seen this uses the
native OSX toolbar so fits in better with other applications, The gradients
mainly seem to come from the AUI toolkit.

On Wed, Dec 16, 2015 at 6:08 AM, Simon Wells  wrote:

> I have tested it on OSX with before and after here
>
> http://s14.postimg.org/gf0kty89t/Untitled_1.png
>
> I would prefer to see the top toolbar no longer based on the AUI as i
> think it is unnecessary for that particular toolbar as it is not really one
> that needs to be docked and undocked.
>
> It this was to occur it would be able to use the native toolkits on each
> operating system rather than what it is currently using, including on OSX
> using the titlebar colour for the toolbar which is more natural on OSX
>
> thanks
>
> Simon
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] commit 6377

[Chris Pavlina]

Would have been nice, though, if the couple "miscellaneous" changes in 
that commit were done in _separate_ commits and _described_ rather than 
being silent. Would have been less of a WTF for me when something 
supposedly only touching pcbnew failed to merge in a branch only 
touching eeschema, at least.

Seriously people, we don't pay per commit.

On Tue, Dec 15, 2015 at 10:09:59PM +, Mário Luzeiro wrote:
> Thanks for the commit JP, it was also on my todo list for a long time!
> ___
> Mailing list: https://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] Library license update.

[Torsten Hüter]

Hi Wayne,

thank you very much for your efforts. I'm guessing that this is not an easy 
topic and takes thus more time. 
Hopefully a good solution can be found this way.

Maybe it makes then sense to announce this change on the KiCad homepage, I 
could also imagine to add a definition of the "audience" - just like on the 
FreeCad homepage. 

Quote from http://www.freecadweb.org/:

"[..] 
Who is FreeCAD for? A couple of user cases:
The home user/hobbyist. 
Got yourself a project you want to build, have built, or 3D printed? Model it 
in FreeCAD. No previous CAD experience required. Our community will help you 
get the hang of it quickly!

The experienced CAD user. 
If you use commercial CAD or BIM modeling software at work, you will find 
similar tools and workflow among the many 
workbenches[http://www.freecadweb.org/wiki/?title=Workbenches] of FreeCAD. 
[..]"

Thanks,
Torsten

>I just wanted to give everyone a heads up that I did not forget about
>our library license issue.  I sent a modified version of the gEDA symbol
>library (GPL font exception) to the FSF for comment on November 20.  I
>received a reply that they are looking at and will get back to me.  I'm
>not sure what is taking so long but as I'm not a lawyer, I would rather
>get some feedback before making it public.  As soon as I hear back from
>the FSF and we have an acceptable license, I will forward the license to
>the library and website devs.  Who knows, if I did a good enough job,
>maybe I can start my second career as lawyer. 

___
Mailing list: https://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: To facilitate easier Via Curtain/Filling

[Torsten Hüter]

Hi Wayne & Jean-Pierre,

 

please consider also my implementation, I've announced this already (April/August 2015) on the mailing list:

 

https://lists.launchpad.net/kicad-developers/msg19584.html

 

Now is the stable release finished and we can talk about this.

 

I'm using there pads for stitching because they offer some advantages. Just like Jean-Pierre has written I need meta-informations (the netname, a time stamp, the RefDes for erasing stitching vias, padstack informations like mask opening etc.).

 

The only unsupported feature is stitching of blind or burried vias, because there is AFAIK no layer concept for pads existing.

 

--

 

Ideally pcbnew would support free vias with meta informations, like Wayne has written.

 

However I could imagine as well, that simply the through hole pad code is used for this purpose and a top level entity (or component) contains these "stitching pads". For blind and burried vias a start and stop layer needs to be added to such pads as well.

 

Such special free vias should be pretty easy to manage by the python script.

 

Thanks,

Torsten

 



Stitching vias must be added, but also removed and edited (size, drill,
net name..) all in once.
Therefore they need a "link" (for instance a time stamp) to be removed

A good via placement tool in not "quite trivial", but feasible, obvioulsy.

The first work is not write code, but define how vias stitching are
managed (are they a group, and/or items inside a parent polygon like a
zone ...)

 


>
> I would rather we do a complete free via
>> implementation and not introduce a stop gap measure into Pcbnew. We've
>> discussed the idea of incorporating free vias many times in the past.
>> Since we are in a new development cycle, now is the time to revisit
>> this. At a minimum this should include the following:
>>
>> 1) Board file format support for free vias. Do we need to add any new
>> tokens to the board file format and where do we want to put the free
>> vias in the board file? We need to define what capabilities our free
>> vias require and plan accordingly. This will be a file format change so
>> we need to consider this carefully.
>>
>> 2) Editing tools (menu entries, toolbars, hot keys, dialogs, etc.) for
>> adding and editing free vias. Our array tool could come in handy here.
>>
>> 3) Update DRC to handle free vias.
>>
>> 4) Verify support code still works. I'm guessing we wont need to change
>> our plotting, printing, and/or export code since we already support
>> through hole, micro, and blind/buried vias (are there any other types of
>> vias?).
>>
>> Please consider this instead of quick fixes. This is one of the reasons
>> the KiCad code base is so crufty. We need to start doing a better job
>> of looking at the big picture.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 12/14/2015 9:26 AM, Tomasz Wlostowski wrote:
>>> On 14.12.2015 14:40, Strontium wrote:
 Hi Thomas,

 I considered this, but tracking zones is non trivial.

 For example, imagine the stackup:

 GND
 VCC
 GND
 VCC

 A Through Via, from top to bottom could be connected validly connected
 to either GND or VCC.

 Once the net is removed from the via by the reassignment pass, there is
 no longer any information left to tell kicad which pair of zones was
 connected by the via.
>>>
>>> Indeed, in case of such a conflict retaining the via's net is IMHO the
>>> only good solution.
>>>

 The approach I suggest will fix this problem, because it just wont
 change the net for those vias. It wont consider if there is a zone or
 not, it just says "hey, you gave it the GND net, so i will leave it as
 GND."
>>>
>>> It also seems Altium is managing via's nets this way. I would vote for
>>> merging the patch.
>>>
>>> Cheers,
>>> Tom
>>>


 On 14/12/15 21:21, Tomasz Wlostowski wrote:
> On 12.12.2015 02:41, Strontium wrote:
>> This change should not break or modify any current behaviour, EXCEPT to
>> retain the nets of tracks/vias which Kicad is otherwise incapable of
>> determining automatically.
> Hi Steven,
>
> Thanks for the patch, it also (partially) fixes the via stitching issue
> many people have been complaining about. The origin of the problem is
> that the net propagation code does not take zones into account - so a
> via that is not connected to any pad with a chain of tracks is treated
> as disconnected.
>
> Adding zone support in the net calculation code should AFAIK fix this
> for good, but it may also require enhancing the DRC (so that it will
> report every object with no pad connection) and the 'clean tracks'
> tool code.
>
> Regards,
> Tom


--
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] Layer Widget modifications

[Wayne Stambaugh]

On 12/15/2015 4:48 PM, Jon Neal wrote:
> It looks nicer in some ways, but I don't think I completely like it.
> 
> Two comments I have:
> 1. A little bit of whitespace in between each color block would make it
> look even nicer I think.

I don't like the square run on color buttons either.  I would like to
see something to distinguish one color button from another.  I do
however like the standard font instead of the really small font that is
bad for us old guys with less than perfect vision.

> 2. From this picture it is way, way less obvious that you can click on
> the color blocks to change their color. I am not a fan of that at all.
> Maybe there is some indication that could be added on mouseover? A light
> color change? Not sure
> 
> Jon
> 
> On Tue, Dec 15, 2015 at 4:07 PM Simon Wells  > wrote:
> 
> I am doing some modifications to the layer widget and was wanting
> some comments. Part of this is making it so that if you LEFT click
> on the colour button you get the colour selection dialog. Currently
> i believe this is very broken as you should not have a wxButton that
> does not behave as expected with a left click. 
> 
> There is plenty of real-estate on the row to click to make the row
> the current layer
> 
> http://postimg.org/image/az7os23x9/
> 
> In that screenshot the left is the current layer_widget screenshot
> and on the right is my currently modified one. This is currently
> broken on other operating systems due to being fixed height bitmap
> buttons but that is the next thing i will be working on as it will
> require some changes to how things are done.
> 
> Currently the code is set so that if the vertical resolution of the
> display is <= 900px then the text has a transformer done
> pointSize*8/10 as can be seen in the left hand version of the
> widget, however due to the icons in the right hand toolbar it seems
> unnecessary to bother with that when the window has to be fairly
> tall due to the icons anyway and the layer widget will be in a
> scrolled window
> 
> If anyone has any comments/critiques about how it looks/order please
> let me know, I am also considering making the rendering window look
> the aka the same spacing of the items as even though the icon is not
> in the rendering tab it still looks cleaner if similar components
> don't move horizontally between tabs in a notebook
> ___
> Mailing list: https://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] Dark Theme Fixups

[Simon Wells]

I would prefer to see all the applications get a native toolbar for their
main toolbar, I have only hacked it on in the kicad manager currently to
see whether it was popular at all. if not then i won't bother, however i
don't believe the dark patch to remove the gradient works very well on OSX
esspecially in the manager as then the toolbar has no division from the
rest of the window.


> Which top toolbar, kicad, eeschema, pcbnew?


On Wed, Dec 16, 2015 at 10:14 AM, Simon Wells  wrote:

> http://s14.postimg.org/rnvw70sr5/Screen_Shot_2015_12_16_at_08_02_19.png
>
> Here is the main toolbar not as AUI on osx, as can be seen this uses the
> native OSX toolbar so fits in better with other applications, The gradients
> mainly seem to come from the AUI toolkit.
>
> On Wed, Dec 16, 2015 at 6:08 AM, Simon Wells  wrote:
>
>> I have tested it on OSX with before and after here
>>
>> http://s14.postimg.org/gf0kty89t/Untitled_1.png
>>
>> I would prefer to see the top toolbar no longer based on the AUI as i
>> think it is unnecessary for that particular toolbar as it is not really one
>> that needs to be docked and undocked.
>>
>> It this was to occur it would be able to use the native toolkits on each
>> operating system rather than what it is currently using, including on OSX
>> using the titlebar colour for the toolbar which is more natural on OSX
>>
>> thanks
>>
>> Simon
>>
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Dark Theme Fixups

[Wayne Stambaugh]

Which top toolbar, kicad, eeschema, pcbnew?

On 12/15/2015 12:08 PM, Simon Wells wrote:
> I have tested it on OSX with before and after here
> 
> http://s14.postimg.org/gf0kty89t/Untitled_1.png
> 
> I would prefer to see the top toolbar no longer based on the AUI as i
> think it is unnecessary for that particular toolbar as it is not really
> one that needs to be docked and undocked.
> 
> It this was to occur it would be able to use the native toolkits on each
> operating system rather than what it is currently using, including on
> OSX using the titlebar colour for the toolbar which is more natural on OSX
> 
> thanks
> 
> 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] Library license update.

[Wayne Stambaugh]

On 12/15/2015 5:13 PM, "Torsten Hüter" wrote:
> 
> Hi Wayne,
> 
> thank you very much for your efforts. I'm guessing that this is not an easy 
> topic and takes thus more time. 
> Hopefully a good solution can be found this way.

As soon as I hear back from the FSF, I will forward the license to the
website devs for inclusion on our website and as part of the library repo.

> 
> Maybe it makes then sense to announce this change on the KiCad homepage, I 
> could also imagine to add a definition of the "audience" - just like on the 
> FreeCad homepage. 
> 
> Quote from http://www.freecadweb.org/:
> 
> "[..] 
> Who is FreeCAD for? A couple of user cases:
> The home user/hobbyist. 
> Got yourself a project you want to build, have built, or 3D printed? Model it 
> in FreeCAD. No previous CAD experience required. Our community will help you 
> get the hang of it quickly!
> 
> The experienced CAD user. 
> If you use commercial CAD or BIM modeling software at work, you will find 
> similar tools and workflow among the many 
> workbenches[http://www.freecadweb.org/wiki/?title=Workbenches] of FreeCAD. 
> [..]"
> 
> Thanks,
> Torsten
> 
>> I just wanted to give everyone a heads up that I did not forget about
>> our library license issue.  I sent a modified version of the gEDA symbol
>> library (GPL font exception) to the FSF for comment on November 20.  I
>> received a reply that they are looking at and will get back to me.  I'm
>> not sure what is taking so long but as I'm not a lawyer, I would rather
>> get some feedback before making it public.  As soon as I hear back from
>> the FSF and we have an acceptable license, I will forward the license to
>> the library and website devs.  Who knows, if I did a good enough job,
>> maybe I can start my second career as lawyer. 
> 
> ___
> Mailing list: https://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: To facilitate easier Via Curtain/Filling

[Wayne Stambaugh]

On 12/15/2015 12:44 PM, Tomasz Wlostowski wrote:
> On 15.12.2015 16:52, Wayne Stambaugh wrote:
>> Sorry I didn't respond to this sooner but I've been busy.  I'm not
>> thrilled with this idea.  I know it solves the immediate problem but it
>> is an incomplete solution.
> 
> Hi Wayne,
> 
> I surely agree that changing just the net propagation algorithm is not
> enough, but I'm not sure adding support for free vias needs to go as far
> as changing the file format. Neither Eagle nor Altium (as far as I know)
> have a special notion of a free via. In the latter, any via or trace (or
> a free track) will retain its net unless:

By free I mean not placed as part of a trace.

> - the net is removed from the netlist,
> - new netcode is propagated from a pad through traces or vias and there
> is no conflict (= more than 1 netcode hitting the item after propagation).
> If the via is placed by the 'via' tool, it can also inherit its net from
> the underlying zone, but only if there's no net conflict. I believe this
> is more or less the behaviour of Steven's patch.

How does the via's net name get set.  Is he assuming that it is whatever
two zones it is connecting.  What happens when a via crosses through
multiple sets of zones?  How does the user specify the correct via net name?

> 
> So IMHO, the minimum changes are:
> - keep the file format unmodified.

It does appear that a trace can be a single via so no changes to the
file format should be necessary.

> - update the net propagation algorithm.

I'm not sure what this is or why you would need it but OK.

> - update the DRC to always report tracks/vias not connected to any pad
> (must take zone connections into account). Same for the 'cleanup' algorithm.

I would do this first.  Otherwise users are going be upset when their
vias are cleaned up inadvertently.

> - update orphan filled area removal code to take stitching vias into
> account.

This would have to happen early on as well.

> - add a via placement tool (quite trivial, like MODULE_TOOLS::PlacePad
> in the module editor)

We should use drc checks to prevent vias from violating clearances as
well as vias that do no join two or more zones (when not part of a
trace) from being placed.

> - update the existing GAL track/via properties dialog to allow assigning
> nets.
> - add Ben's RF patches & update array tool ;)
> 
> None of these changes has impact on the file format/data model, so
> hopefully they should not break anything and can be done incrementally.
> 
> Cheers,
> Tom
> 
>   I would rather we do a complete free via
>> implementation and not introduce a stop gap measure into Pcbnew.  We've
>> discussed the idea of incorporating free vias many times in the past.
>> Since we are in a new development cycle, now is the time to revisit
>> this.  At a minimum this should include the following:
>>
>> 1) Board file format support for free vias.  Do we need to add any new
>> tokens to the board file format and where do we want to put the free
>> vias in the board file?  We need to define what capabilities our free
>> vias require and plan accordingly.  This will be a file format change so
>> we need to consider this carefully.
>>
>> 2) Editing tools (menu entries, toolbars, hot keys, dialogs, etc.) for
>> adding and editing free vias.  Our array tool could come in handy here.
>>
>> 3) Update DRC to handle free vias.
>>
>> 4) Verify support code still works.  I'm guessing we wont need to change
>> our plotting, printing, and/or export code since we already support
>> through hole, micro, and blind/buried vias (are there any other types of
>> vias?).
>>
>> Please consider this instead of quick fixes.  This is one of the reasons
>> the KiCad code base is so crufty.  We need to start doing a better job
>> of looking at the big picture.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 12/14/2015 9:26 AM, Tomasz Wlostowski wrote:
>>> On 14.12.2015 14:40, Strontium wrote:
 Hi Thomas,

 I considered this, but tracking zones is non trivial.

 For example, imagine the stackup:

 GND
 VCC
 GND
 VCC

 A Through Via, from top to bottom could be connected validly connected
 to either GND or VCC.

 Once the net is removed from the via by the reassignment pass, there is
 no longer any information left to tell kicad which pair of zones was
 connected by the via.
>>>
>>> Indeed, in case of such a conflict retaining the via's net is IMHO the
>>> only good solution.
>>>

 The approach I suggest will fix this problem, because it just wont
 change the net for those vias.  It wont consider if there is a zone or
 not, it just says "hey, you gave it the GND net, so i will leave it as
 GND."
>>>
>>> It also seems Altium is managing via's nets this way. I would vote for
>>> merging the patch.
>>>
>>> Cheers,
>>> Tom
>>>


 On 14/12/15 21:21, Tomasz Wlostowski wrote:
> On 12.12.2015 02:41, Strontium wrote:
>> This change should not break or 

[Kicad-developers] help with 3D normals

[Cirilo Bernardo]

Hi folks,

 I've added 3D per-vertex normal calculations to the 3D model plugins
but I'm calculating bad figures as seen in the *.wrl file below and a
corresponding render from view3dscene:

https://drive.google.com/file/d/0By_XTJN-s8aXX3pCeFhWbTZNYWs/view?usp=sharing

https://drive.google.com/file/d/0By_XTJN-s8aXSmNEMlhOblRlLUE/view?usp=sharing

Does anyone have some idea what I could be doing wrong to get such artefacts
in the image? I would like to fix my per-vertex normals calculation as it's
meant
to be a tool to help 3D plugin developers create normals lists in cases
where
the model does not provide the information.

- Cirilo
___
Mailing list: https://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] Dark Theme Fixups

[Maciej Sumiński]

Hi Windsor,

Thank you for the patch, I like the results. Personally, I would love to
have it merged, but we need to check if it does not break anything on
other platforms first.

Regards,
Orson

On 12/14/2015 04:42 AM, Windsor Schmidt wrote:
> Hi everyone,
> 
> This is my first post to the list, so please go easy on me. :D I have made a 
> couple of changes to improve the appearance of the GUI for users with dark 
> themes in Linux. A patch is attached.
> 
> * Removed toolbar gradient by adding wxAUI_TB_PLAIN_BACKGROUND to
>   wxAuiToolBar style (gradient is the default).
> 
> * Removed the white border from the main project tree view
>   by replacing style constant wxSW_3D with wxSW_3DSASH.
> 
> * Removed the white border from wxAui panes in KiCad manager,
>   pcbnew, and eeschema by calling PaneBorder( false ) on AUI panes.
> 
> Here are some screenshots from my Arch Linux desktop running bspwm (GTK2):
> 
> Dark theme from trunk: http://i.imgur.com/o1ueuVm.png
> Dark theme after fixups: http://i.imgur.com/TMdu8TF.png
> Light theme from trunk: http://i.imgur.com/MohCz76.png
> Light theme after fixups: http://i.imgur.com/Oj6Bi0F.png
> 
> NOTE: That third fixup involves a loop that runs before updating the wxAUI 
> manager. I duplicate this code in 3 places where the white border was most 
> prominent (toolbars in the manager, eeschema, and pcbnew). I assume this 
> routine could be centralized and called before any time the AUI manager is 
> updated, however I don't know the KiCad codebase well enough to approach this.
> 
> Thanks. KiCad rocks!
> 
> -Windsor
> 
> 
> 
> ___
> Mailing list: https://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] FreeCAD StepUp tools Openfile dialog issue on OSX

[easyw]

Hi Jose,

here is the solution for OSX:

1) add
import PySide
  just before (line 48 of StepUp tools 1.3.2.8)
from PySide import QtGui, QtCore
2) and change
name=QtGui.QFileDialog.getOpenFileName(self, "Open File...", 
last_file_path, "kicad module files (*.kicad_mod)")[0]

  (line 629,630 of StepUp tools 1.3.2.8)
  with
name, Filter = PySide.QtGui.QFileDialog.getOpenFileName(None,
"Open File...", last_file_path, "*.kicad_mod")

that should work on all platform with native dialog

If you could confirm me that is fine, I will update the tool on 
repository :)


thank you
Maurice

On 14/12/2015 20.56, Jose A. Saumell wrote:

No problem, thank you for the tools, I am working on a new board and
using the FreeCAD only workflow. Today created a PCB 3D model in step
which is really valuable!
Take care

On Mon, Dec 14, 2015 at 4:43 PM easyw > wrote:

Hi Jose,

I can reproduce it in OSX Lion, so I can debug :)

Thank you for reporting it and also for the solution-workaround you have
found!

keep in touch
Maurice :)

On 14/12/2015 16.43, Jose A. Saumell wrote:
 > Hi,
 >
 > I've ran into an issue whenever I had to use the StepUp tools on
Freecad
 > to open a footprint and do the alignment of 3D model.
 >
 > I would get an open file dialog but nothing would happen after
selecting
 > the .kicad_mod file.
 >
 > Inside kicad-StepUp-tools.FCMacro:
 > The name[0] variable would return an empty value.
 >
 > I worked around the problem by not using native OSX Open file dialog:
 > //
 >
 > name=QtGui.QFileDialog.getOpenFileName(self, 'Open file',
 > last_file_path,"kicad module files (*.kicad_mod)",
 > options=QtGui.QFileDialog.DontUseNativeDialog )[0]
 >
 > //
 >
 > This is working for me now, not sure exactly why it is not
working with
 > native OSX dialog.
 >
 >
 > Cheers, Jose
 >
 >
 >
 >
 >
 >
 > ___
 > Mailing list: https://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] Layer Widget modifications

[Simon Wells]

I am doing some modifications to the layer widget and was wanting some
comments. Part of this is making it so that if you LEFT click on the colour
button you get the colour selection dialog. Currently i believe this is
very broken as you should not have a wxButton that does not behave as
expected with a left click.

There is plenty of real-estate on the row to click to make the row the
current layer

http://postimg.org/image/az7os23x9/

In that screenshot the left is the current layer_widget screenshot and on
the right is my currently modified one. This is currently broken on other
operating systems due to being fixed height bitmap buttons but that is the
next thing i will be working on as it will require some changes to how
things are done.

Currently the code is set so that if the vertical resolution of the display
is <= 900px then the text has a transformer done pointSize*8/10 as can be
seen in the left hand version of the widget, however due to the icons in
the right hand toolbar it seems unnecessary to bother with that when the
window has to be fairly tall due to the icons anyway and the layer widget
will be in a scrolled window

If anyone has any comments/critiques about how it looks/order please let me
know, I am also considering making the rendering window look the aka the
same spacing of the items as even though the icon is not in the rendering
tab it still looks cleaner if similar components don't move horizontally
between tabs in a notebook
___
Mailing list: https://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] Layer Widget modifications

[Jon Neal]

It looks nicer in some ways, but I don't think I completely like it.

Two comments I have:
1. A little bit of whitespace in between each color block would make it
look even nicer I think.
2. From this picture it is way, way less obvious that you can click on the
color blocks to change their color. I am not a fan of that at all. Maybe
there is some indication that could be added on mouseover? A light color
change? Not sure

Jon

On Tue, Dec 15, 2015 at 4:07 PM Simon Wells  wrote:

> I am doing some modifications to the layer widget and was wanting some
> comments. Part of this is making it so that if you LEFT click on the colour
> button you get the colour selection dialog. Currently i believe this is
> very broken as you should not have a wxButton that does not behave as
> expected with a left click.
>
> There is plenty of real-estate on the row to click to make the row the
> current layer
>
> http://postimg.org/image/az7os23x9/
>
> In that screenshot the left is the current layer_widget screenshot and on
> the right is my currently modified one. This is currently broken on other
> operating systems due to being fixed height bitmap buttons but that is the
> next thing i will be working on as it will require some changes to how
> things are done.
>
> Currently the code is set so that if the vertical resolution of the
> display is <= 900px then the text has a transformer done pointSize*8/10 as
> can be seen in the left hand version of the widget, however due to the
> icons in the right hand toolbar it seems unnecessary to bother with that
> when the window has to be fairly tall due to the icons anyway and the layer
> widget will be in a scrolled window
>
> If anyone has any comments/critiques about how it looks/order please let
> me know, I am also considering making the rendering window look the aka the
> same spacing of the items as even though the icon is not in the rendering
> tab it still looks cleaner if similar components don't move horizontally
> between tabs in a notebook
> ___
> Mailing list: https://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: To facilitate easier Via Curtain/Filling

[Strontium]

Hi Wayne, Everyone,

This is the process now.  If you have a fill zone, and you start to lay 
a track within it, KiCad will assign that track/via to the net of the 
zone of the layer you are on.  AND, as a board Designer, that's exactly 
what you would expect. But then, following this design process, you 
press the DRC button.


All of a sudden the Track/Via you just laid in the fill zone, and which 
KiCad gave you a Net for, loses its net assignment, and becomes 
"unconnected".  Now the fill area flows around it, avoiding it by the 
distance of the fill clearance.


Its a case of Kicad Giving with one hand (the net from the fill) and 
then taking away with the other (net reassignment).  All my patch does, 
is align these so that once the net has been given by KiCad, it wont 
needlessly be taken away.  It might be reassigned because of a pad 
connection, but it wont otherwise be "lost".


This "misalignment" between the DRC Net reassignment and the laying 
code, causes multiple problems, on real boards:


1. If you do this, and it doesn't cause a DRC.  You may not notice it, 
because a "unconnected" track/via is not a DRC error or warning.  So the 
design intent of your board is thwarted, you may have fill planes now 
disconnected at certain points and not enough vias connecting them, 
disconnected islands of fill, etc.  This board goes to production, and 
is actually flawed. All because the designer ran "DRC" check before 
sending it AND there is nothing obvious to highlight the change KiCad 
made to the board, to the designer.  The only way to find them is a 
detailed visual inspection, after every DRC Check.


2. To work around point 1, you need need to criss cross your board with 
interconnecting tracks from pads with that net to the vias, so they keep 
their assignment.  This causes a problem that if you now edit, you have 
all of these tracks, which you are only using to keep nets assigned to 
your vias, making it very difficult to edit/relay, etc.  In many cases 
the nearest pad may be on the other side of the board, requiring you to 
manually lay a track to it.


OR Place a single pad component which simulates a VIA, but then you cant 
use microvias, and you need to now manage the "extra" components.


3. Changing vias/tracks to "unassigned" may introduce "DRC" errors on 
the board that weren't there before the DRC pass.  So, in effect, KiCad 
is actually generating these DRC errors with the DRC check Pass, they 
didn’t exist BEFORE the DRC check, but do after. Which, as a board 
designer, is surprising and off-putting.


Basically, and at its core, this patch makes the net reassignment code 
compatible with the code that lets you place a track/via on a fill plane 
and pick up its net.  Without it, its like KiCad telling you what you 
are doing while editing is OK.  But then changing its mind later.


And while my patch allows me to much more easily, manually, lay GND vias 
for filling, etc, its utility is not limited to "Via Curtains" or "Via 
Fills".  For example, you may simply want to put a few extra vias 
between two VCC planes to share the current load.  This patch makes that 
easy and consistent.


I can certainly understand the desire not to implement "quick fixes" 
that increase "cruftiness", I wouldn't want that either. And while this 
patch is small, I don't think this patch increases cruftiness but 
actually reduces cruftiness and makes the board design DRC process less 
surprising to a board designer and more consistent with the way the 
layout tools work.


Steven

___
Mailing list: https://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] (no subject)

[devel]

Yikes, guys, I have a repeatable crash in the EEschema library editor with
4.0.0 (downloaded from kicad-pcb.org) in OS X 10.11.2.

I cloned a part, and I went to edit it. I was able to change a couple of
the fields, but when I went to change the footprint in the Field
Properties dialog, Kicad crashes as soon as I press the "Assign Footprint"
button.

Here is the crash dump:

Process:   kicad [1336]
Path:  /Applications/Kicad/kicad.app/Contents/MacOS/kicad
Identifier:org.kicad-pcb.kicad
Version:   ??? (???)
Code Type: X86-64 (Native)
Parent Process:??? [1]
Responsible:   kicad [1336]
User ID:   501

Date/Time: 2015-12-15 19:11:33.926 -0700
OS Version:Mac OS X 10.11.2 (15C50)
Report Version:11
Anonymous UUID:D7CB354B-B328-BBD0-DB45-E2A977133B91


Time Awake Since Boot: 3800 seconds

System Integrity Protection: enabled

Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes:   0x0001, 0x
Exception Note:EXC_CORPSE_NOTIFY

Application Specific Information:
/Applications/Kicad/kicad.app/Contents/MacOS/../Frameworks/libpixman-1.0.dylib
Performing @selector(controlAction:) from sender wxNSButton 0x7fdeeb9b33b0

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libpixman-1.0.dylib 0x000113e1f20e
_pixman_setup_combiner_functions_32 + 1290
1   libpixman-1.0.dylib 0x000113e4e21f
_pixman_implementation_create_general + 31
2   libpixman-1.0.dylib 0x000113e4fe87
_pixman_choose_implementation + 11
3   libpixman-1.0.dylib 0x000113e10869 pixman_constructor + 
9
4   dyld0x7fff61bdbf2b
ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) +
265
5   dyld0x7fff61bdc0a4
ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
6   dyld0x7fff61bd86dd
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
unsigned int, ImageLoader::InitializerTimingList&,
ImageLoader::UninitedUpwards&) + 305
7   dyld0x7fff61bd8672
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
unsigned int, ImageLoader::InitializerTimingList&,
ImageLoader::UninitedUpwards&) + 198
8   dyld0x7fff61bd8672
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
unsigned int, ImageLoader::InitializerTimingList&,
ImageLoader::UninitedUpwards&) + 198
9   dyld0x7fff61bd8563
ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned
int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) +
127
10  dyld0x7fff61bd87d3
ImageLoader::runInitializers(ImageLoader::LinkContext const&,
ImageLoader::InitializerTimingList&) + 75
11  dyld0x7fff61bcdeb0
dyld::runInitializers(ImageLoader*) + 89
12  dyld0x7fff61bd5128 dlopen + 555
13  libdyld.dylib   0x7fff9634979c dlopen + 59
14  libwx_baseu-3.0.0.dylib 0x00010b5f917c
wxDynamicLibrary::RawLoad(wxString const&, int) + 156
15  libwx_baseu-3.0.0.dylib 0x00010b5017bc
wxDynamicLibrary::Load(wxString const&, int) + 348
16  org.kicad-pcb.kicad 0x00010a925b69
KIWAY::KiFACE(KIWAY::FACE_T, bool) + 185
17  org.kicad-pcb.kicad 0x00010a92626c
KIWAY::Player(FRAME_T, bool) + 172
18  _eeschema.kiface0x000112c2699e
DIALOG_EDIT_LIBENTRY_FIELDS_IN_LIB::showButtonHandler(wxCommandEvent&) +
174
19  libwx_baseu-3.0.0.dylib 0x00010b623862
wxEvtHandler::SearchDynamicEventTable(wxEvent&) + 178
20  libwx_baseu-3.0.0.dylib 0x00010b6235db
wxEvtHandler::ProcessEventLocally(wxEvent&) + 59
21  libwx_baseu-3.0.0.dylib 0x00010b6234eb
wxEvtHandler::ProcessEvent(wxEvent&) + 187
22  libwx_baseu-3.0.0.dylib 0x00010b6238ff
wxEvtHandler::SafelyProcessEvent(wxEvent&) + 15
23  libwx_osx_cocoau_core-3.0.0.dylib   0x00010addbb8e
wxButton::OSXHandleClicked(double) + 62
24  libsystem_trace.dylib   0x7fff9829a07a
_os_activity_initiate + 75
25  com.apple.AppKit0x7fff9123f51d -[NSApplication
sendAction:to:from:] + 460
26  com.apple.AppKit0x7fff91254486 -[NSControl
sendAction:to:] + 86
27  com.apple.AppKit0x7fff912543b0 __26-[NSCell
_sendActionFrom:]_block_invoke + 131
28  libsystem_trace.dylib   0x7fff9829a07a
_os_activity_initiate + 75
29  com.apple.AppKit0x7fff9125430d -[NSCell
_sendActionFrom:] + 144
30 

Re: [Kicad-developers] Crash in Library Editor, OS X 10.11.2, Kicad 4.0.0

[Adam Wolf]

Yes, this is a known issue.  Please try a nightly from 12/13 or later to
confirm it fixes the issue for you too.

Adam Wolf

On Tue, Dec 15, 2015 at 8:20 PM,  wrote:

> > Yikes, guys, I have a repeatable crash in the EEschema library editor
> with
> > 4.0.0 (downloaded from kicad-pcb.org) in OS X 10.11.2.
> >
> > I cloned a part, and I went to edit it. I was able to change a couple of
> > the fields, but when I went to change the footprint in the Field
> > Properties dialog, Kicad crashes as soon as I press the "Assign
> Footprint"
> > button.
> >
>
> OK, more on this. Kicad crashes in the same way when you try to run the
> PCB footprint editor from the project manager.
>
>
> ___
> Mailing list: https://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] Crash in Library Editor, OS X 10.11.2, Kicad 4.0.0

[Adam Wolf]

Great.  Sorry about this.

The fix will be in 4.0.1, any, erm, um, day now?  Soon!

Adam Wolf

On Tue, Dec 15, 2015 at 9:45 PM,  wrote:

> > Yes, this is a known issue.  Please try a nightly from 12/13 or later to
> > confirm it fixes the issue for you too.
> >
> > Adam Wolf
>
> Did that, and we're good. Thanks.
>
> -a
>
>
> > On Tue, Dec 15, 2015 at 8:20 PM,  wrote:
> >
> >> > Yikes, guys, I have a repeatable crash in the EEschema library editor
> >> with
> >> > 4.0.0 (downloaded from kicad-pcb.org) in OS X 10.11.2.
> >> >
> >> > I cloned a part, and I went to edit it. I was able to change a couple
> >> of
> >> > the fields, but when I went to change the footprint in the Field
> >> > Properties dialog, Kicad crashes as soon as I press the "Assign
> >> Footprint"
> >> > button.
> >> >
> >>
> >> OK, more on this. Kicad crashes in the same way when you try to run the
> >> PCB footprint editor from the project manager.
> >>
> >>
> >> ___
> >> Mailing list: https://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] Dark Theme Fixups

[Chris Pavlina]

If it counts for anything, I vote for this patch too. It's not /just/ an 
improvement for dark themes, I think it looks way nicer and more 
professional for the light themes too. I'd love to clean up those lumpy 
gradients :)

Unfortunately I don't have any other platforms at hand to test it on :(

On Tue, Dec 15, 2015 at 01:54:14PM +0100, Maciej Sumiński wrote:
> Hi Windsor,
> 
> Thank you for the patch, I like the results. Personally, I would love to
> have it merged, but we need to check if it does not break anything on
> other platforms first.
> 
> Regards,
> Orson
> 
> On 12/14/2015 04:42 AM, Windsor Schmidt wrote:
> > Hi everyone,
> > 
> > This is my first post to the list, so please go easy on me. :D I have made 
> > a couple of changes to improve the appearance of the GUI for users with 
> > dark themes in Linux. A patch is attached.
> > 
> > * Removed toolbar gradient by adding wxAUI_TB_PLAIN_BACKGROUND to
> >   wxAuiToolBar style (gradient is the default).
> > 
> > * Removed the white border from the main project tree view
> >   by replacing style constant wxSW_3D with wxSW_3DSASH.
> > 
> > * Removed the white border from wxAui panes in KiCad manager,
> >   pcbnew, and eeschema by calling PaneBorder( false ) on AUI panes.
> > 
> > Here are some screenshots from my Arch Linux desktop running bspwm (GTK2):
> > 
> > Dark theme from trunk: http://i.imgur.com/o1ueuVm.png
> > Dark theme after fixups: http://i.imgur.com/TMdu8TF.png
> > Light theme from trunk: http://i.imgur.com/MohCz76.png
> > Light theme after fixups: http://i.imgur.com/Oj6Bi0F.png
> > 
> > NOTE: That third fixup involves a loop that runs before updating the wxAUI 
> > manager. I duplicate this code in 3 places where the white border was most 
> > prominent (toolbars in the manager, eeschema, and pcbnew). I assume this 
> > routine could be centralized and called before any time the AUI manager is 
> > updated, however I don't know the KiCad codebase well enough to approach 
> > this.
> > 
> > Thanks. KiCad rocks!
> > 
> > -Windsor
> > 
> > 
> > 
> > ___
> > Mailing list: https://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