kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/27/2010 1:03 PM, Marco Serantoni wrote:
> 
> On 27/ott/2010, at 02.27, Wayne Stambaugh wrote:
>>
>> Marco,
>>
>> Before you commit this, I would like to see an example of how you are
>> going to handle these events in some type of plug in framework.  
>> I'm just not seeing where you are going with this.  If you are planning on
>> handling these events in any of the Kicad application main windows, that
>> doesn't make much sense because it was a command event generated by the
>> main window that got you to that point in the first place.  
> First implementation would be a little EagleView window, showing the entire 
> schematics and clickable to point the DrawView.
> I see two way to do it: hardcoding the callbacks to the object in the codepaths
> needed, 
> or using events.
> The advantage of events is that you can unbind them if the frame is not visible or 
> to the user and that the approach is reusable.
> Moreover the events way keeps the code contained in the Eagleview window i think
> could be a cleaner way also for this reason.

This is a good start.  You should have anticipated my next question.  What
actions are you going to perform to the board or schematic in this "EagleView"
window that you can't or couldn't perform in the main application window?  If
you make the "EagleView" window a child of the main window, you could add the
"EagleView" window to the event handler chain by calling SetNextHandler().  You
could also override the main application loop to provide the correct behavior
when the "EagleView" window is open.

Wayne.

> 
> 
>> What does make sense to me it to create some custom command events for handling
>> things like zoom and grid selection.  One of the often overlooked
>> features of command events is that they can be used to pass objects and
>> data pointers along with the event by using the Set/GetClientObject and
>> Set/GetClientData.  I'm not rejecting this patch, but I'm concerned that
>> this patch will not be fully developed and no plugins that handle these
>> events will ever be written which means there is an unnecessary level
>> complexity in this code.
> 
> If is a suggest to avoid members and add directly a pointer the changed object, 
> could be a good approach.
> 
> 
>> Your patch has a few issues.  The code formatting is incorrect.  Please
>> see the recently released coding guidelines in the Kicad source tree or
>> use uncrustify to correct the formatting.  Also, try to avoid the wx
>> prefix when naming source code that is not going to be pushed upstream
>> to wxWidgets.  I think we should leave that to the wxWidget developers.
>> I know there are a few other places in where this is used in the Kicad
>> source tree but this is one of those minor things that should be cleaned
>> up.  Thank you for your effort.
> 
> I will change and uncrustify the code.
> 
> --
> Marco
>