kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #29230
Re: Undo/Redo behavior across schematic
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
tools.
-Jon
On Tue, Apr 18, 2017 at 2:32 PM, David Godfrey <info@xxxxxxxxxxx> 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 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 schematic sheets, than it is to
> apply operations across all files you happen to have open in a text
> editor (other than "find in files", of course).
>
> In my experience, other EDA tools work around the "undoing global
> changes" issue that JP mentioned in the same way that text editors do
> when you replace in multiple files -- they warn the user that the change
> cannot be undone, and sometimes leave the files/sheets in an "unsaved"
> state so there is actually a way to undo it for certain files (i.e. by
> closing them without saving)
>
>
> Hi Jon,
>
> I would suggest having one schematic file per schematic sheet. This
> would greatly simplify the undo/view model, while we could still have
> multiple documents open in tabs. Moreover, each sheet in a separate file
> would make design reuse much easier...
>
> 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 times just for the reference designator
> differences.
>
> It would also break re-usability. I I have a schematic file that
> represents an instrument amp, and use it as a sheet multiple times, I'd
> then expect to modify the schematic once and have the change propagate
> across all instances of that sheet. (eg: adding an additional filter cap)
>
> Cheers,
> Tom
>
>
> -Jon
>
> On Tue, Apr 18, 2017 at 7:46 AM, Nox <noxfiregalaxy@xxxxxxxxx<mailto:noxfiregalaxy@xxxxxxxxx> <noxfiregalaxy@xxxxxxxxx>> wrote:
>
> 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 active document is affected. So I
> guess you are right. We have to first agree which way redo/undo
> should work. Personally I would perfere to move to a "mixed" or
> global redo/undo.
>
> What do you think: how hard will it be to implement a "container"
> undo/redo item which batchs multiple changes (e.g. for component
> changes, annotation, etc) and has an ID to check with all open
> sheets if the top most change matches. Of course it is questionable
> if a "silent" partial undo/redo is the best way to handle desynced
> stacks. Or might a global redo/undo will be easier to maintain? Or
> should global operations simply always "break" the local undo/redo
> stacks (so our "state of the art"-handling)?
>
> P.S: should we branch the discussion here maybe?
>
>
>
> Am 18.04.2017 um 09:12 schrieb jp charras:
>
> 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
> way in kicad and that it is very
> dangerous to break existing workflows. But the undo/redo
> behaviour is currently hardly
> "understandable" for beginners. E.g. why does the undo not
> follow my actions but stays on one view?
> Why does exporting the netlist break the undo? Why can
> automatic annotation not be reverted? The
> undo list wiped on a frequently basis that personally i
> hardly trust into the undo functionality at
> all.
>
> Would it be an option to introduce a "test version" of a
> global undo/redo to get some feedback from
> the crowed which way would be preferred?
>
> For me, the problem is not to have a global or per screen
> undo/redo list, but what an user is
> expecting when undoing/redoing a change.
>
> We *always* expect to undo the last change.
> Any undo/redo system has this behavior.
>
> Now consider an editor (the schematic editor with 3 sheets for
> instance, but this is also the case
> of text editors with 3 files opened and currently edited).
>
> 1 - in sheet1 you call a tool (component table editor, automatic
> annotation) which modify all sheets.
>
> 2 - after that you enter sheet2 and make new changes then
> sheet3 and also make new changes.
>
> 3 - back to sheet1 and try to undelete the latest change in this
> sheet: this is the global change
> (i.e. annotation). This is possible in sheet1.
> But how can you undo this annotation in others sheets: this is
> not the latest change and cannot be
> undone safely (you can have deleted/replaced/edited a symbol in
> other sheets, or deleted a sheet):
> what is the actual meaning of "undo the annotation" in other
> sheets).
>
> And ultimately:
> What a undo (and therefore redo) command must undo:
> 1 - the latest change in the full schematic (global undo/redo)
> or
> 2 - the latest change in the currently edited (active) sheet
> (local undo/redo)
>
> This is a choice, and the answer is for me not trivial.
>
> It could be worth to know what is the option for global/local
> changes in a schematic hierarchy in
> other schematic editors.
>
> Multi-file text editors can undo the latest change only in the
> active file, not in all opened files.
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx> <kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers> <https://launchpad.net/~kicad-developers>
> More help : https://help.launchpad.net/ListHelp
> <https://help.launchpad.net/ListHelp> <https://help.launchpad.net/ListHelp>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
>
> --
> Regards
> David G
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
>
Follow ups
References