kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/27/2010 3:57 PM, Martijn Kuipers wrote:
> 
> 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....

OK.  I'll come clean.  The reason I am hesitant to OK Marco's patch is that I
have already done this using a different development platform with less than
desirable results.  Dispatching messages from non UI objects makes debugging
more difficult because you now have events coming from both directions instead
of only those generated by the UI.  This patch inherently makes Kicad more
complex not less.  Engineering 101: reliability is inversely proportional to
complexity.  I'm not against adding complexity if it provides the project with
something useful.  My concerns are not based on theory or speculation.  I am
speaking from experience here.  Maybe someone else has had a better experience
with this design paradigm than I did.  I believe Marco has commit access to the
testing branch so my input not withstanding he can commit this any time he
wishes.  I commend his decision to check with the group first before committing
this change.  If he feels strongly about the merits of his design and is
willing to see it through, then he probably should commit his code since I seem
to be the only one with any concerns.

Wayne

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