← Back to team overview

kicad-developers team mailing list archive

Re: Undo proposal

 

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


Follow ups

References