Here is a bug tacker for the bug:
https://bugs.launchpad.net/kicad/+bug/1683297
This is observed from the latest ( git SHA1 ID:
01f5a129a317522f544e8bf75f4f36668dae1681) build of the master branch,
running in Ubuntu 16.04.
This can be verified by creating a copper zone, and then creating a
Of course it is a valid solution but is it really the most convenient to
break the undo/redo stack for a operation like annotiating? As already
mentioned there are "text" editors (e.g. visual studio) which handle a
replacement in multiple files differently (e.g. try to undo/redo on all
On 4/18/2017 3:35 PM, Jon Evans wrote:
> Hi David,
>
> This is why other EDA tools have a clear differentiation between
> hierarchical blocks (what you are talking about) and multi-sheet
> schematics (what I am talking about). The fact that KiCad mixes the two
> makes it difficult to implement
On 4/18/2017 3:37 PM, Tomasz Wlostowski wrote:
> On 18.04.2017 21:32, David Godfrey wrote:
>
>>> This would break complex hierarchies where a file is referenced in more
>>> than one sheet. Using separate files for each sheet actually makes
>>> designs less reusable in complex hierarchies. It
Hey David,
On 4/18/2017 3:32 PM, David Godfrey wrote:
> Hi Jon
>
>
> On 18/04/17 21:27, Wayne Stambaugh wrote:
>> On 4/18/2017 9:03 AM, Tomasz Wlostowski wrote:
>>> On 18.04.2017 14:55, Jon Evans wrote:
(branched from the component table viewer thread)
In my opinion, a schematic
On 18.04.2017 21:32, David Godfrey wrote:
>> This would break complex hierarchies where a file is referenced in more
>> than one sheet. Using separate files for each sheet actually makes
>> designs less reusable in complex hierarchies. It doesn't make sense to
>> save the same file multiple
Hi David,
This is why other EDA tools have a clear differentiation between
hierarchical blocks (what you are talking about) and multi-sheet schematics
(what I am talking about). The fact that KiCad mixes the two makes it
difficult to implement some features in a way similar to commercial EDA
Wayne,
I have now fixed this such that UNDO actions are pushed to the UNDO stack
for the associated sheet. All UNDO actions for a given sheet are grouped so
a single Ctrl-Z will undo all components changed in the table (for the
given sheet).
Please find patch _007 attached (must be appli ed atop
On 4/18/2017 9:03 AM, Tomasz Wlostowski wrote:
> On 18.04.2017 14:55, Jon Evans wrote:
>> (branched from the component table viewer thread)
>>
>> In my opinion, a schematic with multiple sheets is not like a text
>> editor with multiple documents. The schematic editor is working on a
>> single
On 4/18/2017 8:55 AM, Jon Evans wrote:
> (branched from the component table viewer thread)
>
> In my opinion, a schematic with multiple sheets is not like a text
> editor with multiple documents. The schematic editor is working on a
> single project, and it should be way more common to apply
I have attached two more patches that address issues raised by Tom and JP:
_005:
- Adds OK/CANCEL dialog
- Removes onClose event
- Moves UI updates into onUpdateUI event
_006:
- Fixes editing of "duplicate" components (e.g. components on sheets that
are referenced multiple times)
- Editing one
@Cirilo, I pushed your patch. Thanks for the fix.
On 4/17/2017 5:32 PM, Cirilo Bernardo wrote:
> This is expected since the plugin directory is "lib/kicad/.." which
> is what wxWidgets always reports on Linux. If a multiarch directory
> was used such as lib/x86_64-linux-gnu/kicad/... as in the
On 4/18/2017 5:01 AM, Oliver Walters wrote:
> Wayne,
>
> With this in mind, I am unsure how to determine (given a list of
> components) which sheet they originate in.
All of this information is in the SCH_REFERENCE object. You will have
to cross reference the SCH_SHEET_PATH to find the
On 18.04.2017 14:55, Jon Evans wrote:
> (branched from the component table viewer thread)
>
> In my opinion, a schematic with multiple sheets is not like a text
> editor with multiple documents. The schematic editor is working on a
> single project, and it should be way more common to apply
Hi,
On 18.04.2017 14:55, Jon Evans wrote:
> In my opinion, a schematic with multiple sheets is not like a text
> editor with multiple documents. The schematic editor is working on a
> single project, and it should be way more common to apply operations
> (that might want to be undone) to all
(branched from the component table viewer thread)
In my opinion, a schematic with multiple sheets is not like a text editor
with multiple documents. The schematic editor is working on a single
project, and it should be way more common to apply operations (that might
want to be undone) to all
On 4/18/2017 3:12 AM, jp charras wrote:
> Le 17/04/2017 à 22:51, Nox a écrit :
>> I know that I already suggested that in another context but what about
>> changing the undo/redo
>> semantic to the more common approach to maintain an global undo/redo stack
>> and switch the view
>> accordingly?
I agree with you about the multi file editor behaviour. There it is
natural that the undo/redo works per file. But is this behaviour also
reasonable for a schematic? I just checked the behaviour of visual
studio. There global replacement will be reverted if the stack is in
sync. Else only the
Wayne,
With this in mind, I am unsure how to determine (given a list of
components) which sheet they originate in.
I need a SCH_EDIT_FRAME* for each component, to work out where to push each
undo operation.
I have a list of SCH_REFERENCE objects, is there a way of determining where
each object
Le 17/04/2017 à 22:51, Nox a écrit :
> I know that I already suggested that in another context but what about
> changing the undo/redo
> semantic to the more common approach to maintain an global undo/redo stack
> and switch the view
> accordingly? I know that the "per screen" is the established
20 matches
Mail list logo
