kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 11/29/2017 10:41 AM, Maciej Sumiński wrote:
> 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 );

Is this safe?  What happens when pcbnew is using the legacy canvas?

> 
> 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
>>
> 
> 
> 
> 
> _______________________________________________
> 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
>