[Kicad-developers] Printing and Ledger paper type.

2012-02-27 Thread Alexander Zakamaldin 
Let me try.

The paper sheet is a piece of rectangular paper. Its shape is completely
described with two parameters - size_X and size_Y. Because it has four
sides, its orientation is completely described with four parameters -
R0 (rotation 0), R90, R180 and R270. With this in mind, we can make the 
following
assumptions, some kind of postulates.

1. We choose the initial orientation, for example size_X < size_Y and this is 
R0.
This is the commonly used assumption.
2. We make no distinction in what the size is smaller or larger and we make no
distinction in the orientation.

With the first assumption at any time of computation  we can estimate the real
logical orientation. Just with the help of size_X and size_Y comparison.
With the second assumption we have to define at least two types of paper
for the same size_X and size_Y (for example USLedger 17x11 and USTabloid 11x17).
It should be mentioned, that logical printout computations (affine 
transformations) are
very complex. They are completely rely on the first assumption. And when we try
to mix this assumptions, we only confuses this computations.

By the way, these arguments do not apply to the current implementation of Kicad
testing branch. These assumptions are significant if we are going to implement
page orientation explicitly.

Alexander.

27 февраля 2012, 22:52 от Dick Hollenbeck :
> On 02/27/2012 02:50 AM, Alexander Zakamaldin wrote:
> > Yes, sure. I wrote about US Ledger paper size.
> > It should be mentioned, the US Ledger's size confuses not only me, but
> Gnomeprint job also.
> 
> Please explain in detail what are the symptoms of the problem.  That is how do
> you know it
> is not working.
> 
> 
> 
> 
> > So, what is the best choice to do?
> > 1. Assume the US Ledger is 11x17 inches size, just the same as 'Inkscape'
> project is doing.
> > 2. Replace US Ledger with US Tabloid paper which is 11x17in exactly. The
> same as 'GIMP'
> > project is doing.
> >
> > Alexander.
> >
> >
> > 27 февраля 2012, 09:38 от Dick Hollenbeck :
> >> On 02/26/2012 06:44 AM, Alexander Zakamaldin wrote:
> >>> Hi.
> >>>
> >>> I am working on printing issues for gtk based Kicad at present time.
> >>> Recently implemented 'Ledger'
> >> I implemented it as USLedger, not Ledger.
> >>
> >>
> >>
> >>>  paper type is confusing me a lot. 
> >> Then this may be a short conversation.
> >>
> >>> It is declared as a paper of 17x11 in size.
> >>> The same time there is also a 'Tabloid' paper of 11x17 in size. What does
> it
> >> mean? It is commonly assumed
> >>> that the first value is the size X and the second is the size Y of a
> paper.
> >> That's why is it a kind of implicit logical 
> >>> orientation declaration (e.g. Portrait or Landscape) or is it an implicit
> >> declaration of a direction the paper
> >>> is fed into printer? Maybe it means nothing and it is just the same type
> of
> >> paper?
> >>
> >>
> >> I wanted a page choice of USLedger that was 11x17 inches, since I am in the
> >> US, and I use
> >> that paper size.  You can toggle the landscape button to orient when you
> plot.
> >>
> >> The private member function updatePortrait() establishes the initial page
> >> orientation
> >> according to what height and width are.  User now picks which paper
> >> orientation he wants
> >> from the dialogs, so the initial orientation is not really that important,
> >> especially
> >> since it is recorded in the BOARD file.
> >>
> >>
> >>
> >>
> >>
> >> ___
> >> 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
> 
> 
> ___
> 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] sorting pins in .lib files

2012-02-27 Thread Laurent GONZALEZ 
On 27/02/2012 15:03, Dick Hollenbeck wrote:
> 
> 
>>> I propose to start with getting rid of that mess, and see later whether
>>> we want to introduce more flexible scheme, maybe that would give
>>> priority to pin name, or location in the drawing.
>> It is on my personal to do list at some point in the future.  As an
>> interim step, you could use GetNumberString() and sort using the string
>> instead of the long integer value of the m_number member variable.
> 
> We can and should also think about getting "rid of messes" by *hiding* them 
> behind a
> elegant public interfaces.
> 
> Client code is where you replicate the calling into the public interfaces, 
> and only that
> *replication* would determine if a mess is being made or not.
> 
> If awkward implementation details are kept in a single place, hidden behind a 
> public
> interface, the awkwardness is not important.
> 
> See what I did to the same design of PADs in PCBNEW.  There is a "long" used 
> there to hold
> the 4 character pad number.  But nobody knows this, it is hidden.  So 
> changing strategies
> is trivial, since you did not replicate the strategy.
> 

I wholeheartedly agree with you.

The case I highlighted, breaks down to decide whether ASCII files
holding library data (and others) belong to the interface or not. No
wonder, that my opinion is "yes they do", hence my suggestion to sort
pins in a useful way (some indentation may help as well).

I apologize if somebody has been hurt by my messy words, I do not master
all the nuances of Shakespeare's language :)

--
Laurent

___
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] Printing and Ledger paper type.

2012-02-27 Thread Dick Hollenbeck 
On 02/27/2012 02:50 AM, Alexander Zakamaldin wrote:
> Yes, sure. I wrote about US Ledger paper size.
> It should be mentioned, the US Ledger's size confuses not only me, but 
> Gnomeprint job also.

Please explain in detail what are the symptoms of the problem.  That is how do 
you know it
is not working.




> So, what is the best choice to do?
> 1. Assume the US Ledger is 11x17 inches size, just the same as 'Inkscape' 
> project is doing.
> 2. Replace US Ledger with US Tabloid paper which is 11x17in exactly. The same 
> as 'GIMP'
> project is doing.
>
> Alexander.
>
>
> 27 февраля 2012, 09:38 от Dick Hollenbeck :
>> On 02/26/2012 06:44 AM, Alexander Zakamaldin wrote:
>>> Hi.
>>>
>>> I am working on printing issues for gtk based Kicad at present time.
>>> Recently implemented 'Ledger'
>> I implemented it as USLedger, not Ledger.
>>
>>
>>
>>>  paper type is confusing me a lot. 
>> Then this may be a short conversation.
>>
>>> It is declared as a paper of 17x11 in size.
>>> The same time there is also a 'Tabloid' paper of 11x17 in size. What does it
>> mean? It is commonly assumed
>>> that the first value is the size X and the second is the size Y of a paper.
>> That's why is it a kind of implicit logical 
>>> orientation declaration (e.g. Portrait or Landscape) or is it an implicit
>> declaration of a direction the paper
>>> is fed into printer? Maybe it means nothing and it is just the same type of
>> paper?
>>
>>
>> I wanted a page choice of USLedger that was 11x17 inches, since I am in the
>> US, and I use
>> that paper size.  You can toggle the landscape button to orient when you 
>> plot.
>>
>> The private member function updatePortrait() establishes the initial page
>> orientation
>> according to what height and width are.  User now picks which paper
>> orientation he wants
>> from the dialogs, so the initial orientation is not really that important,
>> especially
>> since it is recorded in the BOARD file.
>>
>>
>>
>>
>>
>> ___
>> 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


___
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 + V8/NodeJS/Swig [split from kicad ideas mail]

2012-02-27 Thread Dick Hollenbeck 
On 02/27/2012 01:48 AM, Miguel Angel Ajo Pelayo wrote:
> I've been doing some experiments about that during the weekend, with python 
> as a first
> target, and using SWIG (which should be highly desired, as it's something 
> easier to
> mantain).
>
> And by now, what I found is that swig is quite mature, but mainly ready for 
> this:
>  
> Python--->[extension]/extension_wrap.o >library.so
>
> This is one of our intended usages, but,  for usage inside kicad:
>
> Kicad<--->Python-->extension--->Kicad


I think to accomplish all our goals, we will have to split PCBNEW and EESCHEMA 
into at
least two parts each, perhaps three.  (Third part might be the graphics 
functions.)  This
means you keep a main() part, and have one or two DLL/DSO's beneath that main 
process
entry point.  This is my vision even *before* SWIG enters into it.

This lets you then have a replaceable main() part, that is a number of 
alternative
implementations of the top level process entry point.   EESCHEMA and PCNBEW 
core document
functions are held in what is essentially shared libraries.


I foresee at least 3 such alternative top main() parts:

a) simple command line processing main() without a scripting language.

b) scripting language main(), for any SWIG favorite language(s).

c) normal UI main() where the wxFrame and Dialogs reside.


For the final use case, which is normal UI but also with scripting:

Once you have this split (or these split_s_, if you consider a second DLL/DSO 
for drawing
functions), then like mortar in between two stacked bricks, there is a place to 
put a shim
in there, that is inject something below c) to handle the case where you want 
the normal
UI but also want scripting.



>
> It may require some hacking.

Your word, not mine.  I don't ever remember having hacked any code.  :)

> They had an embed.i that can be a start point. The problem is that SWIG build 
> wrapper
> modules that are ready to be loaded from python, but they include all the 
> swig logic. So
> then, if we linked kicad + python lib + wrapper_kicad.cxx + 
> wrapper_eeschema.cxx +
> wrapper_pcbnew.cxx then the swig code would be x3 times.


I mention all this so that you understand what we have been talking about, and 
don't
forget the BOARD_ACTION class, which is also still missing.   This is a way of 
pulling
non-UI verb type code down into the DLL/DSO layer without distancing it so far 
that it
cannot still be part of the c) wxFrames above.  I talked about using multiple 
inheritance
to bring BOARD_ACTION back into the frame.  Doing this across a DLL/DSO chasm 
will be a
trick, but it might be possible.  If it cannot be made to work, we can fall 
back to
separate link images, where you simply have identical code in a number places.


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] problem with the Help link "getting started in kicad"

2012-02-27 Thread Fabrizio Tappero 
jean-pierre,

hum... in my fresh dev. build of the kicad-doc folder taken 30 min ago
from here:

bzr branch lp:~kicad-developers/kicad/doc

if I compile and install, I get (among other stuff) the following pdfs:

1) /usr/local/share/doc/kicad/en/KiCad_Tutorial 2011.pdf
2) /usr/local/share/doc/kicad/help/en/Getting_Started_in_KiCad.pdf

when I start kicad (also taken and compiled today) and I go Help -
Getting started in KiCad I get the following error:

Help file getting_started_in_kicad.pdf could not be found

Maybe:
the tutorial 2) should be renamed getting_started_in_kicad.pdf and
also the file 2) should maybe deleted since several months ago when I
make getting_started_in_kicad.pdf I made it based on 1)

I hope this will help to fix a possible problem.
Cheers
Fabrizio



On Mon, Feb 27, 2012 at 11:15 AM, jp.charras  wrote:
> Le 27/02/2012 10:54, Fabrizio Tappero a écrit :
>
>> Hello,
>> it seems to me that the link help- getting started in kicad is broken
>> for all kicad programs. It should link to a short pdf tutorials and it
>> should work for all kicad programs.
>>
>> can anybody confirm that?
>>
>> cheers
>> Fabrizio
>
>
> I recently fixed this issue.
>
>
> --
> Jean-Pierre CHARRAS
> KiCad Developers team.
> KiCad Developers 
>
> ___
> 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

[Kicad-developers] suggestion - proper Yes/No question to user

2012-02-27 Thread Fabrizio Tappero 
Hello,
the Component Library Editor when closed after an unsaved modification
goes like:

Component was modified!
Discard changes?
Yes No

Shouldn't this message say:

This component was modified.
Do you want to save your changes?
Yes Cancel No

The same should maybe apply to the following messaged:

eeschema/libeditframe.cpp
330:if( !IsOK( this, _( "Component was modified!\nDiscard
changes?" ) ) )
346:msg.Printf( _( "Library \"%s\" was modified!\nDiscard
changes?" ),

eeschema/libedit.cpp
545:All changes will be lost. Discard changes?" ) ) )

eeschema/files-io.cpp
202:if( !IsOK( this, _( "Discard changes to the current
schematic?" ) ) )


Also, shouldn't the "Component Library Editor" be called "Library
Component Editor"?


Regards
Fabrizio

___
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] sorting pins in .lib files

2012-02-27 Thread Dick Hollenbeck 


>> I propose to start with getting rid of that mess, and see later whether
>> we want to introduce more flexible scheme, maybe that would give
>> priority to pin name, or location in the drawing.
> It is on my personal to do list at some point in the future.  As an
> interim step, you could use GetNumberString() and sort using the string
> instead of the long integer value of the m_number member variable.

We can and should also think about getting "rid of messes" by *hiding* them 
behind a
elegant public interfaces.

Client code is where you replicate the calling into the public interfaces, and 
only that
*replication* would determine if a mess is being made or not.

If awkward implementation details are kept in a single place, hidden behind a 
public
interface, the awkwardness is not important.

See what I did to the same design of PADs in PCBNEW.  There is a "long" used 
there to hold
the 4 character pad number.  But nobody knows this, it is hidden.  So changing 
strategies
is trivial, since you did not replicate the strategy.

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 + V8/NodeJS/Swig [split from kicad ideas mail]

2012-02-27 Thread Fabio Varesano 
Awesome, this is good news. In case you wanna dig more into this, I'll 
be happy to test any patch or early code development.


It's also worth noting that SWIG isn't the only way to access C/C++ 
libraries from within Python.. these are some of the other ways:

Cython http://cython.org/
Pyrex http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/

Fabio

On 02/27/2012 09:14 AM, Miguel Angel Ajo Pelayo wrote:

Sorry, I ignore the "_wrapper.cxx + yyy_wrapper.cxx + etc cannot
be linked together"... swig define them as static functions, so they
can be linked together and will work. The path is not that dark ;-)



2012/2/27 Miguel Angel Ajo Pelayo mailto:miguelan...@nbee.es>>

I've been doing some experiments about that during the weekend,
with python as a first target, and using SWIG (which should be
highly desired, as it's something easier to mantain).

And by now, what I found is that swig is quite mature, but mainly
ready for this:
 Python--->[extension]/extension_wrap.o >library.so

This is one of our intended usages, but,  for usage inside kicad:

 Kicad<--->Python-->extension--->Kicad

It may require some hacking. They had an embed.i that can be a
start point. The problem is that SWIG build wrapper modules that
are ready to be loaded from python, but they include all the swig
logic. So then, if we linked kicad + python lib +
wrapper_kicad.cxx + wrapper_eeschema.cxx + wrapper_pcbnew.cxx then
the swig code would be x3 times.

So I'll keep playing until I find a good way, and then we could
really estimate the man/hours needed :-)


2012/2/25 Fabio Varesano mailto:fabio.vares...@gmail.com>>

+1 on choosing Python over LUA or JS. Blender is using Python
as scripting language and also internally.. and I guess
Blender's requirements are pretty similar to those of KiCad.



On 02/24/2012 09:22 PM, Miguel Angel Ajo Pelayo wrote:

About python, yes, I think it fits the same way lua does,
and I'm my
opinion, it has more libraries
that can be useful for the scripts (like image
manipulation, etc...).
There wasn't a branch already
trying this, how good or bad did it go?


_
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




--

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] Printing and Ledger paper type.

2012-02-27 Thread Solonen Vesa 
http://www.graphic-design-employment.com/tabloid-paper-dimensions.html
http://www.graphic-design-employment.com/ledger-paper-dimensions.html

It seems there is no "portrait tabloid" or "landscape ledger". This paper size 
confusion shows a good example why well thought standard is usually a good 
thing ;^)

-Vesa
___
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] problem with the Help link "getting started in kicad"

2012-02-27 Thread jp.charras 

Le 27/02/2012 10:54, Fabrizio Tappero a écrit :

Hello,
it seems to me that the link help- getting started in kicad is broken
for all kicad programs. It should link to a short pdf tutorials and it
should work for all kicad programs.

can anybody confirm that?

cheers
Fabrizio


I recently fixed this issue.


--
Jean-Pierre CHARRAS
KiCad Developers team.
KiCad Developers 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] problem with the Help link "getting started in kicad"

2012-02-27 Thread Fabrizio Tappero 
Hello,
it seems to me that the link help- getting started in kicad is broken
for all kicad programs. It should link to a short pdf tutorials and it
should work for all kicad programs.

can anybody confirm that?

cheers
Fabrizio

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Printing and Ledger paper type.

2012-02-27 Thread Alexander Zakamaldin 
Yes, sure. I wrote about US Ledger paper size.
It should be mentioned, the US Ledger's size confuses not only me, but 
Gnomeprint job also.
So, what is the best choice to do?
1. Assume the US Ledger is 11x17 inches size, just the same as 'Inkscape' 
project is doing.
2. Replace US Ledger with US Tabloid paper which is 11x17in exactly. The same 
as 'GIMP'
project is doing.

Alexander.


27 февраля 2012, 09:38 от Dick Hollenbeck :
> On 02/26/2012 06:44 AM, Alexander Zakamaldin wrote:
> > Hi.
> >
> > I am working on printing issues for gtk based Kicad at present time.
> > Recently implemented 'Ledger'
> 
> I implemented it as USLedger, not Ledger.
> 
> 
> 
> >  paper type is confusing me a lot. 
> 
> Then this may be a short conversation.
> 
> > It is declared as a paper of 17x11 in size.
> 
> > The same time there is also a 'Tabloid' paper of 11x17 in size. What does it
> mean? It is commonly assumed
> > that the first value is the size X and the second is the size Y of a paper.
> That's why is it a kind of implicit logical 
> > orientation declaration (e.g. Portrait or Landscape) or is it an implicit
> declaration of a direction the paper
> > is fed into printer? Maybe it means nothing and it is just the same type of
> paper?
> 
> 
> I wanted a page choice of USLedger that was 11x17 inches, since I am in the
> US, and I use
> that paper size.  You can toggle the landscape button to orient when you plot.
> 
> The private member function updatePortrait() establishes the initial page
> orientation
> according to what height and width are.  User now picks which paper
> orientation he wants
> from the dialogs, so the initial orientation is not really that important,
> especially
> since it is recorded in the BOARD file.
> 
> 
> 
> 
> 
> ___
> 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 + V8/NodeJS/Swig [split from kicad ideas mail]

2012-02-27 Thread Miguel Angel Ajo Pelayo 
I've been doing some experiments about that during the weekend, with python
as a first target, and using SWIG (which should be highly desired, as it's
something easier to mantain).

And by now, what I found is that swig is quite mature, but mainly ready for
this:

Python--->[extension]/extension_wrap.o >library.so

This is one of our intended usages, but,  for usage inside kicad:

Kicad<--->Python-->extension--->Kicad

It may require some hacking. They had an embed.i that can be a start point.
The problem is that SWIG build wrapper modules that are ready to be loaded
from python, but they include all the swig logic. So then, if we linked
kicad + python lib + wrapper_kicad.cxx + wrapper_eeschema.cxx +
wrapper_pcbnew.cxx then the swig code would be x3 times.

So I'll keep playing until I find a good way, and then we could really
estimate the man/hours needed :-)

2012/2/25 Fabio Varesano 

> +1 on choosing Python over LUA or JS. Blender is using Python as scripting
> language and also internally.. and I guess Blender's requirements are
> pretty similar to those of KiCad.
>
>
>
> On 02/24/2012 09:22 PM, Miguel Angel Ajo Pelayo wrote:
>
>> About python, yes, I think it fits the same way lua does, and I'm my
>> opinion, it has more libraries
>> that can be useful for the scripts (like image manipulation, etc...).
>> There wasn't a branch already
>> trying this, how good or bad did it go?
>>
>
> __**_
> 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 + V8/NodeJS/Swig [split from kicad ideas mail]

2012-02-27 Thread Miguel Angel Ajo Pelayo 
Sorry, I ignore the "_wrapper.cxx + yyy_wrapper.cxx + etc cannot be
linked together"... swig define them as static functions, so they can be
linked together and will work. The path is not that dark ;-)



2012/2/27 Miguel Angel Ajo Pelayo 

> I've been doing some experiments about that during the weekend, with
> python as a first target, and using SWIG (which should be highly desired,
> as it's something easier to mantain).
>
> And by now, what I found is that swig is quite mature, but mainly ready
> for this:
>
> Python--->[extension]/extension_wrap.o >library.so
>
> This is one of our intended usages, but,  for usage inside kicad:
>
> Kicad<--->Python-->extension--->Kicad
>
> It may require some hacking. They had an embed.i that can be a start
> point. The problem is that SWIG build wrapper modules that are ready to be
> loaded from python, but they include all the swig logic. So then, if we
> linked kicad + python lib + wrapper_kicad.cxx + wrapper_eeschema.cxx +
> wrapper_pcbnew.cxx then the swig code would be x3 times.
>
> So I'll keep playing until I find a good way, and then we could really
> estimate the man/hours needed :-)
>
>
> 2012/2/25 Fabio Varesano 
>
>> +1 on choosing Python over LUA or JS. Blender is using Python as
>> scripting language and also internally.. and I guess Blender's requirements
>> are pretty similar to those of KiCad.
>>
>>
>>
>> On 02/24/2012 09:22 PM, Miguel Angel Ajo Pelayo wrote:
>>
>>> About python, yes, I think it fits the same way lua does, and I'm my
>>> opinion, it has more libraries
>>> that can be useful for the scripts (like image manipulation, etc...).
>>> There wasn't a branch already
>>> trying this, how good or bad did it go?
>>>
>>
>> __**_
>> 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
>



-- 

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