kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

Hi Miles,

On 11/29/2017 03:53 PM, miles mccoo wrote:
> Since BOARD_COMMIT was a requested item to be added to the Python
> interface, since it's related to be previous questions about getting a
> redraw on the GAL canvas, and since it could make a good entry to my kicad
> python tutorials, I have some questions.
> 
> 
> My questions will be mostly in the form of summarizing what I think I see
> in the code and hoping that someone will correct my summary as well as the
> actual questions I have. I can then try to add the needed SWIG stuff in a
> sane way.
> 
> Is there a document the explains Board commit? An email thread about it
> perhaps?

There are some comments in include/commit.h. Perhaps it should be extended.

> It seems to me that the broad purpose of BOARD_COMMIT (I'll call it BC) is
> to handle the details for undo. When changing a wire,module,pad,... you
> tell BC what you're doing. Undo then magically happens. Another side effect
> is that the canvas is redrawn when needed.

Think about the BOARD_COMMIT as of the observer pattern. You make a
change to an observed object and create a commit to notify the observers
about the change and its kind.

> If the above summary is wrong, then my coming questions will likely not
> make sense. I haven't actually tried to use BC
> 
> 1) There will be cases when a utility/command developer doesn't care about
> undo. They just want to make their changes and if the result is not
> desired, just revert. This would be particularly true for automated, final
> processing. One that comes to mind is a teardrop generator
> <https://forum.kicad.info/t/yet-another-python-teardrop-script-adds-and-deletes-teardrops-to-a-pcb-v0-3-3/3388>

Have a look at COMMIT::Revert() method, it does exactly what you are
asking for. You can gather all changes using COMMIT and then either
Push() or Revert(), depending on whether you want them to be applied or not.

> *Will BC update still work if you don't tell it about any changes?* I ask
> because BC was given as a better way to redraw the canvas

No, BC handles only the changes it is notified about. If you want, you
can fully refresh state of all observers that would have been notified
by BC, but I think it is not very efficient.

> Following up on Maciej's comments
> <https://lists.launchpad.net/kicad-developers/msg31925.html> I tried
> calling KIGFX::VIEW::Update() but moved items don't move on the screen
> 
> I tried adding the following to Refresh in pcbnew_scripting_helpers.cpp:
>       s_PcbEditFrame->GetGalCanvas()->Refresh();
>       KIGFX::VIEW* view =  s_PcbEditFrame->GetGalCanvas()->GetView();
>       KIGFX::VIEW_GROUP preview( view );
>       view->Update(&preview);

VIEW_GROUP stores items to be updated. If this is the full code, then
VIEW_GROUP is empty and VIEW will not update anything. Refresh() only
redraws the screen and updates items that requested it via VIEW::Update().

> I also tried calling frame->OnModify() which I've seen sprinkled all over.
> Doesn't do the trick either.

OnModify() only tells the frame there are unsaved changes, so e.g. the
save file button is enabled.

> *So how do I force a redraw?*

KIGFX::VIEW* view =  s_PcbEditFrame->GetGalCanvas()->GetView();
item->MethodThatModifiesTheItemState();
view->Update( item );

or

BOARD_COMMIT commit( s_PcbEditFrame );
commit.Modify( item );
item->MethodThatModifiesTheItemState();
commit.Push();

> 2) I see there are a bunch of Add, Remove,... functions that a script would
> need to call. *Why don't the relevant objects just make these calls when
> they are changed? *Then the code for undo is handled once and developers
> can forget about it.

Because you need to update view, connectivity and undo buffer. We would
like to keep actions decoupled from the model and it is a way of doing so.

> 3) I see there are pre and post modify methods. (ie Remove and Removed) *What's
> the difference?* Why use one over the other?

Remove() does the removal action for you, Removed() only notifies the
observers that an item has been removed and you clean up the object.

> 4) Since there isn't a single global BC object, *are there reasons to have
> multiple objects?* Does it make sense to have two objects active at the
> same time? I'm picturing an editing operation that puts some changes in BCa
> and others in BCc, but I can't think of a reason why.

You can do that. I think BC are easier to handle as multiple objects. I
am not sure if this is the case now, but imagine a routine starts saving
items into a commit and then invokes another one that also does the same
- they will interfere with each other. With multiple objects you are in
control.

Regards,
Orson

> I guess that's all I have to ask about that.
> Miles
> 
> 
> 
> _______________________________________________
> 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
>

Attachment: signature.asc
Description: OpenPGP digital signature