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 >> _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
