kicad-developers team mailing list archive

[Jean-Paul Louis <louijp@xxxxxxxxx>]

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 <louijp@xxxxxxxxx> 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 <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
>