Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/10/2013 04: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,
> 
> Dick




Alfons,  if you are reading this mailing list:


I regret having said the above.  I have had a change of heart, and wish to 
publicly
apologize to you.  You have written one of the greatest software tools that I 
have ever used.

Rewards are slim when one donates a bunch of valuable time.  The donation is 
even more
costly when that time is filled by valuable expertise.  And having to bear any 
kind of
criticism after one does that is simply painful.  Life need not be about that.  
So I am
sorry Alfons.

So Alfons, if you are reading this, please know that your work is very 
appreciated.  I
find much to like in your work, and in particular the last few hours have been 
one
pleasant surprise after another.  But even without that, I owed you an apology.


So with a new perspective, and humbled by your amazing work, I offer my 
apologies.


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

[Miguel Angel Ajo Pelayo]

I don't have much time to keep track of your talk, just wanted to say that
the work being done here is awesome.

Tomasz, this is awesome:
http://www.youtube.com/watch?**v=kzro0Jc70xI

About the specifications, MVC is proven to result in good, clean, and easy
to test code, so thumbs up for that,

 I've never worked with coroutines in C++, so I can't tell about that, only
used them on high level languages like python or ruby (more extensively
here, specially in metaprogramming, but that's another history.).  The
other approaches seem cleaner anyway.




2013/8/13 Dick Hollenbeck 

>
> On Aug 13, 2013 12:31 PM, "Lorenzo Marcantonio" <
> l.marcanto...@logossrl.com> wrote:
> >
> > On Tue, Aug 13, 2013 at 05:58:59PM +0200, Tomasz Wlostowski wrote:
> > > Look at the PDF I put on ohwr.org - one can use coroutines, function
> > > pointers or enum+switch for the FSMs, depending on his/her coding
> > > habits. Nothing is forbidden.
> >
> > All clear for me. I was trying to explain to Dick that coroutines were
> > neither the solution for all the problems neither a blasphemy... they
> > have their use (having them more readily available would simplify
> > things, however they are not idiomatic in C/C++)
>
> LOL.
>
> You assume far too much Lorenzo.
>
> My metaphor explicitly assumed the mechanic understood how to use the 5 mm
> wrench.
>
> I've worked with them very extensively.  Familiarity can be assumed in my
> case.  Applicabilty is another topic and no doubt a matter of opinion.
>
>
>
> >
> > --
> > 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
>
> ___
> 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
>
>


-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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

[Dick Hollenbeck]

On Aug 13, 2013 12:31 PM, "Lorenzo Marcantonio" 
wrote:
>
> On Tue, Aug 13, 2013 at 05:58:59PM +0200, Tomasz Wlostowski wrote:
> > Look at the PDF I put on ohwr.org - one can use coroutines, function
> > pointers or enum+switch for the FSMs, depending on his/her coding
> > habits. Nothing is forbidden.
>
> All clear for me. I was trying to explain to Dick that coroutines were
> neither the solution for all the problems neither a blasphemy... they
> have their use (having them more readily available would simplify
> things, however they are not idiomatic in C/C++)

LOL.

You assume far too much Lorenzo.

My metaphor explicitly assumed the mechanic understood how to use the 5 mm
wrench.

I've worked with them very extensively.  Familiarity can be assumed in my
case.  Applicabilty is another topic and no doubt a matter of opinion.



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

[Lorenzo Marcantonio]

On Tue, Aug 13, 2013 at 05:58:59PM +0200, Tomasz Wlostowski wrote:
> Look at the PDF I put on ohwr.org - one can use coroutines, function
> pointers or enum+switch for the FSMs, depending on his/her coding
> habits. Nothing is forbidden.

All clear for me. I was trying to explain to Dick that coroutines were
neither the solution for all the problems neither a blasphemy... they
have their use (having them more readily available would simplify
things, however they are not idiomatic in C/C++)

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

[Tomasz Wlostowski]

On 08/13/2013 06:43 PM, Dick Hollenbeck wrote:

On 08/13/2013 10:58 AM, Tomasz Wlostowski wrote:

On 08/13/2013 05:48 PM, Lorenzo Marcantonio wrote:

On Tue, Aug 13, 2013 at 07:14:05AM -0500, Dick Hollenbeck wrote:

If you ignore the context of application, then this is the same thing as 
guessing that a
mechanic hates his 5mm wrench when he goes to loosen a 11mm nut.


I think it more than using a ratchet instead of an open wrench to loose
the nut. Same result, different way to do it.

Of course a really tight nut may require a long wrench and break the
ratchet... i.e. not necessarily coroutines are the solution.


The solution I proposed does not make coroutines obligatory. If you
don't want to use them in a particular tool, just don't call any
Wait()/Yield() methods. TOOL_INTERACTIVE constructor could have an
additional parameter that prevents creating an unnecessary stack frame
for coroutine-less tools.



As a way to maintain the tool state machine (fed by events), they seem
appropriate to me; of course everyone will propose his own 'best' idea
(heck, no women here:P)


Look at the PDF I put on ohwr.org - one can use coroutines, function
pointers or enum+switch for the FSMs, depending on his/her coding
habits. Nothing is forbidden.

Tom




I had not seen the PDF before I made my initial positive comments.  I had only 
read the
synopsis on the web page.  Maybe I missed it or maybe you added it recently.


I wonder how important building a team around this code is.   I wonder who will 
be on that
team.

Whoever wants to join it :)


Alfons sunk 7 man years into the code before it was useable.  That suggests a 
team may be
necessary.

When do we see the code?


For the P&S router: as soon as it stops crashing and leaking memory.

For the tool system: the proposal code has been in kicad-gal-orson 
branch since my first e-mail (~1.5 weeks). It shows a trivial selection 
tool that uses coroutines and non-wx events.


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

[Dick Hollenbeck]

On 08/13/2013 10:58 AM, Tomasz Wlostowski wrote:
> On 08/13/2013 05:48 PM, Lorenzo Marcantonio wrote:
>> On Tue, Aug 13, 2013 at 07:14:05AM -0500, Dick Hollenbeck wrote:
>>> If you ignore the context of application, then this is the same thing as 
>>> guessing that a
>>> mechanic hates his 5mm wrench when he goes to loosen a 11mm nut.
>>
>> I think it more than using a ratchet instead of an open wrench to loose
>> the nut. Same result, different way to do it.
>>
>> Of course a really tight nut may require a long wrench and break the
>> ratchet... i.e. not necessarily coroutines are the solution.
> 
> The solution I proposed does not make coroutines obligatory. If you 
> don't want to use them in a particular tool, just don't call any 
> Wait()/Yield() methods. TOOL_INTERACTIVE constructor could have an 
> additional parameter that prevents creating an unnecessary stack frame 
> for coroutine-less tools.
> 
>>
>> As a way to maintain the tool state machine (fed by events), they seem
>> appropriate to me; of course everyone will propose his own 'best' idea
>> (heck, no women here:P)
>>
> Look at the PDF I put on ohwr.org - one can use coroutines, function 
> pointers or enum+switch for the FSMs, depending on his/her coding 
> habits. Nothing is forbidden.
> 
> Tom



I had not seen the PDF before I made my initial positive comments.  I had only 
read the
synopsis on the web page.  Maybe I missed it or maybe you added it recently.


I wonder how important building a team around this code is.   I wonder who will 
be on that
team.

Alfons sunk 7 man years into the code before it was useable.  That suggests a 
team may be
necessary.

When do we see the code?

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

[Tomasz Wlostowski]

On 08/13/2013 05:48 PM, Lorenzo Marcantonio wrote:

On Tue, Aug 13, 2013 at 07:14:05AM -0500, Dick Hollenbeck wrote:

If you ignore the context of application, then this is the same thing as 
guessing that a
mechanic hates his 5mm wrench when he goes to loosen a 11mm nut.


I think it more than using a ratchet instead of an open wrench to loose
the nut. Same result, different way to do it.

Of course a really tight nut may require a long wrench and break the
ratchet... i.e. not necessarily coroutines are the solution.


The solution I proposed does not make coroutines obligatory. If you 
don't want to use them in a particular tool, just don't call any 
Wait()/Yield() methods. TOOL_INTERACTIVE constructor could have an 
additional parameter that prevents creating an unnecessary stack frame 
for coroutine-less tools.




As a way to maintain the tool state machine (fed by events), they seem
appropriate to me; of course everyone will propose his own 'best' idea
(heck, no women here:P)

Look at the PDF I put on ohwr.org - one can use coroutines, function 
pointers or enum+switch for the FSMs, depending on his/her coding 
habits. Nothing is forbidden.


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

[Lorenzo Marcantonio]

On Tue, Aug 13, 2013 at 07:14:05AM -0500, Dick Hollenbeck wrote:
> If you ignore the context of application, then this is the same thing as 
> guessing that a
> mechanic hates his 5mm wrench when he goes to loosen a 11mm nut.

I think it more than using a ratchet instead of an open wrench to loose
the nut. Same result, different way to do it.

Of course a really tight nut may require a long wrench and break the
ratchet... i.e. not necessarily coroutines are the solution.

As a way to maintain the tool state machine (fed by events), they seem
appropriate to me; of course everyone will propose his own 'best' idea
(heck, no women here: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] Kicad Tool Framework

[Lorenzo Marcantonio]

On Tue, Aug 13, 2013 at 05:11:52PM +0200, Tomasz Wlostowski wrote:
> With more or less acrobatics one could probably cast everything into
> wx event system.

With sufficient acrobatics you could do kicad in assembly (looking at
the disk platter to toggle the bits, obviously).

Since the event system you described is pretty simple maybe it would be
not too complicate to write one ad-hoc.

> Why programs like Mozilla, Gimp, Blender, Webkit and EDA tools
> (proprietary, such as Altium & free, like gEDA) have custom event
> systems? Maybe this is one of the reasons.

Blender is toolkitless, couldn't have done in any other way:D Gimp uses,
by definition, the GTK one and mozilla/webkit are more or less toolkit
agnostic so they need to do it in their way. Altium probably did that
because it already has some graphical abstraction (IIRC it can use
DirectStuff to accelerate drawing), so probably the reason is similar to
our.

IMHO is better to recode a *simple* system than to try to bend
a *complex* one into shape, if possible.

> I was going to explain the concept of coroutines in tools, but
> Lorenzo was faster (thanks for nice examples!).

Did that stuff I don't remember how many times... every product of ours
with keys and a display substantially work that way. In assembly: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] Kicad Tool Framework

[Lorenzo Marcantonio]

On Tue, Aug 13, 2013 at 07:09:54AM -0500, Dick Hollenbeck wrote:
> > 
> The OS+native windowing system will move the mouse coordinates in the next 
> mouse move event.

Then is not forbidden, it's only difficult to do:D

What I had in mind was an OS where the mouse pointer couldn't moved by
the application...

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

[Tomasz Wlostowski]

On 08/13/2013 03:30 PM, Dick Hollenbeck wrote:

On 08/13/2013 08:03 AM, Dick Hollenbeck wrote:

On 08/13/2013 07:09 AM, Dick Hollenbeck wrote:


I find track laying impossible without mouse warping... there is an
option to disable it. But how could you *emulate* it, if there is no way
to physically move the pointer?



The OS+native windowing system will move the mouse coordinates in the next 
mouse move event.

Your tool, if pushed onto the wxEvtHandler stack, I am thinking should have 
first access
to ALL events, (~captured mouse) so as long as you retain state information the 
next call
to ProcessEvent(), possibly routed to TOOL::OnMouseMove(), you can/could in 
there redraw
the mouse cursor at the new desired location, or not.

See wxEventLoopBase in 
http://docs.wxwidgets.org/trunk/classwx_event_loop_base.html

This class sucks events out of the os queue, and gets first dibs on any events, 
it is the
first recipient of any OS events when it is alive, and dispatching happens from 
here.


If simply residing topmost on the wxEvtHandler stack does not give you enough 
control,
then there is the option to create another wxEventLoopBase temporarily.





Here are some nice graphics and explanation of PushEventHandler:

http://docs.wxwidgets.org/trunk/classwx_window.html#a398c11ab9af7956067a964f560d1978c

It is my thinking that putting this in the wxFrame, by calling its 
PushEventHandler will
give you first dibs on all events.




With more or less acrobatics one could probably cast everything into wx 
event system.
I don't see however why it would be simpler than a small, self-contained 
internal one. Having an example of both is a good idea.


Ours is in tools/selection_tool.cpp.

Why programs like Mozilla, Gimp, Blender, Webkit and EDA tools 
(proprietary, such as Altium & free, like gEDA) have custom event 
systems? Maybe this is one of the reasons.


I was going to explain the concept of coroutines in tools, but Lorenzo 
was faster (thanks for nice examples!).


I need more time to think about wx vs internal events. wxEvtHandler may 
be a good way to go if someone solves all wx platform-dependent quirks 
transparently to the tools.


In the meanwhile it will be better if I focus on the P&S. The router, 
fortunately isn't and will never be wx-dependent :).


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

[Dick Hollenbeck]

On 08/13/2013 08:03 AM, Dick Hollenbeck wrote:
> On 08/13/2013 07:09 AM, Dick Hollenbeck wrote:
>>>
>>> I find track laying impossible without mouse warping... there is an
>>> option to disable it. But how could you *emulate* it, if there is no way
>>> to physically move the pointer? 
>>
>>
>> The OS+native windowing system will move the mouse coordinates in the next 
>> mouse move event.
>>
>> Your tool, if pushed onto the wxEvtHandler stack, I am thinking should have 
>> first access
>> to ALL events, (~captured mouse) so as long as you retain state information 
>> the next call
>> to ProcessEvent(), possibly routed to TOOL::OnMouseMove(), you can/could in 
>> there redraw
>> the mouse cursor at the new desired location, or not.
>>
>> See wxEventLoopBase in 
>> http://docs.wxwidgets.org/trunk/classwx_event_loop_base.html
>>
>> This class sucks events out of the os queue, and gets first dibs on any 
>> events, it is the
>> first recipient of any OS events when it is alive, and dispatching happens 
>> from here.
>>
>>
>> If simply residing topmost on the wxEvtHandler stack does not give you 
>> enough control,
>> then there is the option to create another wxEventLoopBase temporarily.
>>
>>
> 
> 
> Here are some nice graphics and explanation of PushEventHandler:
> 
> http://docs.wxwidgets.org/trunk/classwx_window.html#a398c11ab9af7956067a964f560d1978c
> 
> It is my thinking that putting this in the wxFrame, by calling its 
> PushEventHandler will
> give you first dibs on all events. 



That was a guess.  Probably time to stop guessing and write some test code, and 
examine
the source.



>If you follow the wEvent::Skip() protocol, and not
> process events not pertinent to you, and I think this means knowing the 
> client window area
> coord and checking mouse events against that box, then any wxEvent can still 
> find its way
> to its normal destination outside the tool.
> 
> 


___
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

[Dick Hollenbeck]

On 08/13/2013 07:09 AM, Dick Hollenbeck wrote:
>>
>> I find track laying impossible without mouse warping... there is an
>> option to disable it. But how could you *emulate* it, if there is no way
>> to physically move the pointer? 
> 
> 
> The OS+native windowing system will move the mouse coordinates in the next 
> mouse move event.
> 
> Your tool, if pushed onto the wxEvtHandler stack, I am thinking should have 
> first access
> to ALL events, (~captured mouse) so as long as you retain state information 
> the next call
> to ProcessEvent(), possibly routed to TOOL::OnMouseMove(), you can/could in 
> there redraw
> the mouse cursor at the new desired location, or not.
> 
> See wxEventLoopBase in 
> http://docs.wxwidgets.org/trunk/classwx_event_loop_base.html
> 
> This class sucks events out of the os queue, and gets first dibs on any 
> events, it is the
> first recipient of any OS events when it is alive, and dispatching happens 
> from here.
> 
> 
> If simply residing topmost on the wxEvtHandler stack does not give you enough 
> control,
> then there is the option to create another wxEventLoopBase temporarily.
> 
> 


Here are some nice graphics and explanation of PushEventHandler:

http://docs.wxwidgets.org/trunk/classwx_window.html#a398c11ab9af7956067a964f560d1978c

It is my thinking that putting this in the wxFrame, by calling its 
PushEventHandler will
give you first dibs on all events.  If you follow the wEvent::Skip() protocol, 
and not
process events not pertinent to you, and I think this means knowing the client 
window area
coord and checking mouse events against that box, then any wxEvent can still 
find its way
to its normal destination outside the tool.



___
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

[Dick Hollenbeck]

On 08/13/2013 02:00 AM, Lorenzo Marcantonio wrote:
> On Tue, Aug 13, 2013 at 12:54:10AM -0500, Dick Hollenbeck wrote:
> 
> Huge mail, but very interesting...
> 
>> 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.
> 
> More or less the reason for which I doubted it works... coroutines in
> this case are used to suspend/restart the process to avoid a state
> variable in a state machine. The main issue here is what to do when a
> coroutine need to exit... *if* these are created in the right
> environment you could just dispose of the stack and then return to the
> caller (unwinding the last frame would be tricky). There is a whole
> theory of continuation-style programming, most of that can't be applied
> to C++, since it requires a branched stack (IIRC that's the reason for
> the call limitation in python generators)
> 
> I think that if:
> - Coroutine are created with a 'neutral' stack (i.e. nothing living
>   after their return)
> - Every event dispatch to the coroutine until a yield or terminate
>   occur
> 
> It should work without any big trouble (maybe some limitation in what
> can be done in the coroutine, but I don't think a lot).
> 
>> 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.
> 
> Well, that's not very different using a coroutine... in fact the old
> windows 3.1 application ran as huge coroutines from the OS yielding on
> GetMessage (and few other functions). MacOS class was cooperative too,
> AFAIK.
> 
> Paraphrasing: "the goal of the tool coroutine handler should be to
> *yield* as fast as it can, since it is being called on the wx event
> handler thread". The key here is that it yields, not return, so it keeps
> the whole processing state. All your consideration about a competing
> tool thread are correct *but* we have *no thread safety whatsoever* in
> kicad so it will be a huge work and source of race conditions.
> 
> Also there should be a theorem somewhere stating that all what you can
> do with a state machine can be done with a coroutine (and the converse);
> it's only a programming convenience (just like you could program kicad
> on a Turing machine, yeah:D)
> 
> A more realistic stance: what would have to do the tool code that would
> need a separate thread? Since it need to provide feedback, he would have
> to wait for that thread anyway (making the fork not useful...). IMHO
> most performance problems in pcbnew can be solved with better data
> structures (like spatial indices as discussed).
> 
>> 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 don't feel the 'tool change' is a transition... otherwise even moving
> the cursor would be:D is more like swapping one state machine with
> another and aborting the previous one. Your sub-state machine would be
> the tool state machine, I agree with that. Track lying use case
> (extremely simplified)
> 
> S1: pick the start point
> S2: drag trace
> 
> With a pure state machine that would be like:
> 
> S1/mouse move -> update cursor -> S1
> S1/click -> validate start position, pin start -> S2
> S2/mouse move -> update rubber track -> S2
> S2/click -> validate rubber track, pin start -> S2
> S2/end track -> validate rubber track -> S1
> 
> With a coroutine it would be like (heavily pseudocoded, I'm focusing on
> the coroutine view *not* on how event are dispatched in it). Please
> correct me if I misunderstood something here
> 
> forever {
> while (!start_pinned) {
> event = yield();
> switch (event) { // or some clever dispatch
> case click:
> pin_start();
> 
> case move:
> update_cursor;
> }
> }
> 
> while (!track_done) {
> event = yield;
> switch (event) {
> case click:
> validate_track();
> pin_start();
> 
> case move:
> update_rubber_track
> 
> case end_track

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

> 
> I find track laying impossible without mouse warping... there is an
> option to disable it. But how could you *emulate* it, if there is no way
> to physically move the pointer? 


The OS+native windowing system will move the mouse coordinates in the next 
mouse move event.

Your tool, if pushed onto the wxEvtHandler stack, I am thinking should have 
first access
to ALL events, (~captured mouse) so as long as you retain state information the 
next call
to ProcessEvent(), possibly routed to TOOL::OnMouseMove(), you can/could in 
there redraw
the mouse cursor at the new desired location, or not.

See wxEventLoopBase in 
http://docs.wxwidgets.org/trunk/classwx_event_loop_base.html

This class sucks events out of the os queue, and gets first dibs on any events, 
it is the
first recipient of any OS events when it is alive, and dispatching happens from 
here.


If simply residing topmost on the wxEvtHandler stack does not give you enough 
control,
then there is the option to create another wxEventLoopBase temporarily.



___
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

[Lorenzo Marcantonio]

On Tue, Aug 13, 2013 at 12:54:10AM -0500, Dick Hollenbeck wrote:

Huge mail, but very interesting...

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

More or less the reason for which I doubted it works... coroutines in
this case are used to suspend/restart the process to avoid a state
variable in a state machine. The main issue here is what to do when a
coroutine need to exit... *if* these are created in the right
environment you could just dispose of the stack and then return to the
caller (unwinding the last frame would be tricky). There is a whole
theory of continuation-style programming, most of that can't be applied
to C++, since it requires a branched stack (IIRC that's the reason for
the call limitation in python generators)

I think that if:
- Coroutine are created with a 'neutral' stack (i.e. nothing living
  after their return)
- Every event dispatch to the coroutine until a yield or terminate
  occur

It should work without any big trouble (maybe some limitation in what
can be done in the coroutine, but I don't think a lot).

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

Well, that's not very different using a coroutine... in fact the old
windows 3.1 application ran as huge coroutines from the OS yielding on
GetMessage (and few other functions). MacOS class was cooperative too,
AFAIK.

Paraphrasing: "the goal of the tool coroutine handler should be to
*yield* as fast as it can, since it is being called on the wx event
handler thread". The key here is that it yields, not return, so it keeps
the whole processing state. All your consideration about a competing
tool thread are correct *but* we have *no thread safety whatsoever* in
kicad so it will be a huge work and source of race conditions.

Also there should be a theorem somewhere stating that all what you can
do with a state machine can be done with a coroutine (and the converse);
it's only a programming convenience (just like you could program kicad
on a Turing machine, yeah:D)

A more realistic stance: what would have to do the tool code that would
need a separate thread? Since it need to provide feedback, he would have
to wait for that thread anyway (making the fork not useful...). IMHO
most performance problems in pcbnew can be solved with better data
structures (like spatial indices as discussed).

> 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 don't feel the 'tool change' is a transition... otherwise even moving
the cursor would be:D is more like swapping one state machine with
another and aborting the previous one. Your sub-state machine would be
the tool state machine, I agree with that. Track lying use case
(extremely simplified)

S1: pick the start point
S2: drag trace

With a pure state machine that would be like:

S1/mouse move -> update cursor -> S1
S1/click -> validate start position, pin start -> S2
S2/mouse move -> update rubber track -> S2
S2/click -> validate rubber track, pin start -> S2
S2/end track -> validate rubber track -> S1

With a coroutine it would be like (heavily pseudocoded, I'm focusing on
the coroutine view *not* on how event are dispatched in it). Please
correct me if I misunderstood something here

forever {
while (!start_pinned) {
event = yield();
switch (event) { // or some clever dispatch
case click:
pin_start();

case move:
update_cursor;
}
}

while (!track_done) {
event = yield;
switch (event) {
case click:
validate_track();
pin_start();

case move:
update_rubber_track

case end_track:
validate_track();
track_done = true;
}
}
}

The coroutine better show the tool code flow, the state machine is more
'elegant' in a formal way... I think it all go to personal preference.
In fact in tail-recursive languages FSM

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

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 c

Re: [Kicad-developers] Kicad Tool Framework

[Lorenzo Marcantonio]

On Mon, Aug 12, 2013 at 08:29:40PM +0200, Tomasz Wlostowski wrote:
> 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

Same here :D I'm giving some suggestion but I have no idea if can be
made working in wx... but maybe these could click an idea for someone.

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

Are you handling states with method pointers? It should be possible to
handle it with a 'stub' ProcessEvent which just call the 'current
state'. At least that's the way I do FSM (instead of coding and
switching on the state, the state variable contains the function for
handling it). Put it in the root of your handlers and forget it exists.

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

Technically UI commands should be classes, if you're going the OO way.
A typical trick is using singleton addresses as ids but I don't know if
it's doable in wx. C++ lack symbols:P

> nearby objects/grid and. It could be done on event level, by
> adjusting cursor coordinates accordingly.

Well maybe some tool need to work in screen space too. And converting
should be easy so I don't see that as a fundamental flaw. The important
thing is the roundtrip is possible.

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

Utility functions to handle this? Otherwise: can a wx handler *modify*
the event? then you could add 'filters' in the stack to handle this and
the previous point. But that would be stretching the wx architecture
IMHO.

> - No idea how wx event stack will play with coroutines:

I feel is not a good idea keeping a coroutine in an event call stack...
study of wx code is needed to ensure compability

> - Wanted to avoid translating between VECTOR2<>/BOX2<> and
> wxRect/wxPoint in the tools.

Can't we subclass the event to contain them? so it could even keep the
board/screen coordinates and stuff... or it's a closed class passed by
value? Ideally that would be populated in the 'first' filter which
receives the event.

> - (a less technical one) I'm slightly biased against wx, so I didn't
> want to depend too much on it:

A lot of people thinks that way :D but in a way or the other I couldn't
find a toolkit that simply works...

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

I *still* can't find the source of the dragging bug in eeschema. Must be
something like that, some critical ordering issue... 

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

I find track laying impossible without mouse warping... there is an
option to disable it. But how could you *emulate* it, if there is no way
to physically move the pointer? (of course pcbnew would greatly suck
with a tablet, if only for the required precision)

>   * 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 the wxWidgets project and its
> packages in different distros.

gtk printing is not *too* better... the only program I ever seen which
consistently printed correctly generate postscript on their own. I think
it's due to the impedance mismatch between the screen model and the
printing model (everyone want to do it with the same routines since
MFC... but it's fundamentally flawed as approach...)

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

[Lorenzo Marcantonio]

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] Kicad Tool Framework

[Wayne Stambaugh]

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, P&S 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

Re: [Kicad-developers] Kicad Tool Framework

[Tomasz Wlostowski]

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, P&S 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 

Re: [Kicad-developers] Kicad Tool Framework

[Tomasz Wlostowski]

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] Kicad Tool Framework

[Tomasz Wlostowski]

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

[Lorenzo Marcantonio]

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

> boost::context + a small wrapper class.

In short, setjmp/longjmp wrapped in a class :D

OK thanks

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

[Lorenzo Marcantonio]

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

[Wayne Stambaugh]

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

[Lorenzo Marcantonio]

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

[Lorenzo Marcantonio]

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] Kicad Tool Framework

[Brian Sidebotham]

On 12 August 2013 16:41, 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...
>
> (next step for world domination would be continuations:D)
>
>
I have done co-routines using "ucontext" available on both Linux and (with
a little work) Windows. I saw an article on the CodeProject (
http://www.codeproject.com/Articles/4225/Unix-ucontext_t-Operations-on-Windows-Platforms
)
which resulted in me implementing this. It works rather well.

I only implemented it like that because I had no choice though. I don't
particularly like co-routines.

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

[Tomasz Wlostowski]

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

[Lorenzo Marcantonio]

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

[Lorenzo Marcantonio]

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

(next step for world domination would be continuations:D)

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

[Dick Hollenbeck]

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

[Tomasz Wlostowski]

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;

DELEGATE0 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

[Dick Hollenbeck]

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

[Dick Hollenbeck]

On 08/12/2013 07:00 AM, Tomasz Wlostowski wrote:
> 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...



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.

They use it to entirely run the largest power plant in the USA.  And about 10 
additional
smaller ones.

And anywhere else you might find PLCs in countless industries.

We recently ported it to the beaglebone, and we're doing some I/O boards for the
beaglebone now.


How important is realtime collaboration, vs. git repo collaboration for an EDA? 
 Or is
that simply a concurrent skype conversation or a form of a meeting using show 
and tell?

Like I said, I know how to do that.  Same old story, there is know how but no 
motive.


Dick





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

[Tomasz Wlostowski]

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

[Brian Sidebotham]

On 12 August 2013 11:00, Tomasz Wlostowski wrote:

> 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 P&S 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
>
>
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

[Tomasz Wlostowski]

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 P&S 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

[Tomasz Wlostowski]

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

[Tomasz Wlostowski]

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

[Cirilo Bernardo]

- Original Message -

> From: Dick Hollenbeck 
> To: kicad-developers@lists.launchpad.net
> Cc: 
> Sent: Monday, August 12, 2013 2:26 AM
> Subject: Re: [Kicad-developers] Kicad Tool Framework
> 
> On 08/11/2013 01:44 AM, Lorenzo Marcantonio wrote:
>>  On Sat, Aug 10, 2013 at 04:34:03PM -0500, Dick Hollenbeck wrote:
>>>  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.
>> 
>>  Strange... what has freerouter of bad other than is java-slowness and
>>  foggy display?
> 
> 
> Under freerouter, I saved to a dsn file after 5 hours of push and shove 
> routing, 
> a
> partially complete design, and went to lunch figuratively, shutdown 
> freerouter, 
> when I
> came back to load back in the dsn file, it could not load its own file.  This 
> is 
> the file
> that *it* wrote to disk, presumably with the commitment that it could reload 
> it 
> later.  My
> mistake was in believing that.  I could have concurrently saved to *.ses file 
> also, at
> least that way my intermediate work progress could have come back through 
> pcbnew, then
> back to freerouter. *.ses -> pcbnew -> *.dsn -> freerouter.
> 
> For years I have had numerous conversations with Alfons, mostly always the 
> same 
> two questions:
> 
> a) why he does not go open source?
> 
> b) why do you not report line numbers when you puke loading a file?  The 
> procedure has
> been "send him the file in personal email, and he walks through the code 
> under a debugger
> to find the problem".  This is now rubbish since he has retired.  So you 
> are stuck
> guessing.  This is guessing:  load the *.dsn file into a text editor, cut 
> huge 
> portions
> out, try reloading again, when it finally loads, add back in the content in 
> smaller
> increments until you find the problem.  Then doctor it, load it and proceed.
> 
> 
> So when I wrote my posting about freerouter, I was at that point of losing 5 
> hours of work.
> 
> Fortunately in this case just this morning before church, I ran the 
> freerouter 
> written dsn
> file through my s-expression beautifier, which you build under our 
> /tools dir by
> 
> 
> $ make property_tree
> 
> Then tried beautifying Alfons' file:
> 
> $ tools/property_tree a.dsn > /tmp/pray_hard.dsn
> 
> I got lucky.  /tmp/pray_hard.dsn loaded.  (Remember, I was on my way to 
> church.)
> 
> In my tech support thread on his forum, I finally asked what I hope is a 
> profoundly
> important question to his many man years of excellent work.  The question is: 
> "now that
> you are retired, is it your intention to let freerouter simply fade into 
> retirement also?
> Why not take pride in your retirement and let freerouter live on so you can 
> at 
> least take
> a sense of pride in this extraordinary work?"
> 


Wow ... I always considered freerouter a serious liability since it was not 
open, but I was hoping it wouldn't become a problem so soon.  It really would 
be a shame if Alfons simply lets it die; it's not only KiCAD people using it.  
As for push/shove - I see that as a basic and essential tool and the biggest 
bit missing from KiCAD - I can't wait for the work being done by the folks at 
CERN.

- Cirilo


___
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

[Lorenzo Marcantonio]

On Sun, Aug 11, 2013 at 11:52:48AM -0500, Dick Hollenbeck wrote:
> I think it is positive for the project that you and I agree with Tom on this 
> design
> concept.  We are approaching a unified vision for the project moving forward. 
>  This
> architecture also allows folks to contribute new tools and do so in a less 
> disruptive and
> modular fashion.

It's not extremely different than the one discussed for better
scriptability. Essentially a controller/model split, as we said. Also
IIRC the current tool code is not *too* intermingled with model code, so
it should be too traumatic:D

> But I think Tom sees it as an opportunity to transport code into the new 
> architecture.
> The act of transporting code is a healthy endeavour because it lets you 
> scrutinize and
> revitalize and quality enhance.  It is like pouring a dirty liquid through a 
> filter into a
> new container.

Usually when I refactor, I revise. So, yes, that would be the idea. But,
for example, I wouldn't throw away all the code for deciding what are
the things under the cursor (that would be foolish and a can of bugs...)

> With a #ifdef we can keep the new code out of the stock build binaries for 
> awhile.
> Co-mingling the source is possible, some minor drawbacks no doubt, but how 
> bad are they?

I fear a huge transitional mess.

Depending on the timeline for the GAL code, maybe is not convenient to
port the current pcbnew to the new tool and then merge in the GAL. I.e.
if GAL is near to the 'stable' point, maybe it would be a good idea to
freeze the tools in the current version and write them directly in the
GAL branch.

Otherwise could be useful to implement the tool infrastructure in the
current pcbnew and then merge in the GAL when is more mature (this only
if the new tools don't depend on GAL features...)

I have no idea on what would be the best way to proceed... like you in
this period I need to make more boards than developing kicad. However
I think that a feature freeze for pcbnew at the moment would be doable
(or is someone making huge new stuff for it?)

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

[Lorenzo Marcantonio]

On Sun, Aug 11, 2013 at 11:26:51AM -0500, Dick Hollenbeck wrote:
> Under freerouter, I saved to a dsn file after 5 hours of push and shove 
> routing, a
> partially complete design, and went to lunch figuratively, shutdown 
> freerouter, when I
> came back to load back in the dsn file, it could not load its own file.  This 
> is the file
> that *it* wrote to disk, presumably with the commitment that it could reload 
> it later.  My

That's a big ouch. Sort of the behaviour of excel with quick save
enabled :P

> I got lucky.  /tmp/pray_hard.dsn loaded.  (Remember, I was on my way to 
> church.)

The file name was the key:D seriously, it only was a formatting issue?
I don't believe it's parser is so crappy...

> Of course I am nobody to him, and in retirement, freerouter may not be 
> important to him
> either.

Conclusion: freerouter became 'unsupported software'

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

[Lorenzo Marcantonio]

On Sun, Aug 11, 2013 at 11:39:26AM -0500, Dick Hollenbeck wrote:
> Data can reside on the moon if you have accessors that hide that fact.  The 
> interface is
> the important thing, since it is what is propagated through the client code.

Well, that's only partially true, it only hold for 1-to-1 relationships;
example: one board, two views. When grid is stored in the board, you
change the grid and both view follows.  When the grid is on the view,
each view has its grid and you simply *can't* have the grid from the
board only (which one would you get?); also the grid couldn't be
persisted, if the file represents the board.

> In the case of the grid origin *data*, it had to be moved to the BOARD 
> because PLUGINs
> have no access to the frame, only to the BOARD, and the grid origin wanted to 
> be saved to
> disk as part of the board file.  And BOARDs should not know about frames, so 
> no accessor
> magic in the BOARD was possible.

These are extremely good reasons for this model. Of course the current
model has the grid tied to the board; a perfectly valid decision
would have been to tie the grid to the view (and maybe save it as user
preference). Of course, as a use case, that would be not desiderable
(especially when exchanging files:D).

Coming from a heavy database shop (stock trading in COBOL, DB2 and IMS
:D) the model drives the implementation (but the model need to satisfy
specifications). And, by the way, IMS is used because hierarchical is
faster than relational in fixed use cases:P

So, the grid can't stay on the moon, at least not until you have
specified the moon responsibilities and ensured that there is one and
only one moon for each board:D; after that, as you correctly said,
it's only a navigation thing (what you call interfaces).

> But again, the grid origin accessor is the important thing, and the code that 
> uses it can
> use it just fine since it is in the frame.

I don't especially like these 'convenience accessor' that delegates to
related objects (i.e. if it's in the board you shouldn't call the frame
only because the frame can access them indirectly: get the board and ask
to it). However, I agree that they are... convenient. It depends how
much you like pointer chasing.

> Near term, I would vote against multiple BOARD views and how that would 
> affect the pcbnew
> code.

That was just an example for the implications, I wasn't actively
promoting multiple views. Altough the genesis blow-up panels are pretty
cool in the screen shots, 90% of their usage would be fine with a 'list
of bookmark', anyway.

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

[Dick Hollenbeck]

> 
> That's independently of the GAL, I think some/most of this stuff would
> be useful even for 'stock' kicad, 


Lorenzo,

I think it is positive for the project that you and I agree with Tom on this 
design
concept.  We are approaching a unified vision for the project moving forward.  
This
architecture also allows folks to contribute new tools and do so in a less 
disruptive and
modular fashion.

So if tools are the destination of code, then what are the sources of code for 
those
destination buckets?

Basically:  old code and new code.

You like it so much that you want to move old code into tools for 'stock" 
KiCad.  That is
a solid endorsement of the idea.

But I think Tom sees it as an opportunity to transport code into the new 
architecture.
The act of transporting code is a healthy endeavour because it lets you 
scrutinize and
revitalize and quality enhance.  It is like pouring a dirty liquid through a 
filter into a
new container.

So I hear Tom saying that the new containers could define the new GAL pcbnew.

One has to ask then:

"if the the GAL display code is working well enough, why don't we merge it in 
and start
writing tools?"  Clearly the P&S router is not the only thing that needs to be 
done.

With a #ifdef we can keep the new code out of the stock build binaries for 
awhile.
Co-mingling the source is possible, some minor drawbacks no doubt, but how bad 
are they?


Dick



> 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...). Well,
> there *was* but it was deprecated together with color index mode and
> other 'non-photorealistic' stuff.
> 


___
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

[Dick Hollenbeck]

On 08/10/2013 01:22 PM, Lorenzo Marcantonio wrote:
> On Sat, Aug 10, 2013 at 09:53:40AM -0500, Dick Hollenbeck wrote:
> 
>> After more thought, and a long walk, I like it even more.  I guess you are 
>> talking putting
>> full featured board actions or procedural handlers in the tool also?  This 
>> opens up the
>> architecture quite a bit to extensions and is an outstanding idea Tom.
> 
> I only have one thing to say: please take care to not mix the model and
> the view/controller... sanity check: could the same operation be done
> from the scripting interface without calling the tool UI stuff? if not,
> some refactoring could be useful.
> 
>> I still think the frame is the best place for that data, if it cross-tool, 
>> else of course
>> in the tool.  For the data in the frame, maybe try and put the accessors in 
>> the base class
>> tool.  And declare that class a friend of the frame.   This at least keeps 
>> the interface
>> to the data clean, the tools really don't have to know where such frame 
>> resident data is.
> 
> 100% agree on that. 'General' display/control stuff IMHO should reside
> in the frame, unless it's some board-related preference: what is where
> is debatable and subject to a design decision; example: the aux origin
> is undeniably on the board, but should, say, the grid be tied to the
> board or to the view?

Data can reside on the moon if you have accessors that hide that fact.  The 
interface is
the important thing, since it is what is propagated through the client code.

In the case of the grid origin *data*, it had to be moved to the BOARD because 
PLUGINs
have no access to the frame, only to the BOARD, and the grid origin wanted to 
be saved to
disk as part of the board file.  And BOARDs should not know about frames, so no 
accessor
magic in the BOARD was possible.

But again, the grid origin accessor is the important thing, and the code that 
uses it can
use it just fine since it is in the frame.


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

I like full screen views, so I am less than neutral about multiple views for a 
BOARD.

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.

Near term, I would vote against multiple BOARD views and how that would affect 
the pcbnew
code.


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

[Dick Hollenbeck]

On 08/11/2013 01:44 AM, Lorenzo Marcantonio wrote:
> On Sat, Aug 10, 2013 at 04:34:03PM -0500, Dick Hollenbeck wrote:
>> 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.
> 
> Strange... what has freerouter of bad other than is java-slowness and
> foggy display?


Under freerouter, I saved to a dsn file after 5 hours of push and shove 
routing, a
partially complete design, and went to lunch figuratively, shutdown freerouter, 
when I
came back to load back in the dsn file, it could not load its own file.  This 
is the file
that *it* wrote to disk, presumably with the commitment that it could reload it 
later.  My
mistake was in believing that.  I could have concurrently saved to *.ses file 
also, at
least that way my intermediate work progress could have come back through 
pcbnew, then
back to freerouter. *.ses -> pcbnew -> *.dsn -> freerouter.

For years I have had numerous conversations with Alfons, mostly always the same 
two questions:

a) why he does not go open source?

b) why do you not report line numbers when you puke loading a file?  The 
procedure has
been "send him the file in personal email, and he walks through the code under 
a debugger
to find the problem".  This is now rubbish since he has retired.  So you are 
stuck
guessing.  This is guessing:  load the *.dsn file into a text editor, cut huge 
portions
out, try reloading again, when it finally loads, add back in the content in 
smaller
increments until you find the problem.  Then doctor it, load it and proceed.


So when I wrote my posting about freerouter, I was at that point of losing 5 
hours of work.

Fortunately in this case just this morning before church, I ran the freerouter 
written dsn
file through my s-expression beautifier, which you build under our 
/tools dir by


$ make property_tree

Then tried beautifying Alfons' file:

$ tools/property_tree a.dsn > /tmp/pray_hard.dsn

I got lucky.  /tmp/pray_hard.dsn loaded.  (Remember, I was on my way to church.)

In my tech support thread on his forum, I finally asked what I hope is a 
profoundly
important question to his many man years of excellent work.  The question is: 
"now that
you are retired, is it your intention to let freerouter simply fade into 
retirement also?
 Why not take pride in your retirement and let freerouter live on so you can at 
least take
a sense of pride in this extraordinary work?"

Of course I am nobody to him, and in retirement, freerouter may not be 
important to him
either.

That leaves us vulnerable.  Without a push and shove option to route, I would 
simply bite
the bullet and go buy a linux based EDA package, and quit with KiCad.  P&S is 
that
important to me.

Dick



> 
> OTOH I agree, the P&S would be very useful (100 pin packages, only two
> signal layers, 0,2mm clearance and a way-too-small board... I've ripped
> up the thing almost 6 times now...)
> 



___
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

[Lorenzo Marcantonio]

On Sat, Aug 10, 2013 at 04:34:03PM -0500, Dick Hollenbeck wrote:
> 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.

Strange... what has freerouter of bad other than is java-slowness and
foggy display?

OTOH I agree, the P&S would be very useful (100 pin packages, only two
signal layers, 0,2mm clearance and a way-too-small board... I've ripped
up the thing almost 6 times now...)

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

[Dick Hollenbeck]

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,

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

[Dick Hollenbeck]

On 08/10/2013 09:28 AM, 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
>> 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.
> 
> 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). 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? 


wx has a stack of event handlers built into each event context.
So what I describe is already written for you in wx, except the tests of the 
events, and
that is either a switch or else ifs.

I think this entire infrastructure in b) probably came from wx, its just that 
it lurked in
my subconscious for a few months until I wrote that.

The tools could be SWIGed, and this partitions the python function space into 
logical
categories.  That is, assuming you put the C++ handlers which to the actual 
work in the
tools, maybe without wxEvent parameters, but with expanded C++ arguments so 
python does
not have to fabricate an event to call them.



The second scenario rules out inheritance but
> I don't think we ever need that. As an aside object pickers could be
> handled as mixins or something similar...
> 
> Another simpler idea is to install fallback handlers, i.e.  everything
> that's not handled by the current tool is subject to 'default
> processing'. If this default processing is static in code or driven by
> some event processor depends on the degree of modularity required (think
> about 'event sieves', everything not handled pass down thru a 'chain' of
> handlers). IIRC gtk works that way.
> 
>> 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.  :)
> 
> 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
> 
>> 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...). Well,
> there *was* but it was deprecated together with color index mode and
> other 'non-photorealistic' stuff.
> 


___
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

[Lorenzo Marcantonio]

On Sat, Aug 10, 2013 at 09:53:40AM -0500, Dick Hollenbeck wrote:

> After more thought, and a long walk, I like it even more.  I guess you are 
> talking putting
> full featured board actions or procedural handlers in the tool also?  This 
> opens up the
> architecture quite a bit to extensions and is an outstanding idea Tom.

I only have one thing to say: please take care to not mix the model and
the view/controller... sanity check: could the same operation be done
from the scripting interface without calling the tool UI stuff? if not,
some refactoring could be useful.

> I still think the frame is the best place for that data, if it cross-tool, 
> else of course
> in the tool.  For the data in the frame, maybe try and put the accessors in 
> the base class
> tool.  And declare that class a friend of the frame.   This at least keeps 
> the interface
> to the data clean, the tools really don't have to know where such frame 
> resident data is.

100% agree on that. 'General' display/control stuff IMHO should reside
in the frame, unless it's some board-related preference: what is where
is debatable and subject to a design decision; example: the aux origin
is undeniably on the board, but should, say, the grid be tied to the
board or to the view?

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)

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

[Dick Hollenbeck]

On 08/10/2013 08:27 AM, 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.
> 
> 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, 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.
> 
> 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.  :)

After more thought, and a long walk, I like it even more.  I guess you are 
talking putting
full featured board actions or procedural handlers in the tool also?  This 
opens up the
architecture quite a bit to extensions and is an outstanding idea Tom.

The question of data accessors comes up though, and where is the data kept 
pertinent to
the display, stuff which might be shared across tools yet is not related to the 
BOARD.

I still think the frame is the best place for that data, if it cross-tool, else 
of course
in the tool.  For the data in the frame, maybe try and put the accessors in the 
base class
tool.  And declare that class a friend of the frame.   This at least keeps the 
interface
to the data clean, the tools really don't have to know where such frame 
resident data is.

Other than that sticky spot, I think the benefits of bundling the know how with 
the state
machine is a very major positive architectural change.

Well done Tom.

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

[Lorenzo Marcantonio]

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

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). 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? The second scenario rules out inheritance but
I don't think we ever need that. As an aside object pickers could be
handled as mixins or something similar...

Another simpler idea is to install fallback handlers, i.e.  everything
that's not handled by the current tool is subject to 'default
processing'. If this default processing is static in code or driven by
some event processor depends on the degree of modularity required (think
about 'event sieves', everything not handled pass down thru a 'chain' of
handlers). IIRC gtk works that way.

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

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

> 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...). Well,
there *was* but it was deprecated together with color index mode and
other 'non-photorealistic' stuff.

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

[Dick Hollenbeck]

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.

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

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

Exciting stuff,

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

[Dick Hollenbeck]

On 08/09/2013 10:15 PM, Dick Hollenbeck wrote:
> On 08/02/2013 12:10 PM, Tomasz Wlostowski wrote:
>> Hello,
>>
>> Thanks to Orson, Camille, Vesa and others we now have the cool and 
>> lightning-fast GAL-driven graphics view in pcbnew. Now it's time to make 
>> it do some real work, that means editing operations.
>>
>> Since the GAL does not allow XOR rendering, some significant refactoring 
>> of the editing tools' code will have to happen at some point. I took it 
>> as an opportunity to propose a tiny library/framework/abstraction (pick 
>> your favorite name) for the editing tools. Its main goals are:
>> - separate tool = separate class, contrary to the current state where 
>> all tools reside in PCB_EDIT_FRAME event handlers. This would allow for
>> writing new tools without touching the frame code (which is quite 
>> complex) and abstract tools into plugins.
>> - no "asynchronous" drawing. If a tool wants to draw something, it adds 
>> it to a VIEW, and the VIEW makes sure it's displayed in correct order 
>> and without damaging other parts of screen.
>> - eliminate static/global tool states.
>> - independence from the GUI toolkit and its quirks on different systems. 
>> Tools get the events in world space that are already adjusted to what's 
>> going on with the view (panning, scrolling, zoom, etc.)
>> - tools accessible from scripts
>>
>> I wrote a slightly longer technical description and uploaded it to the 
>> CERN project Wiki: http://www.ohwr.org/projects/cern-kicad/wiki/Kicad-tool.
>>
>> 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
> 
> Tom,
> 
> You deserve better than this buddy.  Anyone give you feedback yet?
> 
> I will try to this weekend.  Please don't take the silence as anyone thinking 
> your work is
> not exceedingly important.


Wayne, JP, anyone else, please give this document a look over, or live with the 
choices
Tom makes.   (Neither path is likely to be bad.)

Thanks,

Dick


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

[Dick Hollenbeck]

On 08/02/2013 12:10 PM, Tomasz Wlostowski wrote:
> Hello,
> 
> Thanks to Orson, Camille, Vesa and others we now have the cool and 
> lightning-fast GAL-driven graphics view in pcbnew. Now it's time to make 
> it do some real work, that means editing operations.
> 
> Since the GAL does not allow XOR rendering, some significant refactoring 
> of the editing tools' code will have to happen at some point. I took it 
> as an opportunity to propose a tiny library/framework/abstraction (pick 
> your favorite name) for the editing tools. Its main goals are:
> - separate tool = separate class, contrary to the current state where 
> all tools reside in PCB_EDIT_FRAME event handlers. This would allow for
> writing new tools without touching the frame code (which is quite 
> complex) and abstract tools into plugins.
> - no "asynchronous" drawing. If a tool wants to draw something, it adds 
> it to a VIEW, and the VIEW makes sure it's displayed in correct order 
> and without damaging other parts of screen.
> - eliminate static/global tool states.
> - independence from the GUI toolkit and its quirks on different systems. 
> Tools get the events in world space that are already adjusted to what's 
> going on with the view (panning, scrolling, zoom, etc.)
> - tools accessible from scripts
> 
> I wrote a slightly longer technical description and uploaded it to the 
> CERN project Wiki: http://www.ohwr.org/projects/cern-kicad/wiki/Kicad-tool.
> 
> 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

Tom,

You deserve better than this buddy.  Anyone give you feedback yet?

I will try to this weekend.  Please don't take the silence as anyone thinking 
your work is
not exceedingly important.


Thanks,


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