Re: [Kicad-developers] Improving usability of KiCad

[Marco Serantoni]

On Oct 13, 2010, at 8:17 AM, Dick Hollenbeck wrote:

> 
>> I wonder if it occurred to others - if the inch had been defined as 25.6 
>> instead of 25.4/mm this 
>> problem would have been quite different.  
> 
> I thought the inch was defined first.
> 
>> I do think the inch will die out someday. 
> 
> That's what they said in here in the USA in the 1960's.  And then Dr.
> Spock came along and the world got soft, teachers got a break, kids got
> a break.  In the 1960's I remember there being a commitment to learn
> metric, then that commitment went away, because it meant, ahem, work and
> study and teaching. Not just for kids in school but also for adults out
> of school.


Dick, we doesn't want that US will change its metric system, nor begin a lesson 
of metrology.
Scientific international system is MKS, wxDC has also calls that returns 
millimeters, the greatest part of the world population uses a metric system, 
ISO 31 says the same,  don't you find those be good reasons to switch the 
internal metric system to a metric one ?

Mr Spock could say in this occasion: the many outweigh the needs of the few. 

--
Marco___
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] Overflow-button in about menu segfaults

[Marco Serantoni]

On Oct 20, 2010, at 12:18 AM, Martijn Kuipers wrote:

> Hi Devs,
> 
> I just noticed that the overflow button in the about-menu crashes with 
> accessing a null-pointer. Easy fix would be to just remove 
> wxAUI_NB_WINDOWLIST_BUTTON from the line below in common/dialog_about_base.fbp
> 
>  name="style">wxAUI_NB_SCROLL_BUTTONS|wxAUI_NB_TAB_FIXED_WIDTH|wxAUI_NB_WINDOWLIST_BUTTON
> 
> Is this the correct fix?

If nobody has something against this change i will commit it tomorrow.

--
Marco

___
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] Events inside kicad

[Marco Serantoni]

In those days i was thinking about to add an internal event generation for some 
kicad classes.
Adding internal events at wxAUIManager could be a good start to implement 
"external frames" and utilities (plugins) , making possible plug-in new 
functionalities and probably reorganizing some parts of code

I've already something ready, if nobody has something against it i wish commit 
the first tranche of the implementation on pcbnew.

--
Marco
___
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] Events inside kicad

[Marco Serantoni]

kicad-events.diff
Description: Binary data

On 26/ott/2010, at 20.54, Dick Hollenbeck wrote:

> On 10/26/2010 01:50 PM, Marco Serantoni wrote:
>> In those days i was thinking about to add an internal event generation for 
>> some kicad classes.
>> Adding internal events at wxAUIManager could be a good start to implement 
>> "external frames" and utilities (plugins) , making possible plug-in new 
>> functionalities and probably reorganizing some parts of code
>> 
>> I've already something ready, if nobody has something against it i wish 
>> commit the first tranche of the implementation on pcbnew.
>> 
> 
> If it is as disruptive as you say, can we see a patch and have a short
> chat about it before you commit?

Indeed, 
Here is the patch, let's chat :)

--
Marco___
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] Events inside kicad

[Marco Serantoni]

On 26/ott/2010, at 21.10, Dick Hollenbeck wrote:
>> Indeed, 
>> Here is the patch, let's chat :)
> 
> Thanks for your patience, and willingness to accept feedback.
> 
> We might need to wait a day or two for folks to comment.
> 
> I know English is not your favorite language, but it would be easier for
> folks to grasp what you are trying to do with some supporting
> documentation.  It looks like you have something ambitious in mind.
> 
> Can an inkscape diagram tell the story better than words, using arrows
> or what not?
> 

I have nothing ambitious in mind, just add something like this also to BOARD. 
those events could be at the service of who wants to bind those events.

For the sake of discussion, i've nothing against English it is just not my 
mother tongue, just figure out that i speak another couple of languages even 
worse :)

--
Marco
___
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] Events inside kicad

[Marco Serantoni]

On 27/ott/2010, at 21.55, Wayne Stambaugh wrote:
>>> 
>> No, definitelly, i'm not proposing to create a custom internal scripting 
>> language, and in case, the SCREEN is not the best place to start with.
>> I also think that bind command events is not a good way, being  too much gui 
>> tied you have to listen Menu and Toolbar ones and tomorrow probably  you 
>> should also listen additional command IDs.
>> 
>> If you don't have them, you can neither have a consumer for those events, 
>> Chicken and Egg dilemma.
> 
> True.  But what happens if you code egg and chicken never comes?  After a 
> while
> the egg rots.  Remember the boost::python implementation?  Did anyone ever
> write a useful Python program that took advantage of this good idea?  I don't
> remember ever seeing one published since I've been with the project.  I'm sure
> who ever wrote this code thought it was a good idea but they never followed
> through.  This is what I am trying to avoid.  If you can give me an example of
> an "EagleView" window that provides some must have functionality that cannot 
> be
> duplicated in the main application window then I'll give my OK to commit this
> patch.

So why you don't cleanup that ? 
You have a rotten egg, is correct yell and trash it if nobody complains.
The other soluction is sterelize the chickens , avoid other chicken enter and 
choose to change house.

I still personally think that bind Menu, Buttons  and all other GUI objects 
events still a less clean approach, but still not a problem i'm thrashing the 
egg, they are free :)

--
Marco



___
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] Events inside kicad

[Marco Serantoni]

On 27/ott/2010, at 22.58, Wayne Stambaugh wrote:
>> 
>> So why you don't cleanup that ? 
> 
> That was done a long time ago.
> 
>> You have a rotten egg, is correct yell and trash it if nobody complains.
> 
> This assumes that someone has the time to go back and get rid of it.  Maybe
> publishing a personal development branch on launchpad is a better way to go
> until we can get a clearer picture of how your code will make Kicad cleaner,
> easier to debug, and provide some as yet defined feature.  Then it can be
> merged into the testing branch.  This way you get to develop at your pace and
> if it doesn't work, someone doesn't have to clean up after it's abandoned.
> 

I think to have ever asked other to clean my dirt, and i don't wish to begin 
to do it now, nor i've ever asked others to do things that i usually i don't 
deserve to me.
If having a personal branch is the new rule, all must follow this rule also 
if Summum ius, summa iniuria.
Otherwise i should be concerned about the usage of pluralium maiestatum.

I wish close this discussion because i don't think that will be usefully for no 
one.

Honestly nothing personal, 

--
Marco 

PS
Yes, english is not my favourite language.

> Wayne
> 
>> The other soluction is sterelize the chickens , avoid other chicken enter 
>> and choose to change house.
>> 
>> I still personally think that bind Menu, Buttons  and all other GUI objects 
>> events still a less clean approach, but still not a problem i'm thrashing 
>> the egg, they are free :)
>> 
>> 

___
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] Revision 2604 has broken cvpcb and some random warnings

[Marco Serantoni]

On 12/nov/2010, at 11.02, Jerry Jacobs wrote:

Jerry i'm working on it.

> [ 70%] Building CXX object cvpcb/CMakeFiles/cvpcb.dir/cvpcb.cpp.o
> /Users/jerry/Projects/kicad/testing/cvpcb/cvpcb.cpp: In member
> function ‘virtual bool WinEDA_App::OnInit()’:
> /Users/jerry/Projects/kicad/testing/cvpcb/cvpcb.cpp:87: error:
> ‘ID_KICAD_ABOUT’ was not declared in this scope
> /Users/jerry/Projects/kicad/testing/cvpcb/cvpcb.cpp:88: error:
> ‘ID_OPTIONS_SETUP’ was not declared in this scope
> make[2]: *** [cvpcb/CMakeFiles/cvpcb.dir/cvpcb.cpp.o] Error 1
> make[1]: *** [cvpcb/CMakeFiles/cvpcb.dir/all] Error 2
> 
> Including id.h seems to fix this.

It fixes, committing soon.

> 
> Also some not nice warning include:
> 
> [ 87%] Building CXX object pcbnew/CMakeFiles/pcbnew.dir/block.cpp.o
> /Users/jerry/Projects/kicad/testing/pcbnew/block.cpp: In function
> ‘void drawPickedItems(WinEDA_DrawPanel*, wxDC*, wxPoint)’:
> /Users/jerry/Projects/kicad/testing/pcbnew/block.cpp:653: warning:
> enumeration value ‘NOT_USED’ not handled in switch
> /Users/jerry/Projects/kicad/testing/pcbnew/block.cpp:653: warning:
> enumeration value ‘EOT’ not handled in switch
> /Users/jerry/Projects/kicad/testing/pcbnew/block.cpp:653: warning:
> enumeration value ‘TYPE_NOT_INIT’ not handled in switch
> /Users/jerry/Projects/kicad/testing/pcbnew/block.cpp:653: warning:
> enumeration value ‘TYPE_PCB’ not handled in switch
> /Users/jerry/Projects/kicad/testing/pcbnew/block.cpp:653: warning:
> enumeration value ‘TYPE_SCREEN’ not handled in switch
> 

This one was already fixed

> And this:
> 
> /Users/jerry/Projects/kicad/testing/pcbnew/export_vrml.cpp:760:
> warning: ‘void export_vrml_zones(BOARD*)’ defined but not used
> 
> And this:
> 
> In file included from /Users/jerry/Projects/kicad/testing/common/xnode.cpp:26:
> /Users/jerry/Projects/kicad/testing/include/xnode.h: In member
> function ‘wxString XNODE::GetAttribute(const wxString&, const
> wxString&) const’:
> /Users/jerry/Projects/kicad/testing/include/xnode.h:76: warning:
> ‘GetPropVal’ is deprecated (declared at
> /opt/wxwidgets/65968/include/wx-2.9/wx/xml/xml.h:229)
> /Users/jerry/Projects/kicad/testing/include/xnode.h: In member
> function ‘bool XNODE::GetAttribute(const wxString&, wxString*) const’:
> /Users/jerry/Projects/kicad/testing/include/xnode.h:80: warning:
> ‘GetPropVal’ is deprecated (declared at
> /opt/wxwidgets/65968/include/wx-2.9/wx/xml/xml.h:226)
> /Users/jerry/Projects/kicad/testing/include/xnode.h: In member
> function ‘wxXmlAttribute* XNODE::GetAttributes() const’:
> /Users/jerry/Projects/kicad/testing/include/xnode.h:88: warning:
> ‘GetProperties’ is deprecated (declared at
> /opt/wxwidgets/65968/include/wx-2.9/wx/xml/xml.h:223)
> 
> And last:
> 
> In file included from
> /Users/jerry/Projects/kicad/testing/eeschema/netform.cpp:53:
> /Users/jerry/Projects/kicad/testing/include/xnode.h: In member
> function ‘wxString XNODE::GetAttribute(const wxString&, const
> wxString&) const’:
> /Users/jerry/Projects/kicad/testing/include/xnode.h:76: warning:
> ‘GetPropVal’ is deprecated (declared at
> /opt/wxwidgets/65968/include/wx-2.9/wx/xml/xml.h:229)
> /Users/jerry/Projects/kicad/testing/include/xnode.h: In member
> function ‘bool XNODE::GetAttribute(const wxString&, wxString*) const’:
> /Users/jerry/Projects/kicad/testing/include/xnode.h:80: warning:
> ‘GetPropVal’ is deprecated (declared at
> /opt/wxwidgets/65968/include/wx-2.9/wx/xml/xml.h:226)
> /Users/jerry/Projects/kicad/testing/include/xnode.h: In member
> function ‘wxXmlAttribute* XNODE::GetAttributes() const’:
> /Users/jerry/Projects/kicad/testing/include/xnode.h:88: warning:
> ‘GetProperties’ is deprecated (declared at
> /opt/wxwidgets/65968/include/wx-2.9/wx/xml/xml.h:223)
> 
> I compile on OS X with wxWidgets 2.9.2 (svn revision 65968)
> 

Those are old, and probably will be fixed in the future when wx2.9 will be the 
standard for all the platforms, users with wx2.8 aren't few.

--
Marco


___
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] Revision 2604 has broken cvpcb and some random warnings

[Marco Serantoni]

Seen,

Mercì Jean-pierre

On 12/nov/2010, at 19.53, jean-pierre charras wrote:

> Le 12/11/2010 19:06, Marco Serantoni a écrit :
>> 
>> 
>> On 12/nov/2010, at 11.02, Jerry Jacobs wrote:
>> 
>> Jerry i'm working on it.
> 
> I committed some changes (mainly an annoying  bug when reading old eeschema 
> files)
> This issues should be fixed now.
> 
> -- 
> Jean-Pierre CHARRAS
> 

___
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] Make USE_WX_ZOOM=ON the default.

[Marco Serantoni]

On 11/gen/2011, at 19.34, Wayne Stambaugh wrote:

Wayne, i had some problems with WX_ZOOM some time ago, expecially with 
printing, there was some fixes of wxwidgets latelly, i'll compile and check it 
on all 3 OSX main platforms ASAP.
Anyway i'm interested too to simplify the code and reuse the wxwidgets one.

--
Marco

> I have been playing around with USE_WX_ZOOM=ON again because I've yet again 
> run
> up against my second least favorite global variable ActiveScreen.  It seems to
> work fine on both Linux and Windows for displaying, printing, and plotting.
> Has anyone using OSX tested this?  If there are no technical reasons not to 
> use
> it, I would like to make this the default setting to flesh out any corner case
> behavior.  After any issues have been resolved, I would like to eliminate all
> of the #ifdef USE_WX_ZOOM/#endif code and all of the dead code associated with
> ActiveScreen.  This has the following advantages:

___
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] Make USE_WX_ZOOM=ON the default.

[Marco Serantoni]

On 12/gen/2011, at 00.41, Wayne Stambaugh wrote:
There are some problems with the refresh on pcbnew initially and zooming in and 
out the screen remains completly black, i've to understood why.
The great thing is that the subpixel lines are great with the OSX aliasing.

I can workaround that with some forced Refresh(), will impact on performace but 
for me is GO.

Marco

> Marco,
> 
> Thanks for taking a look a this on OSX.  Let me know if you find any
> problems and I do my best to fix them.
> 
> Wayne
> 
> On 1/11/2011 6:37 PM, Marco Serantoni wrote:
>> 
>> On 11/gen/2011, at 19.34, Wayne Stambaugh wrote:
>> 
>> Wayne, i had some problems with WX_ZOOM some time ago, expecially with 
>> printing, there was some fixes of wxwidgets latelly, i'll compile and check 
>> it on all 3 OSX main platforms ASAP.
>> Anyway i'm interested too to simplify the code and reuse the wxwidgets one.
>> 
>> --
>> Marco

___
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] Make USE_WX_ZOOM=ON the default.

[Marco Serantoni]

On 12/gen/2011, at 22.00, Wayne Stambaugh wrote:
> On 1/12/2011 3:31 PM, Marco Serantoni wrote:
>> 
>> On 12/gen/2011, at 00.41, Wayne Stambaugh wrote:
>> There are some problems with the refresh on pcbnew initially and zooming in 
>> and out the screen remains completly black, i've to understood why.
> 
> This is strange indeed because DrawFrame::Recadre_Trace() calls
> DrawPanel::ReDraw() directly instead of issuing a refresh command.  Maybe 
> there
> is an extra refresh sneaking in somewhere on OSX that doesn't occur on other
> platforms.  I'm not sure why this is implemented this way, JP may have some
> insight as to why the normal refresh isn't being used.

It couldn't be an extra refresh, OSX doesn't support correctly Logical 
Operators so i was forced to arrange each draw in solid with wxOverlay.

>> The great thing is that the subpixel lines are great with the OSX aliasing.
>> 
>> I can workaround that with some forced Refresh(), will impact on performace 
>> but for me is GO.
> 
> I'm sure this works but it seems like an ugly hack to me.  I would like to see
> if there isn't a better solution before we add an extra refresh for OSX.

A temporary hack can be afforded until the problem is well focused.
the strange thing is that this doesn't happens with eeschema :)
--
Marco___
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] USE_WX_ZOOM update.

[Marco Serantoni]

On 28/gen/2011, at 18.46, Wayne Stambaugh wrote:

> I am pretty much done removing USE_WX_ZOOM and all of the unused code

Is ok for me :)

--
Marco

___
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] Mac OS X Performance Questions

[Marco Serantoni]

On 15/lug/2011, at 15.39, Fred Cooke wrote:
Fred,
About which version you are referring to, picked from where ?
And which test you have done ?

Cause is Know, 
wx-widgets related vs XOR (un)support on OSX, workarounded with wxOverlay that 
is not correctly implemented under wxCoccoa too.
ask to wx-developers.

Regards,
  Marco

> Hello All,
> 
> A few weeks ago I tried KiCad on OS X and although eeschema appeared
> to work OK, pcbnew was unusably slow (0.3fps scrolling or zooming in
> 2d, 3d, which I just, tried is acceptable). I assume that you're
> already aware of this, and as such I have the following questions:
> 
> Is the cause known?
> If not, is it being looked for?
> If so, is it being worked on?
> If so, estimated date of completion?
> 
> If my assumption about this being a known issue was wrong, can I do
> something to provide feedback more formally?
> 
> Thank you for your time!
> 
> Regards,
> 
> Fred.
> 
> ___
> 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] Mac OS X Performance Questions

[Marco Serantoni]

Try this one http://www.mdx4.org/uploads/kicad/Kicad-20-MAY-2011.zip

This uses an hacked version of wx-widgets to enable the Native wxOverlay,
the result is a working Kicad with some small issues but i think still
usable.

This was possible after the fix of some problems with the UserScale (
http://trac.wxwidgets.org/ticket/13216 ) now in the svn tree.

Still missing a native wxOverlay implementation under Cocoa:
http://trac.wxwidgets.org/ticket/12894
(The default implemented flickers)

--
Marco


On Tue, Jul 19, 2011 at 8:57 PM, Fred Cooke  wrote:

> OK, back from the shops!
>
> kicad_osx_v3009_STABLE
>
> It was some daily build, I think. I'm sure you know where from.
>
> I suspected that it was a wx issue. Can you give me a link to pester
> the wx devs? I will happily be their tester too :-)
>
> I have a project of my own and a bunch of people, at least two of whom
> are reading this use or want to use Kicad to design PCBs for it.
>
> One of my biggest fans is a Mac fan, which is how I ended up with a
> Mac, he'll be happy if it works reasonably on them too.
>
> Regards,
>
> Fred.
>
> On Tue, Jul 19, 2011 at 6:56 PM, Marco Serantoni
>  wrote:
> >
> > On 15/lug/2011, at 15.39, Fred Cooke wrote:
> > Fred,
> > About which version you are referring to, picked from where ?
> > And which test you have done ?
> >
> > Cause is Know,
> > wx-widgets related vs XOR (un)support on OSX, workarounded with wxOverlay
> that is not correctly implemented under wxCoccoa too.
> > ask to wx-developers.
> >
> > Regards,
> >  Marco
> >
> >> Hello All,
> >>
> >> A few weeks ago I tried KiCad on OS X and although eeschema appeared
> >> to work OK, pcbnew was unusably slow (0.3fps scrolling or zooming in
> >> 2d, 3d, which I just, tried is acceptable). I assume that you're
> >> already aware of this, and as such I have the following questions:
> >>
> >> Is the cause known?
> >> If not, is it being looked for?
> >> If so, is it being worked on?
> >> If so, estimated date of completion?
> >>
> >> If my assumption about this being a known issue was wrong, can I do
> >> something to provide feedback more formally?
> >>
> >> Thank you for your time!
> >>
> >> Regards,
> >>
> >> Fred.
> >>
> >> ___
> >> 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] Concerns about clearing disagreements before committing.

[Marco Serantoni]

On 27/nov/2011, at 23:44, Vladimir Uryvaev wrote:
> 
>> So it is not clear to me that a function written by you for this purpose
>> would serve previously stated goals.
>> 
>> If you are insistent on no exponents in the number, I am insistent on the
>> smallest files including trailing zero removal where we can.
> 
> Being self documenting and smallest size are contradict features, don't you 
> think? ;) Self documeting means adding redundant information, and shrinking 
> size meand removing it.
> 
>> fprintf( fp, "example coord: %3s %3s\n",
>>biuFmt( pad.x() ).c_str(), biuFmt( pad.y() ).c_str() );
> 
> Why don't you use iostreams for this?

Sorry if I'm entering in this discussion that late, i were away for a long time 
from the project and discussions here.
Looking to the discussion i can understand both points of view, i like 
readibility and i hate loose space on my HD.
Since we are talking about a file format change and a rewrite, was already 
weighted the possibility of take advantage of wxwidgets 
using wxZlib(Input/Output)Stream and/or wxString::Printf  ?
We could also thing about a successive expansion and use Zip format instead 
storing multiple versions of the project and/or to add library cache in the 
future.

Just my 5c,

--
Marco___
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] OSX and new Icons

[Marco Serantoni]

Hi folks,
I'm as usual doing my semestral build of Kicad, one is for Xmas.
I've noticed that icons were changed i wish to compliment with the author for 
the enhancement, i appreciated the KDE style but i'm afraid that could be 
confusing for operations like New, Open and Save that are usually coded in a 
different way under Windows and OSX.

Now passing to the problem, i've noticed that also the icons for the 
applications are changed, to make them appear correctly under OSX i need to a 
bitmap of different square sizes: 16,32,128,256,512 needed for a icns file 
(icon).
Are those avaiable ? otherwise i had to still use the old icons and create a 
new one for PCB Calculator.

Thank you,
 Marco
___
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] OSX and new Icons

[Marco Serantoni]

On 10/dic/2011, at 08:14, jean-pierre charras wrote:


> Le 10/12/2011 02:18, Martijn Kuipers a écrit :
>> Hi,
>> On Dec 9, 2011, at 8:51 PM, Marco Serantoni wrote:
>> 
>>> Hi folks,
>>> I'm as usual doing my semestral build of Kicad, one is for Xmas.
>>> I've noticed that icons were changed i wish to compliment with the author 
>>> for the enhancement, i appreciated the KDE style but i'm afraid that could 
>>> be confusing for operations like New, Open and Save that are usually coded 
>>> in a different way under Windows and OSX.
>>> 
>>> Now passing to the problem, i've noticed that also the icons for the 
>>> applications are changed, to make them appear correctly under OSX i need to 
>>> a bitmap of different square sizes: 16,32,128,256,512 needed for a icns 
>>> file (icon).
>>> Are those avaiable ? otherwise i had to still use the old icons and create 
>>> a new one for PCB Calculator.
>> 
> 
> If you need only a png version of icons,
> you can just convert the source icons (see bitmaps_png/sources/*.svg) to 
> various png icons sizes
> using Inkscape (It was used to create the svg files).
> sources icons are vectored, and can be converted to any size without loss of 
> quality.
> Inkscape has a build-in png exporter.
> 

Jean pierre,
I've already seen those, the problem is that i can't find the PCB Calulator 
one, someone could suggest me the filename ?

---
Marco___
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] Hating wx configuration more than ever...

[Marco Serantoni]

On Tue, May 8, 2012 at 8:01 AM, Dick Hollenbeck  wrote:

>
> This means that we eventually, we'll no longer need all the wxT() stuff,
> since we
> basically never put anything but ASCII characters in those wrappers and to
> convert from an
> ASCII string to UTF8 is simply a matter of copying bytes without any
> conversion at all.
> And converting ASCII bytes to UTF16 characters is simply a matter of
> zeroing out the upper
> byte.
>

I don't think is that simple for cyrillic, japanese and languages that used
accented or Diaeresized words.
There is an hard work on some of those aspects, i don't think we want to
trash it out.

--
Marco
___
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] SCH_POLYLINE?

[Marco Serantoni]

On 08/mag/2012, at 06:16, Lorenzo Marcantonio wrote:

> On Mon, May 07, 2012 at 02:18:57PM -0500, Dick Hollenbeck wrote:
>> OSX
> 
> OSX is handled in GRSetDrawMode (as it should be). GRSetColorPen uses 
> MakeColour which only sets the alpha from the upper bits (are you referring 
> to this?)
> 
> Compositing mode has nothing to do with EDA_COLOR_T

Lorenzo, you got the point about bezier curves on bitmap conversion library and 
is there at disposition for further library conversion tools moreover is a 2d 
primitive of wxGraphicPath.

About OSX i'll resume again the status, OSX has not a raster interface but 
vectorial interface with alpha enabled by default called Quartz 2D.
The advantage of using a vectorial interface could be the possibility of 
zooming in hardware and having a virtually infinite resolution, etc , and I 
know that you are well aware of that.

I'm waiting from years that we could migrate to some of more "modern" than 
wxDC, i hope in the GAL will ship soon or that could be used wxGraphicsContext 
interface also on windows (there were performance problems) or some GAL that 
can be casted in wxGC.

In the meanwhile i had the not nice task to "CAST" the raster algorithm into 
the vectorial one, and wasn't a nice task, like cast a Blue Ray storage in 
punched cards.

The algorithm used by kicad to draw relies and is optimized to raster and there 
were some issues casted in the best effort way:

All bit enabled operations are unusable like: XOR erasing and XOR color 
additions so:
In redraw (zooming too) all is erased and redrawn - one reason 
why is "slow"
Moving cursor has required wxOverlay (i've customized/patched 
wxWidgets to use native one after the Zoom hack change I can't use BITMAP one)
Adding colors needs Alpha (that is enabled by default)

Subpixels are DRAWN and blurred
Zero size is respected (i become mad until few months ago)
Being HW accelerated the expected primitive is not a point or a line 
but a complete PATH, roundtrip is expensive - other reason why is "slow"

All this "cast" is injected in the old code and now STABLE and usable, before 
do a revolution please take in account this, i don't want to stop you but make 
a change that has the right value added.
This code now compiles on 4 architecture (ppc,ppc64,x86,x86_64) just imagine 
how much it takes only to compile to test something, have mercy and do 
something that makes the worth to begin from scratch.

--
Marco


___
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] Graphics Limits … Windows & CAIRO

[Marco Serantoni]

Jep,
I'm here advocaciong again wxGraphicsContext.
I'm feeling that also with nanometers we are going to fit tight with the simple 
wxDC.
I'm proposing to fade using wxGCDC and use Paths that handles coordinates with 
wxDouble.


To test the state of the art i suggest to test it on Windows doing those hacks:

Compile wxwidgets statically enabling wxUSE_CAIRO (switches on CAIRO instead 
GDI/GDI+ that was result to be slugghish/slow).
Change the Kicad code to use wxGCDC (is enough change a bit 
kicad_device_context.h)

This should show us how Kicad + wx + cairo performs on Windows and show if we 
can pass for this way to enhance kicad.

If someone has enough time, compiling CAIRO should also possible test how 
performs its OpenGL backend on windows.

I wish do it, but i haven't a windows platform under my hands, so there is any 
volunteer ?


--
Marco Serantoni
___
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] Graphics Limits … Windows & CAIRO

[Marco Serantoni]

On 10/mag/2012, at 10:46, Torsten Hüter wrote:

Torsen,
I'm still stuck but i can wait, which is the deadline for the shipment of the 
GAL in the trunk ? 
I'm proposing this approach because is a viable way to start to redesign the 
drawing code before GAL is ready.

I recall well that we have done performance tests were Windows was the 
showstopper platform but:
- Not with CAIRO on windows, since http://trac.wxwidgets.org/ticket/14194 was 
closed 4-5 weeks ago and tests were conducted on GDI (only matrox supports this 
in HW).
- We were using wxDC style, drawing immediate is more an handicap than a 
performance gaining approach with HW acceleration.

I'm almost scared to fight with a new Custom Graphics Abstration Layer. 
I'vent much time to dedicate and i'm afraid that debugging and correct 
implementation on the platform will require months of frustrating work to make 
it just work, this situation summed with the frustrating work i were required 
to do for making it work until now (wxOverlay addition) and added those months 
of Freeze the situation begins to approach the limits of the allowable for a 
Gratis/Free work (as Dick reminds us frequently).

--
Marco

> Hi Marco,
> 
> I hope you have the patience to wait for the integration of the GAL. I've 
> done these performance tests before I've started to write the code and I've 
> narrowed my selection to a direct, simple OpenGL backend for speed and a 
> cairo variant. With the interface that I've created you can write your own 
> plugin for another backend, but I'd prefer to concentrate on these two first.
> Dick has already started to integrate the VECTOR2D class, which is our 
> independent implementation of a point/vector.
> I'm doing at the moment some code cleaning and go through all examples and 
> then I'll upload an updated version.
> I need some help for testing it on OSX, perhaps if you have some time left?
> 
> Thanks,
> Torsten


___
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] Graphics Limits … Windows & CAIRO

[Marco Serantoni]

On 10/mag/2012, at 15:22, Dick Hollenbeck wrote
> 
> Will the real Jep please stand up who is Jep?

Is a friend of Godot :)

> 
> 
> Torsten, do you know about
> 
> 
>  http://www.hackintosh.com
> 
> 
> Somebody I know is running the OSX stack under a VM on a Windows machine.
> 
> This person said they made the image himself, and referred to it as 
> hackintosh, I googled
> and found the above site.
> 
> However, my own opinion is that someone using macs should buy you a mac, just 
> to offset of
> the costs that you have into this project.
> 
> 
> Dick

Could be a good solution for compile, but platform is old and i dubt is much 
legal to own and run that VM on non Apple HW.
Doing it is just to say: "So Sue Me"

--
Marco
___
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] Graphics Limits … Windows & CAIRO

[Marco Serantoni]

On Mon, May 14, 2012 at 8:32 AM, Lorenzo Marcantonio <
l.marcanto...@logossrl.com> wrote:

> On Sat, May 12, 2012 at 04:59:58PM +0200, Marco Serantoni wrote:
> > - Not with CAIRO on windows, since
> http://trac.wxwidgets.org/ticket/14194 was closed 4-5 weeks ago and tests
> were conducted on GDI (only matrox supports this in HW).
>
> CAIRO is a showstopper on Linux without gallium (i.e. hw acceleration),
> so the problem remain...
>

Lorenzo, if i recall correctly there is also an OpenGL backend that can be
enabled setting an enviroment variable.

> - We were using wxDC style, drawing immediate is more an handicap than a
performance gaining approach with HW acceleration.

 I'm not familiar with this issue
>
 Just see DoubleBuffered vs Non buffered wxDC, the first done first in
memory then pushed on the Device, the second done directly on the device.


 > I'm almost scared to fight with a new Custom Graphics Abstration Layer.
>
> Do you have another idea to keep the current (very reasonable)
> performance without hw accel and implementing hw accel support (most
> probably with opengl)?
>
> I agree that is not a trivial problem to solve. There are worse in the
> field :D for example: code for opengl supporting efficiently both triangle
> streaming gpu (Intel/ATI/NVidia) *and* tile renderers (PowerVR): if you
> think about it these are almost complementar way to handle rendering:P
>
> That and most open source drivers tends to have better performance in
> the 2d graphics path...
>

http://cairographics.org/backends/ <http://cairographics.org/OpenGL/>   -->
cairo-gl && xlib

We have usually a statically wireframe loaded, changed in small pieces and
almost moved or zoomed.
And those operations are easy to do doing operations with transformation
matrix :)

--
Marco
___
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 building on MacOS or just boost?

[Marco Serantoni]

Miguel,
Is a well know problem you should add to CXXFLAGS
-D__ASSERTMACROS__
error is already defined in the OSX headers otherwise.
Please look to the instructions we have already done with jerry.
http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/annotate/head:/Documentation/compiling/mac-osx.txt

If you have further problems, drop a mail here and directly to me.

--
Marco


On Sat, Sep 22, 2012 at 3:14 PM, Miguel Angel Ajo Pelayo <
miguelan...@nbee.es> wrote:

>
>Hi everybody, I'm still struggling through my ton of work, but had some
> time to learn how to setup everything to build on MacOS (including
> wxpython),
> anyway I didn't manage to get it working, compilation stops at here,
>
> Not sure if it's a mac-os compiler problem (llvm-gcc-4.2) or just a boost
> issue:
>
>
>
> Scanning dependencies of target polygon
> [ 35%] Building CXX object 3d-viewer/CMakeFiles/3d-viewer.dir/3d_aux.cpp.o
> [ 35%] Building CXX object
> polygon/CMakeFiles/polygon.dir/math_for_graphics.cpp.o
> [ 35%] Building CXX object
> common/CMakeFiles/common.dir/dialogs/dialog_image_editor.cpp.o
> [ 35%] Building CXX object
> common/CMakeFiles/pcbcommon.dir/base_screen.cpp.o
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/3d-viewer/3d_aux.cpp:34:
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/include/wxBasePcbFrame.h:38:
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/include/base_struct.h:38:
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/include/boost/ptr_container/ptr_vector.hpp:20:
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/include/boost/ptr_container/ptr_sequence_adapter.hpp:20:
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/include/boost/ptr_container/detail/reversible_ptr_container.hpp:22:
> /Users/ajo/Documents/work/kicad/kicad/include/boost/ptr_container/detail/static_move_ptr.hpp:154:42:
> error: too many arguments provided to function-like macro
>   invocation
> void check(const static_move_ptr& ptr)
>  ^
> /Users/ajo/Documents/work/kicad/kicad/include/boost/ptr_container/detail/static_move_ptr.hpp:154:10:
> error: function definition does not declare parameters
> void check(const static_move_ptr& ptr)
>  ^
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/common/base_screen.cpp:34:
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/include/base_struct.h:38:
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/include/boost/ptr_container/ptr_vector.hpp:20:
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/include/boost/ptr_container/ptr_sequence_adapter.hpp:20:
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/include/boost/ptr_container/detail/reversible_ptr_container.hpp:22:
> /Users/ajo/Documents/work/kicad/kicad/include/boost/ptr_container/detail/static_move_ptr.hpp:154:42:
> error: too many arguments provided to function-like macro
>   invocation
> void check(const static_move_ptr& ptr)
>  ^
> /Users/ajo/Documents/work/kicad/kicad/include/boost/ptr_container/detail/static_move_ptr.hpp:154:10:
> error: function definition does not declare parameters
> void check(const static_move_ptr& ptr)
>  ^
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/common/dialogs/dialog_image_editor.cpp:32:
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/include/class_bitmap_base.h:34:
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/include/sch_item_struct.h:34:
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/include/class_base_screen.h:34:
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/include/base_struct.h:38:
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/include/boost/ptr_container/ptr_vector.hpp:20:
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/include/boost/ptr_container/ptr_sequence_adapter.hpp:20:
> In file included from
> /Users/ajo/Documents/work/kicad/kicad/include/boost/ptr_container/detail/reversible_ptr_container.hpp:22:
> /Users/ajo/Documents/work/kicad/kicad/include/boost/ptr_container/detail/static_move_ptr.hpp:154:42:
> error: too many arguments provided to function-like macro
>   invocation
> void check(const static_move_ptr& ptr)
>  ^
> /Users/ajo/Documents/work/kicad/kicad/include/boost/ptr_container/detail/static_move_ptr.hpp:154:10:
> error: function definition does not declare parameters
> void check(const static_move_ptr& ptr)
>  ^
> 2 errors generated.
> make[2]: *** [common/CMakeFiles/pcbcommon.dir/base_screen.cpp.o] Error 1
> make[1]: *** [common/CMakeFiles/pcbcommon.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs
> 2 errors generated.
> [ 35%] make[2]: ***
> [common/CMakeFiles/common.dir/dialogs/dialog_image_editor.cpp

[Kicad-developers] Revision 3817 - netlist read and setvbuf

[Marco Serantoni]

I wish to discuss about my patch #3817, that comes to me from some
signalations of problems in cvpcb and i've applied that is a probably a
dirt workaround for a more deep problem that i wish to describe.

The code parsing the netlist does more or less this:

[Reads the header to identify the netlist type]
[Rewind the stream]
[Creates a FILE_LINE_READER]
> calls setvbuf
[Proceed to parse the file]

Brian Woodcox, the person that has signalated to me the problem in cvpcb,
has also hinted to me that reading the documentation, the setvbuf call
should be not used after calls:
http://www.cplusplus.com/reference/cstdio/setvbuf/.
That seems that doesn't create problems in Linux/Windows with their current
implementation but being formal this could be spot as an error.

So I personally think that my "dirty hack" could be collapsed for all
platforms, do you agree ?

Waiting for your feedbacks,

--
Marco
___
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] Revision 3817 - netlist read and setvbuf

[Marco Serantoni]

On 27/nov/2012, at 15:29, Dick Hollenbeck wrote:

Dick,
Sadly it doesn't work, i'll just revert to the old code and add an #ifndef to 
exclude the setvbuff call.
Cleaner and simpler :)

Marco


> 
>> I know Dick, is "dirty" for this reason, but knowing that the problem is 
>> more systemic
>> i've preferred have a leak than a non working suite.
>> 
>> I will wait :)
>> 
>> --
>> Marco
> 
> 
> Maybe it will work now.  If you can try it for MAC now, that would be 
> appreciated.
> 
> 
>if( doOwn && ftell( aFile ) == 0L )
>{
>setvbuf( fp, NULL, _IOFBF, BUFSIZ * 8 );
>}
> 
> 
> ftell() might tell us when it's OK to toss the original buffer.
> 
> 
> 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] Revision 3817 - netlist read and setvbuf

[Marco Serantoni]

Sure Dick,
Seems that fseek returns 0L, as that is where the internal buffer points.
The setvbuff destroys the internal buffer and when is used the read call, file 
operations begins where the buffer manager has leaved the real file descriptor 
(6k ahead).

Being the read already buffered, #ifdef it out has almost no impact on 
performance.

Hoping this makes now more sense,

--
Marco


On 06/dic/2012, at 19:17, Dick Hollenbeck wrote:

> On 12/06/2012 12:03 PM, Marco Serantoni wrote:
>> On 27/nov/2012, at 15:29, Dick Hollenbeck wrote:
>> 
>> Dick,
>> Sadly it doesn't work, i'll just revert to the old code and add an #ifndef 
>> to exclude the setvbuff call.
> 
> ftell() is returning 0?
> 
> 
>> Cleaner and simpler :)
> 
> Nonsense.
> 
> 


___
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] Revision 3817 - netlist read and setvbuf

[Marco Serantoni]

On 06/dic/2012, at 20:58, Dick Hollenbeck wrote:

> On 12/06/2012 12:44 PM, Marco Serantoni wrote:
>> Sure Dick,
>> Seems that fseek returns 0L, as that is where the internal buffer points.
>> The setvbuff destroys the internal buffer and when is used the read call, 
>> file operations begins where the buffer manager has leaved the real file 
>> descriptor (6k ahead).
>> 
>> Being the read already buffered, #ifdef it out has almost no impact on 
>> performance.
>> 
>> Hoping this makes now more sense,
> 
> Yes more, but the picture is still not crystal clear. 
> 
> Does setvbuf() work under any circumstances on your OS?  If it simply never 
> works, then
> 
> {
>be sure and make it conditional in *both* FILE_LINE_READER constructors.
> 
>consider filing a bug report with your OS (glibc) maintainers.
> 
> }
> 
> The newer FILE_LINE_READER::FILE_LINE_READER( const wxString& ) will be 
> getting more and
> more use with time.
> 
Dick 

I can't file any kind of bug report because reading a netlist, the call is 
misused, in the other cases it worked.

As i've said in the first mail.

The code parsing the netlist does more or less this:

[Reads the header to identify the netlist type]
[Rewind the stream]
[Creates a FILE_LINE_READER]
> calls setvbuf 
[Proceed to parse the file]

And the documentation about the call explicitly says:
"This function should be called once the stream has been associated with an 
open file, but before any input or output operation is performed with it." 
" The setvbuf function may only be used after opening a stream and before any 
other operations have been performed on it."

Ref:
http://linux.about.com/library/cmd/blcmdl3_setvbuf.htm
http://www.cplusplus.com/reference/cstdio/setvbuf/

And sadly is called after having identified the netlist kind (reads + rewind).

Marco___
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] Fwd: OSX Support for EESchema (still?) experimental?

[Marco Serantoni]

Begin forwarded message:

> From: Marco Serantoni 
> Subject: Re: [Kicad-developers] OSX Support for EESchema (still?) 
> experimental?
> Date: 10 maggio 2013 18:48:13 GMT+02:00
> To: Travis Ayres 
> 
> I was thinking i was on the ML, is not a problem if i forward ?
> Just to avoid to have to response again in the future..
> 
> 
> On 10/mag/2013, at 10:41, Marco Serantoni wrote:
> 
>> This is not the problem,
>> you are looking for bitmap2component application, not the main applications.
>> The issue show-up in the PCBNEW mainly and is due the implementation of 
>> wx-widgets and kicad draw code.
>> I wish to work on it as soon as possible and compatible with my time, when 
>> i'll have a working and cleaver idea on which strategy pick i'll apply it in 
>> the stable and testing.
>> 
>> 
>> --
>> Marco
>> 
>> 
>> On Fri, May 10, 2013 at 7:31 AM, Travis Ayres  wrote:
>> Marco-
>> 
>> I grep'd the source for wxClientDC, in /bitmap2component/bitmap2cmp_gui.cpp 
>> I find:
>> #ifdef __WXMAC__
>> // Otherwise fails due: using wxPaintDC without being in a native paint 
>> event
>> wxClientDC pict_dc( m_InitialPicturePanel );
>> wxClientDC greyscale_dc( m_GreyscalePicturePanel );
>> wxClientDC nb_dc( m_BNPicturePanel );
>> 
>> I am not sure why this is defined differently and why it fails due to using 
>> wxPaintDC without being in a native paint event - I wonder if anyone wrote 
>> more notes as to why this comment is written into the source here?
>> 
>> I'll keep looking at it; let me know what you come up with!
>> 
>> 
>> On Thu, May 9, 2013 at 1:58 AM, Marco Serantoni  
>> wrote:
>> Travis, 
>> The OSX version still have one hard issue with the wxwidgets implementation, 
>> that showstops IMHO the "RELEASE" grade, but i think that is more than 
>> usable.
>> 
>> The issue is caused due the modal windows and their interaction with the 
>> application and leading as crash.
>> 
>> The error is: "Unlocking Focus on wrong view (), 
>> expected "
>> 
>> And is long time filed as: 
>> http://trac.wxwidgets.org/ticket/14389
>> 
>> I'm thinking how to solve this puzzle, once was resolved i think that OSX 
>> can be trusted a other platforms as for production grade.
>> 
>> --
>> Marco
>> 
>> 
>> On Tue, Apr 30, 2013 at 8:03 AM, Travis Ayres  wrote:
>> The reference manual @ 
>> http://www.kicad-pcb.org/download/attachments/1212538/eeschema.pdf
>> says that OSX support for EESchema is still experimental. Is this correct? 
>> It hasn't been updated in a while (or I'm looking at the old one 
>> accidentally?)
>> 
>> Thanks all!
>> 
>> ___
>> 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 look (the icon situation)

[Marco Serantoni]

I agree with Jean Pierre,
In OSX you need to have high rescalable icons (ICNS), is requested to
provide (application) icons starting from 512px passing by 256, 128, 32 and
16 pxs and is important have a good Alpha Channel, i prefer have SVG
masters to do this operations.


--
Marco


On Tue, Oct 29, 2013 at 9:46 AM, jp charras  wrote:

> Le 25/10/2013 14:08, Fabrizio Tappero a écrit :
> > Dear Jean-Pierre,
> > I agree, updating documentation is such a pain when icons change and I
> > actually remember spending a long time on it. That is why I actually
> > let 2 years pass. I think 26px icons changed and improved a lot how
> > KiCad looks.
> >
> > The thing is that from a graphical point of view the current KiCad
> > icons are a little bit a mishmash of colors and styles, I think it
> > would be good to make them belong to the same theme. More or less the
> > same thing was done with Tango icons for Linux.
> >
> > Original Icons are vector-based SVG icons but unfortunately that does
> > not mean that they can be resized on any resolution. when you do a svg
> > to 26px png conversion and the svg icon has a vertical line that is
> > larger than 1/26 the width of the svg icon the result is a fuzzy
> > vertical line. This is a very well known problem in the graphic design
> > world and re-touching manually the PNG is always a must.
>
> I know that.
> However I am still thinking using vector-based SVG icons is better than
> using fixed bitmap icons.
>
> Most of time we have to choose between disadvantages, not advantages.
>
> And for me, to be able to easily change the icon size is a bigger
> advantage than having good vertical lines.
> (In fact, SVG icons are not so bad)
> And sometimes you have to create a set of 16,32,64 ... bitmaps of the
> same icon.
> I also am thinking modifying SVG icons with inkscape is (by far) more
> easier than modifying bitmaps icons
>
> I am also pretty sure many icons used in Linux world are most of time
> created in svg format (see
> http://openiconlibrary.sourceforge.net/downloads.html, full package)
> Using only bitmap icons come from Windows world, not from Unix world
>
> >
> > In the work for KiCad I did adjust each of the 460 icons but I have
> > not really done a great job because of the limited time (=large number
> > of icons). So some icons need to be fixed. However, what I cannot
> > really do is to maintain 460 icons, that is why I proposed to drop the
> > drop down menu ones.
>
> I fully understand 460 icons to maintain is a lot of work.
> Thanks you for the great work you did.
>
> But like you said only some icons need to be fixed, not 460!.
> Most of them are quite good, therefore no need to recreate all icons:
> Recreating *all* icons, when most of them are good is just wasting you
> time.
>
> Of course, enhancing some icons (the bad ones) is good.
>
> >
> > So here we have two problems: 1) some icons are fuzzy, 2) many icons
> > are a mishmash of styles. Fixing both is hard but possible and would
> > give to KiCad was it is often perceived as a professional looking
> > software tool (like gEDA for instance)
>
> I agree: I would like to see these fuzzy icons, and mismatch style fixed.
>
> But I really thinking most of icons are quite good.
>
> Still believe me:
> A professional looking software tool needs to have some icons in dialogs
> which explains the purpose or the effect of some options
> (in dialog zone for instance to show thermal reliefs, and many other
> dialogs).
> Have a look to Pcb Calculator and its Transline dialog:
> without icons, it is not usable.
>
> A professional looking software tool needs this kind of icons:
> This is more important than recreate all icons in toolbars.
>
> >
> > To ease this transition I am offering to update some of the English
> > documentation too. I would ask the people who appear as maintainers of
> > the various non English docs to take care of their portion.
> Thanks.
>
> For icons which are enhanced, if the new look is not very different from
> the old one, doc does not always require to be updated.
> Update is needed when icons are fully different.
>
> >
> > Regarding the icons in the drop-down menus, I of course see the
> > advantage of having additional info next to the menu item. I am a
> > great fan of it but if you like it to be done, it is necessary to do
> > it as it is normally done, for instance, in inkscape, see attachment.
> > icons in the drop down menues are smaller.
>
> I am fan of icons in menus. In many case they help (see mirror/rotate
> commands for instance).
>
> But I do not understand the meaning of "it is necessary to do
>  it as it is normally done".
> Smaller icon sizes in menus is only a convenient way to have smaller
> menus (16x16 icon is roughly the size of a letter and its margins).
> Until now I never read anything about the best icon size in menus, there
> is also not a better size for fonts: the better size is the size you
> like and it depends on you screen size, and how old you are (

[Kicad-developers] [MACOSX] OSX Port status

[Marco Serantoni]

As usual in those times i release of the OSX port, I’m shipping in this moment 
the STABLE tree for ppc, i386 and x86_64 that should have resolved some issues.

Going to the Testing tree and the state of the Art,I’ve seen the improvements, 
really a great job  and I wish have some feedbacks from you.

In the last releases of OSX there was a switch of compiler, we have passed from 
gcc to llvm and at the same time there was the switch from stdlibc++ to libc++: 
to maintain the compatibility with old release of OSX and with wx-widgets we 
stick on stdlibc++ (solved with -mmacosx-version-min=10.5) 
I’ve seen the GAL, nice job folks.
Besides this takes with it dependencies to a couple of libraries (cairo and 
GLEW) that adds complexity for the Release since aren’t shipped with OSX, i 
wish to know if is scheduled to add those in the tree (like was done with 
boost) allowing it be added statically.
I need to avoid users the need compile themselves those libraries.
Since i’m looking to experiment kicad’s build for iphone/ipad and probably will 
be nice and forecastable add also other tablets os-ports, i wish have GAL 
options selectable by cmake.
I’ve got some crashes with wx-widgets  3.0/trunk, the issue is well described 
in http://forums.wxwidgets.org/viewtopic.php?f=1&t=38482
At the moment i’ve resolved with some hacks i’m studying how to fix those the 
cleanest way.
Unicode related, some parts relies on the conversion wxString -> wxChar * -> ( 
char * ), not more true in wx-widgets 3.0/trunk llvm says:
candidate function not viable: no known conversion from 'wxString' to 'const 
wxChar *' (aka 'const wchar_t *’)
I think we wish overload those functions or someone has better 
approach to the issue ?

I’ll ship some patches for OSX in those hours for the boost compiling in 
testing, solving issues and adding multi-platform compile.
I'll really appreciate your honest ideas on those points, 
--
Marco


___
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] best KiCad OS X distro - where is it?

[Marco Serantoni]

Fabrizio,
Since 2008 i maintain binaries for kicat at

http://www.mdx4.org/index.php?/categories/5-Kicad


On 07/nov/2013, at 20:08, Fabrizio Tappero  wrote:

> Hello Guys,
> some people have been asking for the OS X distribution of KiCad. Can I
> please be directed to some webpage?
> 
> thank you
> 
> 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


___
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] Bazaar revision cmake patch

[Marco Serantoni]

Nick,
I’ve listened your complain about the wrong result in version.h and therefore 
in the kicad application title when you checkout a previous revision of the 
code.
I personally found your patch functionally correct, if no one will disregard in 
the next days with your patch I think we could proceed to use it.

Thank your for your contribution,

—
Marco


On 25/dic/2013, at 01:27, Nick Østergaard  wrote:

> 
> Hello Marco
> 
> I have made a proposed patch for the revision number generated by the cmake 
> scripts. Here attached.
> 
> Background information:
> The current cmake scripts that generate the bzr revision number to be 
> displayed in the version info in kicad showed only the (HEAD) revision of the 
> repository, and not the working tree. This is not any good if one tries to 
> checkout an older version and build and then forgets what he has build.
> 
> I have modified such that it grabs the tree version, which is the version 
> checked out with bzr update -r1337 or whatever revision you are interrested 
> in.
> 
> I am new to cmake, so patch might not be ideal, but it works!
> 
> Nick Østergaard
> 


___
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] -fvisibility && OSX

[Marco Serantoni]

Sadly,
Despite was a great idea use -fvisibility the llvm compiler seems doesn’t like 
this option.
So i’ve to disable it, sorry Dick was as good idea.


ld: bad codegen, pointer diff in ___cxx_global_var_init19 to global weak symbol 
__ZN8wxStringD1Ev for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [eeschema/eeschema.app/Contents/MacOS/eeschema] Error 1
make[1]: *** [eeschema/CMakeFiles/eeschema.dir/all] Error 2
make: *** [all] Error 2___
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] GIT Plugin

[Marco Serantoni]

Dick,
I was able to compile also the GIT plugin.
Now i’ve a couple of problems to show you 

* i’ve a clean machine so i have the problem to populate the Library table with 
my old legacy modules, could you implement an automatic “insert” of rows when 
it is empty using the Library Paths or add a button that makes this job ?

* Pressing the Options with a clean grid i result to a crash

—
Marco
___
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] TODO: remove this whole "if test" on or after 14-Jan-2014 and remove the system/*.s sources if no one complains by then.

[Marco Serantoni]

Dick,
I’ve to support multiple processors,I’ve just ended to spit blood implementing 
it in boost for PPC32 an PPC64 in asm to add support in boost::context. ( 
https://svn.boost.org/trac/boost/ticket/8266 ).
Now i’m building all for three platforms, then i’ll try to do a more extensive 
testing of kicad applications.
I’ll try to test and change your code if needed, but which is the problem with 
using directly boost::context ?

—
Marco___
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] Boost building as an option

[Marco Serantoni]

On 06/gen/2014, at 21:27, Maciej Sumiński  wrote
> 
> Thank you for the explanations. I expected that boost comes with KiCad to 
> make building easier for some users, but I did not even think of bugs related 
> to version of the library.
Many of the issues I had on OSX are related to to wrong compilation or choices, 
restrict and be sure about which is the library used is a nice first step to be 
able to support users.


>> Newer versions of Boost would break builds and the CMake
>> FindBoost() macro only tests for a minimum version not a specific
>> version.
> 
> It can be forced to check for specific version of the library using EXACT 
> keyword. But I can imagine it helps only a little, as usually Linux 
> distributions / Mac OS ports do not offer you a variety of versions, but the 
> most recent one that was prepared by package maintainers.
Maciej, package maintainers doesn’t do a good work as we have done I and Dick 
lately on boost, just take a look to the patches applied and the related 
tickets.
Our current boost patched release doesn’t exists already neither in the 
Development branch of boost.
The support in boost::context for OSX was almost NONE, there was a ticket 
laying there for 10 months, no option for building (i386/x86_64) no option at 
all for building PPC32/PPC64, options that now is in our repository and 
building.
The same is the support for GNU AS/MINGW on Windows.

Take a look to tickets url near the patches in the 
CMakeModules/download_boost.cmake file 

I’ll expect to see if boost 1.56 will contain those feature before moving on 
“normal distribution” channels.

Moreover i’m asking myself which is the best final distribution of kicad, i 
think that normal users will use binaries not a build from scratch, and i think 
that request normal users on the different platforms one version of library 
could be practicable with difficulties, i don’t see normal users install ports 
on OSX, additional libraries on Windows and moreover knowing well how works 
linux distributions that still have seasoned libraries on stable trees (RHAS , 
Debian Stable) and probably advance quickier on the more fast distributions 
(Fedora, Debian testing/unstable) having a large plethora of different flavour 
of configurations and releases to obfuscate tickets diagnose.

Same difficulties I will see deploying the software in an large organization 
and the interaction with systems for the configuration management.

Is this a good choice to pick ?

I build already for 2/3 platforms at once, i can understand better than all 
which are the problems/flags you are raising.

—
Marco

___
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] Net names and net codes

[Marco Serantoni]

Only the warning: keep attention that boost::context doesn't support the
context switch for the vector registers
(mmx*/v*).
If needed i can help you to implement.


--
Marco


On Mon, Jan 13, 2014 at 7:48 PM, Vesa Solonen  wrote:

> 13/01/14 10:04, Maciej Sumiński kirjoitti:
>
> > I fully support the idea, in fact I have dreamed about this too
> > (
> http://www.ohwr.org/projects/cern-kicad/wiki/ratsnest-gal#Possible-upgrades
> ).
> > I had a short try with OpenMP, but I did not get any better results, so
> > it seems that I could have done it wrong.
>
> Some articles:
> http://locklessinc.com/articles/vectorize/
> http://gcc.gnu.org/projects/tree-ssa/vectorizathttps://twiki.cern.ch
>
> https://twiki.cern.ch/twiki/bin/view/CMSPublic/WorkBookWritingAutovectorizableCode
>
> Some tools:
> http://code.entropywave.com/blog/
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk
>
> ORC may be the best tool to go with. GNU Radio's DSP stack and GStreamer
> depends on it.
>
> > If there are volunteers who have some experience with parallelization I
> > am very eager to cooperate to speed up some of computations. The
> > ratsnest algorithm is a perfect place to start with. It is performed on
> > per net basis, so they are all independent to each other.
>
> I could possibly do something, but I'm not familiar with much of the
> Kicad code. Single function "optimise this ->" might work, but delivery
> times can't be guaranteed...
>
> -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
>
___
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] Net names and net codes

[Marco Serantoni]

Nice,
But please, think before add dependencies and look deeply if those are
supported for all platforms, I wish being able to don't trash years of work.



--
Marco


On Tue, Jan 14, 2014 at 11:00 AM, Maciej Sumiński
wrote:

> Great, now it seems that we have a group of people who are experienced
> with the subject. I believe this has to end up with some speed up in KiCad.
>
> Regards,
> Orson
>
>
> On 01/14/2014 10:59 AM, Marco Serantoni wrote:
>
>> Only the warning: keep attention that boost::context doesn't support the
>> context switch for the vector registers
>> (mmx*/v*).
>> If needed i can help you to implement.
>>
>>
>> --
>> Marco
>>
>>
>> On Mon, Jan 13, 2014 at 7:48 PM, Vesa Solonen > <mailto:vesa.solo...@aalto.fi>> wrote:
>>
>> 13/01/14 10:04, Maciej Sumiński kirjoitti:
>>
>>  > I fully support the idea, in fact I have dreamed about this too
>>  >
>> (http://www.ohwr.org/projects/cern-kicad/wiki/ratsnest-gal#
>> Possible-upgrades).
>>  > I had a short try with OpenMP, but I did not get any better
>> results, so
>>  > it seems that I could have done it wrong.
>>
>> Some articles:
>> http://locklessinc.com/articles/vectorize/
>> http://gcc.gnu.org/projects/tree-ssa/vectorizathttps://twiki.cern.ch
>> https://twiki.cern.ch/twiki/bin/view/CMSPublic/
>> WorkBookWritingAutovectorizableCode
>>
>> Some tools:
>> http://code.entropywave.com/blog/
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk
>>
>> ORC may be the best tool to go with. GNU Radio's DSP stack and
>> GStreamer
>> depends on it.
>>
>>  > If there are volunteers who have some experience with
>> parallelization I
>>  > am very eager to cooperate to speed up some of computations. The
>>  > ratsnest algorithm is a perfect place to start with. It is
>> performed on
>>  > per net basis, so they are all independent to each other.
>>
>> I could possibly do something, but I'm not familiar with much of the
>> Kicad code. Single function "optimise this ->" might work, but
>> delivery
>> times can't be guaranteed...
>>
>> -Vesa
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> <mailto: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] Python&QA vs OSX ...

[Marco Serantoni]

Sorry, I forgot to reply to all

Miguel,
As you can see i've committed the part to make possibile the linking of Kicad 
also with dynamic linking and making binaries portable 
(scripts/osx_fixbundle.sh )
I'm in those days working on wxPython, i'm confident to release a similar 
mechanism for Python by the end of this month with a minimal set of patches.

—
Marco


On 02/feb/2014, at 23:26, Miguel Angel  wrote:

> 
>  As far as I know, at this moment, Marco keeps working on the platform, 
> to keep building possible, and easier, and Adam Wolf has plans to work on the 
> automated dmg build... that will be awesome.
> 
>  I retreat, I know OSX is a platform with a lot of users, and they seem 
> to like KiCad, but... it only made my time as a developer miserable, I didn't 
> enjoy it too much, because every time I wanted to go on on the python part, 
> or QA, or anything, I had to fight again and again with a platform that it 
> was new to me ...  If I had more available time, that wouldn't be a problem 
> (I suppose) because I could do both things.., but I feel my python part has a 
> long way ahead and I want to use my available time on that.
> 
> That being said, I hope that we'll have more volunteers to help with 
> KiCad/OSX, I've seen a lot of collaboration on github (kicadosxbuilder) which 
> I'm donating to the community... I asked all contributors and they seem to 
> agree that this code is good as GPL.


___
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] Python&QA vs OSX ...

[Marco Serantoni]

No,
Python is already on the OS, wxPython will be build from sources directly
from Cmake.
After that adding features will be easy, and in the meanwhile we will have
a common bases on which we can do support on.
I'm studing the "packaging" at the moment and some modifies to do, then
i'll add patches and do some tests on different architectures/Universal and
versions.
Let me end this part, anyway i don't think there will be great issues, will
be only adding/set in the enviroment variables some PYTHONPATH directly
from the executables, just standardize them.



--
Marco


On Wed, Feb 5, 2014 at 7:38 AM, Miguel Angel  wrote:

> Wow, good good Marco!,
>
>Having our own python build looks interesting to overcome the OSX
> version problems with python.
>
>The bad point of having our own python is that we stop from having the
> python community libraries
> (I guess) probably it's a matter of including easy_python or pip in the
> build in the future. Anyway I believe
> it's a good thing, having the same as Brian built for windows.
>
>
>Good work! :)
>
>
> ---
> irc: ajo / mangelajo
> Miguel Angel Ajo Pelayo
> +34 636 52 25 69
> skype: ajoajoajo
>
>
> 2014-02-05 Marco Serantoni :
>
> Sorry, I forgot to reply to all
>>
>> Miguel,
>> As you can see i've committed the part to make possibile the linking of
>> Kicad also with dynamic linking and making binaries portable
>> (scripts/osx_fixbundle.sh )
>> I'm in those days working on wxPython, i'm confident to release a similar
>> mechanism for Python by the end of this month with a minimal set of patches.
>>
>> --
>> Marco
>>
>>
>> On 02/feb/2014, at 23:26, Miguel Angel  wrote:
>>
>> >
>> >  As far as I know, at this moment, Marco keeps working on the
>> platform, to keep building possible, and easier, and Adam Wolf has plans to
>> work on the automated dmg build... that will be awesome.
>> >
>> >  I retreat, I know OSX is a platform with a lot of users, and they
>> seem to like KiCad, but... it only made my time as a developer miserable, I
>> didn't enjoy it too much, because every time I wanted to go on on the
>> python part, or QA, or anything, I had to fight again and again with a
>> platform that it was new to me ...  If I had more available time, that
>> wouldn't be a problem (I suppose) because I could do both things.., but I
>> feel my python part has a long way ahead and I want to use my available
>> time on that.
>> >
>> > That being said, I hope that we'll have more volunteers to help
>> with KiCad/OSX, I've seen a lot of collaboration on github
>> (kicadosxbuilder) which I'm donating to the community... I asked all
>> contributors and they seem to agree that this code is good as GPL.
>>
>>
>
___
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] patch: new KiCad icons

[Marco Serantoni]

Fabrizio,
Nice set, they looks much cleaver than older ones.


--
Marco


On Thu, Feb 6, 2014 at 12:17 AM, Fabrizio Tappero <
fabrizio.tapp...@gmail.com> wrote:

> Dear Jean-Pierre,
> since I believe you have not yet committed my previous icon patch, please
> neglect it and used instead this new set. I have added few new ones.
>
> Also, please commit this patch as soon as you can otherwise I will not
> stop modifying  them and produce new ones over and over for ever !!
>
> thank you
> 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
>
>
___
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] Patch: don't hardcode wxPython path

[Marco Serantoni]

Sorry,
Was mine error.

There was a long work full of pitfalls, all those libraries and the related 
libraries are needed by OSX to let him carry the external libraries
not provided to OS into the executable bundle and make it self-contained.

This is not required on other platforms, but was left generic to be adaptee, if 
needed, by other platforms.

Mine apologies and Thanks Jean Pierre for the quick fix.

—
Marco



On 08/feb/2014, at 07:35, Blair Bonnett  wrote:

> The recent addition of CMakeModules/download_wxpython.cmake has resulted in 
> build failures. The main cause is the fact the --prefix option passed to the 
> configure script of wxPython is hardcoded to 
> /Users/marco/Development/product/libwxpython_root. The attached patch 
> replaces that with the appropriate CMake variable, ${LIBWXPYTHON_ROOT}. This 
> fixes the build for me.
> 
> The additional system dependencies for this also need to be documented. On 
> Ubuntu 13.04, I needed to install the libgstreamer-plugins-base0.10-dev 
> package to get a pkg-config file so the wxPython build could find the system 
> install of gstreamer; this is a required dependency for the build to succeed.
> 
> To the limited extent of my testing, KiCad had been compiling fine with the 
> system copies of wxPython and swig. Is there now a need for this to be built 
> locally in all cases, or can it be dependent on the OS or some other set of 
> conditions?
> 
> Regards,
> Blair
> ___
> 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] Recent dependencies break builds.

[Marco Serantoni]

Sorry Wayne,
I apologize with you, wasn’t mine intention put dependencies on other platforms 
nor change
the way other developers and other platforms wants to build their binaries.

This was an huge work propedeutic to others work, intentions are to take enough 
advantage to fix it and have the timeslot needed to face current and be ready 
for future changes.
Tackling 3 processors archs, 3 version of OS, two compilers and two kind of 
binaries with their dependencies lib and fixing some their building systems has 
let me lost the focus on some parts, i’ll wish anyway to fix definitely those 
issues soon to minimize issues.


Trying to be understood in intentions, I come in Peace,
—
Marco






On 07/feb/2014, at 23:38, Wayne Stambaugh  wrote:

> Please use find_package() first and then if you need to download the
> dependency source and build the dependency.  Some developers (me) prefer
> to build project dependencies outside of KiCad source.  That way when I
> do a make clean, I don't have to rebuild all of the dependencies as
> well.  The only exception to this is to patch a bug that effects KiCad
> like we have to do with Boost.  If it's a build fix only patch, always
> use find_package() first.  I believe this was added to resolve OSX build
> issues.  If this is an OSX only issue, please qualify this with a
> platform check so as not to break building on other platforms.
> 
> Thanks,
> 
> Wayne
> 
> ___
> 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] Recent dependencies break builds.

[Marco Serantoni]

On 08/feb/2014, at 13:57, Wayne Stambaugh  wrote:
> Marco,
> 
> Not a problem.  Please keep in mind that downloading and building
> dependencies like wxPython or swig from source should be the last option
> even on OSX.  Always use find_package() first to see if it is already
> installed on the system and only if it can not be found should you build
> a dependency from source.  This saves a huge amount of time when the
> dependency is already installed on the system.  There is no
> FindwxPython.cmake that I'm aware of but someone should write one.
> Wayne

Wayne, 
I’ve tried to do that, but was not a viable way, (is the reason why building 
with wxPython and swig is 
a two-step operation) first enable *BUILD*, make the library, then set the 
*SCRIPTING* flag and ultimate the code.

Now, about always use find_package(), i think we have to understood which is 
the goal, 
your is understate that kicad’s distribution path is compile, i mine in this 
case was binary.
Download the package and make (after have installed the library obviously).
That I think is the easier way to distribute and make users “operative” soon on 
my platform,
without have users hassle with difference of installed libraries/dependancies.

This also because OSX has not a package manager like yum, apt-get, rpm or pacman
and i wish avoid users to have to fight/manage with something like ports, that 
could be 
an obstacle for someone that is not a poweruser, or works on corporate machines 
where
privileges are limited.
On the other side, OSX has already some libraries installed by default and 
different versions
of them, i forced a version python-2.6 for example because i know that is 
spread on the machine 
already running, lately OSX has also 2.7 by default but this could break 
backwards compatibility.

When i force build libraries, is because those are missing, or doesn’t need the 
requirements to
make kicad work correctly (wx-* for example).
OSX has for example wx-2.8 that is nor patched for native overlay, that is 
known to be a common pitfall 
for much new adopting people that wants to build from scratch,
i wish avoid this frustration and try to avoid abandon from those 
potential-(user/developer)base.
This helps also me to avoid to understand which library he has used and all the 
triage when there is 
an issue/ticket.

**ANYWAY**
The work i made was thinked to be usable by other platforms, if you have ideas
about change it and make it adaptable for your platform you are more than 
welcome,
the cmake code i’ve kept it more neutral I can, with the intent to have 
something that could be shared/reused
between platforms otherwise i’ve shipped that by another path.
If you all agree that is not needed i could change the flag name KICAD_ in 
something more linked to OSX like
KICAD_OSX* or OSX_BUILD_* to avoid confusion.

—
Marco
___
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] Moving field-texts with connecting line to component; potential patch

[Marco Serantoni]

>  -  In other places in the code that has to do with redraws, there is
> some special handling with the USE_WX_OVERLAY macro. I can't really
> test this properly in my installation of wxWidgets, so I don't know if
> I always do what would be needed in this case.
> 

Henner, 
This is my code, for OSX, Mac having a vectorial GUI interface, doesn’t have 
graphical logical operations.
so i managed to use Native Overlay to “cleanup”, i don’t know this way is 
viable for other platforms,
but is the ONLY way we could manage “immediate” changes with the current 
drawing code.

When a tool is selected, the object is flagged in “MOVE” so not drawn in the 
first refresh that will be keeped.
All moves and “immediate” operations are drawn on the overlay that is erased 
each time.
When operation ends, there will be a refresh that will shown the ending result.

If you patch, just remember to honor the ERASE flag when erasing with XOR, the 
rest should be managed:
Overlay code will do the rest.

—
Marco
___
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] PATCH: making component choosing (much!) more usable

[Marco Serantoni]

Nice work, really :)

--
Marco


On Thu, Feb 20, 2014 at 6:06 AM, Henner Zeller  wrote:

> On 19 February 2014 17:30, Kaspar Emanuel 
> wrote:
> > Thanks for this patch! I was working on a new schematic all day today
> > using the new dialogue and it felt super snappy. A joy to use!
>
> Thanks for the kind feedback. This is why I like open source software,
> win/win for everybody: it is possible to add little improvement ideas
> to already awesome software. The rest is just a bit of writing it down
> in code and a patch .. and the maintainers finding it useful enough to
> include. And positive feedback like yours keeps things going. Thanks.
>
> -h
>
> ___
> 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] Wxpython configuration options

[Marco Serantoni]

Adam,
Perfect, your build is done correctly.
wxwidgets is build directly by wxpython the wxOverlay patch is already
included.

Which is your need and why you wish to change the configuration ?

--
Marco



--
Marco


On Wed, Feb 26, 2014 at 5:03 AM, Adam Wolf wrote:

> Hi folks,
>
> Working on incorporating Marco's latest changes into the KicadOSXBuilder
> script so we have a working script for Mac like we do for Linux, and I'm
> running into an issue that I don't quite have the cmake skills for.
>
> Basically, right now, I'm doing
> cmake -DKICAD_BUILD_DYNAMIC=ON .
> make swig
> cmake -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_WXPYTHON=ON .
> make
>
> When doing the last make, it pulls in wxpython, which pulls in wxwidgets.
>  I am trying to pass another configuration option to wxwidgets (when pulled
> in by wxpython).  I figure it should be somewhere in download_wxpython.py,
> but I can't see how to do it.
>
> Do I need to patch wxpython?
>
> Thanks folks!
>
> Adam Wolf
> Wayne and Layne, LLC
>
> ___
> 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] Wxpython configuration options

[Marco Serantoni]

Is an known issue, i've fighted with it on IRC with an user, seems that
configure detects lzma.h from homebrew but is unable to use it.
Doesn't happens with a clean machine.
Seems that it founds in the path the executable but is unable to "find" the
libraries or something like that.

Could you open a ticked adding config.log ?
We have to investigate if is an homebrew issue or wx-widgets issue.
This happens also without wxPython support, building wx-widgets.

--
Marco


On Wed, Feb 26, 2014 at 5:09 PM, Adam Wolf wrote:

> Right now, I'm having an issue with libtiff and lzma.h.  Wxwidgets's
> configure says it finds everything it needs, but when it goes to build, it
> can't find my lzma.h.
>
> This is on a 10.9 machine, relatively vanilla, with homebrew.
>
> Adam Wolf
> Wayne and Layne LLC
> On Feb 26, 2014 9:13 AM, "Marco Serantoni" 
> wrote:
>
>> Adam,
>> Perfect, your build is done correctly.
>> wxwidgets is build directly by wxpython the wxOverlay patch is already
>> included.
>>
>> Which is your need and why you wish to change the configuration ?
>>
>> --
>> Marco
>>
>>
>>
>> --
>> Marco
>>
>>
>> On Wed, Feb 26, 2014 at 5:03 AM, Adam Wolf > > wrote:
>>
>>> Hi folks,
>>>
>>> Working on incorporating Marco's latest changes into the KicadOSXBuilder
>>> script so we have a working script for Mac like we do for Linux, and I'm
>>> running into an issue that I don't quite have the cmake skills for.
>>>
>>> Basically, right now, I'm doing
>>> cmake -DKICAD_BUILD_DYNAMIC=ON .
>>> make swig
>>> cmake -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_WXPYTHON=ON .
>>> make
>>>
>>> When doing the last make, it pulls in wxpython, which pulls in
>>> wxwidgets.  I am trying to pass another configuration option to wxwidgets
>>> (when pulled in by wxpython).  I figure it should be somewhere in
>>> download_wxpython.py, but I can't see how to do it.
>>>
>>> Do I need to patch wxpython?
>>>
>>> Thanks folks!
>>>
>>> Adam Wolf
>>> Wayne and Layne, LLC
>>>
>>> ___
>>> 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] isn't KiCad doing pretty bloody well?

[Marco Serantoni]

Nobody has noticed that ohloh.net was pointing to old testing and not
product ? ;)

--
Marco


On Mon, Feb 24, 2014 at 9:02 AM, Lorenzo Marcantonio <
l.marcanto...@logossrl.com> wrote:

> On Sun, Feb 23, 2014 at 11:59:10PM +0100, Fabrizio Tappero wrote:
> > I would like to share with you a very recent ohloh.net activity report
> that
> > can give use an idea of how well KiCad is doing.
>
> Uh what are "Y-O-Y commits"? Some kind of metric?
>
> Anyway, other than code metrics is (IMHO) more important the number of
> boards done and the average number of f*cks thrown for board (<-
> subjective index of software quality :D)
>
> With an average of one board every month I'd say I'm quite content. For
> mixed signal and power work; probably people doing cutting edge digital
> circuitry would be disappointed, especially if HDI boards were needed.
>
> Of course it's difficult to beat the price tag :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
>
___
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] Fail to build wxpython on OS X Maverick

[Marco Serantoni]

I’m Working on it.
Recently there was a compiler update (two days ago), 
And it becomes a lot more choosy and restrictive and affects a lot of projects.

please execute before the building:
export CPPFLAGS="-Qunused-arguments"

clang: error: unknown argument: '-mno-fused-madd' 
[-Wunused-command-line-argument-hard-error-in-future]
^^^ it becomed NOW :)

Clang seems refuse gcc arguments.

I’ll fix really soon, i hope.


—
MArco


On 13/mar/2014, at 20:51, Adam Wolf  wrote:

> My last automated Mac buiild was 4732.  I will rerun and let you know in a 
> few hours, Jean-Paul.
> 
> Adam Wolf
> Wayne and Layne, LLC
> 
> 
> On Thu, Mar 13, 2014 at 2:36 PM, Jean-Paul Louis  wrote:
> Hello all,
> 
> Last build I tried was BZR4729, and went fine.
> 
> Today, I try again with the 4745
> 
> cd ~/Soft_Dev
> bzr branch lp:kicad
> mv kicad/ kicad-BZR4745
> cd kicad-BZR4745
> cmake -DKICAD_BUILD_DYNAMIC=ON
> make swig
> cmake -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_WXPYTHON=ON
> make
> 
> Now, make is failing when building wxPython (see below)
> What am I doing wrong? I would like to fix this, and get back to my build.
> The only difference that I can think of is that I installed Homebrew, but I 
> have not used it yet
> as I got a warning about issues with MacPorts.
> 
> 
> Jean-Paul (AC9GH)
> 
> 
> Jean-Pauls-MacBook-Pro:kicad-BZR4745 jean-paullouis$ make
> [  4%] Built target boost
> [  4%] Built target pixman
> [  4%] Built target pkgconfig
> [  4%] Built target libpng
> [  4%] Built target cairo
> [  4%] Built target glew
> [  4%] Performing configure step for 'libwxpython'
> old_options = 
> set(['--wxpy_installdir=/Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root/wxPython',
>  '--unicode', '--osx_cocoa', 
> '--prefix=/Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root', 
> '--install'])
> sys.argv = 
> ['--prefix=/Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root', 
> '--unicode', '--install', 
> '--wxpy_installdir=/Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root/wxPython',
>  '--osx_cocoa']
> wxWidgets directory is: 
> /Users/jean-paullouis/Soft_Dev/kicad-BZR4745/.downloads-by-cmake/libwxpython/src/libwxpython
> wxWidgets build options: ['--wxpython', '--jobs=8', 
> '--prefix=/Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root', 
> '--unicode', '--no_config', '--osx_cocoa', '--installdir=', '--install', 
> '--builddir=/Users/jean-paullouis/Soft_Dev/kicad-BZR4745/.downloads-by-cmake/libwxpython/src/libwxpython/wxpy-bld/cocoa']
> Configure options: ['--enable-unicode', '--with-osx_cocoa', 
> '--prefix=/Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root', 
> '--with-opengl', '--enable-sound', '--enable-graphics_ctx', 
> '--enable-mediactrl', '--enable-display', '--enable-geometry', 
> '--enable-debug_flag', '--enable-optimise', '--disable-debugreport', 
> '--enable-uiactionsim', '--enable-monolithic', 
> '--with-macosx-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk']
> /usr/bin/make
> make --jobs=8
> /usr/bin/make
> make install
>  
>  --
>  
>  The installation of wxWidgets is finished.  On certain
>  platforms (e.g. Linux) you'll now have to run ldconfig
>  if you installed a shared library and also modify the
>  LD_LIBRARY_PATH (or equivalent) environment variable.
>  
>  wxWidgets comes with no guarantees and doesn't claim
>  to be suitable for any purpose.
>  
>  Read the wxWindows Licence on licencing conditions.
>  
>  --
>  
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> DESTDIR: 
> PREFIX: /Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root
> wxlocation: /Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root
> wxcfg: 
> /Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root/bin/wx-config
> wxcfgsrc: 
> /Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root/lib/wx/config/osx_cocoa-unicode-3.0
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  /usr/bin/python2.6 -u ./setup.py build UNICODE=1 WXPORT=osx_cocoa 
> BUILD_BASE=build/cocoa 
> WX_CONFIG="/Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root/bin/wx-config
>  --prefix=/Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root" 
> WARNING: WXWIN not set in environment. Assuming '..'
> Preparing CORE...
> Preparing STC...
> Preparing GLCANVAS...
> Preparing GIZMOS...
> running build
> running build_py
> running build
> running build_py
> copying wx/__version__.py -> build/cocoa/lib.macosx-10.9-intel-2.6/wx
> copying wx/build/build_options.py -> 
> build/cocoa/lib.macosx-10.9-intel-2.6/wx/build
> package init file 'wx/tools/XRCed/plugins/__init__.py' not found (or not a 
> regular file)
> package init file 'wx/tools/XRCed/plugins/__init__.py' not found (or not a 
> regular file)
> running build_ext
> building '_core_' extension
> gcc -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platfo

Re: [Kicad-developers] Fail to build wxpython on OS X Maverick

[Marco Serantoni]

Just committed fixes needed.
Now it should build again.

Thanks also to Maciej for the quick support today.

—
Marco


On 14/mar/2014, at 01:46, Adam Wolf  wrote:

> I can confirm on an OS X system that hasn't done updates in 1 week that it 
> builds the latest revno just fine.
> 
> Adam Wolf
> W&L
> 
> 
> On Thu, Mar 13, 2014 at 6:31 PM, Marco Serantoni  
> wrote:
> I’m Working on it.
> Recently there was a compiler update (two days ago), 
> And it becomes a lot more choosy and restrictive and affects a lot of 
> projects.
> 
> please execute before the building:
> export CPPFLAGS="-Qunused-arguments"
> 
> clang: error: unknown argument: '-mno-fused-madd' 
> [-Wunused-command-line-argument-hard-error-in-future]
> ^^^ it becomed NOW :)
> 
> Clang seems refuse gcc arguments.
> 
> I’ll fix really soon, i hope.
> 
> 
> —
> MArco
> 
> 
> On 13/mar/2014, at 20:51, Adam Wolf  wrote:
> 
>> My last automated Mac buiild was 4732.  I will rerun and let you know in a 
>> few hours, Jean-Paul.
>> 
>> Adam Wolf
>> Wayne and Layne, LLC
>> 
>> 
>> On Thu, Mar 13, 2014 at 2:36 PM, Jean-Paul Louis  wrote:
>> Hello all,
>> 
>> Last build I tried was BZR4729, and went fine.
>> 
>> Today, I try again with the 4745
>> 
>> cd ~/Soft_Dev
>> bzr branch lp:kicad
>> mv kicad/ kicad-BZR4745
>> cd kicad-BZR4745
>> cmake -DKICAD_BUILD_DYNAMIC=ON
>> make swig
>> cmake -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_WXPYTHON=ON
>> make
>> 
>> Now, make is failing when building wxPython (see below)
>> What am I doing wrong? I would like to fix this, and get back to my build.
>> The only difference that I can think of is that I installed Homebrew, but I 
>> have not used it yet
>> as I got a warning about issues with MacPorts.
>> 
>> 
>> Jean-Paul (AC9GH)
>> 
>> 
>> Jean-Pauls-MacBook-Pro:kicad-BZR4745 jean-paullouis$ make
>> [  4%] Built target boost
>> [  4%] Built target pixman
>> [  4%] Built target pkgconfig
>> [  4%] Built target libpng
>> [  4%] Built target cairo
>> [  4%] Built target glew
>> [  4%] Performing configure step for 'libwxpython'
>> old_options = 
>> set(['--wxpy_installdir=/Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root/wxPython',
>>  '--unicode', '--osx_cocoa', 
>> '--prefix=/Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root', 
>> '--install'])
>> sys.argv = 
>> ['--prefix=/Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root', 
>> '--unicode', '--install', 
>> '--wxpy_installdir=/Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root/wxPython',
>>  '--osx_cocoa']
>> wxWidgets directory is: 
>> /Users/jean-paullouis/Soft_Dev/kicad-BZR4745/.downloads-by-cmake/libwxpython/src/libwxpython
>> wxWidgets build options: ['--wxpython', '--jobs=8', 
>> '--prefix=/Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root', 
>> '--unicode', '--no_config', '--osx_cocoa', '--installdir=', '--install', 
>> '--builddir=/Users/jean-paullouis/Soft_Dev/kicad-BZR4745/.downloads-by-cmake/libwxpython/src/libwxpython/wxpy-bld/cocoa']
>> Configure options: ['--enable-unicode', '--with-osx_cocoa', 
>> '--prefix=/Users/jean-paullouis/Soft_Dev/kicad-BZR4745/libwxpython_root', 
>> '--with-opengl', '--enable-sound', '--enable-graphics_ctx', 
>> '--enable-mediactrl', '--enable-display', '--enable-geometry', 
>> '--enable-debug_flag', '--enable-optimise', '--disable-debugreport', 
>> '--enable-uiactionsim', '--enable-monolithic', 
>> '--with-macosx-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk']
>> /usr/bin/make
>> make --jobs=8
>> /usr/bin/make
>> make install
>>  
>>  --
>>  
>>  The installation of wxWidgets is finished.  On certain
>>  platforms (e.g. Linux) you'll now have to run ldconfig
>>  if you installed a shared library and also modify the
>>  LD_LIBRARY_PATH (or equivalent) environment variable.
>>  
>>  wxWidgets comes with no guarantees and doesn't claim
>>  to be suitable for any purpose.
>>  
>>  Read the wxWindows Licence on licencing co

Re: [Kicad-developers] Local Variables

[Marco Serantoni]

I strongly agree with Tomasz, helping the user just firsts steps just after
the download is the key for a quick adoption.
When someone downloads Kicad for the first time is because have an idea in
mind that wish to trasfer in the reality or just to comparate its software
with the OpenSource one.

My humble opinion is that this programmer-centric approach to the GUI is
the one that hasn't permitted Linux to be a new reference for the desktop
systems.

Wayne, at the DOS time the default interface was the CLI, so was cooerent
for an user being able to set those, like now could be coerent on windows
for an user handle the registry keys.

If really we wish being able in the future to try a port to a Tablet, also
if only as "a reader", we can't require users to set enviroment variables
by hand, they could not be able to do it.

I personally think that "Preferences" could be the old good standard way to
place the variables now stored in the enviroment, then those could be
stored in the .pro files, Easy, straight and following a KISS approach.

Mac has enviroment variables but those are thinked to be used for command
line commands in a terminal and there isn't a standard way to make them
set, as anything not directly stated by Apple, each interface you use, can
change between releases or also with a patchset, OSX users/programmers know
that and are strict to follow the guidelines, this is a cathedral approach.

I personally think also that the Tomasz interface should be done in C++,
the first setup should be rock solid and failsafe:
is the first fly, we can reasonably expect issues with python on the first
fly, probably is the place where we could test and exercize the enviroment
before leaving the control to the User.
Is the first place we could fail and loose a new adopter.

I know, there is a new toy python and all us are happy of that and wish
play a bit, but i personally think that the "first setup interface" is the
homeworks that prepare to go to play after quietly.



--
Marco


On Fri, Mar 14, 2014 at 4:11 PM, Tomasz Wlostowski <
tomasz.wlostow...@cern.ch> wrote:

> On 03/14/2014 03:33 PM, Wayne Stambaugh wrote:
>
>> On 03/14/2014 10:24 AM, Adam Wolf wrote:
>>
>>> Hi folks,
>>>
>>> I heartily agree with this.  I've been trying to show some Kicad users
>>> how to use new features in Kicad, and environment variables is turning
>>> out to be a real turn-off for many of them.
>>>
>>
>> That's a rather sad statement.  Before the advent of the GUI (I know I
>> am showing my age), even the secretary (...)
>>
>
> Hi Wayne,
>
> In my humble opinion, it's not a matter of technical competence, but the
> first impression that Kicad makes on the first-time user. Most people
> expect software to work more or less out of the box, even the advanced ones
> (that's why among proprietary tools me & my folks @ CERN prefer Altium over
> Cadence, despite the latter being much more powerful).
>
> When somebody buys a Mac, the usual reason is it to avoid having to edit
> config files. I know many extremely competent analog designers who simply
> use autotrax or old orcad, just because they didn't require any
> configuration.
>
> The idea of keeping Kicad libs in Github is great, but if the
> first-time-ever user has to set it up in some system config files or run
> bash scripts (think of Windows users!), it will ruin his experience (sorry
> for sounding Steve Jobs-ish...). Eagle, DesignSpark and Altium have
> libraries working out-of-the box. Why we shouldn't?
>
> My proposal is add a configuration window (see attachment) that appears
> the first time freshly installed Kicad is launched. What do you think of
> this approach?
>
> Cheers,
> 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] Local Variables

[Marco Serantoni]

On 14/mar/2014, at 20:00, Wayne Stambaugh  wrote:
>> 
>> The idea of keeping Kicad libs in Github is great, but if the
>> first-time-ever user has to set it up in some system config files or run
>> bash scripts (think of Windows users!), it will ruin his experience
>> (sorry for sounding Steve Jobs-ish...). Eagle, DesignSpark and Altium
>> have libraries working out-of-the box. Why we shouldn't?
>> 
>> My proposal is add a configuration window (see attachment) that appears
>> the first time freshly installed Kicad is launched. What do you think of
>> this approach?
> 
> Hey Tom,
> 
> Yes I agree that it should just work and it should.  The problem is not
> in the code AFAICT.  The problem appears to be in the location where the
> default fp_lib_table file is installed on OSX.  When either CvPcb or
> Pcbnew are run for the first time without a define fp_lib_table file in
> the user's platform dependent home folder, an attempt is made to copy
> the default fp_lib_table file to the user's home folder.  On Linux the
> default fp_lib_table file is stored in /usr/share/kicad/template and
> copied to ~/.  If the default file cannot be found, then there is no
> choice but to create an empty fp_lib_table file which is what appears to
> be happening on OSX.  The path(s) searched for the default fp_lib_table
> are defined in EDA_APP::FindLibraryPath().  If the path that the OSX
> installer is placing the default fp_lib_table is not in the list of
> paths, then that is the problem or there is potentially a file
> permission problem preventing the file from being copied.  This used to
> work fine on both Windows and Linux so if no one changed it, it should
> still work.



Wayne the problem is not the code and this is CLEAR.
The problem is that there isn’t an installer to install programs under OSX, 
that can be placed by the user anywhere under /Applications directory.
The other issue is that the /Applications directory is not supposed to guest 
“support files”, so the combination of the two things doesn’t allow me to 
hardcode it on FindLibraryPath.
I’ve also tried to think an arrangement on that, but interacting with Dick on 
ticket  #1267911, i’ve understood with error that EDA_APP is gone, letting me 
wait Kiway.



The limit of the previous approach is that the developer/packager choose for 
the user if use the old libraries or the GitHub approach, not letting the user 
choose what is better for him.
Probably the “startup configuration window/wizard” could be a mayor enhancement 
for the user and solve also the other issue in a single move.
This was also the spirit that I had when the 31/12/2013 on the ML i’ve asked a 
button to “fill in” the table starting from the old legacy library path.


—
Marco
___
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] New icons for KiCAD

[Marco Serantoni]

Your contribution is appreciated probably i'll ask to you two a bit more 
Efforts for making the new icns files

Pleshanka,
Marco
> Il giorno 14/mar/2014, alle ore 13:49, Барановский Константин 
>  ha scritto:
> 
> I not wanted and not want to make a problem, but I want to make a 
> contribution in KiCAD. If you believe that needs to modify the icons, then I 
> ready to finalize it together with you.
> 
> Regards, Konstantin.
> 
> ___
> 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] Local Variables

[Marco Serantoni]

t; >>
>> >> I am trying to find a way to have all the *.app under the
>> /Applications/KiCad/,
>> >> and all the data under the home directory, so I can update/upgrade
>> without touching the data.
>> >> ~/Documents/ would be acceptable, I would prefer ~/Data/.
>> >> Github is OK for storage, but local storage is better for
>> efficiency/load.
>> >
>> > I would not put the component or footprint libraries in your ~/ folder.
>> > This will remove the temptation of modifying them only to have them
>> > overwritten the next time you update them.  It's best to create new
>> > libraries and leave the default libraries unchanged.
>> >
>> >>
>> >> What is the best route to do just that?
>> >
>> > You should be able use git to create your own branch form
>> > https://github.com/KiCad/kicad-library.  The CMake installer file is
>> > still there so you can run cmake -DCMAKE_INSTALL_PREFIX=path_to_intall
>> > and then make install.  I'm guessing you will have to have admin
>> > privileges to install them in the system paths so the sudo command
>> > should work.  If you choose this option, you will have to periodically
>> > pull the changes from github to keep your libraries up to date.
>> >
>> > Wayne
>> >
>> >>
>> >> Regards,
>> >> Jean-Paul (AC9GH)
>> >>
>> >>
>> >>
>> >> On Mar 14, 2014, at 7:08 PM, Wayne Stambaugh 
>> wrote:
>> >>
>> >>> On 3/14/2014 5:32 PM, Marco Serantoni wrote:
>> >>>>
>> >>>> On 14/mar/2014, at 20:00, Wayne Stambaugh 
>> wrote:
>> >>>>>>
>> >>>>>> The idea of keeping Kicad libs in Github is great, but if the
>> >>>>>> first-time-ever user has to set it up in some system config files
>> or run
>> >>>>>> bash scripts (think of Windows users!), it will ruin his experience
>> >>>>>> (sorry for sounding Steve Jobs-ish...). Eagle, DesignSpark and
>> Altium
>> >>>>>> have libraries working out-of-the box. Why we shouldn't?
>> >>>>>>
>> >>>>>> My proposal is add a configuration window (see attachment) that
>> appears
>> >>>>>> the first time freshly installed Kicad is launched. What do you
>> think of
>> >>>>>> this approach?
>> >>>>>
>> >>>>> Hey Tom,
>> >>>>>
>> >>>>> Yes I agree that it should just work and it should.  The problem is
>> not
>> >>>>> in the code AFAICT.  The problem appears to be in the location
>> where the
>> >>>>> default fp_lib_table file is installed on OSX.  When either CvPcb or
>> >>>>> Pcbnew are run for the first time without a define fp_lib_table
>> file in
>> >>>>> the user's platform dependent home folder, an attempt is made to
>> copy
>> >>>>> the default fp_lib_table file to the user's home folder.  On Linux
>> the
>> >>>>> default fp_lib_table file is stored in /usr/share/kicad/template and
>> >>>>> copied to ~/.  If the default file cannot be found, then there is no
>> >>>>> choice but to create an empty fp_lib_table file which is what
>> appears to
>> >>>>> be happening on OSX.  The path(s) searched for the default
>> fp_lib_table
>> >>>>> are defined in EDA_APP::FindLibraryPath().  If the path that the OSX
>> >>>>> installer is placing the default fp_lib_table is not in the list of
>> >>>>> paths, then that is the problem or there is potentially a file
>> >>>>> permission problem preventing the file from being copied.  This
>> used to
>> >>>>> work fine on both Windows and Linux so if no one changed it, it
>> should
>> >>>>> still work.
>> >>>>
>> >>>>
>> >>>>
>> >>>> Wayne the problem is not the code and this is CLEAR.
>> >>>> The problem is that there isn't an installer to install programs
>> under OSX, that can be placed by the user anywhere under /Applications
>> directory.
>> >>>> The other issue is that the /Applications directory is not supposed
>> to guest "support files", so the combination 

Re: [Kicad-developers] Local Variables

[Marco Serantoni]

Jean-Paul,
I don't agree with "Programs".
Until now OSX has supported /Library/Application Support/kicad and
$HOME/Library/Application Support/kicad
(Order: Own Home before, then system one)
To be failsafe we could arrange a .dmg with a Symbolic Link and the Arrow
"Copy here", is a well know approach for OSX users, here some links with
examples:

http://jhelioviewer.org/imgs/JHelioviewer_OSX_installer_screenshot.png
http://www.visitusers.org/images/1/10/VisItMac_dmg.png
http://ruby.bastardsbook.com/assets/images/fundamentals/installation/run-code-step-by-step/mac-textwrangler-dmg.png

The issue in this case will be the $HOME/Library[..] link that we could
ignore for the moment.
This simplification could be not sufficient for a machine that is used from
multiple users.

pkg is not a "not like", just we got issues in the past with it that a
simpler approach could avoid.

--
Marco


On Mon, Mar 17, 2014 at 4:47 PM, Jean-Paul Louis  wrote:

> Hi Adam and Marco,
>
> I agree with both of you. Let's keep it simple.
> A DMG bundle that have a "Kicad" folder with all the apps to be dragged
> into /Applications/.
> Data Bundle in "Kicad" folder to be dragged into /Library/Application
> Support/.
>
> We could have a small app which move everything to the right locations.
>
> my $0.02,
>
> Jean-Paul
>
> On Mar 17, 2014, at 11:14 AM, Adam Wolf 
> wrote:
>
> Hi Marco,
>
> I'm glad you agree that .pkg is not a good option.  How do you suggest we
> get data into /Library/Application\ Support/kicad?  Should we have users
> drag a folder into there?
>
> Adam Wolf
> Wayne and Layne, LLC
>
>
> On Mon, Mar 17, 2014 at 10:03 AM, Marco Serantoni <
> marco.serant...@gmail.com> wrote:
>
>> Adam,
>> 1) is the approach we will have dmg/zip file.
>> 2) there was a package manager, but becomes an hell to configure put in
>> bzr that forced us to remove few years ago.
>> 3) Requires 1), applications are downloaded from a bundle.
>>
>> Jean-Paul, /opt is something that should be used for command line
>> applications, not for GUI ones, try to interact with that will lead you in
>> different behaviour of Finder between versions.
>> Command line binaries related to Kicad should be placed in the bundle,
>> like happens for Xcode with the compiler/SDKs.
>>
>> The
>> /Library/Application Support/kicad is the path where the executables
>> expect to find their data.
>>
>> Wayne is a common error, OSX is POSIX and have the BSD API but is not BSD
>> in its organization.
>> OSX has a mach kernel (not a BSD one) in which there is the BSD
>> subsystem, like in the past NT had a POSIX subsystem.
>> Like each distro have completelly different approach in package manager
>> and organization for configuration files.
>> I've already tried to explain why, that neither the pure wxStandardPaths
>> before the K-way will work.
>>
>>
>>
>> --
>> Marco
>>
>>
>> On Mon, Mar 17, 2014 at 2:11 PM, Adam Wolf > > wrote:
>>
>>> I think that'll work for users who want to compile their own.  From a
>>> packaging and distribution standpoint:  I'm excited for kiways.
>>>  Distributed Mac applications come in 3 types:
>>>
>>> 1) a DMG that contains a .app bundle that you drag to /Applications.
>>>  This is basically what installing to /Applications does, except minus the
>>> packaging step (which I already scripted)
>>> 2) a .pkg installer.  These can install files all over your system, but
>>> then uninstalling means running the .pkg again.  Users don't like these as
>>> much as #1.
>>> 3) from the Mac App Store. (Probably not a short term solution for us
>>> right now--hopefully someday!)
>>>
>>> If we can set it up so that everything is contained in the .app, then we
>>> can do #1 for distribution.  What's stopping us now from doing that is that
>>> multiple .apps want to refer to the same libraries, so we have to have a
>>> place outside of the .app that is common.  Once we have kiways, this should
>>> be doable, right?
>>>
>>> Other Mac folks, what do you think?  (Other non-Mac folks too...)
>>>
>>> Adam Wolf
>>> Wayne and Layne, LLC
>>>
>>>
>>> On Mon, Mar 17, 2014 at 12:22 AM, Jean-Paul Louis wrote:
>>>
>>>> Wayne,
>>>>
>>>> Thank you for your detailed reply.
>>>> I will add -DCMAKE_INSTALL_PREFIX=/Applications/Kicad/ to my script,
>>>> and the library files in /Library/Application Sup

Re: [Kicad-developers] Local Variables

[Marco Serantoni]

Obliusly a second .dmg with only libraries to avoid confusion and adding
the possibility for the user to be archived if needed.

--
Marco


On Mon, Mar 17, 2014 at 6:01 PM, Marco Serantoni
wrote:

> Jean-Paul,
> I don't agree with "Programs".
> Until now OSX has supported /Library/Application Support/kicad and
> $HOME/Library/Application Support/kicad
> (Order: Own Home before, then system one)
> To be failsafe we could arrange a .dmg with a Symbolic Link and the Arrow
> "Copy here", is a well know approach for OSX users, here some links with
> examples:
>
> http://jhelioviewer.org/imgs/JHelioviewer_OSX_installer_screenshot.png
> http://www.visitusers.org/images/1/10/VisItMac_dmg.png
>
> http://ruby.bastardsbook.com/assets/images/fundamentals/installation/run-code-step-by-step/mac-textwrangler-dmg.png
>
> The issue in this case will be the $HOME/Library[..] link that we could
> ignore for the moment.
> This simplification could be not sufficient for a machine that is used
> from multiple users.
>
> pkg is not a "not like", just we got issues in the past with it that a
> simpler approach could avoid.
>
> --
> Marco
>
>
> On Mon, Mar 17, 2014 at 4:47 PM, Jean-Paul Louis  wrote:
>
>> Hi Adam and Marco,
>>
>> I agree with both of you. Let's keep it simple.
>> A DMG bundle that have a "Kicad" folder with all the apps to be dragged
>> into /Applications/.
>> Data Bundle in "Kicad" folder to be dragged into /Library/Application
>> Support/.
>>
>> We could have a small app which move everything to the right locations.
>>
>> my $0.02,
>>
>> Jean-Paul
>>
>> On Mar 17, 2014, at 11:14 AM, Adam Wolf 
>> wrote:
>>
>> Hi Marco,
>>
>> I'm glad you agree that .pkg is not a good option.  How do you suggest we
>> get data into /Library/Application\ Support/kicad?  Should we have users
>> drag a folder into there?
>>
>> Adam Wolf
>> Wayne and Layne, LLC
>>
>>
>> On Mon, Mar 17, 2014 at 10:03 AM, Marco Serantoni <
>> marco.serant...@gmail.com> wrote:
>>
>>> Adam,
>>> 1) is the approach we will have dmg/zip file.
>>> 2) there was a package manager, but becomes an hell to configure put in
>>> bzr that forced us to remove few years ago.
>>> 3) Requires 1), applications are downloaded from a bundle.
>>>
>>> Jean-Paul, /opt is something that should be used for command line
>>> applications, not for GUI ones, try to interact with that will lead you in
>>> different behaviour of Finder between versions.
>>> Command line binaries related to Kicad should be placed in the bundle,
>>> like happens for Xcode with the compiler/SDKs.
>>>
>>> The
>>> /Library/Application Support/kicad is the path where the executables
>>> expect to find their data.
>>>
>>> Wayne is a common error, OSX is POSIX and have the BSD API but is not
>>> BSD in its organization.
>>> OSX has a mach kernel (not a BSD one) in which there is the BSD
>>> subsystem, like in the past NT had a POSIX subsystem.
>>> Like each distro have completelly different approach in package manager
>>> and organization for configuration files.
>>> I've already tried to explain why, that neither the pure wxStandardPaths
>>> before the K-way will work.
>>>
>>>
>>>
>>> --
>>> Marco
>>>
>>>
>>> On Mon, Mar 17, 2014 at 2:11 PM, Adam Wolf <
>>> adamw...@feelslikeburning.com> wrote:
>>>
>>>> I think that'll work for users who want to compile their own.  From a
>>>> packaging and distribution standpoint:  I'm excited for kiways.
>>>>  Distributed Mac applications come in 3 types:
>>>>
>>>> 1) a DMG that contains a .app bundle that you drag to /Applications.
>>>>  This is basically what installing to /Applications does, except minus the
>>>> packaging step (which I already scripted)
>>>> 2) a .pkg installer.  These can install files all over your system, but
>>>> then uninstalling means running the .pkg again.  Users don't like these as
>>>> much as #1.
>>>> 3) from the Mac App Store. (Probably not a short term solution for us
>>>> right now--hopefully someday!)
>>>>
>>>> If we can set it up so that everything is contained in the .app, then
>>>> we can do #1 for distribution.  What's stopping us now from doing that is
>>>> that multiple .apps wa

Re: [Kicad-developers] Local Variables

[Marco Serantoni]

If you wish,
there are some old templates, look if you could do something with artworks
at:
http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/files/head:/packaging/mac-osx/

There you can find my LD pkg maker (a pain), just ignore it.

And an old Jerry Script to make .dmg, that could be a good startpoint,
probably the artworks are reusable too.
Please use a FULL shell scripting approach if is possibile, i feel better
than native scripts and less problematic for all to manage and submit
patches (other scripts are binary, i don't like it due the difficulties to
make review).
Also please be aware that some paths will need an adjustment.


--
Marco


On Mon, Mar 17, 2014 at 6:03 PM, Adam Wolf wrote:

> (I agree with Marco.)
>
>
> On Mon, Mar 17, 2014 at 12:01 PM, Marco Serantoni <
> marco.serant...@gmail.com> wrote:
>
>> Jean-Paul,
>> I don't agree with "Programs".
>> Until now OSX has supported /Library/Application Support/kicad and
>> $HOME/Library/Application Support/kicad
>> (Order: Own Home before, then system one)
>> To be failsafe we could arrange a .dmg with a Symbolic Link and the Arrow
>> "Copy here", is a well know approach for OSX users, here some links with
>> examples:
>>
>> http://jhelioviewer.org/imgs/JHelioviewer_OSX_installer_screenshot.png
>> http://www.visitusers.org/images/1/10/VisItMac_dmg.png
>>
>> http://ruby.bastardsbook.com/assets/images/fundamentals/installation/run-code-step-by-step/mac-textwrangler-dmg.png
>>
>> The issue in this case will be the $HOME/Library[..] link that we could
>> ignore for the moment.
>> This simplification could be not sufficient for a machine that is used
>> from multiple users.
>>
>> pkg is not a "not like", just we got issues in the past with it that a
>> simpler approach could avoid.
>>
>> --
>> Marco
>>
>>
>> On Mon, Mar 17, 2014 at 4:47 PM, Jean-Paul Louis wrote:
>>
>>> Hi Adam and Marco,
>>>
>>> I agree with both of you. Let's keep it simple.
>>> A DMG bundle that have a "Kicad" folder with all the apps to be dragged
>>> into /Applications/.
>>> Data Bundle in "Kicad" folder to be dragged into /Library/Application
>>> Support/.
>>>
>>> We could have a small app which move everything to the right locations.
>>>
>>> my $0.02,
>>>
>>> Jean-Paul
>>>
>>> On Mar 17, 2014, at 11:14 AM, Adam Wolf 
>>> wrote:
>>>
>>> Hi Marco,
>>>
>>> I'm glad you agree that .pkg is not a good option.  How do you suggest
>>> we get data into /Library/Application\ Support/kicad?  Should we have users
>>> drag a folder into there?
>>>
>>> Adam Wolf
>>> Wayne and Layne, LLC
>>>
>>>
>>> On Mon, Mar 17, 2014 at 10:03 AM, Marco Serantoni <
>>> marco.serant...@gmail.com> wrote:
>>>
>>>> Adam,
>>>> 1) is the approach we will have dmg/zip file.
>>>> 2) there was a package manager, but becomes an hell to configure put in
>>>> bzr that forced us to remove few years ago.
>>>> 3) Requires 1), applications are downloaded from a bundle.
>>>>
>>>> Jean-Paul, /opt is something that should be used for command line
>>>> applications, not for GUI ones, try to interact with that will lead you in
>>>> different behaviour of Finder between versions.
>>>> Command line binaries related to Kicad should be placed in the bundle,
>>>> like happens for Xcode with the compiler/SDKs.
>>>>
>>>> The
>>>> /Library/Application Support/kicad is the path where the executables
>>>> expect to find their data.
>>>>
>>>> Wayne is a common error, OSX is POSIX and have the BSD API but is not
>>>> BSD in its organization.
>>>> OSX has a mach kernel (not a BSD one) in which there is the BSD
>>>> subsystem, like in the past NT had a POSIX subsystem.
>>>> Like each distro have completelly different approach in package manager
>>>> and organization for configuration files.
>>>> I've already tried to explain why, that neither the pure
>>>> wxStandardPaths before the K-way will work.
>>>>
>>>>
>>>>
>>>> --
>>>> Marco
>>>>
>>>>
>>>> On Mon, Mar 17, 2014 at 2:11 PM, Adam Wolf <
>>>> adamw...@feelslikeburning.com> wrote:
>>>>
>>>>> I think that'll

Re: [Kicad-developers] OSX build fails consistently with same error

[Marco Serantoni]

On 22/mar/2014, at 07:00, Dick Hollenbeck  wrote:
Here where was a couple of issues.
The pcb_plot_params_keywords i think is a multi platform issue that happens 
only on scratch new checkouts using an high parallelism (like make -j12)
Doesn’t happens on not “fresh” rebuilds because we found the previous build .h.
I’ve fixed some of those race, but seems that still happening somewhere, i’ll 
wait the end of deployment of Kiway to see it in a deeper way.

The other one was due the CAIRO_FOUND in download_cairo.cmake, there is 
something missing in bypassing the check_package, i’ve workarounded it for now.

—
Marco

> On 03/21/2014 11:01 PM, Jean-Paul Louis wrote:
>> The make in the common directory made a difference, but now I get a failure 
>> I never saw
>> before.
>> Looks like an issue with Cairo and GAL, but I have no clue as I never looked 
>> at that part
>> of the code.
>> 
>> Jean-Paul (AC9GH)
>> 
>> The result below is the "make" after the previous “make" in the "common" 
>> directory.
> 
> I said
> 
> $ make pcb_plot_params_keywords.o
> 
> not:
> 
> $ make

___
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] OSX build fails consistently with same error

[Marco Serantoni]

On 22/mar/2014, at 22:03, Jean-Paul Louis  wrote:

Jean-Paul,
You choose the hard way, and the one i can’t control.
You need only compiler, bzr and cmake downloaded from the respective sites and 
follow the indication
in Documentation/compiling/mac-osx.txt
Libraries and dependencies are downloaded and compiled accordly the 
Architecture/processors you need, all the rest too.


The last issue you shown is solved since 11 am CET, please update your 
repository.

—
Marco


> KiCad OS X Maverick Build ===> 99% SUCCESS
> 
> Now the BZR4766 was build to almost the very end.
> I have all the executables in the right directory /Applications/KiCad/bin.
> The only thing left to resolve is how to let Launchpad know about he new Apps.
> What was created in Launchpad is a Folder called "KiCad (Other)”, but it 
> contain
> only one icon (pl_editor) that will not launch anything except an error 
> message
> 
> <2014-03-22_17-00-22.jpg>
> 
> Jean-Paul
> 
> 
> On Mar 22, 2014, at 11:09 AM, Jean-Paul Louis  wrote:
> 
>> I just completely removed the build directory I used.
>> 
>> I will try a fresh build today with all the new info I got from all of you.
>> 
>> I used MacPort to install whatever was needed for the build
>>  bzr bzrtools swig glew cairo etc..
>> 
>> My build platform is:
>> 
>> Hardware is Macbook Pro w Retina Display 2.3GHz 4-core I7 - 16GB RAM - 500GB 
>> SSD
>> 
>> Software is:
>> OS X 10.9 Latest Maverick
>> 
>> Xcode Version 5.1 (5B130a)
>> 
>> Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
>> Target: x86_64-apple-darwin13.1.0
>> Thread model: posix
>> 
>> cmake version 2.8.12.2
>> 
>> GNU Make 3.81
>> ...
>> This program built for i386-apple-darwin11.3.0
>> 
>> Bazaar (bzr) 2.6.0
>>  Python interpreter: 
>> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
>>  2.7.6
>>  Python standard library: 
>> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7
>>  Platform: Darwin-13.1.0-x86_64-i386-64bit
>>  bzrlib: 
>> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/bzrlib
>>  Bazaar configuration: /Users/jean-paullouis/.bazaar
>>  Bazaar log file: /Users/jean-paullouis/.bzr.log
>> 
>> Copyright 2005-2012 Canonical Ltd.
>> http://bazaar.canonical.com/
>> 
>> SWIG Version 2.0.11
>> Compiled with /usr/bin/clang++ [x86_64-apple-darwin13.0.0]
>> Configured options: +pcre
>> 
>>> 
>>> On 22/mar/2014, at 07:00, Dick Hollenbeck  wrote:
>>> Here where was a couple of issues.
>>> The pcb_plot_params_keywords i think is a multi platform issue that happens 
>>> only on scratch new checkouts using an high parallelism (like make -j12)
>>> Doesn’t happens on not “fresh” rebuilds because we found the previous build 
>>> .h.
>>> I’ve fixed some of those race, but seems that still happening somewhere, 
>>> i’ll wait the end of deployment of Kiway to see it in a deeper way.
>>> 
>>> The other one was due the CAIRO_FOUND in download_cairo.cmake, there is 
>>> something missing in bypassing the check_package, i’ve workarounded it for 
>>> now.
>>> 
>>> —
>>> Marco
>>> 

___
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] OSX build fails consistently with same error

[Marco Serantoni]

Jean-Paul,
You got right, i forgot that.
Fixed

—
Marco

On 23/mar/2014, at 02:43, Marco Serantoni  wrote:

> 
> On 22/mar/2014, at 22:03, Jean-Paul Louis  wrote:
> 
> Jean-Paul,
> You choose the hard way, and the one i can’t control.
> You need only compiler, bzr and cmake downloaded from the respective sites 
> and follow the indication
> in Documentation/compiling/mac-osx.txt
> Libraries and dependencies are downloaded and compiled accordly the 
> Architecture/processors you need, all the rest too.
> 
> 
> The last issue you shown is solved since 11 am CET, please update your 
> repository.
> 
> —
> Marco
> 
> 
>> KiCad OS X Maverick Build ===> 99% SUCCESS
>> 
>> Now the BZR4766 was build to almost the very end.
>> I have all the executables in the right directory /Applications/KiCad/bin.
>> The only thing left to resolve is how to let Launchpad know about he new 
>> Apps.
>> What was created in Launchpad is a Folder called "KiCad (Other)”, but it 
>> contain
>> only one icon (pl_editor) that will not launch anything except an error 
>> message
>> 
>> <2014-03-22_17-00-22.jpg>
>> 
>> Jean-Paul
>> 
>> 
>> On Mar 22, 2014, at 11:09 AM, Jean-Paul Louis  wrote:
>> 
>>> I just completely removed the build directory I used.
>>> 
>>> I will try a fresh build today with all the new info I got from all of you.
>>> 
>>> I used MacPort to install whatever was needed for the build
>>> bzr bzrtools swig glew cairo etc..
>>> 
>>> My build platform is:
>>> 
>>> Hardware is Macbook Pro w Retina Display 2.3GHz 4-core I7 - 16GB RAM - 
>>> 500GB SSD
>>> 
>>> Software is:
>>> OS X 10.9 Latest Maverick
>>> 
>>> Xcode Version 5.1 (5B130a)
>>> 
>>> Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
>>> Target: x86_64-apple-darwin13.1.0
>>> Thread model: posix
>>> 
>>> cmake version 2.8.12.2
>>> 
>>> GNU Make 3.81
>>> ...
>>> This program built for i386-apple-darwin11.3.0
>>> 
>>> Bazaar (bzr) 2.6.0
>>>  Python interpreter: 
>>> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
>>>  2.7.6
>>>  Python standard library: 
>>> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7
>>>  Platform: Darwin-13.1.0-x86_64-i386-64bit
>>>  bzrlib: 
>>> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/bzrlib
>>>  Bazaar configuration: /Users/jean-paullouis/.bazaar
>>>  Bazaar log file: /Users/jean-paullouis/.bzr.log
>>> 
>>> Copyright 2005-2012 Canonical Ltd.
>>> http://bazaar.canonical.com/
>>> 
>>> SWIG Version 2.0.11
>>> Compiled with /usr/bin/clang++ [x86_64-apple-darwin13.0.0]
>>> Configured options: +pcre
>>> 
>>>> 
>>>> On 22/mar/2014, at 07:00, Dick Hollenbeck  wrote:
>>>> Here where was a couple of issues.
>>>> The pcb_plot_params_keywords i think is a multi platform issue that 
>>>> happens only on scratch new checkouts using an high parallelism (like make 
>>>> -j12)
>>>> Doesn’t happens on not “fresh” rebuilds because we found the previous 
>>>> build .h.
>>>> I’ve fixed some of those race, but seems that still happening somewhere, 
>>>> i’ll wait the end of deployment of Kiway to see it in a deeper way.
>>>> 
>>>> The other one was due the CAIRO_FOUND in download_cairo.cmake, there is 
>>>> something missing in bypassing the check_package, i’ve workarounded it for 
>>>> now.
>>>> 
>>>> —
>>>> Marco
>>>> 
> 

___
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 OS X - eeschema, pcbnew, etc.. starts minimized

[Marco Serantoni]

Happy of that,
You are signalating a Known issue when using kicad.app.
There was a thread 2-3 months ago about it, this is the best we can do with
this code arrangement, this should disappear once k-way will be fully
deployed.
If you have suggestions/patches on how to fix it we will review it together.


--
Marco


On Mon, Mar 31, 2014 at 6:37 PM, Jean-Paul Louis  wrote:

> Hello all,
>
> I have now workable apps built with OS X. When I double click on the app
> in Finder, the Kicad app starts normally.
> So, I load my current project, select the schematic file, and click on the
> eeschema icon. the eeschema app always start minimized, so I have to go to
> the dock, and click the icon to restore the window.
> Where can I find a setting that will start the app normally?
>
> Now, my next task will be to create a DMG file for the Mac users that
> cannot or do not want to build.
> In my machine, with the virus check disabled, I build the whole thing in
> less than two hours, so I should be able to
> build nightly.
>
> Jean-Paul (AC9GH)
>
> ___
> 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] [PATCH] kiface app bundle

[Marco Serantoni]

On 24/apr/2014, at 17:55, Dick Hollenbeck  wrote:

Dick 
I’m there, i wish ask to you and bug reporters to send a mail in CC directly to 
me if there are urgent and important things about OSX.
I’ven always the time to read the Developer ML during my work peaks, sorry.

> Marco (or in his continued absence, any other OSX developer),
> 
> 1)
> After reading for a few minutes about app bundles on wikipedia, I am thinking 
> we can
> eliminate the copy of the *.kiface file which is up at the directory where 
> the *.app files
> exist.
> 
> Do you agree?
> 
> If so, please look at this patch as a proposed strategy for all but the 
> kicad.app.  This
> only deals with pcbnew.app as a trial balloon.  The trick is to build the 
> *.kiface module
> down in the bundle right out of the get go.  I am curious if it gets copied 
> properly
> during the install.  I have no way to test that since this is OSX CMake 
> specific behavior.

Dick why you wish do that, which is the improvement that that could do to the 
current way ?
The current arrangement works nice with 3 releases of OSX testing it all will 
mean days of testing.


> 2)
> For the kicad.app/Contents/MacOS/ directory, I would suggest we install 
> symlinks with
> these names
> 
> _pcbnew.kiface, _eeschema.kiface, _cvpcb.kiface to the real deals up and over 
> in the
> 
> pcbnew.app/Contents/MacOS directory equivalents.
> 
> I don't know how to do this with CMake yet.  But we should try it manually 
> first.  This
> will leave us with one copy of each *.kiface binary.
> 
> I think I know how to create the symlinks in the build directory copy of the 
> bundle, so I
> wonder if during install these would get transformed to actual full copies.
> 
> The difficulty is that the ${KIFACE_BIN} variable does not get expanded 
> before the
> install() steps are actually done.  In fact it looks like it happens inside 
> the install()
> steps.  So there's no way to get an expanded variable during installation.
> 
> So let's hope setting up the symlinks in the build dir will get carried into 
> the install dir.

If i’ve understood well the point 1) is propaedeutic for this step.
This makes the debug also more difficult and render impossible make symbolic 
links in the build tree.
/product/pcbnew/pcbnew.app/[…]
is different of in place
/Applications/Kicad/pcbnew.app/[…]
There is a directory level of difference with the consequent difference in the 
“relative path” that is the strategy that we should point to and we shall pass 
to the ln command.

Moreover, we will introduce a dependency of the bundles to another one.

This is the “ratio" of the integral copy of .kiface libraries and not the 
linking.
And the reason that induces me to discourage that changes.

Moreover the final step of the kiway operation points us to have a single 
bundle in small time: the problem will be resolved naturally.
Does this change worth the costs to debug bugs for symbolic links pointing to 
nowhere that are also difficult to trace via mail/bugtracker ?

—
Marco



___
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] BZR 4813 OS X crash all the time - USELESS

[Marco Serantoni]

On 24/apr/2014, at 15:40, Dick Hollenbeck  wrote:

I’m sorry for the late, but i’ven’t received any bug report about this issue.

There are two issues at the moment:
The first is probably caused by the update of the developer tools shipped the 
11 April (Command Line Developer Tools 5.1.0).
The second is due the change in kicad.app made by dick for the advancement of 
the kiway in BZR 4757.

I’m assesting the second, but probably i have to change my mind and use 
symbolic link with an caveat: will be a little dirty but simple and effective.

For the first i’ll ask help to the owners to how to bypass the issue.

—
Marco


> On 04/23/2014 12:22 PM, Jean-Paul Louis wrote:
>> Dick,
>> 
>> I really appreciate the help you provided me, and I did not know that you 
>> spent over a man-year in this KiCad Development Team.
>> I am copying this to the user group, and I hope that Marco will pick up the 
>> ball to keep the OS X build possible.
>> For me, OS X is new and confusing because of quite a few similarities with 
>> the Unix/Linux world.
>> But Apple guys made enough changes to make if a constant frustration. I made 
>> the switch to OS X to learn something new, and if I fail to run Kicad on OS 
>> X, I have a back-up plan to run it on a VM with either Ubuntu or Debian 
>> which are familiar to me. I might even end-up running Linux on dual boot.
>> 
>> I have not done any timing, but the Debian/VM is fast, so I might be able to 
>> use Kicad with Parallels 9 for Desktop.
>> Meanwhile, I will try to make it work on OS X. and I will bug report to 
>> Marco.
>> 
>> What I do not understand is if the crash is really due to the lost 
>> connection between the exe and the kiface, why is the crash not happening on 
>> all the execs? 
> 
> 
> 
> Jean-Paul,
> 
> Sorry for this inconvenience, and I appreciate you willing to be a tester for 
> the Mac
> KIWAY work, rather than going the safe route and running the "pre-kiway" 
> tagged version.
> (AKA stable code, in a modern sense.)
> 
> This looks solvable now to me, even without Marco's help, providing you can 
> continue
> helping by trying some things for me.
> 
> Any chain loaded *.kiface file must be in the same directory as its client 
> loader.  On
> OSX, we have met this requirement for pcb_calculator, eeschema, pl_editor, 
> cvpcb,
> gerbview, and pl_editor.  All are stand alone programs.
> 
> 
> The kicad (executable) program is different, it is a client loader for 
> _pcbnew.kiface,
> _eeschema.kiface, and _cvpcb.kiface, at this time, subject to change.
> 
> 
> The kicad project manager is not satisfied in this "same directory" regard on 
> OSX.  I
> don't think this is a bug per se, not in the C++, but a shortcoming of the 
> CMake install()
> statements.
> 
> There are two things I ask you to try here:
> 
> 1) Try version 4821 without doing anything else.  When you get the fatal 
> installation
> error message, write down:
> 
> missing file: 
> argv[0] 
> 
> 
> 2) After you get the fatal error, see if what follows in this email makes 
> sense, namely
> the copying of the 3 kiface files mentioned below.  But I'd like to make that 
> step 2) so
> we can capture the information in step 1 first.
> 
> 
> More below
> 
> 
>> Why only eeschema, cvpcb and pcbnew, and not the others?
>> Also, those three apps run fine if launched individually, so the change has 
>> happened in the last week, and in kicad only (the launch buttons of kicad 
>> project manager).
>> 
>> Everything (OS X wise) was fine until sometime (not sure exactly when) after 
>> BZR 4805.
>> Right now, I have kept an older (4801) build that runs fine. So something 
>> changed that broke the camel’s back,
>> and I hope that Marco will be able to trace it to a specific BZR change.
>> I will help by building every branch between 4805 which I had tested and 
>> 4813 which is when I noticed the change. 
>> I just need to read the man page for bar in order to select a given branch.
>> 
>> Again, I am sorry to see you leaving the team, as I have seen the huge 
>> improvements made during your tenure.
>> But I understand your frustration, and the cost of your effort.
>> 
>> Best regards,
>> Jean-Paul
>> AC9GH
>> 
> 
 The executable and the kiface, must go into the same directory
> 
> 
> But pl_editor seems to open and close immediately while pcb_calculator, 
> bitmap2component and gerbview opens as expected.
> The kicad crash is then limited to eeschema, cvpcb and pcbnew.
> 
> 
> So I checked the app directory. the “make install” create the structure 
> below.
> The kiface files are created in two places.
> 
> Jean-Pauls-MacBook-Pro:KiCad jean-paullouis$ pwd
> /Applications/KiCad
> Jean-Pauls-MacBook-Pro:KiCad jean-paullouis$ ls -al
> total 84768
> drwxr-xr-x  24 jean-paullouis  admin   816 Apr 23 09:37 .
> drwxrwxr-x+ 96 rootadmin  3264 Apr 19 23:31 ..
> -rw-r--r--@  1 jean-paullouis  admin  6148 Apr 23 09:37 .DS_

Re: [Kicad-developers] BZR 4813 OS X crash all the time - USELESS

[Marco Serantoni]

On 27/apr/2014, at 15:01, Marco Serantoni  wrote:
Should be both fixed.
I’ve done a quick fix to the issue #1, please if responsible developer doesn’t 
like they can reject or rework.

Jean-Paul please take a look.

I’ve Accepted the Dick hint to symbolic link kiface libraries to the owner 
bundle, probably will need some refine in the future.


—
Marco

> 
> On 24/apr/2014, at 15:40, Dick Hollenbeck  wrote:
> 
> I’m sorry for the late, but i’ven’t received any bug report about this issue.
> 
> There are two issues at the moment:
> The first is probably caused by the update of the developer tools shipped the 
> 11 April (Command Line Developer Tools 5.1.0).
> The second is due the change in kicad.app made by dick for the advancement of 
> the kiway in BZR 4757.
> 
> I’m assesting the second, but probably i have to change my mind and use 
> symbolic link with an caveat: will be a little dirty but simple and effective.
> 
> For the first i’ll ask help to the owners to how to bypass the issue.
> 
> —
> Marco
> 
> 
>> On 04/23/2014 12:22 PM, Jean-Paul Louis wrote:
>>> Dick,
>>> 
>>> I really appreciate the help you provided me, and I did not know that you 
>>> spent over a man-year in this KiCad Development Team.
>>> I am copying this to the user group, and I hope that Marco will pick up the 
>>> ball to keep the OS X build possible.
>>> For me, OS X is new and confusing because of quite a few similarities with 
>>> the Unix/Linux world.
>>> But Apple guys made enough changes to make if a constant frustration. I 
>>> made the switch to OS X to learn something new, and if I fail to run Kicad 
>>> on OS X, I have a back-up plan to run it on a VM with either Ubuntu or 
>>> Debian which are familiar to me. I might even end-up running Linux on dual 
>>> boot.
>>> 
>>> I have not done any timing, but the Debian/VM is fast, so I might be able 
>>> to use Kicad with Parallels 9 for Desktop.
>>> Meanwhile, I will try to make it work on OS X. and I will bug report to 
>>> Marco.
>>> 
>>> What I do not understand is if the crash is really due to the lost 
>>> connection between the exe and the kiface, why is the crash not happening 
>>> on all the execs? 
>> 
>> 
>> 
>> Jean-Paul,
>> 
>> Sorry for this inconvenience, and I appreciate you willing to be a tester 
>> for the Mac
>> KIWAY work, rather than going the safe route and running the "pre-kiway" 
>> tagged version.
>> (AKA stable code, in a modern sense.)
>> 
>> This looks solvable now to me, even without Marco's help, providing you can 
>> continue
>> helping by trying some things for me.
>> 
>> Any chain loaded *.kiface file must be in the same directory as its client 
>> loader.  On
>> OSX, we have met this requirement for pcb_calculator, eeschema, pl_editor, 
>> cvpcb,
>> gerbview, and pl_editor.  All are stand alone programs.
>> 
>> 
>> The kicad (executable) program is different, it is a client loader for 
>> _pcbnew.kiface,
>> _eeschema.kiface, and _cvpcb.kiface, at this time, subject to change.
>> 
>> 
>> The kicad project manager is not satisfied in this "same directory" regard 
>> on OSX.  I
>> don't think this is a bug per se, not in the C++, but a shortcoming of the 
>> CMake install()
>> statements.
>> 
>> There are two things I ask you to try here:
>> 
>> 1) Try version 4821 without doing anything else.  When you get the fatal 
>> installation
>> error message, write down:
>> 
>> missing file: 
>> argv[0] 
>> 
>> 
>> 2) After you get the fatal error, see if what follows in this email makes 
>> sense, namely
>> the copying of the 3 kiface files mentioned below.  But I'd like to make 
>> that step 2) so
>> we can capture the information in step 1 first.
>> 
>> 
>> More below
>> 
>> 
>>> Why only eeschema, cvpcb and pcbnew, and not the others?
>>> Also, those three apps run fine if launched individually, so the change has 
>>> happened in the last week, and in kicad only (the launch buttons of kicad 
>>> project manager).
>>> 
>>> Everything (OS X wise) was fine until sometime (not sure exactly when) 
>>> after BZR 4805.
>>> Right now, I have kept an older (4801) build that runs fine. So something 
>>> changed that broke the camel’s back,
>>> and I hope that Marco will be able to trace it to a specific BZR change.
>>> I will help 

Re: [Kicad-developers] [PATCH] kiface app bundle

[Marco Serantoni]

On 27/apr/2014, at 23:36, Dick Hollenbeck  wrote:
>> Dick 
>> I’m there, i wish ask to you and bug reporters to send a mail in CC directly 
>> to me if there are urgent and important things about OSX.
>> I’ven always the time to read the Developer ML during my work peaks, sorry.
>> 
>>> Marco (or in his continued absence, any other OSX developer),
>>> 
>>> 1)
>>> After reading for a few minutes about app bundles on wikipedia, I am 
>>> thinking we can
>>> eliminate the copy of the *.kiface file which is up at the directory where 
>>> the *.app files
>>> exist.
>>> 
>>> Do you agree?
>>> 
>>> If so, please look at this patch as a proposed strategy for all but the 
>>> kicad.app.  This
>>> only deals with pcbnew.app as a trial balloon.  The trick is to build the 
>>> *.kiface module
>>> down in the bundle right out of the get go.  I am curious if it gets copied 
>>> properly
>>> during the install.  I have no way to test that since this is OSX CMake 
>>> specific behavior.
>> 
>> Dick why you wish do that, which is the improvement that that could do to 
>> the current way ?
>> The current arrangement works nice with 3 releases of OSX testing it all 
>> will mean days of testing.
> 
> This is in the thread between me and Jean-Paul.  Having a *.kiface file in 
> the same place
> as the *.app is located, and then again two directories down seemed sloppy to 
> me.  So
> clearly neither Jean-Paul or myself thought it was a good idea and 
> unnecessary for his
> version of OSX.
> 
> Is this needed for a particular version of OSX, or was it just as quick, 
> sloppy hack to
> get the kiface in any place it *might* be needed?

Uh i’m sorry that I misunderstand, i’vent understand that was a private dialog 
about OSX proceedings.
UI Binaries in OSX are distributed only in the bundles, the rest are only an 
intermediate files used for the build, like object files.


>>> 2)
>>> For the kicad.app/Contents/MacOS/ directory, I would suggest we install 
>>> symlinks with
>>> these names
>>> 
>>> _pcbnew.kiface, _eeschema.kiface, _cvpcb.kiface to the real deals up and 
>>> over in the
>>> 
>>> pcbnew.app/Contents/MacOS directory equivalents.
>>> 
>>> I don't know how to do this with CMake yet.  But we should try it manually 
>>> first.  This
>>> will leave us with one copy of each *.kiface binary.
>>> 
>>> I think I know how to create the symlinks in the build directory copy of 
>>> the bundle, so I
>>> wonder if during install these would get transformed to actual full copies.
>>> 
>>> The difficulty is that the ${KIFACE_BIN} variable does not get expanded 
>>> before the
>>> install() steps are actually done.  In fact it looks like it happens inside 
>>> the install()
>>> steps.  So there's no way to get an expanded variable during installation.
>>> 
>>> So let's hope setting up the symlinks in the build dir will get carried 
>>> into the install dir.
>> 
>> If i’ve understood well the point 1) is propaedeutic for this step.
>> This makes the debug also more difficult and render impossible make symbolic 
>> links in the build tree.
>> /product/pcbnew/pcbnew.app/[…]
>> is different of in place
>> /Applications/Kicad/pcbnew.app/[…]
>> There is a directory level of difference with the consequent difference in 
>> the “relative path” that is the strategy that we should point to and we 
>> shall pass to the ln command.
>> 
>> Moreover, we will introduce a dependency of the bundles to another one.
> 
> There is only one Kicad application as far as I am concerned.  Bundles are 
> something that
> gets in my way, and would be like treating eeschema and pcbnew as two 
> different linux
> packages.  They are not.  It is one application suite, made even more tightly 
> bound by the
> KIWAY.
> 
> So I don't see your argument, at least not based on bundles.  However I 
> suffer no
> particular loss if Mac users want to use more disk space than needed, and you 
> want another
> copy of the *.kiface files in the kicad.app tree.  And I remind the list, 
> that this would
> bring the total under your scheme to 3 copies of each *.kiface, vs. one copy 
> of each using
> my patch, if it works.
> 
> Really I don't care.  However, I do find it disrespectful that after I spent 
> a whole day
> with Jean-Paul offline solving the issues for him on his machine manually, 
> that no one has
> had the courtesy to actually try my patch to see if it even works.
> 
> This is clearly another example of why the disrespect of my time around here 
> has gotten
> intolerable.

Each binary is a single application, each application is hosted in a bundle, 
each bundle is a single ICON.
This is the OS architecture.
There aren’t 3 copies, who says that hasn’t understood well what happens.


As you can see in the later message i’ve followed your idea, i’ve bent the 
system to symbolic link the kifaces.
I’ve worked 3 months to make a build system that support your kiface interface, 
that was blueprinted and acted without screening the work impact on the OSX and 
the

Re: [Kicad-developers] [PATCH] kiface app bundle

[Marco Serantoni]

Jean-Paul,
I've well realized that there are problems to build Kicad on OSX, i've
worked a lot since 2008 to let it work as it does now including a lot of
patches needed to make it work.
The documentation on how to compile Kicad is in
Documentation/compiling/mac-osx.txt, do you have tried following that ?
Why you doesn't contacted me that mantain OSX ?

KicadOSXBuilder is not a my product and i can't help you a lot with him,
I've aided Miguel Angel in the past to do it, then to respond to other OSX
users and the mounting request for the Kiface interface, i had to integrate
all the changes in the Cmake Building system to make the compiling more
flexible and portable (dynamic libraries,  compiled for kicad  and for the
choosen Architecture) avoiding request to installl external
libraries/packages .

The only thing you have to do is Copy all the .app to the distribution
package, all the rest you see are only intermediate files.

About the three copies of kiface as i was able to explain in a previous
mail there aren't tree and are not intended to be distributed.


--
Marco


On Mon, Apr 28, 2014 at 4:37 AM, Jean-Paul Louis  wrote:

> Hi Marco,
>
> I am sorry that you didn’t realize that there was problems with the OS X
> builds.
> I am trying to help, and to do so, I took the responsibility to build new
> BZR revs on OS X as often as possible for me.
> I was struggling to build, so I posted questions on this Mailing list and
> on the kicad-user list.
> I received help from various people, and finally I succeeded in my builds,
> but with quite a few gotchas left to resolve.
> Dick is really the one who spent time with me, and together we improved
> the OS X process, but it seems that it is broken again.
> I am currently traveling to visit my family (new grand-son), so until may
> 10th, I will not have as much time as I used to in order to do a new OS X
> build several times a week as I was doing before.
> I tried to use the KicadOSXBuilder script from github, but never reached
> the end of the script. It crashed on step 5.
>
> So I decided to start from scratch. For OS X build, the Cmake is still
> badly broken, as the build will not complete as downloaded from the
> repository. So I created a Bash script to do some repairs of the process
> (thanks to Adam and Dick mostly).
> As currently existing, the "make install” process is still broken because
> the OS X bundles end-up in a bin directory, which is not OS X standard
> behavior. Thanks to Dick help, I had a good build with a few symlinks to
> have only one copy of the kiface files.
> This was until 4810 to 4817. I tried to build yesterday (I forgot the BZR
> number) with a fresh install to create a new baseline in order to test the
> patch from Dick, but I failed miserably, as I could not build anymore.
> Tomorrow Monday, I will try to get some time to do a new build, and will
> report here my findings.
> I am using the latest version of the tools (OS X 10.9.1 - Xcode 5.1 -
> Developer tools )
> To clear the air about the 3 versions of kiface, we were looking at the
> result of the install in the /Applications/KiCad directory.
> There was one copy of the kiface files in that directory with all the
> *.app bundles, and another one kiface file in each of the bundles.
> That makes for two copies. Then in order to work, we needed a kiface for
> eeschema, cvpcb and pcbnew in the kicad bundle. That’s the third copy.
> With Dick help, I deleted all the kiface files from the install directory
> (/Applications/KiCad), and added the 3 symlinks in the kicad bundle.
> So I am saying that the Cmake process needs to be fixed in order to have a
> clean build under OS X, and also a clean install.
> Then we will be able to create a distribution process for OS X users that
> cannot or do not want to build, but would like to use Kicad on OS X
> natively.
>
> Jean-Paul
>
>
> On Apr 27, 2014, at 8:25 PM, Marco Serantoni 
> wrote:
>
>
> On 27/apr/2014, at 23:36, Dick Hollenbeck  wrote:
>
> Dick
> I’m there, i wish ask to you and bug reporters to send a mail in CC
> directly to me if there are urgent and important things about OSX.
> I’ven always the time to read the Developer ML during my work peaks, sorry.
>
> Marco (or in his continued absence, any other OSX developer),
>
> 1)
> After reading for a few minutes about app bundles on wikipedia, I am
> thinking we can
> eliminate the copy of the *.kiface file which is up at the directory where
> the *.app files
> exist.
>
> Do you agree?
>
> If so, please look at this patch as a proposed strategy for all but the
> kicad.app.  This
> only deals with pcbnew.app as a trial balloon.  The trick is to build the
> *.kiface module
> down in the bundle right out of the get g

Re: [Kicad-developers] OSX - Issue with the last Compiler Update (again) 11/April/2014

[Marco Serantoni]

On 28/apr/2014, at 21:44, Maciej Sumiński  wrote:

Great Maciej, please commit it :)

Bye

> Hi Marco,
> 
> I am currently away from CERN, so I do not have any access to OS X at the 
> moment. Usually, when I hear about errors related to Mac, I build KiCad with 
> clang under Linux, but this time it is not enough (everything compiles fine 
> on my machine).
> I see that you have already changed the conflicting define. Does it solve the 
> problem? If so, I would suggest one more minor modification (in the 
> attachment).
> 
> Regards,
> Orson
> 
> On 04/27/2014 03:09 PM, Marco Serantoni wrote:
>> Maciej,
>> After the last update of the compiler on OSX done the 11/ April i’ve a
>> conflict in the headers.
>> How we can circumvent this issue and let the code compile ?
>> Under is the point, in attachment there is an rtf file with the complete
>> error, do you have suggestions ?
>> 
>> 
>> In file included from
>> /Users/marco/Development/product/boost_root/include/boost/polygon/polygon.hpp:65:
>> /Users/marco/Development/product/boost_root/include/boost/polygon/polygon_90_set_traits.hpp:187:86:
>> warning: template argument uses unnamed
>>   type [-Wunnamed-type-template-args]
>> typedef typename gtl_same_type> geometry_concept::type>::type type;
>> 
>>   ^
>> /Users/marco/Development/product/boost_root/include/boost/polygon/detail/polygon_90_set_view.hpp:466:30:
>> note: in instantiation of template
>>   class 'boost::polygon::is_mutable_polygon_90_set_type<> enum at
>> 
>> /System/Library/Frameworks/Security.framework/Headers/cssmtype.h:84:1>
>> >' requested here
>> typename gtl_if> is_mutable_polygon_90_set_type::type>::type,
>>  ^
>> /Users/marco/Development/product/boost_root/include/boost/polygon/detail/polygon_90_set_view.hpp:469:3:
>> note: while substituting deduced
>>   template arguments into function template 'operator+' [with
>> geometry_type_1 = > 
>> /System/Library/Frameworks/Security.framework/Headers/cssmtype.h:84:1>,
>> coordinate_type_1 = int]
>>   operator+(const geometry_type_1& lvalue, coordinate_type_1 rvalue) {
>>   ^
>> /System/Library/Frameworks/Security.framework/Headers/cssmtype.h:84:1:
>> note: unnamed type used in template argument was declared here
>> enum {
>> ^
>> /System/Library/Frameworks/Security.framework/Headers/cssmtype.h:714:12:
>> error: non-friend class member 'min' cannot have a qualified name
>> uint32 Min; /* inclusive minimum value */
>>^~~
>> /Users/marco/Development/product/include/geometry/rtree.h:35:20: note:
>> expanded from macro 'Min'
>>   #define Min std::min
>>   ~^
> 
> 


___
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] [PATCH] kiface app bundle

[Marco Serantoni]

On 28/apr/2014, at 19:25, Jean-Paul Louis  wrote:

Jean-Paul,
You should try bzr 4835, look to ML “OSX - Issue with the last Compiler 
Update”, as you see is not always simple to keep up the ML.
I’ve waited you on IRC until 1am Local time, then i’m an Human i need sleeptime 
too.

You weren’t supposed to use install as i said to you in the mails you have to 
just copy the only bundles in place, in the case zip/package them for further 
distribution.
I’ve also suggested to you to use cp.

If you want to shortcut exec from the repository build root:
mkdir -p /Applications/Kicad
cp -R ./bitmap2component/bitmap2component.app /Applications/Kicad
cp -R ./cvpcb/cvpcb.app /Applications/Kicad
cp -R ./eeschema/eeschema.app /Applications/Kicad
cp -R ./gerbview/gerbview.app /Applications/Kicad
cp -R ./kicad/kicad.app /Applications/Kicad
cp -R ./pagelayout_editor/pl_editor.app /Applications/Kicad
cp -R ./pcb_calculator/pcb_calculator.app /Applications/Kicad
cp -R ./pcbnew/pcbnew.app /Applications/Kicad

Bye,
—
Marco

> Marco,
> 
> I have been working on the Mac OS X build for quite a while now, and I was 
> successful in the build.
> The weak part was the install, as the default install was installing the 
> bundles in /usr/local/bin which is wrong for Apple OS X.
> So I added a “-DCMAKE_INSTALL_PREFIX=$INSTALL_DIR” in my script with 
> INSTALL_DIR=/Applications/KiCad.
> The Cmake was still wrong because the bundles were installed in 
> "/Applications/KiCad/bin” instead of “/Applications/KiCad”.
> Adam Wolf helped me to have the script running as it is described in the file 
> you mentioned in your previous email.
> I succeeded the first time February 27th, and I posted an email here, so you 
> can find it in the ML archive.
> On March 13th, you told me to connect on IRC. I went there, and waited for 
> hours without anyone ever talking. I only saw a bunch of users all asleep, 
> maybe that was because of the time difference between USA and Europe.
> We had several emails between you, Adam and me around from March 21st to 
> March 26th, so I progressed in my build. That is the period when Dick started 
> to help me.
> 
> I modified my script to move the files to the right place, and that was not 
> good enough. That’s when Dick helped me a lot to understand what was wrong. I 
> posted all the steps in this mailing list, so you should have been made aware 
> of the issues
> few weeks ago.
> 
> As of today, the OS X build (BZR4830) is broken again.
>  ^
> 174 warnings and 2 errors generated.
> make[2]: *** [pcbnew/router/CMakeFiles/pnsrouter.dir/pns_router.cpp.o] Error 1
> make[1]: *** [pcbnew/router/CMakeFiles/pnsrouter.dir/all] Error 2
> make: *** [all] Error 2
> Mon Apr 28 12:30:08 EDT 2014
> 
> Building KiCad for OS X took 0:17:09.
> 
> jean-pauls-mbp:Soft_Dev jean-paullouis$ cat ~/Soft_Dev/kicad-build/version.h 
> | grep BZR
> #define KICAD_BUILD_VERSION "(2014-04-25 BZR 4830)"
> jean-pauls-mbp:Soft_Dev jean-paullouis$ 
> 
> Will you help to fix this?
> 
> Jean-Paul
> 
> 
> 
> 
> On Apr 28, 2014, at 8:26 AM, Marco Serantoni  
> wrote:
> 
>> realized
> 

___
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] [PATCH] kiface app bundle

[Marco Serantoni]

Jean-Paul,
Ok, i try to re-state: you weren't supposed to do a make install, just copy
the binaries/bundle in place.
On OSX all what you need have be inside the bundles, is how the system work
and users expect, since there is no need for /usr/share or other things
there is need to issue a make install, is enough copy the .app where you
want (Installation Directory; DMG; or any other distributing package).
All what is outside kicad.app, eeschema.app, etc are not to be distribuited
(so no 3 releases of files).

The issue with kicad.app has started with release
4807<http://bazaar.launchpad.net/%7Ekicad-product-committers/kicad/product/revision/4807>(10
days ago) when was kifaced (previous was not).
There is no radical departure from apple concept of bundle, the issue was
how to make symbolic link from eeschema.app from the building tree that
still valid also when deployed in the final destination.

There can be several approaches for the symbolic link:
Use an absolute path like
/Application/Kicad/eeschema.app/[...]/eeschema.kiface, that restrict where
to place the binaries: will create more problems than the one he fix, users
on OSX has not a fixed path where to place binaries/bundles there is the
high risk that those will point to nowhere, moreover borns an issues for
developers: they have to install the application to debug or develop.
Develop an application doing an install each time will be really time
consuming and not pratical at all.

Relative path:
The use of the relative link is fine and is what i've used: the issue here
is 1 level of difference between the repository where you build and install
place, where all the bundle/binaries are at the same level.

$REPOSITORY/eeschema/eeschema.app
$REPOSITORY/kicad/kicad.app

Versus

$INSTALLDIR/eeschema.app
$INSTALLDIR/kicad.app

That means that the number of ".." will be different in relative symbolic
link.

I've solved this doing symbolic links in the $REPOSITOR/kicad/ to
applications making it as they were installed, then link them, moreover
this solution makes the developer also be able to test the application
buttons in place.

After applications link you will find

$REPOSITORY/kicad/kicad.app
$REPOSITORY/kicad/eeschema.app -> ../eeschema/eeschema.app

Then you are able to do the right symbolik link.

Regarding the distribution, i can assure that since 2009 binaries could be
shipped in a single dmg, .zip, .tar.gz.
I can also assure you that there are a much more packagers than developers
on OSX, if they find difficult do a copy instead a 'make install' to ease
the developer work and let they work better they will be much more
frustrated soon.

Bye,

--
Marco


On Tue, Apr 29, 2014 at 3:01 AM, Jean-Paul Louis  wrote:

> Marco,
>
> It looks like the previous problem has been fixed, and I am now able to
> complete the build.
> I just finished to build the BZR4837 without trouble.
> I understand what you said about the install. but the cake process is not
> working right.
> During the "make install", a “bin" directory is added to the default
> install directory.
> The apps should be in /Applications/Kicad/, but the "make install” put
> them in
> /Applications/Kicad/bin/. That’s why I said that the install process is
> broken.
> I made cmake use "/Applications/Kicad" by adding the switch
>  -DCMAKE_INSTALL_PREFIX=$INSTALL_DIR to cmake and I add previously set
> INSTALL_DIR to /Applications/Kicad in my script.
> So the part of cmake that needs to be fixed is the area where the /bin is
> added to the install path.
> It is ok to have for UNIX, but not for APPLE. Then, at the end,  we need
> to fix the kicad bundle.
> Symbolic links is one way to fix the kiface issue with an Apple bundle. I
> also understand that
> kiface concept is a radical departure from the Apple concept of bundle,
> but Dick idea of the symlinks
> worked nicely when I tested it. I need to consolidate all the experiments
> that we did into a single document
> explaining how to fix the broken process until we can fix the cmake for
> kicad on OS X.
>
> I am willing to help testing the OS X builds until we can make a package
> (DMG) for easy distribution.
> Then we might get more leverage as OS X users if more people use Kicad on
> OS X.
> A lot of people using Mac OS X are frustrated because they do not find a
> decent version of Kicad.
> So they go use other CAD software like Eagle, GEDA, and many others that
> are nowhere near the performance
> of Kicad.
>
> Jean-Paul
>
>
> On Apr 28, 2014, at 4:46 PM, Marco Serantoni 
> wrote:
>
>
> On 28/apr/2014, at 19:25, Jean-Paul Louis  wrote:
>
> Jean-Paul,
> You should try bzr 4835, look to ML “OSX - Issue with the last Compiler
> Update”, as you see is not always simple to keep up the ML.
> I’ve waited you on I

Re: [Kicad-developers] [PATCH] kiface app bundle

[Marco Serantoni]

That DOES the symlinks, but feel free to script it :)

Jean-Paul which existing project you wish to open the first time you launch
kicad, and where should it be located ?
Probably before doing that probably is better look to bug #1313321

Your intention with the messagebox is to create a new custom one overriding
the native one ?

--
Marco


On Wed, Apr 30, 2014 at 2:57 PM, Jean-Paul Louis  wrote:

> Marco,
>
> Thank you for your reply.
> I can live with the symlinks. I will add them to my script until it can be
> done with the cmake.
> I will post a bug report about the pop-up error message. It should be
> possible to create a new message
> box (child of the current) and overload the creation of the text-box with
> a scrolling text-box. I will have to look at the
> wxwidgets API.
> About the nonane.pro, I think it might be a work-around by loading an
> existing project before doing anything. so the nonane.pro
> might not be saved at all.
>
> I need help to complete the update of the cake process to include the
> install with “make install”. This would be a much better process that is
> easy to customize with variables passed to the cmake.
> I need to learn more about the cmake.
>
> Jean-Paul
> AC9GH
>
> On Apr 30, 2014, at 6:18 AM, Marco Serantoni 
> wrote:
>
> Jean-Paul,
> About missin kifaces, that was the reason why i've asked you to use r4835,
> that does that links.
>
> - About noname.pro issue, i can agree with you, where it should be placed
> for you ? This would be a special code for OSX, that is not well seen by
> other platform developers.
> - On the message box, this is wx-widget standard widget i dubt we can
> insert scrollbars, probably could be easier truncate the output.
>
> On those two issues at the moment I can't help you.
>
> --
> Marco
>
>
___
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_DATA on OS X

[Marco Serantoni]

Adam,
I'm for /Library & ~/Library, first because they are coherent with the
enviroment and wxStandardPaths.
We have discussed about that with Wayne not much months ago, we agree from
much time about the correctness to use that class without reinvent the
wheel, the differences were about ::GetUserConfigDir ::GetUserDataDir and
fp_table, now the discussion could be easier to understand with updated
documentation.

http://docs.wxwidgets.org/trunk/classwx_standard_paths.html#a7c7cf595d94d29147360d031647476b0


Placing things inside a bundle is nice, but is nice only for Support files
that are immutable, libraries are not, they have  be changed.

/usr/local in osx is the same than ask an linux user to make a C:/windows
directory in its root, moreover the Finder could not navigate those
directory easly.


Try to take a look to common/systemdirsappend.cpp, i'vent seen deepier the
changes but i don't think that points to /usr/local.


--
Marco


On Tue, May 6, 2014 at 5:30 PM, Adam Wolf  wrote:

> Hi folks,
>
> I have been producing OS X builds for a while now, and I'm working on
> addressing some feedback before I start setting up the push of DMGs to
> Miguel's system.
>
> The first main feedback point is KICAD_DATA.  I apologize if this has been
> discussed before--I promise I searched in the archives for about five
> minutes before drafting this.
>
> Right now, various things like eeschema are looking at /usr/local/library,
> which isn't what we want.
>
> Some places users have suggested to me include:
> • /usr/local/share/kicad/library
> • /Library/Application Support/Kicad
>  • ~/LibraryApplication Support/Kicad
> • Inside the .app Bundle
>
> Marco and the other Mac folks, I am especially interested in your input.
>  Thanks!
>
> Adam Wolf
> Wayne and Layne, LLC
>
>
>
___
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_DATA on OS X

[Marco Serantoni]

On 06/mag/2014, at 22:59, Jean-Paul Louis  wrote:

Lower case kicad,

This choose was planned in advance, when all applications will collapse in 
kicad.app the default “application name” will be kicad.
This approach permits to use wxStandardPaths references for Application Data 
repository, since will match ::GetUserDataDir  “appinfo” 

The reason why is not already used is because each application has a different 
"application name” then:
eeschema will be -> ~/Library/Application Support/eeschema
pcbnew will be -> ~/Library/Application Support/pcbnew
etc.
So they will point to different paths.

To cirmcumvent it was choosen to hardcode it, waiting for use something more 
standard that could arrive soon.

About /Library/Application Support/kicad, i prefer it because could save a lot 
of diskspace in multiuser workstations avoiding to replicate libraries for each 
user.
If some user needs its private library could use ~/Library/Application 
Support/kicad that has the precedence over the global one.

Precendence:
~/Library/Application Support/kicad
/Library/Application Support/kicad

The first is found is used.

This arrangement optimizes diskspace that in the new SSDs Macs become again an 
issue and still provide the maximum flexibility for the users.

—
Marco



> Thanks a lot, Adam!
> 
> Now I can see my $HOME/Library.
> 
> For the Master Data Location, I would prefer /Library/Application 
> Support/Kicad,
> and a similar ~/Library/Application Support/Kicad, for the personal or 
> project libraries.
> 
> Jean-Paul
> AC9GH
> 
> On May 6, 2014, at 4:08 PM, Adam Wolf  wrote:
> 
>> http://www.macworld.com/article/2057221/how-to-view-the-library-folder-in-mavericks.html
>> 
>> 
>> On Tue, May 6, 2014 at 3:04 PM, louijp  wrote:
>> Marco,
>> /Library is not visible in my finder.
>> I have to use a terminal to go there, and I do not have a ~/Library. That's 
>> the default on a new Macbook pro. But that might be an acceptable choice if 
>> you tell me how to modify the Finder app to see the /Library directory.
>> 
>> My $0.02,
>> Jean-Paul
>> 
>> 
>> Sent from my Verizon Wireless 4G LTE smartphone
>> 
>> 
>>  Original message 
>> From: Marco Serantoni 
>> Date:2014/05/06 12:59 PM (GMT-05:00) 
>> To: Adam Wolf 
>> Cc: kicad-developers@lists.launchpad.net 
>> Subject: Re: [Kicad-developers] KICAD_DATA on OS X 
>> 
>> Adam,
>> I'm for /Library & ~/Library, first because they are coherent with the 
>> enviroment and wxStandardPaths.
>> We have discussed about that with Wayne not much months ago, we agree from 
>> much time about the correctness to use that class without reinvent the 
>> wheel, the differences were about ::GetUserConfigDir ::GetUserDataDir and 
>> fp_table, now the discussion could be easier to understand with updated 
>> documentation.
>> 
>> http://docs.wxwidgets.org/trunk/classwx_standard_paths.html#a7c7cf595d94d29147360d031647476b0
>> 
>> 
>> Placing things inside a bundle is nice, but is nice only for Support files 
>> that are immutable, libraries are not, they have  be changed.
>> 
>> /usr/local in osx is the same than ask an linux user to make a C:/windows 
>> directory in its root, moreover the Finder could not navigate those 
>> directory easly.
>> 
>> 
>> Try to take a look to common/systemdirsappend.cpp, i'vent seen deepier the 
>> changes but i don't think that points to /usr/local.
>> 
>> 
>> --
>> Marco
>> 
>> 
>> On Tue, May 6, 2014 at 5:30 PM, Adam Wolf  wrote:
>> Hi folks,
>> 
>> I have been producing OS X builds for a while now, and I'm working on 
>> addressing some feedback before I start setting up the push of DMGs to 
>> Miguel's system.
>> 
>> The first main feedback point is KICAD_DATA.  I apologize if this has been 
>> discussed before--I promise I searched in the archives for about five 
>> minutes before drafting this.
>> 
>> Right now, various things like eeschema are looking at /usr/local/library, 
>> which isn't what we want.
>> 
>> Some places users have suggested to me include:
>>  •   /usr/local/share/kicad/library
>>  •   /Library/Application Support/Kicad
>>  •   ~/LibraryApplication Support/Kicad
>>  •   Inside the .app Bundle
>> 
>> Marco and the other Mac folks, I am especially interested in your input.  
>> Thanks!
>> 
>> Adam Wolf
>> Wayne and Layne, LLC
>> 
>> 
>> 
>> 
> 


___
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] Last kicad button is broken (pl_editor) Build BZR4854 OSX

[Marco Serantoni]

On 08/mag/2014, at 20:52, Dick Hollenbeck  wrote:

> On 05/08/2014 01:21 PM, jp charras wrote:
>> Le 08/05/2014 18:28, Jean-Paul Louis a écrit :
>>> Hi Developpers,
>>> 
>>> I found a weird error that I never noticed before. The screenshot below
>>> was taken just after clicking on the last button on the right. As usual,
>>> it does not work, but the message in the window is weird. As you can see
>>> the message refer to the guts of the pcb_calculator app, and the
>>> software expect to find the pl_editor there.
>>> Is that a normal behavior or a bug.
>>> 
>>> Jean-Paul
>> 
>> Strange!
>> But I do not have this issue.
>> 
>> 
> 
> I think my Mac OS patch fixed this.  But it was never tested.  Apparently the 
> KiCad Mac
> team is unwilling to test patches, and in fact I was scolded for offering it.

There is a mistype at include/common.h @ 105, should be changed from:
#define PL_EDITOR_EXE  wxT( "pcb_calculator.app/Contents/MacOS/pl_editor" )
to
#define PL_EDITOR_EXE  wxT( “pl_editor.app/Contents/MacOS/pl_editor" )

Since as you know I can’t fix it, someone could change that line ?

Thanks,
—
Marco___
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-lib-committers] Issues with BZR4854 for OS X

[Marco Serantoni]

On 08/mag/2014, at 08:10, Dick Hollenbeck  wrote:

> On 05/07/2014 02:17 AM, jp charras wrote:
>> Le 07/05/2014 05:07, Jean-Paul Louis a écrit :
>>> Hi Marco,
>>> 
>>> I just finished building BZR4854 according to your instructions, and
>>> still kicad does not work properly on OSX.
>>> 
>>> See screen capture below.
>>> I remember exchanging emails with Dick in this mailing list, and there was 
>>> a fix for that, but it was never applied to the source code for OS X on the 
>>> repository. 
>>> 
>>> The behavior of the kicad buttons is still not consistent. the first three 
>>> (3) using kiface symlink are working fine, but the other four (4) are not.
>>> So we have three separate behaviors.
>>> Buttons 1, 2 and 3 are fine (thanks to symlink).
>>> Buttons 4, 5 and 6 start the application minimized, so we need to go to the 
>>> dock, and click on the icon to open the app window.
>>> Button 7 does not work as the app (pl_editor) open and close immediately.
>>> 
>>> Please see Dick for his insights on how to fix it. He was very helpful to 
>>> me when you were not responding to the issues. I will be back home after 
>>> May 12th, so I will have more time to give you feedback inn the new builds.
>>> 
>>> Last, I am not sure how to install properly the libraries. Is there a 
>>> script that will work for OS X? Something that I could add to my script 
>>> (Bash script BuildKicad-OSX) attached to have everything at once.
>>> 
>>> Thank you for your help.
>>> 
>>> Jean-Paul
>>> AC9GH
>> 
>> I do not know anything to OSX, but it is for me an unix system.
>> 
>> Therefore I am thinking your script is missing something. in section:
>> echo Fixing kicad.app issue with three symlinks to kiface for eeschema,
>> cvpcb and pcbnew
>> cd ${INSTALL_DIR}/kicad.app/Contents/MacOS/
>> ln -s
>> ~/Soft_Dev/kicad-build/eeschema/eeschema.app/Contents/MacOS/_eeschema.kiface
>> .
>> ln -s ~/Soft_Dev/kicad-build/cvpcb/cvpcb.app/Contents/MacOS/_cvpcb.kiface .
>> ln -s
>> ~/Soft_Dev/kicad-build/pcbnew/pcbnew.app/Contents/MacOS/_pcbnew.kiface .
>> 
>> Symbolic links are made for eeschema, cvpcb and pcbnew only.
>> They are missing for gerbview, pcb_calculator and pl_editor.
>> This is strange for me.
>> 
>> You should have 6 symlinks, not 3.
>> 

Jean-Paul,
If you do symbolic links in that way the binaries: will not work on another 
system or if you remove binaries from Soft_Dev.
Those are ABSOLUTE links, if you wish distribute those you will need relative 
ones.


> 
> Currently only those 3 binaries are loaded as kiface files, i.e. in process.  
> The rest of
> the binaries are loaded as new processes, because I was unable to find a 
> compelling reason
> not to do so.  They tend to edit files which are not as tightly bound to each 
> other as
> 
> *.sch and *.kicad_pcb are.
> 
> The problem with the Mac will continue under such circumstances.  When the 
> executable is
> launched as a separate process, not an in-process kiface, then the Mac seems 
> shy about
> bringing it to the top of the world.

https://bugs.launchpad.net/kicad/+bug/1154859


> It is not a bug in Kicad, it is a bug in the Mac OS as far as I can see.  It 
> really is of
> no interest to me anymore.
> 
> Furthermore having OSX scripts do things that the CMakeLists.txt file should 
> be doing is
> curious to me.  I really don't care to participate.  AFAIAC, the entire Mac 
> support should
> can be kept in a separate branch until the project has an English speaking 
> Mac developer
> who can cooperate as part of a team.
> There's no reason a single patch file cannot be maintained that overlays a 
> working tree.
> These patches are easy to generate simply by doing a diff from the merge of a 
> Mac branch.
> 
> My Mac patch handled these issues in the CMakeLists.txt files, where policy 
> like this
> should be made.

There are two ways to approach the world: the first is be self-referenced, the 
second is to learn 
something from the difference and understand that those differences could be an 
enrichment.

This happens also for OSes:  This is the challenge of this project, and why has 
its appeal for the world.
 
I wish suggest you also to think what happened if someone has used your same 
sentence changing English with French some years ago.

—
Marco




___
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 road map.

[Marco Serantoni]

jp, probably he wants an incremental DRC.
Could be usefully check and signalate the error during the drawing, such
kind of feature could avoid an feedback/reiteration phase.


--
Marco


On Mon, May 19, 2014 at 12:05 PM, jp charras  wrote:

> Le 19/05/2014 10:55, Tomasz Wlostowski a écrit :
> > On 19.05.2014 01:45, Wayne Stambaugh wrote:
> >> I finally got around to finishing up and committing the initial draft
> >> KiCad road map.  You can build it into the standard developer
> >> documentation by running `make doxygen-docs` or as a stand alone road
> >> map by running `make dev-docs`.  I'm still not terribly thrilled with
> >> the formatting but I'm not a CSS developer so I'll stick with the
> >> default Doxygen formatting for now.
> >>
> >
> > Hi Wayne,
> >
> > Thanks a lot, great document!
> >
> > I found one package missing (wrs to the CERN roadmap).
> >
> > Improved DRC:
> > Depends on: geometry library
> > Goal: Additional DRC checks.
> > Status: planning
> > Plan:
> > - replace all existing geometry code with the new geometry library.
> > - ensure there is no floating point in any clearance-related
> > calculations (rounding!).
> > - add DRC checks: component/silkscreen/mask clearance.
> > - fix polygon stitching issue
> > - remove DRC-related limitations such as no arcs/text on copper layers.
> > - on-line DRC (for less CPU-consuming checks).
> > - add option for saving/loading DRC rules settings
> >
> > -- my 5 cents,
> > Tom
>
> Thanks, Wayne.
>
> Tom,
> For my info, what do you mean with "on-line DRC (for less CPU-consuming
> checks)" ? (the current on-line DRC is not very CPU time consuming).
>
> I am thinking one other package could be added to Gerber plot generation
> + Gerbview:
> This is the "Gerber file function attribute".
>
>
> see:
>
> www.ucamco.com/files/downloads/file/5/Extending_the_Gerber_Format_with_Attributes.pdf
> and:
>
> www.ucamco.com/files/downloads/file/22/Kick_Starting_a_Revolution_IPC-2581_Meets_Gerber.pdf
>
> (Karel Tavernier, the technical manager of Ucamco contacted me some time
> ago about this extension).
>
>
> A pending issue in current Gerber format is the fact you are never
> surehow gerber files and stackup are related (mainly for internal layers).
>
> This is an extension to add inside Gerber files
> the ".FileFunction file attribute" which identifies the function of the
> file.
> Add also a "stackup" file descriptor ( see an idea in
> Kick_Starting_a_Revolution_IPC-2581_Meets_Gerber.pdf), which could be
> read by Gerbview to automatically load gerber files
>
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> 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-users] Recent builds on OSX working?

[Marco Serantoni]

tic linking.
>> I did that because in the past dynamic linking didn’t produce portable
>> applications.
>> That is, they contained a reference to the wxWidgets libs at the place
>> when being built and haven’t been copied to the app bundle… and all the
>> usual fix-scripts to copy those libs into the bundle failed for me
>> (problems with the symlinks)… and I didn’t want to fix every path manually.
>>
>> I looked around a bit and found some cmake modules that should be able to
>> produce portable application bundles… I’ll try to add/change that in the
>> cmake files… if I succeed, I will of course propose a patch.
>>
>>
>> Thanks,
>> Bernhard
>>
>> On 24.05.2014, at 04:16, Dick Hollenbeck  wrote:
>>
>> On 05/23/2014 12:31 PM, Jean-Paul Louis wrote:
>>
>> Hi Bernhard,
>>
>> I am attaching my script to this email.
>> Some of the stuff in the script might not be needed anymore, but I will
>> clean it up when I have time.
>>
>> After the “make” is finished, I skip the “make install” as it is not yet
>> capable to work.
>> So I just copy the bundles (*.app) to "/Applications/kicad” (see towards
>> the end of the script).
>>
>> Thanks to the help of Marco, Adam and even more so from Dick of the
>> development team, I simplified the script so it build to 100%, and Dick
>> modified the Cmake files to create the bundles with the kiface files
>> properly copied where they belongs.
>> That might by why we have duplicate kiface files (seems to be the cause
>> of the error at the end of the “make”.
>>
>> I will create the files for the ENV variables, and let you know how that
>> works.
>>
>> Regards,
>> Jean-Paul
>>
>>
>> On May 23, 2014, at 10:59 AM, Bernhard Stegmaier 
>> stegma...@sw-systems.de[kicad-users] <
>> kicad-us...@yahoogroups.com> wrote:
>>
>> Hi Jean-Paul,
>>
>>
>> can you tell me what files have to be copied where?
>> I remember some discussions about copying/linking/whatever .kiface files
>> that on the dev-list, but I didn’t find anything on first glance.
>> And yes, let’s try to fix this…
>>
>> With respect to setting the environment variables I did the following:
>> Using Linux-like ~/.profile, etc. files will set the variables only when
>> launching from command-line… not from the dock/launcher.
>> To set a variable for the launcher I made in
>> ~/Library/LaunchAgents
>> files named like
>> local.kicad.kisys3dmod.plist
>> which looks like
>> 
>> >"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
>> 
>> 
>>Label
>>local.kicad.kisys3dmod
>>EnableGlobbing
>>
>>ProgramArguments
>>
>>launchctl
>>setenv
>>KISYS3DMOD
>>~/10 - Projekte/KiCad/Modules
>>
>>RunAtLoad
>>
>> 
>> 
>> and in the case sets KISYS3DMOD variable. I did the same for the other
>> variables I need (I didn’t find any solution to set more than one variable
>> in a single file). The files will be loaded automatically on login (as far
>> as I remember) or you can test them with “launchctl load …”.
>> But caution: those files will only set it for the launcher, not the
>> shell… while searching for that I found some shell scripting that can be
>> added to e.g., .profile reading the values from launched so that you don’t
>> have to maintain it in two places if you need that, but I didn’t need it so
>> I don’t have a link at hand.
>>
>> This solution works well for me both on 10.8 and 10.9.
>>
>> The KiCadOSXBuilder creates a wrapper-script for setting the variables,
>> but I didn’t like that approach, because for me those variables are
>> machine-specific (especially the library stuff).
>> So, it shouldn’t be hardcoded somewhere in the application bundle, but
>> defined by the machine/account itself.
>>
>>
>> Regards,
>> Bernhard
>>
>> On 23.05.2014, at 16:27, Jean-Paul Louis lou...@yahoo.com [kicad-users] <
>> kicad-us...@yahoogroups.com> wrote:
>>
>> Hi Bernhard,
>>
>> I use OS X 10.9.2 and I keep trying the most recents BZR. I came to the
>> same conclusion about some failures due to duplicate work copying files
>> into the OS X bundles.
>>
>> I use a bash script fairly raw to copy the files from the build to the
>> /Applications/kicad directory.
>> eeschema sort of work, but cannot find kicad.pro template.
>> it does complain about a missing 

Re: [Kicad-developers] [PATCH] Fix osx_fixbundle.sh for building on OSX

[Marco Serantoni]

On 29/mag/2014, at 20:44, jp charras  wrote:

Jp,
Should be not mistakes ;)


> Le 29/05/2014 19:11, Bernhard Stegmaier a écrit :
>> Hi,
>> 
>> oh, sorry for that… I have some other small changes in my local repository.
>> I guess that's why.
> 
> I just need to be sure there was no mistake.
> A warning is not a problem, but only if it is expected.
> 
> I committed your patch.
> 
>> 
>> General question:
>> If I push my local repository to my own launchpad branch, is it then
>> more easy to pull a fix from there even if I have some (unrelated)
>> changes in my branch?
>> Otherwise I would always have to maintain changes in 2 branches before
>> sending a patch to ML...
>> 
>> 
>> Regards,
>> Bernhard
> 
> Avoiding to maintain 2 branches is better.
> 
> If you are thinking a patch can create issues, you just can have a
> (pristine) copy of launchpad kicad branch, and see what happens when
> applying the patch to this branch.
> 
> If there is a warning, just say "when applying my patch, you could have
> a warning, but this is OK".
> 
> 
> -- 
> Jean-Pierre CHARRAS
> 
> ___
> 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] [PATCH] Fix wrong "&&" usage

[Marco Serantoni]

A lot more picky, you got correct, that have to be a bitwise comparation.

Being Cocoa UI API vectorial, misses pixel logical operations, the "erase"
made with XOR on the pixels has been substituted with a trasparent Overlay
that guests "immediate" draws, for immediate i mean "moving components or
tracks".
This is the reason why i've introduced the cocoa patch for wxOverlay and
added that pieces of code.

Tomaz and Orson are now working and doing a nice job with GAL, so this part
of code, binded to the old drawing code, will be purged soon.


--
Marco


On Fri, May 30, 2014 at 2:56 PM, Bernhard Stegmaier  wrote:

> Hi,
>
> clang seems to be much more picky than gcc… attached a patch that fixes 2
> warnings I spotted during my last build experiments (being obviously really
> a bug).
> I don't know what it will improve, though.
>
>
> Regards,
> Bernhard
>
>
>
>
>
>
>
> ___
> 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] [PATCH] Build broken on OSX since rev. 4895

[Marco Serantoni]

On 29/mag/2014, at 18:21, jp charras  wrote:

> Le 29/05/2014 11:45, Bernhard Stegmaier a écrit :
>> Hi,
>> 
>> build on OSX is broken since rev. 4895 (I guess)… 
>> The include  is not found because __DARWIN__ is not set. Moving the 
>> include of glcanvas.h from the .cpp to the beginning of the header seems to 
>> fix this. Further, it seems as if no special library is needed to link 
>> against - especially “GLU” doesn’t exist (and pcbnew also does link glu32 
>> only on Windows).
>> 
>> The attached patch fixes at least the compilation problem for me on OSX and 
>> corrects the include guard (copy&paste bug I guess).
> I just committed changes for OSX compatibility.

Gives a lot of warnings under gcc (10.8) but seems work.

/Users/marco/Development/product/utils/idftools/idf2vrml.cpp:109: warning: 
missing braces around initializer for 'double [3]'

—
Marco___
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] OS X Menus do not have Icons (BZR 4931)

[Marco Serantoni]

On 07/giu/2014, at 13:11, Nick Østergaard  wrote:

Nick,
OSX has not menus icons by design, good hint.
wx-widgets ignores them too.


> Hello
> 
> I am no an OSX user, but I know that OSX generally don't use these
> menu icons. It is also described in [1], see the section "Using Icons
> in Menus".
> 
> I have also seen in Gnome 3 that it has been removed. I cann't see the
> menus in my Gnome setup, even though I try to enable it via gconf.
> 
> I don't like this, I like the icons in the menu, they make it easier
> to find the wanted menu entry by looking at these small pictograms.
> IMO this is a matter of fact that some designers don't actually use
> their computer.
> 
> [1] 
> https://developer.apple.com/library/mac/documentation/userexperience/conceptual/applehiguidelines/Menus/Menus.html
> 
> 2014-06-07 10:15 GMT+02:00 jp charras :
>> Le 07/06/2014 07:00, Jean-Paul Louis a écrit :
>>> I did not pay attention to it until I reread the KiCad Manual tonight.
>>> Here is the capture of the kicad menu on my Mac (OS X 10.9.3)
>>> 
>>> 
>>> Here is the copy of the Manual. We can see that the Mac is missing the
>>> Icons. I do not know if this is normal, or something that needs to be
>>> sorted out by the KiCad OS X gurus.
>>> 
>>> 
>>> Jean-Paul
>>> AC9GH
>> 
>> This is optional.
>> 
>> You can run cmake with option -DUSE_IMAGES_IN_MENUS=ON
>> 
>> the default is OFF for OSX and ON for other systems (due to some OS X
>> guru but not KiCad guru)
>> 
>> I do not know if this is a bad or good option (I am not an OSX user).
>> OSX users could give their opinion about this option.
>> 
>> (see CMakeLists.txt, line 276)
>> 

___
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] OS X Build - Hot-key list error in pl_editor

[Marco Serantoni]

On 07/giu/2014, at 22:46, Jean-Paul Louis  wrote:

Mac Keyboard has both HOME and END, you were probably referring to 
compact/notebook one that requires the fn key.
Apple doesn’t hates no “button", just optimize the keyboard for common use and 
documents how to use them.

I can assure as PC notebook user that Fn key exists also on PC notebooks with 
weird acer/hp/ibm keyboards.

This is the normal Apple keyboard :
http://store.apple.com/us/product/MB110LL

This is the compact Apple keyboard:
http://store.apple.com/us/product/MC184H

HP and other vendors uses on notebooks the same Apple solution for HOME/END 
(but i still hate how they design “enter” key).
http://www.digitaltrends.com/wp-content/uploads/2011/12/hp-elitebook-2560p-silver-keyboard.jpg

No alarm, no issue, no bug, just normal design.

—
Marco


> BZR 4932 fixed the problem.
> I was not fully awake when I was asking for “Home” and “End” keys.
> Apple hates those, but accepted a replacement:
> 
> Home = Function Key (Fn) + Left Arrow
> End = Function Key (Fn) + Right Arrow
> 
> Sorry for complaining too much.
> 
> Jean-Paul
> AC9GH
> 
>> Hello Marco,
>> 
>> I found a bug in pl_editor. As you can see below, there are two hot keys for 
>> Move Item.
>> I’m sure it is a typo, as I would hate to have the Delete key assigned to 
>> move item, unless it was meant to move to the trash.
>> Also the Zoom Auto use the Home key which is missing on Apple keyboards (at 
>> least I could not find it), but I am still a newbie at OS X. Same thing with 
>> the End key (Mouse Left DClick).
>> I am going to read OS X for dummies to figure out where are the Home and End 
>> keys.
>> 
>> Jean-Paul
>> AC9GH
>> 
>> 
> 


___
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] OSX redraw artifact fixes

[Marco Serantoni]

On 11/giu/2014, at 21:13, Dick Hollenbeck  wrote:

> On 06/11/2014 02:07 PM, Dick Hollenbeck wrote:
>> On 06/11/2014 01:54 PM, Jean-Paul Louis wrote:
>>> Thank you Bernhard.
>>> 
>>> I would much prefer to apply your patches to the last kicad BZR at least 
>>> until someone
>>> from the dev team has a chance to look at those and approve them. Do you 
>>> mind telling
>>> us what you did change? Please attach a patch to your email for us to 
>>> review it.
>>> 
>>> Regards, Jean-Paul
>> 
>> 
>> $ bzr diff -r 4939..4941  
>> https://code.launchpad.net/~stegmaier/kicad/kicad-osx >
>> /tmp/bernard.patch
> 
> 
> Seems OK to me, if it works.
Looks nice for me too :)

Good work Berhhard !

—
Marco
___
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] Mac OS X nightlies are up!

[Marco Serantoni]

Good Job Guys..

> On 24/feb/2015, at 06:58, Johannes Maibaum  wrote:
> 
> Hi Adam,
> 
> I just tried your build, and it works like a charm. I'm now looking forward 
> to regularly
> using the Kicad OSX nightlies. Again, thank you for all your effort improving 
> the Kicad
> experience for OSX users!
> 
> 
> Best,
> Johannes
> 
>> Am 23.02.2015 um 22:48 schrieb Adam Wolf :
>> 
>> Hi Johannes,
>> 
>> Can you try the build here:
>> 
>> http://downloads.kicad-pcb.org/osx/DEBUG/
>> 
>> Please let me know if it is the exact same crash, a different one, or if by 
>> some miracle it works :)
>> 
>> Thanks!
>> 
>> Adam Wolf
>> 
>> On Mon, Feb 23, 2015 at 1:00 PM, Nick Østergaard  wrote:


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

[Marco Serantoni]

Wayne,
At the time we were in a timeframe where was ppc finishing his fading out, i386 
in mid term, x86_64 was not already fully adopted.
KiFace work begin was forcing a migration from the old default behavior of 
static linking to dynamic.
Now: 
i386 fading/faded out completely. 
The linking is dynamic.
All bundles are collapsed to a single one after KiFace become complete.

So i386 could be desupported, the issue of multiple copies of dynamic libraries 
for each bundle, as planned, is no more needed too.
I personally think that also Phyton could be now migrated to 2.7 and no more 
2.6 (other legacy from the platforms above).

Much of that work is now obsolete.
Guys has done a great job with the new disto.

I’ve a couple of question for them:
* Are libX*.dynlib really needed ?
* Since binaries are x86_64, do you think isn’t the case to use “lipo -remove” 
for unneeded architecture from all dynlibs?

Great job!

—
Marco

> On 25/feb/2015, at 22:52, Wayne Stambaugh  wrote:
> 
> I'm surprised it still works with all of the changes made for the OSX
> bundle support.  I'll leave it as is for the upcoming stable release.
> Please take note that one of the first things I'm going to do after the
> stable release is remove all of the download_foo code from the kicad
> build system.  This code should have always been maintained outside the
> kicad source tree as a stand alone project or projects if you would
> prefer one project per dependency.  Everyone has plenty of warning so if
> you depend on this to build dependencies on your platform, now is the
> time to start working on what ever dependency builders you need.
> 
> On 2/25/2015 1:47 PM, Garth Corral wrote:
>> I do use it but I'm not opposed to removing it if that's what you want.
>> It does still seem to work and is convenient if you don't want to use
>> installed dependencies.  I can just as easily move that to a script, though.
>> 
>> Garth
>> 
>> On Feb 25, 2015, at 10:30 AM, Bernhard Stegmaier
>> mailto:stegma...@sw-systems.de>> wrote:
>> 
>>> No, I didn’t use it since the app bundle updates.
>>> I even don’t know if it still works with all the changes since.
>>> 
>>> 
>>> Regards,
>>> Bernhard
>>> 
 On 25 Feb 2015, at 18:47, Adam Wolf >>> > wrote:
 
 The nightlies do not.
 
 Adam Wolf
 
 On Wed, Feb 25, 2015 at 11:29 AM, Wayne Stambaugh
 mailto:stambau...@gmail.com>> wrote:
 
Is anyone still using the old USE_OSX_DEPS_BUILDER?  If not, I think
it's time to remove it from CMakeLists.txt.
 
Cheers,
 
Wayne


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

[Marco Serantoni]

I was suspecting that.

Another hint for distro

to finish better the work could be nice to put all directories that in linux is 
under
 /usr/share/kicad/internat/  into  kicad.app/Contents/Resources/

Having something like:
kicad.app/Contents/Resources//kicad.mo
kicad.app/Contents/Resources//kicad.po

then simbolic link directories them under the bundled applications, 
having something like:
kicad.app/Contents/Applications/.app/Contents/Resources//kicad.mo

This will provide translations for all languages like other platforms keep 
saving diskspace.
I’ve tested the translations successfully time ago and i think should still 
work.

PS.
Please make a i386 binary once each 6 months, i have an old mini that still 
kicking ;)

—
Marco


> On 01/mar/2015, at 03:52, Garth Corral  wrote:
> 
> The libX dylibs are not needed.  The library dependencies can and should be 
> built without X.
> If the kicad binaries are not 2-way fat then there’s no reason the bundled 
> libs should be either.
> 
> Garth
> 
>> On Feb 28, 2015, at 3:18 PM, Marco Serantoni  
>> wrote:
>> 
>> Wayne,
>> At the time we were in a timeframe where was ppc finishing his fading out, 
>> i386 in mid term, x86_64 was not already fully adopted.
>> KiFace work begin was forcing a migration from the old default behavior of 
>> static linking to dynamic.
>> Now: 
>>  i386 fading/faded out completely. 
>>  The linking is dynamic.
>>  All bundles are collapsed to a single one after KiFace become complete.
>> 
>> So i386 could be desupported, the issue of multiple copies of dynamic 
>> libraries for each bundle, as planned, is no more needed too.
>> I personally think that also Phyton could be now migrated to 2.7 and no more 
>> 2.6 (other legacy from the platforms above).
>> 
>> Much of that work is now obsolete.
>> Guys has done a great job with the new disto.
>> 
>> I’ve a couple of question for them:
>> * Are libX*.dynlib really needed ?
>> * Since binaries are x86_64, do you think isn’t the case to use “lipo 
>> -remove” for unneeded architecture from all dynlibs?
>> 
>> Great job!
>> 
>> —
>> Marco
>> 
>>> On 25/feb/2015, at 22:52, Wayne Stambaugh  wrote:
>>> 
>>> I'm surprised it still works with all of the changes made for the OSX
>>> bundle support.  I'll leave it as is for the upcoming stable release.
>>> Please take note that one of the first things I'm going to do after the
>>> stable release is remove all of the download_foo code from the kicad
>>> build system.  This code should have always been maintained outside the
>>> kicad source tree as a stand alone project or projects if you would
>>> prefer one project per dependency.  Everyone has plenty of warning so if
>>> you depend on this to build dependencies on your platform, now is the
>>> time to start working on what ever dependency builders you need.
>>> 
>>> On 2/25/2015 1:47 PM, Garth Corral wrote:
>>>> I do use it but I'm not opposed to removing it if that's what you want.
>>>> It does still seem to work and is convenient if you don't want to use
>>>> installed dependencies.  I can just as easily move that to a script, 
>>>> though.
>>>> 
>>>> Garth
>>>> 
>>>> On Feb 25, 2015, at 10:30 AM, Bernhard Stegmaier
>>>> mailto:stegma...@sw-systems.de>> wrote:
>>>> 
>>>>> No, I didn’t use it since the app bundle updates.
>>>>> I even don’t know if it still works with all the changes since.
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> Bernhard
>>>>> 
>>>>>> On 25 Feb 2015, at 18:47, Adam Wolf >>>>> <mailto:adamw...@feelslikeburning.com>> wrote:
>>>>>> 
>>>>>> The nightlies do not.
>>>>>> 
>>>>>> Adam Wolf
>>>>>> 
>>>>>> On Wed, Feb 25, 2015 at 11:29 AM, Wayne Stambaugh
>>>>>> mailto:stambau...@gmail.com>> wrote:
>>>>>> 
>>>>>>  Is anyone still using the old USE_OSX_DEPS_BUILDER?  If not, I think
>>>>>>  it's time to remove it from CMakeLists.txt.
>>>>>> 
>>>>>>  Cheers,
>>>>>> 
>>>>>>  Wayne
>> 
>> 
>> ___
>> 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] OSX: Where to store the libraries and modules

[Marco Serantoni]

On 09/set/2010, at 22.46, Martijn Kuipers wrote:

Libraries should go in /Library/Application Support/kicad or in 
$HOME/Library/Application Support/kicad 

--
Marco

> I managed to create the DMG-files for kicad on OSX. Next I wanted to add the 
> libraries, but where should they be stored?
> I was thinking of using the same drag&drop principle, so you would get 
> something like
> 
> Kicad  -> /Applications
> 
> Inside this DMG I would add a Library DMG, which does more or less the same 
> thing
> 
> Libs&Mods -> /Users/Share/


___
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 broken on OS X case sensitive filesystem

[Marco Serantoni]

On 15/set/2010, at 19.51, Jonathan Stroud wrote:

Jonathan,
Sorry for the late response, i were in the middle of some adjustments of the 
OSX code and i've commited the changes you suggested.
I'm waiting for feedbacks.

--
Marco

> I can fix this problem and check in a patch.  I just discovered KiCad
> recently and was intrigued by it's multiplatform support since I use
> both OS X and Linux equally.
> 
> 
> 
> On Sep 15, 2010, at 12:43 PM, Dick Hollenbeck  wrote:
> 
>> On 09/15/2010 09:18 AM, Jonathan Stroud wrote:
>>> If you install KiCad on a case sensitive file system under OS X, you will 
>>> get the following error:
>>> 
>>> "You can't open application kicad because it may be damaged or incomplete."
>>> 
>>> The fix is trivial.  You simply need to edit the "Info.plist" file and 
>>> change the CFBundleExecutable and CFBundleName from "KiCad" to "kicad":
>>> 
>>> CFBundleExecutable
>>> KiCad
>>> 
>>> and change to:
>>> 
>>> CFBundleExecutable
>>> kicadhttps://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] library structure

[Marco Serantoni]

On 23/set/2010, at 19.40, Wayne Stambaugh wrote:
> 
> I don't see how aliases can be used for heavy libraries.  Aliases do not have
> fields (unless you count the information in the document file) so you cannot
> assign different default or user specified field values to them.  Once you add
> field support to aliases, you have effectively made them components.  As you
> mentioned above, most heavy libraries would be generated by scripts or copy 
> and
> paste so any advantage of sharing a symbol largely negated.

After much silence i want to contribute with my cent:

We could use a "base library" that is referred from "specific parts library" as 
"father" using its symbol like classes (inherance).
So who wants heavy libraries has its parts, who keeps its library light has its 
part fallbacking to the father.

Each specific parts could have also the substitution others, case supported and 
probably also the part number of the largest distributors for the List of 
Material.

--
Marco


___
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] library structure

[Marco Serantoni]

On 23/set/2010, at 21.50, Dick Hollenbeck wrote:
>> 
>> We could use a "base library" that is referred from "specific parts library" 
>> as "father" using its symbol like classes (inherance).
>> So who wants heavy libraries has its parts, who keeps its library light has 
>> its part fallbacking to the father.
>> 
> 
> Inheritance.  hmmm.  Why not just *copy* symbol by symbol and make each
> copied symbol into a part-specific component in a new project specific
> library. 

Because we have load the same symbol multiple times, wasting in large libraries 
a lot of memory , so i'm suggesting a pointer to base symbols.

--
Marco___
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] C++ conformance (was [Merge] lp:~amir-mohammadkhani/kicad/ash into lp:kicad)

[Marco Serantoni]

On Tue, Sep 28, 2010 at 10:49 PM, Alex G  wrote:

> > I think we are reaching the point where we need a separate branch for
> > visual c++.
> I'm sorry to just jump in, but what was the problem with Blinded C++ in
> the first place?
> Is it not compiling? I wouldn't like to see kicad deviate from standard
> C/C++ (name your favorite standard), and if it doesn't, there shouldn't
> be an issue with other compilers. If Blinded C++ is incapable of
> handling the standards, then, and only then we shouldn't even consider
> supporting it.

[..]

> Shouldn't this be cleaned up before deciding if other compilers are crap?
>

Alex,
We are talking about CMake/VC++ issues at the moment, so the way that VC++
builds the software.
Remains clear that the being Kicad a multiplatform software the first choice
compiler is gcc and this is not because we are free-software talibans, but
because is the compiler avaiable on the largest number of platforms.
Keep kicad running the largest number of platforms means a lot of
compromises that developers have to keep in mind when changing the code (to
avoid to broke something else).
Dick on his side i think would avoid to efford more compromises just to
support an already supported platform, probably the answer could be
different if becomes from an unsupported platform (like QNX).

Please stop this "compiler war", i don't think we need just another useless
holy war with no winners.

--
Marco
___
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] exploiting human readability

[Marco Serantoni]

On Thu, Oct 7, 2010 at 3:40 AM, Dick Hollenbeck  wrote:

>
> It occurs to me that if you had the assignment operator in place for
> COMPONENT or copy constructor, you could simply assign to the containing
> component when seeing an "inherit" token using the base component.
>
> (component A
>  (inherit component B GUID)
>  (pin 12 ...)
>  (property NAME VALUE (offset X Y) (orientation 0)(font FONT)(visible NO))
> )
>
> Dick to avoid problems i think we should overload the pins and attributes
only and make the graphic part of the component immutable.
--
Marco
___
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] Improving usability of KiCad

[Marco Serantoni]

On Sun, Oct 10, 2010 at 11:35 AM, Vesa Solonen  wrote:

> On Sat, 9 Oct 2010, Dick Hollenbeck wrote:
>
>  We are essentially rewriting eeschema very soon.
>>
>
> Any plans going metric on the way? I know it doesn't actuallu matter much,
> but "now or never (tm)". Brainstorming ahead, is the wxWidgets the right
> tool? I remember some previous brainstorming about Qt, even python was
> mentioned for the UI. My (very limited) experience has proven PyQt4 _very_
> usable and also faster than any other common Python GUI toolkit. GUI layout
> tools are in my opinion way better and there is less breakage between
> platforms. On wx(GTK) the layout with labels and textboxes is never correct
> (just look at KiCad on wxGTK vs Windows), but on Qt it's completely non
> issue. Platform nativenes issue was solved some time ago, so Qt ought to be
> as native as wxWidgets. I know the great deal of investment for wxWidgets,
> but sometimes one has to leave old behind. Nokia pushing Qt seems to be a
> good thing as license was relaxed LGPL/GPL/commercial and development is
> ongoing. Qucs and FreeCAD would combine with KiCad more seamlessly...
>
> Vesa, we could switch to wxUniversal, instead having the native widgets,
but this has a performance price..
I wish to change the point of view, we use wxWidgets in the best way ?
I want to see PyQt4 drawing the amount of lines in video.brd one by one.
I have nothing against Qt, neither wx has nothing against Qt in fact there
is a QT port (wxQT)..

--
Marco
___
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] Improving usability of KiCad

[Marco Serantoni]

On Sun, Oct 10, 2010 at 4:49 PM, Alex G  wrote:

>
> I never questioned kicad's decision to use wxWidgets. I do think,
> however, of the 3d-viewer crashing on non-nvidia cards or nvidia cards
> with nouveau. I can reproduce it 100%. Are these and similar sort of
> issues common with wx? Would it be easier to switch to a different GUI
> system instead of patching up wx? If the answer to the last two
> questions is yes, then count me in on the effort.
>
>
Alex,
The only issue i'm aware of is the
#648289that looks going
straight to the related bug in RH/X11
https://bugzilla.redhat.com/show_bug.cgi?id=539764.
If you fall in the same issue, fix your OpenGL stack otherwise try to
collect and show more infos, we wil try to solve it or at least
diagnosticate it.

--
Marco
___
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] Kicad performance

[Marco Serantoni]

I wish make the point  we are at the moment, seen the number of newcomers.
We have 2 main platforms: Windows and Linux, there is also a third platform
at the moment that is OSX.
The accelerated APIs on this platforms are provided by:

Linux: GTK/CairoLib
Windows: GDI+ / Direct2D
OSX: Quartz 2D (CoreGraphics)

New APIs, wrapped in wxGraphicsContext, to perform at their maximum should
transfer draw commands in the largest batch as possible.
Instead the current Kicad code born with the old generation APIs draws the
screen primitive by primitive.

Dick (if i recall well) has already done a brunch of job to support
wxGraphicsContext but the showstopper in this case was the Windows Platform
using GDI+ (being slower than the old stlyle API).

And Torsen has started its GAL job for this reason..

Now we have also another problem GDI+ HW acceleration (on the cards
supporting it) is unsupported on Windows 7 or Vista (updated) that has
issued a new standard Direct2D (
http://msdn.microsoft.com/en-us/library/dd370990%28v=VS.85%29.aspx ).


wxWidgets supports multiple wxGraphicsContexts for each platforms and lets
the user choose which wants to use.
If some Windows User/Developer is not happy about Kicad performance could
make the wxGraphicsContext interface work on Direct2D
here the GDI+ implementation
http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/src/msw/graphics.cpp?view=markup

US Kicad developers we will more than happy to change deeply the drawing
code to perform much better, than now and i think that also Torsen could be
happy to have some working example to expand its GAL.

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

[Marco Serantoni]

On Oct 11, 2010, at 5:17 PM, Alex G wrote:
> 
> 
> On 10/11/2010 05:54 PM, Marco Serantoni wrote:
>> I wish make the point  we are at the moment, seen the number of newcomers.
>> We have 2 main platforms: Windows and Linux, there is also a third
>> platform at the moment that is OSX.
>> The accelerated APIs on this platforms are provided by:
>> 
>> Linux: GTK/CairoLib
>> Windows: GDI+ / Direct2D
>> OSX: Quartz 2D (CoreGraphics)
> 
> Don't we have OpenGL that works an all of these platforms? Wouldn't it
> be infinitely simpler to use OpenGL and call it a day, instead of
> supporting three different APIs (AKA 1 code code path vs. three)?
Surelly, do you have an OpenGL printer or SVG writer ?

--
Marco

___
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] 3D viewer issue (from: Improving usability of KiCad)

[Marco Serantoni]

On Oct 11, 2010, at 4:40 PM, Alex G wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 10/11/2010 05:23 PM, Marco Serantoni wrote:
>> Alex,
>> The only issue i'm aware of is the #648289
> Marco,
> 
> Here's the issue I'm referring to (and my failed attempt to find the
> culprit):
> https://bugzilla.redhat.com/show_bug.cgi?id=592047
> https://bugs.launchpad.net/kicad/+bug/582997
> 
> I was able to reproduce all the steps in the redhat bugzilla report.
> It doesn't sounds too similar to the one you pointed out.
> 
> I don't know what you mean by "fix your OpenGL stack", but I'm not
> getting any z-buffer messages.
> What info do you need me to collect? I'd like to help fix this issue,
> not just help diagnose it and leave it for someone else to fix.


bug: https://bugs.launchpad.net/kicad/+bug/582997
Is Oblisly related to Driver problem, 

Different is for https://bugzilla.redhat.com/show_bug.cgi?id=592047#c18
That is an obliusly stack overflow over wxWindow::DoSetSize(int, int, int, int, 
int)
Probably fixed in: 
http://svn.wxwidgets.org/svn/wx/wxWidgets/tags/WX_2_8_11/docs/changes.txt
- Fix a crash in wxAuiFrameManager when Update() was called in between mouse-up
  and mouse-down events

The other could be a resize caused by the manager,  during OpenGL buffer switch 
Try to comment out m_mgr.Update().. and recompile.

If stops crashing, try to add a couple of SwapBuffers () before the 
m_mgr.Update()

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

[Marco Serantoni]

On Oct 11, 2010, at 6:09 PM, Alex G wrote:

> 
> On 10/11/2010 06:41 PM, Marco Serantoni wrote:
>> Surelly, do you have an OpenGL printer or SVG writer ?
>> 
> About the OpenGL printer:
> Setup a framebuffer any resolution you'd like, render whatever you need
> to there, then copy the framebuffer to a texture, and save as a high
> resolution bitmap. :)

Cute, i dubt this is nice for the printer driver, and for the gerber files, 
HPGL Files, SVG ? All those are vectorial formats.

You still use a couple of Code Paths.. and this could limit your changes.. not 
thinking the problems of mantaining those two approaches ..

PS.
Try to take a look to Windows and ICDs issues and avaiability, and how OpenGL 
ICDs are placed on the graphics stack in Windows..

As we use say here:
We aren't combing the dolls :)

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