kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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 some features in a way similar to
> commercial EDA tools.

AFAIK, most commercial schematic editors allow you to mix simple
hierarchies and complex hierarchies.  They may store them differently
than we do but conceptually they are similar to what we do.  KiCad could
use some indicator (color, graphic, etc.) to indicate if a sheet is
simple or complex.  Under the hood, KiCad uses the same code path to
handle both.  The primary difference is in the file itself.  For simple
hierarchies, there is no component sheet path.  For complex hierarchies,
there is a component sheet path for every sheet that links to the file.

> 
> -Jon
> 
> On Tue, Apr 18, 2017 at 2:32 PM, David Godfrey <info@xxxxxxxxxxx
> <mailto: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>
>>>>     <mailto: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>
>>>>         <https://launchpad.net/~kicad-developers>
>>>>     <https://launchpad.net/~kicad-developers>
>>>>         Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>         <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>         Unsubscribe : https://launchpad.net/~kicad-developers
>>>>     <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>
>>>>     <https://help.launchpad.net/ListHelp>
>>>>
>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     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
>>>     <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
>>     <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>
>>
> 
>     -- 
>     Regards
>     David G
> 
>     _______________________________________________
>     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
>