This refactors COMPONENT_TREE_SEARCH_CONTAINER into a Model-View-Adapter
architecture comprising:
- eeschema/cmp_tree_model.h
- CMP_TREE_NODE: Base class representing a searchable library
set with scoring and sorting
- CMP_TREE_NODE_UNIT
- CMP_TREE_NODE_ALIAS
- CMP_TREE_NODE_LIB
- CMP_TREE_NODE_ROOT
- eeschema/cmp_tree_model_adapter.h
- CMP_TREE_MODEL_ADAPTER: mediator between wxDataViewCtrl (via
wxDataViewModel) and CMP_TREE_NODE*
+---+ +------------------+
+---+ Generates | A | | VIEW |
| M | from libs | D | wxDataViewModel |------------------|
| O | <---------- | A | <------------------> | wxDataViewCtrl |
| D | | P | |------------------|
| E | <---------> | T | <------------------- | wxTextCtrl |
| L | UpdateScore | E | UpdateSearchString() |------------------|
+---+ | R | | |
+---+ +------------------+
Representing the data with a proper model allows the wxDataViewCtrl to
be updated in bulk, which is significantly faster than the old method of
populating it one item at a time. This also adds flexibility if more
data is to be added in the future (which may come in handy with the
upcoming .sweet format, as that adds more ways components can be related
to each other).
Replacing the wxTreeListCtrl with a wxDataViewCtrl also significantly
reduces the general GUI quirkiness, as wxDataViewCtrl is much more well
behaved.
This is the right implementation of the commit b25ded4d.
Previously if there were tools launched from another tool,
the settings could be stored in a wrong TOOL_STATE object.
The base-devel package install was missing from the "MSYS2 The Easy Way"
section of the compiling developers document.
Fixes lp:1670067
https://bugs.launchpad.net/kicad/+bug/1670067
Only the root sheet symbol library links were being updated when the
schematic was loaded so changed call to update all sheets.
Fixes lp:1670079
https://bugs.launchpad.net/kicad/+bug/1670079
For some reason, the schematic symbol library link was being regenerated
every time the schematic was redrawn in SCH_SCREEN::Draw(). Remove the
re-link call from the Draw() and Plot() functions.
Add function the SCH_SCREENS to update the links in all of the schematic
sheets.
Update all schematic sheet symbol library links whenever the symbol
library list is modified or any library in the library list is modified.
That should cover all cases where the symbol library links could be
broken.
Refresh schematic window after applying library changes to update any
possible symbol changes.
Add KIWAY message to update the schematic when symbol library changes
could change the schematic. The KIWAY mail was used because the schematic
frame is not a parent of the symbol library editor so wxEvents cannot be
used.
For some reason, rather than using the LIB_PART object reference by an
SCH_COMPONENT to check if a pin was at a given position in the schematic,
a LIB_PART search was performed for every component in a schematic. This
made absolutely no sense and was changed to use the LIB_PART referenced
by the SCH_COMPONENT object. This should significantly speed up any
operations that call SCH_SCREEN functions, IsTerminalPoint(),
MarkConnections(), and IsJunctionNeeded().
Add function to SCH_COMPONENT to access PART_REF object.
- The tools can now specify if the items in the selection must be editable/
deletable. This is groundwork to be able to select/delete DRC markers, which can't
otherwise be edited.
- Fixed disappearing of selected objects
BOARD::GetBoundingBox() now directly calls BOARD::ComputeBoundingBox()
and there is a new method BOARD::GetBoardEdgesBoundingBox() used for
call sites that needed to use ComputeBoundingBox( true ) in the past.
This allows COMMON_TOOLS to implement ZoomFitScreen without knowledge
of the BOARD class.
Adds a similar crossprobe as modules has in pcbnew. When clicking a
sheet in eeschema, the items that are exclusive in that scheet will be
selected in pcbnew if using the GAL canvas.
This appears to normally use the move constructor, but on Jenkins Fedora
20, it tried to use the copy ctor, which is deleted.
Constructing directly fixes this, and is the right way, anyway.
This compares the performance of RICHIO line readers against other
implementations, and can be used for profiling and optimisation.
Current benchmarks provided:
* richio FILE_LINE_READER
* Raw std::ifstream (no LINE_READER wrapper), using getline (so no line
length limiting)
* LINE_READER wrapper around std::istream, with a std::ifstream
implementation
* Existing richio wxInputStream wrappers (with File and FFile
implemntations)
José Ignacio Romero
Chris Pavlina
Simon Richter
jean-pierre charras
Maciej Suminski
Wayne Stambaugh
Cirilo Bernardo
Tomasz Włostowski
Kristoffer Ödmark
Jon Evans
John Beard