Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-23 Thread Wayne Stambaugh
Oliver,

Understood.  I'm fine with pushing this off until version 6.  I'm pretty
busy myself.

I'm guessing there is a lot of common code that could be refactored.
Given that the new symbol library editor already has a tree view, I
wonder if the symbol library viewer is even necessary.  After playing
around with the new symbol library editor, it seems redundant.  Once the
footprint library editor gets the same make over as the symbol library
editor, getting rid of the views might be something to consider.

Cheers,

Wayne

On 11/23/2017 04:25 PM, Oliver Walters wrote:
> Wayne,
> 
> I feel like I'm running in circles a bit here - I originally had the
> filtering working across all libraries but it was deemed "too slow" to
> load the libraries...
> 
> Now that the symbol editor tree is implemented, I think that is a good
> model for how this filtering should look - at the very least for
> consistency across the windows.
> 
> Perhaps some of that code could be refactored to be somewhat generic...
> 
> I'll put this on hold for now, I'm spreading myself too thin trying to
> get the libraries ready for v5 and implementing some sort of global
> library loader (which seems like it would be needed to satisfy
> requirements here) is too much right now.
> 
> I think (in the future) that the modviewer frame could have a tree style
> selector like the new symbol editor. Then, with a bit of work, the tasks
> of cvpcb could be completely replaced by this window...
> 
> Anyway, if the implemented functionality isn't enough right now, I will
> have to put it aside.
> 
> Thanks
> 
> 
> On Fri, Nov 24, 2017 at 3:20 AM, Wayne Stambaugh  > wrote:
> 
> Oliver,
> 
> It seems to work but I found one issue that will certainly confuse
> users.  Footprint libraries are loaded on demand so until you actually
> select a library in the viewer, there are no footprints to filter.  Even
> after you select a library, only the footprints in the selected library
> are filtered.  I don't think this is what users are going to expect.
> They are going to want a filtered list of all of the footprints in the
> library table not just the footprints in the libraries that have been
> loaded.  You would have to first load all of the footprints before you
> launch the viewer which can take a long time so this may not be
> desirable.  The utility of these changes is questionable until you
> address the library loading issue.
> 
> Cheers,
> 
> Wayne
> 
> On 11/23/2017 07:53 AM, Oliver Walters wrote:
> > Wayne,
> >
> > Based on those line numbers I think you are using an old patch set.
> >
> > Try the attached patch set, I hope this time it works for you :)
> >
> >
> >
> > On Thu, Nov 23, 2017 at 2:01 AM, Wayne Stambaugh  
> > >> wrote:
> >
> >     Oliver,
> >
> >     Here is the stack trace after typing 'r' in the search control.
> >
> >     Thread 1 "kicad" received signal SIGSEGV, Segmentation fault.
> >     0x7fffe0e3a250 in std::vector >     std::default_delete >,
> >     std::allocator >     std::default_delete > > >::size (this=0x10)
> >         at /usr/include/c++/7/bits/stl_vector.h:671
> >     671           { return size_type(this->_M_impl._M_finish -
> >     this->_M_impl._M_start); }
> >     (gdb) bt 10
> >     #0  0x7fffe0e3a250 in
> std::vector >     std::default_delete >,
> >     std::allocator >     std::default_delete > > >::size() const
> (this=0x10)
> >         at /usr/include/c++/7/bits/stl_vector.h:671
> >     #1  0x7fffe0e573c2 in FOOTPRINT_LIST::GetCount() const
> (this=0x0)
> >         at
> /home/wayne/src/kicad/kicad-trunk/include/footprint_info.h:199
> >     #2  0x7fffe14d4138 in FOOTPRINT_FILTER::end()
> (this=0x595049b8)
> >         at
> /home/wayne/src/kicad/kicad-trunk/common/footprint_filter.cpp:231
> >     #3  0x7fffe0bfb006 in FOOTPRINT_VIEWER_FRAME::FilterLibs()
> (this=
> >         0x59502400)
> >         at
> /home/wayne/src/kicad/kicad-trunk/pcbnew/modview_frame.cpp:382
> >     #4  0x7fffe0bfaed0 in
> >     FOOTPRINT_VIEWER_FRAME::OnFilterUpdated(wxCommandEvent&)
> >     (this=0x59502400, event=...)
> >         at
> /home/wayne/src/kicad/kicad-trunk/pcbnew/modview_frame.cpp:362
> >     #5  0x765352ce in
> >     wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase
> const&,
> >     wxEvtHandler*, wxEvent&) ()
> >         at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> >     #6  

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-23 Thread Wayne Stambaugh
Oliver,

It seems to work but I found one issue that will certainly confuse
users.  Footprint libraries are loaded on demand so until you actually
select a library in the viewer, there are no footprints to filter.  Even
after you select a library, only the footprints in the selected library
are filtered.  I don't think this is what users are going to expect.
They are going to want a filtered list of all of the footprints in the
library table not just the footprints in the libraries that have been
loaded.  You would have to first load all of the footprints before you
launch the viewer which can take a long time so this may not be
desirable.  The utility of these changes is questionable until you
address the library loading issue.

Cheers,

Wayne

On 11/23/2017 07:53 AM, Oliver Walters wrote:
> Wayne,
> 
> Based on those line numbers I think you are using an old patch set.
> 
> Try the attached patch set, I hope this time it works for you :)
> 
> 
> 
> On Thu, Nov 23, 2017 at 2:01 AM, Wayne Stambaugh  > wrote:
> 
> Oliver,
> 
> Here is the stack trace after typing 'r' in the search control.
> 
> Thread 1 "kicad" received signal SIGSEGV, Segmentation fault.
> 0x7fffe0e3a250 in std::vector std::default_delete >,
> std::allocator std::default_delete > > >::size (this=0x10)
>     at /usr/include/c++/7/bits/stl_vector.h:671
> 671           { return size_type(this->_M_impl._M_finish -
> this->_M_impl._M_start); }
> (gdb) bt 10
> #0  0x7fffe0e3a250 in std::vector std::default_delete >,
> std::allocator std::default_delete > > >::size() const (this=0x10)
>     at /usr/include/c++/7/bits/stl_vector.h:671
> #1  0x7fffe0e573c2 in FOOTPRINT_LIST::GetCount() const (this=0x0)
>     at /home/wayne/src/kicad/kicad-trunk/include/footprint_info.h:199
> #2  0x7fffe14d4138 in FOOTPRINT_FILTER::end() (this=0x595049b8)
>     at /home/wayne/src/kicad/kicad-trunk/common/footprint_filter.cpp:231
> #3  0x7fffe0bfb006 in FOOTPRINT_VIEWER_FRAME::FilterLibs() (this=
>     0x59502400)
>     at /home/wayne/src/kicad/kicad-trunk/pcbnew/modview_frame.cpp:382
> #4  0x7fffe0bfaed0 in
> FOOTPRINT_VIEWER_FRAME::OnFilterUpdated(wxCommandEvent&)
> (this=0x59502400, event=...)
>     at /home/wayne/src/kicad/kicad-trunk/pcbnew/modview_frame.cpp:362
> #5  0x765352ce in
> wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&,
> wxEvtHandler*, wxEvent&) ()
>     at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #6  0x765353d3 in wxEventHashTable::HandleEvent(wxEvent&,
> wxEvtHandler*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #7  0x7653579b in wxEvtHandler::TryHereOnly(wxEvent&) ()
>     at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #8  0x7fffe1479725 in EDA_BASE_FRAME::ProcessEvent(wxEvent&)
> (this=0x59502400, aEvent=...)
>     at /home/wayne/src/kicad/kicad-trunk/common/basicframe.cpp:187
> #9  0x76535593 in wxEvtHandler::DoTryChain(wxEvent&) ()
>     at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #10 0x76535885 in wxEvtHandler::ProcessEvent(wxEvent&) ()
>     at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> 
> 
> On 11/22/2017 07:33 AM, Oliver Walters wrote:
> > Wayne,
> >
> > That's disappointing. Any further debug info you can provide?
> >
> > On Wed, Nov 22, 2017 at 11:31 PM, Wayne Stambaugh  
> > >> wrote:
> >
> >     Oliver,
> >
> >     I tested your footprint filtering patch set last night and it 
> didn't go
> >     very well.  The very first letter I typed ('r') in the filter 
> control
> >     caused kicad to crash so it's not ready just yet.
> >
> >     Cheers,
> >
> >     Wayne
> >
> >     On 11/20/2017 06:57 PM, Oliver Walters wrote:
> >     > Wayne,
> >     >
> >     > Friendly bump in case this has been forgotten - this thread has 
> wandered
> >     > around a fair bit. Patches 0001 through 0008 are in the email 
> above.
> >     >
> >     > Thanks
> >     >
> >     > On Fri, Nov 17, 2017 at 11:05 PM, Oliver Walters
> >     >  
> >      >
> >      
> >       >     > wrote:
> >     >
> >     >     

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-23 Thread Wayne Stambaugh
Oops!  Wrong email.  Thanks for looking at this.

On 11/23/2017 08:48 AM, Oliver Walters wrote:
> Wayne,
> 
> I think you meant to respond to the other thread. But good point, I
> haven't fixed the step s-expr reader. Why doesn't this use the same
> code? Anyway, I'll have a look.
> 
> On Fri, Nov 24, 2017 at 12:45 AM, Wayne Stambaugh  > wrote:
> 
> Oliver,
> 
> Have you tested the impact of these changes on the step exporter?  I'm
> not sure it will understand the offset keyword and the step export will
> have incorrect model offsets.  Please verify this before I commit these
> patches.  If it creates a lot of work to correct, I'm thinking we should
> just revert the commit that converts the model offset to millimeters.
> 
> Cheers,
> 
> Wayne
> 
> On 11/23/2017 07:53 AM, Oliver Walters wrote:
> > Wayne,
> >
> > Based on those line numbers I think you are using an old patch set.
> >
> > Try the attached patch set, I hope this time it works for you :)
> >
> >
> >
> > On Thu, Nov 23, 2017 at 2:01 AM, Wayne Stambaugh  
> > >> wrote:
> >
> >     Oliver,
> >
> >     Here is the stack trace after typing 'r' in the search control.
> >
> >     Thread 1 "kicad" received signal SIGSEGV, Segmentation fault.
> >     0x7fffe0e3a250 in std::vector >     std::default_delete >,
> >     std::allocator >     std::default_delete > > >::size (this=0x10)
> >         at /usr/include/c++/7/bits/stl_vector.h:671
> >     671           { return size_type(this->_M_impl._M_finish -
> >     this->_M_impl._M_start); }
> >     (gdb) bt 10
> >     #0  0x7fffe0e3a250 in
> std::vector >     std::default_delete >,
> >     std::allocator >     std::default_delete > > >::size() const
> (this=0x10)
> >         at /usr/include/c++/7/bits/stl_vector.h:671
> >     #1  0x7fffe0e573c2 in FOOTPRINT_LIST::GetCount() const
> (this=0x0)
> >         at
> /home/wayne/src/kicad/kicad-trunk/include/footprint_info.h:199
> >     #2  0x7fffe14d4138 in FOOTPRINT_FILTER::end()
> (this=0x595049b8)
> >         at
> /home/wayne/src/kicad/kicad-trunk/common/footprint_filter.cpp:231
> >     #3  0x7fffe0bfb006 in FOOTPRINT_VIEWER_FRAME::FilterLibs()
> (this=
> >         0x59502400)
> >         at
> /home/wayne/src/kicad/kicad-trunk/pcbnew/modview_frame.cpp:382
> >     #4  0x7fffe0bfaed0 in
> >     FOOTPRINT_VIEWER_FRAME::OnFilterUpdated(wxCommandEvent&)
> >     (this=0x59502400, event=...)
> >         at
> /home/wayne/src/kicad/kicad-trunk/pcbnew/modview_frame.cpp:362
> >     #5  0x765352ce in
> >     wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase
> const&,
> >     wxEvtHandler*, wxEvent&) ()
> >         at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> >     #6  0x765353d3 in wxEventHashTable::HandleEvent(wxEvent&,
> >     wxEvtHandler*) () at
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> >     #7  0x7653579b in wxEvtHandler::TryHereOnly(wxEvent&) ()
> >         at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> >     #8  0x7fffe1479725 in EDA_BASE_FRAME::ProcessEvent(wxEvent&)
> >     (this=0x59502400, aEvent=...)
> >         at /home/wayne/src/kicad/kicad-trunk/common/basicframe.cpp:187
> >     #9  0x76535593 in wxEvtHandler::DoTryChain(wxEvent&) ()
> >         at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> >     #10 0x76535885 in wxEvtHandler::ProcessEvent(wxEvent&) ()
> >         at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> >
> >
> >     On 11/22/2017 07:33 AM, Oliver Walters wrote:
> >     > Wayne,
> >     >
> >     > That's disappointing. Any further debug info you can provide?
> >     >
> >     > On Wed, Nov 22, 2017 at 11:31 PM, Wayne Stambaugh
> 
> >
> >     > 
>  >     >
> >     >     Oliver,
> >     >
> >     >     I tested your footprint filtering patch set last night
> and it didn't go
> >     >     very well.  The very first letter I typed ('r') in the
> filter control
> >     >     caused kicad to crash so it's not ready just yet.
> >     >
> >     >     Cheers,
> >     >
> >     >     Wayne
> >     >
> >     >   

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-23 Thread Wayne Stambaugh
Oliver,

Have you tested the impact of these changes on the step exporter?  I'm
not sure it will understand the offset keyword and the step export will
have incorrect model offsets.  Please verify this before I commit these
patches.  If it creates a lot of work to correct, I'm thinking we should
just revert the commit that converts the model offset to millimeters.

Cheers,

Wayne

On 11/23/2017 07:53 AM, Oliver Walters wrote:
> Wayne,
> 
> Based on those line numbers I think you are using an old patch set.
> 
> Try the attached patch set, I hope this time it works for you :)
> 
> 
> 
> On Thu, Nov 23, 2017 at 2:01 AM, Wayne Stambaugh  > wrote:
> 
> Oliver,
> 
> Here is the stack trace after typing 'r' in the search control.
> 
> Thread 1 "kicad" received signal SIGSEGV, Segmentation fault.
> 0x7fffe0e3a250 in std::vector std::default_delete >,
> std::allocator std::default_delete > > >::size (this=0x10)
>     at /usr/include/c++/7/bits/stl_vector.h:671
> 671           { return size_type(this->_M_impl._M_finish -
> this->_M_impl._M_start); }
> (gdb) bt 10
> #0  0x7fffe0e3a250 in std::vector std::default_delete >,
> std::allocator std::default_delete > > >::size() const (this=0x10)
>     at /usr/include/c++/7/bits/stl_vector.h:671
> #1  0x7fffe0e573c2 in FOOTPRINT_LIST::GetCount() const (this=0x0)
>     at /home/wayne/src/kicad/kicad-trunk/include/footprint_info.h:199
> #2  0x7fffe14d4138 in FOOTPRINT_FILTER::end() (this=0x595049b8)
>     at /home/wayne/src/kicad/kicad-trunk/common/footprint_filter.cpp:231
> #3  0x7fffe0bfb006 in FOOTPRINT_VIEWER_FRAME::FilterLibs() (this=
>     0x59502400)
>     at /home/wayne/src/kicad/kicad-trunk/pcbnew/modview_frame.cpp:382
> #4  0x7fffe0bfaed0 in
> FOOTPRINT_VIEWER_FRAME::OnFilterUpdated(wxCommandEvent&)
> (this=0x59502400, event=...)
>     at /home/wayne/src/kicad/kicad-trunk/pcbnew/modview_frame.cpp:362
> #5  0x765352ce in
> wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&,
> wxEvtHandler*, wxEvent&) ()
>     at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #6  0x765353d3 in wxEventHashTable::HandleEvent(wxEvent&,
> wxEvtHandler*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #7  0x7653579b in wxEvtHandler::TryHereOnly(wxEvent&) ()
>     at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #8  0x7fffe1479725 in EDA_BASE_FRAME::ProcessEvent(wxEvent&)
> (this=0x59502400, aEvent=...)
>     at /home/wayne/src/kicad/kicad-trunk/common/basicframe.cpp:187
> #9  0x76535593 in wxEvtHandler::DoTryChain(wxEvent&) ()
>     at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #10 0x76535885 in wxEvtHandler::ProcessEvent(wxEvent&) ()
>     at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> 
> 
> On 11/22/2017 07:33 AM, Oliver Walters wrote:
> > Wayne,
> >
> > That's disappointing. Any further debug info you can provide?
> >
> > On Wed, Nov 22, 2017 at 11:31 PM, Wayne Stambaugh  
> > >> wrote:
> >
> >     Oliver,
> >
> >     I tested your footprint filtering patch set last night and it 
> didn't go
> >     very well.  The very first letter I typed ('r') in the filter 
> control
> >     caused kicad to crash so it's not ready just yet.
> >
> >     Cheers,
> >
> >     Wayne
> >
> >     On 11/20/2017 06:57 PM, Oliver Walters wrote:
> >     > Wayne,
> >     >
> >     > Friendly bump in case this has been forgotten - this thread has 
> wandered
> >     > around a fair bit. Patches 0001 through 0008 are in the email 
> above.
> >     >
> >     > Thanks
> >     >
> >     > On Fri, Nov 17, 2017 at 11:05 PM, Oliver Walters
> >     >  
> >      >
> >      
> >       >     > wrote:
> >     >
> >     >     Wayne,
> >     >
> >     >     Please ignore the previous patch sets. I have made further 
> tweaks
> >     >     and the attached patch set 0001 through 0008 should be 
> considered
> >     >     canonical.
> >     >     .
> >     >     I have fixed a couple of pointer errors, and have also 
> dropped the
> >     >     filter-by-library 

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-22 Thread Wayne Stambaugh
Oliver,

Here is the stack trace after typing 'r' in the search control.

Thread 1 "kicad" received signal SIGSEGV, Segmentation fault.
0x7fffe0e3a250 in std::vector,
std::allocator > >::size (this=0x10)
at /usr/include/c++/7/bits/stl_vector.h:671
671   { return size_type(this->_M_impl._M_finish -
this->_M_impl._M_start); }
(gdb) bt 10
#0  0x7fffe0e3a250 in std::vector,
std::allocator > >::size() const (this=0x10)
at /usr/include/c++/7/bits/stl_vector.h:671
#1  0x7fffe0e573c2 in FOOTPRINT_LIST::GetCount() const (this=0x0)
at /home/wayne/src/kicad/kicad-trunk/include/footprint_info.h:199
#2  0x7fffe14d4138 in FOOTPRINT_FILTER::end() (this=0x595049b8)
at /home/wayne/src/kicad/kicad-trunk/common/footprint_filter.cpp:231
#3  0x7fffe0bfb006 in FOOTPRINT_VIEWER_FRAME::FilterLibs() (this=
0x59502400)
at /home/wayne/src/kicad/kicad-trunk/pcbnew/modview_frame.cpp:382
#4  0x7fffe0bfaed0 in
FOOTPRINT_VIEWER_FRAME::OnFilterUpdated(wxCommandEvent&)
(this=0x59502400, event=...)
at /home/wayne/src/kicad/kicad-trunk/pcbnew/modview_frame.cpp:362
#5  0x765352ce in
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&,
wxEvtHandler*, wxEvent&) ()
at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#6  0x765353d3 in wxEventHashTable::HandleEvent(wxEvent&,
wxEvtHandler*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#7  0x7653579b in wxEvtHandler::TryHereOnly(wxEvent&) ()
at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#8  0x7fffe1479725 in EDA_BASE_FRAME::ProcessEvent(wxEvent&)
(this=0x59502400, aEvent=...)
at /home/wayne/src/kicad/kicad-trunk/common/basicframe.cpp:187
#9  0x76535593 in wxEvtHandler::DoTryChain(wxEvent&) ()
at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#10 0x76535885 in wxEvtHandler::ProcessEvent(wxEvent&) ()
at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0


On 11/22/2017 07:33 AM, Oliver Walters wrote:
> Wayne,
> 
> That's disappointing. Any further debug info you can provide?
> 
> On Wed, Nov 22, 2017 at 11:31 PM, Wayne Stambaugh  > wrote:
> 
> Oliver,
> 
> I tested your footprint filtering patch set last night and it didn't go
> very well.  The very first letter I typed ('r') in the filter control
> caused kicad to crash so it's not ready just yet.
> 
> Cheers,
> 
> Wayne
> 
> On 11/20/2017 06:57 PM, Oliver Walters wrote:
> > Wayne,
> >
> > Friendly bump in case this has been forgotten - this thread has wandered
> > around a fair bit. Patches 0001 through 0008 are in the email above.
> >
> > Thanks
> >
> > On Fri, Nov 17, 2017 at 11:05 PM, Oliver Walters
> >  
>  >>
> > wrote:
> >
> >     Wayne,
> >
> >     Please ignore the previous patch sets. I have made further tweaks
> >     and the attached patch set 0001 through 0008 should be considered
> >     canonical.
> >     .
> >     I have fixed a couple of pointer errors, and have also dropped the
> >     filter-by-library functionality. It was a bit hooky and I'd rather
> >     submit a solid functional set of patches and don't have time to
> >     investigate further.
> >
> >     I hope that the attached patch set meets your standards and can be
> >     merged as-is :)
> >
> >     Thanks!
> >
> >     On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh
> >     
> >> wrote:
> >
> >         On 10/31/2017 5:01 PM, Oliver Walters wrote:
> >         > How should I proceed here then?
> >         >
> >         > I would like to see the various libraries being "cached"
> in the
> >         > background, but this is increasing the scope of the work
> by a large factor.
> >         >
> >         > One thing I have noticed:
> >         >
> >         > In eeschema when you launch the component viewer, it (on
> first run) maps
> >         > and caches all the footprint libraries. This can take
> AGES (especially
> >         > on Windows). However on subsequent launches of the
> component viewer it
> >         > appears instantly. It appears to be keeping a static map
> of the
> >         > footprint library data.
> >         >
> >         > a) Would this be an acceptable approach for the
> footprint viewer window
> >
> >         Sure.  

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-22 Thread Wayne Stambaugh
I already removed the patches from my dev branch so I could work on my
stuff.  I will try to get a stack dump when I get a chance.

On 11/22/2017 07:33 AM, Oliver Walters wrote:
> Wayne,
> 
> That's disappointing. Any further debug info you can provide?
> 
> On Wed, Nov 22, 2017 at 11:31 PM, Wayne Stambaugh  > wrote:
> 
> Oliver,
> 
> I tested your footprint filtering patch set last night and it didn't go
> very well.  The very first letter I typed ('r') in the filter control
> caused kicad to crash so it's not ready just yet.
> 
> Cheers,
> 
> Wayne
> 
> On 11/20/2017 06:57 PM, Oliver Walters wrote:
> > Wayne,
> >
> > Friendly bump in case this has been forgotten - this thread has wandered
> > around a fair bit. Patches 0001 through 0008 are in the email above.
> >
> > Thanks
> >
> > On Fri, Nov 17, 2017 at 11:05 PM, Oliver Walters
> >  
>  >>
> > wrote:
> >
> >     Wayne,
> >
> >     Please ignore the previous patch sets. I have made further tweaks
> >     and the attached patch set 0001 through 0008 should be considered
> >     canonical.
> >     .
> >     I have fixed a couple of pointer errors, and have also dropped the
> >     filter-by-library functionality. It was a bit hooky and I'd rather
> >     submit a solid functional set of patches and don't have time to
> >     investigate further.
> >
> >     I hope that the attached patch set meets your standards and can be
> >     merged as-is :)
> >
> >     Thanks!
> >
> >     On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh
> >     
> >> wrote:
> >
> >         On 10/31/2017 5:01 PM, Oliver Walters wrote:
> >         > How should I proceed here then?
> >         >
> >         > I would like to see the various libraries being "cached"
> in the
> >         > background, but this is increasing the scope of the work
> by a large factor.
> >         >
> >         > One thing I have noticed:
> >         >
> >         > In eeschema when you launch the component viewer, it (on
> first run) maps
> >         > and caches all the footprint libraries. This can take
> AGES (especially
> >         > on Windows). However on subsequent launches of the
> component viewer it
> >         > appears instantly. It appears to be keeping a static map
> of the
> >         > footprint library data.
> >         >
> >         > a) Would this be an acceptable approach for the
> footprint viewer window
> >
> >         Sure.  Code reuse is a good thing.  I'm pretty sure the
> threaded
> >         footprint library code is split out from the component
> chooser so it
> >         should be reusable.
> >
> >         > b) What happens when the library data changes
> externally? Does component
> >         > viewer need to be reloaded?
> >
> >         No, only the library that changed gets reloaded the next
> time it's
> >         accessed.  It is not automatic.  I thought about using
> >         wxFileWatcher but
> >         that could be a lot of overhead for little net gain.  See the
> >         pcb plugin
> >         cache() functions.
> >
> >         > c) Can we globally perform this caching in a background
> thread when
> >         > KiCad launches? This will hide the large pauses (up to a
> minute under
> >         > Windows) from the user...
> >
> >         Yes, this should be done as a project element so that it
> can be
> >         accessed
> >         from all of the main windows.  Please keep in mind, this could
> >         be a lot
> >         of work and given that we are nearing a stable 5 release
> feature
> >         freeze,
> >         so if it's not by then it will not make it into the stable 5
> >         release.
> >
> >         >
> >         > Oliver
> >         >
> >         > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh
> 
> >
> >         > 
>  >         >
> >         >     On 10/31/2017 1:25 AM, Oliver Walters wrote:
> >         >     > Hmm, I had thought that there was a way to load only 
> the *names* of
> >         >     > footprints, rather than individually parsing each 
> 

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-22 Thread Oliver Walters
Wayne,

That's disappointing. Any further debug info you can provide?

On Wed, Nov 22, 2017 at 11:31 PM, Wayne Stambaugh 
wrote:

> Oliver,
>
> I tested your footprint filtering patch set last night and it didn't go
> very well.  The very first letter I typed ('r') in the filter control
> caused kicad to crash so it's not ready just yet.
>
> Cheers,
>
> Wayne
>
> On 11/20/2017 06:57 PM, Oliver Walters wrote:
> > Wayne,
> >
> > Friendly bump in case this has been forgotten - this thread has wandered
> > around a fair bit. Patches 0001 through 0008 are in the email above.
> >
> > Thanks
> >
> > On Fri, Nov 17, 2017 at 11:05 PM, Oliver Walters
> > >
> > wrote:
> >
> > Wayne,
> >
> > Please ignore the previous patch sets. I have made further tweaks
> > and the attached patch set 0001 through 0008 should be considered
> > canonical.
> > .
> > I have fixed a couple of pointer errors, and have also dropped the
> > filter-by-library functionality. It was a bit hooky and I'd rather
> > submit a solid functional set of patches and don't have time to
> > investigate further.
> >
> > I hope that the attached patch set meets your standards and can be
> > merged as-is :)
> >
> > Thanks!
> >
> > On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh
> > > wrote:
> >
> > On 10/31/2017 5:01 PM, Oliver Walters wrote:
> > > How should I proceed here then?
> > >
> > > I would like to see the various libraries being "cached" in the
> > > background, but this is increasing the scope of the work by a
> large factor.
> > >
> > > One thing I have noticed:
> > >
> > > In eeschema when you launch the component viewer, it (on first
> run) maps
> > > and caches all the footprint libraries. This can take AGES
> (especially
> > > on Windows). However on subsequent launches of the component
> viewer it
> > > appears instantly. It appears to be keeping a static map of the
> > > footprint library data.
> > >
> > > a) Would this be an acceptable approach for the footprint
> viewer window
> >
> > Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
> > footprint library code is split out from the component chooser
> so it
> > should be reusable.
> >
> > > b) What happens when the library data changes externally? Does
> component
> > > viewer need to be reloaded?
> >
> > No, only the library that changed gets reloaded the next time
> it's
> > accessed.  It is not automatic.  I thought about using
> > wxFileWatcher but
> > that could be a lot of overhead for little net gain.  See the
> > pcb plugin
> > cache() functions.
> >
> > > c) Can we globally perform this caching in a background thread
> when
> > > KiCad launches? This will hide the large pauses (up to a
> minute under
> > > Windows) from the user...
> >
> > Yes, this should be done as a project element so that it can be
> > accessed
> > from all of the main windows.  Please keep in mind, this could
> > be a lot
> > of work and given that we are nearing a stable 5 release feature
> > freeze,
> > so if it's not by then it will not make it into the stable 5
> > release.
> >
> > >
> > > Oliver
> > >
> > > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh <
> stambau...@gmail.com 
> > > >>
> wrote:
> > >
> > > On 10/31/2017 1:25 AM, Oliver Walters wrote:
> > > > Hmm, I had thought that there was a way to load only the
> *names* of
> > > > footprints, rather than individually parsing each
> footprint file. It
> > > > appears that this is not the case. Any suggestions on
> how the speed
> > > > could be improved? Currently I'm reading out all the
> footprint names in
> > > > each footprint library and only storing the names
> (wxString) rather than
> > > > the MODULE* objects. However, I still have to parse the
> entire library
> > > > on load.
> > > >
> > > > Ideally, I think it would be good to just read in the
> names, and then
> > > > load and display individual MODULE objects on demand..
> Is this possible?
> > >
> > > This is possible (although not implemented) for library
> types (kicad,
> > > geda) that use one file per footprint.  You could just
> read the file
> > > names from the folder and load the files as required.  If
> you want to
> > > search any other properties of 

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-22 Thread Wayne Stambaugh
Oliver,

I tested your footprint filtering patch set last night and it didn't go
very well.  The very first letter I typed ('r') in the filter control
caused kicad to crash so it's not ready just yet.

Cheers,

Wayne

On 11/20/2017 06:57 PM, Oliver Walters wrote:
> Wayne,
> 
> Friendly bump in case this has been forgotten - this thread has wandered
> around a fair bit. Patches 0001 through 0008 are in the email above.
> 
> Thanks
> 
> On Fri, Nov 17, 2017 at 11:05 PM, Oliver Walters
> >
> wrote:
> 
> Wayne,
> 
> Please ignore the previous patch sets. I have made further tweaks
> and the attached patch set 0001 through 0008 should be considered
> canonical.
> .
> I have fixed a couple of pointer errors, and have also dropped the
> filter-by-library functionality. It was a bit hooky and I'd rather
> submit a solid functional set of patches and don't have time to
> investigate further.
> 
> I hope that the attached patch set meets your standards and can be
> merged as-is :)
> 
> Thanks!
> 
> On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh
> > wrote:
> 
> On 10/31/2017 5:01 PM, Oliver Walters wrote:
> > How should I proceed here then?
> >
> > I would like to see the various libraries being "cached" in the
> > background, but this is increasing the scope of the work by a large 
> factor.
> >
> > One thing I have noticed:
> >
> > In eeschema when you launch the component viewer, it (on first run) 
> maps
> > and caches all the footprint libraries. This can take AGES 
> (especially
> > on Windows). However on subsequent launches of the component viewer 
> it
> > appears instantly. It appears to be keeping a static map of the
> > footprint library data.
> >
> > a) Would this be an acceptable approach for the footprint viewer 
> window
> 
> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
> footprint library code is split out from the component chooser so it
> should be reusable.
> 
> > b) What happens when the library data changes externally? Does 
> component
> > viewer need to be reloaded?
> 
> No, only the library that changed gets reloaded the next time it's
> accessed.  It is not automatic.  I thought about using
> wxFileWatcher but
> that could be a lot of overhead for little net gain.  See the
> pcb plugin
> cache() functions.
> 
> > c) Can we globally perform this caching in a background thread when
> > KiCad launches? This will hide the large pauses (up to a minute 
> under
> > Windows) from the user...
> 
> Yes, this should be done as a project element so that it can be
> accessed
> from all of the main windows.  Please keep in mind, this could
> be a lot
> of work and given that we are nearing a stable 5 release feature
> freeze,
> so if it's not by then it will not make it into the stable 5
> release.
> 
> >
> > Oliver
> >
> > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh 
> 
> > >> wrote:
> >
> >     On 10/31/2017 1:25 AM, Oliver Walters wrote:
> >     > Hmm, I had thought that there was a way to load only the 
> *names* of
> >     > footprints, rather than individually parsing each footprint 
> file. It
> >     > appears that this is not the case. Any suggestions on how the 
> speed
> >     > could be improved? Currently I'm reading out all the 
> footprint names in
> >     > each footprint library and only storing the names (wxString) 
> rather than
> >     > the MODULE* objects. However, I still have to parse the 
> entire library
> >     > on load.
> >     >
> >     > Ideally, I think it would be good to just read in the names, 
> and then
> >     > load and display individual MODULE objects on demand.. Is 
> this possible?
> >
> >     This is possible (although not implemented) for library types 
> (kicad,
> >     geda) that use one file per footprint.  You could just read the 
> file
> >     names from the folder and load the files as required.  If you 
> want to
> >     search any other properties of the footprint, then you will 
> have to load
> >     all of the footprints anyway.  I don't know if this would be 
> worth the
> >     effort.
> >
> >     For library types that contain multiple footprints per file 
> (legacy,
> >     Eagle), this wouldn't make much sense.  Parsing the entire 

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-21 Thread Wayne Stambaugh
Oliver,

I didn't forget.  It's still on my todo list.  I just haven't had the
time to review it.  I will do my best to get it reviewed and merged over
the Thanksgiving Holiday before the feature freeze.

Cheers,

Wayne

On 11/20/2017 6:57 PM, Oliver Walters wrote:
> Wayne,
> 
> Friendly bump in case this has been forgotten - this thread has wandered
> around a fair bit. Patches 0001 through 0008 are in the email above.
> 
> Thanks
> 
> On Fri, Nov 17, 2017 at 11:05 PM, Oliver Walters
> >
> wrote:
> 
> Wayne,
> 
> Please ignore the previous patch sets. I have made further tweaks
> and the attached patch set 0001 through 0008 should be considered
> canonical.
> .
> I have fixed a couple of pointer errors, and have also dropped the
> filter-by-library functionality. It was a bit hooky and I'd rather
> submit a solid functional set of patches and don't have time to
> investigate further.
> 
> I hope that the attached patch set meets your standards and can be
> merged as-is :)
> 
> Thanks!
> 
> On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh
> > wrote:
> 
> On 10/31/2017 5:01 PM, Oliver Walters wrote:
> > How should I proceed here then?
> >
> > I would like to see the various libraries being "cached" in the
> > background, but this is increasing the scope of the work by a large 
> factor.
> >
> > One thing I have noticed:
> >
> > In eeschema when you launch the component viewer, it (on first run) 
> maps
> > and caches all the footprint libraries. This can take AGES 
> (especially
> > on Windows). However on subsequent launches of the component viewer 
> it
> > appears instantly. It appears to be keeping a static map of the
> > footprint library data.
> >
> > a) Would this be an acceptable approach for the footprint viewer 
> window
> 
> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
> footprint library code is split out from the component chooser so it
> should be reusable.
> 
> > b) What happens when the library data changes externally? Does 
> component
> > viewer need to be reloaded?
> 
> No, only the library that changed gets reloaded the next time it's
> accessed.  It is not automatic.  I thought about using
> wxFileWatcher but
> that could be a lot of overhead for little net gain.  See the
> pcb plugin
> cache() functions.
> 
> > c) Can we globally perform this caching in a background thread when
> > KiCad launches? This will hide the large pauses (up to a minute 
> under
> > Windows) from the user...
> 
> Yes, this should be done as a project element so that it can be
> accessed
> from all of the main windows.  Please keep in mind, this could
> be a lot
> of work and given that we are nearing a stable 5 release feature
> freeze,
> so if it's not by then it will not make it into the stable 5
> release.
> 
> >
> > Oliver
> >
> > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh 
> 
> > >> wrote:
> >
> >     On 10/31/2017 1:25 AM, Oliver Walters wrote:
> >     > Hmm, I had thought that there was a way to load only the 
> *names* of
> >     > footprints, rather than individually parsing each footprint 
> file. It
> >     > appears that this is not the case. Any suggestions on how the 
> speed
> >     > could be improved? Currently I'm reading out all the 
> footprint names in
> >     > each footprint library and only storing the names (wxString) 
> rather than
> >     > the MODULE* objects. However, I still have to parse the 
> entire library
> >     > on load.
> >     >
> >     > Ideally, I think it would be good to just read in the names, 
> and then
> >     > load and display individual MODULE objects on demand.. Is 
> this possible?
> >
> >     This is possible (although not implemented) for library types 
> (kicad,
> >     geda) that use one file per footprint.  You could just read the 
> file
> >     names from the folder and load the files as required.  If you 
> want to
> >     search any other properties of the footprint, then you will 
> have to load
> >     all of the footprints anyway.  I don't know if this would be 
> worth the
> >     effort.
> >
> >     For library types that contain multiple footprints per file 
> (legacy,
> >     Eagle), this wouldn't make much sense.  Parsing the 

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-20 Thread Oliver Walters
Wayne,

Friendly bump in case this has been forgotten - this thread has wandered
around a fair bit. Patches 0001 through 0008 are in the email above.

Thanks

On Fri, Nov 17, 2017 at 11:05 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Wayne,
>
> Please ignore the previous patch sets. I have made further tweaks and the
> attached patch set 0001 through 0008 should be considered canonical.
> .
> I have fixed a couple of pointer errors, and have also dropped the
> filter-by-library functionality. It was a bit hooky and I'd rather submit a
> solid functional set of patches and don't have time to investigate further.
>
> I hope that the attached patch set meets your standards and can be merged
> as-is :)
>
> Thanks!
>
> On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh 
> wrote:
>
>> On 10/31/2017 5:01 PM, Oliver Walters wrote:
>> > How should I proceed here then?
>> >
>> > I would like to see the various libraries being "cached" in the
>> > background, but this is increasing the scope of the work by a large
>> factor.
>> >
>> > One thing I have noticed:
>> >
>> > In eeschema when you launch the component viewer, it (on first run) maps
>> > and caches all the footprint libraries. This can take AGES (especially
>> > on Windows). However on subsequent launches of the component viewer it
>> > appears instantly. It appears to be keeping a static map of the
>> > footprint library data.
>> >
>> > a) Would this be an acceptable approach for the footprint viewer window
>>
>> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
>> footprint library code is split out from the component chooser so it
>> should be reusable.
>>
>> > b) What happens when the library data changes externally? Does component
>> > viewer need to be reloaded?
>>
>> No, only the library that changed gets reloaded the next time it's
>> accessed.  It is not automatic.  I thought about using wxFileWatcher but
>> that could be a lot of overhead for little net gain.  See the pcb plugin
>> cache() functions.
>>
>> > c) Can we globally perform this caching in a background thread when
>> > KiCad launches? This will hide the large pauses (up to a minute under
>> > Windows) from the user...
>>
>> Yes, this should be done as a project element so that it can be accessed
>> from all of the main windows.  Please keep in mind, this could be a lot
>> of work and given that we are nearing a stable 5 release feature freeze,
>> so if it's not by then it will not make it into the stable 5 release.
>>
>> >
>> > Oliver
>> >
>> > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh > > > wrote:
>> >
>> > On 10/31/2017 1:25 AM, Oliver Walters wrote:
>> > > Hmm, I had thought that there was a way to load only the *names*
>> of
>> > > footprints, rather than individually parsing each footprint file.
>> It
>> > > appears that this is not the case. Any suggestions on how the
>> speed
>> > > could be improved? Currently I'm reading out all the footprint
>> names in
>> > > each footprint library and only storing the names (wxString)
>> rather than
>> > > the MODULE* objects. However, I still have to parse the entire
>> library
>> > > on load.
>> > >
>> > > Ideally, I think it would be good to just read in the names, and
>> then
>> > > load and display individual MODULE objects on demand.. Is this
>> possible?
>> >
>> > This is possible (although not implemented) for library types
>> (kicad,
>> > geda) that use one file per footprint.  You could just read the file
>> > names from the folder and load the files as required.  If you want
>> to
>> > search any other properties of the footprint, then you will have to
>> load
>> > all of the footprints anyway.  I don't know if this would be worth
>> the
>> > effort.
>> >
>> > For library types that contain multiple footprints per file (legacy,
>> > Eagle), this wouldn't make much sense.  Parsing the entire file
>> just to
>> > pick out the footprint names probably isn't going to save you very
>> much
>> > time.
>> >
>> > >
>> > > On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh <
>> stambau...@gmail.com 
>> > > >>
>> wrote:
>> > >
>> > > On 10/30/2017 5:23 PM, Oliver Walters wrote:
>> > > > Thanks for the suggestions on fixing the text. I have that
>> sorted.
>> > > >
>> > > > I will look into different ways of caching footprint data
>> so it is quicker.
>> > > >
>> > > > Wayne, I didn't know about FOOTPRINT_FILTER I will switch
>> to using that
>> > > > instead (and provide regex search).
>> > >
>> > > Thanks Oliver!
>> > >
>> > > >
>> > > > On 31 Oct 2017 06:55, "Seth Hillbrand" <
>> seth.hillbr...@gmail.com 
>> > 

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-17 Thread Oliver Walters
Wayne,

Please ignore the previous patch sets. I have made further tweaks and the
attached patch set 0001 through 0008 should be considered canonical.
.
I have fixed a couple of pointer errors, and have also dropped the
filter-by-library functionality. It was a bit hooky and I'd rather submit a
solid functional set of patches and don't have time to investigate further.

I hope that the attached patch set meets your standards and can be merged
as-is :)

Thanks!

On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh 
wrote:

> On 10/31/2017 5:01 PM, Oliver Walters wrote:
> > How should I proceed here then?
> >
> > I would like to see the various libraries being "cached" in the
> > background, but this is increasing the scope of the work by a large
> factor.
> >
> > One thing I have noticed:
> >
> > In eeschema when you launch the component viewer, it (on first run) maps
> > and caches all the footprint libraries. This can take AGES (especially
> > on Windows). However on subsequent launches of the component viewer it
> > appears instantly. It appears to be keeping a static map of the
> > footprint library data.
> >
> > a) Would this be an acceptable approach for the footprint viewer window
>
> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
> footprint library code is split out from the component chooser so it
> should be reusable.
>
> > b) What happens when the library data changes externally? Does component
> > viewer need to be reloaded?
>
> No, only the library that changed gets reloaded the next time it's
> accessed.  It is not automatic.  I thought about using wxFileWatcher but
> that could be a lot of overhead for little net gain.  See the pcb plugin
> cache() functions.
>
> > c) Can we globally perform this caching in a background thread when
> > KiCad launches? This will hide the large pauses (up to a minute under
> > Windows) from the user...
>
> Yes, this should be done as a project element so that it can be accessed
> from all of the main windows.  Please keep in mind, this could be a lot
> of work and given that we are nearing a stable 5 release feature freeze,
> so if it's not by then it will not make it into the stable 5 release.
>
> >
> > Oliver
> >
> > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh  > > wrote:
> >
> > On 10/31/2017 1:25 AM, Oliver Walters wrote:
> > > Hmm, I had thought that there was a way to load only the *names* of
> > > footprints, rather than individually parsing each footprint file.
> It
> > > appears that this is not the case. Any suggestions on how the speed
> > > could be improved? Currently I'm reading out all the footprint
> names in
> > > each footprint library and only storing the names (wxString)
> rather than
> > > the MODULE* objects. However, I still have to parse the entire
> library
> > > on load.
> > >
> > > Ideally, I think it would be good to just read in the names, and
> then
> > > load and display individual MODULE objects on demand.. Is this
> possible?
> >
> > This is possible (although not implemented) for library types (kicad,
> > geda) that use one file per footprint.  You could just read the file
> > names from the folder and load the files as required.  If you want to
> > search any other properties of the footprint, then you will have to
> load
> > all of the footprints anyway.  I don't know if this would be worth
> the
> > effort.
> >
> > For library types that contain multiple footprints per file (legacy,
> > Eagle), this wouldn't make much sense.  Parsing the entire file just
> to
> > pick out the footprint names probably isn't going to save you very
> much
> > time.
> >
> > >
> > > On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh <
> stambau...@gmail.com 
> > > >>
> wrote:
> > >
> > > On 10/30/2017 5:23 PM, Oliver Walters wrote:
> > > > Thanks for the suggestions on fixing the text. I have that
> sorted.
> > > >
> > > > I will look into different ways of caching footprint data so
> it is quicker.
> > > >
> > > > Wayne, I didn't know about FOOTPRINT_FILTER I will switch to
> using that
> > > > instead (and provide regex search).
> > >
> > > Thanks Oliver!
> > >
> > > >
> > > > On 31 Oct 2017 06:55, "Seth Hillbrand" <
> seth.hillbr...@gmail.com 
> > >
> > > > 
> >  >  > > >
> > > > On Mon, Oct 30, 2017 at 11:42 AM, Wayne Stambaugh
> > > > 
> > 

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-16 Thread Carsten Schoenert
Hi,

Am 16.11.2017 um 23:46 schrieb Seth Hillbrand:
> Hi Oliver-
> 
> I found where the issue is.  I apparently have an invalid line in my
> fp-lib-table.  It lists my github library as type "KiCad".  This is why the
> URL looked odd in the debug message.  I have to admit, I'm not certain how
> this got mixed up but it must have been my mistake at some point in the
> past.  However, I think we should be able to handle a bad line without
> crashing.
> 
> Once I fixed the error in my fp-lib-table, your patch functions without
> crashing.  Couple comments:
Beside the file wasn't correct, but that doesn't "allow' to happen a
segfault at all here. A segfault is always a visible issues about not
correct error handling. Could you devs please take a look at this to
catch up such things?

-- 
Regards
Carsten Schoenert

___
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 live footprint filtering in modview window

2017-11-16 Thread Oliver Walters
Seth,

Currently at work but I'll have a look at these issues ASAP. I'd like to
get this merged :)

On Fri, Nov 17, 2017 at 9:46 AM, Seth Hillbrand 
wrote:

> Hi Oliver-
>
> I found where the issue is.  I apparently have an invalid line in my
> fp-lib-table.  It lists my github library as type "KiCad".  This is why the
> URL looked odd in the debug message.  I have to admit, I'm not certain how
> this got mixed up but it must have been my mistake at some point in the
> past.  However, I think we should be able to handle a bad line without
> crashing.
>
> Once I fixed the error in my fp-lib-table, your patch functions without
> crashing.  Couple comments:
>
> - When the user clicks on a new library, it seems to move the location of
> the selected row to the top of the listbox.  This isn't a problem if you
> are scrolling but clicking around, I find it problematic.
> - The layout of the window doesn't seem to adjust well to changing the
> width.  (see attached image)  It seems to remember the starting width and
> not unwrap when enlarged.
>
> Thanks for the work on this!
>
> Best-
> Seth
>
>
>
>
> On Thu, Nov 16, 2017 at 1:26 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Wayne,
>>
>> Patch set now goes to 0009 (all patches re-attached to this email).
>>
>> Most recent patch adds the following:
>>
>> - Busy cursor while loading each library (otherwise it feels like KiCad
>> is just sleepy)
>> - Further nullptr checks, trying to fix Seth's error
>> - Removed a tooltip that erroneously suggested that regex was supported.
>>
>> Cheers
>>
>> On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh 
>> wrote:
>>
>>> On 10/31/2017 5:01 PM, Oliver Walters wrote:
>>> > How should I proceed here then?
>>> >
>>> > I would like to see the various libraries being "cached" in the
>>> > background, but this is increasing the scope of the work by a large
>>> factor.
>>> >
>>> > One thing I have noticed:
>>> >
>>> > In eeschema when you launch the component viewer, it (on first run)
>>> maps
>>> > and caches all the footprint libraries. This can take AGES (especially
>>> > on Windows). However on subsequent launches of the component viewer it
>>> > appears instantly. It appears to be keeping a static map of the
>>> > footprint library data.
>>> >
>>> > a) Would this be an acceptable approach for the footprint viewer window
>>>
>>> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
>>> footprint library code is split out from the component chooser so it
>>> should be reusable.
>>>
>>> > b) What happens when the library data changes externally? Does
>>> component
>>> > viewer need to be reloaded?
>>>
>>> No, only the library that changed gets reloaded the next time it's
>>> accessed.  It is not automatic.  I thought about using wxFileWatcher but
>>> that could be a lot of overhead for little net gain.  See the pcb plugin
>>> cache() functions.
>>>
>>> > c) Can we globally perform this caching in a background thread when
>>> > KiCad launches? This will hide the large pauses (up to a minute under
>>> > Windows) from the user...
>>>
>>> Yes, this should be done as a project element so that it can be accessed
>>> from all of the main windows.  Please keep in mind, this could be a lot
>>> of work and given that we are nearing a stable 5 release feature freeze,
>>> so if it's not by then it will not make it into the stable 5 release.
>>>
>>> >
>>> > Oliver
>>> >
>>> > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh <
>>> stambau...@gmail.com
>>> > > wrote:
>>> >
>>> > On 10/31/2017 1:25 AM, Oliver Walters wrote:
>>> > > Hmm, I had thought that there was a way to load only the *names*
>>> of
>>> > > footprints, rather than individually parsing each footprint
>>> file. It
>>> > > appears that this is not the case. Any suggestions on how the
>>> speed
>>> > > could be improved? Currently I'm reading out all the footprint
>>> names in
>>> > > each footprint library and only storing the names (wxString)
>>> rather than
>>> > > the MODULE* objects. However, I still have to parse the entire
>>> library
>>> > > on load.
>>> > >
>>> > > Ideally, I think it would be good to just read in the names, and
>>> then
>>> > > load and display individual MODULE objects on demand.. Is this
>>> possible?
>>> >
>>> > This is possible (although not implemented) for library types
>>> (kicad,
>>> > geda) that use one file per footprint.  You could just read the
>>> file
>>> > names from the folder and load the files as required.  If you want
>>> to
>>> > search any other properties of the footprint, then you will have
>>> to load
>>> > all of the footprints anyway.  I don't know if this would be worth
>>> the
>>> > effort.
>>> >
>>> > For library types that contain multiple footprints per file
>>> (legacy,
>>> > Eagle), this wouldn't make much sense.  Parsing the entire file

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-16 Thread Oliver Walters
Kevin - noted. It appears that Seth found the cause of the issue anyway :)

On Fri, Nov 17, 2017 at 10:30 AM, Kevin Cozens  wrote:

> On 2017-11-16 04:08 PM, Oliver Walters wrote:
>
>> I just tried that github repo and it works fine for me. It appears that
>> you are missing a "/" after https:/
>>
>
> I don't think the second / is missing after https:/. There are places
> where the code normalizes paths which converts // to /.
>
> --
> 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 live footprint filtering in modview window

2017-11-16 Thread Oliver Walters
Orson,

Yes this is correct. I have noticed this too and there is a workaround I
can make.

On Fri, Nov 17, 2017 at 10:07 AM, Maciej Suminski 
wrote:

> Hi Oliver,
>
> I admit that recently I have wished for a footprint filter (/me puts a
> tinfoil hat), so I like the idea.
>
> Being picky, I noticed that library and footprint filters behave a
> little differently: for libraries one needs to explicitly use wildcards,
> whereas it is not necessary for footprint names. To give an example:
> "SMD:" leaves an empty list but "*SMD*:" gets me beloved SMD parts. For
> footprint names it is enough to type "0603", no need to use "*0603*". As
> you see, it is a minor detail, no showstoppers.
>
> Cheers,
> Orson
>
> On 11/16/2017 10:26 PM, Oliver Walters wrote:
> > Wayne,
> >
> > Patch set now goes to 0009 (all patches re-attached to this email).
> >
> > Most recent patch adds the following:
> >
> > - Busy cursor while loading each library (otherwise it feels like KiCad
> is
> > just sleepy)
> > - Further nullptr checks, trying to fix Seth's error
> > - Removed a tooltip that erroneously suggested that regex was supported.
> >
> > Cheers
> >
> > On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh 
> > wrote:
> >
> >> On 10/31/2017 5:01 PM, Oliver Walters wrote:
> >>> How should I proceed here then?
> >>>
> >>> I would like to see the various libraries being "cached" in the
> >>> background, but this is increasing the scope of the work by a large
> >> factor.
> >>>
> >>> One thing I have noticed:
> >>>
> >>> In eeschema when you launch the component viewer, it (on first run)
> maps
> >>> and caches all the footprint libraries. This can take AGES (especially
> >>> on Windows). However on subsequent launches of the component viewer it
> >>> appears instantly. It appears to be keeping a static map of the
> >>> footprint library data.
> >>>
> >>> a) Would this be an acceptable approach for the footprint viewer window
> >>
> >> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
> >> footprint library code is split out from the component chooser so it
> >> should be reusable.
> >>
> >>> b) What happens when the library data changes externally? Does
> component
> >>> viewer need to be reloaded?
> >>
> >> No, only the library that changed gets reloaded the next time it's
> >> accessed.  It is not automatic.  I thought about using wxFileWatcher but
> >> that could be a lot of overhead for little net gain.  See the pcb plugin
> >> cache() functions.
> >>
> >>> c) Can we globally perform this caching in a background thread when
> >>> KiCad launches? This will hide the large pauses (up to a minute under
> >>> Windows) from the user...
> >>
> >> Yes, this should be done as a project element so that it can be accessed
> >> from all of the main windows.  Please keep in mind, this could be a lot
> >> of work and given that we are nearing a stable 5 release feature freeze,
> >> so if it's not by then it will not make it into the stable 5 release.
> >>
> >>>
> >>> Oliver
> >>>
> >>> On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh <
> stambau...@gmail.com
> >>> > wrote:
> >>>
> >>> On 10/31/2017 1:25 AM, Oliver Walters wrote:
> >>> > Hmm, I had thought that there was a way to load only the *names*
> of
> >>> > footprints, rather than individually parsing each footprint file.
> >> It
> >>> > appears that this is not the case. Any suggestions on how the
> speed
> >>> > could be improved? Currently I'm reading out all the footprint
> >> names in
> >>> > each footprint library and only storing the names (wxString)
> >> rather than
> >>> > the MODULE* objects. However, I still have to parse the entire
> >> library
> >>> > on load.
> >>> >
> >>> > Ideally, I think it would be good to just read in the names, and
> >> then
> >>> > load and display individual MODULE objects on demand.. Is this
> >> possible?
> >>>
> >>> This is possible (although not implemented) for library types
> (kicad,
> >>> geda) that use one file per footprint.  You could just read the
> file
> >>> names from the folder and load the files as required.  If you want
> to
> >>> search any other properties of the footprint, then you will have to
> >> load
> >>> all of the footprints anyway.  I don't know if this would be worth
> >> the
> >>> effort.
> >>>
> >>> For library types that contain multiple footprints per file
> (legacy,
> >>> Eagle), this wouldn't make much sense.  Parsing the entire file
> just
> >> to
> >>> pick out the footprint names probably isn't going to save you very
> >> much
> >>> time.
> >>>
> >>> >
> >>> > On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh <
> >> stambau...@gmail.com 
> >>> > >>
> >> wrote:
> >>> >
> >>> > On 10/30/2017 5:23 PM, Oliver Walters wrote:
> >>>   

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-16 Thread Kevin Cozens

On 2017-11-16 04:08 PM, Oliver Walters wrote:
I just tried that github repo and it works fine for me. It appears that you 
are missing a "/" after https:/


I don't think the second / is missing after https:/. There are places where 
the code normalizes paths which converts // to /.


--
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] [PATCH] Add live footprint filtering in modview window

2017-11-16 Thread Maciej Suminski
Hi Oliver,

I admit that recently I have wished for a footprint filter (/me puts a
tinfoil hat), so I like the idea.

Being picky, I noticed that library and footprint filters behave a
little differently: for libraries one needs to explicitly use wildcards,
whereas it is not necessary for footprint names. To give an example:
"SMD:" leaves an empty list but "*SMD*:" gets me beloved SMD parts. For
footprint names it is enough to type "0603", no need to use "*0603*". As
you see, it is a minor detail, no showstoppers.

Cheers,
Orson

On 11/16/2017 10:26 PM, Oliver Walters wrote:
> Wayne,
> 
> Patch set now goes to 0009 (all patches re-attached to this email).
> 
> Most recent patch adds the following:
> 
> - Busy cursor while loading each library (otherwise it feels like KiCad is
> just sleepy)
> - Further nullptr checks, trying to fix Seth's error
> - Removed a tooltip that erroneously suggested that regex was supported.
> 
> Cheers
> 
> On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh 
> wrote:
> 
>> On 10/31/2017 5:01 PM, Oliver Walters wrote:
>>> How should I proceed here then?
>>>
>>> I would like to see the various libraries being "cached" in the
>>> background, but this is increasing the scope of the work by a large
>> factor.
>>>
>>> One thing I have noticed:
>>>
>>> In eeschema when you launch the component viewer, it (on first run) maps
>>> and caches all the footprint libraries. This can take AGES (especially
>>> on Windows). However on subsequent launches of the component viewer it
>>> appears instantly. It appears to be keeping a static map of the
>>> footprint library data.
>>>
>>> a) Would this be an acceptable approach for the footprint viewer window
>>
>> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
>> footprint library code is split out from the component chooser so it
>> should be reusable.
>>
>>> b) What happens when the library data changes externally? Does component
>>> viewer need to be reloaded?
>>
>> No, only the library that changed gets reloaded the next time it's
>> accessed.  It is not automatic.  I thought about using wxFileWatcher but
>> that could be a lot of overhead for little net gain.  See the pcb plugin
>> cache() functions.
>>
>>> c) Can we globally perform this caching in a background thread when
>>> KiCad launches? This will hide the large pauses (up to a minute under
>>> Windows) from the user...
>>
>> Yes, this should be done as a project element so that it can be accessed
>> from all of the main windows.  Please keep in mind, this could be a lot
>> of work and given that we are nearing a stable 5 release feature freeze,
>> so if it's not by then it will not make it into the stable 5 release.
>>
>>>
>>> Oliver
>>>
>>> On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh >> > wrote:
>>>
>>> On 10/31/2017 1:25 AM, Oliver Walters wrote:
>>> > Hmm, I had thought that there was a way to load only the *names* of
>>> > footprints, rather than individually parsing each footprint file.
>> It
>>> > appears that this is not the case. Any suggestions on how the speed
>>> > could be improved? Currently I'm reading out all the footprint
>> names in
>>> > each footprint library and only storing the names (wxString)
>> rather than
>>> > the MODULE* objects. However, I still have to parse the entire
>> library
>>> > on load.
>>> >
>>> > Ideally, I think it would be good to just read in the names, and
>> then
>>> > load and display individual MODULE objects on demand.. Is this
>> possible?
>>>
>>> This is possible (although not implemented) for library types (kicad,
>>> geda) that use one file per footprint.  You could just read the file
>>> names from the folder and load the files as required.  If you want to
>>> search any other properties of the footprint, then you will have to
>> load
>>> all of the footprints anyway.  I don't know if this would be worth
>> the
>>> effort.
>>>
>>> For library types that contain multiple footprints per file (legacy,
>>> Eagle), this wouldn't make much sense.  Parsing the entire file just
>> to
>>> pick out the footprint names probably isn't going to save you very
>> much
>>> time.
>>>
>>> >
>>> > On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh <
>> stambau...@gmail.com 
>>> > >>
>> wrote:
>>> >
>>> > On 10/30/2017 5:23 PM, Oliver Walters wrote:
>>> > > Thanks for the suggestions on fixing the text. I have that
>> sorted.
>>> > >
>>> > > I will look into different ways of caching footprint data so
>> it is quicker.
>>> > >
>>> > > Wayne, I didn't know about FOOTPRINT_FILTER I will switch to
>> using that
>>> > > instead (and provide regex search).
>>> >
>>> > Thanks Oliver!
>>> >
>>> > >
>>> > 

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-16 Thread Oliver Walters
Wayne,

Patch set now goes to 0009 (all patches re-attached to this email).

Most recent patch adds the following:

- Busy cursor while loading each library (otherwise it feels like KiCad is
just sleepy)
- Further nullptr checks, trying to fix Seth's error
- Removed a tooltip that erroneously suggested that regex was supported.

Cheers

On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh 
wrote:

> On 10/31/2017 5:01 PM, Oliver Walters wrote:
> > How should I proceed here then?
> >
> > I would like to see the various libraries being "cached" in the
> > background, but this is increasing the scope of the work by a large
> factor.
> >
> > One thing I have noticed:
> >
> > In eeschema when you launch the component viewer, it (on first run) maps
> > and caches all the footprint libraries. This can take AGES (especially
> > on Windows). However on subsequent launches of the component viewer it
> > appears instantly. It appears to be keeping a static map of the
> > footprint library data.
> >
> > a) Would this be an acceptable approach for the footprint viewer window
>
> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
> footprint library code is split out from the component chooser so it
> should be reusable.
>
> > b) What happens when the library data changes externally? Does component
> > viewer need to be reloaded?
>
> No, only the library that changed gets reloaded the next time it's
> accessed.  It is not automatic.  I thought about using wxFileWatcher but
> that could be a lot of overhead for little net gain.  See the pcb plugin
> cache() functions.
>
> > c) Can we globally perform this caching in a background thread when
> > KiCad launches? This will hide the large pauses (up to a minute under
> > Windows) from the user...
>
> Yes, this should be done as a project element so that it can be accessed
> from all of the main windows.  Please keep in mind, this could be a lot
> of work and given that we are nearing a stable 5 release feature freeze,
> so if it's not by then it will not make it into the stable 5 release.
>
> >
> > Oliver
> >
> > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh  > > wrote:
> >
> > On 10/31/2017 1:25 AM, Oliver Walters wrote:
> > > Hmm, I had thought that there was a way to load only the *names* of
> > > footprints, rather than individually parsing each footprint file.
> It
> > > appears that this is not the case. Any suggestions on how the speed
> > > could be improved? Currently I'm reading out all the footprint
> names in
> > > each footprint library and only storing the names (wxString)
> rather than
> > > the MODULE* objects. However, I still have to parse the entire
> library
> > > on load.
> > >
> > > Ideally, I think it would be good to just read in the names, and
> then
> > > load and display individual MODULE objects on demand.. Is this
> possible?
> >
> > This is possible (although not implemented) for library types (kicad,
> > geda) that use one file per footprint.  You could just read the file
> > names from the folder and load the files as required.  If you want to
> > search any other properties of the footprint, then you will have to
> load
> > all of the footprints anyway.  I don't know if this would be worth
> the
> > effort.
> >
> > For library types that contain multiple footprints per file (legacy,
> > Eagle), this wouldn't make much sense.  Parsing the entire file just
> to
> > pick out the footprint names probably isn't going to save you very
> much
> > time.
> >
> > >
> > > On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh <
> stambau...@gmail.com 
> > > >>
> wrote:
> > >
> > > On 10/30/2017 5:23 PM, Oliver Walters wrote:
> > > > Thanks for the suggestions on fixing the text. I have that
> sorted.
> > > >
> > > > I will look into different ways of caching footprint data so
> it is quicker.
> > > >
> > > > Wayne, I didn't know about FOOTPRINT_FILTER I will switch to
> using that
> > > > instead (and provide regex search).
> > >
> > > Thanks Oliver!
> > >
> > > >
> > > > On 31 Oct 2017 06:55, "Seth Hillbrand" <
> seth.hillbr...@gmail.com 
> > >
> > > > 
> >  >  > > >
> > > > On Mon, Oct 30, 2017 at 11:42 AM, Wayne Stambaugh
> > > > 
> > >
> > > 

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-16 Thread Oliver Walters
Seth,

Did you try with the included 0008 patch? I have tried a lot to reproduce
your bug but cannot do so.

On Fri, Nov 17, 2017 at 4:40 AM, Seth Hillbrand 
wrote:

> Oops, also got a segfault when hitting the "Reload button" on a github
> library.  Here's the backtrace:
>
> #0  0x7fffd69a1ccc in std::vector std::default_delete >, 
> std::allocator std::default_delete > > >::size (this=0x10)
> at /usr/include/c++/6/bits/stl_vector.h:656
> #1  0x7fffd69c0a90 in FOOTPRINT_LIST::GetCount (this=0x0) at
> /home/seth/code/kicad/kicad-launchpad/include/footprint_info.h:199
> #2  0x7fffd6e4bac9 in FOOTPRINT_FILTER::end (this=0x59140bf8) at
> /home/seth/code/kicad/kicad-launchpad/common/footprint_filter.cpp:231
> #3  0x7fffd6753475 in FOOTPRINT_VIEWER_FRAME::FilterLibs
> (this=0x5913e640) at /home/seth/code/kicad/kicad-
> launchpad/pcbnew/modview_frame.cpp:428
> #4  0x7fffd6752f71 in FOOTPRINT_VIEWER_FRAME::OnFilterUpdated
> (this=0x5913e640, event=...) at /home/seth/code/kicad/kicad-
> launchpad/pcbnew/modview_frame.cpp:365
> #5  0x7634440e in wxAppConsoleBase::CallEventHandler(wxEvtHandler*,
> wxEventFunctor&, wxEvent&) const () from /usr/lib/x86_64-linux-gnu/
> libwx_baseu-3.0.so.0
> #6  0x764c9ea5 in 
> wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase
> const&, wxEvtHandler*, wxEvent&) () from /usr/lib/x86_64-linux-gnu/
> libwx_baseu-3.0.so.0
> #7  0x764c9f9b in wxEventHashTable::HandleEvent(wxEvent&,
> wxEvtHandler*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #8  0x764ca34b in wxEvtHandler::TryHereOnly(wxEvent&) () from
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #9  0x7fffd6deffb7 in EDA_BASE_FRAME::ProcessEvent
> (this=0x5913e640, aEvent=...) at /home/seth/code/kicad/kicad-
> launchpad/common/basicframe.cpp:187
> #10 0x764ca153 in wxEvtHandler::DoTryChain(wxEvent&) () from
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #11 0x764ca435 in wxEvtHandler::ProcessEvent(wxEvent&) () from
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #12 0x76e562f8 in wxWindowBase::TryAfter(wxEvent&) () from
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
> #13 0x76e562f8 in wxWindowBase::TryAfter(wxEvent&) () from
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
> #14 0x76ed0740 in ?? () from /usr/lib/x86_64-linux-gnu/
> libwx_gtk2u_core-3.0.so.0
> #15 0x7634440e in wxAppConsoleBase::CallEventHandler(wxEvtHandler*,
> wxEventFunctor&, wxEvent&) const () from /usr/lib/x86_64-linux-gnu/
> libwx_baseu-3.0.so.0
> #16 0x764c9ea5 in 
> wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase
> const&, wxEvtHandler*, wxEvent&) () from /usr/lib/x86_64-linux-gnu/
> libwx_baseu-3.0.so.0
> #17 0x764c9f9b in wxEventHashTable::HandleEvent(wxEvent&,
> wxEvtHandler*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #18 0x764ca34b in wxEvtHandler::TryHereOnly(wxEvent&) () from
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #19 0x764ca3d3 in wxEvtHandler::ProcessEventLocally(wxEvent&) ()
> from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #20 0x764ca435 in wxEvtHandler::ProcessEvent(wxEvent&) () from
> /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #21 0x764ca1a7 in wxEvtHandler::SafelyProcessEvent(wxEvent&) ()
> from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #22 0x76e4277f in wxTextEntryBase::SendTextUpdatedEvent(wxWindow*)
> () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
> #23 0x76d0a69c in wxTextEntry::DoSetValue(wxString const&, int)
> () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
> #24 0x76d08a6c in wxTextCtrl::DoSetValue(wxString const&, int) ()
> from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
> #25 0x76ecc04a in wxSearchCtrl::Clear() () from
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
> #26 0x7fffd6752e21 in FOOTPRINT_VIEWER_FRAME::ClearFilter
> (this=0x5913e640) at /home/seth/code/kicad/kicad-
> launchpad/pcbnew/modview_frame.cpp:350
> #27 0x7fffd67537c2 in FOOTPRINT_VIEWER_FRAME::ReCreateLibraryList
> (this=0x5913e640) at /home/seth/code/kicad/kicad-
> launchpad/pcbnew/modview_frame.cpp:482
> #28 0x7fffd6759eae in FOOTPRINT_VIEWER_FRAME::ReloadAllLibraries
> (this=0x5913e640, event=...) at /home/seth/code/kicad/kicad-
> launchpad/pcbnew/./modview_frame.h:166
> #29 0x7634440e in wxAppConsoleBase::CallEventHandler(wxEvtHandler*,
> wxEventFunctor&, wxEvent&) const () from /usr/lib/x86_64-linux-gnu/
> libwx_baseu-3.0.so.0
> #30 0x764c9ea5 in 
> wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase
> const&, wxEvtHandler*, wxEvent&) () from /usr/lib/x86_64-linux-gnu/
> libwx_baseu-3.0.so.0
> #31 0x764c9f9b in wxEventHashTable::HandleEvent(wxEvent&,
> wxEvtHandler*) () from 

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-16 Thread Oliver Walters
Seth,

I just tried that github repo and it works fine for me. It appears that you
are missing a "/" after https:/

On Fri, Nov 17, 2017 at 4:37 AM, Seth Hillbrand 
wrote:

> Hi Oliver-
>
> I tried the new patchset but I can't seem to get it to work.  It only
> loads the local libraries (none of the Github libraries).
>
> I get the error:
> Error: IO_ERROR: Footprint library path 'https:/github.com/KiCad/
> Connectors_JST.pretty' does not exist
>
> -S
>
> On Thu, Nov 16, 2017 at 5:23 AM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Important! Patch 0008 (attached) fixes a nullpointer error.
>>
>> BUT more importantly, it also reintroduces the ability to filter out
>> libraries using the ':' separator!
>>
>> Now we are getting somewhere!
>>
>> On Thu, Nov 16, 2017 at 11:38 PM, Oliver Walters <
>> oliver.henry.walt...@gmail.com> wrote:
>>
>>> Wayne,
>>>
>>> I have finally found some time to readdress this.
>>>
>>> I have reimplemented the filtering using the existing FOOTPRINT_FILTER
>>> class. I have also reverted behaviour to work only on the currently
>>> selected footprint library. This removes the requirement to load all the
>>> libraries when the dialog opens.
>>>
>>> I think all requirements are satisfied now. Please find modified patch
>>> set attached.
>>>
>>> Regards,
>>> Oliver
>>>
>>> On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh 
>>> wrote:
>>>
 On 10/31/2017 5:01 PM, Oliver Walters wrote:
 > How should I proceed here then?
 >
 > I would like to see the various libraries being "cached" in the
 > background, but this is increasing the scope of the work by a large
 factor.
 >
 > One thing I have noticed:
 >
 > In eeschema when you launch the component viewer, it (on first run)
 maps
 > and caches all the footprint libraries. This can take AGES (especially
 > on Windows). However on subsequent launches of the component viewer it
 > appears instantly. It appears to be keeping a static map of the
 > footprint library data.
 >
 > a) Would this be an acceptable approach for the footprint viewer
 window

 Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
 footprint library code is split out from the component chooser so it
 should be reusable.

 > b) What happens when the library data changes externally? Does
 component
 > viewer need to be reloaded?

 No, only the library that changed gets reloaded the next time it's
 accessed.  It is not automatic.  I thought about using wxFileWatcher but
 that could be a lot of overhead for little net gain.  See the pcb plugin
 cache() functions.

 > c) Can we globally perform this caching in a background thread when
 > KiCad launches? This will hide the large pauses (up to a minute under
 > Windows) from the user...

 Yes, this should be done as a project element so that it can be accessed
 from all of the main windows.  Please keep in mind, this could be a lot
 of work and given that we are nearing a stable 5 release feature freeze,
 so if it's not by then it will not make it into the stable 5 release.

 >
 > Oliver
 >
 > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh <
 stambau...@gmail.com
 > > wrote:
 >
 > On 10/31/2017 1:25 AM, Oliver Walters wrote:
 > > Hmm, I had thought that there was a way to load only the
 *names* of
 > > footprints, rather than individually parsing each footprint
 file. It
 > > appears that this is not the case. Any suggestions on how the
 speed
 > > could be improved? Currently I'm reading out all the footprint
 names in
 > > each footprint library and only storing the names (wxString)
 rather than
 > > the MODULE* objects. However, I still have to parse the entire
 library
 > > on load.
 > >
 > > Ideally, I think it would be good to just read in the names,
 and then
 > > load and display individual MODULE objects on demand.. Is this
 possible?
 >
 > This is possible (although not implemented) for library types
 (kicad,
 > geda) that use one file per footprint.  You could just read the
 file
 > names from the folder and load the files as required.  If you
 want to
 > search any other properties of the footprint, then you will have
 to load
 > all of the footprints anyway.  I don't know if this would be
 worth the
 > effort.
 >
 > For library types that contain multiple footprints per file
 (legacy,
 > Eagle), this wouldn't make much sense.  Parsing the entire file
 just to
 > pick out the footprint names probably isn't going to save you
 very much
 > time.
 >
 > >
 > > On Tue, 

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-16 Thread Seth Hillbrand
Oops, also got a segfault when hitting the "Reload button" on a github
library.  Here's the backtrace:

#0  0x7fffd69a1ccc in std::vector,
std::allocator > >::size (this=0x10)
at /usr/include/c++/6/bits/stl_vector.h:656
#1  0x7fffd69c0a90 in FOOTPRINT_LIST::GetCount (this=0x0) at
/home/seth/code/kicad/kicad-launchpad/include/footprint_info.h:199
#2  0x7fffd6e4bac9 in FOOTPRINT_FILTER::end (this=0x59140bf8) at
/home/seth/code/kicad/kicad-launchpad/common/footprint_filter.cpp:231
#3  0x7fffd6753475 in FOOTPRINT_VIEWER_FRAME::FilterLibs
(this=0x5913e640) at
/home/seth/code/kicad/kicad-launchpad/pcbnew/modview_frame.cpp:428
#4  0x7fffd6752f71 in FOOTPRINT_VIEWER_FRAME::OnFilterUpdated
(this=0x5913e640, event=...) at
/home/seth/code/kicad/kicad-launchpad/pcbnew/modview_frame.cpp:365
#5  0x7634440e in wxAppConsoleBase::CallEventHandler(wxEvtHandler*,
wxEventFunctor&, wxEvent&) const () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#6  0x764c9ea5 in
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&,
wxEvtHandler*, wxEvent&) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#7  0x764c9f9b in wxEventHashTable::HandleEvent(wxEvent&,
wxEvtHandler*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#8  0x764ca34b in wxEvtHandler::TryHereOnly(wxEvent&) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#9  0x7fffd6deffb7 in EDA_BASE_FRAME::ProcessEvent
(this=0x5913e640, aEvent=...) at
/home/seth/code/kicad/kicad-launchpad/common/basicframe.cpp:187
#10 0x764ca153 in wxEvtHandler::DoTryChain(wxEvent&) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#11 0x764ca435 in wxEvtHandler::ProcessEvent(wxEvent&) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#12 0x76e562f8 in wxWindowBase::TryAfter(wxEvent&) () from
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#13 0x76e562f8 in wxWindowBase::TryAfter(wxEvent&) () from
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#14 0x76ed0740 in ?? () from
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#15 0x7634440e in wxAppConsoleBase::CallEventHandler(wxEvtHandler*,
wxEventFunctor&, wxEvent&) const () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#16 0x764c9ea5 in
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&,
wxEvtHandler*, wxEvent&) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#17 0x764c9f9b in wxEventHashTable::HandleEvent(wxEvent&,
wxEvtHandler*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#18 0x764ca34b in wxEvtHandler::TryHereOnly(wxEvent&) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#19 0x764ca3d3 in wxEvtHandler::ProcessEventLocally(wxEvent&) ()
from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#20 0x764ca435 in wxEvtHandler::ProcessEvent(wxEvent&) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#21 0x764ca1a7 in wxEvtHandler::SafelyProcessEvent(wxEvent&) ()
from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#22 0x76e4277f in wxTextEntryBase::SendTextUpdatedEvent(wxWindow*)
() from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#23 0x76d0a69c in wxTextEntry::DoSetValue(wxString const&, int) ()
from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#24 0x76d08a6c in wxTextCtrl::DoSetValue(wxString const&, int) ()
from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#25 0x76ecc04a in wxSearchCtrl::Clear() () from
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#26 0x7fffd6752e21 in FOOTPRINT_VIEWER_FRAME::ClearFilter
(this=0x5913e640) at
/home/seth/code/kicad/kicad-launchpad/pcbnew/modview_frame.cpp:350
#27 0x7fffd67537c2 in FOOTPRINT_VIEWER_FRAME::ReCreateLibraryList
(this=0x5913e640) at
/home/seth/code/kicad/kicad-launchpad/pcbnew/modview_frame.cpp:482
#28 0x7fffd6759eae in FOOTPRINT_VIEWER_FRAME::ReloadAllLibraries
(this=0x5913e640, event=...) at
/home/seth/code/kicad/kicad-launchpad/pcbnew/./modview_frame.h:166
#29 0x7634440e in wxAppConsoleBase::CallEventHandler(wxEvtHandler*,
wxEventFunctor&, wxEvent&) const () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#30 0x764c9ea5 in
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&,
wxEvtHandler*, wxEvent&) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#31 0x764c9f9b in wxEventHashTable::HandleEvent(wxEvent&,
wxEvtHandler*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#32 0x764ca34b in wxEvtHandler::TryHereOnly(wxEvent&) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#33 0x7fffd6deffb7 in EDA_BASE_FRAME::ProcessEvent
(this=0x5913e640, aEvent=...) at
/home/seth/code/kicad/kicad-launchpad/common/basicframe.cpp:187
#34 0x764ca153 in 

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-16 Thread Seth Hillbrand
Hi Oliver-

I tried the new patchset but I can't seem to get it to work.  It only loads
the local libraries (none of the Github libraries).

I get the error:
Error: IO_ERROR: Footprint library path 'https:/
github.com/KiCad/Connectors_JST.pretty' does not exist

-S

On Thu, Nov 16, 2017 at 5:23 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Important! Patch 0008 (attached) fixes a nullpointer error.
>
> BUT more importantly, it also reintroduces the ability to filter out
> libraries using the ':' separator!
>
> Now we are getting somewhere!
>
> On Thu, Nov 16, 2017 at 11:38 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> Wayne,
>>
>> I have finally found some time to readdress this.
>>
>> I have reimplemented the filtering using the existing FOOTPRINT_FILTER
>> class. I have also reverted behaviour to work only on the currently
>> selected footprint library. This removes the requirement to load all the
>> libraries when the dialog opens.
>>
>> I think all requirements are satisfied now. Please find modified patch
>> set attached.
>>
>> Regards,
>> Oliver
>>
>> On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh 
>> wrote:
>>
>>> On 10/31/2017 5:01 PM, Oliver Walters wrote:
>>> > How should I proceed here then?
>>> >
>>> > I would like to see the various libraries being "cached" in the
>>> > background, but this is increasing the scope of the work by a large
>>> factor.
>>> >
>>> > One thing I have noticed:
>>> >
>>> > In eeschema when you launch the component viewer, it (on first run)
>>> maps
>>> > and caches all the footprint libraries. This can take AGES (especially
>>> > on Windows). However on subsequent launches of the component viewer it
>>> > appears instantly. It appears to be keeping a static map of the
>>> > footprint library data.
>>> >
>>> > a) Would this be an acceptable approach for the footprint viewer window
>>>
>>> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
>>> footprint library code is split out from the component chooser so it
>>> should be reusable.
>>>
>>> > b) What happens when the library data changes externally? Does
>>> component
>>> > viewer need to be reloaded?
>>>
>>> No, only the library that changed gets reloaded the next time it's
>>> accessed.  It is not automatic.  I thought about using wxFileWatcher but
>>> that could be a lot of overhead for little net gain.  See the pcb plugin
>>> cache() functions.
>>>
>>> > c) Can we globally perform this caching in a background thread when
>>> > KiCad launches? This will hide the large pauses (up to a minute under
>>> > Windows) from the user...
>>>
>>> Yes, this should be done as a project element so that it can be accessed
>>> from all of the main windows.  Please keep in mind, this could be a lot
>>> of work and given that we are nearing a stable 5 release feature freeze,
>>> so if it's not by then it will not make it into the stable 5 release.
>>>
>>> >
>>> > Oliver
>>> >
>>> > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh <
>>> stambau...@gmail.com
>>> > > wrote:
>>> >
>>> > On 10/31/2017 1:25 AM, Oliver Walters wrote:
>>> > > Hmm, I had thought that there was a way to load only the *names*
>>> of
>>> > > footprints, rather than individually parsing each footprint
>>> file. It
>>> > > appears that this is not the case. Any suggestions on how the
>>> speed
>>> > > could be improved? Currently I'm reading out all the footprint
>>> names in
>>> > > each footprint library and only storing the names (wxString)
>>> rather than
>>> > > the MODULE* objects. However, I still have to parse the entire
>>> library
>>> > > on load.
>>> > >
>>> > > Ideally, I think it would be good to just read in the names, and
>>> then
>>> > > load and display individual MODULE objects on demand.. Is this
>>> possible?
>>> >
>>> > This is possible (although not implemented) for library types
>>> (kicad,
>>> > geda) that use one file per footprint.  You could just read the
>>> file
>>> > names from the folder and load the files as required.  If you want
>>> to
>>> > search any other properties of the footprint, then you will have
>>> to load
>>> > all of the footprints anyway.  I don't know if this would be worth
>>> the
>>> > effort.
>>> >
>>> > For library types that contain multiple footprints per file
>>> (legacy,
>>> > Eagle), this wouldn't make much sense.  Parsing the entire file
>>> just to
>>> > pick out the footprint names probably isn't going to save you very
>>> much
>>> > time.
>>> >
>>> > >
>>> > > On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh <
>>> stambau...@gmail.com 
>>> > > >>
>>> wrote:
>>> > >
>>> > > On 10/30/2017 5:23 PM, Oliver Walters wrote:
>>> > > > Thanks for the suggestions on fixing the text. I have that
>>> sorted.

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-16 Thread Oliver Walters
Important! Patch 0008 (attached) fixes a nullpointer error.

BUT more importantly, it also reintroduces the ability to filter out
libraries using the ':' separator!

Now we are getting somewhere!

On Thu, Nov 16, 2017 at 11:38 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Wayne,
>
> I have finally found some time to readdress this.
>
> I have reimplemented the filtering using the existing FOOTPRINT_FILTER
> class. I have also reverted behaviour to work only on the currently
> selected footprint library. This removes the requirement to load all the
> libraries when the dialog opens.
>
> I think all requirements are satisfied now. Please find modified patch set
> attached.
>
> Regards,
> Oliver
>
> On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh 
> wrote:
>
>> On 10/31/2017 5:01 PM, Oliver Walters wrote:
>> > How should I proceed here then?
>> >
>> > I would like to see the various libraries being "cached" in the
>> > background, but this is increasing the scope of the work by a large
>> factor.
>> >
>> > One thing I have noticed:
>> >
>> > In eeschema when you launch the component viewer, it (on first run) maps
>> > and caches all the footprint libraries. This can take AGES (especially
>> > on Windows). However on subsequent launches of the component viewer it
>> > appears instantly. It appears to be keeping a static map of the
>> > footprint library data.
>> >
>> > a) Would this be an acceptable approach for the footprint viewer window
>>
>> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
>> footprint library code is split out from the component chooser so it
>> should be reusable.
>>
>> > b) What happens when the library data changes externally? Does component
>> > viewer need to be reloaded?
>>
>> No, only the library that changed gets reloaded the next time it's
>> accessed.  It is not automatic.  I thought about using wxFileWatcher but
>> that could be a lot of overhead for little net gain.  See the pcb plugin
>> cache() functions.
>>
>> > c) Can we globally perform this caching in a background thread when
>> > KiCad launches? This will hide the large pauses (up to a minute under
>> > Windows) from the user...
>>
>> Yes, this should be done as a project element so that it can be accessed
>> from all of the main windows.  Please keep in mind, this could be a lot
>> of work and given that we are nearing a stable 5 release feature freeze,
>> so if it's not by then it will not make it into the stable 5 release.
>>
>> >
>> > Oliver
>> >
>> > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh > > > wrote:
>> >
>> > On 10/31/2017 1:25 AM, Oliver Walters wrote:
>> > > Hmm, I had thought that there was a way to load only the *names*
>> of
>> > > footprints, rather than individually parsing each footprint file.
>> It
>> > > appears that this is not the case. Any suggestions on how the
>> speed
>> > > could be improved? Currently I'm reading out all the footprint
>> names in
>> > > each footprint library and only storing the names (wxString)
>> rather than
>> > > the MODULE* objects. However, I still have to parse the entire
>> library
>> > > on load.
>> > >
>> > > Ideally, I think it would be good to just read in the names, and
>> then
>> > > load and display individual MODULE objects on demand.. Is this
>> possible?
>> >
>> > This is possible (although not implemented) for library types
>> (kicad,
>> > geda) that use one file per footprint.  You could just read the file
>> > names from the folder and load the files as required.  If you want
>> to
>> > search any other properties of the footprint, then you will have to
>> load
>> > all of the footprints anyway.  I don't know if this would be worth
>> the
>> > effort.
>> >
>> > For library types that contain multiple footprints per file (legacy,
>> > Eagle), this wouldn't make much sense.  Parsing the entire file
>> just to
>> > pick out the footprint names probably isn't going to save you very
>> much
>> > time.
>> >
>> > >
>> > > On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh <
>> stambau...@gmail.com 
>> > > >>
>> wrote:
>> > >
>> > > On 10/30/2017 5:23 PM, Oliver Walters wrote:
>> > > > Thanks for the suggestions on fixing the text. I have that
>> sorted.
>> > > >
>> > > > I will look into different ways of caching footprint data
>> so it is quicker.
>> > > >
>> > > > Wayne, I didn't know about FOOTPRINT_FILTER I will switch
>> to using that
>> > > > instead (and provide regex search).
>> > >
>> > > Thanks Oliver!
>> > >
>> > > >
>> > > > On 31 Oct 2017 06:55, "Seth Hillbrand" <
>> seth.hillbr...@gmail.com 
>> > 

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-11-16 Thread Oliver Walters
Wayne,

I have finally found some time to readdress this.

I have reimplemented the filtering using the existing FOOTPRINT_FILTER
class. I have also reverted behaviour to work only on the currently
selected footprint library. This removes the requirement to load all the
libraries when the dialog opens.

I think all requirements are satisfied now. Please find modified patch set
attached.

Regards,
Oliver

On Wed, Nov 1, 2017 at 11:21 AM, Wayne Stambaugh 
wrote:

> On 10/31/2017 5:01 PM, Oliver Walters wrote:
> > How should I proceed here then?
> >
> > I would like to see the various libraries being "cached" in the
> > background, but this is increasing the scope of the work by a large
> factor.
> >
> > One thing I have noticed:
> >
> > In eeschema when you launch the component viewer, it (on first run) maps
> > and caches all the footprint libraries. This can take AGES (especially
> > on Windows). However on subsequent launches of the component viewer it
> > appears instantly. It appears to be keeping a static map of the
> > footprint library data.
> >
> > a) Would this be an acceptable approach for the footprint viewer window
>
> Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
> footprint library code is split out from the component chooser so it
> should be reusable.
>
> > b) What happens when the library data changes externally? Does component
> > viewer need to be reloaded?
>
> No, only the library that changed gets reloaded the next time it's
> accessed.  It is not automatic.  I thought about using wxFileWatcher but
> that could be a lot of overhead for little net gain.  See the pcb plugin
> cache() functions.
>
> > c) Can we globally perform this caching in a background thread when
> > KiCad launches? This will hide the large pauses (up to a minute under
> > Windows) from the user...
>
> Yes, this should be done as a project element so that it can be accessed
> from all of the main windows.  Please keep in mind, this could be a lot
> of work and given that we are nearing a stable 5 release feature freeze,
> so if it's not by then it will not make it into the stable 5 release.
>
> >
> > Oliver
> >
> > On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh  > > wrote:
> >
> > On 10/31/2017 1:25 AM, Oliver Walters wrote:
> > > Hmm, I had thought that there was a way to load only the *names* of
> > > footprints, rather than individually parsing each footprint file.
> It
> > > appears that this is not the case. Any suggestions on how the speed
> > > could be improved? Currently I'm reading out all the footprint
> names in
> > > each footprint library and only storing the names (wxString)
> rather than
> > > the MODULE* objects. However, I still have to parse the entire
> library
> > > on load.
> > >
> > > Ideally, I think it would be good to just read in the names, and
> then
> > > load and display individual MODULE objects on demand.. Is this
> possible?
> >
> > This is possible (although not implemented) for library types (kicad,
> > geda) that use one file per footprint.  You could just read the file
> > names from the folder and load the files as required.  If you want to
> > search any other properties of the footprint, then you will have to
> load
> > all of the footprints anyway.  I don't know if this would be worth
> the
> > effort.
> >
> > For library types that contain multiple footprints per file (legacy,
> > Eagle), this wouldn't make much sense.  Parsing the entire file just
> to
> > pick out the footprint names probably isn't going to save you very
> much
> > time.
> >
> > >
> > > On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh <
> stambau...@gmail.com 
> > > >>
> wrote:
> > >
> > > On 10/30/2017 5:23 PM, Oliver Walters wrote:
> > > > Thanks for the suggestions on fixing the text. I have that
> sorted.
> > > >
> > > > I will look into different ways of caching footprint data so
> it is quicker.
> > > >
> > > > Wayne, I didn't know about FOOTPRINT_FILTER I will switch to
> using that
> > > > instead (and provide regex search).
> > >
> > > Thanks Oliver!
> > >
> > > >
> > > > On 31 Oct 2017 06:55, "Seth Hillbrand" <
> seth.hillbr...@gmail.com 
> > >
> > > > 
> >  >  > > >
> > > > On Mon, Oct 30, 2017 at 11:42 AM, Wayne Stambaugh
> > > > 
> > >

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-10-31 Thread Wayne Stambaugh
On 10/31/2017 5:01 PM, Oliver Walters wrote:
> How should I proceed here then?
> 
> I would like to see the various libraries being "cached" in the
> background, but this is increasing the scope of the work by a large factor.
> 
> One thing I have noticed:
> 
> In eeschema when you launch the component viewer, it (on first run) maps
> and caches all the footprint libraries. This can take AGES (especially
> on Windows). However on subsequent launches of the component viewer it
> appears instantly. It appears to be keeping a static map of the
> footprint library data.
> 
> a) Would this be an acceptable approach for the footprint viewer window

Sure.  Code reuse is a good thing.  I'm pretty sure the threaded
footprint library code is split out from the component chooser so it
should be reusable.

> b) What happens when the library data changes externally? Does component
> viewer need to be reloaded?

No, only the library that changed gets reloaded the next time it's
accessed.  It is not automatic.  I thought about using wxFileWatcher but
that could be a lot of overhead for little net gain.  See the pcb plugin
cache() functions.

> c) Can we globally perform this caching in a background thread when
> KiCad launches? This will hide the large pauses (up to a minute under
> Windows) from the user...

Yes, this should be done as a project element so that it can be accessed
from all of the main windows.  Please keep in mind, this could be a lot
of work and given that we are nearing a stable 5 release feature freeze,
so if it's not by then it will not make it into the stable 5 release.

> 
> Oliver
> 
> On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh  > wrote:
> 
> On 10/31/2017 1:25 AM, Oliver Walters wrote:
> > Hmm, I had thought that there was a way to load only the *names* of
> > footprints, rather than individually parsing each footprint file. It
> > appears that this is not the case. Any suggestions on how the speed
> > could be improved? Currently I'm reading out all the footprint names in
> > each footprint library and only storing the names (wxString) rather than
> > the MODULE* objects. However, I still have to parse the entire library
> > on load.
> >
> > Ideally, I think it would be good to just read in the names, and then
> > load and display individual MODULE objects on demand.. Is this possible?
> 
> This is possible (although not implemented) for library types (kicad,
> geda) that use one file per footprint.  You could just read the file
> names from the folder and load the files as required.  If you want to
> search any other properties of the footprint, then you will have to load
> all of the footprints anyway.  I don't know if this would be worth the
> effort.
> 
> For library types that contain multiple footprints per file (legacy,
> Eagle), this wouldn't make much sense.  Parsing the entire file just to
> pick out the footprint names probably isn't going to save you very much
> time.
> 
> >
> > On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh  
> > >> wrote:
> >
> >     On 10/30/2017 5:23 PM, Oliver Walters wrote:
> >     > Thanks for the suggestions on fixing the text. I have that 
> sorted. 
> >     >
> >     > I will look into different ways of caching footprint data so it 
> is quicker. 
> >     >
> >     > Wayne, I didn't know about FOOTPRINT_FILTER I will switch to 
> using that
> >     > instead (and provide regex search).
> >
> >     Thanks Oliver!
> >
> >     >
> >     > On 31 Oct 2017 06:55, "Seth Hillbrand"  
> >
> >     > 
>   >     >
> >     >     On Mon, Oct 30, 2017 at 11:42 AM, Wayne Stambaugh
> >     >     
> >
> >     
>  >     >
> >     >         On 10/30/2017 1:16 PM, Seth Hillbrand wrote:
> >     >         > Oliver, this is neat and very helpful.
> >     >         >
> >     >         > The greyed-out thing is a wx2.8 bug.  You can work
> >     around it by setting
> >     >         > the foreground color when updating the filter like
> this:
> >     >         >  
> >     >         >  void FOOTPRINT_VIEWER_FRAME::OnFilterUpdated(
> >     wxCommandEvent& event )
> >     >         >  

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-10-31 Thread Oliver Walters
How should I proceed here then?

I would like to see the various libraries being "cached" in the background,
but this is increasing the scope of the work by a large factor.

One thing I have noticed:

In eeschema when you launch the component viewer, it (on first run) maps
and caches all the footprint libraries. This can take AGES (especially on
Windows). However on subsequent launches of the component viewer it appears
instantly. It appears to be keeping a static map of the footprint library
data.

a) Would this be an acceptable approach for the footprint viewer window
b) What happens when the library data changes externally? Does component
viewer need to be reloaded?
c) Can we globally perform this caching in a background thread when KiCad
launches? This will hide the large pauses (up to a minute under Windows)
from the user...

Oliver

On Tue, Oct 31, 2017 at 11:32 PM, Wayne Stambaugh 
wrote:

> On 10/31/2017 1:25 AM, Oliver Walters wrote:
> > Hmm, I had thought that there was a way to load only the *names* of
> > footprints, rather than individually parsing each footprint file. It
> > appears that this is not the case. Any suggestions on how the speed
> > could be improved? Currently I'm reading out all the footprint names in
> > each footprint library and only storing the names (wxString) rather than
> > the MODULE* objects. However, I still have to parse the entire library
> > on load.
> >
> > Ideally, I think it would be good to just read in the names, and then
> > load and display individual MODULE objects on demand.. Is this possible?
>
> This is possible (although not implemented) for library types (kicad,
> geda) that use one file per footprint.  You could just read the file
> names from the folder and load the files as required.  If you want to
> search any other properties of the footprint, then you will have to load
> all of the footprints anyway.  I don't know if this would be worth the
> effort.
>
> For library types that contain multiple footprints per file (legacy,
> Eagle), this wouldn't make much sense.  Parsing the entire file just to
> pick out the footprint names probably isn't going to save you very much
> time.
>
> >
> > On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh  > > wrote:
> >
> > On 10/30/2017 5:23 PM, Oliver Walters wrote:
> > > Thanks for the suggestions on fixing the text. I have that sorted.
> > >
> > > I will look into different ways of caching footprint data so it is
> quicker.
> > >
> > > Wayne, I didn't know about FOOTPRINT_FILTER I will switch to using
> that
> > > instead (and provide regex search).
> >
> > Thanks Oliver!
> >
> > >
> > > On 31 Oct 2017 06:55, "Seth Hillbrand"  
> > > >>
> wrote:
> > >
> > > On Mon, Oct 30, 2017 at 11:42 AM, Wayne Stambaugh
> > > 
> > >>wrote:
> > >
> > > On 10/30/2017 1:16 PM, Seth Hillbrand wrote:
> > > > Oliver, this is neat and very helpful.
> > > >
> > > > The greyed-out thing is a wx2.8 bug.  You can work
> > around it by setting
> > > > the foreground color when updating the filter like this:
> > > >
> > > >  void FOOTPRINT_VIEWER_FRAME::OnFilterUpdated(
> > wxCommandEvent& event )
> > > >  {
> > > > +// Workaround wx2.8 bug showing greyed color
> > > > +if( m_searchBox->GetValue() !=
> > m_searchBox->GetDescriptiveText() )
> > > > +m_searchBox->SetForegroundColour(
> > > > m_searchBox->GetDefaultAttributes().colFg );
> > > > +
> > > >  // Filter is non case sensitive
> > > >  wxString filter = m_searchBox->GetValue().Lower();
> > > >
> > > > The searchbox handles resetting it to grey on idle()
> > when the text is empty.
> > >
> > > Don't you mean wx 3.0?  CMake should not even generate the
> > build
> > > configuration files without wx 3.0 or greater.
> > >
> > >
> > > Hmm... This was an issue back in 2.8 that appears to be only
> > partly
> > > fixed.  The workaround I suggest above is functional but, for
> > this,
> > > we can also execute a cleaner fix by setting the descriptive
> > text in
> > > the declaration:
> > >
> > > @@ -67,9 +67,10 @@ void FOOTPRINT_VIEWER_FRAME::
> ReCreateHToolbar()
> > >  KiBitmap( module_xpm ),
> > >  _( "Select footprint to
> > browse" ) );
> > >
> > > -m_searchBox = new 

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-10-31 Thread Fabrizio Tappero
hi Guys,
this is a great feature. It would be a good thing to have a gray suggestion
often used in webpages and phone apps. Example here:

https://storage.googleapis.com/material-design/publish/material_v_12/assets/0B5ZSepuCX1xOOURmSHNjdktDR28/discoverable-extracted-label1.png


cheers
Fabrizio



On Tue, Oct 31, 2017 at 1:32 PM, Wayne Stambaugh 
wrote:

> On 10/31/2017 1:25 AM, Oliver Walters wrote:
> > Hmm, I had thought that there was a way to load only the *names* of
> > footprints, rather than individually parsing each footprint file. It
> > appears that this is not the case. Any suggestions on how the speed
> > could be improved? Currently I'm reading out all the footprint names in
> > each footprint library and only storing the names (wxString) rather than
> > the MODULE* objects. However, I still have to parse the entire library
> > on load.
> >
> > Ideally, I think it would be good to just read in the names, and then
> > load and display individual MODULE objects on demand.. Is this possible?
>
> This is possible (although not implemented) for library types (kicad,
> geda) that use one file per footprint.  You could just read the file
> names from the folder and load the files as required.  If you want to
> search any other properties of the footprint, then you will have to load
> all of the footprints anyway.  I don't know if this would be worth the
> effort.
>
> For library types that contain multiple footprints per file (legacy,
> Eagle), this wouldn't make much sense.  Parsing the entire file just to
> pick out the footprint names probably isn't going to save you very much
> time.
>
> >
> > On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh  > > wrote:
> >
> > On 10/30/2017 5:23 PM, Oliver Walters wrote:
> > > Thanks for the suggestions on fixing the text. I have that sorted.
> > >
> > > I will look into different ways of caching footprint data so it is
> quicker.
> > >
> > > Wayne, I didn't know about FOOTPRINT_FILTER I will switch to using
> that
> > > instead (and provide regex search).
> >
> > Thanks Oliver!
> >
> > >
> > > On 31 Oct 2017 06:55, "Seth Hillbrand"  
> > > >>
> wrote:
> > >
> > > On Mon, Oct 30, 2017 at 11:42 AM, Wayne Stambaugh
> > > 
> > >>wrote:
> > >
> > > On 10/30/2017 1:16 PM, Seth Hillbrand wrote:
> > > > Oliver, this is neat and very helpful.
> > > >
> > > > The greyed-out thing is a wx2.8 bug.  You can work
> > around it by setting
> > > > the foreground color when updating the filter like this:
> > > >
> > > >  void FOOTPRINT_VIEWER_FRAME::OnFilterUpdated(
> > wxCommandEvent& event )
> > > >  {
> > > > +// Workaround wx2.8 bug showing greyed color
> > > > +if( m_searchBox->GetValue() !=
> > m_searchBox->GetDescriptiveText() )
> > > > +m_searchBox->SetForegroundColour(
> > > > m_searchBox->GetDefaultAttributes().colFg );
> > > > +
> > > >  // Filter is non case sensitive
> > > >  wxString filter = m_searchBox->GetValue().Lower();
> > > >
> > > > The searchbox handles resetting it to grey on idle()
> > when the text is empty.
> > >
> > > Don't you mean wx 3.0?  CMake should not even generate the
> > build
> > > configuration files without wx 3.0 or greater.
> > >
> > >
> > > Hmm... This was an issue back in 2.8 that appears to be only
> > partly
> > > fixed.  The workaround I suggest above is functional but, for
> > this,
> > > we can also execute a cleaner fix by setting the descriptive
> > text in
> > > the declaration:
> > >
> > > @@ -67,9 +67,10 @@ void FOOTPRINT_VIEWER_FRAME::
> ReCreateHToolbar()
> > >  KiBitmap( module_xpm ),
> > >  _( "Select footprint to
> > browse" ) );
> > >
> > > -m_searchBox = new wxSearchCtrl( m_mainToolBar,
> > > ID_MODVIEW_SEARCH_TEXT );
> > > +m_searchBox = new wxSearchCtrl( m_mainToolBar,
> > > ID_MODVIEW_SEARCH_TEXT,
> > > +_( "Enter filter string" ) );
> > >  m_searchBox->SetMinSize( wxSize( 250, 30 ) );
> > > -m_searchBox->SetDescriptiveText( _( "Enter filter
> > string" ) );
> > >
> > >
> > >
> > > ___
> > > Mailing list: 

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-10-31 Thread Wayne Stambaugh
On 10/31/2017 1:25 AM, Oliver Walters wrote:
> Hmm, I had thought that there was a way to load only the *names* of
> footprints, rather than individually parsing each footprint file. It
> appears that this is not the case. Any suggestions on how the speed
> could be improved? Currently I'm reading out all the footprint names in
> each footprint library and only storing the names (wxString) rather than
> the MODULE* objects. However, I still have to parse the entire library
> on load.
> 
> Ideally, I think it would be good to just read in the names, and then
> load and display individual MODULE objects on demand.. Is this possible?

This is possible (although not implemented) for library types (kicad,
geda) that use one file per footprint.  You could just read the file
names from the folder and load the files as required.  If you want to
search any other properties of the footprint, then you will have to load
all of the footprints anyway.  I don't know if this would be worth the
effort.

For library types that contain multiple footprints per file (legacy,
Eagle), this wouldn't make much sense.  Parsing the entire file just to
pick out the footprint names probably isn't going to save you very much
time.

> 
> On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh  > wrote:
> 
> On 10/30/2017 5:23 PM, Oliver Walters wrote:
> > Thanks for the suggestions on fixing the text. I have that sorted. 
> >
> > I will look into different ways of caching footprint data so it is 
> quicker. 
> >
> > Wayne, I didn't know about FOOTPRINT_FILTER I will switch to using that
> > instead (and provide regex search).
> 
> Thanks Oliver!
> 
> >
> > On 31 Oct 2017 06:55, "Seth Hillbrand"  
> > >> 
> wrote:
> >
> >     On Mon, Oct 30, 2017 at 11:42 AM, Wayne Stambaugh
> >     
> >>wrote:
> >
> >         On 10/30/2017 1:16 PM, Seth Hillbrand wrote:
> >         > Oliver, this is neat and very helpful.
> >         >
> >         > The greyed-out thing is a wx2.8 bug.  You can work
> around it by setting
> >         > the foreground color when updating the filter like this:
> >         >  
> >         >  void FOOTPRINT_VIEWER_FRAME::OnFilterUpdated(
> wxCommandEvent& event )
> >         >  {
> >         > +    // Workaround wx2.8 bug showing greyed color
> >         > +    if( m_searchBox->GetValue() !=
> m_searchBox->GetDescriptiveText() )
> >         > +        m_searchBox->SetForegroundColour(
> >         > m_searchBox->GetDefaultAttributes().colFg );
> >         > +
> >         >      // Filter is non case sensitive
> >         >      wxString filter = m_searchBox->GetValue().Lower();
> >         >
> >         > The searchbox handles resetting it to grey on idle()
> when the text is empty.
> >
> >         Don't you mean wx 3.0?  CMake should not even generate the
> build
> >         configuration files without wx 3.0 or greater.
> >
> >
> >     Hmm... This was an issue back in 2.8 that appears to be only
> partly
> >     fixed.  The workaround I suggest above is functional but, for
> this,
> >     we can also execute a cleaner fix by setting the descriptive
> text in
> >     the declaration:
> >
> >     @@ -67,9 +67,10 @@ void FOOTPRINT_VIEWER_FRAME::ReCreateHToolbar()
> >                                      KiBitmap( module_xpm ),
> >                                      _( "Select footprint to
> browse" ) );
> >      
> >     -        m_searchBox = new wxSearchCtrl( m_mainToolBar,
> >     ID_MODVIEW_SEARCH_TEXT );
> >     +        m_searchBox = new wxSearchCtrl( m_mainToolBar,
> >     ID_MODVIEW_SEARCH_TEXT,
> >     +                _( "Enter filter string" ) );
> >              m_searchBox->SetMinSize( wxSize( 250, 30 ) );
> >     -        m_searchBox->SetDescriptiveText( _( "Enter filter
> string" ) );
> >
> >
> >
> >     ___
> >     Mailing list: https://launchpad.net/~kicad-developers
> 
> >      >
> >     Post to     : kicad-developers@lists.launchpad.net
> 
> >      >
> >     Unsubscribe : https://launchpad.net/~kicad-developers
> 
> >      

Re: [Kicad-developers] [PATCH] Add live footprint filtering in modview window

2017-10-30 Thread Oliver Walters
Hmm, I had thought that there was a way to load only the *names* of
footprints, rather than individually parsing each footprint file. It
appears that this is not the case. Any suggestions on how the speed could
be improved? Currently I'm reading out all the footprint names in each
footprint library and only storing the names (wxString) rather than the
MODULE* objects. However, I still have to parse the entire library on load.

Ideally, I think it would be good to just read in the names, and then load
and display individual MODULE objects on demand.. Is this possible?

On Tue, Oct 31, 2017 at 10:40 AM, Wayne Stambaugh 
wrote:

> On 10/30/2017 5:23 PM, Oliver Walters wrote:
> > Thanks for the suggestions on fixing the text. I have that sorted.
> >
> > I will look into different ways of caching footprint data so it is
> quicker.
> >
> > Wayne, I didn't know about FOOTPRINT_FILTER I will switch to using that
> > instead (and provide regex search).
>
> Thanks Oliver!
>
> >
> > On 31 Oct 2017 06:55, "Seth Hillbrand"  > > wrote:
> >
> > On Mon, Oct 30, 2017 at 11:42 AM, Wayne Stambaugh
> > >wrote:
> >
> > On 10/30/2017 1:16 PM, Seth Hillbrand wrote:
> > > Oliver, this is neat and very helpful.
> > >
> > > The greyed-out thing is a wx2.8 bug.  You can work around it
> by setting
> > > the foreground color when updating the filter like this:
> > >
> > >  void FOOTPRINT_VIEWER_FRAME::OnFilterUpdated(
> wxCommandEvent& event )
> > >  {
> > > +// Workaround wx2.8 bug showing greyed color
> > > +if( m_searchBox->GetValue() != 
> > m_searchBox->GetDescriptiveText()
> )
> > > +m_searchBox->SetForegroundColour(
> > > m_searchBox->GetDefaultAttributes().colFg );
> > > +
> > >  // Filter is non case sensitive
> > >  wxString filter = m_searchBox->GetValue().Lower();
> > >
> > > The searchbox handles resetting it to grey on idle() when the
> text is empty.
> >
> > Don't you mean wx 3.0?  CMake should not even generate the build
> > configuration files without wx 3.0 or greater.
> >
> >
> > Hmm... This was an issue back in 2.8 that appears to be only partly
> > fixed.  The workaround I suggest above is functional but, for this,
> > we can also execute a cleaner fix by setting the descriptive text in
> > the declaration:
> >
> > @@ -67,9 +67,10 @@ void FOOTPRINT_VIEWER_FRAME::ReCreateHToolbar()
> >  KiBitmap( module_xpm ),
> >  _( "Select footprint to browse" ) );
> >
> > -m_searchBox = new wxSearchCtrl( m_mainToolBar,
> > ID_MODVIEW_SEARCH_TEXT );
> > +m_searchBox = new wxSearchCtrl( m_mainToolBar,
> > ID_MODVIEW_SEARCH_TEXT,
> > +_( "Enter filter string" ) );
> >  m_searchBox->SetMinSize( wxSize( 250, 30 ) );
> > -m_searchBox->SetDescriptiveText( _( "Enter filter string"
> ) );
> >
> >
> >
> > ___
> > 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] [PATCH] Add live footprint filtering in modview window

2017-10-30 Thread Wayne Stambaugh
On 10/30/2017 5:23 PM, Oliver Walters wrote:
> Thanks for the suggestions on fixing the text. I have that sorted. 
> 
> I will look into different ways of caching footprint data so it is quicker. 
> 
> Wayne, I didn't know about FOOTPRINT_FILTER I will switch to using that
> instead (and provide regex search). 

Thanks Oliver!

> 
> On 31 Oct 2017 06:55, "Seth Hillbrand"  > wrote:
> 
> On Mon, Oct 30, 2017 at 11:42 AM, Wayne Stambaugh
> >wrote:
> 
> On 10/30/2017 1:16 PM, Seth Hillbrand wrote:
> > Oliver, this is neat and very helpful.
> >
> > The greyed-out thing is a wx2.8 bug.  You can work around it by 
> setting
> > the foreground color when updating the filter like this:
> >  
> >  void FOOTPRINT_VIEWER_FRAME::OnFilterUpdated( wxCommandEvent& 
> event )
> >  {
> > +    // Workaround wx2.8 bug showing greyed color
> > +    if( m_searchBox->GetValue() != 
> m_searchBox->GetDescriptiveText() )
> > +        m_searchBox->SetForegroundColour(
> > m_searchBox->GetDefaultAttributes().colFg );
> > +
> >      // Filter is non case sensitive
> >      wxString filter = m_searchBox->GetValue().Lower();
> >
> > The searchbox handles resetting it to grey on idle() when the text 
> is empty.
> 
> Don't you mean wx 3.0?  CMake should not even generate the build
> configuration files without wx 3.0 or greater.
> 
> 
> Hmm... This was an issue back in 2.8 that appears to be only partly
> fixed.  The workaround I suggest above is functional but, for this,
> we can also execute a cleaner fix by setting the descriptive text in
> the declaration:
> 
> @@ -67,9 +67,10 @@ void FOOTPRINT_VIEWER_FRAME::ReCreateHToolbar()
>                                  KiBitmap( module_xpm ),
>                                  _( "Select footprint to browse" ) );
>  
> -        m_searchBox = new wxSearchCtrl( m_mainToolBar,
> ID_MODVIEW_SEARCH_TEXT );
> +        m_searchBox = new wxSearchCtrl( m_mainToolBar,
> ID_MODVIEW_SEARCH_TEXT,
> +                _( "Enter filter string" ) );
>          m_searchBox->SetMinSize( wxSize( 250, 30 ) );
> -        m_searchBox->SetDescriptiveText( _( "Enter filter string" ) );
> 
> 
> 
> ___
> 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 live footprint filtering in modview window

2017-10-30 Thread Oliver Walters
Thanks for the suggestions on fixing the text. I have that sorted.

I will look into different ways of caching footprint data so it is quicker.

Wayne, I didn't know about FOOTPRINT_FILTER I will switch to using that
instead (and provide regex search).

On 31 Oct 2017 06:55, "Seth Hillbrand"  wrote:

> On Mon, Oct 30, 2017 at 11:42 AM, Wayne Stambaugh 
> wrote:
>
>> On 10/30/2017 1:16 PM, Seth Hillbrand wrote:
>> > Oliver, this is neat and very helpful.
>> >
>> > The greyed-out thing is a wx2.8 bug.  You can work around it by setting
>> > the foreground color when updating the filter like this:
>> >
>> >  void FOOTPRINT_VIEWER_FRAME::OnFilterUpdated( wxCommandEvent& event )
>> >  {
>> > +// Workaround wx2.8 bug showing greyed color
>> > +if( m_searchBox->GetValue() != m_searchBox->GetDescriptiveText() )
>> > +m_searchBox->SetForegroundColour(
>> > m_searchBox->GetDefaultAttributes().colFg );
>> > +
>> >  // Filter is non case sensitive
>> >  wxString filter = m_searchBox->GetValue().Lower();
>> >
>> > The searchbox handles resetting it to grey on idle() when the text is
>> empty.
>>
>> Don't you mean wx 3.0?  CMake should not even generate the build
>> configuration files without wx 3.0 or greater.
>>
>
> Hmm... This was an issue back in 2.8 that appears to be only partly
> fixed.  The workaround I suggest above is functional but, for this, we can
> also execute a cleaner fix by setting the descriptive text in the
> declaration:
>
> @@ -67,9 +67,10 @@ void FOOTPRINT_VIEWER_FRAME::ReCreateHToolbar()
>  KiBitmap( module_xpm ),
>  _( "Select footprint to browse" ) );
>
> -m_searchBox = new wxSearchCtrl( m_mainToolBar,
> ID_MODVIEW_SEARCH_TEXT );
> +m_searchBox = new wxSearchCtrl( m_mainToolBar,
> ID_MODVIEW_SEARCH_TEXT,
> +_( "Enter filter string" ) );
>  m_searchBox->SetMinSize( wxSize( 250, 30 ) );
> -m_searchBox->SetDescriptiveText( _( "Enter filter string" ) );
>
>
>
> ___
> 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 live footprint filtering in modview window

2017-10-30 Thread Seth Hillbrand
On Mon, Oct 30, 2017 at 11:42 AM, Wayne Stambaugh 
wrote:

> On 10/30/2017 1:16 PM, Seth Hillbrand wrote:
> > Oliver, this is neat and very helpful.
> >
> > The greyed-out thing is a wx2.8 bug.  You can work around it by setting
> > the foreground color when updating the filter like this:
> >
> >  void FOOTPRINT_VIEWER_FRAME::OnFilterUpdated( wxCommandEvent& event )
> >  {
> > +// Workaround wx2.8 bug showing greyed color
> > +if( m_searchBox->GetValue() != m_searchBox->GetDescriptiveText() )
> > +m_searchBox->SetForegroundColour(
> > m_searchBox->GetDefaultAttributes().colFg );
> > +
> >  // Filter is non case sensitive
> >  wxString filter = m_searchBox->GetValue().Lower();
> >
> > The searchbox handles resetting it to grey on idle() when the text is
> empty.
>
> Don't you mean wx 3.0?  CMake should not even generate the build
> configuration files without wx 3.0 or greater.
>

Hmm... This was an issue back in 2.8 that appears to be only partly fixed.
The workaround I suggest above is functional but, for this, we can also
execute a cleaner fix by setting the descriptive text in the declaration:

@@ -67,9 +67,10 @@ void FOOTPRINT_VIEWER_FRAME::ReCreateHToolbar()
 KiBitmap( module_xpm ),
 _( "Select footprint to browse" ) );

-m_searchBox = new wxSearchCtrl( m_mainToolBar,
ID_MODVIEW_SEARCH_TEXT );
+m_searchBox = new wxSearchCtrl( m_mainToolBar,
ID_MODVIEW_SEARCH_TEXT,
+_( "Enter filter string" ) );
 m_searchBox->SetMinSize( wxSize( 250, 30 ) );
-m_searchBox->SetDescriptiveText( _( "Enter filter string" ) );
___
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 live footprint filtering in modview window

2017-10-30 Thread Wayne Stambaugh
On 10/30/2017 1:16 PM, Seth Hillbrand wrote:
> Oliver, this is neat and very helpful.
> 
> The greyed-out thing is a wx2.8 bug.  You can work around it by setting
> the foreground color when updating the filter like this:
>  
>  void FOOTPRINT_VIEWER_FRAME::OnFilterUpdated( wxCommandEvent& event )
>  {
> +    // Workaround wx2.8 bug showing greyed color
> +    if( m_searchBox->GetValue() != m_searchBox->GetDescriptiveText() )
> +        m_searchBox->SetForegroundColour(
> m_searchBox->GetDefaultAttributes().colFg );
> +
>      // Filter is non case sensitive
>      wxString filter = m_searchBox->GetValue().Lower();
> 
> The searchbox handles resetting it to grey on idle() when the text is empty.

Don't you mean wx 3.0?  CMake should not even generate the build
configuration files without wx 3.0 or greater.

> 
> One downside of this patch is that the initial library load takes quite
> a while (on my machine).  So everytime I want to change a footprint, I
> need to wait 10-15 seconds for all libraries to load.  It seems like we
> should be able to cache that and maybe (greedy here?) thread the load so
> that it happens in the background when the schematic is opened?

There is already threaded footprint caching code used in the component
chooser dialog.  I would imagine it would be useful in this case.  Users
are not going to tolerate UI freezes of 10-15 seconds waiting for the
filter to update.  If this is the case, I retract my original approval.

> 
> -Seth
> 
> 
> On Mon, Oct 30, 2017 at 12:45 AM, Chris Fiege  > wrote:
> 
> Hi Oliver,
> I have tested your patchset against the current master.
> 
> On 10/29/2017 02:37 PM, Oliver Walters wrote:
> > In the footprint viewer window it is often hard to find the exact 
> footprint
> > you want across multiple libraries
> This looks great. Filtering by keywords is really good alternative
> to clicking in the
> library tree in those cases where you already know what you are
> looking for.
> 
> >
> > The attached patch set adds a search filter input to the toolbar.
> I mentioned one thing testing your patchset on my Debian stretch:
> The text in your input box stays gray, even after entering a
> keyword. Switching the text
> to black would help in situations with "not so good" visibility.
> See the attached screen shot.
> 
> 
> --
> 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
> 
> 
> 
> 
> 
> ___
> 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 live footprint filtering in modview window

2017-10-30 Thread Seth Hillbrand
Oliver, this is neat and very helpful.

The greyed-out thing is a wx2.8 bug.  You can work around it by setting the
foreground color when updating the filter like this:

 void FOOTPRINT_VIEWER_FRAME::OnFilterUpdated( wxCommandEvent& event )
 {
+// Workaround wx2.8 bug showing greyed color
+if( m_searchBox->GetValue() != m_searchBox->GetDescriptiveText() )
+m_searchBox->SetForegroundColour(
m_searchBox->GetDefaultAttributes().colFg );
+
 // Filter is non case sensitive
 wxString filter = m_searchBox->GetValue().Lower();

The searchbox handles resetting it to grey on idle() when the text is empty.

One downside of this patch is that the initial library load takes quite a
while (on my machine).  So everytime I want to change a footprint, I need
to wait 10-15 seconds for all libraries to load.  It seems like we should
be able to cache that and maybe (greedy here?) thread the load so that it
happens in the background when the schematic is opened?

-Seth


On Mon, Oct 30, 2017 at 12:45 AM, Chris Fiege  wrote:

> Hi Oliver,
> I have tested your patchset against the current master.
>
> On 10/29/2017 02:37 PM, Oliver Walters wrote:
> > In the footprint viewer window it is often hard to find the exact
> footprint
> > you want across multiple libraries
> This looks great. Filtering by keywords is really good alternative to
> clicking in the
> library tree in those cases where you already know what you are looking
> for.
>
> >
> > The attached patch set adds a search filter input to the toolbar.
> I mentioned one thing testing your patchset on my Debian stretch:
> The text in your input box stays gray, even after entering a keyword.
> Switching the text
> to black would help in situations with "not so good" visibility.
> See the attached screen shot.
>
>
> --
> 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
>
>
___
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 live footprint filtering in modview window

2017-10-30 Thread Wayne Stambaugh
What!  No regular expression search!  Just kidding but you know someone
will ask for it.  I'm fine with merging this as long as the grey text
issue that Chris pointed out is resolved.  It seems odd that the text is
greyed out.  It looks like a focus issue.

Also, is there any reason why the FOOTPRINT_FILTER object was not used?
FOOTPRINT_FILTER already has built in pattern matching of footprints.

On 10/30/2017 5:36 AM, Maciej Sumiński wrote:
> Hi Oliver,
> 
> This is a really useful improvement and works as advertised, I vote for
> merging!
> 
> Cheers,
> Orson
> 
> On 10/29/2017 02:37 PM, Oliver Walters wrote:
>> In the footprint viewer window it is often hard to find the exact footprint
>> you want across multiple libraries
>>
>> The attached patch set adds a search filter input to the toolbar.
>>
>> Entering a filter string in this box updates the list of available
>> libraries and footprints.
>>
>> Features:
>>
>> 1. Wildcard searching with * and ?
>> 2. Include library name in the filter with the : character
>> 3. Not case sensitive
>>
>> To accomplish this, all the libraries have to be loaded first, rather than
>> individually when the library is selected.
>>
>> Because of this change, I have also added a "reload footprint libraries"
>> button to the toolbar.
>>
>> This is a feature I have wanted for a while, I think it saves a lot of
>> effort when searching for footprints.
>>
>> Cheers,
>> 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
>>
> 
> 
> 
> 
> ___
> 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 live footprint filtering in modview window

2017-10-30 Thread Maciej Sumiński
Hi Oliver,

This is a really useful improvement and works as advertised, I vote for
merging!

Cheers,
Orson

On 10/29/2017 02:37 PM, Oliver Walters wrote:
> In the footprint viewer window it is often hard to find the exact footprint
> you want across multiple libraries
> 
> The attached patch set adds a search filter input to the toolbar.
> 
> Entering a filter string in this box updates the list of available
> libraries and footprints.
> 
> Features:
> 
> 1. Wildcard searching with * and ?
> 2. Include library name in the filter with the : character
> 3. Not case sensitive
> 
> To accomplish this, all the libraries have to be loaded first, rather than
> individually when the library is selected.
> 
> Because of this change, I have also added a "reload footprint libraries"
> button to the toolbar.
> 
> This is a feature I have wanted for a while, I think it saves a lot of
> effort when searching for footprints.
> 
> Cheers,
> 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
> 




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] Add live footprint filtering in modview window

2017-10-30 Thread Chris Fiege
Hi Oliver,
I have tested your patchset against the current master.

On 10/29/2017 02:37 PM, Oliver Walters wrote:
> In the footprint viewer window it is often hard to find the exact footprint
> you want across multiple libraries
This looks great. Filtering by keywords is really good alternative to clicking 
in the
library tree in those cases where you already know what you are looking for.

> 
> The attached patch set adds a search filter input to the toolbar.
I mentioned one thing testing your patchset on my Debian stretch:
The text in your input box stays gray, even after entering a keyword. Switching 
the text
to black would help in situations with "not so good" visibility.
See the attached screen shot.


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