Re: [Kicad-developers] PATCH: OS X copy/close bug fix

[Bernhard Stegmaier]

Why do you think they are not going to fix it?
These two defects are still open and marked as “accepted defect”.
They maybe won’t fix it like your patch does and yes, nobody knows when they 
will fix it.
But it unfortunately is the same for many other OS X wxWidgets bugs… :(

Until then, your patch looks quite fine for being used in KiCad on OS X.

Moreover, as JP pointed out your first patch won’t work, because you changed 
generated code.
Doing the same in the source .fpb files would mean to change it for every 
platform.
That’s probably also not the way to go…


Regards,
Bernhard


> On 12 May 2016, at 00:46, Collin Anderson  wrote:
> 
> http://trac.wxwidgets.org/ticket/15678
> http://trac.wxwidgets.org/ticket/14953
> 
> They are not going to fix it, and the behavior is considered correct.  The 
> developer should not use the default names for various buttons that overlap 
> with system shortcuts and manually name them without the & if they conflict.  
> That's the consensus on the wx trac anyway.  
> 
> I submitted a patch that did exactly this, had KiCad manually set the button 
> names if being built for OS X (which was quite a number of buttons), but it 
> was suggested that we patch wx instead.  
> 
> It's one or the other.  This bug is very annoying.  Could we please settle on 
> a course of action? It isn't considered a bug by the wx developers so isn't 
> going to be fixed, so the only options available are work arounds, 
> unfortunately.
> 
> -- 
> "Violence is the last refuge of the incompetent." - Isaac Asimov
> 
>> On May 5, 2016, at 4:36 AM, Simon Wells  wrote:
>> 
>> the only issue i see with this patch is it seems to be working around
>> the problem rather than fixing it. Has this been fixed in wxwidgets
>> 3.1 if anyone knows?
>> 
>> Simon
>> 
>> On Thu, May 5, 2016 at 8:38 PM, Collin Anderson  
>> wrote:
>>> Another little OS X fix.  Most, though not all, of the dialogs in KiCad 
>>> that have cancel buttons break copy of text on OS X.  If you highlight text 
>>> (for example, the net of a pad, an operation I find myself doing fairly 
>>> often) and hit 'Command-C', the dialog is closed and the text is not 
>>> copied.  Command-C is not ever used in this way under OS X, it should and 
>>> is always intended to copy whatever is selected.
>>> 
>>> The problem stems from how many of the dialogues in KiCad are declaring 
>>> their cancel buttons.  If one declares a button with this constructor:
>>> 
>>> wxButton( this, wxID_CANCEL )
>>> 
>>> then the default name is filled in, which is "&Cancel".  The & is what 
>>> makes a button have a keyboard shortcut with the directly following letter 
>>> (C) in windows, but wx translates this to command- on OS X.  This 
>>> means any button with the name "&C> will break copy and paste on OS X 
>>> and simply trigger the button event stead.
>>> 
>>> I went through and fixed *every single button* in Kicad, such that the 
>>> code/behavior is completely unchanged on other platforms, but if __APPLE__ 
>>> is defined, it will explicitly name the button "Cancel" or "Close" as 
>>> opposed to "&Cancel" or "&Close" (both the automatic fill-ins if not 
>>> specified).  It's not pretty, but the only other option I can see is remove 
>>> the keyboard shortcut for the cancel and close buttons entirely, or at 
>>> least change them to a different letter, but that could potentially break 
>>> other people's workflows.
>>> 
>>> Here's the patch!
>>> 
>>> 
>>> 
>>> --
>>> "Violence is the last refuge of the incompetent." - Isaac Asimov
>>> 
>>> 
>>> ___
>>> Mailing list: https://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] Maximum undo items

[Chris Pavlina]

While we're discussing making an option config-file-only, do we have a
preferred place in developer documentation to list these sorts of things?

On Wed, May 11, 2016 at 02:50:10PM +0200, jp charras wrote:
> Le 11/05/2016 à 14:32, Wayne Stambaugh a écrit :
> > At a minimum I would leave the config file entry and the code to access
> > the config entries in place so you could manually modify the config file
> > for debugging purposes.  @JP, would that be acceptable to you?  I agree
> > that we should not expose debugging settings in the UI but I also
> > understand the need for development settings without having to create a
> > special build just to debug a specific section of code.
> 
> Yes, this is acceptable.
> 
> > 
> > On 5/10/2016 3:31 PM, Chris Pavlina wrote:
> >> Actually, you might be onto something. Of course you can FRO with the
> >> environment vars ;D but perhaps we could leave it an option to be set in 
> >> the
> >> configuration manually for the one time in 2018 JP wants to restrict this 
> >> for
> >> debugging...
> >>
> >> On Wed, May 11, 2016 at 06:58:58AM +1200, Simon Wells wrote:
> >>> or just make it so it always works but is either a command line
> >>> option/env variable or manually editing the configuration file
> >>>
> >>> On Wed, May 11, 2016 at 6:56 AM, Chris Pavlina  
> >>> wrote:
>  Urgh, do we really need to keep features that a developer may need at 
>  some
>  point in the future in the UI? This is something that one person may 
>  need once
>  sometime next year. Can't we make this a #define or something instead?
> 
>  We really shouldn't be cluttering everyone's UI with developer-only 
>  options.
> 
>  On Tue, May 10, 2016 at 08:54:05PM +0200, jp charras wrote:
> > Le 10/05/2016 à 20:41, Chris Pavlina a écrit :
> >> Back in August (git:aaadb40), I made the undo history infinite in 
> >> pcbnew,
> >> eeschema, modedit, and libedit. Wayne wanted this to remain an option, 
> >> in case
> >> of issues with the memory consumption of the undo stack. Currently, if 
> >> you set
> >> "Maximum undo items" to zero, you get infinite history. I also made it 
> >> default
> >> to unlimited.
> >>
> >> In the seven months since I did that, has anybody ever needed to limit 
> >> that?
> >> I've found the memory consumption caused by it to be quite minimal 
> >> even on very
> >> long layout sessions (I do not often shut my computer down other than 
> >> to
> >> install kernel updates and do not generally close things I'm working 
> >> on, so
> >> pcbnew can remain open for weeks at a time...).
> >>
> >> And if nobody has needed to change the limit, can I remove it to 
> >> reduce options
> >> clutter?
> >>
> >
> > Please, do not remove it.
> > For most of users, this option is not useful.
> >
> > However, developers need to be able to set the value (usually at a low 
> > value like 2 or 3) when the
> > undo/redo has an issue (usually related to object deletion), even in 
> > release mode.
> > Sometimes a crash can happen when objects in undo/redo list are 
> > deleted, if there is a bug in these
> > functions.
> >
> > --
> > Jean-Pierre CHARRAS
> 
> 
> 
> -- 
> Jean-Pierre CHARRAS
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

[Strontium]

The idea of passing the entire field list as a dictionary to a python 
"component" is the most "pythonic" way to do it. (IMHO)


It also means that its not really an "abuse" of the footprint field, 
just that there are 2 kinds of footprint libraries, static and dynamic.  
Dynamic footprints are python module (I think Dynamic footprints should 
ALL be python modules, not single files, and each component in the 
module should be an implementation of a component base class, with known 
methods).


Dynamic footprints should have a set of sensible defaults when no 
dictionary is passed, so that they can render acceptably in the 
footprint viewer.


With regard to caching PCB footprints,  I dont know why this is a 
problem?? it seems no different to placing a component on a PCB and then 
editing the footprint later.  Once the footprint is placed, it should be 
a static graphical object, like any other footprint.  It shouldn't 
update on the PCB unless the user tells it to.  BUT if it is more 
complex than that, could not the time-stamp be used for that?  The 
component could produce a unique hash, based ONLY on the parameters it 
uses, and that’s used in the time-stamp on the PCB.  Any change to the 
parameters would change the time-stamp and so could be used to indicate 
the component changed?


As far as the fields themselves and their validity, as the component 
footprint is dynamic and a python script, it could be called sanely from 
the DRC pass of both the schematic and PCB editor.  In the Schematic DRC 
check, it can verify the values of fields, and emit DRC errors/warning 
if any of them are wrong or badly formatted.  Same goes for PCB DRC 
checks.  This would not require specific changes to handle field formats 
in schematic/pcb but is just the ability to do custom DRC checks which 
would probably be required for dynamic components in any event.


And while we are at the topic of dynamic PCB components, would it not 
also make sense to dynamically generate the Schematic symbol for said 
component in exactly the same way?



On 12/05/16 00:33, Wayne Stambaugh wrote:

A standard format for the text of a given field is not the same thing as
adding code to the schematic editor to edit that field.  I do not want
to introduce code into the schematic editor for generating formatted
field text for external use.  This should be done within the current
field editor or an external text editor if you are so inclined.

All fields are saved in the netlist so the netlist format will not need
to be modified.


On 5/11/2016 11:46 AM, José Ignacio wrote:

If it's still too offensive, you could discard the naming part of my
proposal and just modify the netlist format so that eeschema passes
_all fields_ to pcbnew, that way the script can access them and do
whatever it wants. It would enable all sorts of powerful things in the
future, though it might complicate the "caching" behavior when
deciding whether to regenerate footprints or not.

On Wed, May 11, 2016 at 10:41 AM, José Ignacio  wrote:

It would not introduce a limitation, just a standard format that would
work with pcbnew footprint generators, external scripts can run
outside of kicad and use field names and values however they please.

On Wed, May 11, 2016 at 10:23 AM, Wayne Stambaugh  wrote:

On 5/11/2016 10:24 AM, José Ignacio wrote:

What about (ab)using the footprint field (actually the library plugin
system) for this? Say you add a new library plugin called "python",
each library would be a python module (either a single .py file or a
folder with an __init__.py script) That module will have a callable
for each "virtual" footprint. Those callables will take in a
dictionary of key-values and spit out a footprint object. The name of
the callable will be the base name of the footprint, say, Microwave.py
having a Microstrip(**args) will be called out as
Microwave:Microstrip.

To add parameters to the called footprint a dash "-" could be used as
the argument separator (as it is an illegal identifier for python
objects), with an underscore "_" to separate key and value. For
example a microstrip could be called out as
Microwave:Microstrip-W_10mil-L_50mil, which will cause pcbnew to load
Microwave.py and call Microstrip({'W': '10mil', 'L':'50mil'}) . This
allows for some neat things to happen without touching much code in
both eeschema and pcbnew. When the dimensions change in eeschema,
pcbnew will automatically try to fetch the new footprint (which will
call the script) but the rest will be left alone as they have the same
name. This will also allow using the existing footprint archival
facilities to save "baked in" copies of the generated footprints.

The text in a given field would be completely dependent on the script
that would use it.  Key/value pairs may or may not make sense depending
on the script.  The formatting of the field text should be left to the
script developer.  The schematic editor should have no say in the
formatting.


To make editing parameters 

Re: [Kicad-developers] PATCH: OS X copy/close bug fix

[Collin Anderson]

http://trac.wxwidgets.org/ticket/15678
http://trac.wxwidgets.org/ticket/14953

They are not going to fix it, and the behavior is considered correct.  The 
developer should not use the default names for various buttons that overlap 
with system shortcuts and manually name them without the & if they conflict.  
That's the consensus on the wx trac anyway.  

I submitted a patch that did exactly this, had KiCad manually set the button 
names if being built for OS X (which was quite a number of buttons), but it was 
suggested that we patch wx instead.  

It's one or the other.  This bug is very annoying.  Could we please settle on a 
course of action? It isn't considered a bug by the wx developers so isn't going 
to be fixed, so the only options available are work arounds, unfortunately.

-- 
"Violence is the last refuge of the incompetent." - Isaac Asimov

> On May 5, 2016, at 4:36 AM, Simon Wells  wrote:
> 
> the only issue i see with this patch is it seems to be working around
> the problem rather than fixing it. Has this been fixed in wxwidgets
> 3.1 if anyone knows?
> 
> Simon
> 
> On Thu, May 5, 2016 at 8:38 PM, Collin Anderson  
> wrote:
>> Another little OS X fix.  Most, though not all, of the dialogs in KiCad that 
>> have cancel buttons break copy of text on OS X.  If you highlight text (for 
>> example, the net of a pad, an operation I find myself doing fairly often) 
>> and hit 'Command-C', the dialog is closed and the text is not copied.  
>> Command-C is not ever used in this way under OS X, it should and is always 
>> intended to copy whatever is selected.
>> 
>> The problem stems from how many of the dialogues in KiCad are declaring 
>> their cancel buttons.  If one declares a button with this constructor:
>> 
>> wxButton( this, wxID_CANCEL )
>> 
>> then the default name is filled in, which is "&Cancel".  The & is what makes 
>> a button have a keyboard shortcut with the directly following letter (C) in 
>> windows, but wx translates this to command- on OS X.  This means any 
>> button with the name "&C> will break copy and paste on OS X and simply 
>> trigger the button event stead.
>> 
>> I went through and fixed *every single button* in Kicad, such that the 
>> code/behavior is completely unchanged on other platforms, but if __APPLE__ 
>> is defined, it will explicitly name the button "Cancel" or "Close" as 
>> opposed to "&Cancel" or "&Close" (both the automatic fill-ins if not 
>> specified).  It's not pretty, but the only other option I can see is remove 
>> the keyboard shortcut for the cancel and close buttons entirely, or at least 
>> change them to a different letter, but that could potentially break other 
>> people's workflows.
>> 
>> Here's the patch!
>> 
>> 
>> 
>> --
>> "Violence is the last refuge of the incompetent." - Isaac Asimov
>> 
>> 
>> ___
>> Mailing list: https://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] myBalsamiq UI mockups

[Chris Pavlina]

I'm going to send out a bunch of staff invites to frequent contributors
shortly. Anyone who contributes regularly and doesn't get one, make sure to
check your spam trap, and if there's still nothing just insult me for
forgetting you and I'll send one your way. :)

Staff access gives you the privilege to create new projects and invite external
participants to them. Also, once I finish configuring your accounts you will be
automatically added to new projects. The ability to edit the site itself and
add further staff is retained by the site owner, who is currently me and may be
Wayne in the near future.

I was wrong when I indicated you could ask other staff for membership; you can
ask project creators for membership in an individual sub-project but only the
owner can make you staff on the entire site.

On Wed, May 11, 2016 at 02:51:37PM -0400, Chris Pavlina wrote:
> Hi,
> 
> The lovely people of https://balsamiq.com/ have supported the KiCad project
> with a free subscription to the myBalsamiq UI mockup system. Hopefully this is
> a tool that we can make use of in the near future to improve our UI design
> process.
> 
> Our subdomain is: https://kicad.mybalsamiq.com/
> 
> All users can see content that has been marked public; currently I only have a
> quick test project up. Any developers who want edit access can contact me, or
> in the near future, Wayne or any other future site staff. Projects can also be
> set to allow the anonymous public to comment; I will probably do this by
> default for most things to allow all developers access whether they've
> requested it or not.
> 
> Wayne, I'm currently set up as the site 'owner', but will happily transfer to
> you if you like, or if you'd rather not muck around with it I'll happily 
> manage
> it for you. Either way, if you create an account I'll obviously make you a 
> full
> admin. :)
> 
> -- 
> Chris

___
Mailing list: https://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] myBalsamiq UI mockups

[Wayne Stambaugh]

Chris,

I created a user account.  You probably should give me admin access just
as a backup.  I have admin access for most of the other parts of the
project.  Thanks for setting this up.

Cheers,

Wayne

On 5/11/2016 2:51 PM, Chris Pavlina wrote:
> Hi,
> 
> The lovely people of https://balsamiq.com/ have supported the KiCad project
> with a free subscription to the myBalsamiq UI mockup system. Hopefully this is
> a tool that we can make use of in the near future to improve our UI design
> process.
> 
> Our subdomain is: https://kicad.mybalsamiq.com/
> 
> All users can see content that has been marked public; currently I only have a
> quick test project up. Any developers who want edit access can contact me, or
> in the near future, Wayne or any other future site staff. Projects can also be
> set to allow the anonymous public to comment; I will probably do this by
> default for most things to allow all developers access whether they've
> requested it or not.
> 
> Wayne, I'm currently set up as the site 'owner', but will happily transfer to
> you if you like, or if you'd rather not muck around with it I'll happily 
> manage
> it for you. Either way, if you create an account I'll obviously make you a 
> full
> admin. :)
> 

___
Mailing list: https://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 support to remote libraries with sftp

[Wayne Stambaugh]

Patrick,

I'm not sure your patch is necessary.  Did you try adding /gvfs/sftp to
your component library search list?  Eeschema should be able to search
any valid path in the list of library search paths for component library
files.

I don't know how long you've been following the dev mailing list but
your patch will be obsoleted during the current development cycle once
the new schematic and component library file formats are implemented.
The search path concept is going away because it is inherently broken
and will be replace with a look up table similar in scope to the
footprint library table.  Changing this code is not going to happen
because it will only complicate the transition to the new file format.

Cheers,

Wayne

On 5/11/2016 2:41 PM, Pereira, Patrick wrote:
> Hello,
> 
> This patch is a correction to Eeschema to use properly sftp to open
> remote libraries.
> 
> 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

[Kicad-developers] myBalsamiq UI mockups

[Chris Pavlina]

Hi,

The lovely people of https://balsamiq.com/ have supported the KiCad project
with a free subscription to the myBalsamiq UI mockup system. Hopefully this is
a tool that we can make use of in the near future to improve our UI design
process.

Our subdomain is: https://kicad.mybalsamiq.com/

All users can see content that has been marked public; currently I only have a
quick test project up. Any developers who want edit access can contact me, or
in the near future, Wayne or any other future site staff. Projects can also be
set to allow the anonymous public to comment; I will probably do this by
default for most things to allow all developers access whether they've
requested it or not.

Wayne, I'm currently set up as the site 'owner', but will happily transfer to
you if you like, or if you'd rather not muck around with it I'll happily manage
it for you. Either way, if you create an account I'll obviously make you a full
admin. :)

-- 
Chris

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

[Kicad-developers] [PATCH] Eeschema support to remote libraries with sftp

[Pereira, Patrick]

Hello,

This patch is a correction to Eeschema to use properly sftp to open
remote libraries.

Best regards,From 5888f08e096a7a0236129eb01cdccab4b93c2b63 Mon Sep 17 00:00:00 2001
From: "Patrick J.P" 
Date: Wed, 11 May 2016 15:20:09 -0300
Subject: [PATCH] Eeschema support to remote libraries access

Allow remote libraries access when using sftp in Eeschema.

Signed-off-by: Patrick J.P 
---
 common/search_stack.cpp| 16 +---
 eeschema/class_library.cpp | 20 +++-
 2 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/common/search_stack.cpp b/common/search_stack.cpp
index 9982f41..cc7eb02 100644
--- a/common/search_stack.cpp
+++ b/common/search_stack.cpp
@@ -38,11 +38,23 @@ int SEARCH_STACK::Split( wxArrayString* aResult, const wxString aPathString )
 {
 wxStringTokenizer   tokenizer( aPathString, PATH_SEPS, wxTOKEN_STRTOK );
 
+wxString temp;
+temp.Clear();
 while( tokenizer.HasMoreTokens() )
 {
 wxString path = tokenizer.GetNextToken();
+if( !temp.IsEmpty() )
+{
+path=temp+":"+path;
+temp.Clear();
+}
 
-aResult->Add( path );
+if( !path.Contains("/gvfs/sftp") )
+aResult->Add( path );
+else
+{
+temp = path;
+}
 }
 
 return aResult->GetCount();
@@ -118,7 +130,6 @@ void SEARCH_STACK::AddPaths( const wxString& aPaths, int aIndex )
 {
 boolisCS = wxFileName::IsCaseSensitive();
 wxArrayString   paths;
-
 Split( &paths, aPaths );
 
 // appending all of them, on large or negative aIndex
@@ -127,7 +138,6 @@ void SEARCH_STACK::AddPaths( const wxString& aPaths, int aIndex )
 for( unsigned i=0; iSchSearchS();
 
 #if defined(DEBUG) && 1
@@ -1132,11 +1132,7 @@ void PART_LIBS::LoadAllLibraries( PROJECT* aProject ) throw( IO_ERROR, boost::ba
 filename = lib_search->FindValidPath( fn.GetFullPath() );
 
 if( !filename )
-{
-libs_not_found += fn.GetName();
-libs_not_found += wxT( '\n' );
-continue;
-}
+filename = aProject->GetProjectPath() + fn.GetFullPath();
 }
 else
 {
@@ -1149,14 +1145,16 @@ void PART_LIBS::LoadAllLibraries( PROJECT* aProject ) throw( IO_ERROR, boost::ba
 }
 catch( const IO_ERROR& ioe )
 {
-wxString msg = wxString::Format( _(
-"Part library '%s' failed to load. Error:\n"
+libs_not_found_error += wxString::Format( _(
+"Part library '%s' : '%s' failed to load. Error:\n"
 "%s" ),
 GetChars( filename ),
+GetChars( fn.GetName() ),
 GetChars( ioe.errorText )
 );
 
-THROW_IO_ERROR( msg );
+libs_not_found += fn.GetName();
+libs_not_found += wxT( '\n' );
 }
 }
 
@@ -1197,6 +1195,10 @@ void PART_LIBS::LoadAllLibraries( PROJECT* aProject ) throw( IO_ERROR, boost::ba
 printf( "%s: lib_names:\n", __func__ );
 
 for( PART_LIBS::const_iterator it = begin(); it < end(); ++it )
+{
 printf( " %s\n", TO_UTF8( it->GetName() ) );
+}
+
+printf(" %s ", TO_UTF8( libs_not_found_error ) );
 #endif
 }
-- 
2.8.2

___
Mailing list: https://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] Build failed in Jenkins: KiCad (Linux, all options, Debug) #1251

[Wayne Stambaugh]

Nick,

Many thanks for getting this back up and running!

Cheers,

Wayne

On 5/11/2016 2:29 PM, Nick Østergaard wrote:
> Jenkins operations should now be back to normal. The main build is
> green, time will show if it will trigger on new commits properly.
> 
> 2016-05-11 18:46 GMT+02:00 Nick Østergaard :
>> Ahh yeah, we were messing about with that some time ago. :)
>>
>> 2016-05-11 17:38 GMT+02:00 Jon Neal :
>>> The issue is because the master jenkins node doesn't support c++11. I'm
>>> wondering if we should lay out a plan to upgrade the jenkins server since it
>>> is so out of date (some of our other scripts can't run on it due to things
>>> like git being 5 or 6 years out of date).
>>>
>>> We've also started getting lots of gateway timeout errors lately which makes
>>> things difficult. I can't actually update the jenkins main config any more
>>> due to this.
>>>
>>> On Wed, May 11, 2016 at 11:31 AM Nick Østergaard  wrote:

 Something is wonky with the jenkins master. I will give it a look when i
 get home. It seems to not have built for a month on the lp:kicad branch.

> 
> 
> ___
> Mailing list: https://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] Build failed in Jenkins: KiCad (Linux, all options, Debug) #1251

[Nick Østergaard]

Jenkins operations should now be back to normal. The main build is
green, time will show if it will trigger on new commits properly.

2016-05-11 18:46 GMT+02:00 Nick Østergaard :
> Ahh yeah, we were messing about with that some time ago. :)
>
> 2016-05-11 17:38 GMT+02:00 Jon Neal :
>> The issue is because the master jenkins node doesn't support c++11. I'm
>> wondering if we should lay out a plan to upgrade the jenkins server since it
>> is so out of date (some of our other scripts can't run on it due to things
>> like git being 5 or 6 years out of date).
>>
>> We've also started getting lots of gateway timeout errors lately which makes
>> things difficult. I can't actually update the jenkins main config any more
>> due to this.
>>
>> On Wed, May 11, 2016 at 11:31 AM Nick Østergaard  wrote:
>>>
>>> Something is wonky with the jenkins master. I will give it a look when i
>>> get home. It seems to not have built for a month on the lp:kicad branch.
>>>


___
Mailing list: https://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] Maker Faire SF KiCad Presentation

[Adam Wolf]

To those who are going to be at the Bay Area Maker Faire next next weekend,
the presentation is


*KiCad: Open Source Electronic Design Software*Make: Electronics
Sunday 5/22/16
11:30 AM - 11:55 AM (PDT)

If you're on the list, there won't be anything useful in the presentation
for you :), but last year we had a good group of folks discussing stuff
afterwards.

Adam Wolf

On Mon, May 9, 2016 at 10:18 AM, Adam Wolf 
wrote:

> Thanks!
>
> Adam Wolf
>
> On Mon, May 9, 2016 at 9:26 AM, Wayne Stambaugh 
> wrote:
>
>> Hey Adam,
>>
>> Thank you for representing KiCad at Maker Faire SF.  I wish I could join
>> you.  Maybe one of these years I'll be able to make it.
>>
>> Take a look at the version 5 road map[1] for ideas on what the goals are
>> for the next stable release.  Please keep in mind that this is the goal,
>> what actually will get implemented remains to be seen.  As for the
>> user-facing Eeschema changes, we hope to GALify (at least an initial
>> pass) and get the new file format implemented which will change the
>> library management code more along the lines of the Pcbnew.  Maybe we
>> will get few features like gate/pin swap implemented and don't forget
>> Tom's board update feature (no intermediate netlist file required).
>> Feel free to borrow any of my 2016 FOSDEM presentation if it helps.  It
>> should be available on the FOSDEM website.  If not, let me know and I
>> can send you a copy of it.
>>
>> Cheers,
>>
>> Wayne
>>
>> [1]:
>>
>> http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/v5_road_map.html
>>
>> On 5/9/2016 10:13 AM, Adam Wolf wrote:
>> > Hi folks!
>> >
>> > Once again, I'm doing a presentation on KiCad at Maker Faire SF.  It's
>> > in a few weeks, and I'm looking for ideas on what to include.
>> >
>> > The idea, in essence, is a yearly report on KiCad, focussing on what's
>> > recently happened, and what's in the near-term roadmap, but there are so
>> > many people who have absolutely no idea what KiCad is, that there's a
>> > few slides in the beginning that are basically the same every year.
>> >
>> > Previous things we've talked about are the improvements in pcbnew, the
>> > then-upcoming release, and the fact that we had nightly builds on lots
>> > of platforms.
>> >
>> > I'll still cover most of these things, but much abbreviated.
>> >
>> > I plan on talking a bit about the 3D work.  Do we have a good handle on
>> > the upcoming eeschema changes, especially user-facing things?
>> >
>> > Any other thoughts/suggestions?
>> >
>> > Adam Wolf
>> > Cofounder and Engineer
>> > W&L
>> >
>> >
>> > ___
>> > Mailing list: https://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] Maker Faire SF KiCad Presentation

[Lawrence Kesteloot]

Adam,

When and where is your talk?

Lawrence


On Mon, May 9, 2016 at 8:18 AM Adam Wolf 
wrote:

> Thanks!
>
> Adam Wolf
>
> On Mon, May 9, 2016 at 9:26 AM, Wayne Stambaugh 
> wrote:
>
>> Hey Adam,
>>
>> Thank you for representing KiCad at Maker Faire SF.  I wish I could join
>> you.  Maybe one of these years I'll be able to make it.
>>
>> Take a look at the version 5 road map[1] for ideas on what the goals are
>> for the next stable release.  Please keep in mind that this is the goal,
>> what actually will get implemented remains to be seen.  As for the
>> user-facing Eeschema changes, we hope to GALify (at least an initial
>> pass) and get the new file format implemented which will change the
>> library management code more along the lines of the Pcbnew.  Maybe we
>> will get few features like gate/pin swap implemented and don't forget
>> Tom's board update feature (no intermediate netlist file required).
>> Feel free to borrow any of my 2016 FOSDEM presentation if it helps.  It
>> should be available on the FOSDEM website.  If not, let me know and I
>> can send you a copy of it.
>>
>> Cheers,
>>
>> Wayne
>>
>> [1]:
>>
>> http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/v5_road_map.html
>>
>> On 5/9/2016 10:13 AM, Adam Wolf wrote:
>> > Hi folks!
>> >
>> > Once again, I'm doing a presentation on KiCad at Maker Faire SF.  It's
>> > in a few weeks, and I'm looking for ideas on what to include.
>> >
>> > The idea, in essence, is a yearly report on KiCad, focussing on what's
>> > recently happened, and what's in the near-term roadmap, but there are so
>> > many people who have absolutely no idea what KiCad is, that there's a
>> > few slides in the beginning that are basically the same every year.
>> >
>> > Previous things we've talked about are the improvements in pcbnew, the
>> > then-upcoming release, and the fact that we had nightly builds on lots
>> > of platforms.
>> >
>> > I'll still cover most of these things, but much abbreviated.
>> >
>> > I plan on talking a bit about the 3D work.  Do we have a good handle on
>> > the upcoming eeschema changes, especially user-facing things?
>> >
>> > Any other thoughts/suggestions?
>> >
>> > Adam Wolf
>> > Cofounder and Engineer
>> > W&L
>> >
>> >
>> > ___
>> > Mailing list: https://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

[Kicad-developers] Reddit discussion about KiCAD

[Lawrence Kesteloot]

"What do you like or hate about KiCad PCB software?"


https://www.reddit.com/r/PrintedCircuitBoard/comments/4ircja/what_do_you_like_or_hate_about_kicad_pcb_software/

Lawrence
___
Mailing list: https://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] What are dx and dy?

[Эльдар Хайруллин]

 I think it will be good if one can to see like:
[vector coordinates] (abs coord) (relative coord)
where [] - context visible field (drawing a graphic primitive),
() - visible always.
Or do like:
[vector coordinates] (A: abs coord | R: relative coord)
where ( | ) - switchable with the hotkey.
PS: I think the abs or rel coordinates should be visible always.
>Среда, 11 мая 2016, 0:04 +03:00 от Clemens Koller :
>
>Hi!
>
>I would see the following information on the UI quite useful:
>
>1. absolute (world) coordinates x,y
>2. relative coordinates dx,dy,dphi,ds to the last object coordinate (i.e. last 
>polygone corner/click) to place objects of a certain size.
>3. relative coordinates dx,dy,dphi,ds to the i.e. space-settable-origin to 
>place multiple objects relative to the origin.
>
>Priorities are as shown: 1->2->3.
>With the current screen real-estate it shouldn't harm to add 1+2+3 or use a
>function key to toggle the display in between 1+2 to 1+3.
>
>
>I would love to see the spacebar getting a way more important function assigned
>than placing the user origin. It seems that many users didn't even know that 
>the
>spacebar is doing that.
>What if the spacebar would fully duplicate the left mouse button because of:
>https://en.wikipedia.org/wiki/Repetitive_strain_injury
>
>I am very serious here as I am doing big designs and klicking some thousand
>times / day for many month a year is definitely worth some optimization.
>(I've tried working with keyboard reassignments, touchpads, graphic tablets,
>foot-mice, bluetooth buttons...)
>
>Regards,
>
>Clemens
>
>
>On 2016-05-10 18:20, Эльдар Хайруллин wrote:
>> Hello. I think he want to see additional fields with delta_x and delta_y 
>> (and maybe distance) relative of latest start point of drawing graphic 
>> primitive (like line) but he doesn't want to reset the user origin.
>> 
>> 
>> Вторник, 10 мая 2016, 17:25 +03:00 от Wayne Stambaugh < 
>> stambau...@gmail.com >:
>> 
>> I don't like the idea of a "smart" origin either. When I set the user
>> origin, it's typically to place multiple objects on a given x or y
>> coordinate. I don't want kicad thinking it's smarter than I am and
>> reset the user origin relative to where I started drawing some object.
>> To me that would be more annoying than useful.
>> 
>> On 5/10/2016 10:19 AM, Chris Pavlina wrote:
>> > Because that's only useful once in the entire session using pcbnew. 
>> Once you've
>> > set an origin once you can't use that anymore. What's the point?
>> > 
>> > I quite like the simplicity of the tool as it is. It's a ruler that 
>> you can
>> > move around. Why do you need a ruler that's smart and picks itself up 
>> once in a
>> > while? That just seems confusing.
>> > 
>> > On Tue, May 10, 2016 at 08:15:52AM -0600, Duane Johnson wrote:
>> >> I can see how this is useful once you know to press space bar. But 
>> what if
>> >> it assumes an implicit origin in the following case:
>> >> - no explicit origin has been set
>> >> - the user is drawing a shape
>> >> On May 10, 2016 12:39 AM, "Nick Østergaard" < oe.n...@gmail.com 
>> > wrote:
>> >>
>> >>>  
>> http://docs.kicad-pcb.org/en/pcbnew.html#_displaying_cursor_coordinates
>> >>>
>> >>> 2016-05-09 22:44 GMT+02:00 Collin Anderson < metacol...@electropi.mp 
>> >:
>>  Hit space bar, it will set the origin for dx and dy.  It's useful 
>> for
>> >>> seeing where the cursor is relative to the most recent 'origin' set 
>> with
>> >>> the spacebar.  I use it all the time :).
>>  --
>>  "Violence is the last refuge of the incompetent." - Isaac Asimov
>> 
>> > On May 9, 2016, at 2:39 PM, Duane Johnson < 
>> duane.john...@gmail.com >
>> >>> wrote:
>> >
>> > When I create a rectangle, or line, I frequently want to know what 
>> the
>> >>> size of the rectangle is (width and height). I would have assumed 
>> that's
>> >>> what "dx" and "dy" in the footer/status bar are for; however, it 
>> seems like
>> >>> in all cases, they simply reflect the same values as "X" and "Y". Am 
>> I
>> >>> missing something, or is this something to be fixed?
>> >
>> > Thanks,
>> > Duane
>> > > >>> .37.18.png>___
>> > Mailing list:  https://launchpad.net/~kicad-developers
>> > Post to :  kicad-developers@lists.launchpad.net > 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 > kicad-developers@lists.launchpad.net >
>>  Unsubscribe :  https://launchpad.net/~kicad-developers
>

Re: [Kicad-developers] Build failed in Jenkins: KiCad (Linux, all options, Debug) #1251

[Nick Østergaard]

Ahh yeah, we were messing about with that some time ago. :)

2016-05-11 17:38 GMT+02:00 Jon Neal :
> The issue is because the master jenkins node doesn't support c++11. I'm
> wondering if we should lay out a plan to upgrade the jenkins server since it
> is so out of date (some of our other scripts can't run on it due to things
> like git being 5 or 6 years out of date).
>
> We've also started getting lots of gateway timeout errors lately which makes
> things difficult. I can't actually update the jenkins main config any more
> due to this.
>
> On Wed, May 11, 2016 at 11:31 AM Nick Østergaard  wrote:
>>
>> Something is wonky with the jenkins master. I will give it a look when i
>> get home. It seems to not have built for a month on the lp:kicad branch.
>>
>> Den 11/05/2016 17.28 skrev "Miguel Angel Ajo" :
>>>
>>> See 
>>>
>>> Changes:
>>>
>>> [jean-pierre charras] Pcbnew: Fix a very minor bug ( The "Move
>>> exactly..."  sometimes truncates the saved parameter floating point values
>>> during a session)
>>>
>>> [jean-pierre charras] Fix minor bug in Modedit: Adding a new rounded rect
>>> pad to a footprint doesn't clone rectangle rounding
>>>
>>> [jean-pierre charras] Fix a few deprecated compil warnings in dialogs
>>> generated by wxformbuilder
>>>
>>> [Chris Pavlina] OS X: Disable full-screen cursor
>>>
>>> This feature cannot work reliably for reasons explained in lp:1463505.
>>> Remove
>>> the option on OS X builds and force cursor to the small one.
>>>
>>> https://bugs.launchpad.net/kicad/+bug/1463505
>>>
>>> > Bernhard Stegmaier (stegmaier) wrote on 2016-01-14:
>>> >
>>> > As far as I see from the code this is no bug but done on intention.
>>> >
>>> > The reason probably is that on OSX in the legacy canvas you don't have
>>> > the
>>> > XOR-drawing as on other platforms. To the best of my knowledge, this
>>> > would
>>> > mean that on every mouse move you would have to repaint the whole
>>> > window just
>>> > to get rid of the "old" cross.
>>> >
>>> > So, I would say this is a clear "won't fix".
>>> > We could think of just removing/disabling the button in the legacy
>>> > canvas.
>>>
>>> [Chris Pavlina] Correct handling of unused parameter
>>>
>>> Coverity: CID 143742
>>>
>>> [Chris Pavlina] Clean up dodgy array dimension
>>>
>>> Array is in pairs but has a single sentinel, trips up Coverity (CID
>>> 147346) and
>>> does allow an out-of-bounds write if WX_GL_SAMPLES were ever removed from
>>> the
>>> array.
>>>
>>> [Chris Pavlina] Remove unneeded 'new' and NULL check
>>>
>>> Coverity CID: 143743
>>>
>>> [Chris Pavlina] Fix null dereference for certain bad PCB files
>>>
>>> Coverity: CID 147344 Unchecked dynamic_cast
>>>
>>> If a file that parses validly in Parse() but does not return a BOARD is
>>> loaded,
>>> no exception will be thrown but the dynamic_cast will return NULL. This
>>> NULL
>>> is tested by wxASSERT(), which does not actually halt anything
>>> (especially in
>>> release builds), and then we proceed to board->SetFileName().
>>>
>>> This can be demonstrated quickly by renaming a .kicad_mod to .kicad_pcb
>>> and
>>> trying to load it. pcbnew will crash.
>>>
>>> [Chris Pavlina] Fix uninitialized fields
>>>
>>> Coverity: CIDs 102698, 147347, 147349, 147350
>>>
>>> [Chris Pavlina] Fix build error on some platforms from r6788
>>>
>>> r6788 = git f9386fc
>>>
>>> [Chris Pavlina] Remove "Dump zone geometry to files when filling"
>>>
>>> The code to perform the dump has not been removed, but the GUI option and
>>> global flag (ugh) have been.
>>>
>>> [Chris Pavlina] pcbnew legacy: remove option to hide via drill
>>>
>>> Via drills are now shown in all cases, matching GAL behavior, and the
>>> option no
>>> longer exists in the preferences dialog.
>>>
>>> [Chris Pavlina] Add support for PCB and footprint format versioning
>>>
>>> Currently, kicad_pcb files have a (version ...) tag, but it is ignored.
>>> This
>>> commit does the following:
>>>
>>> 1. Parse the version. If it's later than the last supported version,
>>> present an
>>> alternative error message suggesting an upgrade if the file does not load
>>> correctly. The version will be interpreted as an integer MMDD to
>>> suggest
>>> a KiCad release date.
>>>
>>> 2. Accept a (version ...) tag also in kicad_mod files, but do not write
>>> them
>>> yet. If no version tag is present in these files, assume the version to
>>> be that
>>> of the current format version at the time of this commit.
>>>
>>> This is meant to be merged to the 4.x stable series, and preps for KiCad
>>> 5
>>> which will start emitting version tags also in footprints - users with
>>> what
>>> will then be 'old stable' will not get a parse error when we introduce
>>> this for
>>> footprints, and we can safely increment the format version later.
>>>
>>> [Maciej Suminski] Commented out 'override' keyword due to problems with
>>> older swig versions (see bug lp:1579042).
>>>
>>> [Maciej Suminski] Removed remaining trac

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

[Wayne Stambaugh]

A standard format for the text of a given field is not the same thing as
adding code to the schematic editor to edit that field.  I do not want
to introduce code into the schematic editor for generating formatted
field text for external use.  This should be done within the current
field editor or an external text editor if you are so inclined.

All fields are saved in the netlist so the netlist format will not need
to be modified.


On 5/11/2016 11:46 AM, José Ignacio wrote:
> If it's still too offensive, you could discard the naming part of my
> proposal and just modify the netlist format so that eeschema passes
> _all fields_ to pcbnew, that way the script can access them and do
> whatever it wants. It would enable all sorts of powerful things in the
> future, though it might complicate the "caching" behavior when
> deciding whether to regenerate footprints or not.
> 
> On Wed, May 11, 2016 at 10:41 AM, José Ignacio  wrote:
>> It would not introduce a limitation, just a standard format that would
>> work with pcbnew footprint generators, external scripts can run
>> outside of kicad and use field names and values however they please.
>>
>> On Wed, May 11, 2016 at 10:23 AM, Wayne Stambaugh  
>> wrote:
>>> On 5/11/2016 10:24 AM, José Ignacio wrote:
 What about (ab)using the footprint field (actually the library plugin
 system) for this? Say you add a new library plugin called "python",
 each library would be a python module (either a single .py file or a
 folder with an __init__.py script) That module will have a callable
 for each "virtual" footprint. Those callables will take in a
 dictionary of key-values and spit out a footprint object. The name of
 the callable will be the base name of the footprint, say, Microwave.py
 having a Microstrip(**args) will be called out as
 Microwave:Microstrip.

 To add parameters to the called footprint a dash "-" could be used as
 the argument separator (as it is an illegal identifier for python
 objects), with an underscore "_" to separate key and value. For
 example a microstrip could be called out as
 Microwave:Microstrip-W_10mil-L_50mil, which will cause pcbnew to load
 Microwave.py and call Microstrip({'W': '10mil', 'L':'50mil'}) . This
 allows for some neat things to happen without touching much code in
 both eeschema and pcbnew. When the dimensions change in eeschema,
 pcbnew will automatically try to fetch the new footprint (which will
 call the script) but the rest will be left alone as they have the same
 name. This will also allow using the existing footprint archival
 facilities to save "baked in" copies of the generated footprints.
>>>
>>> The text in a given field would be completely dependent on the script
>>> that would use it.  Key/value pairs may or may not make sense depending
>>> on the script.  The formatting of the field text should be left to the
>>> script developer.  The schematic editor should have no say in the
>>> formatting.
>>>

 To make editing parameters less cumbersome in eeschema it would be
 neat to add a feature at netlist generation, for fields with special
 names like "footprint(W)" with a value of say "10mil" will cause
 eeschema to tack "-W_10mil" at the end of the footprint name when
 generating the netlist. The policy for duplicated keys is that the
 last one counts, and the keys would be sorted alphabetically to have a
 predictable ordering.
>>>
>>> I would reject any change that would impose any formatting limitations
>>> on the field text.  Fields are merely generic text for anything the user
>>> can think of so all text is valid.  The formatting of the text is
>>> determined by the user not by schematic editor.
>>>

 Recap:

 The features that would be needed for this idea would be:
 * A new pcbnew library plugin that calls functions in a python script
 to generate footprints based on the footprint name
   - Perhaps later on build a toolkit library to ease the creation of
 parametric footprints, an initial hacky version could be to just
 generate SEXPRs in python and barf them into the existing kicad_mod
 parser.
 * A change in the eeschema netlister to append arguments to the footprint 
 name
 Format changes needed: none

 The python bit is optional actually, the library plugin could be done
 in pure C++ if it proves to be easier, but having python access would
 be the most flexible.

 What do you think of this idea?

 On Wed, May 11, 2016 at 8:24 AM, Wayne Stambaugh  
 wrote:
> On 5/11/2016 6:13 AM, Tomasz Wlostowski wrote:
>> On 09.05.2016 14:38, Wayne Stambaugh wrote:
>>> On 5/4/2016 4:11 PM, Tomasz Wlostowski wrote:
 On 04.05.2016 16:48, Wayne Stambaugh wrote:
> How are you saving this auto generate flag and width/length parameters
> in the schematic?  If you are using component fi

Re: [Kicad-developers] Build failed in Jenkins: KiCad (Linux, all options, Debug) #1251

[Adam Wolf]

Jenkins 2 recently came out as well, and I'm thinking about redoing how I
do the OS X builds in my Jenkins.

On Wed, May 11, 2016 at 10:38 AM, Jon Neal  wrote:

> The issue is because the master jenkins node doesn't support c++11. I'm
> wondering if we should lay out a plan to upgrade the jenkins server since
> it is so out of date (some of our other scripts can't run on it due to
> things like git being 5 or 6 years out of date).
>
> We've also started getting lots of gateway timeout errors lately which
> makes things difficult. I can't actually update the jenkins main config any
> more due to this.
>
> On Wed, May 11, 2016 at 11:31 AM Nick Østergaard 
> wrote:
>
>> Something is wonky with the jenkins master. I will give it a look when i
>> get home. It seems to not have built for a month on the lp:kicad branch.
>> Den 11/05/2016 17.28 skrev "Miguel Angel Ajo" :
>>
>>> See 
>>>
>>> Changes:
>>>
>>> [jean-pierre charras] Pcbnew: Fix a very minor bug ( The "Move
>>> exactly..."  sometimes truncates the saved parameter floating point values
>>> during a session)
>>>
>>> [jean-pierre charras] Fix minor bug in Modedit: Adding a new rounded
>>> rect pad to a footprint doesn't clone rectangle rounding
>>>
>>> [jean-pierre charras] Fix a few deprecated compil warnings in dialogs
>>> generated by wxformbuilder
>>>
>>> [Chris Pavlina] OS X: Disable full-screen cursor
>>>
>>> This feature cannot work reliably for reasons explained in lp:1463505.
>>> Remove
>>> the option on OS X builds and force cursor to the small one.
>>>
>>> https://bugs.launchpad.net/kicad/+bug/1463505
>>>
>>> > Bernhard Stegmaier (stegmaier) wrote on 2016-01-14:
>>> >
>>> > As far as I see from the code this is no bug but done on intention.
>>> >
>>> > The reason probably is that on OSX in the legacy canvas you don't have
>>> the
>>> > XOR-drawing as on other platforms. To the best of my knowledge, this
>>> would
>>> > mean that on every mouse move you would have to repaint the whole
>>> window just
>>> > to get rid of the "old" cross.
>>> >
>>> > So, I would say this is a clear "won't fix".
>>> > We could think of just removing/disabling the button in the legacy
>>> canvas.
>>>
>>> [Chris Pavlina] Correct handling of unused parameter
>>>
>>> Coverity: CID 143742
>>>
>>> [Chris Pavlina] Clean up dodgy array dimension
>>>
>>> Array is in pairs but has a single sentinel, trips up Coverity (CID
>>> 147346) and
>>> does allow an out-of-bounds write if WX_GL_SAMPLES were ever removed
>>> from the
>>> array.
>>>
>>> [Chris Pavlina] Remove unneeded 'new' and NULL check
>>>
>>> Coverity CID: 143743
>>>
>>> [Chris Pavlina] Fix null dereference for certain bad PCB files
>>>
>>> Coverity: CID 147344 Unchecked dynamic_cast
>>>
>>> If a file that parses validly in Parse() but does not return a BOARD is
>>> loaded,
>>> no exception will be thrown but the dynamic_cast will return NULL. This
>>> NULL
>>> is tested by wxASSERT(), which does not actually halt anything
>>> (especially in
>>> release builds), and then we proceed to board->SetFileName().
>>>
>>> This can be demonstrated quickly by renaming a .kicad_mod to .kicad_pcb
>>> and
>>> trying to load it. pcbnew will crash.
>>>
>>> [Chris Pavlina] Fix uninitialized fields
>>>
>>> Coverity: CIDs 102698, 147347, 147349, 147350
>>>
>>> [Chris Pavlina] Fix build error on some platforms from r6788
>>>
>>> r6788 = git f9386fc
>>>
>>> [Chris Pavlina] Remove "Dump zone geometry to files when filling"
>>>
>>> The code to perform the dump has not been removed, but the GUI option and
>>> global flag (ugh) have been.
>>>
>>> [Chris Pavlina] pcbnew legacy: remove option to hide via drill
>>>
>>> Via drills are now shown in all cases, matching GAL behavior, and the
>>> option no
>>> longer exists in the preferences dialog.
>>>
>>> [Chris Pavlina] Add support for PCB and footprint format versioning
>>>
>>> Currently, kicad_pcb files have a (version ...) tag, but it is ignored.
>>> This
>>> commit does the following:
>>>
>>> 1. Parse the version. If it's later than the last supported version,
>>> present an
>>> alternative error message suggesting an upgrade if the file does not load
>>> correctly. The version will be interpreted as an integer MMDD to
>>> suggest
>>> a KiCad release date.
>>>
>>> 2. Accept a (version ...) tag also in kicad_mod files, but do not write
>>> them
>>> yet. If no version tag is present in these files, assume the version to
>>> be that
>>> of the current format version at the time of this commit.
>>>
>>> This is meant to be merged to the 4.x stable series, and preps for KiCad
>>> 5
>>> which will start emitting version tags also in footprints - users with
>>> what
>>> will then be 'old stable' will not get a parse error when we introduce
>>> this for
>>> footprints, and we can safely increment the format version later.
>>>
>>> [Maciej Suminski] Commented out 'override' keyword due to problems with
>>> older swig versions (see bug lp:1579042

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

[José Ignacio]

If it's still too offensive, you could discard the naming part of my
proposal and just modify the netlist format so that eeschema passes
_all fields_ to pcbnew, that way the script can access them and do
whatever it wants. It would enable all sorts of powerful things in the
future, though it might complicate the "caching" behavior when
deciding whether to regenerate footprints or not.

On Wed, May 11, 2016 at 10:41 AM, José Ignacio  wrote:
> It would not introduce a limitation, just a standard format that would
> work with pcbnew footprint generators, external scripts can run
> outside of kicad and use field names and values however they please.
>
> On Wed, May 11, 2016 at 10:23 AM, Wayne Stambaugh  
> wrote:
>> On 5/11/2016 10:24 AM, José Ignacio wrote:
>>> What about (ab)using the footprint field (actually the library plugin
>>> system) for this? Say you add a new library plugin called "python",
>>> each library would be a python module (either a single .py file or a
>>> folder with an __init__.py script) That module will have a callable
>>> for each "virtual" footprint. Those callables will take in a
>>> dictionary of key-values and spit out a footprint object. The name of
>>> the callable will be the base name of the footprint, say, Microwave.py
>>> having a Microstrip(**args) will be called out as
>>> Microwave:Microstrip.
>>>
>>> To add parameters to the called footprint a dash "-" could be used as
>>> the argument separator (as it is an illegal identifier for python
>>> objects), with an underscore "_" to separate key and value. For
>>> example a microstrip could be called out as
>>> Microwave:Microstrip-W_10mil-L_50mil, which will cause pcbnew to load
>>> Microwave.py and call Microstrip({'W': '10mil', 'L':'50mil'}) . This
>>> allows for some neat things to happen without touching much code in
>>> both eeschema and pcbnew. When the dimensions change in eeschema,
>>> pcbnew will automatically try to fetch the new footprint (which will
>>> call the script) but the rest will be left alone as they have the same
>>> name. This will also allow using the existing footprint archival
>>> facilities to save "baked in" copies of the generated footprints.
>>
>> The text in a given field would be completely dependent on the script
>> that would use it.  Key/value pairs may or may not make sense depending
>> on the script.  The formatting of the field text should be left to the
>> script developer.  The schematic editor should have no say in the
>> formatting.
>>
>>>
>>> To make editing parameters less cumbersome in eeschema it would be
>>> neat to add a feature at netlist generation, for fields with special
>>> names like "footprint(W)" with a value of say "10mil" will cause
>>> eeschema to tack "-W_10mil" at the end of the footprint name when
>>> generating the netlist. The policy for duplicated keys is that the
>>> last one counts, and the keys would be sorted alphabetically to have a
>>> predictable ordering.
>>
>> I would reject any change that would impose any formatting limitations
>> on the field text.  Fields are merely generic text for anything the user
>> can think of so all text is valid.  The formatting of the text is
>> determined by the user not by schematic editor.
>>
>>>
>>> Recap:
>>>
>>> The features that would be needed for this idea would be:
>>> * A new pcbnew library plugin that calls functions in a python script
>>> to generate footprints based on the footprint name
>>>   - Perhaps later on build a toolkit library to ease the creation of
>>> parametric footprints, an initial hacky version could be to just
>>> generate SEXPRs in python and barf them into the existing kicad_mod
>>> parser.
>>> * A change in the eeschema netlister to append arguments to the footprint 
>>> name
>>> Format changes needed: none
>>>
>>> The python bit is optional actually, the library plugin could be done
>>> in pure C++ if it proves to be easier, but having python access would
>>> be the most flexible.
>>>
>>> What do you think of this idea?
>>>
>>> On Wed, May 11, 2016 at 8:24 AM, Wayne Stambaugh  
>>> wrote:
 On 5/11/2016 6:13 AM, Tomasz Wlostowski wrote:
> On 09.05.2016 14:38, Wayne Stambaugh wrote:
>> On 5/4/2016 4:11 PM, Tomasz Wlostowski wrote:
>>> On 04.05.2016 16:48, Wayne Stambaugh wrote:
 How are you saving this auto generate flag and width/length parameters
 in the schematic?  If you are using component fields or text that's
 fine.  However, please keep in mind that using component fields and 
 text
 is for passing information to third party tools that are not part of
 kicad.  If we are going to support net ties and micro wave component
 generation, we should do that as part of KiCad proper rather than treat
 it like a third party tool which you are proposing.
>>>
>>> Hi Wayne,
>>>
>>> I would store the microwave dimensions as key:value pairs, just like the
>>> current schematic fields. I think microwa

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

[José Ignacio]

It would not introduce a limitation, just a standard format that would
work with pcbnew footprint generators, external scripts can run
outside of kicad and use field names and values however they please.

On Wed, May 11, 2016 at 10:23 AM, Wayne Stambaugh  wrote:
> On 5/11/2016 10:24 AM, José Ignacio wrote:
>> What about (ab)using the footprint field (actually the library plugin
>> system) for this? Say you add a new library plugin called "python",
>> each library would be a python module (either a single .py file or a
>> folder with an __init__.py script) That module will have a callable
>> for each "virtual" footprint. Those callables will take in a
>> dictionary of key-values and spit out a footprint object. The name of
>> the callable will be the base name of the footprint, say, Microwave.py
>> having a Microstrip(**args) will be called out as
>> Microwave:Microstrip.
>>
>> To add parameters to the called footprint a dash "-" could be used as
>> the argument separator (as it is an illegal identifier for python
>> objects), with an underscore "_" to separate key and value. For
>> example a microstrip could be called out as
>> Microwave:Microstrip-W_10mil-L_50mil, which will cause pcbnew to load
>> Microwave.py and call Microstrip({'W': '10mil', 'L':'50mil'}) . This
>> allows for some neat things to happen without touching much code in
>> both eeschema and pcbnew. When the dimensions change in eeschema,
>> pcbnew will automatically try to fetch the new footprint (which will
>> call the script) but the rest will be left alone as they have the same
>> name. This will also allow using the existing footprint archival
>> facilities to save "baked in" copies of the generated footprints.
>
> The text in a given field would be completely dependent on the script
> that would use it.  Key/value pairs may or may not make sense depending
> on the script.  The formatting of the field text should be left to the
> script developer.  The schematic editor should have no say in the
> formatting.
>
>>
>> To make editing parameters less cumbersome in eeschema it would be
>> neat to add a feature at netlist generation, for fields with special
>> names like "footprint(W)" with a value of say "10mil" will cause
>> eeschema to tack "-W_10mil" at the end of the footprint name when
>> generating the netlist. The policy for duplicated keys is that the
>> last one counts, and the keys would be sorted alphabetically to have a
>> predictable ordering.
>
> I would reject any change that would impose any formatting limitations
> on the field text.  Fields are merely generic text for anything the user
> can think of so all text is valid.  The formatting of the text is
> determined by the user not by schematic editor.
>
>>
>> Recap:
>>
>> The features that would be needed for this idea would be:
>> * A new pcbnew library plugin that calls functions in a python script
>> to generate footprints based on the footprint name
>>   - Perhaps later on build a toolkit library to ease the creation of
>> parametric footprints, an initial hacky version could be to just
>> generate SEXPRs in python and barf them into the existing kicad_mod
>> parser.
>> * A change in the eeschema netlister to append arguments to the footprint 
>> name
>> Format changes needed: none
>>
>> The python bit is optional actually, the library plugin could be done
>> in pure C++ if it proves to be easier, but having python access would
>> be the most flexible.
>>
>> What do you think of this idea?
>>
>> On Wed, May 11, 2016 at 8:24 AM, Wayne Stambaugh  
>> wrote:
>>> On 5/11/2016 6:13 AM, Tomasz Wlostowski wrote:
 On 09.05.2016 14:38, Wayne Stambaugh wrote:
> On 5/4/2016 4:11 PM, Tomasz Wlostowski wrote:
>> On 04.05.2016 16:48, Wayne Stambaugh wrote:
>>> How are you saving this auto generate flag and width/length parameters
>>> in the schematic?  If you are using component fields or text that's
>>> fine.  However, please keep in mind that using component fields and text
>>> is for passing information to third party tools that are not part of
>>> kicad.  If we are going to support net ties and micro wave component
>>> generation, we should do that as part of KiCad proper rather than treat
>>> it like a third party tool which you are proposing.
>>
>> Hi Wayne,
>>
>> I would store the microwave dimensions as key:value pairs, just like the
>> current schematic fields. I think microwave components will be best
>> handled by python scripting. These scripts should be IMHO permanently
>> included in Kicad distribution, not a 3rd party tool. I chose component
>> fields to pass the dimensions information because with every new exotic
>> shape (e.g. a Wilkinson power divider instead of a simple microstrip
>> line), we would need to add new tokens to the SCH file format and
>> netlist specification.
>
> Hey Tom,
>
> Would it be easier to provide a python script with a UI to input the
>

Re: [Kicad-developers] Build failed in Jenkins: KiCad (Linux, all options, Debug) #1251

[Jon Neal]

The issue is because the master jenkins node doesn't support c++11. I'm
wondering if we should lay out a plan to upgrade the jenkins server since
it is so out of date (some of our other scripts can't run on it due to
things like git being 5 or 6 years out of date).

We've also started getting lots of gateway timeout errors lately which
makes things difficult. I can't actually update the jenkins main config any
more due to this.

On Wed, May 11, 2016 at 11:31 AM Nick Østergaard  wrote:

> Something is wonky with the jenkins master. I will give it a look when i
> get home. It seems to not have built for a month on the lp:kicad branch.
> Den 11/05/2016 17.28 skrev "Miguel Angel Ajo" :
>
>> See 
>>
>> Changes:
>>
>> [jean-pierre charras] Pcbnew: Fix a very minor bug ( The "Move
>> exactly..."  sometimes truncates the saved parameter floating point values
>> during a session)
>>
>> [jean-pierre charras] Fix minor bug in Modedit: Adding a new rounded rect
>> pad to a footprint doesn't clone rectangle rounding
>>
>> [jean-pierre charras] Fix a few deprecated compil warnings in dialogs
>> generated by wxformbuilder
>>
>> [Chris Pavlina] OS X: Disable full-screen cursor
>>
>> This feature cannot work reliably for reasons explained in lp:1463505.
>> Remove
>> the option on OS X builds and force cursor to the small one.
>>
>> https://bugs.launchpad.net/kicad/+bug/1463505
>>
>> > Bernhard Stegmaier (stegmaier) wrote on 2016-01-14:
>> >
>> > As far as I see from the code this is no bug but done on intention.
>> >
>> > The reason probably is that on OSX in the legacy canvas you don't have
>> the
>> > XOR-drawing as on other platforms. To the best of my knowledge, this
>> would
>> > mean that on every mouse move you would have to repaint the whole
>> window just
>> > to get rid of the "old" cross.
>> >
>> > So, I would say this is a clear "won't fix".
>> > We could think of just removing/disabling the button in the legacy
>> canvas.
>>
>> [Chris Pavlina] Correct handling of unused parameter
>>
>> Coverity: CID 143742
>>
>> [Chris Pavlina] Clean up dodgy array dimension
>>
>> Array is in pairs but has a single sentinel, trips up Coverity (CID
>> 147346) and
>> does allow an out-of-bounds write if WX_GL_SAMPLES were ever removed from
>> the
>> array.
>>
>> [Chris Pavlina] Remove unneeded 'new' and NULL check
>>
>> Coverity CID: 143743
>>
>> [Chris Pavlina] Fix null dereference for certain bad PCB files
>>
>> Coverity: CID 147344 Unchecked dynamic_cast
>>
>> If a file that parses validly in Parse() but does not return a BOARD is
>> loaded,
>> no exception will be thrown but the dynamic_cast will return NULL. This
>> NULL
>> is tested by wxASSERT(), which does not actually halt anything
>> (especially in
>> release builds), and then we proceed to board->SetFileName().
>>
>> This can be demonstrated quickly by renaming a .kicad_mod to .kicad_pcb
>> and
>> trying to load it. pcbnew will crash.
>>
>> [Chris Pavlina] Fix uninitialized fields
>>
>> Coverity: CIDs 102698, 147347, 147349, 147350
>>
>> [Chris Pavlina] Fix build error on some platforms from r6788
>>
>> r6788 = git f9386fc
>>
>> [Chris Pavlina] Remove "Dump zone geometry to files when filling"
>>
>> The code to perform the dump has not been removed, but the GUI option and
>> global flag (ugh) have been.
>>
>> [Chris Pavlina] pcbnew legacy: remove option to hide via drill
>>
>> Via drills are now shown in all cases, matching GAL behavior, and the
>> option no
>> longer exists in the preferences dialog.
>>
>> [Chris Pavlina] Add support for PCB and footprint format versioning
>>
>> Currently, kicad_pcb files have a (version ...) tag, but it is ignored.
>> This
>> commit does the following:
>>
>> 1. Parse the version. If it's later than the last supported version,
>> present an
>> alternative error message suggesting an upgrade if the file does not load
>> correctly. The version will be interpreted as an integer MMDD to
>> suggest
>> a KiCad release date.
>>
>> 2. Accept a (version ...) tag also in kicad_mod files, but do not write
>> them
>> yet. If no version tag is present in these files, assume the version to
>> be that
>> of the current format version at the time of this commit.
>>
>> This is meant to be merged to the 4.x stable series, and preps for KiCad 5
>> which will start emitting version tags also in footprints - users with
>> what
>> will then be 'old stable' will not get a parse error when we introduce
>> this for
>> footprints, and we can safely increment the format version later.
>>
>> [Maciej Suminski] Commented out 'override' keyword due to problems with
>> older swig versions (see bug lp:1579042).
>>
>> [Maciej Suminski] Removed remaining traces of KICAD_SKIP_BOOST parameter.
>>
>> [jean-pierre charras] Fix an issue in LOCALE_IO class, used to switch
>> to/back locale "C" when reading/writing files: the back to locale was
>> broken, and created issues in countries using the ',' as fp separator,
>

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

[Wayne Stambaugh]

On 5/11/2016 10:24 AM, José Ignacio wrote:
> What about (ab)using the footprint field (actually the library plugin
> system) for this? Say you add a new library plugin called "python",
> each library would be a python module (either a single .py file or a
> folder with an __init__.py script) That module will have a callable
> for each "virtual" footprint. Those callables will take in a
> dictionary of key-values and spit out a footprint object. The name of
> the callable will be the base name of the footprint, say, Microwave.py
> having a Microstrip(**args) will be called out as
> Microwave:Microstrip.
> 
> To add parameters to the called footprint a dash "-" could be used as
> the argument separator (as it is an illegal identifier for python
> objects), with an underscore "_" to separate key and value. For
> example a microstrip could be called out as
> Microwave:Microstrip-W_10mil-L_50mil, which will cause pcbnew to load
> Microwave.py and call Microstrip({'W': '10mil', 'L':'50mil'}) . This
> allows for some neat things to happen without touching much code in
> both eeschema and pcbnew. When the dimensions change in eeschema,
> pcbnew will automatically try to fetch the new footprint (which will
> call the script) but the rest will be left alone as they have the same
> name. This will also allow using the existing footprint archival
> facilities to save "baked in" copies of the generated footprints.

The text in a given field would be completely dependent on the script
that would use it.  Key/value pairs may or may not make sense depending
on the script.  The formatting of the field text should be left to the
script developer.  The schematic editor should have no say in the
formatting.

> 
> To make editing parameters less cumbersome in eeschema it would be
> neat to add a feature at netlist generation, for fields with special
> names like "footprint(W)" with a value of say "10mil" will cause
> eeschema to tack "-W_10mil" at the end of the footprint name when
> generating the netlist. The policy for duplicated keys is that the
> last one counts, and the keys would be sorted alphabetically to have a
> predictable ordering.

I would reject any change that would impose any formatting limitations
on the field text.  Fields are merely generic text for anything the user
can think of so all text is valid.  The formatting of the text is
determined by the user not by schematic editor.

> 
> Recap:
> 
> The features that would be needed for this idea would be:
> * A new pcbnew library plugin that calls functions in a python script
> to generate footprints based on the footprint name
>   - Perhaps later on build a toolkit library to ease the creation of
> parametric footprints, an initial hacky version could be to just
> generate SEXPRs in python and barf them into the existing kicad_mod
> parser.
> * A change in the eeschema netlister to append arguments to the footprint name
> Format changes needed: none
> 
> The python bit is optional actually, the library plugin could be done
> in pure C++ if it proves to be easier, but having python access would
> be the most flexible.
> 
> What do you think of this idea?
> 
> On Wed, May 11, 2016 at 8:24 AM, Wayne Stambaugh  wrote:
>> On 5/11/2016 6:13 AM, Tomasz Wlostowski wrote:
>>> On 09.05.2016 14:38, Wayne Stambaugh wrote:
 On 5/4/2016 4:11 PM, Tomasz Wlostowski wrote:
> On 04.05.2016 16:48, Wayne Stambaugh wrote:
>> How are you saving this auto generate flag and width/length parameters
>> in the schematic?  If you are using component fields or text that's
>> fine.  However, please keep in mind that using component fields and text
>> is for passing information to third party tools that are not part of
>> kicad.  If we are going to support net ties and micro wave component
>> generation, we should do that as part of KiCad proper rather than treat
>> it like a third party tool which you are proposing.
>
> Hi Wayne,
>
> I would store the microwave dimensions as key:value pairs, just like the
> current schematic fields. I think microwave components will be best
> handled by python scripting. These scripts should be IMHO permanently
> included in Kicad distribution, not a 3rd party tool. I chose component
> fields to pass the dimensions information because with every new exotic
> shape (e.g. a Wilkinson power divider instead of a simple microstrip
> line), we would need to add new tokens to the SCH file format and
> netlist specification.

 Hey Tom,

 Would it be easier to provide a python script with a UI to input the
 dimensional information used to generate these complex microwave
 footprints and just associate them with a schematic symbol rather that
 trying to squeeze all of that dimensional information into a field?
 This may be more natural for the user to handle.  I understand the
 temptation to use fields to do this but I'm not sure this is the easiest

Re: [Kicad-developers] Build failed in Jenkins: KiCad (Linux, all options, Debug) #1251

[Nick Østergaard]

Something is wonky with the jenkins master. I will give it a look when i
get home. It seems to not have built for a month on the lp:kicad branch.
Den 11/05/2016 17.28 skrev "Miguel Angel Ajo" :

> See 
>
> Changes:
>
> [jean-pierre charras] Pcbnew: Fix a very minor bug ( The "Move
> exactly..."  sometimes truncates the saved parameter floating point values
> during a session)
>
> [jean-pierre charras] Fix minor bug in Modedit: Adding a new rounded rect
> pad to a footprint doesn't clone rectangle rounding
>
> [jean-pierre charras] Fix a few deprecated compil warnings in dialogs
> generated by wxformbuilder
>
> [Chris Pavlina] OS X: Disable full-screen cursor
>
> This feature cannot work reliably for reasons explained in lp:1463505.
> Remove
> the option on OS X builds and force cursor to the small one.
>
> https://bugs.launchpad.net/kicad/+bug/1463505
>
> > Bernhard Stegmaier (stegmaier) wrote on 2016-01-14:
> >
> > As far as I see from the code this is no bug but done on intention.
> >
> > The reason probably is that on OSX in the legacy canvas you don't have
> the
> > XOR-drawing as on other platforms. To the best of my knowledge, this
> would
> > mean that on every mouse move you would have to repaint the whole window
> just
> > to get rid of the "old" cross.
> >
> > So, I would say this is a clear "won't fix".
> > We could think of just removing/disabling the button in the legacy
> canvas.
>
> [Chris Pavlina] Correct handling of unused parameter
>
> Coverity: CID 143742
>
> [Chris Pavlina] Clean up dodgy array dimension
>
> Array is in pairs but has a single sentinel, trips up Coverity (CID
> 147346) and
> does allow an out-of-bounds write if WX_GL_SAMPLES were ever removed from
> the
> array.
>
> [Chris Pavlina] Remove unneeded 'new' and NULL check
>
> Coverity CID: 143743
>
> [Chris Pavlina] Fix null dereference for certain bad PCB files
>
> Coverity: CID 147344 Unchecked dynamic_cast
>
> If a file that parses validly in Parse() but does not return a BOARD is
> loaded,
> no exception will be thrown but the dynamic_cast will return NULL. This
> NULL
> is tested by wxASSERT(), which does not actually halt anything (especially
> in
> release builds), and then we proceed to board->SetFileName().
>
> This can be demonstrated quickly by renaming a .kicad_mod to .kicad_pcb and
> trying to load it. pcbnew will crash.
>
> [Chris Pavlina] Fix uninitialized fields
>
> Coverity: CIDs 102698, 147347, 147349, 147350
>
> [Chris Pavlina] Fix build error on some platforms from r6788
>
> r6788 = git f9386fc
>
> [Chris Pavlina] Remove "Dump zone geometry to files when filling"
>
> The code to perform the dump has not been removed, but the GUI option and
> global flag (ugh) have been.
>
> [Chris Pavlina] pcbnew legacy: remove option to hide via drill
>
> Via drills are now shown in all cases, matching GAL behavior, and the
> option no
> longer exists in the preferences dialog.
>
> [Chris Pavlina] Add support for PCB and footprint format versioning
>
> Currently, kicad_pcb files have a (version ...) tag, but it is ignored.
> This
> commit does the following:
>
> 1. Parse the version. If it's later than the last supported version,
> present an
> alternative error message suggesting an upgrade if the file does not load
> correctly. The version will be interpreted as an integer MMDD to
> suggest
> a KiCad release date.
>
> 2. Accept a (version ...) tag also in kicad_mod files, but do not write
> them
> yet. If no version tag is present in these files, assume the version to be
> that
> of the current format version at the time of this commit.
>
> This is meant to be merged to the 4.x stable series, and preps for KiCad 5
> which will start emitting version tags also in footprints - users with what
> will then be 'old stable' will not get a parse error when we introduce
> this for
> footprints, and we can safely increment the format version later.
>
> [Maciej Suminski] Commented out 'override' keyword due to problems with
> older swig versions (see bug lp:1579042).
>
> [Maciej Suminski] Removed remaining traces of KICAD_SKIP_BOOST parameter.
>
> [jean-pierre charras] Fix an issue in LOCALE_IO class, used to switch
> to/back locale "C" when reading/writing files: the back to locale was
> broken, and created issues in countries using the ',' as fp separator,
> especially when the non default language was used.
> It was reported in many bugs.
>
> [jean-pierre charras] Fix a few shadowed local variables and deprecated
> warnings in dialogs (using a very recent wxformbuilder version).
>
> [Maciej Suminski] OpenGL GAL: Set context in destructor when possible
> (under Linux the window has to be visible).
>
> [Maciej Suminski] 3D viewer: set right OpenGL context before freeing
> memory.
>
> [Maciej Suminski] Fixed a crash when starting pcbnew with OpenGL GAL.
>
> [Maciej Suminski] Highlight an item when context menu is displayed (GAL).
>
> [Maciej Suminski] Added menu for lockin

[Kicad-developers] Build failed in Jenkins: KiCad (Linux, all options, Debug) #1251

[Miguel Angel Ajo]

See 

Changes:

[jean-pierre charras] Pcbnew: Fix a very minor bug ( The "Move exactly..."  
sometimes truncates the saved parameter floating point values during a session)

[jean-pierre charras] Fix minor bug in Modedit: Adding a new rounded rect pad 
to a footprint doesn't clone rectangle rounding

[jean-pierre charras] Fix a few deprecated compil warnings in dialogs generated 
by wxformbuilder

[Chris Pavlina] OS X: Disable full-screen cursor

This feature cannot work reliably for reasons explained in lp:1463505. Remove
the option on OS X builds and force cursor to the small one.

https://bugs.launchpad.net/kicad/+bug/1463505

> Bernhard Stegmaier (stegmaier) wrote on 2016-01-14:
>
> As far as I see from the code this is no bug but done on intention.
>
> The reason probably is that on OSX in the legacy canvas you don't have the
> XOR-drawing as on other platforms. To the best of my knowledge, this would
> mean that on every mouse move you would have to repaint the whole window just
> to get rid of the "old" cross.
>
> So, I would say this is a clear "won't fix".
> We could think of just removing/disabling the button in the legacy canvas.

[Chris Pavlina] Correct handling of unused parameter

Coverity: CID 143742

[Chris Pavlina] Clean up dodgy array dimension

Array is in pairs but has a single sentinel, trips up Coverity (CID 147346) and
does allow an out-of-bounds write if WX_GL_SAMPLES were ever removed from the
array.

[Chris Pavlina] Remove unneeded 'new' and NULL check

Coverity CID: 143743

[Chris Pavlina] Fix null dereference for certain bad PCB files

Coverity: CID 147344 Unchecked dynamic_cast

If a file that parses validly in Parse() but does not return a BOARD is loaded,
no exception will be thrown but the dynamic_cast will return NULL. This NULL
is tested by wxASSERT(), which does not actually halt anything (especially in
release builds), and then we proceed to board->SetFileName().

This can be demonstrated quickly by renaming a .kicad_mod to .kicad_pcb and
trying to load it. pcbnew will crash.

[Chris Pavlina] Fix uninitialized fields

Coverity: CIDs 102698, 147347, 147349, 147350

[Chris Pavlina] Fix build error on some platforms from r6788

r6788 = git f9386fc

[Chris Pavlina] Remove "Dump zone geometry to files when filling"

The code to perform the dump has not been removed, but the GUI option and
global flag (ugh) have been.

[Chris Pavlina] pcbnew legacy: remove option to hide via drill

Via drills are now shown in all cases, matching GAL behavior, and the option no
longer exists in the preferences dialog.

[Chris Pavlina] Add support for PCB and footprint format versioning

Currently, kicad_pcb files have a (version ...) tag, but it is ignored. This
commit does the following:

1. Parse the version. If it's later than the last supported version, present an
alternative error message suggesting an upgrade if the file does not load
correctly. The version will be interpreted as an integer MMDD to suggest
a KiCad release date.

2. Accept a (version ...) tag also in kicad_mod files, but do not write them
yet. If no version tag is present in these files, assume the version to be that
of the current format version at the time of this commit.

This is meant to be merged to the 4.x stable series, and preps for KiCad 5
which will start emitting version tags also in footprints - users with what
will then be 'old stable' will not get a parse error when we introduce this for
footprints, and we can safely increment the format version later.

[Maciej Suminski] Commented out 'override' keyword due to problems with older 
swig versions (see bug lp:1579042).

[Maciej Suminski] Removed remaining traces of KICAD_SKIP_BOOST parameter.

[jean-pierre charras] Fix an issue in LOCALE_IO class, used to switch to/back 
locale "C" when reading/writing files: the back to locale was broken, and 
created issues in countries using the ',' as fp separator, especially when the 
non default language was used.
It was reported in many bugs.

[jean-pierre charras] Fix a few shadowed local variables and deprecated 
warnings in dialogs (using a very recent wxformbuilder version).

[Maciej Suminski] OpenGL GAL: Set context in destructor when possible (under 
Linux the window has to be visible).

[Maciej Suminski] 3D viewer: set right OpenGL context before freeing memory.

[Maciej Suminski] Fixed a crash when starting pcbnew with OpenGL GAL.

[Maciej Suminski] Highlight an item when context menu is displayed (GAL).

[Maciej Suminski] Added menu for locking tracks & vias (GAL).

[Maciej Suminski] Added SELECTION_CONDITIONS::OnlyTypes() variant that takes 
KICAD_T[]4

[Maciej Suminski] Mark locked tracks with 'L' letter in status field.

[jean-pierre charras] Minor fixes: Fix a few shadowed local variables, and 
deprecated warnings is a few dialogs generated by wxFormbuilder (using a very 
recent wxFormbuilder version, after apr 25, 2016)

[Chris Pavlina] Fix beep on hot

Re: [Kicad-developers] Dump zone geometry to files when filling

[Wayne Stambaugh]

I'm not proposing that we change the frame name prefixing.  I only
mentioned it because it's not always obvious what the config entry names
are.  If you were looking for "MaxUndoCount", you wont find it in any of
the config files.  It will always have the the frame name prefixed to it.

On 5/11/2016 11:13 AM, Chris Pavlina wrote:
> Did someone propose changing that? I'm confused.
> 
> On Wed, May 11, 2016 at 11:05:23AM -0400, Wayne Stambaugh wrote:
>> In the Eeschema config file I see:
>>
>> SchematicFrameMaxUndoItems=0
>> LibeditFrameMaxUndoItems=0
>> ViewlibFrameMaxUndoItems=0
>>
>> In the Pcbnew config file I see:
>>
>> ModEditFrameMaxUndoItems=0
>> PcbFrameMaxUndoItems=0
>> ModViewFrameMaxUndoItems=0
>>
>>
>> This is result of prefixing the frame name to "MaxUndoItem".  I don't
>> know why we don't use separate sections for each frame rather than
>> prefixing the frame name to the config entry string but we do.  It's
>> been that way since I've been with the project and changing it now would
>> break everyone's settings.
>>
>> On 5/11/2016 10:30 AM, Chris Pavlina wrote:
>>> There _is_ no config file entry, unless I'm missing something you can point 
>>> me
>>> to. There was only a global bool flag in pcbnew.h that held the config 
>>> value, I
>>> was not able to find any place that was recorded to disk nor do I see any
>>> evidence of it in my config files. Are you sure there is one?
>>>
>>> On Wed, May 11, 2016 at 10:54:57AM +0200, Tomasz Wlostowski wrote:
 On 10.05.2016 23:41, Chris Pavlina wrote:
> In 6790 I removed the user option to "Dump zone geometry to files when
> filling"; Tom indicated that this was no longer necessary and could be 
> removed.
>
> I left the *code*, however. I took the global flag out of pcbnew.h and 
> replaced
> it with a static const bool in the file where the actual dumping happens, 
> to
> allow this to be switched back on in the future if absolutely necessary.
>
> Particularly @ Tom: should the code be removed as well? How sure are we 
> that
> we'll never need it again? If "mostly sure", I'd advocate for removing 
> it; in
> the unlikely case that that changes we can drag it back out of the rev 
> history.
> If "kinda sure", maybe it can be left in.
>
> What do you think?
>

 I would drop the option from the dialog, but leave the code and the
 config file entry (so that it can be enabled by editing the config file
 only). Zone filling algorithm still has some rare corner case bugs and
 being able to see the intermediate steps of zone filling is a big aid in
 fixing them.

 Cheers,
 Tom

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

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

Re: [Kicad-developers] Dump zone geometry to files when filling

[Chris Pavlina]

Did someone propose changing that? I'm confused.

On Wed, May 11, 2016 at 11:05:23AM -0400, Wayne Stambaugh wrote:
> In the Eeschema config file I see:
> 
> SchematicFrameMaxUndoItems=0
> LibeditFrameMaxUndoItems=0
> ViewlibFrameMaxUndoItems=0
> 
> In the Pcbnew config file I see:
> 
> ModEditFrameMaxUndoItems=0
> PcbFrameMaxUndoItems=0
> ModViewFrameMaxUndoItems=0
> 
> 
> This is result of prefixing the frame name to "MaxUndoItem".  I don't
> know why we don't use separate sections for each frame rather than
> prefixing the frame name to the config entry string but we do.  It's
> been that way since I've been with the project and changing it now would
> break everyone's settings.
> 
> On 5/11/2016 10:30 AM, Chris Pavlina wrote:
> > There _is_ no config file entry, unless I'm missing something you can point 
> > me
> > to. There was only a global bool flag in pcbnew.h that held the config 
> > value, I
> > was not able to find any place that was recorded to disk nor do I see any
> > evidence of it in my config files. Are you sure there is one?
> > 
> > On Wed, May 11, 2016 at 10:54:57AM +0200, Tomasz Wlostowski wrote:
> >> On 10.05.2016 23:41, Chris Pavlina wrote:
> >>> In 6790 I removed the user option to "Dump zone geometry to files when
> >>> filling"; Tom indicated that this was no longer necessary and could be 
> >>> removed.
> >>>
> >>> I left the *code*, however. I took the global flag out of pcbnew.h and 
> >>> replaced
> >>> it with a static const bool in the file where the actual dumping happens, 
> >>> to
> >>> allow this to be switched back on in the future if absolutely necessary.
> >>>
> >>> Particularly @ Tom: should the code be removed as well? How sure are we 
> >>> that
> >>> we'll never need it again? If "mostly sure", I'd advocate for removing 
> >>> it; in
> >>> the unlikely case that that changes we can drag it back out of the rev 
> >>> history.
> >>> If "kinda sure", maybe it can be left in.
> >>>
> >>> What do you think?
> >>>
> >>
> >> I would drop the option from the dialog, but leave the code and the
> >> config file entry (so that it can be enabled by editing the config file
> >> only). Zone filling algorithm still has some rare corner case bugs and
> >> being able to see the intermediate steps of zone filling is a big aid in
> >> fixing them.
> >>
> >> Cheers,
> >> Tom
> >>
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Dump zone geometry to files when filling

[Wayne Stambaugh]

In the Eeschema config file I see:

SchematicFrameMaxUndoItems=0
LibeditFrameMaxUndoItems=0
ViewlibFrameMaxUndoItems=0

In the Pcbnew config file I see:

ModEditFrameMaxUndoItems=0
PcbFrameMaxUndoItems=0
ModViewFrameMaxUndoItems=0


This is result of prefixing the frame name to "MaxUndoItem".  I don't
know why we don't use separate sections for each frame rather than
prefixing the frame name to the config entry string but we do.  It's
been that way since I've been with the project and changing it now would
break everyone's settings.

On 5/11/2016 10:30 AM, Chris Pavlina wrote:
> There _is_ no config file entry, unless I'm missing something you can point me
> to. There was only a global bool flag in pcbnew.h that held the config value, 
> I
> was not able to find any place that was recorded to disk nor do I see any
> evidence of it in my config files. Are you sure there is one?
> 
> On Wed, May 11, 2016 at 10:54:57AM +0200, Tomasz Wlostowski wrote:
>> On 10.05.2016 23:41, Chris Pavlina wrote:
>>> In 6790 I removed the user option to "Dump zone geometry to files when
>>> filling"; Tom indicated that this was no longer necessary and could be 
>>> removed.
>>>
>>> I left the *code*, however. I took the global flag out of pcbnew.h and 
>>> replaced
>>> it with a static const bool in the file where the actual dumping happens, to
>>> allow this to be switched back on in the future if absolutely necessary.
>>>
>>> Particularly @ Tom: should the code be removed as well? How sure are we that
>>> we'll never need it again? If "mostly sure", I'd advocate for removing it; 
>>> in
>>> the unlikely case that that changes we can drag it back out of the rev 
>>> history.
>>> If "kinda sure", maybe it can be left in.
>>>
>>> What do you think?
>>>
>>
>> I would drop the option from the dialog, but leave the code and the
>> config file entry (so that it can be enabled by editing the config file
>> only). Zone filling algorithm still has some rare corner case bugs and
>> being able to see the intermediate steps of zone filling is a big aid in
>> fixing them.
>>
>> Cheers,
>> 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] Dump zone geometry to files when filling

[Chris Pavlina]

There _is_ no config file entry, unless I'm missing something you can point me
to. There was only a global bool flag in pcbnew.h that held the config value, I
was not able to find any place that was recorded to disk nor do I see any
evidence of it in my config files. Are you sure there is one?

On Wed, May 11, 2016 at 10:54:57AM +0200, Tomasz Wlostowski wrote:
> On 10.05.2016 23:41, Chris Pavlina wrote:
> > In 6790 I removed the user option to "Dump zone geometry to files when
> > filling"; Tom indicated that this was no longer necessary and could be 
> > removed.
> > 
> > I left the *code*, however. I took the global flag out of pcbnew.h and 
> > replaced
> > it with a static const bool in the file where the actual dumping happens, to
> > allow this to be switched back on in the future if absolutely necessary.
> > 
> > Particularly @ Tom: should the code be removed as well? How sure are we that
> > we'll never need it again? If "mostly sure", I'd advocate for removing it; 
> > in
> > the unlikely case that that changes we can drag it back out of the rev 
> > history.
> > If "kinda sure", maybe it can be left in.
> > 
> > What do you think?
> > 
> 
> I would drop the option from the dialog, but leave the code and the
> config file entry (so that it can be enabled by editing the config file
> only). Zone filling algorithm still has some rare corner case bugs and
> being able to see the intermediate steps of zone filling is a big aid in
> fixing them.
> 
> Cheers,
> Tom
> 

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

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

[José Ignacio]

What about (ab)using the footprint field (actually the library plugin
system) for this? Say you add a new library plugin called "python",
each library would be a python module (either a single .py file or a
folder with an __init__.py script) That module will have a callable
for each "virtual" footprint. Those callables will take in a
dictionary of key-values and spit out a footprint object. The name of
the callable will be the base name of the footprint, say, Microwave.py
having a Microstrip(**args) will be called out as
Microwave:Microstrip.

To add parameters to the called footprint a dash "-" could be used as
the argument separator (as it is an illegal identifier for python
objects), with an underscore "_" to separate key and value. For
example a microstrip could be called out as
Microwave:Microstrip-W_10mil-L_50mil, which will cause pcbnew to load
Microwave.py and call Microstrip({'W': '10mil', 'L':'50mil'}) . This
allows for some neat things to happen without touching much code in
both eeschema and pcbnew. When the dimensions change in eeschema,
pcbnew will automatically try to fetch the new footprint (which will
call the script) but the rest will be left alone as they have the same
name. This will also allow using the existing footprint archival
facilities to save "baked in" copies of the generated footprints.

To make editing parameters less cumbersome in eeschema it would be
neat to add a feature at netlist generation, for fields with special
names like "footprint(W)" with a value of say "10mil" will cause
eeschema to tack "-W_10mil" at the end of the footprint name when
generating the netlist. The policy for duplicated keys is that the
last one counts, and the keys would be sorted alphabetically to have a
predictable ordering.

Recap:

The features that would be needed for this idea would be:
* A new pcbnew library plugin that calls functions in a python script
to generate footprints based on the footprint name
  - Perhaps later on build a toolkit library to ease the creation of
parametric footprints, an initial hacky version could be to just
generate SEXPRs in python and barf them into the existing kicad_mod
parser.
* A change in the eeschema netlister to append arguments to the footprint name
Format changes needed: none

The python bit is optional actually, the library plugin could be done
in pure C++ if it proves to be easier, but having python access would
be the most flexible.

What do you think of this idea?

On Wed, May 11, 2016 at 8:24 AM, Wayne Stambaugh  wrote:
> On 5/11/2016 6:13 AM, Tomasz Wlostowski wrote:
>> On 09.05.2016 14:38, Wayne Stambaugh wrote:
>>> On 5/4/2016 4:11 PM, Tomasz Wlostowski wrote:
 On 04.05.2016 16:48, Wayne Stambaugh wrote:
> How are you saving this auto generate flag and width/length parameters
> in the schematic?  If you are using component fields or text that's
> fine.  However, please keep in mind that using component fields and text
> is for passing information to third party tools that are not part of
> kicad.  If we are going to support net ties and micro wave component
> generation, we should do that as part of KiCad proper rather than treat
> it like a third party tool which you are proposing.

 Hi Wayne,

 I would store the microwave dimensions as key:value pairs, just like the
 current schematic fields. I think microwave components will be best
 handled by python scripting. These scripts should be IMHO permanently
 included in Kicad distribution, not a 3rd party tool. I chose component
 fields to pass the dimensions information because with every new exotic
 shape (e.g. a Wilkinson power divider instead of a simple microstrip
 line), we would need to add new tokens to the SCH file format and
 netlist specification.
>>>
>>> Hey Tom,
>>>
>>> Would it be easier to provide a python script with a UI to input the
>>> dimensional information used to generate these complex microwave
>>> footprints and just associate them with a schematic symbol rather that
>>> trying to squeeze all of that dimensional information into a field?
>>> This may be more natural for the user to handle.  I understand the
>>> temptation to use fields to do this but I'm not sure this is the easiest
>>> path for users.  I just don't see users be comfortable with this in
>>> terms of usability.  Developers will have no issues with it but I'm
>>> trying to see this from a typical user's point of view.  It might be
>>> worth getting some feedback on the users forum.
>>
>> Hi Wayne,
>>
>> The tools I used in the past (Microwave Office/ADS) keeps all dimensions
>> in user-defined schematic symbol fields. AFAIK Qucs uses the same
>> philosophy. I think most microwave users are aware of this workflow. I
>> find it efficient because during the design/simulation phase I need very
>> often to change the dimensions of microstrip components. Running an
>> external script to update a footprint every time would be IMHO less
>>

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

[Wayne Stambaugh]

On 5/11/2016 6:13 AM, Tomasz Wlostowski wrote:
> On 09.05.2016 14:38, Wayne Stambaugh wrote:
>> On 5/4/2016 4:11 PM, Tomasz Wlostowski wrote:
>>> On 04.05.2016 16:48, Wayne Stambaugh wrote:
 How are you saving this auto generate flag and width/length parameters
 in the schematic?  If you are using component fields or text that's
 fine.  However, please keep in mind that using component fields and text
 is for passing information to third party tools that are not part of
 kicad.  If we are going to support net ties and micro wave component
 generation, we should do that as part of KiCad proper rather than treat
 it like a third party tool which you are proposing. 
>>>
>>> Hi Wayne,
>>>
>>> I would store the microwave dimensions as key:value pairs, just like the
>>> current schematic fields. I think microwave components will be best
>>> handled by python scripting. These scripts should be IMHO permanently
>>> included in Kicad distribution, not a 3rd party tool. I chose component
>>> fields to pass the dimensions information because with every new exotic
>>> shape (e.g. a Wilkinson power divider instead of a simple microstrip
>>> line), we would need to add new tokens to the SCH file format and
>>> netlist specification.
>>
>> Hey Tom,
>>
>> Would it be easier to provide a python script with a UI to input the
>> dimensional information used to generate these complex microwave
>> footprints and just associate them with a schematic symbol rather that
>> trying to squeeze all of that dimensional information into a field?
>> This may be more natural for the user to handle.  I understand the
>> temptation to use fields to do this but I'm not sure this is the easiest
>> path for users.  I just don't see users be comfortable with this in
>> terms of usability.  Developers will have no issues with it but I'm
>> trying to see this from a typical user's point of view.  It might be
>> worth getting some feedback on the users forum.
> 
> Hi Wayne,
> 
> The tools I used in the past (Microwave Office/ADS) keeps all dimensions
> in user-defined schematic symbol fields. AFAIK Qucs uses the same
> philosophy. I think most microwave users are aware of this workflow. I
> find it efficient because during the design/simulation phase I need very
> often to change the dimensions of microstrip components. Running an
> external script to update a footprint every time would be IMHO less
> efficient and error prone.

I hadn't considered the geometry data being passed to a simulator so it
makes sense to keep this information in a field.

> 
> 
> 
>>
>>>
>>> For net ties, there's no schematic/netlist format changes, only PCB.
>>>
>>> I'm wondering how to handle the auto_generate flag. Maybe this one
>>> justifies a separate file format entity connected to a checkbox in the
>>> sch library editor and a text field specifying which plugin/script to run...
>>
>> The only risk I see with using a field as an auto_generate flag is field
>> namespace pollution.  If someone inadvertently uses the auto_generate
>> field name, I image a bunch of script errors would be a bit confusing.
>> This risk is low but it is something to consider.  My proposal would
>> eliminate the need for an auto_generate flag.
> 
> How about keeping this flag outside the user-defined fields.

I'm not sure how that would work without modifying the schematic or
board file formats.  I'm not sure we should modify either file format
since these scripts and the information they require are external to
kicad.  What about using a field that calls out the script to run?  I
don't know if it makes sense to run this every time a new netlist is
generated.  You could always add a menu entry when the netlist is loaded
in Pcbnew to run the script manually.  If we decide to go that route, we
need to define a generic script field since it would be useful for
things other than microwave generation.  The script field could look
something like:

RUN_ script_name:data_field_name:menu_string:other_info

This is just conceptual.  I'm not terribly concerned about the
delimiters or formatting at this point.  Whatever we decide to
implement, it will have to be well documented so users understand how to
use it.

>>
>>>
 I don't want the
 component fields and text used for kicad features.  If you want to
 provide this as an interim solution, I am OK with that.  However, you
 may be creating more work for yourself when we finally get around to
 supporting net ties and micro wave component generation as part of the
 schematic editor. 
>>>
>>> How do you see the role of the schematic editor in generation of
>>> microwave components (in my proposal there's none)?
>>
>> I agree.  I don't pretend to be a microwave expert but AFAIK most if not
>> all microwave features are complex geometrical shapes which should be
>> treated as footprints and associated with a schematic symbol.  I don't
>> see why the schematic editor would need to know anything abou

Re: [Kicad-developers] Maximum undo items

[José Ignacio]

If a setting is removed from the GUI but is still read from the config
files the key name should be changed. Otherwise we'd have a situation
where an unsuspecting user could (accidentally or not) set something
in the UI, upgrade, and then have no way to revert to the default
behavior without editing or deleting the settings file.

On Wed, May 11, 2016 at 7:32 AM, Wayne Stambaugh  wrote:
> At a minimum I would leave the config file entry and the code to access
> the config entries in place so you could manually modify the config file
> for debugging purposes.  @JP, would that be acceptable to you?  I agree
> that we should not expose debugging settings in the UI but I also
> understand the need for development settings without having to create a
> special build just to debug a specific section of code.
>
> On 5/10/2016 3:31 PM, Chris Pavlina wrote:
>> Actually, you might be onto something. Of course you can FRO with the
>> environment vars ;D but perhaps we could leave it an option to be set in the
>> configuration manually for the one time in 2018 JP wants to restrict this for
>> debugging...
>>
>> On Wed, May 11, 2016 at 06:58:58AM +1200, Simon Wells wrote:
>>> or just make it so it always works but is either a command line
>>> option/env variable or manually editing the configuration file
>>>
>>> On Wed, May 11, 2016 at 6:56 AM, Chris Pavlina  
>>> wrote:
 Urgh, do we really need to keep features that a developer may need at some
 point in the future in the UI? This is something that one person may need 
 once
 sometime next year. Can't we make this a #define or something instead?

 We really shouldn't be cluttering everyone's UI with developer-only 
 options.

 On Tue, May 10, 2016 at 08:54:05PM +0200, jp charras wrote:
> Le 10/05/2016 à 20:41, Chris Pavlina a écrit :
>> Back in August (git:aaadb40), I made the undo history infinite in pcbnew,
>> eeschema, modedit, and libedit. Wayne wanted this to remain an option, 
>> in case
>> of issues with the memory consumption of the undo stack. Currently, if 
>> you set
>> "Maximum undo items" to zero, you get infinite history. I also made it 
>> default
>> to unlimited.
>>
>> In the seven months since I did that, has anybody ever needed to limit 
>> that?
>> I've found the memory consumption caused by it to be quite minimal even 
>> on very
>> long layout sessions (I do not often shut my computer down other than to
>> install kernel updates and do not generally close things I'm working on, 
>> so
>> pcbnew can remain open for weeks at a time...).
>>
>> And if nobody has needed to change the limit, can I remove it to reduce 
>> options
>> clutter?
>>
>
> Please, do not remove it.
> For most of users, this option is not useful.
>
> However, developers need to be able to set the value (usually at a low 
> value like 2 or 3) when the
> undo/redo has an issue (usually related to object deletion), even in 
> release mode.
> Sometimes a crash can happen when objects in undo/redo list are deleted, 
> if there is a bug in these
> functions.
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

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

Re: [Kicad-developers] Maximum undo items

[jp charras]

Le 11/05/2016 à 14:32, Wayne Stambaugh a écrit :
> At a minimum I would leave the config file entry and the code to access
> the config entries in place so you could manually modify the config file
> for debugging purposes.  @JP, would that be acceptable to you?  I agree
> that we should not expose debugging settings in the UI but I also
> understand the need for development settings without having to create a
> special build just to debug a specific section of code.

Yes, this is acceptable.

> 
> On 5/10/2016 3:31 PM, Chris Pavlina wrote:
>> Actually, you might be onto something. Of course you can FRO with the
>> environment vars ;D but perhaps we could leave it an option to be set in the
>> configuration manually for the one time in 2018 JP wants to restrict this for
>> debugging...
>>
>> On Wed, May 11, 2016 at 06:58:58AM +1200, Simon Wells wrote:
>>> or just make it so it always works but is either a command line
>>> option/env variable or manually editing the configuration file
>>>
>>> On Wed, May 11, 2016 at 6:56 AM, Chris Pavlina  
>>> wrote:
 Urgh, do we really need to keep features that a developer may need at some
 point in the future in the UI? This is something that one person may need 
 once
 sometime next year. Can't we make this a #define or something instead?

 We really shouldn't be cluttering everyone's UI with developer-only 
 options.

 On Tue, May 10, 2016 at 08:54:05PM +0200, jp charras wrote:
> Le 10/05/2016 à 20:41, Chris Pavlina a écrit :
>> Back in August (git:aaadb40), I made the undo history infinite in pcbnew,
>> eeschema, modedit, and libedit. Wayne wanted this to remain an option, 
>> in case
>> of issues with the memory consumption of the undo stack. Currently, if 
>> you set
>> "Maximum undo items" to zero, you get infinite history. I also made it 
>> default
>> to unlimited.
>>
>> In the seven months since I did that, has anybody ever needed to limit 
>> that?
>> I've found the memory consumption caused by it to be quite minimal even 
>> on very
>> long layout sessions (I do not often shut my computer down other than to
>> install kernel updates and do not generally close things I'm working on, 
>> so
>> pcbnew can remain open for weeks at a time...).
>>
>> And if nobody has needed to change the limit, can I remove it to reduce 
>> options
>> clutter?
>>
>
> Please, do not remove it.
> For most of users, this option is not useful.
>
> However, developers need to be able to set the value (usually at a low 
> value like 2 or 3) when the
> undo/redo has an issue (usually related to object deletion), even in 
> release mode.
> Sometimes a crash can happen when objects in undo/redo list are deleted, 
> if there is a bug in these
> functions.
>
> --
> Jean-Pierre CHARRAS



-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] What are dx and dy?

[Chris Pavlina]

Yup, I wasn't going to leave the function exactly as is. Hotkey should be
pulled from config. I also don't like the way it checks whether an origin has
been set.

On Wed, May 11, 2016 at 09:12:36AM +0200, jp charras wrote:
> Le 11/05/2016 à 00:25, Chris Pavlina a écrit :
> > Ooh, I like! I'll test and merge this tonight if nobody else complains. I 
> > have
> > no problem with showing a hint when no origin has been set.
> > 
> > Note for the future, use _() instead of wxT() to make a string that can be
> > translated - and a couple bits don't follow the defined coding style. I'll 
> > just
> > fix it myself this time though, NBD :)
> 
> About the hint, [space] is not always the right hotkey, because it is 
> editable by the hotkey editor.
> 
> 
> > 
> > On Wed, May 11, 2016 at 12:16:51AM +0200, Martin d'Allens wrote:
> >> I think that the current ruler feature works great. Unfortunately
> >> people don't discover it easily.
> >> There are frequent questions on the user forum that we just answer by
> >> mentioning the space hotkey and how it works.
> >>
> >> Here is a patch that could solve this problem:
> >> https://github.com/KiCad/kicad-source-mirror/compare/master...Caerbannog:master.patch
> >> The patch needs improvements to show the current shortcut if "space"
> >> was changed.
> >>
> >> The idea is to show a hint about the space shortcut instead of the DX
> >> DY values until the key has been pressed.
> >> There is no disadvantage since the DX and DY values will be redundant
> >> with the X and Y until the key has been pressed.
> >>
> 
> 
> 
> -- 
> 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] Maximum undo items

[Wayne Stambaugh]

At a minimum I would leave the config file entry and the code to access
the config entries in place so you could manually modify the config file
for debugging purposes.  @JP, would that be acceptable to you?  I agree
that we should not expose debugging settings in the UI but I also
understand the need for development settings without having to create a
special build just to debug a specific section of code.

On 5/10/2016 3:31 PM, Chris Pavlina wrote:
> Actually, you might be onto something. Of course you can FRO with the
> environment vars ;D but perhaps we could leave it an option to be set in the
> configuration manually for the one time in 2018 JP wants to restrict this for
> debugging...
> 
> On Wed, May 11, 2016 at 06:58:58AM +1200, Simon Wells wrote:
>> or just make it so it always works but is either a command line
>> option/env variable or manually editing the configuration file
>>
>> On Wed, May 11, 2016 at 6:56 AM, Chris Pavlina  
>> wrote:
>>> Urgh, do we really need to keep features that a developer may need at some
>>> point in the future in the UI? This is something that one person may need 
>>> once
>>> sometime next year. Can't we make this a #define or something instead?
>>>
>>> We really shouldn't be cluttering everyone's UI with developer-only options.
>>>
>>> On Tue, May 10, 2016 at 08:54:05PM +0200, jp charras wrote:
 Le 10/05/2016 à 20:41, Chris Pavlina a écrit :
> Back in August (git:aaadb40), I made the undo history infinite in pcbnew,
> eeschema, modedit, and libedit. Wayne wanted this to remain an option, in 
> case
> of issues with the memory consumption of the undo stack. Currently, if 
> you set
> "Maximum undo items" to zero, you get infinite history. I also made it 
> default
> to unlimited.
>
> In the seven months since I did that, has anybody ever needed to limit 
> that?
> I've found the memory consumption caused by it to be quite minimal even 
> on very
> long layout sessions (I do not often shut my computer down other than to
> install kernel updates and do not generally close things I'm working on, 
> so
> pcbnew can remain open for weeks at a time...).
>
> And if nobody has needed to change the limit, can I remove it to reduce 
> options
> clutter?
>

 Please, do not remove it.
 For most of users, this option is not useful.

 However, developers need to be able to set the value (usually at a low 
 value like 2 or 3) when the
 undo/redo has an issue (usually related to object deletion), even in 
 release mode.
 Sometimes a crash can happen when objects in undo/redo list are deleted, 
 if there is a bug in these
 functions.

 --
 Jean-Pierre CHARRAS

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

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

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

[Tomasz Wlostowski]

On 09.05.2016 14:38, Wayne Stambaugh wrote:
> On 5/4/2016 4:11 PM, Tomasz Wlostowski wrote:
>> On 04.05.2016 16:48, Wayne Stambaugh wrote:
>>> How are you saving this auto generate flag and width/length parameters
>>> in the schematic?  If you are using component fields or text that's
>>> fine.  However, please keep in mind that using component fields and text
>>> is for passing information to third party tools that are not part of
>>> kicad.  If we are going to support net ties and micro wave component
>>> generation, we should do that as part of KiCad proper rather than treat
>>> it like a third party tool which you are proposing. 
>>
>> Hi Wayne,
>>
>> I would store the microwave dimensions as key:value pairs, just like the
>> current schematic fields. I think microwave components will be best
>> handled by python scripting. These scripts should be IMHO permanently
>> included in Kicad distribution, not a 3rd party tool. I chose component
>> fields to pass the dimensions information because with every new exotic
>> shape (e.g. a Wilkinson power divider instead of a simple microstrip
>> line), we would need to add new tokens to the SCH file format and
>> netlist specification.
> 
> Hey Tom,
> 
> Would it be easier to provide a python script with a UI to input the
> dimensional information used to generate these complex microwave
> footprints and just associate them with a schematic symbol rather that
> trying to squeeze all of that dimensional information into a field?
> This may be more natural for the user to handle.  I understand the
> temptation to use fields to do this but I'm not sure this is the easiest
> path for users.  I just don't see users be comfortable with this in
> terms of usability.  Developers will have no issues with it but I'm
> trying to see this from a typical user's point of view.  It might be
> worth getting some feedback on the users forum.

Hi Wayne,

The tools I used in the past (Microwave Office/ADS) keeps all dimensions
in user-defined schematic symbol fields. AFAIK Qucs uses the same
philosophy. I think most microwave users are aware of this workflow. I
find it efficient because during the design/simulation phase I need very
often to change the dimensions of microstrip components. Running an
external script to update a footprint every time would be IMHO less
efficient and error prone.



> 
>>
>> For net ties, there's no schematic/netlist format changes, only PCB.
>>
>> I'm wondering how to handle the auto_generate flag. Maybe this one
>> justifies a separate file format entity connected to a checkbox in the
>> sch library editor and a text field specifying which plugin/script to run...
> 
> The only risk I see with using a field as an auto_generate flag is field
> namespace pollution.  If someone inadvertently uses the auto_generate
> field name, I image a bunch of script errors would be a bit confusing.
> This risk is low but it is something to consider.  My proposal would
> eliminate the need for an auto_generate flag.

How about keeping this flag outside the user-defined fields.
> 
>>
>>> I don't want the
>>> component fields and text used for kicad features.  If you want to
>>> provide this as an interim solution, I am OK with that.  However, you
>>> may be creating more work for yourself when we finally get around to
>>> supporting net ties and micro wave component generation as part of the
>>> schematic editor. 
>>
>> How do you see the role of the schematic editor in generation of
>> microwave components (in my proposal there's none)?
> 
> I agree.  I don't pretend to be a microwave expert but AFAIK most if not
> all microwave features are complex geometrical shapes which should be
> treated as footprints and associated with a schematic symbol.  I don't
> see why the schematic editor would need to know anything about microwave
> footprints other than possibly passing parametric information via a
> field to the board editor.

Sure. That's why I proposed to keep the parameters in user fields, as
there's so many microwave design technologies that it would be difficult
to standardize this as an internal Kicad feature. Moreover, the same
dimensions are needed both for simulation and PCB design (relying on the
netlist extracted from the schematics), so IMHO the schematic file is
the most logical place to store dimension information. We shouldn't also
forget about other uses of script-driven footprints (e.g. TouchSense
capacitive buttons/sliders, antennas, multilayer printed transformers),
which can use exactly the same technology.

Cheers,
Tom



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

Re: [Kicad-developers] Dump zone geometry to files when filling

[Tomasz Wlostowski]

On 10.05.2016 23:41, Chris Pavlina wrote:
> In 6790 I removed the user option to "Dump zone geometry to files when
> filling"; Tom indicated that this was no longer necessary and could be 
> removed.
> 
> I left the *code*, however. I took the global flag out of pcbnew.h and 
> replaced
> it with a static const bool in the file where the actual dumping happens, to
> allow this to be switched back on in the future if absolutely necessary.
> 
> Particularly @ Tom: should the code be removed as well? How sure are we that
> we'll never need it again? If "mostly sure", I'd advocate for removing it; in
> the unlikely case that that changes we can drag it back out of the rev 
> history.
> If "kinda sure", maybe it can be left in.
> 
> What do you think?
> 

I would drop the option from the dialog, but leave the code and the
config file entry (so that it can be enabled by editing the config file
only). Zone filling algorithm still has some rare corner case bugs and
being able to see the intermediate steps of zone filling is a big aid in
fixing them.

Cheers,
Tom


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

Re: [Kicad-developers] What are dx and dy?

[Martin d'Allens]

Yes, the patch needs improvements to show the current shortcut if
"space" was changed.

Another little improvement that may be useful is to show the local
coordinates origin with some kind of crosshair.

On Wed, May 11, 2016 at 9:12 AM, jp charras  wrote:
> Le 11/05/2016 à 00:25, Chris Pavlina a écrit :
>> Ooh, I like! I'll test and merge this tonight if nobody else complains. I 
>> have
>> no problem with showing a hint when no origin has been set.
>>
>> Note for the future, use _() instead of wxT() to make a string that can be
>> translated - and a couple bits don't follow the defined coding style. I'll 
>> just
>> fix it myself this time though, NBD :)
>
> About the hint, [space] is not always the right hotkey, because it is 
> editable by the hotkey editor.
>
>
>>
>> On Wed, May 11, 2016 at 12:16:51AM +0200, Martin d'Allens wrote:
>>> I think that the current ruler feature works great. Unfortunately
>>> people don't discover it easily.
>>> There are frequent questions on the user forum that we just answer by
>>> mentioning the space hotkey and how it works.
>>>
>>> Here is a patch that could solve this problem:
>>> https://github.com/KiCad/kicad-source-mirror/compare/master...Caerbannog:master.patch
>>> The patch needs improvements to show the current shortcut if "space"
>>> was changed.
>>>
>>> The idea is to show a hint about the space shortcut instead of the DX
>>> DY values until the key has been pressed.
>>> There is no disadvantage since the DX and DY values will be redundant
>>> with the X and Y until the key has been pressed.
>>>
>
>
>
> --
> 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] mode openGL issues after latest updates

[easyw]

tested with r6788 after a fresh build and it is fine now!
thanks :)


On 10/05/2016 22.41, Maciej Sumiński wrote:

There was another fix for pcbnew crashing with OpenGL GAL applied in
revision 6781, so there is a chance that your problem is already
resolved. I will be grateful for feedback.

Regards,
Orson

On 05/10/2016 09:07 PM, easyw wrote:

Hi,

Are there any particular steps I need to perform? Open pcbnew empty?
Load a specific board? Use the launcher?

I tried just opening pcbnew empty or with a board but when I switch from
legacy to OpenGl it crashes...The same from the kicad launcher...

I tested till rev 6776 ...
I'm going to try a fresh build with latest, cleaning all the files and I
will be back with more info...
thanks


On 10/05/2016 17.50, Maciej Sumiński wrote:

Do you get any error message? I am trying hard to reproduce the problem,
but none of the available PCs expose the bug. I have tried Win7 & Win10
64-bit. Both build with msys2/gcc 5.3, but I still cannot crash pcbnew.

Are there any particular steps I need to perform? Open pcbnew empty?
Load a specific board? Use the launcher?

Regards,
Orson

On 05/09/2016 10:32 PM, easyw wrote:

Hi, I'm having an issue (crash) changing from default canvas to OpenGl

Comparing my settings to the dev pre-built it seems only gcc version is
different; mine is gcc 5.3.0, pre-built is 5.2.0
is there anyone having this problem?

and here there are the settings:

Application: pcbnew
Version: 6776-dev, release build
Libraries: wxWidgets 3.0.2
 libcurl/7.46.0 OpenSSL/1.0.2e zlib/1.2.8 libidn/1.32
libssh2/1.6.0 librtmp/2.3
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian,
wxMSW
- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.57.0
Curl: 7.46.0
KiCad - Compiler: GCC 5.3.0 with C++ ABI 1009
  Settings: USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
USE_FP_LIB_TABLE=HARD_CODED_ON
BUILD_GITHUB_PLUGIN=ON


Application: pcbnew
Version: (2016-05-06 BZR 6776, Git 63decd7)-product, release build
Libraries: wxWidgets 3.0.2
 libcurl/7.46.0 OpenSSL/1.0.2d zlib/1.2.8 libidn/1.32
libssh2/1.6.0 librtmp/2.3
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian,
wxMSW
- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.57.0
Curl: 7.46.0
KiCad - Compiler: GCC 5.2.0 with C++ ABI 1009
  Settings: USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
USE_FP_LIB_TABLE=HARD_CODED_ON
BUILD_GITHUB_PLUGIN=ON


___
Mailing list: https://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] What are dx and dy?

[jp charras]

Le 11/05/2016 à 00:25, Chris Pavlina a écrit :
> Ooh, I like! I'll test and merge this tonight if nobody else complains. I have
> no problem with showing a hint when no origin has been set.
> 
> Note for the future, use _() instead of wxT() to make a string that can be
> translated - and a couple bits don't follow the defined coding style. I'll 
> just
> fix it myself this time though, NBD :)

About the hint, [space] is not always the right hotkey, because it is editable 
by the hotkey editor.


> 
> On Wed, May 11, 2016 at 12:16:51AM +0200, Martin d'Allens wrote:
>> I think that the current ruler feature works great. Unfortunately
>> people don't discover it easily.
>> There are frequent questions on the user forum that we just answer by
>> mentioning the space hotkey and how it works.
>>
>> Here is a patch that could solve this problem:
>> https://github.com/KiCad/kicad-source-mirror/compare/master...Caerbannog:master.patch
>> The patch needs improvements to show the current shortcut if "space"
>> was changed.
>>
>> The idea is to show a hint about the space shortcut instead of the DX
>> DY values until the key has been pressed.
>> There is no disadvantage since the DX and DY values will be redundant
>> with the X and Y until the key has been pressed.
>>



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