kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

Reusable sheets are undeniably cool.  But how often are they used?  Are they worth the headache/bugs/limitations/etc.?

> On 2 Jul 2019, at 19:34, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> 
> Hierarchical sheets, the gift that keeps on giving.  There are many
> subtle and not so subtle issues in play here so be very, very careful.
> The probably of breaking hierarchical schematics in spectacular ways is
> high.  I still haven't determined the ideal solution for the new file
> format, that's why I haven't published the new schematic file format
> document.  I keep hoping a moment of inspiration will make everything
> come into focus but I get the sinking feeling that all solutions are
> going to be a compromise that may be no better than the current design.
> 
> The beauty of the current design is that schematic files can be reused
> (symbol library links aside which will be resolved by the new file
> format) as both hierarchical sheets and as stand alone root sheets.
> This flexibility is also it's Achilles.  This means the that the
> reference for each hierarchical sheet path of each project must be
> stored in the schematic file.  This is why you cannot blindly clear all
> symbol annotations and/or remove sheet paths that are not part of the
> current project in a schematic file.  Otherwise, you may end up blowing
> away the annotation of a different project.  Not a good situation.
> 
> One possible option is to store all of the annotations in the root sheet
> and make hierarchical sheets a special file format that prevent them
> from being used as a root sheet and contain no annotations.  The problem
> with this design is that if a hierarchical sheet is modified by another
> project, the annotations would be broken in the other project although
> that problem exists to some extent already.  I'm not particularly
> trilled with this solution.  I do like the idea of completely portable
> schematic files that our current format provides.
> 
> Maybe the issue is not the current design but rather the lack of user
> interface tools that make it obvious what is going on under the hood
> when creating hierarchical sheets when reusing schematics.  I think a
> lot of the user confusion could be mitigated with some UI improvements.
> 
> Cheers,
> 
> Wayne
> 
> On 7/2/2019 10:46 AM, Jeff Young wrote:
>> Doesn’t get around the problem.  If I do a Find/Replace All, I want changes across all sheets.
>> 
>> Same problem with Symbol Fields Editor, Global Edit Text and Graphics Properties, etc.
>> 
>> And it also doesn’t fit the user’s model when they have multi-unit components split across sheets.  I think they’re expecting they’re still the same component.
>> 
>> Cheers,
>> Jeff.
>> 
>>> On 2 Jul 2019, at 14:41, Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:
>>> 
>>> Hi Jeff-
>>> 
>>> Got it, thanks.
>>> 
>>> When we switch to the new schematic format, could we just make sure that we don't share components around the schematic?  Each has their own SCH_COMPONENT and embedded symbol?
>>> 
>>> -Seth
>>> 
>>> On 2019-07-02 06:25, Jeff Young wrote:
>>>> Hi Seth,
>>>> Let’s say that you change the datasheet of a component that exists in
>>>> two sheets.  The undo information needs to go in each sheet.  Now you
>>>> go to the other sheet and perform another action.  The datasheet
>>>> change is now the second item on the stack in that sheet.  Now you go
>>>> back to the original sheet and undo (the datasheet change is at the
>>>> top here).  What do we do in the other sheet?
>>>> An alternative is to view the whole hierarchy as a single document and
>>>> just maintain a single undo stack.  I still like that; JP still
>>>> doesn’t.  The current proposal is a compromise.
>>>> Cheers,
>>>> Jeff.
>>>>> On 2 Jul 2019, at 14:20, Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:
>>>>> On 2019-07-02 02:51, Jeff Young wrote:
>>>>>> I think I’ve figured out a neat (and easy) way to solve multi-sheet undo:
>>>>>> 1) move the undo stacks to the SCH_EDIT_FRAME
>>>>>> 2) stack sheet navigations as undoable operations
>>>>>> This way the conceptual sheet-specific stacks can’t get out of
>>>>>> alignment as you have to go through the sheet navigation undo’s to get
>>>>>> to them.  And you can’t accidentally undo things that you’re not
>>>>>> focusing on (with the exception of hierarchy-wide ops like Replace
>>>>>> All, but that should be expected).
>>>>>> Thoughts?
>>>>> Maybe...  My first impression though is that I think that could be a frustrating experience.
>>>>> Remind me why we can't put the undo stack in SCH_SCREEN next to the drawlist?
>>>>> -Seth
>> 
>> 
>> _______________________________________________
>> 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