kicad-developers team mailing list archive

[Martijn Kuipers <martijn.kuipers@xxxxxxxxx>]

On Oct 27, 2010, at 20:55 PM, Wayne Stambaugh wrote:

> On 10/27/2010 1:32 PM, Marco Serantoni wrote:
>> 
>> On 27/ott/2010, at 15.22, Wayne Stambaugh wrote:
>>>> 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. 
>>> 
>>> External scripts cannot handle wxWidgets events so posting events from
>>> BASE_SCREEN.  Unless Marco is proposing the creation of a custom internal
>>> scripting language that runs in the current process this won't work.  AFIAK,
>>> events can't handled be sent across process boundaries.  You need to use some
>>> type of IPC such as sockets or dbus for that.
>>> 
>> No, definitelly, i'm not proposing to create a custom internal scripting language, and in case, the SCREEN is not the best place to start with.
>> I also think that bind command events is not a good way, being  too much gui tied you have to listen Menu and Toolbar ones and tomorrow probably  you should also listen additional command IDs.
>> 
>> 
>>>> 
>>>> 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.
>>> 
>>> It may be a good thing.  I'm not entirely convinced.  All Marco's patch current
>>> does is post events when the grid or zoom level is changed or the BASE_SCREEN
>>> object is initialized.  Since there are no handlers for them, they end up being
>>> ignored by wxWidgets main event loop ( in other words they go to the bit
>>> bucket).  The custom events themselves are good idea and could be dispatched
>>> from the main window in response to the user selecting an new grid or zoom
>>> setting but I don't see the need to send messages from the BASE_SCREEN object.
>> 
>> 
>> If you don't have them, you can neither have a consumer for those events, Chicken and Egg dilemma.
> 
> True.  But what happens if you code egg and chicken never comes?  After a while
> the egg rots.  Remember the boost::python implementation?  Did anyone ever
> write a useful Python program that took advantage of this good idea?  I don't
> remember ever seeing one published since I've been with the project.  I'm sure
> who ever wrote this code thought it was a good idea but they never followed
> through.  This is what I am trying to avoid.  If you can give me an example of
> an "EagleView" window that provides some must have functionality that cannot be
> duplicated in the main application window then I'll give my OK to commit this
> patch.

I suppose that "cannot be duplicated" is too harsh. What if using Marco's solution leads to a cleaner approach, with less code repetition, easier to debug code, etc....



> 
> Wayne
> 
>> 
>> 
>> --
>> Marco
>>