← Back to team overview

kicad-developers team mailing list archive

Re: Undo/Redo behavior across schematic

 

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 documents and ignore silently desycned ones). The approach of the patch proposed by Oliver for the component table viewer looks promising as well. Maybe this would be a good alternative for the other "global" operations as well? Personally I would prefer possibly desycned stacks over completely wiped out stacks.


Am 18.04.2017 um 15:21 schrieb Wayne Stambaugh:
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 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)
This is perfectly valid solution as well which I find acceptable.  We
already do this with annotation.

-Jon

On Tue, Apr 18, 2017 at 7:46 AM, Nox <noxfiregalaxy@xxxxxxxxx
<mailto: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>
     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
     Unsubscribe : https://launchpad.net/~kicad-developers
     <https://launchpad.net/~kicad-developers>
     More help   : 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



References