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 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)
I think that it is a pretty safe bet that this wont happen. I would not allow this change. The usage you described is precisely why complex hierarchies exist. >> >>> Cheers, >>> Tom >>> >>>> -Jon >>>> >>>> On Tue, Apr 18, 2017 at 7:46 AM, Nox <noxfiregal...@gmail.com >>>> <mailto:noxfiregal...@gmail.com>> 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@lists.launchpad.net >>>> <mailto:kicad-developers@lists.launchpad.net> >>>> 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@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 >> > > -- > Regards > David G > > > _______________________________________________ > 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
