← Back to team overview

kicad-developers team mailing list archive

Re: [Kicad-lib-committers] Issues with BZR4854 for OS X

 

Thanks Marco,

It was just a test for functionality.
I can now replace them with relative ones.

Jean-Paul


On May 8, 2014, at 4:34 PM, Marco Serantoni <marco.serantoni@xxxxxxxxx> wrote:

> 
> On 08/mag/2014, at 08:10, Dick Hollenbeck <dick@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp



Follow ups

References