kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/27/2010 4:29 AM, Martijn Kuipers wrote:
> 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.

Kicad is message based.  It uses events ( mostly wxWidgets events and some
custom events) just like any other GUI application does.  I'm trying to
understand why Marco wants to send events from what is effectively a container
object.

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

This is the documentation that describes events in objects derived from
wxWindow not using events in non-wxWindow based objects.  The BASE_SCREEN
object is not derived from wxWindow even though it's name may suggest
otherwise.  Where do the actions come from that cause BASE_SCREEN to generate
an event?  It cannot respond to mouse, keyboard, or other input events.  I
think I have a pretty firm grasp on the event concept.  See the source file
eeschema/dialog_schematic_find.h for an example of where a custom event is
typically used.

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

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

Wayne

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