kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

This is what I am thinking for the new schematic file format but this
design concept may be as rife with issues as our current design so it
may be a case of the devil you know versus the devil you don't know.

On 7/2/2019 3:02 PM, Seth Hillbrand wrote:
> I'm with Jeff here.  It may be easier to implement a "schematic block"
> library function like [1] to handle the reusable aspect for UX and then
> tie the actual sheets to the root schematic.
> 
> -S
> 
> [1] https://bugs.launchpad.net/kicad/+bug/1797683
> 
> On 2019-07-02 14:48, Jeff Young wrote:
>> 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
>>
>>
>> _______________________________________________
>> 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