Re: [Kicad-developers] eeschema regression

[Seth Hillbrand]

Hi Oliver-

I've had similar issues.  If you can, would you mind testing the attached
patch on Windows?  It offloads the library processing to a thread that runs
when the schematic loads or the library table changes.

It isn't ready for merge consideration yet because I'm not convinced that
the BASE_FRAME is the correct place for it, nor am I completely happy with
the process for figuring out when an update is needed.  But the bones are
in place and I haven't found any bugs yet in Linux or Mac, so please let me
know if it has any adverse effects in Windows.

Best-
Seth

On Fri, Dec 15, 2017 at 6:10 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> I think that there has been a functional regression in a recent build,
> relating to placing symbols in eeschema.
>
> Previously, the libraries were loaded once when the schematic was opened.
>
> now, the entire symbol library set is re-loaded every time you select
> "Place Symbol". This brings up the "loading symbol libraries" progress
> dialog before opening the component selector window.
>
> This is very tedious - especially on Windows where loading symbols can be
> an order of magnitude slower than linux. It really interrupts work flow.
>
> I do not imagine this is intended behaviour? Can anyone comment on this?
>
> Oliver
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>


0001-Eeschema-Asynchronous-library-loading.patch
Description: Binary data
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] eeschema regression

[Oliver Walters]

I think that there has been a functional regression in a recent build,
relating to placing symbols in eeschema.

Previously, the libraries were loaded once when the schematic was opened.

now, the entire symbol library set is re-loaded every time you select
"Place Symbol". This brings up the "loading symbol libraries" progress
dialog before opening the component selector window.

This is very tedious - especially on Windows where loading symbols can be
an order of magnitude slower than linux. It really interrupts work flow.

I do not imagine this is intended behaviour? Can anyone comment on this?

Oliver
___
Mailing list: https://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] Eeschema bus upgrades and new connectivity algorithm

[Chris Pavlina]

Holy crap this is dope. I wanted to do something along similar lines a
long time ago, but I've never had nearly enough time for it. I would use
this stuff SO much.

I love that you demoed it on the project I REALLY wish it existed for :D

On Thu, Dec 14, 2017 at 04:15:34AM +, Jon Evans wrote:
> Hi all,
> 
> As some of you know, I've been working on some new features for Eeschema
> that expand the capabilities of buses.
> These features are not yet complete, but I wanted to share my progress to
> get early feedback.
> 
> Since there are a number of things, I have made a ~4 minute demo video, in
> which I walk through them and discuss:
> 
> https://youtu.be/z6x0xiKgDIc
> 
> In case you don't want to watch the video, here are the new features:
> 
>- The existing style of bus is now referred to as a Bus Vector (for
>example: "A[7..0]")
>- New concept: Bus Groups, for adding arbitrary nets to a bus
>- Defined in a list, separated by spaces, enclosed in curly braces. For
>   example: "{DP DM}"
>   - Can contain bus vectors as well as plain nets, for example
>   "{A[7..0] D[7..0] OE WE}"
>   - Can have an optional name in front, like "MEMORY{A[7..0] D[7..0]}"
>   - If you add a name, the resulting nets will have the name prefixed
>   on the front, like "MEMORY.A7"
>- New concept: Bus Aliases
>   - You can use aliases to define shortcuts for bus groups.
>   - For example, you could create an alias called "USB" that refers to
>   the nets "DP" and "DM"
>   - Then, you can define a bus group as "{USB}" which will contain both
>   of those nets.
>   - You can also add a label, like "USB1{USB}" which will result in
>   nets "USB1.DP" and "USB1.DM"
>   - Bus Aliases are editable through a new dialog, and saved with the
>   schematic file.
>- New tool: Bus Unfolding
>   - Right click on a bus, and you can easily break out any of its
>   members into a bus entry, label, and wire.
>   - You place the label (and set the bus entry orientation) with the
>   first click, and then can continue wiring.
> 
> In order to support this work, I am also working on a new connectivity
> algorithm for Eeschema.
> This algorithm stores the resulting connectivity information with the
> graphical objects on the schematic, meaning that it's quite easy to look up
> what net any particular object is part of.  The new algorithm is also
> significantly (i.e. an order of magnitude) faster at generating
> connectivity than the current netlisting algorithm in my testing so far.
> It will support partial updates of the connectivity when editing the
> schematic, so the net information will always be in sync when
> adding/removing/editing items in the schematic.
> 
> The combination of a faster algorithm and caching of the connectivity
> results in dramatic speedups when working with large designs.
> For example, Chris' motherboard project (which is a great benchmark, by the
> way!) takes several seconds to highlight nets in the current master branch,
> and with my changes, you can highlight any net instantaneously.
> 
> Although it is not yet far enough along to demonstrate this, I plan to use
> this new connectivity algorithm to generate netlists for export, and
> replace the existing algorithm entirely.
> 
> You can check out the code in my branch here, but be warned that it is not
> yet complete, so I am not yet proposing that anyone do exhaustive testing
> of it and report bugs (because I already know about many of the bugs you
> will find :-)
> 
> https://github.com/craftyjon/kicad/tree/bus_upgrades
> 
> Thanks,
> Jon


___
Mailing list: https://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] Wire-bus entry dangling points

[Chris Pavlina]

Interesting, when I added this feature a couple years ago I explicitly
made it display the ends in this case to indicate an "error". I had no
idea it was intended that bus entries be used in this way.

I wish we could come up with a redesign of the bus entries that isn't
visually ambiguous with wires drawn in the exact same shape, since they
don't form connections the same way.

On Fri, Dec 15, 2017 at 06:15:11PM +, Seth Hillbrand wrote:
> The attached patch adjusts how dangling ends are shown for wire-bus entries
> to correct the behavior Nick reported.
> 
> Previously, wire-bus entries were shown as dangling if there was a wire or
> a bus at both ends.  This broke in the case of the Coldfire demo where a
> bus was drawn over a wire and there was also an entry point (see attached
> image coldfire-broken.png).
> 
> The patch implements the logic that if there is _at least_ a wire and a bus
> at each end, that the entry is considered not dangling. (see attached image
> coldfire-fixed.png)
> 
> -Seth


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

Re: [Kicad-developers] macOS 3d-viewer improvements

[Wayne Stambaugh]

Bernhard,

Your patch set fails to build on Linux (Debian testing) with the
following build errors:

In file included from
/home/wayne/src/kicad/kicad-trunk/common/gal/hidpi_gl_canvas.cpp:27:0:
/home/wayne/src/kicad/kicad-trunk/include/gal/hidpi_gl_canvas.h:45:22:
error: ‘wxGLAttributes’ does not name a type; did you mean
‘wxVisualAttributes’?
const wxGLAttributes& dispAttrs,
  ^~
  wxVisualAttributes
/home/wayne/src/kicad/kicad-trunk/common/gal/hidpi_gl_canvas.cpp:31:18:
error: ‘wxGLAttributes’ does not name a type; did you mean
‘wxVisualAttributes’?
const wxGLAttributes& dispAttrs,
  ^~
  wxVisualAttributes
/home/wayne/src/kicad/kicad-trunk/common/gal/hidpi_gl_canvas.cpp: In
constructor ‘HIDPI_GL_CANVAS::HIDPI_GL_CANVAS(wxWindow*, const int&,
wxWindowID, const wxPoint&, const wxSize&, long int, const wxString&,
const wxPalette&)’:
/home/wayne/src/kicad/kicad-trunk/common/gal/hidpi_gl_canvas.cpp:38:72:
error: invalid conversion from ‘wxWindowID {aka int}’ to ‘const int*’
[-fpermissive]
 wxGLCanvas( parent, dispAttrs, id, pos, size, style, name, palette )
^
In file included from /usr/include/wx-3.0/wx/glcanvas.h:195:0,
 from
/home/wayne/src/kicad/kicad-trunk/include/gal/hidpi_gl_canvas.h:30,
 from
/home/wayne/src/kicad/kicad-trunk/common/gal/hidpi_gl_canvas.cpp:27:
/usr/include/wx-3.0/wx/gtk/glcanvas.h:23:5: note:   initializing
argument 3 of ‘wxGLCanvas::wxGLCanvas(wxWindow*, wxWindowID, const int*,
const wxPoint&, const wxSize&, long int, const wxString&, const wxPalette&)’
 wxGLCanvas(wxWindow *parent,
 ^~
common/CMakeFiles/gal.dir/build.make:422: recipe for target
'common/CMakeFiles/gal.dir/gal/hidpi_gl_canvas.cpp.o' failed
make[2]: *** [common/CMakeFiles/gal.dir/gal/hidpi_gl_canvas.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs
In file included from
/home/wayne/src/kicad/kicad-trunk/include/gal/opengl/opengl_gal.h:41:0,
 from
/home/wayne/src/kicad/kicad-trunk/common/gal/opengl/opengl_gal.cpp:29:
/home/wayne/src/kicad/kicad-trunk/include/gal/hidpi_gl_canvas.h:45:22:
error: ‘wxGLAttributes’ does not name a type; did you mean
‘wxVisualAttributes’?
const wxGLAttributes& dispAttrs,
  ^~
  wxVisualAttributes
In file included from
/home/wayne/src/kicad/kicad-trunk/include/gal/opengl/opengl_gal.h:41:0,
 from
/home/wayne/src/kicad/kicad-trunk/common/draw_panel_gal.cpp:37:
/home/wayne/src/kicad/kicad-trunk/include/gal/hidpi_gl_canvas.h:45:22:
error: ‘wxGLAttributes’ does not name a type; did you mean
‘wxVisualAttributes’?
const wxGLAttributes& dispAttrs,
  ^~
  wxVisualAttributes
common/CMakeFiles/gal.dir/build.make:446: recipe for target
'common/CMakeFiles/gal.dir/gal/opengl/opengl_gal.cpp.o' failed
make[2]: *** [common/CMakeFiles/gal.dir/gal/opengl/opengl_gal.cpp.o] Error 1
common/CMakeFiles/gal.dir/build.make:86: recipe for target
'common/CMakeFiles/gal.dir/draw_panel_gal.cpp.o' failed
make[2]: *** [common/CMakeFiles/gal.dir/draw_panel_gal.cpp.o] Error 1
CMakeFiles/Makefile2:360: recipe for target
'common/CMakeFiles/gal.dir/all' failed
make[1]: *** [common/CMakeFiles/gal.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
In file included from
/home/wayne/src/kicad/kicad-trunk/common/../3d-viewer/3d_viewer/../3d_canvas/eda_3d_canvas.h:39:0,
 from
/home/wayne/src/kicad/kicad-trunk/common/../3d-viewer/3d_viewer/eda_3d_viewer.h:37,
 from
/home/wayne/src/kicad/kicad-trunk/pcbnew/basepcbframe.cpp:42:
/home/wayne/src/kicad/kicad-trunk/include/gal/hidpi_gl_canvas.h:45:22:
error: ‘wxGLAttributes’ does not name a type; did you mean
‘wxVisualAttributes’?
const wxGLAttributes& dispAttrs,
  ^~
  wxVisualAttributes
common/CMakeFiles/pcbcommon.dir/build.make:180: recipe for target
'common/CMakeFiles/pcbcommon.dir/__/pcbnew/basepcbframe.cpp.o' failed
make[2]: ***
[common/CMakeFiles/pcbcommon.dir/__/pcbnew/basepcbframe.cpp.o] Error 1
CMakeFiles/Makefile2:400: recipe for target
'common/CMakeFiles/pcbcommon.dir/all' failed
make[1]: *** [common/CMakeFiles/pcbcommon.dir/all] Error 2
Makefile:151: recipe for target 'all' failed
make: *** [all] Error 2


On 12/11/2017 06:52 AM, Bernhard Stegmaier wrote:
> Hi,
> 
> Attached patches improve 3d-viewer on macOS a bit.
> 
> Patches (1)+(2) add Retina support to 3d-viewer just like it was already 
> there for GAL canvas.
> I pulled out all the ugly #ifdef stuff into a new base class, so now all 
> Retina related code for GAL and 3d-viewer is in one class.
> I put it into the gal folder… if you think it shouldn’t be there, please move 
> it to a better spot 

Re: [Kicad-developers] [PATCH] Add double-click handling to disambiguation menu

[Wayne Stambaugh]

Seth,

I was thinking about Seth's macos opengl touch tapping patch but I now
realize that your patch is only relevant to the legacy canvas.  In any
event, I merged your patch.  Keep up the great work!

Thanks,

Wayne

On 12/15/2017 12:34 PM, Seth Hillbrand wrote:
> Wayne-
> 
> Just one.  They are both the same patch (I resent one for Jeff).  It
> should be ready for merging, provided no one has objections.
> 
> -S
> 
> On Fri, Dec 15, 2017 at 9:27 AM, Wayne Stambaugh  > wrote:
> 
> I'm I safe in assuming that both of these patches are ready to be merged
> or is more testing required?
> 
> On 12/15/2017 12:19 PM, Jeff Young wrote:
> > Hi Seth,
> >
> > Yep, works fine for tap and double-tap on OSX.
> >
> > Cheers,
> > Jeff.
> >
> >> On 15 Dec 2017, at 16:29, Seth Hillbrand  
> >> >> 
> wrote:
> >>
> >> Hi Jeff-
> >>
> >> Here is the patch from the original e-mail.
> >>
> >> Best-
> >> Seth
> >>
> >> On Fri, Dec 15, 2017 at 3:35 AM, Jeff Young  
> >> >> wrote:
> >>
> >>     Where can I find the patch (it wasn’t linked to either bug report
> >>     mentioned)?
> >>
> >>     I want to make sure it doesn’t break trackpad double-tapping.
> >>
> >>     Speaking of which, tapping in general is broken in GAL
> >>     (see https://bugs.launchpad.net/kicad/+bug/1737010
> 
> >>      >).  I submitted a
> >>     patch with that bug; any chance we can get it merged along with 
> this?
> >>
> >>     Thanks,
> >>     Jeff
> >>
> >>
> >>>     On 15 Dec 2017, at 04:29, Seth Hillbrand
> >>>     
> >>
> wrote:
> >>>
> >>>     Thanks Chris and Orson for testing.  As long as everyone is OK
> >>>     with the approach, I'm happy to build a second patch to extend
> >>>     this to the GAL canvas.  Does anyone have objections to how this
> >>>     functions in legacy for now?
> >>>
> >>>     Best-
> >>>     Seth
> >>>
> >>>     On Mon, Dec 11, 2017 at 5:02 AM, Maciej Sumiński
> >>>     
> >>
> wrote:
> >>>
> >>>         I tested the patch on Linux and it works as advertised. Well
> >>>         done, we
> >>>         need the same thing for GAL too.
> >>>
> >>>         Cheers,
> >>>         Orson
> >>>
> >>>         On 12/06/2017 07:05 PM, Seth Hillbrand wrote:
> >>>         > ​The attached patch fixes
> >>>         https://bugs.launchpad.net/kicad/+bug/1154020
> 
> >>>          >
> >>>         >
> >>>         > The current double-click handler in draw_panel​ gets
> >>>         overridden by the
> >>>         > disambiguation menu, preventing double-clicks from being
> >>>         properly handled.
> >>>         > This patch introduces a delay between the mouse up and
> >>>         handling the
> >>>         > single-click.  If the double-click arrives in this time,
> >>>         the double-click
> >>>         > is handled.  Otherwise, the normal single-click is
> processed.
> >>>         >
> >>>         > Of note, we only introduce this delay in cases where the
> >>>         disambiguation
> >>>         > menu is needed.  Otherwise, single-clicks are immediately
> >>>         processed.
> >>>         >
> >>>         > Tested on MacOS and Linux.  The current delay is set to
> >>>         250ms.  We might
> >>>         > slow this down to 400-500ms but that felt a bit clunky
> to me.
> >>>         >
> >>>         > -Seth
> >>>         >
> >>>         >
> >>>         >
> >>>         > ___
> >>>         > Mailing list: https://launchpad.net/~kicad-developers
> 
> >>>          >
> >>>         > Post to     : kicad-developers@lists.launchpad.net
> 
> >>>          

[Kicad-developers] [PATCH] Wire-bus entry dangling points

[Seth Hillbrand]

The attached patch adjusts how dangling ends are shown for wire-bus entries
to correct the behavior Nick reported.

Previously, wire-bus entries were shown as dangling if there was a wire or
a bus at both ends.  This broke in the case of the Coldfire demo where a
bus was drawn over a wire and there was also an entry point (see attached
image coldfire-broken.png).

The patch implements the logic that if there is _at least_ a wire and a bus
at each end, that the entry is considered not dangling. (see attached image
coldfire-fixed.png)

-Seth
From 81b9ecd25b46c665ec372d2ea32a409be5b1b797 Mon Sep 17 00:00:00 2001
From: Seth Hillbrand 
Date: Fri, 15 Dec 2017 10:01:19 -0800
Subject: [PATCH] Eeschema: Mark wire-bus entries correctly

Marks wire-bus entries as not dangling if there is at least a wire
and a bus on each end.  Corrects behavior when wires and buses overlap
at the endpoint.
---
 eeschema/sch_bus_entry.cpp | 73 +-
 eeschema/sch_bus_entry.h   |  6 ++--
 2 files changed, 64 insertions(+), 15 deletions(-)

diff --git a/eeschema/sch_bus_entry.cpp b/eeschema/sch_bus_entry.cpp
index a9708103c..01bd70b9d 100644
--- a/eeschema/sch_bus_entry.cpp
+++ b/eeschema/sch_bus_entry.cpp
@@ -201,7 +201,7 @@ void SCH_BUS_ENTRY_BASE::Rotate( wxPoint aPosition )
 }
 
 
-bool SCH_BUS_ENTRY_BASE::IsDanglingStateChanged( std::vector& aItemList )
+bool SCH_BUS_WIRE_ENTRY::IsDanglingStateChanged( std::vector& aItemList )
 {
 bool previousStateStart = m_isDanglingStart;
 bool previousStateEnd = m_isDanglingEnd;
@@ -213,11 +213,9 @@ bool SCH_BUS_ENTRY_BASE::IsDanglingStateChanged( std::vector&
 // when the end position is found.
 wxPoint seg_start;
 
-// Special case: if both items are wires, show as dangling. This is because
-// a bus entry between two wires will look like a connection, but does NOT
-// actually represent one. We need to clarify this for the user.
-bool start_is_wire = false;
-bool end_is_wire = false;
+// Store the connection type and state for the start (0) and end (1)
+bool has_wire[2] = { false };
+bool has_bus[2] = { false };
 
 for( DANGLING_END_ITEM& each_item : aItemList )
 {
@@ -233,11 +231,64 @@ bool SCH_BUS_ENTRY_BASE::IsDanglingStateChanged( std::vector&
 
 case WIRE_END_END:
 if( IsPointOnSegment( seg_start, each_item.GetPosition(), m_pos ) )
-start_is_wire = true;
+has_wire[0] = true;
+
 if( IsPointOnSegment( seg_start, each_item.GetPosition(), m_End() ) )
-end_is_wire = true;
-// Fall through
+has_wire[1] = true;
+
+break;
+
+case BUS_END_END:
+if( IsPointOnSegment( seg_start, each_item.GetPosition(), m_pos ) )
+has_bus[0] = true;
+
+if( IsPointOnSegment( seg_start, each_item.GetPosition(), m_End() ) )
+has_bus[1] = true;
+
+break;
+
+default:
+break;
+}
+}
+
+/**
+ * A bus-wire entry is connected at both ends if it has a bus and a wire on its
+ * ends.  Otherwise, we connect only one end (in the case of a wire-wire or bus-bus)
+ */
+if( ( has_wire[0] && has_bus[1] ) || ( has_wire[1] && has_bus[0] ) )
+m_isDanglingEnd = m_isDanglingStart = false;
+else if( has_wire[0] || has_bus[0] )
+m_isDanglingStart = false;
+else if( has_wire[1] || has_bus[1] )
+m_isDanglingEnd = false;
+
+return (previousStateStart != m_isDanglingStart) || (previousStateEnd != m_isDanglingEnd);
+}
+
+
+bool SCH_BUS_BUS_ENTRY::IsDanglingStateChanged( std::vector& aItemList )
+{
+bool previousStateStart = m_isDanglingStart;
+bool previousStateEnd = m_isDanglingEnd;
 
+m_isDanglingStart = m_isDanglingEnd = true;
+
+// Wires and buses are stored in the list as a pair, start and end. This
+// variable holds the start position from one iteration so it can be used
+// when the end position is found.
+wxPoint seg_start;
+
+for( DANGLING_END_ITEM& each_item : aItemList )
+{
+if( each_item.GetItem() == this )
+continue;
+
+switch( each_item.GetType() )
+{
+case BUS_START_END:
+seg_start = each_item.GetPosition();
+break;
 case BUS_END_END:
 if( IsPointOnSegment( seg_start, each_item.GetPosition(), m_pos ) )
 m_isDanglingStart = false;
@@ -249,10 +300,6 @@ bool SCH_BUS_ENTRY_BASE::IsDanglingStateChanged( std::vector&
 }
 }
 
-// See above: show as dangling if joining two wires
-if( start_is_wire && end_is_wire )
-m_isDanglingStart = m_isDanglingEnd = true;
-
 return (previousStateStart != m_isDanglingStart) || (previousStateEnd != m_isDanglingEnd);
 }
 
diff --git a/eeschema/sch_bus_entry.h b/eeschema/sch_bus_entry.h
index bfe18cecd..fc51873c9 100644
--- 

Re: [Kicad-developers] P-Cad patch

[Eldar Khayrullin]

Are any questions?

В Четверг, 14 дек. 2017 в 9:38 П. П., Eldar Khayrullin 
 написал:

Link to my previous mail
https://lists.launchpad.net/kicad-developers/msg32410.html

В Четверг, 14 дек. 2017 в 9:00 П. П., Maciej Suminski 
 написал:
Thank you for quick tests, I have just pushed both patches to the 
master

branch. Regarding the previous patches - I checked the bug reports
tagged 'pcad' and browsed the mailing list, but I could not find any
patch that had not been applied. Would you point me to them?

Regards,
Orson

On 12/14/2017 06:09 PM, Eldar Khayrullin wrote:
 Hi. I tested your patch. But found another one warning (see my 
patch).

 What about my previous patches for PCAD import improvement?

 В Четверг, 14 дек. 2017 в 6:11 П. П., Maciej Suminski
  написал:

 Hi Eldar,

 I have an impression that you are one of the main P-Cad importer 
users.
 Would you test the attached patch? It fixes a number of warnings 
in the
 P-Cad importer plugin, but I do not have any files to verify the 
code.


 Thank you,
 Orson


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

Re: [Kicad-developers] [PATCH] Add double-click handling to disambiguation menu

[Seth Hillbrand]

Wayne-

Just one.  They are both the same patch (I resent one for Jeff).  It should
be ready for merging, provided no one has objections.

-S

On Fri, Dec 15, 2017 at 9:27 AM, Wayne Stambaugh 
wrote:

> I'm I safe in assuming that both of these patches are ready to be merged
> or is more testing required?
>
> On 12/15/2017 12:19 PM, Jeff Young wrote:
> > Hi Seth,
> >
> > Yep, works fine for tap and double-tap on OSX.
> >
> > Cheers,
> > Jeff.
> >
> >> On 15 Dec 2017, at 16:29, Seth Hillbrand  >> > wrote:
> >>
> >> Hi Jeff-
> >>
> >> Here is the patch from the original e-mail.
> >>
> >> Best-
> >> Seth
> >>
> >> On Fri, Dec 15, 2017 at 3:35 AM, Jeff Young  >> > wrote:
> >>
> >> Where can I find the patch (it wasn’t linked to either bug report
> >> mentioned)?
> >>
> >> I want to make sure it doesn’t break trackpad double-tapping.
> >>
> >> Speaking of which, tapping in general is broken in GAL
> >> (see https://bugs.launchpad.net/kicad/+bug/1737010
> >> ).  I submitted a
> >> patch with that bug; any chance we can get it merged along with
> this?
> >>
> >> Thanks,
> >> Jeff
> >>
> >>
> >>> On 15 Dec 2017, at 04:29, Seth Hillbrand
> >>> >
> wrote:
> >>>
> >>> Thanks Chris and Orson for testing.  As long as everyone is OK
> >>> with the approach, I'm happy to build a second patch to extend
> >>> this to the GAL canvas.  Does anyone have objections to how this
> >>> functions in legacy for now?
> >>>
> >>> Best-
> >>> Seth
> >>>
> >>> On Mon, Dec 11, 2017 at 5:02 AM, Maciej Sumiński
> >>> > wrote:
> >>>
> >>> I tested the patch on Linux and it works as advertised. Well
> >>> done, we
> >>> need the same thing for GAL too.
> >>>
> >>> Cheers,
> >>> Orson
> >>>
> >>> On 12/06/2017 07:05 PM, Seth Hillbrand wrote:
> >>> > ​The attached patch fixes
> >>> https://bugs.launchpad.net/kicad/+bug/1154020
> >>> 
> >>> >
> >>> > The current double-click handler in draw_panel​ gets
> >>> overridden by the
> >>> > disambiguation menu, preventing double-clicks from being
> >>> properly handled.
> >>> > This patch introduces a delay between the mouse up and
> >>> handling the
> >>> > single-click.  If the double-click arrives in this time,
> >>> the double-click
> >>> > is handled.  Otherwise, the normal single-click is processed.
> >>> >
> >>> > Of note, we only introduce this delay in cases where the
> >>> disambiguation
> >>> > menu is needed.  Otherwise, single-clicks are immediately
> >>> processed.
> >>> >
> >>> > Tested on MacOS and Linux.  The current delay is set to
> >>> 250ms.  We might
> >>> > slow this down to 400-500ms but that felt a bit clunky to me.
> >>> >
> >>> > -Seth
> >>> >
> >>> >
> >>> >
> >>> > ___
> >>> > Mailing list: https://launchpad.net/~kicad-developers
> >>> 
> >>> > Post to : kicad-developers@lists.launchpad.net
> >>> 
> >>> > Unsubscribe : https://launchpad.net/~kicad-developers
> >>> 
> >>> > More help   : https://help.launchpad.net/ListHelp
> >>> 
> >>> >
> >>>
> >>>
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> 
> >>> Post to : kicad-developers@lists.launchpad.net
> >>> 
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> 
> >>> More help   : https://help.launchpad.net/ListHelp
> >>> 
> >>>
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> 
> >>> Post to : kicad-developers@lists.launchpad.net
> >>> 
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> 
> >>> More help   : https://help.launchpad.net/ListHelp
> >>> 
> >>
> >>
> >> 

Re: [Kicad-developers] [PATCH] Add double-click handling to disambiguation menu

[Wayne Stambaugh]

I'm I safe in assuming that both of these patches are ready to be merged
or is more testing required?

On 12/15/2017 12:19 PM, Jeff Young wrote:
> Hi Seth,
> 
> Yep, works fine for tap and double-tap on OSX.
> 
> Cheers,
> Jeff.
> 
>> On 15 Dec 2017, at 16:29, Seth Hillbrand > > wrote:
>>
>> Hi Jeff-
>>
>> Here is the patch from the original e-mail.
>>
>> Best-
>> Seth
>>
>> On Fri, Dec 15, 2017 at 3:35 AM, Jeff Young > > wrote:
>>
>> Where can I find the patch (it wasn’t linked to either bug report
>> mentioned)?
>>
>> I want to make sure it doesn’t break trackpad double-tapping.
>>
>> Speaking of which, tapping in general is broken in GAL
>> (see https://bugs.launchpad.net/kicad/+bug/1737010
>> ).  I submitted a
>> patch with that bug; any chance we can get it merged along with this?
>>
>> Thanks,
>> Jeff
>>
>>
>>> On 15 Dec 2017, at 04:29, Seth Hillbrand
>>> > wrote:
>>>
>>> Thanks Chris and Orson for testing.  As long as everyone is OK
>>> with the approach, I'm happy to build a second patch to extend
>>> this to the GAL canvas.  Does anyone have objections to how this
>>> functions in legacy for now?
>>>
>>> Best-
>>> Seth
>>>
>>> On Mon, Dec 11, 2017 at 5:02 AM, Maciej Sumiński
>>> > wrote:
>>>
>>> I tested the patch on Linux and it works as advertised. Well
>>> done, we
>>> need the same thing for GAL too.
>>>
>>> Cheers,
>>> Orson
>>>
>>> On 12/06/2017 07:05 PM, Seth Hillbrand wrote:
>>> > ​The attached patch fixes
>>> https://bugs.launchpad.net/kicad/+bug/1154020
>>> 
>>> >
>>> > The current double-click handler in draw_panel​ gets
>>> overridden by the
>>> > disambiguation menu, preventing double-clicks from being
>>> properly handled.
>>> > This patch introduces a delay between the mouse up and
>>> handling the
>>> > single-click.  If the double-click arrives in this time,
>>> the double-click
>>> > is handled.  Otherwise, the normal single-click is processed.
>>> >
>>> > Of note, we only introduce this delay in cases where the
>>> disambiguation
>>> > menu is needed.  Otherwise, single-clicks are immediately
>>> processed.
>>> >
>>> > Tested on MacOS and Linux.  The current delay is set to
>>> 250ms.  We might
>>> > slow this down to 400-500ms but that felt a bit clunky to me.
>>> >
>>> > -Seth
>>> >
>>> >
>>> >
>>> > ___
>>> > Mailing list: https://launchpad.net/~kicad-developers
>>> 
>>> > Post to     : kicad-developers@lists.launchpad.net
>>> 
>>> > Unsubscribe : https://launchpad.net/~kicad-developers
>>> 
>>> > More help   : https://help.launchpad.net/ListHelp
>>> 
>>> >
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://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
>>> 
>>
>>
>> <0001-wx-Add-double-click-handling-in-disambiguation-cases.patch>
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

[jp charras]

Le 15/12/2017 à 18:16, Andy Peters a écrit :
> 
>> On Dec 13, 2017, at 9:15 PM, Jon Evans  wrote:
>>
>> Hi all,
>>
>> As some of you know, I've been working on some new features for Eeschema 
>> that expand the capabilities of buses.
>> These features are not yet complete, but I wanted to share my progress to 
>> get early feedback.
> 
> User perspective: I think the whole idea is GREAT, and I have one question: 
> can a bus be brought up through the hierarchy in the same way as a single 
> net, perhaps using a (new) Bus Hierarchical Label? Kicad schematics _really_ 
> need this feature.
> 
> Thanks,
> -a

Currently, a bus be brought up through the hierarchy.
Bus hierarchical labels and Bus global labels exist.

-- 
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] [PATCH] Add double-click handling to disambiguation menu

[Jeff Young]

Hi Seth,

Yep, works fine for tap and double-tap on OSX.

Cheers,
Jeff.

> On 15 Dec 2017, at 16:29, Seth Hillbrand  wrote:
> 
> Hi Jeff-
> 
> Here is the patch from the original e-mail.
> 
> Best-
> Seth
> 
> On Fri, Dec 15, 2017 at 3:35 AM, Jeff Young  > wrote:
> Where can I find the patch (it wasn’t linked to either bug report mentioned)?
> 
> I want to make sure it doesn’t break trackpad double-tapping.
> 
> Speaking of which, tapping in general is broken in GAL (see 
> https://bugs.launchpad.net/kicad/+bug/1737010 
> ).  I submitted a patch with 
> that bug; any chance we can get it merged along with this?
> 
> Thanks,
> Jeff
> 
> 
>> On 15 Dec 2017, at 04:29, Seth Hillbrand > > wrote:
>> 
>> Thanks Chris and Orson for testing.  As long as everyone is OK with the 
>> approach, I'm happy to build a second patch to extend this to the GAL 
>> canvas.  Does anyone have objections to how this functions in legacy for now?
>> 
>> Best-
>> Seth
>> 
>> On Mon, Dec 11, 2017 at 5:02 AM, Maciej Sumiński > > wrote:
>> I tested the patch on Linux and it works as advertised. Well done, we
>> need the same thing for GAL too.
>> 
>> Cheers,
>> Orson
>> 
>> On 12/06/2017 07:05 PM, Seth Hillbrand wrote:
>> > ​The attached patch fixes https://bugs.launchpad.net/kicad/+bug/1154020 
>> > 
>> >
>> > The current double-click handler in draw_panel​ gets overridden by the
>> > disambiguation menu, preventing double-clicks from being properly handled.
>> > This patch introduces a delay between the mouse up and handling the
>> > single-click.  If the double-click arrives in this time, the double-click
>> > is handled.  Otherwise, the normal single-click is processed.
>> >
>> > Of note, we only introduce this delay in cases where the disambiguation
>> > menu is needed.  Otherwise, single-clicks are immediately processed.
>> >
>> > Tested on MacOS and Linux.  The current delay is set to 250ms.  We might
>> > slow this down to 400-500ms but that felt a bit clunky to me.
>> >
>> > -Seth
>> >
>> >
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers 
>> > 
>> > Post to : kicad-developers@lists.launchpad.net 
>> > 
>> > Unsubscribe : https://launchpad.net/~kicad-developers 
>> > 
>> > More help   : https://help.launchpad.net/ListHelp 
>> > 
>> >
>> 
>> 
>> 
>> ___
>> Mailing list: https://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 
>> 
> 
> 
> <0001-wx-Add-double-click-handling-in-disambiguation-cases.patch>

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

[Jon Evans]

Yes, buses can travel through hierarchy just like nets -- hierarchical
sheet pins and ports can carry buses or nets, no need for a new type of
label.
In my branch I am currently changing the color of hierarchical ports/pins
that connect buses (to the same color as bus wires)

-Jon

On Fri, Dec 15, 2017 at 12:16 PM, Andy Peters  wrote:

>
> > On Dec 13, 2017, at 9:15 PM, Jon Evans  wrote:
> >
> > Hi all,
> >
> > As some of you know, I've been working on some new features for Eeschema
> that expand the capabilities of buses.
> > These features are not yet complete, but I wanted to share my progress
> to get early feedback.
>
> User perspective: I think the whole idea is GREAT, and I have one
> question: can a bus be brought up through the hierarchy in the same way as
> a single net, perhaps using a (new) Bus Hierarchical Label? Kicad
> schematics _really_ need this feature.
>
> Thanks,
> -a
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

[Andy Peters]

> On Dec 13, 2017, at 9:15 PM, Jon Evans  wrote:
> 
> Hi all,
> 
> As some of you know, I've been working on some new features for Eeschema that 
> expand the capabilities of buses.
> These features are not yet complete, but I wanted to share my progress to get 
> early feedback.

User perspective: I think the whole idea is GREAT, and I have one question: can 
a bus be brought up through the hierarchy in the same way as a single net, 
perhaps using a (new) Bus Hierarchical Label? Kicad schematics _really_ need 
this feature.

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

Re: [Kicad-developers] [PATCH] Correct bus junction behavior

[Seth Hillbrand]

It doesn't but I'll see about fixing that separately.  I don't think that's
a recent issue.  I checked back 1yr and see the same thing, so I think that
issue has been around since ed0f17e (2015).  Let me know if you've seen it
working correctly more recently.

-S

On Fri, Dec 15, 2017 at 4:28 AM, Nick Østergaard  wrote:

> I don't have the possibility to test this patch right now, but does it
> affect the way bus entries are managed? See the the IRQ- bus on the pins
> 87, 88, 89, 90, 91, 94 in the coldfire demo. Since recently the bus entries
> are rendered as not connected in both ends.
>
> 2017-12-15 0:24 GMT+01:00 Seth Hillbrand :
>
>> ​The attached patch ​adds junction management to buses in addition to
>> wires.
>>
>> Of note, this also adds buses to the draggable junctions collection.  Now
>> that junctions are managed internally, it makes sense to allow any
>> collection with a junction to allow draggable junctions.
>>
>> -Seth
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://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] New records with zone filling.

[Heikki Pulkkinen]

Hi

And NEXT! I am going to improve pcbnew connectivity. I am just tired that
waiting in big boards when routed or dragged. Especially when tracks are
added full off my new track features (teardrops, t-junctions, fillet
junctions and rounded track corners). Old algorithm just worked quite fine.


Regards


Heikki

On Mon, Dec 11, 2017 at 12:39 PM, Heikki Pulkkinen 
wrote:

> Hi,
>
> With interest, I try to improve my parallel zone filling. And new records
> are:
>
> Olinuxino A64 board.
> My parallel zone filling with new connectivity algo 4s.
> My parallel zone filling with old connectivity algo 6s.
> Current master 13s.
>
> WRS board.
> My parallel zone filling with new connectivity algo 12s.
> My parallel zone filling with old connectivity algo 2min 37s. Old ratsnest
> calculation spend so much time at this board.
> Current master 1 min 47s.
>
> Olinuxino A64 board with fully teardrops, stitch vias and rounded track
> corners inserted.
> My parallel zone filling with new connectivity algo 2min 16s.
> My parallel zone filling with old connectivity algo 2min 27s.
> Current master 3min 45s.
>
>
>
> Records are to be broken. Other things... that was the question.
>
>
> Regards
>
> Heikki
>
>
___
Mailing list: https://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] Eeschema bus upgrades and new connectivity algorithm

[Jon Evans]

Hi Kevin,

Are you thinking about when someone is editing the schematic later in
eeschema, or when someone exports to a PDF or prints it?
Both concerns have been raised and I think are valid.
I like the idea of some kind of mouseover info, or showing the contents in
the message panel (that one is actually quite easy to implement)
But for the plot/print, perhaps later there could be a feature to generate
some table of buses?
On the other hand, you can always look at when the busses are broken out
into plain nets to see the contents in a printed schematic.

Thanks,
Jon

On Fri, Dec 15, 2017 at 11:27 AM, Kevin Cozens  wrote:

> On 2017-12-13 11:15 PM, Jon Evans wrote:
>
>> As some of you know, I've been working on some new features for Eeschema
>> that expand the capabilities of buses.
>>
> [snip]
>
>> https://youtu.be/z6x0xiKgDIc
>>
>
> Those are some interesting changes to working with buses.
>
> There is one documentation type problem I see is related to use of aliases
> for a bus group.
>
> When you set up the alias for RAM via the menus you only see that one name
> on the schematic for the bus. Someone else looking at the schematic won't
> easily know what signals are included in the bus alias. Even the person who
> originally might forget if they haven't touched the schematic for a while
> and need to go back and make some changes.
>
> --
> Cheers!
>
> Kevin.
>
> http://www.ve3syb.ca/   |"Nerds make the shiny things that
> distract
> Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
> | powerful!"
> #include  | --Chris Hardwick
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Add double-click handling to disambiguation menu

[Seth Hillbrand]

Hi Jeff-

Here is the patch from the original e-mail.

Best-
Seth

On Fri, Dec 15, 2017 at 3:35 AM, Jeff Young  wrote:

> Where can I find the patch (it wasn’t linked to either bug report
> mentioned)?
>
> I want to make sure it doesn’t break trackpad double-tapping.
>
> Speaking of which, tapping in general is broken in GAL (see
> https://bugs.launchpad.net/kicad/+bug/1737010).  I submitted a patch with
> that bug; any chance we can get it merged along with this?
>
> Thanks,
> Jeff
>
>
> On 15 Dec 2017, at 04:29, Seth Hillbrand  wrote:
>
> Thanks Chris and Orson for testing.  As long as everyone is OK with the
> approach, I'm happy to build a second patch to extend this to the GAL
> canvas.  Does anyone have objections to how this functions in legacy for
> now?
>
> Best-
> Seth
>
> On Mon, Dec 11, 2017 at 5:02 AM, Maciej Sumiński 
> wrote:
>
>> I tested the patch on Linux and it works as advertised. Well done, we
>> need the same thing for GAL too.
>>
>> Cheers,
>> Orson
>>
>> On 12/06/2017 07:05 PM, Seth Hillbrand wrote:
>> > ​The attached patch fixes https://bugs.launchpad.net/kicad/+bug/1154020
>> >
>> > The current double-click handler in draw_panel​ gets overridden by the
>> > disambiguation menu, preventing double-clicks from being properly
>> handled.
>> > This patch introduces a delay between the mouse up and handling the
>> > single-click.  If the double-click arrives in this time, the
>> double-click
>> > is handled.  Otherwise, the normal single-click is processed.
>> >
>> > Of note, we only introduce this delay in cases where the disambiguation
>> > menu is needed.  Otherwise, single-clicks are immediately processed.
>> >
>> > Tested on MacOS and Linux.  The current delay is set to 250ms.  We might
>> > slow this down to 400-500ms but that felt a bit clunky to me.
>> >
>> > -Seth
>> >
>> >
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>>
>>
>> ___
>> Mailing list: https://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
>
>
>
From f81476ff706626adf461fedfb348c1656a887eaa Mon Sep 17 00:00:00 2001
From: Seth Hillbrand 
Date: Tue, 5 Dec 2017 21:25:52 -0800
Subject: [PATCH] wx: Add double-click handling in disambiguation cases

Fixes: lp:1154020
* https://bugs.launchpad.net/kicad/+bug/1154020
---
 common/draw_panel.cpp| 36 +++-
 eeschema/lib_collectors.cpp  | 12 
 eeschema/lib_collectors.h|  5 +
 eeschema/libedit_onleftclick.cpp |  2 +-
 eeschema/onleftclick.cpp |  2 +-
 eeschema/sch_collectors.cpp  | 14 ++
 eeschema/sch_collectors.h|  5 +
 include/class_drawpanel.h| 16 
 include/id.h |  2 ++
 9 files changed, 91 insertions(+), 3 deletions(-)

diff --git a/common/draw_panel.cpp b/common/draw_panel.cpp
index 716c1e0d2..bce9376fc 100644
--- a/common/draw_panel.cpp
+++ b/common/draw_panel.cpp
@@ -28,6 +28,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -87,6 +88,7 @@ BEGIN_EVENT_TABLE( EDA_DRAW_PANEL, wxScrolledWindow )
 EVT_ERASE_BACKGROUND( EDA_DRAW_PANEL::OnEraseBackground )
 EVT_SCROLLWIN( EDA_DRAW_PANEL::OnScroll )
 EVT_ACTIVATE( EDA_DRAW_PANEL::OnActivate )
+EVT_TIMER( ID_MOUSE_DOUBLECLICK, EDA_DRAW_PANEL::OnTimer )
 EVT_MENU_RANGE( ID_PAN_UP, ID_PAN_RIGHT, EDA_DRAW_PANEL::OnPan )
 END_EVENT_TABLE()
 
@@ -155,6 +157,9 @@ EDA_DRAW_PANEL::EDA_DRAW_PANEL( EDA_DRAW_FRAME* parent, int id,
 
 m_cursorLevel = 0;
 m_PrintIsMirrored = false;
+
+m_ClickTimer = (wxTimer*) NULL;
+m_doubleClickInterval = 250;
 }
 
 
@@ -168,6 +173,8 @@ EDA_DRAW_PANEL::~EDA_DRAW_PANEL()
 cfg->Write( ENBL_ZOOM_NO_CENTER_KEY, m_enableZoomNoCenter );
 cfg->Write( ENBL_AUTO_PAN_KEY, m_enableAutoPan );
 }
+
+wxDELETE( m_ClickTimer );
 }
 
 
@@ -404,6 +411,14 @@ void EDA_DRAW_PANEL::OnActivate( wxActivateEvent& event )
 }
 
 
+void EDA_DRAW_PANEL::OnTimer( wxTimerEvent& event )
+{
+INSTALL_UNBUFFERED_DC( DC, this );
+DC.SetBackground( *wxBLACK_BRUSH );
+GetParent()->OnLeftClick( , m_CursorClickPos );
+}
+
+
 void EDA_DRAW_PANEL::OnScroll( wxScrollWinEvent& event )
 {
 int id = 

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

[Kevin Cozens]

On 2017-12-13 11:15 PM, Jon Evans wrote:
As some of you know, I've been working on some new features for Eeschema 
that expand the capabilities of buses.

[snip]

https://youtu.be/z6x0xiKgDIc


Those are some interesting changes to working with buses.

There is one documentation type problem I see is related to use of aliases 
for a bus group.


When you set up the alias for RAM via the menus you only see that one name 
on the schematic for the bus. Someone else looking at the schematic won't 
easily know what signals are included in the bus alias. Even the person who 
originally might forget if they haven't touched the schematic for a while 
and need to go back and make some changes.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
| powerful!"
#include  | --Chris Hardwick

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

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

[Wayne Stambaugh]

Jon,

I finally had time to watch your video.  The new bus connection work
looks great!  Hopefully I'll be able to find some time in the not too
distant future to take a look at the code.  I'm really interested in the
new real time connection algorithm.  Keep up the great work.

Cheers,

Wayne

On 12/13/2017 11:15 PM, Jon Evans wrote:
> Hi all,
> 
> As some of you know, I've been working on some new features for Eeschema
> that expand the capabilities of buses.
> These features are not yet complete, but I wanted to share my progress
> to get early feedback.
> 
> Since there are a number of things, I have made a ~4 minute demo video,
> in which I walk through them and discuss:
> 
> https://youtu.be/z6x0xiKgDIc
> 
> In case you don't want to watch the video, here are the new features:
> 
>   * The existing style of bus is now referred to as a Bus Vector (for
> example: "A[7..0]")
>   * New concept: Bus Groups, for adding arbitrary nets to a bus
>   o Defined in a list, separated by spaces, enclosed in curly
> braces. For example: "{DP DM}"
>   o Can contain bus vectors as well as plain nets, for example
> "{A[7..0] D[7..0] OE WE}"
>   o Can have an optional name in front, like "MEMORY{A[7..0] D[7..0]}"
>   o If you add a name, the resulting nets will have the name
> prefixed on the front, like "MEMORY.A7"
>   * New concept: Bus Aliases
>   o You can use aliases to define shortcuts for bus groups.
>   o For example, you could create an alias called "USB" that refers
> to the nets "DP" and "DM"
>   o Then, you can define a bus group as "{USB}" which will contain
> both of those nets.
>   o You can also add a label, like "USB1{USB}" which will result in
> nets "USB1.DP" and "USB1.DM "
>   o Bus Aliases are editable through a new dialog, and saved with
> the schematic file.
>   * New tool: Bus Unfolding
>   o Right click on a bus, and you can easily break out any of its
> members into a bus entry, label, and wire.
>   o You place the label (and set the bus entry orientation) with the
> first click, and then can continue wiring.
> 
> In order to support this work, I am also working on a new connectivity
> algorithm for Eeschema.
> This algorithm stores the resulting connectivity information with the
> graphical objects on the schematic, meaning that it's quite easy to look
> up what net any particular object is part of.  The new algorithm is also
> significantly (i.e. an order of magnitude) faster at generating
> connectivity than the current netlisting algorithm in my testing so
> far.  It will support partial updates of the connectivity when editing
> the schematic, so the net information will always be in sync when
> adding/removing/editing items in the schematic.
> 
> The combination of a faster algorithm and caching of the connectivity
> results in dramatic speedups when working with large designs.
> For example, Chris' motherboard project (which is a great benchmark, by
> the way!) takes several seconds to highlight nets in the current master
> branch, and with my changes, you can highlight any net instantaneously.
> 
> Although it is not yet far enough along to demonstrate this, I plan to
> use this new connectivity algorithm to generate netlists for export, and
> replace the existing algorithm entirely.
> 
> You can check out the code in my branch here, but be warned that it is
> not yet complete, so I am not yet proposing that anyone do exhaustive
> testing of it and report bugs (because I already know about many of the
> bugs you will find :-)
> 
> https://github.com/craftyjon/kicad/tree/bus_upgrades
> 
> Thanks,
> Jon
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


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

Re: [Kicad-developers] [PATCH] Fix quotes in UI messages

[Simon Richter]

Hi,

>> This replaces all single and angle bracket quotes in UI messages with
>> double quotes, for consistency.

>> Sorry to all translators.

> I merged your patch.

If anyone feels like helping the translators out here: there are a
number of translations that are now "fuzzy" because the original string
changed. According to the language overview[1] there are 288 strings per
language that need updating, ideally with the appropriate “typographic”
quotes appropriate for the language (and if you feel like it, also
update the existing \"%s\" that weren't changed).

Please leave the fuzzy markers in place if you're not sure that these
are the result of only the quote change (i.e. if you see in git-diff
that the fuzzy marker was added in your update call, and the msgid
change is formatting only).

   Simon

[1]
http://darine.hogyros.de:8080/job/any-kicad-i18n-head/ws/i18n/i18n_status.csv/*view*/



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

Re: [Kicad-developers] [PATCH] Fix quotes in UI messages

[Wayne Stambaugh]

Simon,

I merged your patch.

Thanks,

Wayne

On 12/15/2017 6:37 AM, Simon Richter wrote:
> 
> This replaces all single and angle bracket quotes in UI messages with
> double quotes, for consistency.
> 
> Sorry to all translators.
> ---
>  bitmap2component/bitmap2cmp_gui.cpp|  8 ++---
>  common/basicframe.cpp  | 16 +-
>  common/common.cpp  |  6 ++--
>  common/dialogs/dialog_env_var_config.cpp   |  2 +-
>  common/dialogs/dialog_page_settings.cpp|  6 ++--
>  common/dialogs/wx_html_report_panel.cpp|  2 +-
>  common/dsnlexer.cpp| 10 +++---
>  common/eda_doc.cpp |  4 +--
>  common/exceptions.cpp  |  2 +-
>  common/footprint_info.cpp  |  2 +-
>  common/fp_lib_table.cpp|  6 ++--
>  common/gestfich.cpp|  6 ++--
>  common/kiway.cpp   |  6 ++--
>  common/project.cpp |  4 +--
>  common/richio.cpp  |  6 ++--
>  common/tool/tool_manager.cpp   |  2 +-
>  common/widgets/widget_hotkey_list.cpp  |  2 +-
>  cvpcb/autosel.cpp  |  4 +--
>  cvpcb/cfg.cpp  |  2 +-
>  cvpcb/class_DisplayFootprintsFrame.cpp |  6 ++--
>  cvpcb/cvpcb_mainframe.cpp  |  4 +--
>  cvpcb/dialogs/dialog_config_equfiles.cpp   |  4 +--
>  cvpcb/readwrite_dlgs.cpp   |  6 ++--
>  eeschema/backanno.cpp  |  2 +-
>  eeschema/block.cpp |  2 +-
>  eeschema/class_library.cpp | 10 +++---
>  eeschema/cmp_tree_model_adapter_base.cpp   |  2 +-
>  eeschema/dialogs/dialog_bom.cpp|  2 +-
>  eeschema/dialogs/dialog_edit_component_in_lib.cpp  | 10 +++---
>  .../dialogs/dialog_edit_component_in_schematic.cpp | 12 
>  eeschema/dialogs/dialog_edit_components_libid.cpp  |  2 +-
>  .../dialogs/dialog_global_sym_lib_table_config.cpp |  8 ++---
>  eeschema/dialogs/dialog_plot_schematic.cpp |  4 +--
>  eeschema/dialogs/dialog_sym_lib_table.cpp  |  4 +--
>  eeschema/dialogs/dialog_symbol_remap.cpp   | 26 
>  eeschema/edit_bitmap.cpp   |  4 +--
>  eeschema/erc.cpp   |  8 ++---
>  eeschema/files-io.cpp  | 30 +-
>  eeschema/getpart.cpp   |  2 +-
>  eeschema/lib_export.cpp| 16 +-
>  eeschema/libarch.cpp   |  2 +-
>  eeschema/libedit.cpp   | 16 +-
>  eeschema/libedit_plot_component.cpp|  2 +-
>  eeschema/libeditframe.cpp  |  6 ++--
>  eeschema/libfield.cpp  |  6 ++--
>  .../netlist_exporters/netlist_exporter_cadstar.cpp |  2 +-
>  .../netlist_exporter_orcadpcb2.cpp |  2 +-
>  eeschema/plot_schematic_DXF.cpp|  4 +--
>  eeschema/plot_schematic_HPGL.cpp   |  4 +--
>  eeschema/plot_schematic_PDF.cpp|  4 +--
>  eeschema/plot_schematic_PS.cpp |  4 +--
>  eeschema/plot_schematic_SVG.cpp|  4 +--
>  eeschema/project_rescue.cpp|  2 +-
>  eeschema/sch_base_frame.cpp|  2 +-
>  eeschema/sch_eagle_plugin.cpp  |  4 +--
>  eeschema/sch_io_mgr.cpp|  4 +--
>  eeschema/sch_legacy_plugin.cpp | 12 
>  eeschema/sch_plugin.cpp|  2 +-
>  eeschema/schframe.cpp  |  6 ++--
>  eeschema/selpart.cpp   |  4 +--
>  eeschema/sheet.cpp | 20 ++--
>  eeschema/sim/spice_value.cpp   |  2 +-
>  eeschema/symbedit.cpp  | 10 +++---
>  eeschema/symbol_lib_table.cpp  |  6 ++--
>  gerbview/events_called_functions.cpp   |  2 +-
>  gerbview/export_to_pcbnew.cpp  |  2 +-
>  gerbview/files.cpp |  6 ++--
>  gerbview/gerbview_frame.cpp|  2 +-
>  gerbview/onrightclick.cpp  |  6 ++--
>  gerbview/readgerb.cpp  |  2 +-
>  gerbview/tools/selection_tool.cpp  |  6 ++--
>  kicad/class_treeproject_item.cpp   |  2 +-
>  kicad/files-io.cpp | 14 -
>  kicad/prjconfig.cpp|  4 +--
>  

Re: [Kicad-developers] for improving doc reports

[Marco Ciampa]

On Fri, Dec 15, 2017 at 12:40:06PM +0100, Nick Østergaard wrote:
> See inline comments.
> 
> 2017-12-15 12:27 GMT+01:00 Marco Ciampa :
> 
> > Hello devs!
> > I would like to ask for a favour to improve the reports for errors in the
> > docs.
> >
> > Since we have some CI engines in place for checking for correctness of
> > the doc source, I am here to ask for a little improvement.
> >
> > in
> >
> > http://docs.kicad-pcb.org/
> >
> > now there is:
> >
> > - all the 4.0.X version of the docs (4.0.0, 4.0.1, 4.0.2, etc.)
> > - under the "stable" dir the last stable version released (an alias for
> > 4.0.7)
> > - under the "master" dir the last correctly compiled version of the
> > ongoing dev master branch
> >
> > I would like to have:
> >
> > - just the last stable version (i.e. 4.0.7) should be enough
> >
> 
> I don't see why we should remove the old ones if we can avoid it. It is
> useful for comparison.

No problem for me.

> 
> > - under the "stable" dir the last correctly compiled version of the
> > ongoing "stable" branch
> >   (i.e. the top of the 4.0 branch)
> >
> 
> I would like to keep it as is with that. But we can add a new dir called
> stable-next or stable-head or stable-5 for the tip of the relevant stable
> branch.

great!

> 
> > - under the "master" dir the last correctly compiled version of the
> > ongoing dev "master" branch
> >   (i.e  the top of the master branch)
> >
> 
> This is what there is now, if I understand you correctly.

yes, sorry I was not clear. I meant it is ok as it is.

> 
> > And also some direct links from the web pages to these pages from here:
> >
> > http://kicad-pcb.org/help/documentation/
> >
> > would be the classic "icing on the cake"
> >
> 
> Direct links to what exactly?

I mean that actually in http://kicad-pcb.org/help/documentation there is
no mention of the existence of the dir http://docs.kicad-pcb.org/
still, there are links that references to the html results from the page

http://kicad-pcb.org/help/documentation/

to 

http://docs.kicad-pcb.org/stable/en/getting_started_in_kicad.html

for example, and to

http://docs.kicad-pcb.org/master/en/plugins.html

I would:

1) make that dir explicit. Something like: See here_ to access all
   documentation files directly (or something like that)... where 
   _here_ is a simple web link to http://docs.kicad-pcb.org

optionally...

2) add links to the "stable-next" (I would call it "stable-devel") and
   "master" (nextversion-devel) sections of the docs formatted in the 
   same way as for the stable docs but in a "under development" section 

TIA

Best regards,

-- 


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




___
Mailing list: https://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] Correct bus junction behavior

[Nick Østergaard]

I don't have the possibility to test this patch right now, but does it
affect the way bus entries are managed? See the the IRQ- bus on the pins
87, 88, 89, 90, 91, 94 in the coldfire demo. Since recently the bus entries
are rendered as not connected in both ends.

2017-12-15 0:24 GMT+01:00 Seth Hillbrand :

> ​The attached patch ​adds junction management to buses in addition to
> wires.
>
> Of note, this also adds buses to the draggable junctions collection.  Now
> that junctions are managed internally, it makes sense to allow any
> collection with a junction to allow draggable junctions.
>
> -Seth
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://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] Some thoughts on symbol remapping

[Wayne Stambaugh]

On 12/14/2017 7:46 PM, Oliver Walters wrote:
> I noticed that your symbol library table uses absolute paths rather than
> using the SYMBOL_LIB_DIR path expansion.  This should not make any
> difference as long as the path you used is the same path as old library
> list look up path.  If it's not, that is your problem.  The remapping
> will not look up by symbol name in the symbol library table if the
> symbol is not found in the original library in the old library list that
> it was loaded from.  I will attempt to explain this again so everyone
> who is having this issue can understand what is happening.
> 
> 
> The sym-lib-table was created by the project-update tool, and I had not
> defined SYMBOL_LIB_DIR. However the generated sym-lib-table did point to
> the libraries I was using previously in this project (v4)
> 
> SYMBOL_LIB_DIR was defined as "C:\msys64\mingw64\share\kicad\library". I
> don't have a build setup on this machine and the signed windows were
> unavailable. This is a jenkins nightly.
> 
> The process makes sense (I think) but the failures are quite transparent.
> 
> Currently the "rescue orphans" procedure in the other dialog works very
> well. Perhaps we could:

Since I didn't write it, I do not know how this code works but if it
looks up by symbol name only and library search order, then it is just
as broken as the previous design and it's only a matter of time before
there is bug report filed against it.

> 
> a) Run this operation after "rescue" if the rescue did not work?

I do not know what rescue didn't work means.  All the rescuer does is
creates a new library from symbols in the cache library that are
different than the library they where loaded from or symbols that are no
longer found in the original library list.  The only way the rescue does
not work is if the cache library file is corrupt or missing in which
case your out of luck.

> b) Explicitly point users to make use of this dialog.
> 
> On Fri, Dec 15, 2017 at 10:42 AM, Wayne Stambaugh  > wrote:
> 
> I noticed that your symbol library table uses absolute paths rather than
> using the SYMBOL_LIB_DIR path expansion.  This should not make any
> difference as long as the path you used is the same path as old library
> list look up path.  If it's not, that is your problem.  The remapping
> will not look up by symbol name in the symbol library table if the
> symbol is not found in the original library in the old library list that
> it was loaded from.  I will attempt to explain this again so everyone
> who is having this issue can understand what is happening.
> 
> Here are the steps that occur for remapping each symbol (not including
> the final rescue since that is just another library in the old project
> library list):
> 
> Find the full path and file name of the old library list lookup method
> used obtain the symbol link.  This is found in LIB_PART::m_library
> member.  This will point to the same library as if you were using stable
> version 4.
> 
> Look for the library by path and full file name in the global symbol
> library table.  If the library cannot be found in the global symbol
> library table and the file exists, add this library to the project
> symbol library table and give it a unique name if necessary.
> 
> Set the symbol library nickname to the entry in the symbol library
> table.
> 
> Once all symbols are remapped, write the project symbol library table
> and refresh if necessary and remove all of the libraries from the old
> project library list.
> 
> I suspect that you are running a development version of kicad that
> cannot find the original symbol libraries in the project library list
> because they are not in a path that it expects them to be in.  You can
> fix this by manually editing the project file to include this path so
> the remapping will work correctly.
> 
> Once the remapping is complete,
> On 12/14/2017 06:05 PM, Oliver Walters wrote:
> > Wayne,
> >
> > Here is the issue I am facing. Maybe I have misunderstood the process,
> > or maybe I have found a bug.
> >
> > 1. Load simple legacy project and attempt to remap. Failures across the
> > board.
> > Inline image 1
> >
> > 2. Check the sym-lib-table
> >
> > Inline image 2
> >
> >
> > 3. Confirm that the symbols do actually exist in the loaded libs
> >
> >
> > Inline image 3
> >
> > 4. No dice
> >
> > Inline image 4
> >
> > 5. Try again?
> >
> > Inline image 5
> >
> > 6. Weep, etc
> >
> > What am I doing wrong?
> >
> > Oliver
> >
> > On Thu, Dec 14, 2017 at 10:41 AM, Wayne Stambaugh  
> > 

Re: [Kicad-developers] [RFC] Eeschema bus upgrades and new connectivity algorithm

[kristoffer Ödmark]

Hmm okay, we seem to differ in opinions once again. But you are right, 
nothing stops me from naming my aliases like that anyway.


I have checked schematics for students, and I know that I  would be very 
confused if the aliases they have used did not immediatly pop up for me 
somehow. Be it syntax, colors or even text-style, maybe making aliases 
appear in *bold *text, indicating they are more than meets the eye, or 
cursive text, or a grey background color?


- Kristoffer


On 2017-12-14 13:17, Maciej Suminski wrote:

If I recall correctly, you are allowed to name an alias using 
format, so there is nothing preventing you from doing so. I would rather
not impose such constraint on aliases, but I am interested in other
opinions.

Regards,
Orson

On 12/14/2017 01:09 PM, kristoffer Ödmark wrote:

Maybe we could adapt from c++ here? having the notation  instead
of {ALIAS}, the same way c++ uses templates.

one could do MEMORY{ D[15..0]}. And get MEMORY.OE MEMORY.WE and
MEMORY D15 etc. Just to be more clear that it is an alias and not a
net-name.

- Kristoffer


On 2017-12-14 12:43, Clemens Koller wrote:

Hello, Jon!

Thank you for your work! I just watched your video and want to give
you some feedback:

I would prefer not to use the term "Bus Vector". A bus is simply a
list (or a collection) of arbitrarily named nets. A bus group would be
- in my understanding - a group of (different) busses.

I like your syntax to represent the list (or collection) {} as well as
an array of nets [].
You first had a bus containing arbitrary nets: MEMORY{A{7..0] D[15..0]
OE WE} and you refer to single nets as i.e. MEMORY.A3 or MEMORY.OE -
fine.

But when you add aliases I run into troubles to keep things
separate/clear:
{RAM} appears to me as an unnamed bus containing the net RAM. WTF is
that?

MEMORY{RAM} appears as a bus named MEMORY containing the single net RAM.
I would expect to access that net via MEMORY.RAM - Oops.

I am definitely irritated by a net MEMORY.OE pulled out of an bus
named MEMORY{RAM}. 8-(
It's impossible to distinguish bus aliases from nets of a bus.

Idea: It might be nice to virtually allow folding/unfolding of the net
collection contained in a bus, i.e. by showing MEMORY{*} or MEMORY{..}
or MEMORY{+}, whereas the '*' or '..' or '+' is shown in a different
colour. If that's still to long, I would not mind renaming the bus to
MEM{..} or even M{..}.
A simple mouseover M{..} could pop-up to show all nets and arrays the
bus contains.

Side note: For big designs, table-based design entry (as well as
design entry by importing tons of generated connections) seems to get
more and more important. It might be wise to consider how busses (and
collections of ) are represented there as well.

Just my five cents,

Clemens

On 2017-12-14 05:15, Jon Evans wrote:

Hi all,

As some of you know, I've been working on some new features for
Eeschema that expand the capabilities of buses.
These features are not yet complete, but I wanted to share my
progress to get early feedback.

Since there are a number of things, I have made a ~4 minute demo
video, in which I walk through them and discuss:

https://youtu.be/z6x0xiKgDIc

In case you don't want to watch the video, here are the new features:

    * The existing style of bus is now referred to as a Bus Vector
(for example: "A[7..0]")
    * New concept: Bus Groups, for adding arbitrary nets to a bus
    o Defined in a list, separated by spaces, enclosed in curly
braces. For example: "{DP DM}"
    o Can contain bus vectors as well as plain nets, for example
"{A[7..0] D[7..0] OE WE}"
    o Can have an optional name in front, like "MEMORY{A[7..0]
D[7..0]}"
    o If you add a name, the resulting nets will have the name
prefixed on the front, like "MEMORY.A7"
    * New concept: Bus Aliases
    o You can use aliases to define shortcuts for bus groups.
    o For example, you could create an alias called "USB" that
refers to the nets "DP" and "DM"
    o Then, you can define a bus group as "{USB}" which will
contain both of those nets.
    o You can also add a label, like "USB1{USB}" which will result
in nets "USB1.DP" and "USB1.DM "
    o Bus Aliases are editable through a new dialog, and saved
with the schematic file.
    * New tool: Bus Unfolding
    o Right click on a bus, and you can easily break out any of
its members into a bus entry, label, and wire.
    o You place the label (and set the bus entry orientation) with
the first click, and then can continue wiring.

In order to support this work, I am also working on a new
connectivity algorithm for Eeschema.
This algorithm stores the resulting connectivity information with the
graphical objects on the schematic, meaning that it's quite easy to
look up what net any particular object is part of.  The new algorithm
is also significantly (i.e. an order of magnitude) faster at
generating connectivity than the current netlisting algorithm in my
testing so far.  It will 

Re: [Kicad-developers] for improving doc reports

[Nick Østergaard]

See inline comments.

2017-12-15 12:27 GMT+01:00 Marco Ciampa :

> Hello devs!
> I would like to ask for a favour to improve the reports for errors in the
> docs.
>
> Since we have some CI engines in place for checking for correctness of
> the doc source, I am here to ask for a little improvement.
>
> in
>
> http://docs.kicad-pcb.org/
>
> now there is:
>
> - all the 4.0.X version of the docs (4.0.0, 4.0.1, 4.0.2, etc.)
> - under the "stable" dir the last stable version released (an alias for
> 4.0.7)
> - under the "master" dir the last correctly compiled version of the
> ongoing dev master branch
>
> I would like to have:
>
> - just the last stable version (i.e. 4.0.7) should be enough
>

I don't see why we should remove the old ones if we can avoid it. It is
useful for comparison.


> - under the "stable" dir the last correctly compiled version of the
> ongoing "stable" branch
>   (i.e. the top of the 4.0 branch)
>

I would like to keep it as is with that. But we can add a new dir called
stable-next or stable-head or stable-5 for the tip of the relevant stable
branch.


> - under the "master" dir the last correctly compiled version of the
> ongoing dev "master" branch
>   (i.e  the top of the master branch)
>

This is what there is now, if I understand you correctly.


> And also some direct links from the web pages to these pages from here:
>
> http://kicad-pcb.org/help/documentation/
>
> would be the classic "icing on the cake"
>

Direct links to what exactly?
___
Mailing list: https://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] Eeschema bus upgrades and new connectivity algorithm

[jp charras]

Le 15/12/2017 à 12:28, Jeff Young a écrit :
> Yeah, definitely stay away from anything non-ASCII in the syntax, but the 
> narrower ellipsis character should be fine for display….

... but not in plot files, as pdf files have a searchable text.
Because Kicad is a internationalized tool, we avoid any non ASCII7 char in 
"system" strings.

> 
>> On 15 Dec 2017, at 10:54, Marco Ciampa  wrote:
>>
>> On Fri, Dec 15, 2017 at 11:38:00AM +0100, Clemens Koller wrote:
>>> On 2017-12-15 11:01, Marco Ciampa wrote:
 On Fri, Dec 15, 2017 at 10:54:01AM +0100, Clemens Koller wrote:

> I was also considering the ellipsis '...' but in classical ASCII, they
> are three characters wide, that's why I ended up with .., + or * to keep
> it short.

 ... and the problem with 3 chars is?
>>>
>>> It takes more space in the schematics.
>>
>> IMHO one more char (if not using Unicode...) is worth for being confusion 
>> proof...
>>
> But since we arrived in Unicode, this can be solved by using the
> horizontal ellipsis single character: U+2026 '…' or in our case the
> midline horizontal ellipsis U+22EF '⋯'.

 Please do _not_ use Unicode for this -please-
>>>
>>> What are the issues you expect?
>>> Since these symbols are only used on display, I would not mind using them.
>>
>> Ok right, I was wrong, forget it. It's not a big issue anyway...
>>
>> --
>>
>>
>> Marco Ciampa


-- 
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] [PATCH] Add double-click handling to disambiguation menu

[Jeff Young]

Where can I find the patch (it wasn’t linked to either bug report mentioned)?

I want to make sure it doesn’t break trackpad double-tapping.

Speaking of which, tapping in general is broken in GAL (see 
https://bugs.launchpad.net/kicad/+bug/1737010).  I submitted a patch with that 
bug; any chance we can get it merged along with this?

Thanks,
Jeff


> On 15 Dec 2017, at 04:29, Seth Hillbrand  wrote:
> 
> Thanks Chris and Orson for testing.  As long as everyone is OK with the 
> approach, I'm happy to build a second patch to extend this to the GAL canvas. 
>  Does anyone have objections to how this functions in legacy for now?
> 
> Best-
> Seth
> 
> On Mon, Dec 11, 2017 at 5:02 AM, Maciej Sumiński  > wrote:
> I tested the patch on Linux and it works as advertised. Well done, we
> need the same thing for GAL too.
> 
> Cheers,
> Orson
> 
> On 12/06/2017 07:05 PM, Seth Hillbrand wrote:
> > ​The attached patch fixes https://bugs.launchpad.net/kicad/+bug/1154020 
> > 
> >
> > The current double-click handler in draw_panel​ gets overridden by the
> > disambiguation menu, preventing double-clicks from being properly handled.
> > This patch introduces a delay between the mouse up and handling the
> > single-click.  If the double-click arrives in this time, the double-click
> > is handled.  Otherwise, the normal single-click is processed.
> >
> > Of note, we only introduce this delay in cases where the disambiguation
> > menu is needed.  Otherwise, single-clicks are immediately processed.
> >
> > Tested on MacOS and Linux.  The current delay is set to 250ms.  We might
> > slow this down to 400-500ms but that felt a bit clunky to me.
> >
> > -Seth
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers 
> > 
> > Post to : kicad-developers@lists.launchpad.net 
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers 
> > 
> > More help   : https://help.launchpad.net/ListHelp 
> > 
> >
> 
> 
> 
> ___
> Mailing list: https://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] for improving doc reports

[Marco Ciampa]

Hello devs!
I would like to ask for a favour to improve the reports for errors in the
docs.

Since we have some CI engines in place for checking for correctness of
the doc source, I am here to ask for a little improvement.

in

http://docs.kicad-pcb.org/

now there is:

- all the 4.0.X version of the docs (4.0.0, 4.0.1, 4.0.2, etc.) 
- under the "stable" dir the last stable version released (an alias for 4.0.7)
- under the "master" dir the last correctly compiled version of the ongoing dev 
master branch

I would like to have:

- just the last stable version (i.e. 4.0.7) should be enough
- under the "stable" dir the last correctly compiled version of the ongoing 
"stable" branch
  (i.e. the top of the 4.0 branch)
- under the "master" dir the last correctly compiled version of the ongoing dev 
"master" branch
  (i.e  the top of the master branch)

And also some direct links from the web pages to these pages from here:

http://kicad-pcb.org/help/documentation/

would be the classic "icing on the cake"

Best regards,

--


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




___
Mailing list: https://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] Eeschema bus upgrades and new connectivity algorithm

[Jeff Young]

Yeah, definitely stay away from anything non-ASCII in the syntax, but the 
narrower ellipsis character should be fine for display….

> On 15 Dec 2017, at 10:54, Marco Ciampa  wrote:
> 
> On Fri, Dec 15, 2017 at 11:38:00AM +0100, Clemens Koller wrote:
>> On 2017-12-15 11:01, Marco Ciampa wrote:
>>> On Fri, Dec 15, 2017 at 10:54:01AM +0100, Clemens Koller wrote:
>>> 
 I was also considering the ellipsis '...' but in classical ASCII, they
 are three characters wide, that's why I ended up with .., + or * to keep
 it short.
>>> 
>>> ... and the problem with 3 chars is?
>> 
>> It takes more space in the schematics.
> 
> IMHO one more char (if not using Unicode...) is worth for being confusion 
> proof...
> 
 But since we arrived in Unicode, this can be solved by using the
 horizontal ellipsis single character: U+2026 '…' or in our case the
 midline horizontal ellipsis U+22EF '⋯'.
>>> 
>>> Please do _not_ use Unicode for this -please-
>> 
>> What are the issues you expect?
>> Since these symbols are only used on display, I would not mind using them.
> 
> Ok right, I was wrong, forget it. It's not a big issue anyway...
> 
> --
> 
> 
> Marco Ciampa
> 
> I know a joke about UDP, but you might not get it.
> 
> 
> 
> GNU/Linux User #78271
> FSFE fellow #364
> 
> 
> 
> 
> ___
> Mailing list: https://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] Eeschema bus upgrades and new connectivity algorithm

[Marco Ciampa]

On Fri, Dec 15, 2017 at 11:38:00AM +0100, Clemens Koller wrote:
> On 2017-12-15 11:01, Marco Ciampa wrote:
> > On Fri, Dec 15, 2017 at 10:54:01AM +0100, Clemens Koller wrote:
> > 
> >> I was also considering the ellipsis '...' but in classical ASCII, they
> >> are three characters wide, that's why I ended up with .., + or * to keep
> >> it short.
> > 
> > ... and the problem with 3 chars is?
> 
> It takes more space in the schematics.

IMHO one more char (if not using Unicode...) is worth for being confusion 
proof...

> >> But since we arrived in Unicode, this can be solved by using the
> >> horizontal ellipsis single character: U+2026 '…' or in our case the
> >> midline horizontal ellipsis U+22EF '⋯'.
> > 
> > Please do _not_ use Unicode for this -please-
> 
> What are the issues you expect?
> Since these symbols are only used on display, I would not mind using them.

Ok right, I was wrong, forget it. It's not a big issue anyway...

--


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




___
Mailing list: https://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] Eeschema bus upgrades and new connectivity algorithm

[Clemens Koller]

On 2017-12-15 11:01, Marco Ciampa wrote:
> On Fri, Dec 15, 2017 at 10:54:01AM +0100, Clemens Koller wrote:
> 
>> I was also considering the ellipsis '...' but in classical ASCII, they
>> are three characters wide, that's why I ended up with .., + or * to keep
>> it short.
> 
> ... and the problem with 3 chars is?

It takes more space in the schematics.

>> But since we arrived in Unicode, this can be solved by using the
>> horizontal ellipsis single character: U+2026 '…' or in our case the
>> midline horizontal ellipsis U+22EF '⋯'.
> 
> Please do _not_ use Unicode for this -please-

What are the issues you expect?
Since these symbols are only used on display, I would not mind using them.


Regards,

Clemens

___
Mailing list: https://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] Eeschema bus upgrades and new connectivity algorithm

[Marco Ciampa]

On Fri, Dec 15, 2017 at 10:54:01AM +0100, Clemens Koller wrote:

> I was also considering the ellipsis '...' but in classical ASCII, they
> are three characters wide, that's why I ended up with .., + or * to keep
> it short.

... and the problem with 3 chars is?

> But since we arrived in Unicode, this can be solved by using the
> horizontal ellipsis single character: U+2026 '…' or in our case the
> midline horizontal ellipsis U+22EF '⋯'.

Please do _not_ use Unicode for this -please-

--


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




___
Mailing list: https://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] Eeschema bus upgrades and new connectivity algorithm

[Clemens Koller]

Hello!

On 2017-12-14 14:08, Marco Ciampa wrote:
>> But when you add aliases I run into troubles to keep things separate/clear:
>> {RAM} appears to me as an unnamed bus containing the net RAM. WTF is that?
>> MEMORY{RAM} appears as a bus named MEMORY containing the single net RAM.
>> I would expect to access that net via MEMORY.RAM - Oops.
>>
>> I am definitely irritated by a net MEMORY.OE pulled out of an bus named 
>> MEMORY{RAM}. 8-(
>> It's impossible to distinguish bus aliases from nets of a bus.
> 
> Apart from the _very_ unpolite expression, I agree here.

Off-Topic: Okay, this really puzzles me. There was really no intention to 
offend somebody personally.
I just used WTF and Oops (talking in monologue) to emphasize that the syntax or 
representation seems inconsistent or confusing to me.
I might also have used a confused smiley like "@:-{" to express that. I am 
really sorry if these phrases are considered very unpolite.
English is not my native language. In case I missed the point here in general, 
maybe somebody could give me feedback off-list.


>> Idea: It might be nice to virtually allow folding/unfolding of the net
>> collection contained in a bus, i.e. by showing MEMORY{*} or MEMORY{..} or
>> MEMORY{+}, whereas the '*' or '..' or '+' is shown in a different colour.
>> If that's still to long, I would not mind renaming the bus to MEM{..} or
>> even M{..}.
> 
> The idea that Clemens is describing here (IIUIC) is that what you really
> nead is _not_ a bus alias (although is a good idea anyway...) but a more
> compact equivalent syntax for a BUS name.

To be more clear, what I've tried to express:
... a more compact representation of a bunch of nets of a bus.
 
A bus name could simply be renamed (locally/per sheet or globally), if it 
appears too long - instead of having an alias defined.
But the possibility to use aliases (for nets and/or busses) is a nice-to-have 
feature.

> Once you have defined bus names like MEMORY{something} and MEMORY.OE for
> the single bus entity, you should be able to write something for just the
> bus name like MEMORY{+} or MEMORY{*} or MEMORY{..} (may I add my 2 cents
> here? Why not MEMORY{...} tree dots to distinguish it from the vector
> syntax?) instead of have to specify always all the bus elements in the
> bus name.
> So you should have on the bus name just this label MEMORY{...} (three
> dots ... I like it!) as a bus description and MEMORY.OE and such as
> connections outputting from the bus.

I was also considering the ellipsis '...' but in classical ASCII, they are 
three characters wide, that's why I ended up with .., + or * to keep it short.
But since we arrived in Unicode, this can be solved by using the horizontal 
ellipsis single character: U+2026 '…' or in our case the midline horizontal 
ellipsis U+22EF '⋯'.

Regards,

Clemens

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