Re: [Kicad-developers] Hello & Questions to future Administration of Python Plugins

[easyw]

Hi Simon,

there is already a nice way to call python scripts in kicad through 
Action Plugin (available on dev build)

https://forum.kicad.info/t/howto-register-a-python-plugin-inside-pcbnew-tools-menu/5540
Improving python API would be just great!


I am a Researcher working in the areas of IC Design, (RF-) PCB Design
if you are interested in RF, there is also a branch of kicad that 
implemented some useful features you may interested in

https://github.com/bpkempke/kicad-source-mirror/tree/rf_merge
https://forum.kicad.info/t/rf-aspects-with-kicad/2802/2

BR
Maurice


___
Mailing list: https://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] BOM component table dialog (quasi-)modality in osx

[Wayne Stambaugh]

Hello Dan,

Welcome to the KiCad developer's mailing list and thank you for your
interest in contributing to KiCad.  We can always use another OSX
developer.  It's the one platform where we could use the extra help.

The modal dialog issue became a problem when we moved from a multiple
binary solution to a single binary solution.  The quasi-modal dialog
mode allows the main application to continue to receive events while
blocking events to the window that launched the dialog.  The problem is
if another modal dialog is launched from the quasi-modal dialog then the
same problem occurs.  I haven't tried to stack quasi-modal dialog calls
so I'm not sure what the outcome would be but in theory it should work
and would be a major improvement over what we have now.  The other
option is to go modeless but that requires a lot of manual intervention
between the window that launched the dialog and the dialog itself.  I
agree that the BOM editor should be launched as quasi-modal rather than
modal.   FYI, you really should be call EndQuasiModel from with the
dialog because you cannot know ahead of time how the dialog was
launched.  This is all handled correctly by the DIALOG_SHIM object close
event handler.  We still seem to have trouble understanding how to
properly close dialogs with wxWidgets.  Don't use the code in most of
the dialogs in KiCad as they are incorrect and are poor examples of how
to do it correctly.  There are a few that are correct and none of them
call either EndQuasiModal or EndModal or even handle the OK and/or
cancel button events.  They use TranferData{To,From}Window for updating
the data between the controls and the object storage.

Cheers,

Wayne


On 6/1/2017 4:47 PM, Dan Green wrote:
> Hi, 
> I’ve lurked this list for quite some time, and finally applied to join,
> so thank you for approving me. I hope I can make some contributions to
> this excellent project.
> 
> I use KiCAD in OSX 10.12 and noticed an issue with the recent BOM
> component table feature.
> When closing the dialog box, the main KiCAD windows and menus still
> behave as if a modal dialog box is still open: all menu items are
> greyed-out, and the windows don't respond to clicks or other events, and
> I have to kill the process from the OS.
> 
> After reading some explanations in the comments, I can’t say I fully
> grasp the issue, but when I try invoking and closing the dialog as
> QuasiModal, it seems to work. I don’t know if this breaks it for other
> OS’s or if it violates a UI policy, so please let me know if there’s a
> better way!
> 
> Attached is the simple hack I made.
> 
> thanks!
> 
> From 2253bec68af9b0b4ffc177bccc1325b4702ee084 Mon Sep 17 00:00:00 2001
> 
> From: danngreen 
> 
> Date: Thu, 1 Jun 2017 13:08:17 -0700
> 
> Subject: [PATCH] Made BOM editor dialog quasi modal
> 
> 
> ---
> 
>  eeschema/dialogs/dialog_bom_editor.cpp | 4 +++-
> 
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> 
> diff --git a/eeschema/dialogs/dialog_bom_editor.cpp
> b/eeschema/dialogs/dialog_bom_editor.cpp
> 
> index e5114e533..f1d9a9aee 100644
> 
> --- a/eeschema/dialogs/dialog_bom_editor.cpp
> 
> +++ b/eeschema/dialogs/dialog_bom_editor.cpp
> 
> @@ -44,7 +44,7 @@
> 
>  int InvokeDialogCreateBOMEditor( SCH_EDIT_FRAME* aCaller )
> 
>  {
> 
>  DIALOG_BOM_EDITOR dlg( aCaller );
> 
> -return dlg.ShowModal();
> 
> +return dlg.ShowQuasiModal();
> 
>  }
> 
>  
> 
>  DIALOG_BOM_EDITOR::DIALOG_BOM_EDITOR( SCH_EDIT_FRAME* parent ) :
> 
> @@ -129,6 +129,7 @@ bool DIALOG_BOM_EDITOR::CloseDialog()
> 
>  {
> 
>  if( !m_bom->HaveFieldsChanged() )
> 
>  {
> 
> +EndQuasiModal( wxID_CANCEL );
> 
>  Destroy();
> 
>  return true;
> 
>  }
> 
> @@ -146,6 +147,7 @@ bool DIALOG_BOM_EDITOR::CloseDialog()
> 
> break;
> 
>  }
> 
>  
> 
> +EndQuasiModal( wxID_CANCEL );
> 
>  Destroy();
> 
>  return true;
> 
>  }
> 
> -- 
> 
> 2.11.0
> 
> 
> 
> ___
> Mailing list: https://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] Hello & Questions to future Administration of Python Plugins

[Wayne Stambaugh]

Hello Simon,

Welcome to the KiCad developer's mailing list.  I apologize for not
replying sooner but my real job got in the way.  Thank you for you
interest in contributing to KiCad and watching the FOSDEM video.  It's
nice to know the effort that goes into producing them is not wasted.
Your proposal sounds ambitious.  There are other developers working on
various Python plugins so any useful additions to that ecosystem are
welcome.  I think Python plugins have the potential to make KiCad
extremely powerful.  I'm looking forward to your contributions.

Cheers,

Wayne

On 6/1/2017 2:01 PM, Simon Küppers wrote:
> Hi everyone,
> Thanks Wayne for approving me to the developers mailing list.
> I am very new to KiCAD (only heard of it some time ago) and just
> stumbled upon a
> Youtube Video of 2017 FOSDEM (I believe?) where Wayne presented the
> current state of KiCAD.
> As a result I had to see for myself and I am quite impressed of the
> development of KiCAD in the
> last years! Very impressive.
> 
> I am a Researcher working in the areas of IC Design, (RF-) PCB Design
> and I am also a quite
> realiable programmer (thats what I think anyway :-)). I am used to EAGLE
> CAD (from the oldern days)
> and Altium Designer (ugh..). For IC Design we use Cadence Virtuoso.
> 
> Now, what really kicks me off with KiCAD is the (still very early)
> Python support. In my opinion, it is definitely
> the right choice to pull some non-major functionality from the main
> KiCAD core and implement it into Python.
> Why? Simply because that way it is much easier for people to modify,
> tweak, extend and bugfix the KiCAD software,
> without having to study the KiCAD core. I want to be the living proof
> for this fact ;-)
> 
> I already have some ideas for pcbnew plugins. E.g. a Via-Fence Generator
> (select a line-segment in pcbnew, start
> generator and enjoy the vias to the left and right of the line). There
> is similar functionality in Altium, but it
> is very rudimentory and cannot be adjusted or tweaked very much. Also it
> is sometimes quite buggy resulting in non-ideal via
> placement and due to this we usually place those vias (with GCPW
> transmission lines for example) by hand...
> I think this would be a nice example of what non-proficient users could
> add to KiCAD without ever touching anything belonging
> to the KiCAD C++ core application (where the latter would not fit into
> my available spare time due to its complexity, sorry!)
> 
> Anyway, what I wanted to ask before even starting with the development
> is the following. I know the current status of the
> Python interface in pcbnew is very limited and "only" an interface
> generated by SWIG. So I guess there will be some
> heavy adjustments in the API in the future (which is fine with me).
> 
> Is it planned in the future to make plugins part of the KiCAD
> distribution (i.e. ship them within the distro packages?)?
> (Or do KiCAD users have to find a way for organizing a repository of
> KiCAD plugins?)
> If yes, is the correct place to discuss their development (and request
> features) in this mailing list? Or should the forums
> be used instead/at first?
> 
> I guess that is it for now. A big thanks to all the developers and
> especially the CERN folks. I put in a donation a few days ago :-)
> 
> Best Regards
> 
> ___
> Mailing list: https://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] kicad right click menu corrections and few icons corrections

[Thomas Kindler]

Hi José!

On 02.06.2017 17:05, José Ignacio wrote:
> The use of "..." for menu items that show a dialog with extra options
> necessary to perform the operation has been in Microsoft's UX guidelines and
> apple's HIG since time immemorial:
> 
> https://msdn.microsoft.com/en-us/library/dn742392.aspx#usingellipses
> 
> https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/2957-CH15-SW3
>
>  https://developer.gnome.org/hig/stable/writing-style.html.en#ellipses
> 
> It is a very well known and traditional convention and Kicad shouldn't break
> it. As the guidelines say, the ellipsis (...) is reserved for commands that
> need further input from the user to proceed,

Ok! Totally agree until here..

> showing a modal dialog shouldn't be enough to warrant adding the ellipsis
> (though I've seen several programs be ellipsis-happy and put it on everything
> that calls a dialog...)
>

.. but now I can't follow you.

What could be a more severe indicator of "needing further input" than showing a
/modal/ dialog box?

This is exactly what ellipses are about. They say "Click me, and I will force
you into modal interaction".

Modal interactions should be kept to a minimum.. most of the dialogs that KiCad
shows could be replaced by dockable object inspector windows (Which I think is
already on the roadmap for Version 6). Until then, ellipses should be used.

best regards,
Thomas

> On Fri, Jun 2, 2017 at 8:20 AM, Fabrizio Tappero  > wrote:
> 
> Hi JP,
> 
> thanks a lot!!
> 
> I am a little unsure about this "Save as..." three dots thing used every time
> the menu item takes you to a second window. but I will investigate about UI
> stuff a little.
> 
> cheers Fabrizio
> 
> 
> 
> 
> On Fri, Jun 2, 2017 at 12:44 PM, jp charras  > wrote:
> 
> Le 30/05/2017 à 14:54, Fabrizio Tappero a écrit :
>> Hello Wayne, In attachment you can find a good review of approx 30 icons
>> and a global simplification of approx 30 icons. I have also corrected some
>> menu labels.
>> 
>> Since there is a lot of corrected text that is very much related to 
>> English, it would be great if you could review it before submitting it. A 
>> not so fun work but I think it will make kicad a much better tool.
>> 
>> I think it would be recommendable to avoid "a" and "the" in button and
>> menu tooltips. So that it way easier to understand what the button or
>> tooltip is about. The use of singular plural is also inconsistent and I
>> tried to fix it. Please Wayne feel free to make any changes you think is
>> important.
>> 
>> I have also notices that several menus are a little inconstant. I will try 
>> work on it since I think the current kicad UI is very usable but it needs 
>> to be more consistent.
>> 
>> I have tried to fixed a lot of icons so that their meaning is more 
>> immediate to understand. I have as well started a process of
>> simplification of many redundant icons. I think it is important that we
>> begin simplifing the kicad icon set because at the moment is really too
>> large.
>> 
>> Here below a detailed description of the changes.
>> 
>> Cheers Fabrizio
> 
> 
> Hi Fabrizio,
> 
> I committed your icons. Thanks.
> 
> 
> -- Jean-Pierre CHARRAS
> 
> 
> 
> ___ Mailing list:
> https://launchpad.net/~kicad-developers 
>  Post to :
> kicad-developers@lists.launchpad.net 
>  Unsubscribe :
> https://launchpad.net/~kicad-developers 
>  More help   :
> https://help.launchpad.net/ListHelp 
> 
> 
> 
> 
> ___ Mailing list:
> https://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] kicad right click menu corrections and few icons corrections

[Fabrizio Tappero]

cheers Jose,
I will look into it and submit all necessary fix next week.

cheers
Fabrizio


On Fri, Jun 2, 2017 at 5:05 PM, José Ignacio  wrote:

> The use of "..." for menu items that show a dialog with extra options
> necessary to perform the operation has been in Microsoft's UX guidelines
> and apple's HIG since time immemorial:
>
> https://msdn.microsoft.com/en-us/library/dn742392.aspx#usingellipses
>
> https://developer.apple.com/library/content/documentation/
> UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//
> apple_ref/doc/uid/2957-CH15-SW3
>
> https://developer.gnome.org/hig/stable/writing-style.html.en#ellipses
>
> It is a very well known and traditional convention and Kicad shouldn't
> break it. As the guidelines say, the ellipsis (...) is reserved for
> commands that need further input from the user to proceed, showing a modal
> dialog shouldn't be enough to warrant adding the ellipsis (though I've seen
> several programs be ellipsis-happy and put it on everything that calls a
> dialog...)
>
> On Fri, Jun 2, 2017 at 8:20 AM, Fabrizio Tappero <
> fabrizio.tapp...@gmail.com> wrote:
>
>> Hi JP,
>>
>> thanks a lot!!
>>
>> I am a little unsure about this "Save as..." three dots thing used every
>> time the menu item takes you to a second window. but I will investigate
>> about UI stuff a little.
>>
>> cheers
>> Fabrizio
>>
>>
>>
>>
>> On Fri, Jun 2, 2017 at 12:44 PM, jp charras 
>> wrote:
>>
>>> Le 30/05/2017 à 14:54, Fabrizio Tappero a écrit :
>>> > Hello Wayne,
>>> > In attachment you can find a good review of approx 30 icons and a
>>> global
>>> > simplification of approx 30 icons.
>>> > I have also corrected some menu labels.
>>> >
>>> > Since there is a lot of corrected text that is very much related to
>>> > English, it would be great if you could review it before submitting
>>> it. A
>>> > not so fun work but I think it will make kicad a much better tool.
>>> >
>>> > I think it would be recommendable to avoid "a" and "the" in button and
>>> menu
>>> > tooltips. So that it way easier to understand what the button or
>>> tooltip is
>>> > about. The use of singular plural is also inconsistent and I tried to
>>> fix
>>> > it. Please Wayne feel free to make any changes you think is important.
>>> >
>>> > I have also notices that several menus are a little inconstant. I will
>>> try
>>> > work on it since I think the current kicad UI is very usable but it
>>> needs
>>> > to be more consistent.
>>> >
>>> > I have tried to fixed a lot of icons so that their meaning is more
>>> > immediate to understand. I have as well started a process of
>>> simplification
>>> > of many redundant icons. I think it is important that we begin
>>> simplifing
>>> > the kicad icon set because at the moment is really too large.
>>> >
>>> > Here below a detailed description of the changes.
>>> >
>>> > Cheers
>>> > Fabrizio
>>>
>>>
>>> Hi Fabrizio,
>>>
>>> I committed your icons.
>>> Thanks.
>>>
>>>
>>> --
>>> Jean-Pierre CHARRAS
>>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://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] kicad right click menu corrections and few icons corrections

[José Ignacio]

The use of "..." for menu items that show a dialog with extra options
necessary to perform the operation has been in Microsoft's UX guidelines
and apple's HIG since time immemorial:

https://msdn.microsoft.com/en-us/library/dn742392.aspx#usingellipses

https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/2957-CH15-SW3

https://developer.gnome.org/hig/stable/writing-style.html.en#ellipses

It is a very well known and traditional convention and Kicad shouldn't
break it. As the guidelines say, the ellipsis (...) is reserved for
commands that need further input from the user to proceed, showing a modal
dialog shouldn't be enough to warrant adding the ellipsis (though I've seen
several programs be ellipsis-happy and put it on everything that calls a
dialog...)

On Fri, Jun 2, 2017 at 8:20 AM, Fabrizio Tappero  wrote:

> Hi JP,
>
> thanks a lot!!
>
> I am a little unsure about this "Save as..." three dots thing used every
> time the menu item takes you to a second window. but I will investigate
> about UI stuff a little.
>
> cheers
> Fabrizio
>
>
>
>
> On Fri, Jun 2, 2017 at 12:44 PM, jp charras  wrote:
>
>> Le 30/05/2017 à 14:54, Fabrizio Tappero a écrit :
>> > Hello Wayne,
>> > In attachment you can find a good review of approx 30 icons and a global
>> > simplification of approx 30 icons.
>> > I have also corrected some menu labels.
>> >
>> > Since there is a lot of corrected text that is very much related to
>> > English, it would be great if you could review it before submitting it.
>> A
>> > not so fun work but I think it will make kicad a much better tool.
>> >
>> > I think it would be recommendable to avoid "a" and "the" in button and
>> menu
>> > tooltips. So that it way easier to understand what the button or
>> tooltip is
>> > about. The use of singular plural is also inconsistent and I tried to
>> fix
>> > it. Please Wayne feel free to make any changes you think is important.
>> >
>> > I have also notices that several menus are a little inconstant. I will
>> try
>> > work on it since I think the current kicad UI is very usable but it
>> needs
>> > to be more consistent.
>> >
>> > I have tried to fixed a lot of icons so that their meaning is more
>> > immediate to understand. I have as well started a process of
>> simplification
>> > of many redundant icons. I think it is important that we begin
>> simplifing
>> > the kicad icon set because at the moment is really too large.
>> >
>> > Here below a detailed description of the changes.
>> >
>> > Cheers
>> > Fabrizio
>>
>>
>> Hi Fabrizio,
>>
>> I committed your icons.
>> Thanks.
>>
>>
>> --
>> Jean-Pierre CHARRAS
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://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] kicad right click menu corrections and few icons corrections

[Fabrizio Tappero]

Hi JP,

thanks a lot!!

I am a little unsure about this "Save as..." three dots thing used every
time the menu item takes you to a second window. but I will investigate
about UI stuff a little.

cheers
Fabrizio




On Fri, Jun 2, 2017 at 12:44 PM, jp charras  wrote:

> Le 30/05/2017 à 14:54, Fabrizio Tappero a écrit :
> > Hello Wayne,
> > In attachment you can find a good review of approx 30 icons and a global
> > simplification of approx 30 icons.
> > I have also corrected some menu labels.
> >
> > Since there is a lot of corrected text that is very much related to
> > English, it would be great if you could review it before submitting it. A
> > not so fun work but I think it will make kicad a much better tool.
> >
> > I think it would be recommendable to avoid "a" and "the" in button and
> menu
> > tooltips. So that it way easier to understand what the button or tooltip
> is
> > about. The use of singular plural is also inconsistent and I tried to fix
> > it. Please Wayne feel free to make any changes you think is important.
> >
> > I have also notices that several menus are a little inconstant. I will
> try
> > work on it since I think the current kicad UI is very usable but it needs
> > to be more consistent.
> >
> > I have tried to fixed a lot of icons so that their meaning is more
> > immediate to understand. I have as well started a process of
> simplification
> > of many redundant icons. I think it is important that we begin simplifing
> > the kicad icon set because at the moment is really too large.
> >
> > Here below a detailed description of the changes.
> >
> > Cheers
> > Fabrizio
>
>
> Hi Fabrizio,
>
> I committed your icons.
> Thanks.
>
>
> --
> Jean-Pierre CHARRAS
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Hello & Questions to future Administration of Python Plugins

[Fabrizio Tappero]

Hi Simon,
footprint library components are not very problematic for me because there
are already
so many in the standard kicad lib. In that department I feel it would be
great to just add
aliases so that when some manufacturer decides that a diode SOD123 should
be called
XYZ I can just look for XYZ (in an hypotetical search window that does not
yet exist) and
I find the SOD123 which has XYZ as alias.

Nevertheless I love Altium footprint wizard even thogh I almost never
used it.

What takes some of my time is the schematic lib component generation that
cannot really
be automated. So Once I have created a new component I guess I could just
submit it to
some github repo to be vetted by kicad librarians.

The problem of the existance of a librarian is also a hard issue to
solve... maybe guys at
Nvidia will fix that problem with some AI stuff.

When I mentioned the F1, F2, F3 buttons liked to python script I meant
sometihng like this:
[image: Inline image 1]

An other really time consuming process is the filling up of the schematic
library component
parameters from the mouser webpage. god that is tedious.

cheers
Fabrizio



On Fri, Jun 2, 2017 at 12:36 PM, Simon Küppers <
simon.kuepp...@ruhr-uni-bochum.de> wrote:

> Hi Fabrizio,
>
> I spend long hours doing schematics at work and I love the idea of
>> implementing python stuff that could make my life easier. Specifically
>> I spend a long time in library component generation and I would love
>> to do something about it. This could be done by creating new python
>> (or non python) tools to import component info or to created tools to
>> facilitate the contribution to the quality (and size) of the kicad
>> lib. Not really sure what is best.
>>
>
> With regard to library generation I think the footprint generator is a
> good example
> of what even a "standard" user can achieve with available python scripting
> support.
> Imagine one wants to quickly add pin headers with N pins where N ranges
> from 4 to 64.
>
> Python scripts could be attached to F1, F2 and F3 general-purpose
>> buttons.
>>
>
> I did not check specifically, but I read somewhere that KiCad has
> something like a
> central point where shortcuts are set up right? In this case, executing a
> python script
> with a given name could be just another entry in this central
> configuration. This would
> allow maximum flexibility.
>
> However, you remind me of another thing and that is something like
> function call hooks.
> It would be really cool to have something like a python script that
> registers callback
> functions that are hooked to "pick up trace" and "drop trace" for example.
> Now with
> respect to the Via Fence generator and some clever coding, this could
> allow moving
> a trace with online rebuilding of the Via Fence when the trace is released
> again
> after moving. Just an idea!
>
> This people
>> would probably make kicad better. This would be classified as "kicad
>> user harvesting via python scripting for library component creation "
>> ;-) a topic I always wanted to talk about on this mailing list.
>>
>
> I second that. Could be really powerful to the overall development of the
> KiCad Software
>
> Best Regards
> 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] kicad right click menu corrections and few icons corrections

[jp charras]

Le 30/05/2017 à 14:54, Fabrizio Tappero a écrit :
> Hello Wayne,
> In attachment you can find a good review of approx 30 icons and a global
> simplification of approx 30 icons.
> I have also corrected some menu labels.
> 
> Since there is a lot of corrected text that is very much related to
> English, it would be great if you could review it before submitting it. A
> not so fun work but I think it will make kicad a much better tool.
> 
> I think it would be recommendable to avoid "a" and "the" in button and menu
> tooltips. So that it way easier to understand what the button or tooltip is
> about. The use of singular plural is also inconsistent and I tried to fix
> it. Please Wayne feel free to make any changes you think is important.
> 
> I have also notices that several menus are a little inconstant. I will try
> work on it since I think the current kicad UI is very usable but it needs
> to be more consistent.
> 
> I have tried to fixed a lot of icons so that their meaning is more
> immediate to understand. I have as well started a process of simplification
> of many redundant icons. I think it is important that we begin simplifing
> the kicad icon set because at the moment is really too large.
> 
> Here below a detailed description of the changes.
> 
> Cheers
> Fabrizio


Hi Fabrizio,

I committed your icons.
Thanks.


-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] Hello & Questions to future Administration of Python Plugins

[Simon Küppers]

Hi Fabrizio,


I spend long hours doing schematics at work and I love the idea of
implementing python stuff that could make my life easier. Specifically
I spend a long time in library component generation and I would love
to do something about it. This could be done by creating new python
(or non python) tools to import component info or to created tools to
facilitate the contribution to the quality (and size) of the kicad
lib. Not really sure what is best.


With regard to library generation I think the footprint generator is a 
good example
of what even a "standard" user can achieve with available python 
scripting support.
Imagine one wants to quickly add pin headers with N pins where N ranges 
from 4 to 64.



Python scripts could be attached to F1, F2 and F3 general-purpose
buttons.


I did not check specifically, but I read somewhere that KiCad has 
something like a
central point where shortcuts are set up right? In this case, executing 
a python script
with a given name could be just another entry in this central 
configuration. This would

allow maximum flexibility.

However, you remind me of another thing and that is something like 
function call hooks.
It would be really cool to have something like a python script that 
registers callback
functions that are hooked to "pick up trace" and "drop trace" for 
example. Now with
respect to the Via Fence generator and some clever coding, this could 
allow moving
a trace with online rebuilding of the Via Fence when the trace is 
released again

after moving. Just an idea!


This people
would probably make kicad better. This would be classified as "kicad
user harvesting via python scripting for library component creation "
;-) a topic I always wanted to talk about on this mailing list.


I second that. Could be really powerful to the overall development of 
the KiCad Software


Best Regards
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] Hello & Questions to future Administration of Python Plugins

[Oliver Walters]

Having Python more accessible to core KiCAD functionality would be a very
good improvement IMHO.

Another example - python DRC scripts. Instead of hard-coding DRC checks,
have a folder of DRC scripts that user can select / deselect. Or add extra
scripts if they want them.

On Fri, Jun 2, 2017 at 5:46 PM, Fabrizio Tappero  wrote:

> Hi Simon,
> welcome to the group!
>
> Reading your interesting email I decided to write to you. I am interested
> as well in the python functionality for the purpose of implementing killing
> functionalities. via-fence generator is certainly an interesting thing.
>
> I spend long hours doing schematics at work and I love the idea of
> implementing python stuff that could make my life easier. Specifically I
> spend a long time in library component generation and I would love to do
> something about it. This could be done by creating new python (or non
> python) tools to import component info or to created tools to facilitate
> the contribution to the quality (and size) of the kicad lib. Not really
> sure what is best.
>
> Python scripts could be attached to F1, F2 and F3 general-purpose buttons.
> So that others can easily use these scripts. This people would probably
> make kicad better. This would be classified as "kicad user harvesting via
> python scripting for library component creation " ;-) a topic I always
> wanted to talk about on this mailing list.
>
> Regarding your scripting database idea. Kicad comes with some script for
> BOM generation and I guess lead developers would certainly consider adding
> more scripts into the main kicad repo.
>
> Cheers
> Fabrizio
>
>
>
>
> On Thu, Jun 1, 2017 at 8:01 PM, Simon Küppers  bochum.de> wrote:
>
>> Hi everyone,
>> Thanks Wayne for approving me to the developers mailing list.
>> I am very new to KiCAD (only heard of it some time ago) and just stumbled
>> upon a
>> Youtube Video of 2017 FOSDEM (I believe?) where Wayne presented the
>> current state of KiCAD.
>> As a result I had to see for myself and I am quite impressed of the
>> development of KiCAD in the
>> last years! Very impressive.
>>
>> I am a Researcher working in the areas of IC Design, (RF-) PCB Design and
>> I am also a quite
>> realiable programmer (thats what I think anyway :-)). I am used to EAGLE
>> CAD (from the oldern days)
>> and Altium Designer (ugh..). For IC Design we use Cadence Virtuoso.
>>
>> Now, what really kicks me off with KiCAD is the (still very early) Python
>> support. In my opinion, it is definitely
>> the right choice to pull some non-major functionality from the main KiCAD
>> core and implement it into Python.
>> Why? Simply because that way it is much easier for people to modify,
>> tweak, extend and bugfix the KiCAD software,
>> without having to study the KiCAD core. I want to be the living proof for
>> this fact ;-)
>>
>> I already have some ideas for pcbnew plugins. E.g. a Via-Fence Generator
>> (select a line-segment in pcbnew, start
>> generator and enjoy the vias to the left and right of the line). There is
>> similar functionality in Altium, but it
>> is very rudimentory and cannot be adjusted or tweaked very much. Also it
>> is sometimes quite buggy resulting in non-ideal via
>> placement and due to this we usually place those vias (with GCPW
>> transmission lines for example) by hand...
>> I think this would be a nice example of what non-proficient users could
>> add to KiCAD without ever touching anything belonging
>> to the KiCAD C++ core application (where the latter would not fit into my
>> available spare time due to its complexity, sorry!)
>>
>> Anyway, what I wanted to ask before even starting with the development is
>> the following. I know the current status of the
>> Python interface in pcbnew is very limited and "only" an interface
>> generated by SWIG. So I guess there will be some
>> heavy adjustments in the API in the future (which is fine with me).
>>
>> Is it planned in the future to make plugins part of the KiCAD
>> distribution (i.e. ship them within the distro packages?)?
>> (Or do KiCAD users have to find a way for organizing a repository of
>> KiCAD plugins?)
>> If yes, is the correct place to discuss their development (and request
>> features) in this mailing list? Or should the forums
>> be used instead/at first?
>>
>> I guess that is it for now. A big thanks to all the developers and
>> especially the CERN folks. I put in a donation a few days ago :-)
>>
>> Best Regards
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : 

Re: [Kicad-developers] Hello & Questions to future Administration of Python Plugins

[Fabrizio Tappero]

Hi Simon,
welcome to the group!

Reading your interesting email I decided to write to you. I am interested
as well in the python functionality for the purpose of implementing killing
functionalities. via-fence generator is certainly an interesting thing.

I spend long hours doing schematics at work and I love the idea of
implementing python stuff that could make my life easier. Specifically I
spend a long time in library component generation and I would love to do
something about it. This could be done by creating new python (or non
python) tools to import component info or to created tools to facilitate
the contribution to the quality (and size) of the kicad lib. Not really
sure what is best.

Python scripts could be attached to F1, F2 and F3 general-purpose buttons.
So that others can easily use these scripts. This people would probably
make kicad better. This would be classified as "kicad user harvesting via
python scripting for library component creation " ;-) a topic I always
wanted to talk about on this mailing list.

Regarding your scripting database idea. Kicad comes with some script for
BOM generation and I guess lead developers would certainly consider adding
more scripts into the main kicad repo.

Cheers
Fabrizio




On Thu, Jun 1, 2017 at 8:01 PM, Simon Küppers <
simon.kuepp...@ruhr-uni-bochum.de> wrote:

> Hi everyone,
> Thanks Wayne for approving me to the developers mailing list.
> I am very new to KiCAD (only heard of it some time ago) and just stumbled
> upon a
> Youtube Video of 2017 FOSDEM (I believe?) where Wayne presented the
> current state of KiCAD.
> As a result I had to see for myself and I am quite impressed of the
> development of KiCAD in the
> last years! Very impressive.
>
> I am a Researcher working in the areas of IC Design, (RF-) PCB Design and
> I am also a quite
> realiable programmer (thats what I think anyway :-)). I am used to EAGLE
> CAD (from the oldern days)
> and Altium Designer (ugh..). For IC Design we use Cadence Virtuoso.
>
> Now, what really kicks me off with KiCAD is the (still very early) Python
> support. In my opinion, it is definitely
> the right choice to pull some non-major functionality from the main KiCAD
> core and implement it into Python.
> Why? Simply because that way it is much easier for people to modify,
> tweak, extend and bugfix the KiCAD software,
> without having to study the KiCAD core. I want to be the living proof for
> this fact ;-)
>
> I already have some ideas for pcbnew plugins. E.g. a Via-Fence Generator
> (select a line-segment in pcbnew, start
> generator and enjoy the vias to the left and right of the line). There is
> similar functionality in Altium, but it
> is very rudimentory and cannot be adjusted or tweaked very much. Also it
> is sometimes quite buggy resulting in non-ideal via
> placement and due to this we usually place those vias (with GCPW
> transmission lines for example) by hand...
> I think this would be a nice example of what non-proficient users could
> add to KiCAD without ever touching anything belonging
> to the KiCAD C++ core application (where the latter would not fit into my
> available spare time due to its complexity, sorry!)
>
> Anyway, what I wanted to ask before even starting with the development is
> the following. I know the current status of the
> Python interface in pcbnew is very limited and "only" an interface
> generated by SWIG. So I guess there will be some
> heavy adjustments in the API in the future (which is fine with me).
>
> Is it planned in the future to make plugins part of the KiCAD distribution
> (i.e. ship them within the distro packages?)?
> (Or do KiCAD users have to find a way for organizing a repository of KiCAD
> plugins?)
> If yes, is the correct place to discuss their development (and request
> features) in this mailing list? Or should the forums
> be used instead/at first?
>
> I guess that is it for now. A big thanks to all the developers and
> especially the CERN folks. I put in a donation a few days ago :-)
>
> Best Regards
>
> ___
> Mailing list: https://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