Hi Marco, I modified the file ./include/common.h as you suggested, and that bug is fixed.
Hello Developers with BZR Write permissions, Please modify ./include/common.h as suggested by Marco. Thanks all for your patience with me. Dick, I am going to try to apply your patch if it is OK to do it after so many BZR updates. Do I have to go back to BZR4810 to test it? or can I apply that patch to BZR4854? Please let me know. Jean-Paul On May 8, 2014, at 4:52 PM, Jean-Paul Louis <[email protected]> wrote: > 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 <[email protected]> wrote: > >> >> On 08/mag/2014, at 08:10, Dick Hollenbeck <[email protected]> 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 : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
