[Kicad-developers] KiCad Winbuilder for the GAL branch
Just a short note - for those who have been missing it, there is a modification of Brian's Winbuilder script that works with the GAL branch: http://orson.net.pl/kicad-winbuilder-gal.zip Special thanks goes to Brian Sidebotham and Kerusey Karyu who helped me with the script. The next step is to prepare a Mac OS build, hopefully it will not take too much time. Kind regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad Tool Framework
On 08/10/2013 03:27 PM, Dick Hollenbeck wrote:
On 08/02/2013 12:10 PM, Tomasz Wlostowski wrote:
There is a demo available (kicad-gal-orson branch), that shows a simple
selection tool (Go to Edit-Selection tool with the GAL view enabled).
It's not yet useful for any practical purposes and very unstable - It's
purpose is it just to show the overall idea and prepare ground for
technical discussion.
Thanks in advance for your feedback,
Tom
It looks great.
I have one minor feature that you would have probably added anyways, and that
is a way to
handle persistent or default behaviours that are not addressed in any
particular tool.
Hi Dick,
Sorry for late reply, I just come back from a mountaineering trip.
What do I mean by persistent behaviours? Example:
I like being able to hit the space bar at any time to set the relative origin.
Would be
pain to put that into every tool.
For that I can suggest two things for you to think about:
a) If tools are extended from a base class, the persistent behaviours could be
inherited.
b) If tools are pushed on a stack when they become active
I vote for b). If we go with inheritance, there is a risk that the
TOOL_INTERACTIVE class will gain weight as more persistent behaviours
are added.
, and if you have a mechanism
which the tool uses to report whether it handled an event or not, then if not
handled you
can pass the event to the next tool on the stack. With this strategy you put
the
persistent behaviours into the baseline tool, and stack temporary other tools
onto the
stack above it. Although you can go to more that two high, this architecture
does not
require that you do.
I didn't think about having tools on stack, it's a great idea! Initially
I thought about writing a tool that simply triggers on persistent
commands regardless of what other tool(s) are currently active - for
instance, whenever a Ctrl+LMB click event arrives, the net under the
cursor is highlighted (same for the relative grid command). A stack will
probably make this cleaner and more ordered.
In general, those that have worked with state machines know that they provide
benefits in
troubleshooting. What you have done is to essentially divide what would
otherwise be one
big state machine into smaller ones. And I think this is a great idea. :)
Thanks :) I didn't want to impose any particular way of writing these
FSMs, every programmers has his/her own taste, so he's free to choose
between coroutines, state-as-method or simply a switch(state) {}.
Regards,
Tom
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad Tool Framework
On 08/10/2013 04:28 PM, Lorenzo Marcantonio wrote: On Sat, Aug 10, 2013 at 08:27:26AM -0500, Dick Hollenbeck wrote: a) If tools are extended from a base class, the persistent behaviours could be inherited. b) If tools are pushed on a stack when they become active, and if you have a mechanism(...) Both of those are good for me, the second one is a little more complex and in fact emulates at runtime the VTBL (for example in lua virtual calls work *exactly* like that: when a method is not found it get searched in the ancestor class). (...) Another simpler idea is to install fallback handlers, i.e. everything that's not handled by the current tool is subject to 'default processing'. Hi Lorenzo, IMHO It's a bit similar, but not exactly the same: events come to a tool - it can then react and sometimes consume some of them so that other tools (lower on the stack) don't receive these events anymore. Event handlers are delegates (somewhat similar to signals/slots in Qt) and are dispatched dynamically by the TOOL_MANAGER. This could be probably seen as an enhanced virtual method mechanism... As for the default handlers - there can be a tool permanently residing on the bottom of the stack and dedicated for catching such events. Do we need dynamic method composition? I.e. will tool A be *always* below tool B or there may be a tool C below tool B? I wouldn't preclude such scenario. Having a 2-level stack is as complex as having an N-level one. I agree. The current 'left button' and 'right button' handlers are awfully huge switch statements. Something a little more modular would be helpful for the future :D Fully agree :) Exciting stuff, That's independently of the GAL, I think some/most of this stuff would be useful even for 'stock' kicad, however the GAL *requires* them... too bad you can't have the xor blend in opengl:((( I really prefer the xor contrast compared to Porter/Duff composition (maybe there is some shader trick but good luck having it work fast on the Intel GPUs...). Shaders aren't that bad under intel drivers (the GAL works just fine on a core i7 integrated graphics on my latptop, although Half-life 2 - a 10-year old game doesn't because some texture formats are not supported). Under Linux, if you want performance and truly standard-compliant OpenGL, I'm afraid you have to use the evil Nvidia binary driver... Regard, Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad Tool Framework
On 08/10/2013 11:34 PM, Dick Hollenbeck wrote: Tom, The other thing about your work is that it is important, very important. The push and shove router is something I could have used today. Whatever confidence I used to have in freerouter is gone. It is not working for me very well on this current board, and I am frustrated to no end with it and the lack of support now. Hoping for a better solution, I don't know if mine will be better - AFAIK Alfons has much, much more experience writing EDA software, and there is no literature at all on interactive PCB routing algorithms. As of now, my PS can shove/walkaround tracks and place vias. Its results are not as clean as in the Freerouter (pads sometimes have ugly breakouts which have to be fixed by hand, shoved traces sometimes have right/acute-angled corners, etc.). http://www.youtube.com/watch?v=kzro0Jc70xI Before it's really useful I need dragging tracks/vias and loop removal, and of course few tons of bugs to fix (memory leaks, occasional segfaults and geometry errors). It's also awfully slow on larger boards because of no spatial indexing (but at least the GUI itself is not sluggish, fortunately wx is not Swing/SWT :D ). I'll commit the initial version as soon as the bugs are fixed and I have written the tool for pcbnew. I don't want to give any specific dates, it only depends on the amount of my spare time, current workload and the weather on weekends :) Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad Tool Framework
On 12 August 2013 11:00, Tomasz Wlostowski tomasz.wlostow...@cern.chwrote: On 08/10/2013 11:34 PM, Dick Hollenbeck wrote: Tom, The other thing about your work is that it is important, very important. The push and shove router is something I could have used today. Whatever confidence I used to have in freerouter is gone. It is not working for me very well on this current board, and I am frustrated to no end with it and the lack of support now. Hoping for a better solution, I don't know if mine will be better - AFAIK Alfons has much, much more experience writing EDA software, and there is no literature at all on interactive PCB routing algorithms. As of now, my PS can shove/walkaround tracks and place vias. Its results are not as clean as in the Freerouter (pads sometimes have ugly breakouts which have to be fixed by hand, shoved traces sometimes have right/acute-angled corners, etc.). http://www.youtube.com/watch?**v=kzro0Jc70xIhttp://www.youtube.com/watch?v=kzro0Jc70xI Hi Tom, This video is amazing, I had no idea you were so far forward! It looks amazing already! The only reason you've not had any other response from me is because your specification for the TOOL Framework looks great. I can't offer anything above what you've outlined, other than I'm very excited to see it! Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad Tool Framework
On 08/11/2013 06:39 PM, Dick Hollenbeck wrote: I think that these doubt should be cleared thinking on 'what about if we could have two views on the same board' (which, incidentally, could be a good feature in the far future) That is a fairly fundamental decision, sort of like the decision you have to make before you start building: either a house or a boat. With rapid zoom in and out, a competing idea might be to store viewports as bookmarks. This is a combo of zoom and viewport origin, and maybe cursor position also. With the bookmark you could rapidly BOARD hop. This is trivial to implement with the existing VIEW. I like full screen views, so I am less than neutral about multiple views for a BOARD. Me too. Schematic editor is a different discussion, there you can argue effectively for a tabbed multisheet frame, but I prefer a full frame view of each sheet. IMHO the question is if we should have a possibility of multiple VIEWs of the a single BOARD/schematic sheet. If its only about tabs, I'd say its easier and less invasive to have a separate frame, view and board/sch sheet for each tab. An application that could really take advantage of multiple VIEWs would be some sort of collaborative PCB editor allowing many designers to route the same, big board. But that's far, far future, if ever... Regards, Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad Winbuilder for the GAL branch
FYI: I can't feel as one of the founders of GAL WinBuilder because my contribution was quite marginal. I was just a stone that started an avalanche. Regards Kerusey Karyu___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad Winbuilder for the GAL branch
I do not want to make it a long discussion, but as I based on your fixes I felt obliged to say thank you for that. Who knows? Maybe I would not make it at all without them.. Kind regards, Orson On 08/12/2013 03:02 PM, Kerusey Karyu wrote: FYI: I can't feel as one of the founders of GAL WinBuilder because my contribution was quite marginal. I was just a stone that started an avalanche. Regards Kerusey Karyu ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad Winbuilder for the GAL branch
On 12 August 2013 11:31, Brian Sidebotham brian.sidebot...@gmail.comwrote: Excellent work guys! I've done some binary releases for the glew-cmake project now too. I will likely merge the GAL changes you've made into the main Winbuilder project before making the next binary release for it. Then we'll have the Scripting and GAL work exposed. Thanks very much for your efforts! Best Regards, Brian. Ah, I see you're using a different branch at the momnet, sorry I thought the GAL branch had been merged into KiCad now. I'll wait and merge in the KiCad-Winbuilder updates when the GAL branch is merged into KiCad. Thanks very much for your work Olson. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad Tool Framework
On 08/12/2013 04:19 AM, Tomasz Wlostowski wrote: On 08/10/2013 04:28 PM, Lorenzo Marcantonio wrote: On Sat, Aug 10, 2013 at 08:27:26AM -0500, Dick Hollenbeck wrote: a) If tools are extended from a base class, the persistent behaviours could be inherited. b) If tools are pushed on a stack when they become active, and if you have a mechanism(...) Both of those are good for me, the second one is a little more complex and in fact emulates at runtime the VTBL (for example in lua virtual calls work *exactly* like that: when a method is not found it get searched in the ancestor class). (...) Another simpler idea is to install fallback handlers, i.e. everything that's not handled by the current tool is subject to 'default processing'. Hi Lorenzo, IMHO It's a bit similar, but not exactly the same: events come to a tool - it can then react and sometimes consume some of them so that other tools (lower on the stack) don't receive these events anymore. Event handlers are delegates (somewhat similar to signals/slots in Qt) and are dispatched dynamically by the TOOL_MANAGER. This could be probably seen as an enhanced virtual method mechanism... As for the default handlers - there can be a tool permanently residing on the bottom of the stack and dedicated for catching such events. http://docs.wxwidgets.org/trunk/classwx_evt_handler.html#a78719e8b82c9f9c6e4056b3449df1943 The Connect() method lets you connect wxEvtHandlers together. Seems like the base tool clase should be derived from wxEvtHandler. Significant building blocks of the infrastructure is already in wx that I can tell. My buy in for the tool concept is premised on the notion that the handler functions would exist in the tool which received the event, this is the knowledge encapsulation and the modularity value proposition. If we extend wxEvtHandler, then we can examine events either in virtual boolProcessEvent (wxEvent event) or in a hooked in handler via Connect() but in either case it would be nice to have the initial handler: a) reside in the tool, and b) expand the event arguments into primitive variable types and call a member function, still in the tool, using non-event i.e. primitive argument types, so that such latter function can be SWIGed. The talk about delegates makes me slightly nervous, because to me it connotes an additional class, and that is not what I bought into. It strays from the encapsulation concept that I found so attractive. Dick Do we need dynamic method composition? I.e. will tool A be *always* below tool B or there may be a tool C below tool B? I wouldn't preclude such scenario. Having a 2-level stack is as complex as having an N-level one. I agree. The current 'left button' and 'right button' handlers are awfully huge switch statements. Something a little more modular would be helpful for the future :D Fully agree :) Exciting stuff, That's independently of the GAL, I think some/most of this stuff would be useful even for 'stock' kicad, however the GAL *requires* them... too bad you can't have the xor blend in opengl:((( I really prefer the xor contrast compared to Porter/Duff composition (maybe there is some shader trick but good luck having it work fast on the Intel GPUs...). Shaders aren't that bad under intel drivers (the GAL works just fine on a core i7 integrated graphics on my latptop, although Half-life 2 - a 10-year old game doesn't because some texture formats are not supported). Under Linux, if you want performance and truly standard-compliant OpenGL, I'm afraid you have to use the evil Nvidia binary driver... Regard, Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad Tool Framework
On 08/12/2013 03:46 PM, Dick Hollenbeck wrote:
On 08/12/2013 04:19 AM, Tomasz Wlostowski wrote:
http://docs.wxwidgets.org/trunk/classwx_evt_handler.html#a78719e8b82c9f9c6e4056b3449df1943
The Connect() method lets you connect wxEvtHandlers together. Seems like the
base tool
clase should be derived from wxEvtHandler. Significant building blocks of the
infrastructure is already in wx that I can tell.
Hi,
I would really prefer to avoid mixing wxWidgets classes with the tool
classes. My reasons are:
- tools should be invoke-able without launching any GUI or even without
dependencies on the GUI library,
- tool events are board-space (coordinates) and adjusted to
misbehaviours of wx on different platforms.
- deriving TOOL_BASE/TOOL_INTERACTIVE classes from wxEvtHandler will
drag in wx dependency everywhere, which I find against the modularity
concept. That's why I decided to have a separate TOOL_DISPATCHER class,
which proxies wx events between the GUI (both frame and the draw panel)
and the tools.
My buy in for the tool concept is premised on the notion that the handler
functions
would exist in the tool which received the event, this is the knowledge
encapsulation and
the modularity value proposition.
This is the current situation. Tools request certain types of events
using Go() or Wait() statements, and the events are propagated to either
the state handler (Go) or the next line of code (Wait).
Imagine the following chain of events
- router tool (top of stack) and persistent behaviour tool (bottom of
stack) are active,
- user clicks CTRL-LMB,
- route tool hasn't requested such type of event, so it gets handled by
the next tool in the stack,
- persistent behaviour tool receives the CTRL+LMB click and highlights
the net below the cursor.
b) expand the event arguments into primitive variable types and call a member
function,
still in the tool, using non-event i.e. primitive argument types, so that such
latter
function can be SWIGed.
I don't know much about abilities of SWIG, but can't it pass complex
objects to C++ functions?
The talk about delegates makes me slightly nervous, because to me it connotes an
additional class, and that is not what I bought into. It strays from the
encapsulation
concept that I found so attractive.
They are not exposed to the programmer. By delegate I mean simply a
pointer to a method in a particular object:
class myclass { void method() {} };
myclass myobject;
DELEGATE0void ptr (myobject, myclass::method );
ptr(); - calls myobject::method.
So a transition in a tool FSM is defined by a set of trigger events and
a state handler (the delegate).
Tom
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad Tool Framework
On 08/12/2013 09:09 AM, Tomasz Wlostowski wrote:
On 08/12/2013 03:46 PM, Dick Hollenbeck wrote:
On 08/12/2013 04:19 AM, Tomasz Wlostowski wrote:
http://docs.wxwidgets.org/trunk/classwx_evt_handler.html#a78719e8b82c9f9c6e4056b3449df1943
The Connect() method lets you connect wxEvtHandlers together. Seems like
the base tool
clase should be derived from wxEvtHandler. Significant building blocks of
the
infrastructure is already in wx that I can tell.
Hi,
I would really prefer to avoid mixing wxWidgets classes with the tool
classes. My reasons are:
- tools should be invoke-able without launching any GUI or even without
dependencies on the GUI library,
- tool events are board-space (coordinates) and adjusted to
misbehaviours of wx on different platforms.
- deriving TOOL_BASE/TOOL_INTERACTIVE classes from wxEvtHandler will
drag in wx dependency everywhere, which I find against the modularity
concept. That's why I decided to have a separate TOOL_DISPATCHER class,
which proxies wx events between the GUI (both frame and the draw panel)
and the tools.
Unfortunately, I guess I am losing my hope that we have a unified vision.
We apparently do not.
The project is based on wx. The portions of wx that are objectionable, to me
are:
graphics api, and wxString.
The rest of it are pretty nice. We/you dodged the graphics api issue.
wxString is just a
disease we can live with.
If your concern is the ability to link a tool as a separate DLL/DSO without
pulling in
wx code into that DLL/DSO, then I share that concern, but I don't think it is a
problem, I
believe it can be done with some close investigation.
I am going to go away and cry now. Go silent. I was hopeful we had a unified
vision, but
I fear we do not. Your document did not expose enough details.
When I was young like you my tendency was to over design everything. I have
since changed
to trying to find the simplest solution possible. This has numerous benefits,
not the
least of which is getting other folks to understand your concepts. This is
important in
our current situation because other folks have to write tools, and the API
documentation
and infrastructure of wxEvtHandler is in place.
Maybe a way forward is for you to state why wxEvtHandler is not up to the task,
without
using the explanation, it is part of wx.
Ultimately, KiCad is built on wx, and to try and deny that seems like a pursuit
without a
reward. If and when you want to port KiCad to Qt, then replace wxEvtHandler
then.
I don't have time to back and forth much on this right now.
Dick
My buy in for the tool concept is premised on the notion that the handler
functions
would exist in the tool which received the event, this is the knowledge
encapsulation and
the modularity value proposition.
This is the current situation. Tools request certain types of events
using Go() or Wait() statements, and the events are propagated to either
the state handler (Go) or the next line of code (Wait).
Imagine the following chain of events
- router tool (top of stack) and persistent behaviour tool (bottom of
stack) are active,
- user clicks CTRL-LMB,
- route tool hasn't requested such type of event, so it gets handled by
the next tool in the stack,
- persistent behaviour tool receives the CTRL+LMB click and highlights
the net below the cursor.
b) expand the event arguments into primitive variable types and call a
member function,
still in the tool, using non-event i.e. primitive argument types, so that
such latter
function can be SWIGed.
I don't know much about abilities of SWIG, but can't it pass complex
objects to C++ functions?
The talk about delegates makes me slightly nervous, because to me it
connotes an
additional class, and that is not what I bought into. It strays from the
encapsulation
concept that I found so attractive.
They are not exposed to the programmer. By delegate I mean simply a
pointer to a method in a particular object:
class myclass { void method() {} };
myclass myobject;
DELEGATE0void ptr (myobject, myclass::method );
ptr(); - calls myobject::method.
So a transition in a tool FSM is defined by a set of trigger events and
a state handler (the delegate).
Tom
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
[Kicad-developers] GITHUB_PLUGIN
FYI, In looking at an http plugin for pcbnew, here are my findings so far: It occurred to me that only three class PLUGIN functions seem to be necessary *) IsWriteable() this is one line, return false. *) FootprintEnumerate() *) FootprintLoad() So basically two functions. I wrote FootprintLoad() in about 4 hours using wxHTTP, complete with redirect handling that I added. FootprintEnumerate() is website dependent since you have to parse the dir listing coming back. This is a trivial amount of work, but you have something website specific that is read only for ever. And that is not a terrible thing, quite useful. Then and found an API at GITHUB, and formulated more thoughts about that, so what follows is the formation of a work package: == http://developer.github.com/v3/ is a marriage made in heaven for pcbnew. The only missing building block is https support. We have to parse a little JSON, but this is in boost::property tree already in the source tree. It also gave me a better handle on the use cases of the fp lib table dialog window, which now seems to require a little better support for the options column. I can envision a property table two column popup dialog that lets you show the options in name value form. (Also maybe an additional PLUGIN api function that returns the options that each plugin knows about as fodder for this generic dialog window.) Upon return from the popup dialog, you get a string in form option1=value1,option2,option3=value3 That goes back into the fp lib table dialog options column. And of course this property dialog must parse this string upon invocation. The parser can be re-used if the results go into a PROPERTIES class instance so it can also be passed to the PLUGIN api functions too. RE: https. I have a couple of options in mind for that, after which I am thinking we could start with a read only GITHUB_PLUGIN implementation, and grow into something with write capabilities down the line. I need to solve the https gap in the least painful way. Possibilities I see are: a) cpp-netlib which has HTTPS client, looks like it needs g++ 4.7 to compile, although I've yet to verify this is the case when sub-setting it. b) cherry pick libpoco, which I have used, and has HTTPS client. c) add ssl support on top of wxHTTP using boost and openssl in the same way boost does it for non SSL boost::ASIO sockets. These are currently about equal in my mind. Note that merely having SSL sockets is not as rich as having an HTTPS client, since much header and replay parsing support is need. If anyone is a networking jockey and wants to work with me on this let me know. I think I could and would code the read only form of the plugin in about 2 days if we had the HTTPS client support in place. That is bogging me down right now, and brings the total work to over 3 days, which I have to defer because of other work. Dick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GITHUB_PLUGIN
On Mon, Aug 12, 2013 at 11:13 AM, Dick Hollenbeck d...@softplc.com wrote: FYI, In looking at an http plugin for pcbnew, here are my findings so far: It occurred to me that only three class PLUGIN functions seem to be necessary *) IsWriteable() this is one line, return false. *) FootprintEnumerate() *) FootprintLoad() So basically two functions. I wrote FootprintLoad() in about 4 hours using wxHTTP, complete with redirect handling that I added. FootprintEnumerate() is website dependent since you have to parse the dir listing coming back. This is a trivial amount of work, but you have something website specific that is read only for ever. And that is not a terrible thing, quite useful. Then and found an API at GITHUB, and formulated more thoughts about that, so what follows is the formation of a work package: == http://developer.github.com/v3/ is a marriage made in heaven for pcbnew. The only missing building block is https support. We have to parse a little JSON, but this is in boost::property tree already in the source tree. It also gave me a better handle on the use cases of the fp lib table dialog window, which now seems to require a little better support for the options column. I can envision a property table two column popup dialog that lets you show the options in name value form. (Also maybe an additional PLUGIN api function that returns the options that each plugin knows about as fodder for this generic dialog window.) Upon return from the popup dialog, you get a string in form option1=value1,option2,option3=value3 That goes back into the fp lib table dialog options column. And of course this property dialog must parse this string upon invocation. The parser can be re-used if the results go into a PROPERTIES class instance so it can also be passed to the PLUGIN api functions too. RE: https. I have a couple of options in mind for that, after which I am thinking we could start with a read only GITHUB_PLUGIN implementation, and grow into something with write capabilities down the line. I need to solve the https gap in the least painful way. Possibilities I see are: a) cpp-netlib which has HTTPS client, looks like it needs g++ 4.7 to compile, although I've yet to verify this is the case when sub-setting it. b) cherry pick libpoco, which I have used, and has HTTPS client. c) add ssl support on top of wxHTTP using boost and openssl in the same way boost does it for non SSL boost::ASIO sockets. These are currently about equal in my mind. Note that merely having SSL sockets is not as rich as having an HTTPS client, since much header and replay parsing support is need. If anyone is a networking jockey and wants to work with me on this let me know. I think I could and would code the read only form of the plugin in about 2 days if we had the HTTPS client support in place. That is bogging me down right now, and brings the total work to over 3 days, which I have to defer because of other work. Dick I had seen the github api when I was putting together some of the ideas about the online library sharing. It looks like a lot of the approaches they've used could be borrowed. I presume you are referring to using github directly? I was more thinking the api was suitable to build upon for a custom server implementation with additional commands to handle our application specific usage. Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GITHUB_PLUGIN
On 08/12/2013 10:13 AM, Dick Hollenbeck wrote: FYI, In looking at an http plugin for pcbnew, here are my findings so far: It occurred to me that only three class PLUGIN functions seem to be necessary *) IsWriteable() this is one line, return false. *) FootprintEnumerate() *) FootprintLoad() So basically two functions. I wrote FootprintLoad() in about 4 hours using wxHTTP, complete with redirect handling that I added. FootprintEnumerate() is website dependent since you have to parse the dir listing coming back. What makes this possible is the use of the pretty format and individual *.kicad_mod files in the libpath. The libpath for this plugin is all but the filename portion of the URL, libpath = http://path_to_dir. So to get the footprint, you just http GET http://path_to_dir/footprintname.kicad_mod. Dick This is a trivial amount of work, but you have something website specific that is read only for ever. And that is not a terrible thing, quite useful. Then and found an API at GITHUB, and formulated more thoughts about that, so what follows is the formation of a work package: == http://developer.github.com/v3/ is a marriage made in heaven for pcbnew. The only missing building block is https support. We have to parse a little JSON, but this is in boost::property tree already in the source tree. It also gave me a better handle on the use cases of the fp lib table dialog window, which now seems to require a little better support for the options column. I can envision a property table two column popup dialog that lets you show the options in name value form. (Also maybe an additional PLUGIN api function that returns the options that each plugin knows about as fodder for this generic dialog window.) Upon return from the popup dialog, you get a string in form option1=value1,option2,option3=value3 That goes back into the fp lib table dialog options column. And of course this property dialog must parse this string upon invocation. The parser can be re-used if the results go into a PROPERTIES class instance so it can also be passed to the PLUGIN api functions too. RE: https. I have a couple of options in mind for that, after which I am thinking we could start with a read only GITHUB_PLUGIN implementation, and grow into something with write capabilities down the line. I need to solve the https gap in the least painful way. Possibilities I see are: a) cpp-netlib which has HTTPS client, looks like it needs g++ 4.7 to compile, although I've yet to verify this is the case when sub-setting it. b) cherry pick libpoco, which I have used, and has HTTPS client. c) add ssl support on top of wxHTTP using boost and openssl in the same way boost does it for non SSL boost::ASIO sockets. These are currently about equal in my mind. Note that merely having SSL sockets is not as rich as having an HTTPS client, since much header and replay parsing support is need. If anyone is a networking jockey and wants to work with me on this let me know. I think I could and would code the read only form of the plugin in about 2 days if we had the HTTPS client support in place. That is bogging me down right now, and brings the total work to over 3 days, which I have to defer because of other work. Dick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad Tool Framework
On Mon, Aug 12, 2013 at 08:36:59AM -0500, Dick Hollenbeck wrote: I do that. In our softplc runtime product multiple developers can work on the same control program at the same time from various locations over TCP, and an edit that one developer makes is propagated to other developer's views over TCP. It gets even more interesting when you understand that the program can actually be executing while you are editing it. There is a built in incremental compiler in the softplc runtime. Exactly the same that do SLIME with common lisp. You can replace functions while the program is running (and the function could be in the stack too:D); It's mature technology. In HA is essential that the program continues to run even during upgrades... For a board, well, it could be done; 'just' serialize all the commands to a common core and implements some kind of observer to upgrade the views. As for it usefulness I think that there are more useful things to do in pcbnew:P BTW do the beaglebone survive industrial environments? the sitara seems more apt to low power than high resiliency applications... -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad Tool Framework
On 08/12/2013 05:41 PM, Lorenzo Marcantonio wrote:
On Mon, Aug 12, 2013 at 10:58:31AM +0200, Tomasz Wlostowski wrote:
Thanks :) I didn't want to impose any particular way of writing
these FSMs, every programmers has his/her own taste, so he's free to
choose between coroutines, state-as-method or simply a switch(state)
{}.
Do you know a good way for coroutines in C/C++? i.e. no setjmp/longjmp
ugliness...
Initially, I though about using boost::coroutine, but almost got scared
to death after seeing the example code. Finally I used boost::context +
a small wrapper class.
In kicad-gal-orson, there is a small example in
include/tool/examples/coroutine_example.cpp.
Regards,
Tom
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad Tool Framework
On Mon, Aug 12, 2013 at 11:19:32AM +0200, Tomasz Wlostowski wrote: IMHO It's a bit similar, but not exactly the same: events come to a tool - it can then react and sometimes consume some of them so that other tools (lower on the stack) don't receive these events anymore. Return or call the superclass... it seem pretty stock C++ method handling in action. And exacly like a window procedure function (if you ever used the Windows API) the default handlers - there can be a tool permanently residing on the bottom of the stack and dedicated for catching such events. It would be probably implemented that way, yes. Do we need dynamic method composition? I.e. will tool A be *always* below tool B or there may be a tool C below tool B? I wouldn't preclude such scenario. Having a 2-level stack is as complex as having an N-level one. That was not what I meant. I was 'asking' if the underlying context for a tool was fixed or not; the VTBL obviously is fixed, so that would be not possibile. Anyway that would be not a very big implementation... a call-next-method thingy for this (an object stack) would be nearly trivial to implement (altough a bit verbose, unless you can conjure some template magic). (explanation for call-next-method: look here http://pupeno.com/2007/09/06/common-lisp-method-composition/; and that's only the *default* method composition! of course we would have only the 'primary' column and instead of an is-a relationship that would be a stacked-on relationship) Shaders aren't that bad under intel drivers (the GAL works just fine on a core i7 integrated graphics on my latptop, although Half-life 2 - a 10-year old game doesn't because some texture formats are not supported). Under Linux, if you want performance and truly standard-compliant OpenGL, I'm afraid you have to use the evil Nvidia binary driver... Too bad that the 'current state' of technology in many place in Italy is a Core Duo if you are lucky:D Our biggest box at work, servers aside, is an i3 (with shared memory graphics). Still running some dos boxes for automation control at some clients (ISA cards are becoming scarce, anyway!) No idea on how can Italy be in the G8 ... Until last year I was working on a Via C2/800, so jumping to an Atom was a hge step :P:P it builds kicad in *only* 4 hours! And at least now I can use opengl -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GITHUB_PLUGIN
On 08/12/2013 10:22 AM, Chris Morgan wrote: On Mon, Aug 12, 2013 at 11:13 AM, Dick Hollenbeck d...@softplc.com wrote: FYI, In looking at an http plugin for pcbnew, here are my findings so far: It occurred to me that only three class PLUGIN functions seem to be necessary *) IsWriteable() this is one line, return false. *) FootprintEnumerate() *) FootprintLoad() So basically two functions. I wrote FootprintLoad() in about 4 hours using wxHTTP, complete with redirect handling that I added. FootprintEnumerate() is website dependent since you have to parse the dir listing coming back. This is a trivial amount of work, but you have something website specific that is read only for ever. And that is not a terrible thing, quite useful. Then and found an API at GITHUB, and formulated more thoughts about that, so what follows is the formation of a work package: == http://developer.github.com/v3/ is a marriage made in heaven for pcbnew. The only missing building block is https support. We have to parse a little JSON, but this is in boost::property tree already in the source tree. It also gave me a better handle on the use cases of the fp lib table dialog window, which now seems to require a little better support for the options column. I can envision a property table two column popup dialog that lets you show the options in name value form. (Also maybe an additional PLUGIN api function that returns the options that each plugin knows about as fodder for this generic dialog window.) Upon return from the popup dialog, you get a string in form option1=value1,option2,option3=value3 That goes back into the fp lib table dialog options column. And of course this property dialog must parse this string upon invocation. The parser can be re-used if the results go into a PROPERTIES class instance so it can also be passed to the PLUGIN api functions too. RE: https. I have a couple of options in mind for that, after which I am thinking we could start with a read only GITHUB_PLUGIN implementation, and grow into something with write capabilities down the line. I need to solve the https gap in the least painful way. Possibilities I see are: a) cpp-netlib which has HTTPS client, looks like it needs g++ 4.7 to compile, although I've yet to verify this is the case when sub-setting it. b) cherry pick libpoco, which I have used, and has HTTPS client. c) add ssl support on top of wxHTTP using boost and openssl in the same way boost does it for non SSL boost::ASIO sockets. These are currently about equal in my mind. Note that merely having SSL sockets is not as rich as having an HTTPS client, since much header and replay parsing support is need. If anyone is a networking jockey and wants to work with me on this let me know. I think I could and would code the read only form of the plugin in about 2 days if we had the HTTPS client support in place. That is bogging me down right now, and brings the total work to over 3 days, which I have to defer because of other work. Dick I had seen the github api when I was putting together some of the ideas about the online library sharing. It looks like a lot of the approaches they've used could be borrowed. I presume you are referring to using github directly? Correct. I was more thinking the api was suitable to build upon for a custom server implementation with additional commands to handle our application specific usage. That is also possible if you find the development resources to do it. There are no fixed limits on the number nor the types of pcbnew PLUGINs that get written. If you decide to do that, *start by identifying the development resources*. In my case of GITHUB plugin, because of past discussions that we have had on the topic, and all the work and planning that I put into the PLUGIN API so that it COULD HANDLE REMOTE ACCESS, *I am prepared to provide the development resources* to do GITHUB_PLUGIN. Although if I have to also do the HTTPS client layer work, it will not be in 2 days from now. Having a larger code base to borrow from makes any future plugin work easier of course also. If that does not meet your needs, then do your means analysis up front. Do not assume you can rally the troops to donate valuable time to a large design. You end up with 200 email messages and a piece of paper if you are lucky. The dirty secret about open source is that the code is most always written FOR the guy or organization writing it. It is only coincidental that it solves someone else's problem too. I think a GITHUB plugin will serve my needs, it only looks like I am doing it for someone else. Dick Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to :
Re: [Kicad-developers] Kicad Tool Framework
On Mon, Aug 12, 2013 at 09:24:59AM -0500, Dick Hollenbeck wrote: Maybe a way forward is for you to state why wxEvtHandler is not up to the task, without using the explanation, it is part of wx. I don't see either why wxEvtHandler is not enough for his plan. OTOH since I don't know wx I had already thinked about some ad-hoc solution; I don't know if it can do everything it need to be done. IF and only if it need to only process user action events from what I have read it should be able to do its work (that's what is designed for!). If something more complex need to pass thru it (maybe high-level object selection events or something, I have no idea...) then maybe some evaluation is needed. I think that a prototype/dummy example/technology demo would be in order to evaluate the thing. Ultimately, KiCad is built on wx, and to try and deny that seems like a pursuit without a reward. If and when you want to port KiCad to Qt, then replace wxEvtHandler then. wx data structures suck, so we use STL, for example. And Qt event routing is completely different (but I don't think that would be his reason). boost signals could be an option too (I'm not endorsing them, I only know they exist!). I don't exactly like boost but I don't like C++ either, so it's an acquired taste... Anyway, writing event dispatching code is one of the most boring thing in the world (maybe only second to tallying totals in cobol for a print), so a ready to use solution would be desiderable. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad Tool Framework
On 8/12/2013 10:09 AM, Tomasz Wlostowski wrote:
On 08/12/2013 03:46 PM, Dick Hollenbeck wrote:
On 08/12/2013 04:19 AM, Tomasz Wlostowski wrote:
http://docs.wxwidgets.org/trunk/classwx_evt_handler.html#a78719e8b82c9f9c6e4056b3449df1943
The Connect() method lets you connect wxEvtHandlers together. Seems
like the base tool
clase should be derived from wxEvtHandler. Significant building
blocks of the
infrastructure is already in wx that I can tell.
Sorry it took me so long to look at this but I finally had some time
over the weekend. Your design looks pretty ambitious. I too was
surprised that the base tool class wasn't derived from wxEvtHandler. It
appears that you effectively created your own event object and that
wxEvents will have to be converted to the new event type for processing
by the tool manager. This seems like a lot of unnecessary complexity to
me when any class derived from wxEventHandler would handle wxEvents with
no additional code. This way you could connect your tool to handle any
given wxEvent and then disconnect when the tool is no longer needed.
This should also make it easier to port existing code into the tool
framework.
Hi,
I would really prefer to avoid mixing wxWidgets classes with the tool
classes. My reasons are:
- tools should be invoke-able without launching any GUI or even without
dependencies on the GUI library,
- tool events are board-space (coordinates) and adjusted to
misbehaviours of wx on different platforms.
- deriving TOOL_BASE/TOOL_INTERACTIVE classes from wxEvtHandler will
drag in wx dependency everywhere, which I find against the modularity
concept. That's why I decided to have a separate TOOL_DISPATCHER class,
which proxies wx events between the GUI (both frame and the draw panel)
and the tools.
wxEventHandler is part of the wxBase library which contains no UI code.
See http://docs.wxwidgets.org/trunk/page_libs.html#page_libs_wxbase.
You can even use wxEventHandler in console applications. It's not
limited to UI objects in any way that I can tell. Is there any
technical reason not to use the wxWidgets event handling?
Wayne
My buy in for the tool concept is premised on the notion that the
handler functions
would exist in the tool which received the event, this is the
knowledge encapsulation and
the modularity value proposition.
This is the current situation. Tools request certain types of events
using Go() or Wait() statements, and the events are propagated to either
the state handler (Go) or the next line of code (Wait).
Imagine the following chain of events
- router tool (top of stack) and persistent behaviour tool (bottom of
stack) are active,
- user clicks CTRL-LMB,
- route tool hasn't requested such type of event, so it gets handled by
the next tool in the stack,
- persistent behaviour tool receives the CTRL+LMB click and highlights
the net below the cursor.
b) expand the event arguments into primitive variable types and call a
member function,
still in the tool, using non-event i.e. primitive argument types, so
that such latter
function can be SWIGed.
I don't know much about abilities of SWIG, but can't it pass complex
objects to C++ functions?
The talk about delegates makes me slightly nervous, because to me it
connotes an
additional class, and that is not what I bought into. It strays from
the encapsulation
concept that I found so attractive.
They are not exposed to the programmer. By delegate I mean simply a
pointer to a method in a particular object:
class myclass { void method() {} };
myclass myobject;
DELEGATE0void ptr (myobject, myclass::method );
ptr(); - calls myobject::method.
So a transition in a tool FSM is defined by a set of trigger events and
a state handler (the delegate).
Tom
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad Tool Framework
On Mon, Aug 12, 2013 at 12:00:35PM +0200, Tomasz Wlostowski wrote: occasional segfaults and geometry errors). It's also awfully slow on larger boards because of no spatial indexing (but at least the GUI itself is not sluggish, fortunately wx is not Swing/SWT :D ). One on my biggest point against freerouter... the other one is java-2d blurred graphic (they call it antialiasing, I only see a huge blur). The funny thing is that 90% of the stuff on boards is at 45 degrees multiples, so no antialiasing would be in fact necessary! Did you evaluate some spatial index for the speed issue? AFAIK r-trees are already available in boost, k-d trees are not *too* much difficult to implement (did it one time years ago, but for points, not bigger entities... I don't remember if they can hold bounding boxes, for example). As usual split and rebalancing are the tricky areas... -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad Tool Framework
On 08/12/2013 06:30 PM, Lorenzo Marcantonio wrote: On Mon, Aug 12, 2013 at 05:48:59PM +0200, Tomasz Wlostowski wrote: Initially, I though about using boost::coroutine, but almost got scared to death after seeing the example code. Finally I used Like, almost everything in boost... never seen a more ugly way to code I've seen one: gtk and glib. boost::context + a small wrapper class. In short, setjmp/longjmp wrapped in a class :D All coroutines ultimately end up context switching... Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad Tool Framework
On 08/12/2013 06:24 PM, Lorenzo Marcantonio wrote: Did you evaluate some spatial index for the speed issue? AFAIK r-trees are already available in boost, k-d trees are not *too* much difficult to implement (did it one time years ago, but for points, not bigger entities... I don't remember if they can hold bounding boxes, for example). As usual split and rebalancing are the tricky areas... I have an r-tree implementation, but didn't have time to test it yet. Getting the algorithm to work stably is the first goal. Optimization is the next one. Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GITHUB_PLUGIN
On Mon, Aug 12, 2013 at 1:18 PM, Andrew Seddon and...@circuithub.com wrote: I just did a quick proof of concept API on the CircuitHub side which gives you an endpoint to hit and get the KiCad export of a footprint. Unfortunately I wrote the exporter in the old format rather than S-Expression but i'll rectify that error shortly. Web page for a footprint: https://circuithub.com/footprints/andrew/b0qw7 KiCad export of footprint: https://circuithub.com/api/footprints/andrew/b0qw7/kicad Our format neutral representation (it's plain old human readable SVG which is generated by a plain old Javascript template) https://circuithub.com/api/footprints/andrew/b0qw7/ Cheers, Andy This was also kind of what I had in mind in terms of a basic api. A way to easily fetch a blob from the server. Andrew, any reason you don't include an api rev in your uri? Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GITHUB_PLUGIN
On Mon, Aug 12, 2013 at 12:05 PM, Dick Hollenbeck d...@softplc.com wrote: On 08/12/2013 10:22 AM, Chris Morgan wrote: On Mon, Aug 12, 2013 at 11:13 AM, Dick Hollenbeck d...@softplc.com wrote: FYI, In looking at an http plugin for pcbnew, here are my findings so far: It occurred to me that only three class PLUGIN functions seem to be necessary *) IsWriteable() this is one line, return false. *) FootprintEnumerate() *) FootprintLoad() So basically two functions. I wrote FootprintLoad() in about 4 hours using wxHTTP, complete with redirect handling that I added. FootprintEnumerate() is website dependent since you have to parse the dir listing coming back. This is a trivial amount of work, but you have something website specific that is read only for ever. And that is not a terrible thing, quite useful. Then and found an API at GITHUB, and formulated more thoughts about that, so what follows is the formation of a work package: == http://developer.github.com/v3/ is a marriage made in heaven for pcbnew. The only missing building block is https support. We have to parse a little JSON, but this is in boost::property tree already in the source tree. It also gave me a better handle on the use cases of the fp lib table dialog window, which now seems to require a little better support for the options column. I can envision a property table two column popup dialog that lets you show the options in name value form. (Also maybe an additional PLUGIN api function that returns the options that each plugin knows about as fodder for this generic dialog window.) Upon return from the popup dialog, you get a string in form option1=value1,option2,option3=value3 That goes back into the fp lib table dialog options column. And of course this property dialog must parse this string upon invocation. The parser can be re-used if the results go into a PROPERTIES class instance so it can also be passed to the PLUGIN api functions too. RE: https. I have a couple of options in mind for that, after which I am thinking we could start with a read only GITHUB_PLUGIN implementation, and grow into something with write capabilities down the line. I need to solve the https gap in the least painful way. Possibilities I see are: a) cpp-netlib which has HTTPS client, looks like it needs g++ 4.7 to compile, although I've yet to verify this is the case when sub-setting it. b) cherry pick libpoco, which I have used, and has HTTPS client. c) add ssl support on top of wxHTTP using boost and openssl in the same way boost does it for non SSL boost::ASIO sockets. These are currently about equal in my mind. Note that merely having SSL sockets is not as rich as having an HTTPS client, since much header and replay parsing support is need. If anyone is a networking jockey and wants to work with me on this let me know. I think I could and would code the read only form of the plugin in about 2 days if we had the HTTPS client support in place. That is bogging me down right now, and brings the total work to over 3 days, which I have to defer because of other work. Dick I had seen the github api when I was putting together some of the ideas about the online library sharing. It looks like a lot of the approaches they've used could be borrowed. I presume you are referring to using github directly? Correct. I was more thinking the api was suitable to build upon for a custom server implementation with additional commands to handle our application specific usage. That is also possible if you find the development resources to do it. There are no fixed limits on the number nor the types of pcbnew PLUGINs that get written. If you decide to do that, *start by identifying the development resources*. In my case of GITHUB plugin, because of past discussions that we have had on the topic, and all the work and planning that I put into the PLUGIN API so that it COULD HANDLE REMOTE ACCESS, *I am prepared to provide the development resources* to do GITHUB_PLUGIN. Although if I have to also do the HTTPS client layer work, it will not be in 2 days from now. Having a larger code base to borrow from makes any future plugin work easier of course also. If that does not meet your needs, then do your means analysis up front. Do not assume you can rally the troops to donate valuable time to a large design. You end up with 200 email messages and a piece of paper if you are lucky. The dirty secret about open source is that the code is most always written FOR the guy or organization writing it. It is only coincidental that it solves someone else's problem too. I think a GITHUB plugin will serve my needs, it only looks like I am doing it for someone else. Dick Your thoughts on enumerating parts? Would that be
Re: [Kicad-developers] Kicad Tool Framework
On 08/12/2013 04:24 PM, Dick Hollenbeck wrote: Unfortunately, I guess I am losing my hope that we have a unified vision. We apparently do not. The project is based on wx. The portions of wx that are objectionable, to me are: Dick, Wayne, I said I'd prefer to not use wxEvtHandler for deriving the tools from, but the tool framework code is at a proposal stage, so everything can be changed. I did my own event system, because I wanted to test some concepts (such as FSM state switching and coroutines) which are orthogonal to any UI library. I'm not a wxWidgets guru, and perhaps most of my requirements could be met with some hacking of the wx's event system - I'm asking for your help here. The reasons why I didn't use wxEvent/wxEvtHandler right away are below: - wxEvtHandler specifies a single method for handling events: virtual bool ProcessEvent(). My idea was to have states in separate methods. One reason is avoid enumerating states (and a big switch() statement in MY_TOOL::ProcessEvent()), another is that with states in methods, FSMs could be easily specialized by inheritance. I guess it should be possible to do the same using a wxEventHandler. The base tool class derived from wxEvtHandler could implement its own ProcessEvent() with reworked dispatching code from TOOL_MANAGER, that calls the actual state handlers and/or wakes them coroutines. - AFAIK wx uses integer IDs for defining UI commands. These IDs should to be globally unique, which may be hard to meet, as the project grows and many people contribute tool plugins. I chose to call tools by name. I'm fine with wxEvents if we find a way to ensure that all IDs (also across plugins) are easy to register and unique (hashes?). - wx mouse events work in window space, tools work in board space: I assumed that events passed to the tools will be adjusted to the current state of the view. For example if the view is being auto-scrolled (because the mouse is near the edge), the tools should receive a series of mouse motion events because the cursor moves with respect to the world. Probably overloading wxMouseEvent could fix it, but this brings extra complexity too. In wx, mouse events are in screen space (GetLogicalPosition works for wxDC, but not for the GAL which has a non-wx-related coordinate system) - so the adjustment will have to be done in each state handler method or through some global event filter. The former is not too elegant, and I don't know if the latter is possible. You have much more experience with wxWidgets than me - what do you think about this? Then, there is a problem of distinguishing between events with board-relative coordinates with plain wx mouse events that might be injected from other sources (scripts). Also, tools should be able to request mouse snapping to nearby objects/grid and. It could be done on event level, by adjusting cursor coordinates accordingly. - Drag vs click filtering: Wx gives raw events. A click with a tiny mouse movement is considered a drag, unless some filtering is applied, so an intermediate event filter is required. I did it in TOOL_DISPATCHER class - maybe it could be integrated into wx event stack and work on wxEvent derivatives? - No idea how wx event stack will play with coroutines: One of the key points of my proposal was the ability to handle events in a loop, a thing that we consider really useful and simplifying tool development (a small demo is in pcbnew/tools/selection_tool.cpp in kicad-gal-orson branch). Is it possible to marry coroutines with the wx event system? It would be great if so, otherwise, me Orson would miss them very much (after all, PS and interactive selection tools that we are developing are the most complex ones, that really benefit from all goodies of the tool framework...). - Wanted to avoid translating between VECTOR2/BOX2 and wxRect/wxPoint in the tools. - (a less technical one) I'm slightly biased against wx, so I didn't want to depend too much on it: * Different way of handling events on different plaforms: Let me give an example - the selection tool opens a pop-up menu when multiple items are clicked. We wanted to add some visual feedback that draws a bright, contrast border of the item you're about to select from the clarification menu. Then we discovered that it doesn't work on Windows: under Linux, a menu choice event comes after a menu close event, on Windows the order is opposite. I don't know if wx provides a mechanism for filtering and reordering events and if it can be adapted to fix such issues. * Mouse warping is forbidden on some OSes: emulate it (transparently to the tools, so mouse events need to be adjusted somewhere) or drop it. Existing Kicad tools use mouse warping quite frequently, so it's an important issue. * Linux issues: printing never, ever worked for me and the never-ending story of incompatible versions, which gave me bad feelings about general quality of
Re: [Kicad-developers] Kicad Tool Framework
On 8/12/2013 2:29 PM, Tomasz Wlostowski wrote: On 08/12/2013 04:24 PM, Dick Hollenbeck wrote: Unfortunately, I guess I am losing my hope that we have a unified vision. We apparently do not. The project is based on wx. The portions of wx that are objectionable, to me are: Dick, Wayne, I said I'd prefer to not use wxEvtHandler for deriving the tools from, but the tool framework code is at a proposal stage, so everything can be changed. I did my own event system, because I wanted to test some concepts (such as FSM state switching and coroutines) which are orthogonal to any UI library. I'm not a wxWidgets guru, and perhaps most of my requirements could be met with some hacking of the wx's event system - I'm asking for your help here. The reasons why I didn't use wxEvent/wxEvtHandler right away are below: - wxEvtHandler specifies a single method for handling events: virtual bool ProcessEvent(). My idea was to have states in separate methods. One reason is avoid enumerating states (and a big switch() statement in MY_TOOL::ProcessEvent()), another is that with states in methods, FSMs could be easily specialized by inheritance. I guess it should be possible to do the same using a wxEventHandler. The base tool class derived from wxEvtHandler could implement its own ProcessEvent() with reworked dispatching code from TOOL_MANAGER, that calls the actual state handlers and/or wakes them coroutines. This was pretty much what I was thinking. Derive from wxEvtHandler and override any methods to get your desired behavior an add new methods to cover the use cases specific to the tool event implementation. - AFAIK wx uses integer IDs for defining UI commands. These IDs should to be globally unique, which may be hard to meet, as the project grows and many people contribute tool plugins. I chose to call tools by name. I'm fine with wxEvents if we find a way to ensure that all IDs (also across plugins) are easy to register and unique (hashes?). Unfortunately the wxWidgets folks deprecated ::wxNewId() for 2.9. That used to be the way to do it. Unique IDs are typically used in command events for menus and toolbars. I don't think IDs have any meaning for other events like wxMouseEvent. - wx mouse events work in window space, tools work in board space: I assumed that events passed to the tools will be adjusted to the current state of the view. For example if the view is being auto-scrolled (because the mouse is near the edge), the tools should receive a series of mouse motion events because the cursor moves with respect to the world. Probably overloading wxMouseEvent could fix it, but this brings extra complexity too. In wx, mouse events are in screen space (GetLogicalPosition works for wxDC, but not for the GAL which has a non-wx-related coordinate system) - so the adjustment will have to be done in each state handler method or through some global event filter. The former is not too elegant, and I don't know if the latter is possible. You have much more experience with wxWidgets than me - what do you think about this? Then, there is a problem of distinguishing between events with board-relative coordinates with plain wx mouse events that might be injected from other sources (scripts). Also, tools should be able to request mouse snapping to nearby objects/grid and. It could be done on event level, by adjusting cursor coordinates accordingly. Typically wxMouseEvent::GetLogicalPosition() is used to translate from device coordinates to logical (world) coordinates. It shouldn't be too hard to derive from wxMouseEvent() and add an overloaded version of GetLogicalPosition() that takes an OpenGL context instead of a wxDC to calculate the logical coordinates. - Drag vs click filtering: Wx gives raw events. A click with a tiny mouse movement is considered a drag, unless some filtering is applied, so an intermediate event filter is required. I did it in TOOL_DISPATCHER class - maybe it could be integrated into wx event stack and work on wxEvent derivatives? As of 2.9.3 wxWidgets supports event filtering via wxEventFilter. Unfortunately, in 2.8 you would have to add a filter to the event handler chain to pull this off. - No idea how wx event stack will play with coroutines: One of the key points of my proposal was the ability to handle events in a loop, a thing that we consider really useful and simplifying tool development (a small demo is in pcbnew/tools/selection_tool.cpp in kicad-gal-orson branch). Is it possible to marry coroutines with the wx event system? It would be great if so, otherwise, me Orson would miss them very much (after all, PS and interactive selection tools that we are developing are the most complex ones, that really benefit from all goodies of the tool framework...). As of 2.9 wxWidgets supports event loops via wxEventLoopBase and wxEventLoopActivator(). They may not be useful for what you are trying to do.
Re: [Kicad-developers] Kicad Tool Framework
On Mon, Aug 12, 2013 at 06:31:40PM +0200, Tomasz Wlostowski wrote: I've seen one: gtk and glib. I actually like glib; gtk suffers from doing OO in C, but at least you know what's happening... if it wasn't for all these upper case macros I'd say it's one of the best toolkits around; OTOH with boost... well you *wait* it compiles, then hope does what you want. If it doesn't trigger a compiler bug :D All coroutines ultimately end up context switching... With assorted troubles needing to declare volatile or stuff, at least in C. The problem is doing *correctly* context switching:P -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GITHUB_PLUGIN
On 08/12/2013 01:11 PM, Chris Morgan wrote: On Mon, Aug 12, 2013 at 12:05 PM, Dick Hollenbeck d...@softplc.com wrote: On 08/12/2013 10:22 AM, Chris Morgan wrote: On Mon, Aug 12, 2013 at 11:13 AM, Dick Hollenbeck d...@softplc.com wrote: FYI, In looking at an http plugin for pcbnew, here are my findings so far: It occurred to me that only three class PLUGIN functions seem to be necessary *) IsWriteable() this is one line, return false. *) FootprintEnumerate() *) FootprintLoad() So basically two functions. I wrote FootprintLoad() in about 4 hours using wxHTTP, complete with redirect handling that I added. FootprintEnumerate() is website dependent since you have to parse the dir listing coming back. This is a trivial amount of work, but you have something website specific that is read only for ever. And that is not a terrible thing, quite useful. Then and found an API at GITHUB, and formulated more thoughts about that, so what follows is the formation of a work package: == http://developer.github.com/v3/ is a marriage made in heaven for pcbnew. The only missing building block is https support. We have to parse a little JSON, but this is in boost::property tree already in the source tree. It also gave me a better handle on the use cases of the fp lib table dialog window, which now seems to require a little better support for the options column. I can envision a property table two column popup dialog that lets you show the options in name value form. (Also maybe an additional PLUGIN api function that returns the options that each plugin knows about as fodder for this generic dialog window.) Upon return from the popup dialog, you get a string in form option1=value1,option2,option3=value3 That goes back into the fp lib table dialog options column. And of course this property dialog must parse this string upon invocation. The parser can be re-used if the results go into a PROPERTIES class instance so it can also be passed to the PLUGIN api functions too. RE: https. I have a couple of options in mind for that, after which I am thinking we could start with a read only GITHUB_PLUGIN implementation, and grow into something with write capabilities down the line. I need to solve the https gap in the least painful way. Possibilities I see are: a) cpp-netlib which has HTTPS client, looks like it needs g++ 4.7 to compile, although I've yet to verify this is the case when sub-setting it. b) cherry pick libpoco, which I have used, and has HTTPS client. c) add ssl support on top of wxHTTP using boost and openssl in the same way boost does it for non SSL boost::ASIO sockets. These are currently about equal in my mind. Note that merely having SSL sockets is not as rich as having an HTTPS client, since much header and replay parsing support is need. If anyone is a networking jockey and wants to work with me on this let me know. I think I could and would code the read only form of the plugin in about 2 days if we had the HTTPS client support in place. That is bogging me down right now, and brings the total work to over 3 days, which I have to defer because of other work. Dick I had seen the github api when I was putting together some of the ideas about the online library sharing. It looks like a lot of the approaches they've used could be borrowed. I presume you are referring to using github directly? Correct. I was more thinking the api was suitable to build upon for a custom server implementation with additional commands to handle our application specific usage. That is also possible if you find the development resources to do it. There are no fixed limits on the number nor the types of pcbnew PLUGINs that get written. If you decide to do that, *start by identifying the development resources*. In my case of GITHUB plugin, because of past discussions that we have had on the topic, and all the work and planning that I put into the PLUGIN API so that it COULD HANDLE REMOTE ACCESS, *I am prepared to provide the development resources* to do GITHUB_PLUGIN. Although if I have to also do the HTTPS client layer work, it will not be in 2 days from now. Having a larger code base to borrow from makes any future plugin work easier of course also. If that does not meet your needs, then do your means analysis up front. Do not assume you can rally the troops to donate valuable time to a large design. You end up with 200 email messages and a piece of paper if you are lucky. The dirty secret about open source is that the code is most always written FOR the guy or organization writing it. It is only coincidental that it solves someone else's problem too. I think a GITHUB plugin will serve my needs, it only looks like I am doing it for someone else. Dick
Re: [Kicad-developers] GITHUB_PLUGIN
On 08/12/2013 11:54 PM, Dick Hollenbeck wrote: On 08/12/2013 01:11 PM, Chris Morgan wrote: On Mon, Aug 12, 2013 at 12:05 PM, Dick Hollenbeck d...@softplc.com wrote: On 08/12/2013 10:22 AM, Chris Morgan wrote: On Mon, Aug 12, 2013 at 11:13 AM, Dick Hollenbeck d...@softplc.com wrote: FYI, In looking at an http plugin for pcbnew, here are my findings so far: It occurred to me that only three class PLUGIN functions seem to be necessary *) IsWriteable() this is one line, return false. *) FootprintEnumerate() *) FootprintLoad() So basically two functions. I wrote FootprintLoad() in about 4 hours using wxHTTP, complete with redirect handling that I added. FootprintEnumerate() is website dependent since you have to parse the dir listing coming back. This is a trivial amount of work, but you have something website specific that is read only for ever. And that is not a terrible thing, quite useful. Then and found an API at GITHUB, and formulated more thoughts about that, so what follows is the formation of a work package: == http://developer.github.com/v3/ is a marriage made in heaven for pcbnew. The only missing building block is https support. We have to parse a little JSON, but this is in boost::property tree already in the source tree. It also gave me a better handle on the use cases of the fp lib table dialog window, which now seems to require a little better support for the options column. I can envision a property table two column popup dialog that lets you show the options in name value form. (Also maybe an additional PLUGIN api function that returns the options that each plugin knows about as fodder for this generic dialog window.) Upon return from the popup dialog, you get a string in form option1=value1,option2,option3=value3 That goes back into the fp lib table dialog options column. And of course this property dialog must parse this string upon invocation. The parser can be re-used if the results go into a PROPERTIES class instance so it can also be passed to the PLUGIN api functions too. RE: https. I have a couple of options in mind for that, after which I am thinking we could start with a read only GITHUB_PLUGIN implementation, and grow into something with write capabilities down the line. I need to solve the https gap in the least painful way. Possibilities I see are: a) cpp-netlib which has HTTPS client, looks like it needs g++ 4.7 to compile, although I've yet to verify this is the case when sub-setting it. b) cherry pick libpoco, which I have used, and has HTTPS client. c) add ssl support on top of wxHTTP using boost and openssl in the same way boost does it for non SSL boost::ASIO sockets. These are currently about equal in my mind. Note that merely having SSL sockets is not as rich as having an HTTPS client, since much header and replay parsing support is need. If anyone is a networking jockey and wants to work with me on this let me know. I think I could and would code the read only form of the plugin in about 2 days if we had the HTTPS client support in place. That is bogging me down right now, and brings the total work to over 3 days, which I have to defer because of other work. Dick I had seen the github api when I was putting together some of the ideas about the online library sharing. It looks like a lot of the approaches they've used could be borrowed. I presume you are referring to using github directly? Correct. I was more thinking the api was suitable to build upon for a custom server implementation with additional commands to handle our application specific usage. That is also possible if you find the development resources to do it. There are no fixed limits on the number nor the types of pcbnew PLUGINs that get written. If you decide to do that, *start by identifying the development resources*. In my case of GITHUB plugin, because of past discussions that we have had on the topic, and all the work and planning that I put into the PLUGIN API so that it COULD HANDLE REMOTE ACCESS, *I am prepared to provide the development resources* to do GITHUB_PLUGIN. Although if I have to also do the HTTPS client layer work, it will not be in 2 days from now. Having a larger code base to borrow from makes any future plugin work easier of course also. If that does not meet your needs, then do your means analysis up front. Do not assume you can rally the troops to donate valuable time to a large design. You end up with 200 email messages and a piece of paper if you are lucky. The dirty secret about open source is that the code is most always written FOR the guy or organization writing it. It is only coincidental that it solves someone else's problem too. I think a GITHUB plugin will serve my needs, it only looks like I am
Re: [Kicad-developers] Kicad Tool Framework
On 08/12/2013 01:29 PM, Tomasz Wlostowski wrote:
On 08/12/2013 04:24 PM, Dick Hollenbeck wrote:
Unfortunately, I guess I am losing my hope that we have a unified vision.
We apparently do not.
The project is based on wx. The portions of wx that are objectionable, to
me are:
Dick, Wayne,
I said I'd prefer to not use wxEvtHandler for deriving the tools from,
but the tool framework code is at a proposal stage, so everything can be
changed.
I did my own event system, because I wanted to test some concepts (such
as FSM state switching and coroutines) which are orthogonal to any UI
library. I'm not a wxWidgets guru, and perhaps most of my requirements
could be met with some hacking of the wx's event system - I'm asking for
your help here. The reasons why I didn't use wxEvent/wxEvtHandler right
away are below:
- wxEvtHandler specifies a single method for handling events:
virtual bool ProcessEvent().
My idea was to have states in separate methods. One reason is avoid
enumerating states (and a big switch() statement in
MY_TOOL::ProcessEvent()), another is that with states in methods, FSMs
could be easily specialized by inheritance. I guess it should be
possible to do the same using a wxEventHandler. The base tool class
derived from wxEvtHandler could implement its own ProcessEvent() with
reworked dispatching code from TOOL_MANAGER, that calls the actual state
handlers and/or wakes them coroutines.
I cannot see how coroutines would work in a wx GUI program. Coroutines by
definition are
the same OS thread under a second or more CPU stack region. So we are talking
about one
thread mimicking multiple. Or are you using a contorted definition? No way
coroutines
will work in a wx program IMO.
The goal of the tool event handler should be to cooperatively return as fast as
it can,
since it is being called on the wx event handler thread. If you cannot process
the event
and cooperatively return as fast as you can, you need a separate wxThread to do
on going
work. This, at least if you want the user to continue to see quick interactive
behaviour.
If you were doing a print run, where the user might have lower expectations on
responsiveness, then you don't need the wxThread helper thread. If the
wxThread also had
its own wxEvtHandler, you can queue wxEvents through there, so it becomes a way
to
dispatch work tasks to a helper thread, say long compute runs, or whatever.
The two
threads could simply use wxEvents to talk to each other, each by poking
something into the
others event queue. Let's hope wxThread helpers are not often needed. Most
tools won't
need them.
If you were to duplicate the pcbnew behaviours we have now under the new tool
architecture, your tools would mostly all have one state in them. The act of
changing
tools would be the main state machine. You only need more than one state,
within the same
tool, when you plan on doing something different with the same kind of event.
If you
always intend to do the same thing with any given event type, you do not need
more than
one state in a tool. The tool can be thought of as a sub-state machine. The
tool change
is the topmost state machine.
I have used member function pointers and switch statements to put a state
machine into a
class. Here we are talking about 're-enterable' state machines, since we
cooperatively
return as fast as we can after each event. When we come back in to the tool via
ProcessEvent(), the tool can route execution to the state specific code. When
picking
between member function pointer or enums to identify states, enums are my
preference,
because under a debugger if you have a variable that is an
enum STATE_T
{
} m_state;
Then in the debugger m_state will always show with its *named* value. No such
joy with a
member function pointer. If the enums are all sequential from zero, then the
switch( m_state )
statement will be translated to an array like jump table by the compiler and
this is only
basically two machine instructions.
The base tool class could be rigged to duplicate some of the event
classification that
wxWindow::ProcessEvent() does. This way you can at least get your mouse events
and
keyboard events into to separate virtual functions, and derived tool classes
would need to
override these if they want to do anything tool specific within these
categories of
events. It could also be a runtime decision as to whether the base tool class
does the
classification and routes mouse events to OnMouseHandler(), or not. A boolean
to the
constructor could decide yeah or nay at the base tool class.
If you are going to use multiple states in a tool, and a OnMouseHandler(), and a
OnKeyHandler(), then you would need a switch( m_state ) in each overloaded
virtual member
function.
There are certain aspects of wxEvtHandler that we do not need for a tool, such
as the
message queue (except for the case of a helper wxThread).
I think if you
