kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 05/08/2014 01:10 AM, 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.
>>
> 
> 
> 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.
> 
> 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.


IOW, if this code was loaded "in-process" then you would be dodging a MacOSX deficiency,
and making the kicad.exe process bigger with more moving parts.

I don't have a problem if that's what you guys want to do down the road as a means of
dodging the OSX bug.  Some Mac developer could and should also take a look under the hood
of wx and verify wx is not launching the process in a way that tells OSX to be shy when
that new process starts up.  I have found it virtually impossible to work with wx without
have significant numbers of their source files in my editor at all times.  Last weekend
that entailed even two versions of wx: 2.8.12 and svn head.

I just did not think of the OSX bug, I did not think that running the bitmap editor or
even the gerber viewer "in-process" was pertinent to the problems I have been trying to
solve as listed in the blueprint I am working on.  These are the more tightly coupled
aspects of the design flow where the in-process relationship is used for cross KIFACE
communications.


But you have that flexibility in the future.  In fact that's why my last Mac patch had
that decision in a foreach() loop.  So it was easy to change in the policy now or in future.


Dick



> 
> 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.
> 
> 
> Dick
> 
> 
> _______________________________________________
> 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
>