kicad-developers team mailing list archive

[Martijn Kuipers <martijn.kuipers@xxxxxxxxx>]

On Oct 27, 2010, at 1:27 AM, Wayne Stambaugh wrote:

> On 10/26/2010 2:58 PM, Marco Serantoni wrote:
>> 
>> On 26/ott/2010, at 20.54, Dick Hollenbeck wrote:
>> 
>>> On 10/26/2010 01:50 PM, Marco Serantoni wrote:
>>>> In those days i was thinking about to add an internal event generation for some kicad classes.
>>>> Adding internal events at wxAUIManager could be a good start to implement "external frames" and utilities (plugins) , making possible plug-in new functionalities and probably reorganizing some parts of code
> 
> 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.  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.


Marco could probably explain it better than I can, but from what I understood his intention is to make Kicad event-based and using message-passing, pretty much like wx itself.

A good explanation of this event-based use (for those that do not already know it) can be found here:
http://docs.wxwidgets.org/trunk/overview_events.html

I also misunderstood Marco's email in thinking he was proposing a plugin-framework, but that is not the case. However, having this in Kicad would make it easier to add a plugin-framework. Eagle seems to have a large amount of scripts around, so there must be some use for it. Of course, Kicad is open source so the most wanted plugins could be ported inside Kicad. 

This is just what I understood after a small conversation I had with Marco. Of course, he can probably explain things a lot better than me, although he convinced me it was "a good thing", for what it is worth.

/Martijn
> 
>>>> 
>>>> I've already something ready, if nobody has something against it i wish commit the first tranche of the implementation on pcbnew.
>>>> 
>>> 
>>> If it is as disruptive as you say, can we see a patch and have a short
>>> chat about it before you commit?
>> 
>> Indeed, 
>> Here is the patch, let's chat :)
> 
> 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.
> 
> Wayne
> 
>> 
>> --
>> Marco
>> 
>> 
>> 
>> _______________________________________________
>> 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