Re: [Kicad-developers] A few issues with new OS X bundles

[Wayne Stambaugh]

Oops.  Fat finger a send on that last reply :).  Thank you for taking
care of this Bernhard and thank you Garth for the input.  Send me the
patch when it is ready.

Cheers,

Wayne

On 10/4/2014 4:57 PM, Bernhard Stegmaier wrote:
> Then we should go the way Garth proposed using bundles in bundles (yes,
> even Xcode does it this way, I was not aware of doing it this way).
> 
> Inside the single app bundle everything is kept as a single copy,
> default is the kicad launcher.
> Individual app bundles for everything are created inside the main bundle. 
> If somebody likes to use an application directly he can do some links on
> his own (links could even be already done in the .dmg - you could choose
> to only copy kicad bundle or the whole folder as you wish). 
> 
> The only thing to take care then is the path stuff I mentioned below,
> but it shouldn’t be that hard to map every path ending with something
> other than “kicad” to kicad to always use the same configurations.
> 
> I’ll finish current things, then I will adapt things this way if there
> are no objections.
> 
> 
> Regards,
> Bernhard
> 
> On 04.10.2014, at 22:37, Wayne Stambaugh  > wrote:
> 
>> Anything launched by calling Execute() is a separate executable and will
>> run in a separate process.  I thought KiPlayer() runs in the same
>> process as kicad but I could be wrong.  It makes sense that pl_editor
>> and GerbView are stand alone since they don't make sense in relation to
>> a project.  I still think the single application bundle makes the most
>> sense.  It would be nice to figure out a way to make it play nice with
>> the OSX launcher.  Maybe it's a matter of figuring out the correct magic
>> incantation in Info.plist to make it happen.
>>
>> On 10/4/2014 2:44 PM, Bernhard Stegmaier wrote:
>>> Hi,
>>>
>>> yes, could be easy to do this way.
>>> Let’s see what Wayne thinks about different execution of pcbnew/eeschema
>>> vs. the other applications, then we will see how to proceed.
>>>
>>> I’m almost done with adapting scripting stuff in CMake and also found a
>>> way without explicit usage of install_name_tool to put dylibs into
>>> Framework.
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>> On 04.10.2014, at 20:31, Garth Corral >> 
>>> > wrote:
>>>
 Hi, Bernhard

 I think that the direction you are heading with the single application
 bundle is the right one.  I think a single draggable application
 install will be a huge win for OS X users compared to the way it was
 before.  It seems like you are almost there, but just a couple
 somewhat minor issues that might be confusing to Mac users.

 If what Wayne says it true, and these are not supposed to launch the
 way they do, then perhaps this can be dealt with outside of bundling
 and you’re done.  As for whether users want to be able to launch the
 other applications separately, I can’t really say.  I used to, but
 eventually just got into the habit of using the launcher; a bit more
 convenient.

 What about a hybrid of 1 and 2b?

 For each bundle that launches a separate process (and only those),
 create a bundle for that application and set up the main kicad bundle
 something like this:

 /kicad.app
Contents
Applications
gerbview.app
pcb_calculator.app
etc.
MacOS
kicad
pcbnew
eeschema
*.kiface
Frameworks
etc.

 Then put just a single set of libraries in the Frameworks directory of
 the top-level bundle and use install_name_tool to fix up the binaries
 to point to those as you allude to in 2b.  That would mean the the
 kicad.app application bundle would be relocatable to anywhere, but the
 sub applications would not be relocatable outside the main bundle.  Of
 course this would not solve the *.kiface issue that you mentioned.
 The symlink thing sort of offends me, too, but hopefully it would
 just be temporary, and the sub-applications wouldn’t be relocatable
 outside the bundle anyway.  Then as each application is ‘fixed’, it’s
 bundle could be removed and it gets migrated to MacOS as now.

 As a side effect, these sub-applications would not be visible to to
 users unless they went out of their way to find them.  This could be
 good or bad depending on your perspective.  To me it’s good.  It
 signals the intention that they will not be separate applications in
 the future, but allows them to behave correctly from within the main
 app.  It also eliminates the common folder in the dock.

 This sort of thing is not unprecedented.  Apple does it with some of
 their own applications.  For instance:

 $ ls -1 /Applications/Server.app/Contents
 Applications 

Re: [Kicad-developers] A few issues with new OS X bundles

[Wayne Stambaugh]

On 10/4/2014 4:57 PM, Bernhard Stegmaier wrote:
> Then we should go the way Garth proposed using bundles in bundles (yes,
> even Xcode does it this way, I was not aware of doing it this way).
> 
> Inside the single app bundle everything is kept as a single copy,
> default is the kicad launcher.
> Individual app bundles for everything are created inside the main bundle. 
> If somebody likes to use an application directly he can do some links on
> his own (links could even be already done in the .dmg - you could choose
> to only copy kicad bundle or the whole folder as you wish). 
> 
> The only thing to take care then is the path stuff I mentioned below,
> but it shouldn’t be that hard to map every path ending with something
> other than “kicad” to kicad to always use the same configurations.
> 
> I’ll finish current things, then I will adapt things this way if there
> are no objections.
> 
> 
> Regards,
> Bernhard
> 
> On 04.10.2014, at 22:37, Wayne Stambaugh  > wrote:
> 
>> Anything launched by calling Execute() is a separate executable and will
>> run in a separate process.  I thought KiPlayer() runs in the same
>> process as kicad but I could be wrong.  It makes sense that pl_editor
>> and GerbView are stand alone since they don't make sense in relation to
>> a project.  I still think the single application bundle makes the most
>> sense.  It would be nice to figure out a way to make it play nice with
>> the OSX launcher.  Maybe it's a matter of figuring out the correct magic
>> incantation in Info.plist to make it happen.
>>
>> On 10/4/2014 2:44 PM, Bernhard Stegmaier wrote:
>>> Hi,
>>>
>>> yes, could be easy to do this way.
>>> Let’s see what Wayne thinks about different execution of pcbnew/eeschema
>>> vs. the other applications, then we will see how to proceed.
>>>
>>> I’m almost done with adapting scripting stuff in CMake and also found a
>>> way without explicit usage of install_name_tool to put dylibs into
>>> Framework.
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>> On 04.10.2014, at 20:31, Garth Corral >> 
>>> > wrote:
>>>
 Hi, Bernhard

 I think that the direction you are heading with the single application
 bundle is the right one.  I think a single draggable application
 install will be a huge win for OS X users compared to the way it was
 before.  It seems like you are almost there, but just a couple
 somewhat minor issues that might be confusing to Mac users.

 If what Wayne says it true, and these are not supposed to launch the
 way they do, then perhaps this can be dealt with outside of bundling
 and you’re done.  As for whether users want to be able to launch the
 other applications separately, I can’t really say.  I used to, but
 eventually just got into the habit of using the launcher; a bit more
 convenient.

 What about a hybrid of 1 and 2b?

 For each bundle that launches a separate process (and only those),
 create a bundle for that application and set up the main kicad bundle
 something like this:

 /kicad.app
Contents
Applications
gerbview.app
pcb_calculator.app
etc.
MacOS
kicad
pcbnew
eeschema
*.kiface
Frameworks
etc.

 Then put just a single set of libraries in the Frameworks directory of
 the top-level bundle and use install_name_tool to fix up the binaries
 to point to those as you allude to in 2b.  That would mean the the
 kicad.app application bundle would be relocatable to anywhere, but the
 sub applications would not be relocatable outside the main bundle.  Of
 course this would not solve the *.kiface issue that you mentioned.
 The symlink thing sort of offends me, too, but hopefully it would
 just be temporary, and the sub-applications wouldn’t be relocatable
 outside the bundle anyway.  Then as each application is ‘fixed’, it’s
 bundle could be removed and it gets migrated to MacOS as now.

 As a side effect, these sub-applications would not be visible to to
 users unless they went out of their way to find them.  This could be
 good or bad depending on your perspective.  To me it’s good.  It
 signals the intention that they will not be separate applications in
 the future, but allows them to behave correctly from within the main
 app.  It also eliminates the common folder in the dock.

 This sort of thing is not unprecedented.  Apple does it with some of
 their own applications.  For instance:

 $ ls -1 /Applications/Server.app/Contents
 Applications  <
 Frameworks
 Info.plist
 Library
 MacOS
 PkgInfo
 PlugIns
 Resources


 They also do this in Xcode, bu

Re: [Kicad-developers] A few issues with new OS X bundles

[Bernhard Stegmaier]

Then we should go the way Garth proposed using bundles in bundles (yes, even 
Xcode does it this way, I was not aware of doing it this way).

Inside the single app bundle everything is kept as a single copy, default is 
the kicad launcher.
Individual app bundles for everything are created inside the main bundle. 
If somebody likes to use an application directly he can do some links on his 
own (links could even be already done in the .dmg - you could choose to only 
copy kicad bundle or the whole folder as you wish). 

The only thing to take care then is the path stuff I mentioned below, but it 
shouldn’t be that hard to map every path ending with something other than 
“kicad” to kicad to always use the same configurations.

I’ll finish current things, then I will adapt things this way if there are no 
objections.


Regards,
Bernhard

On 04.10.2014, at 22:37, Wayne Stambaugh  wrote:

> Anything launched by calling Execute() is a separate executable and will
> run in a separate process.  I thought KiPlayer() runs in the same
> process as kicad but I could be wrong.  It makes sense that pl_editor
> and GerbView are stand alone since they don't make sense in relation to
> a project.  I still think the single application bundle makes the most
> sense.  It would be nice to figure out a way to make it play nice with
> the OSX launcher.  Maybe it's a matter of figuring out the correct magic
> incantation in Info.plist to make it happen.
> 
> On 10/4/2014 2:44 PM, Bernhard Stegmaier wrote:
>> Hi,
>> 
>> yes, could be easy to do this way.
>> Let’s see what Wayne thinks about different execution of pcbnew/eeschema
>> vs. the other applications, then we will see how to proceed.
>> 
>> I’m almost done with adapting scripting stuff in CMake and also found a
>> way without explicit usage of install_name_tool to put dylibs into
>> Framework.
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> On 04.10.2014, at 20:31, Garth Corral > > wrote:
>> 
>>> Hi, Bernhard
>>> 
>>> I think that the direction you are heading with the single application
>>> bundle is the right one.  I think a single draggable application
>>> install will be a huge win for OS X users compared to the way it was
>>> before.  It seems like you are almost there, but just a couple
>>> somewhat minor issues that might be confusing to Mac users.
>>> 
>>> If what Wayne says it true, and these are not supposed to launch the
>>> way they do, then perhaps this can be dealt with outside of bundling
>>> and you’re done.  As for whether users want to be able to launch the
>>> other applications separately, I can’t really say.  I used to, but
>>> eventually just got into the habit of using the launcher; a bit more
>>> convenient.
>>> 
>>> What about a hybrid of 1 and 2b?
>>> 
>>> For each bundle that launches a separate process (and only those),
>>> create a bundle for that application and set up the main kicad bundle
>>> something like this:
>>> 
>>> /kicad.app
>>>Contents
>>>Applications
>>>gerbview.app
>>>pcb_calculator.app
>>>etc.
>>>MacOS
>>>kicad
>>>pcbnew
>>>eeschema
>>>*.kiface
>>>Frameworks
>>>etc.
>>> 
>>> Then put just a single set of libraries in the Frameworks directory of
>>> the top-level bundle and use install_name_tool to fix up the binaries
>>> to point to those as you allude to in 2b.  That would mean the the
>>> kicad.app application bundle would be relocatable to anywhere, but the
>>> sub applications would not be relocatable outside the main bundle.  Of
>>> course this would not solve the *.kiface issue that you mentioned.
>>> The symlink thing sort of offends me, too, but hopefully it would
>>> just be temporary, and the sub-applications wouldn’t be relocatable
>>> outside the bundle anyway.  Then as each application is ‘fixed’, it’s
>>> bundle could be removed and it gets migrated to MacOS as now.
>>> 
>>> As a side effect, these sub-applications would not be visible to to
>>> users unless they went out of their way to find them.  This could be
>>> good or bad depending on your perspective.  To me it’s good.  It
>>> signals the intention that they will not be separate applications in
>>> the future, but allows them to behave correctly from within the main
>>> app.  It also eliminates the common folder in the dock.
>>> 
>>> This sort of thing is not unprecedented.  Apple does it with some of
>>> their own applications.  For instance:
>>> 
>>> $ ls -1 /Applications/Server.app/Contents
>>> Applications  <
>>> Frameworks
>>> Info.plist
>>> Library
>>> MacOS
>>> PkgInfo
>>> PlugIns
>>> Resources
>>> 
>>> 
>>> They also do this in Xcode, but that’s probably not an example you’d
>>> want to show anyone.  :-)
>>> 
>>> 
>>> I currently have a bundle that I built using your new build changes,
>>> but I repackaged it to put the libraries in a Frameworks directory
>>> w

Re: [Kicad-developers] A few issues with new OS X bundles

[Wayne Stambaugh]

Anything launched by calling Execute() is a separate executable and will
run in a separate process.  I thought KiPlayer() runs in the same
process as kicad but I could be wrong.  It makes sense that pl_editor
and GerbView are stand alone since they don't make sense in relation to
a project.  I still think the single application bundle makes the most
sense.  It would be nice to figure out a way to make it play nice with
the OSX launcher.  Maybe it's a matter of figuring out the correct magic
incantation in Info.plist to make it happen.

On 10/4/2014 2:44 PM, Bernhard Stegmaier wrote:
> Hi,
> 
> yes, could be easy to do this way.
> Let’s see what Wayne thinks about different execution of pcbnew/eeschema
> vs. the other applications, then we will see how to proceed.
> 
> I’m almost done with adapting scripting stuff in CMake and also found a
> way without explicit usage of install_name_tool to put dylibs into
> Framework.
> 
> 
> Regards,
> Bernhard
> 
> On 04.10.2014, at 20:31, Garth Corral  > wrote:
> 
>> Hi, Bernhard
>>
>> I think that the direction you are heading with the single application
>> bundle is the right one.  I think a single draggable application
>> install will be a huge win for OS X users compared to the way it was
>> before.  It seems like you are almost there, but just a couple
>> somewhat minor issues that might be confusing to Mac users.
>>
>> If what Wayne says it true, and these are not supposed to launch the
>> way they do, then perhaps this can be dealt with outside of bundling
>> and you’re done.  As for whether users want to be able to launch the
>> other applications separately, I can’t really say.  I used to, but
>> eventually just got into the habit of using the launcher; a bit more
>> convenient.
>>
>> What about a hybrid of 1 and 2b?
>>
>> For each bundle that launches a separate process (and only those),
>> create a bundle for that application and set up the main kicad bundle
>> something like this:
>>
>> /kicad.app
>> Contents
>> Applications
>> gerbview.app
>> pcb_calculator.app
>> etc.
>> MacOS
>> kicad
>> pcbnew
>> eeschema
>> *.kiface
>> Frameworks
>> etc.
>>
>> Then put just a single set of libraries in the Frameworks directory of
>> the top-level bundle and use install_name_tool to fix up the binaries
>> to point to those as you allude to in 2b.  That would mean the the
>> kicad.app application bundle would be relocatable to anywhere, but the
>> sub applications would not be relocatable outside the main bundle.  Of
>> course this would not solve the *.kiface issue that you mentioned.
>>  The symlink thing sort of offends me, too, but hopefully it would
>> just be temporary, and the sub-applications wouldn’t be relocatable
>> outside the bundle anyway.  Then as each application is ‘fixed’, it’s
>> bundle could be removed and it gets migrated to MacOS as now.
>>
>> As a side effect, these sub-applications would not be visible to to
>> users unless they went out of their way to find them.  This could be
>> good or bad depending on your perspective.  To me it’s good.  It
>> signals the intention that they will not be separate applications in
>> the future, but allows them to behave correctly from within the main
>> app.  It also eliminates the common folder in the dock.
>>
>> This sort of thing is not unprecedented.  Apple does it with some of
>> their own applications.  For instance:
>>
>> $ ls -1 /Applications/Server.app/Contents
>> Applications  <
>> Frameworks
>> Info.plist
>> Library
>> MacOS
>> PkgInfo
>> PlugIns
>> Resources
>>
>>
>> They also do this in Xcode, but that’s probably not an example you’d
>> want to show anyone.  :-)
>>
>>
>> I currently have a bundle that I built using your new build changes,
>> but I repackaged it to put the libraries in a Frameworks directory
>> within the bundle and also compiled with scripting support on and put
>> the python site-packages in there as well (don’t really know where
>> these belong).  I also moved the command line utilities out to
>> SharedSupport/bin.  It all works fairly well but still has the issues
>> I mentioned in my original message on the topic.
>>
>>
>> On Oct 4, 2014, at 6:56 AM, Bernhard Stegmaier
>> mailto:stegma...@sw-systems.de>> wrote:
>>
>>> There are 2 possibilities as far as I can see:
>>>
>>> *(1) One single application bundle - like it is now.*
>>> There are probably still some cosmetic issues as Garth told, but I
>>> think these are just minor inconsistencies that could be sorted out.
>>> From an efficiency point of view it is no difference… 2 clicks this
>>> way to start e.g. pcbnew (first click opens kicad launcher, second
>>> pcbnew), the same for the “old” approach (one click to open KiCad
>>> folder, second to start pcbnew).
>>> Positive: No space wasted
>>> Positive: No dependency problems, i

Re: [Kicad-developers] A few issues with new OS X bundles

[Bernhard Stegmaier]

Hi,

yes, could be easy to do this way.
Let’s see what Wayne thinks about different execution of pcbnew/eeschema vs. 
the other applications, then we will see how to proceed.

I’m almost done with adapting scripting stuff in CMake and also found a way 
without explicit usage of install_name_tool to put dylibs into Framework.


Regards,
Bernhard

On 04.10.2014, at 20:31, Garth Corral  wrote:

> Hi, Bernhard
> 
> I think that the direction you are heading with the single application bundle 
> is the right one.  I think a single draggable application install will be a 
> huge win for OS X users compared to the way it was before.  It seems like you 
> are almost there, but just a couple somewhat minor issues that might be 
> confusing to Mac users.
> 
> If what Wayne says it true, and these are not supposed to launch the way they 
> do, then perhaps this can be dealt with outside of bundling and you’re done.  
> As for whether users want to be able to launch the other applications 
> separately, I can’t really say.  I used to, but eventually just got into the 
> habit of using the launcher; a bit more convenient.
> 
> What about a hybrid of 1 and 2b?
> 
> For each bundle that launches a separate process (and only those), create a 
> bundle for that application and set up the main kicad bundle something like 
> this:
> 
> /kicad.app
> Contents
> Applications
> gerbview.app
> pcb_calculator.app
> etc.
> MacOS
> kicad
> pcbnew
> eeschema
> *.kiface
> Frameworks
> etc.
> 
> Then put just a single set of libraries in the Frameworks directory of the 
> top-level bundle and use install_name_tool to fix up the binaries to point to 
> those as you allude to in 2b.  That would mean the the kicad.app application 
> bundle would be relocatable to anywhere, but the sub applications would not 
> be relocatable outside the main bundle.  Of course this would not solve the 
> *.kiface issue that you mentioned.  The symlink thing sort of offends me, 
> too, but hopefully it would just be temporary, and the sub-applications 
> wouldn’t be relocatable outside the bundle anyway.  Then as each application 
> is ‘fixed’, it’s bundle could be removed and it gets migrated to MacOS as now.
> 
> As a side effect, these sub-applications would not be visible to to users 
> unless they went out of their way to find them.  This could be good or bad 
> depending on your perspective.  To me it’s good.  It signals the intention 
> that they will not be separate applications in the future, but allows them to 
> behave correctly from within the main app.  It also eliminates the common 
> folder in the dock.
> 
> This sort of thing is not unprecedented.  Apple does it with some of their 
> own applications.  For instance:
> 
> $ ls -1 /Applications/Server.app/Contents
> Applications  <
> Frameworks
> Info.plist
> Library
> MacOS
> PkgInfo
> PlugIns
> Resources
> 
> 
> They also do this in Xcode, but that’s probably not an example you’d want to 
> show anyone.  :-)
> 
> 
> I currently have a bundle that I built using your new build changes, but I 
> repackaged it to put the libraries in a Frameworks directory within the 
> bundle and also compiled with scripting support on and put the python 
> site-packages in there as well (don’t really know where these belong).  I 
> also moved the command line utilities out to SharedSupport/bin.  It all works 
> fairly well but still has the issues I mentioned in my original message on 
> the topic.
> 
> 
> On Oct 4, 2014, at 6:56 AM, Bernhard Stegmaier  
> wrote:
> 
>> There are 2 possibilities as far as I can see:
>> 
>> (1) One single application bundle - like it is now.
>> There are probably still some cosmetic issues as Garth told, but I think 
>> these are just minor inconsistencies that could be sorted out.
>> From an efficiency point of view it is no difference… 2 clicks this way to 
>> start e.g. pcbnew (first click opens kicad launcher, second pcbnew), the 
>> same for the “old” approach (one click to open KiCad folder, second to start 
>> pcbnew).
>> Positive: No space wasted
>> Positive: No dependency problems, it just is self-contained and completely 
>> relocatable
>> Negative: May break with users habits (Apple does this all the time, so 
>> nothing new for OSX users… :) )
>> 
>> (2) A KiCad-fodler with one application bundle per “executable” - from a 
>> users point of view how it was before.
>> Again, two options:
>> (2a) Self-contained bundles 
>> You have to pull every dependency into every bundle. 
>> Especially, you also have to duplicate all the *.kifaces into the kicad 
>> bundle for the launcher (and maybe also into other bundles e.g. if you 
>> want/could launch pcbnew from eeschema - don’t know if that is possible).
>> If you don’t do it like that (as it was before using symlinks between 
>> bundles), it looks l

Re: [Kicad-developers] A few issues with new OS X bundles

[Garth Corral]

Hi, Bernhard

I think that the direction you are heading with the single application bundle 
is the right one.  I think a single draggable application install will be a 
huge win for OS X users compared to the way it was before.  It seems like you 
are almost there, but just a couple somewhat minor issues that might be 
confusing to Mac users.

If what Wayne says it true, and these are not supposed to launch the way they 
do, then perhaps this can be dealt with outside of bundling and you’re done.  
As for whether users want to be able to launch the other applications 
separately, I can’t really say.  I used to, but eventually just got into the 
habit of using the launcher; a bit more convenient.

What about a hybrid of 1 and 2b?

For each bundle that launches a separate process (and only those), create a 
bundle for that application and set up the main kicad bundle something like 
this:

/kicad.app
Contents
Applications
gerbview.app
pcb_calculator.app
etc.
MacOS
kicad
pcbnew
eeschema
*.kiface
Frameworks
etc.

Then put just a single set of libraries in the Frameworks directory of the 
top-level bundle and use install_name_tool to fix up the binaries to point to 
those as you allude to in 2b.  That would mean the the kicad.app application 
bundle would be relocatable to anywhere, but the sub applications would not be 
relocatable outside the main bundle.  Of course this would not solve the 
*.kiface issue that you mentioned.  The symlink thing sort of offends me, too, 
but hopefully it would just be temporary, and the sub-applications wouldn’t be 
relocatable outside the bundle anyway.  Then as each application is ‘fixed’, 
it’s bundle could be removed and it gets migrated to MacOS as now.

As a side effect, these sub-applications would not be visible to to users 
unless they went out of their way to find them.  This could be good or bad 
depending on your perspective.  To me it’s good.  It signals the intention that 
they will not be separate applications in the future, but allows them to behave 
correctly from within the main app.  It also eliminates the common folder in 
the dock.

This sort of thing is not unprecedented.  Apple does it with some of their own 
applications.  For instance:

$ ls -1 /Applications/Server.app/Contents
Applications  <
Frameworks
Info.plist
Library
MacOS
PkgInfo
PlugIns
Resources


They also do this in Xcode, but that’s probably not an example you’d want to 
show anyone.  :-)


I currently have a bundle that I built using your new build changes, but I 
repackaged it to put the libraries in a Frameworks directory within the bundle 
and also compiled with scripting support on and put the python site-packages in 
there as well (don’t really know where these belong).  I also moved the command 
line utilities out to SharedSupport/bin.  It all works fairly well but still 
has the issues I mentioned in my original message on the topic.


On Oct 4, 2014, at 6:56 AM, Bernhard Stegmaier  wrote:

> There are 2 possibilities as far as I can see:
> 
> (1) One single application bundle - like it is now.
> There are probably still some cosmetic issues as Garth told, but I think 
> these are just minor inconsistencies that could be sorted out.
> From an efficiency point of view it is no difference… 2 clicks this way to 
> start e.g. pcbnew (first click opens kicad launcher, second pcbnew), the same 
> for the “old” approach (one click to open KiCad folder, second to start 
> pcbnew).
> Positive: No space wasted
> Positive: No dependency problems, it just is self-contained and completely 
> relocatable
> Negative: May break with users habits (Apple does this all the time, so 
> nothing new for OSX users… :) )
> 
> (2) A KiCad-fodler with one application bundle per “executable” - from a 
> users point of view how it was before.
> Again, two options:
> (2a) Self-contained bundles 
> You have to pull every dependency into every bundle. 
> Especially, you also have to duplicate all the *.kifaces into the kicad 
> bundle for the launcher (and maybe also into other bundles e.g. if you 
> want/could launch pcbnew from eeschema - don’t know if that is possible).
> If you don’t do it like that (as it was before using symlinks between 
> bundles), it looks like it is a normal OSX application you can move around 
> where you want, but actually you can’t because you break inter-bundle 
> dependencies.
> Maybe it is not a regular use-case to pull e.g. pcbnew out of the KiCad 
> folder, but nobody forbids that… so maybe someone likes to drag pcbnew to his 
> desktop because then it’s only one click to start...
> Positive: Everything is individually self-contained
> Negative: Space wasted for duplicating things - especially pcbnew with 
> scripting pulls in all the wxPython stuff that will be contained at least 
> twice then...
> (2b) 

Re: [Kicad-developers] A few issues with new OS X bundles

[Bernhard Stegmaier]

Yes, but some of the problems seem to be no OSX specific issues.

E.g. pl_editor is run this way (kicad/mainframe.cpp):
Execute( this, PL_EDITOR_EXE );

while eeschema/pcbnew related things are run this way:
KIWAY_PLAYER* frame = Kiway.Player( FRAME_PCB, true );

I don’t know if it is done like this on purpose, or if it just has been missed 
when introducing the kiface modularization.
The other question is why gerbview or pl_editor do have a kiface, but 
bitmap2component doesn’t (IMHO all of them don’t have a relation to a single 
project like maybe eeschema or pcbnew have).

Although I am also pretty emotionless about which way to go, for my taste the 
one single bundle fits better the modular idea of the kifaces (given that it is 
done consistently for all applications).

There is one thing that also makes things a bit complicated when doing it the 
individual apps way:
The usual wxWidgets ::GetDataDir(), etc. methods return something like 
~/Library/Application Support/.
So, if you start pcbnew via KiCad launcher it will point to 
~/Library/Application Support/kicad, but if you start it via its own bundle it 
will point to ~/Library/Application Support/pcbnew. Some new code would have to 
be added so that everything is found consistently independent from how you 
launch, e.g., pcbnew.
If have seen this being a problem at least on OSX, according to the wxWidgets 
docs for ::GetUserDataDir() it should/could be the same problem on other OSes:
Unix: ~/.appinfo
Windows: "C:\Documents and Settings\username\Application Data\appinfo"
Mac: "~/Library/Application Support/appinfo"



Regards,
Bernhard


On 04.10.2014, at 19:21, Garth Corral  wrote:

> 
> I’m afraid that’s not true in this case.  It does launch separate processes 
> for some some of the applications, gerbview for instance.  They show up in ps 
> and as Bernhard pointed out, the launcher even shows you the pid when it 
> launches them.  If it isn’t supposed to do this then perhaps just solving 
> this issue makes the rest go away.
> 
> 
> Garth
> 
> 
> On Oct 4, 2014, at 6:17 AM, Wayne Stambaugh  wrote:
> 
>> On 10/4/2014 4:26 AM, Bernhard Stegmaier wrote:
>>> Hi,
>>> 
>>> most of your observations are as far as I can see not a problem of the 
>>> bundles itself, but of the KiCad modular concept (kiface).
>>> When you launch pcbnew et al. from KiCad launcher the correct “application” 
>>> is only loaded as a module, so the main application is still kicad launcher 
>>> and I guess that’s why you for example see the same name, they do not have 
>>> their own icon, etc.
>> 
>> KiCad no longer launches executables that run in a separate process.
>> Since the kiway work was completed, Eeschema, Pcbnew, etc. are actually
>> child windows of the KiCad application.  Eeschema, Pcbnew, etc. are also
>> a stand alone programs but they don't get called from KiCad any longer.
>> Some users prefer to run the individual applications this way so it
>> would be nice if we could provide a separate icon and shortcut (or
>> whatever it's called on OSX) so that the stand alone applications could
>> be launched.
>> 
>>> 
>>> For the “dock roulette” there is possibly a way to set the application icon 
>>> of window dynamically using wxWidgets.
>>> Something to try… I guess behavior is the same on Linux/Windows, so the 
>>> might als benefit.
>>> 
>>> 
>>> Regards,
>>> Bernhard
>>> 
>>> On 04.10.2014, at 09:30, Garth Corral  wrote:
>>> 
 
 Hi all,
 
 I finally had a chance to build and try out the new all-inclusive OS X 
 application bundles and I’ve encountered a couple of issues that tend to 
 reduce the usability a bit for me.
 
 First, an observation unrelated to the new bundles.  I noticed with 
 mainline builds on OS X, some of the subsidiary applications, specifically 
 eeshcema and pcbnew, no longer have their own name in the application 
 menu.  Instead they have the name of the main application, KiCad.
 
 This is fine and I assumed it’s part of an effort to improve integration 
 between the applications.  On OS X, though, it’s a bit weird because the 
 application menu still has an entry to “Quit pcbnew” and selecting that or 
 Cmd-Q will indeed quit the sub-application, leaving you with a KiCad 
 application menu as it switched back the the main app.  Not really a huge 
 issue but is can be confusing and if you’re not paying attention you can 
 accidentally quit your main app.  Not cool.
 
 The additional things I’m seeing with the new bundling is that now the 
 applications the previously did launch as separate applications, even when 
 launched from the main app, now have no icon of their own.  They get the 
 icon of the main kicad.app.  So if I launch, say, gerbview and 
 pcb_calculator, I’ve now got three KiCad icons in my dock with no idea 
 which one belongs to which application.  I have to play icon roulette to 
 find out.  With the new CMak

Re: [Kicad-developers] A few issues with new OS X bundles

[Garth Corral]

I’m afraid that’s not true in this case.  It does launch separate processes for 
some some of the applications, gerbview for instance.  They show up in ps and 
as Bernhard pointed out, the launcher even shows you the pid when it launches 
them.  If it isn’t supposed to do this then perhaps just solving this issue 
makes the rest go away.


Garth


On Oct 4, 2014, at 6:17 AM, Wayne Stambaugh  wrote:

> On 10/4/2014 4:26 AM, Bernhard Stegmaier wrote:
>> Hi,
>> 
>> most of your observations are as far as I can see not a problem of the 
>> bundles itself, but of the KiCad modular concept (kiface).
>> When you launch pcbnew et al. from KiCad launcher the correct “application” 
>> is only loaded as a module, so the main application is still kicad launcher 
>> and I guess that’s why you for example see the same name, they do not have 
>> their own icon, etc.
> 
> KiCad no longer launches executables that run in a separate process.
> Since the kiway work was completed, Eeschema, Pcbnew, etc. are actually
> child windows of the KiCad application.  Eeschema, Pcbnew, etc. are also
> a stand alone programs but they don't get called from KiCad any longer.
> Some users prefer to run the individual applications this way so it
> would be nice if we could provide a separate icon and shortcut (or
> whatever it's called on OSX) so that the stand alone applications could
> be launched.
> 
>> 
>> For the “dock roulette” there is possibly a way to set the application icon 
>> of window dynamically using wxWidgets.
>> Something to try… I guess behavior is the same on Linux/Windows, so the 
>> might als benefit.
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> On 04.10.2014, at 09:30, Garth Corral  wrote:
>> 
>>> 
>>> Hi all,
>>> 
>>> I finally had a chance to build and try out the new all-inclusive OS X 
>>> application bundles and I’ve encountered a couple of issues that tend to 
>>> reduce the usability a bit for me.
>>> 
>>> First, an observation unrelated to the new bundles.  I noticed with 
>>> mainline builds on OS X, some of the subsidiary applications, specifically 
>>> eeshcema and pcbnew, no longer have their own name in the application menu. 
>>>  Instead they have the name of the main application, KiCad.
>>> 
>>> This is fine and I assumed it’s part of an effort to improve integration 
>>> between the applications.  On OS X, though, it’s a bit weird because the 
>>> application menu still has an entry to “Quit pcbnew” and selecting that or 
>>> Cmd-Q will indeed quit the sub-application, leaving you with a KiCad 
>>> application menu as it switched back the the main app.  Not really a huge 
>>> issue but is can be confusing and if you’re not paying attention you can 
>>> accidentally quit your main app.  Not cool.
>>> 
>>> The additional things I’m seeing with the new bundling is that now the 
>>> applications the previously did launch as separate applications, even when 
>>> launched from the main app, now have no icon of their own.  They get the 
>>> icon of the main kicad.app.  So if I launch, say, gerbview and 
>>> pcb_calculator, I’ve now got three KiCad icons in my dock with no idea 
>>> which one belongs to which application.  I have to play icon roulette to 
>>> find out.  With the new CMakeLists.txt changes for these applications it 
>>> seems there’s no way to go back to building individual application bundles 
>>> for them without hacking and slashing.
>>> 
>>> Any chance we can get back the ability to make bundles for these?  I’d go 
>>> so far as to recommend that the bundles be included wholesale in an 
>>> Applications directory int the main bundle, but I’d at least like the 
>>> option of building them as bundles separately.
>>> 
>>> 
>>> Thanks in advance,
>>> 
>>> Garth___
>>> 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
>> 
> 
> 
> 
> ___
> 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



smime.p7s
Description: S/MIME cryptographic signature
___
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] A few issues with new OS X bundles

[Wayne Stambaugh]

Since this doesn't effect me, I don't have a preference one way or
another.  Although option 2B makes the most sense to me.  OSX users
please weigh in so we can get this right.  You might want to get some
input from the user group on Yahoo.  There may be more OSX users than
developers and their input may be useful..Thanks again Bernhard for all
of your hard work.

On 10/4/2014 10:10 AM, Bernhard Stegmaier wrote:
> One additional note on (1):
> You can create an alias pointing to, e.g., the pcbnew executable inside
> the kicad bundle and put it where you want.
> Therewith, you can start pcbnew directly by clicking on it - only
> downside is that since pcbnew executable looks like a command line
> binary for OSX a terminal is started in which then pcbnew is executed.
> 
> 
> Regards,
> Bernhard
> 
> On 04.10.2014, at 15:56, Bernhard Stegmaier  > wrote:
> 
>> There are 2 possibilities as far as I can see:
>>
>> *(1) One single application bundle - like it is now.*
>> There are probably still some cosmetic issues as Garth told, but I
>> think these are just minor inconsistencies that could be sorted out.
>> From an efficiency point of view it is no difference… 2 clicks this
>> way to start e.g. pcbnew (first click opens kicad launcher, second
>> pcbnew), the same for the “old” approach (one click to open KiCad
>> folder, second to start pcbnew).
>> Positive: No space wasted
>> Positive: No dependency problems, it just is self-contained and
>> completely relocatable
>> Negative: May break with users habits (Apple does this all the time,
>> so nothing new for OSX users… :) )
>>
>> *(2) A KiCad-fodler with one application bundle per “executable” -
>> from a users point of view how it was before.*
>> Again, two options:
>> *(2a) Self-contained bundles *
>> You have to pull every dependency into every bundle. 
>> Especially, you also have to duplicate all the *.kifaces into the
>> kicad bundle for the launcher (and maybe also into other bundles e.g.
>> if you want/could launch pcbnew from eeschema - don’t know if that is
>> possible).
>> If you don’t do it like that (as it was before using symlinks between
>> bundles), it looks like it is a normal OSX application you can move
>> around where you want, but actually you can’t because you break
>> inter-bundle dependencies.
>> Maybe it is not a regular use-case to pull e.g. pcbnew out of the
>> KiCad folder, but nobody forbids that… so maybe someone likes to drag
>> pcbnew to his desktop because then it’s only one click to start...
>> Positive: Everything is individually self-contained
>> Negative: Space wasted for duplicating things - especially pcbnew with
>> scripting pulls in all the wxPython stuff that will be contained at
>> least twice then...
>> *(2b) App-Folder + Individual Bundles + Common-Folder*
>> All the dependencies and the *.kifaces are put into the common folder,
>> the bundles itself are linked in a way to use things from the common
>> folder. 
>> Positive: No space wasted
>> Negative: Inter-Bundle dependencies as explained in (2a).
>> Negative: Just a cosmetic issue, but you always see that common folder
>> in the dock launcher
>>
>> One thing to note is that even in (1) you could start, e.g., pcbnew
>> from command line as “standalone” binary.
>>
>> I must confess, I am not an OSX bundle guru. 
>> If anybody has a nice other solution, I’ll be glad to hear.
>>
>>
>> Regards,
>> Bernhard
>>
>> On 04.10.2014, at 15:17, Wayne Stambaugh > > wrote:
>>
>>> On 10/4/2014 4:26 AM, Bernhard Stegmaier wrote:
 Hi,

 most of your observations are as far as I can see not a problem of
 the bundles itself, but of the KiCad modular concept (kiface).
 When you launch pcbnew et al. from KiCad launcher the correct
 “application” is only loaded as a module, so the main application is
 still kicad launcher and I guess that’s why you for example see the
 same name, they do not have their own icon, etc.
>>>
>>> KiCad no longer launches executables that run in a separate process.
>>> Since the kiway work was completed, Eeschema, Pcbnew, etc. are actually
>>> child windows of the KiCad application.  Eeschema, Pcbnew, etc. are also
>>> a stand alone programs but they don't get called from KiCad any longer.
>>> Some users prefer to run the individual applications this way so it
>>> would be nice if we could provide a separate icon and shortcut (or
>>> whatever it's called on OSX) so that the stand alone applications could
>>> be launched.
>>>

 For the “dock roulette” there is possibly a way to set the
 application icon of window dynamically using wxWidgets.
 Something to try… I guess behavior is the same on Linux/Windows, so
 the might als benefit.


 Regards,
 Bernhard

 On 04.10.2014, at 09:30, Garth Corral >>> > wrote:

>
> Hi all,
>
> I finally had a chance to build and try out the new all-

Re: [Kicad-developers] A few issues with new OS X bundles

[Bernhard Stegmaier]

One additional note on (1):
You can create an alias pointing to, e.g., the pcbnew executable inside the 
kicad bundle and put it where you want.
Therewith, you can start pcbnew directly by clicking on it - only downside is 
that since pcbnew executable looks like a command line binary for OSX a 
terminal is started in which then pcbnew is executed.


Regards,
Bernhard

On 04.10.2014, at 15:56, Bernhard Stegmaier  wrote:

> There are 2 possibilities as far as I can see:
> 
> (1) One single application bundle - like it is now.
> There are probably still some cosmetic issues as Garth told, but I think 
> these are just minor inconsistencies that could be sorted out.
> From an efficiency point of view it is no difference… 2 clicks this way to 
> start e.g. pcbnew (first click opens kicad launcher, second pcbnew), the same 
> for the “old” approach (one click to open KiCad folder, second to start 
> pcbnew).
> Positive: No space wasted
> Positive: No dependency problems, it just is self-contained and completely 
> relocatable
> Negative: May break with users habits (Apple does this all the time, so 
> nothing new for OSX users… :) )
> 
> (2) A KiCad-fodler with one application bundle per “executable” - from a 
> users point of view how it was before.
> Again, two options:
> (2a) Self-contained bundles 
> You have to pull every dependency into every bundle. 
> Especially, you also have to duplicate all the *.kifaces into the kicad 
> bundle for the launcher (and maybe also into other bundles e.g. if you 
> want/could launch pcbnew from eeschema - don’t know if that is possible).
> If you don’t do it like that (as it was before using symlinks between 
> bundles), it looks like it is a normal OSX application you can move around 
> where you want, but actually you can’t because you break inter-bundle 
> dependencies.
> Maybe it is not a regular use-case to pull e.g. pcbnew out of the KiCad 
> folder, but nobody forbids that… so maybe someone likes to drag pcbnew to his 
> desktop because then it’s only one click to start...
> Positive: Everything is individually self-contained
> Negative: Space wasted for duplicating things - especially pcbnew with 
> scripting pulls in all the wxPython stuff that will be contained at least 
> twice then...
> (2b) App-Folder + Individual Bundles + Common-Folder
> All the dependencies and the *.kifaces are put into the common folder, the 
> bundles itself are linked in a way to use things from the common folder. 
> Positive: No space wasted
> Negative: Inter-Bundle dependencies as explained in (2a).
> Negative: Just a cosmetic issue, but you always see that common folder in the 
> dock launcher
> 
> One thing to note is that even in (1) you could start, e.g., pcbnew from 
> command line as “standalone” binary.
> 
> I must confess, I am not an OSX bundle guru. 
> If anybody has a nice other solution, I’ll be glad to hear.
> 
> 
> Regards,
> Bernhard
> 
> On 04.10.2014, at 15:17, Wayne Stambaugh  wrote:
> 
>> On 10/4/2014 4:26 AM, Bernhard Stegmaier wrote:
>>> Hi,
>>> 
>>> most of your observations are as far as I can see not a problem of the 
>>> bundles itself, but of the KiCad modular concept (kiface).
>>> When you launch pcbnew et al. from KiCad launcher the correct “application” 
>>> is only loaded as a module, so the main application is still kicad launcher 
>>> and I guess that’s why you for example see the same name, they do not have 
>>> their own icon, etc.
>> 
>> KiCad no longer launches executables that run in a separate process.
>> Since the kiway work was completed, Eeschema, Pcbnew, etc. are actually
>> child windows of the KiCad application.  Eeschema, Pcbnew, etc. are also
>> a stand alone programs but they don't get called from KiCad any longer.
>> Some users prefer to run the individual applications this way so it
>> would be nice if we could provide a separate icon and shortcut (or
>> whatever it's called on OSX) so that the stand alone applications could
>> be launched.
>> 
>>> 
>>> For the “dock roulette” there is possibly a way to set the application icon 
>>> of window dynamically using wxWidgets.
>>> Something to try… I guess behavior is the same on Linux/Windows, so the 
>>> might als benefit.
>>> 
>>> 
>>> Regards,
>>> Bernhard
>>> 
>>> On 04.10.2014, at 09:30, Garth Corral  wrote:
>>> 
 
 Hi all,
 
 I finally had a chance to build and try out the new all-inclusive OS X 
 application bundles and I’ve encountered a couple of issues that tend to 
 reduce the usability a bit for me.
 
 First, an observation unrelated to the new bundles.  I noticed with 
 mainline builds on OS X, some of the subsidiary applications, specifically 
 eeshcema and pcbnew, no longer have their own name in the application 
 menu.  Instead they have the name of the main application, KiCad.
 
 This is fine and I assumed it’s part of an effort to improve integration 
 between the applications.  On OS X, though, it’s a bit weird beca

Re: [Kicad-developers] A few issues with new OS X bundles

[Bernhard Stegmaier]

There are 2 possibilities as far as I can see:

(1) One single application bundle - like it is now.
There are probably still some cosmetic issues as Garth told, but I think these 
are just minor inconsistencies that could be sorted out.
From an efficiency point of view it is no difference… 2 clicks this way to 
start e.g. pcbnew (first click opens kicad launcher, second pcbnew), the same 
for the “old” approach (one click to open KiCad folder, second to start pcbnew).
Positive: No space wasted
Positive: No dependency problems, it just is self-contained and completely 
relocatable
Negative: May break with users habits (Apple does this all the time, so nothing 
new for OSX users… :) )

(2) A KiCad-fodler with one application bundle per “executable” - from a users 
point of view how it was before.
Again, two options:
(2a) Self-contained bundles 
You have to pull every dependency into every bundle. 
Especially, you also have to duplicate all the *.kifaces into the kicad bundle 
for the launcher (and maybe also into other bundles e.g. if you want/could 
launch pcbnew from eeschema - don’t know if that is possible).
If you don’t do it like that (as it was before using symlinks between bundles), 
it looks like it is a normal OSX application you can move around where you 
want, but actually you can’t because you break inter-bundle dependencies.
Maybe it is not a regular use-case to pull e.g. pcbnew out of the KiCad folder, 
but nobody forbids that… so maybe someone likes to drag pcbnew to his desktop 
because then it’s only one click to start...
Positive: Everything is individually self-contained
Negative: Space wasted for duplicating things - especially pcbnew with 
scripting pulls in all the wxPython stuff that will be contained at least twice 
then...
(2b) App-Folder + Individual Bundles + Common-Folder
All the dependencies and the *.kifaces are put into the common folder, the 
bundles itself are linked in a way to use things from the common folder. 
Positive: No space wasted
Negative: Inter-Bundle dependencies as explained in (2a).
Negative: Just a cosmetic issue, but you always see that common folder in the 
dock launcher

One thing to note is that even in (1) you could start, e.g., pcbnew from 
command line as “standalone” binary.

I must confess, I am not an OSX bundle guru. 
If anybody has a nice other solution, I’ll be glad to hear.


Regards,
Bernhard

On 04.10.2014, at 15:17, Wayne Stambaugh  wrote:

> On 10/4/2014 4:26 AM, Bernhard Stegmaier wrote:
>> Hi,
>> 
>> most of your observations are as far as I can see not a problem of the 
>> bundles itself, but of the KiCad modular concept (kiface).
>> When you launch pcbnew et al. from KiCad launcher the correct “application” 
>> is only loaded as a module, so the main application is still kicad launcher 
>> and I guess that’s why you for example see the same name, they do not have 
>> their own icon, etc.
> 
> KiCad no longer launches executables that run in a separate process.
> Since the kiway work was completed, Eeschema, Pcbnew, etc. are actually
> child windows of the KiCad application.  Eeschema, Pcbnew, etc. are also
> a stand alone programs but they don't get called from KiCad any longer.
> Some users prefer to run the individual applications this way so it
> would be nice if we could provide a separate icon and shortcut (or
> whatever it's called on OSX) so that the stand alone applications could
> be launched.
> 
>> 
>> For the “dock roulette” there is possibly a way to set the application icon 
>> of window dynamically using wxWidgets.
>> Something to try… I guess behavior is the same on Linux/Windows, so the 
>> might als benefit.
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> On 04.10.2014, at 09:30, Garth Corral  wrote:
>> 
>>> 
>>> Hi all,
>>> 
>>> I finally had a chance to build and try out the new all-inclusive OS X 
>>> application bundles and I’ve encountered a couple of issues that tend to 
>>> reduce the usability a bit for me.
>>> 
>>> First, an observation unrelated to the new bundles.  I noticed with 
>>> mainline builds on OS X, some of the subsidiary applications, specifically 
>>> eeshcema and pcbnew, no longer have their own name in the application menu. 
>>>  Instead they have the name of the main application, KiCad.
>>> 
>>> This is fine and I assumed it’s part of an effort to improve integration 
>>> between the applications.  On OS X, though, it’s a bit weird because the 
>>> application menu still has an entry to “Quit pcbnew” and selecting that or 
>>> Cmd-Q will indeed quit the sub-application, leaving you with a KiCad 
>>> application menu as it switched back the the main app.  Not really a huge 
>>> issue but is can be confusing and if you’re not paying attention you can 
>>> accidentally quit your main app.  Not cool.
>>> 
>>> The additional things I’m seeing with the new bundling is that now the 
>>> applications the previously did launch as separate applications, even when 
>>> launched from the main app, now have no icon of

Re: [Kicad-developers] A few issues with new OS X bundles

[Wayne Stambaugh]

On 10/4/2014 4:26 AM, Bernhard Stegmaier wrote:
> Hi,
> 
> most of your observations are as far as I can see not a problem of the 
> bundles itself, but of the KiCad modular concept (kiface).
> When you launch pcbnew et al. from KiCad launcher the correct “application” 
> is only loaded as a module, so the main application is still kicad launcher 
> and I guess that’s why you for example see the same name, they do not have 
> their own icon, etc.

KiCad no longer launches executables that run in a separate process.
Since the kiway work was completed, Eeschema, Pcbnew, etc. are actually
child windows of the KiCad application.  Eeschema, Pcbnew, etc. are also
a stand alone programs but they don't get called from KiCad any longer.
 Some users prefer to run the individual applications this way so it
would be nice if we could provide a separate icon and shortcut (or
whatever it's called on OSX) so that the stand alone applications could
be launched.

> 
> For the “dock roulette” there is possibly a way to set the application icon 
> of window dynamically using wxWidgets.
> Something to try… I guess behavior is the same on Linux/Windows, so the might 
> als benefit.
> 
> 
> Regards,
> Bernhard
> 
> On 04.10.2014, at 09:30, Garth Corral  wrote:
> 
>>
>> Hi all,
>>
>> I finally had a chance to build and try out the new all-inclusive OS X 
>> application bundles and I’ve encountered a couple of issues that tend to 
>> reduce the usability a bit for me.
>>
>> First, an observation unrelated to the new bundles.  I noticed with mainline 
>> builds on OS X, some of the subsidiary applications, specifically eeshcema 
>> and pcbnew, no longer have their own name in the application menu.  Instead 
>> they have the name of the main application, KiCad.
>>
>> This is fine and I assumed it’s part of an effort to improve integration 
>> between the applications.  On OS X, though, it’s a bit weird because the 
>> application menu still has an entry to “Quit pcbnew” and selecting that or 
>> Cmd-Q will indeed quit the sub-application, leaving you with a KiCad 
>> application menu as it switched back the the main app.  Not really a huge 
>> issue but is can be confusing and if you’re not paying attention you can 
>> accidentally quit your main app.  Not cool.
>>
>> The additional things I’m seeing with the new bundling is that now the 
>> applications the previously did launch as separate applications, even when 
>> launched from the main app, now have no icon of their own.  They get the 
>> icon of the main kicad.app.  So if I launch, say, gerbview and 
>> pcb_calculator, I’ve now got three KiCad icons in my dock with no idea which 
>> one belongs to which application.  I have to play icon roulette to find out. 
>>  With the new CMakeLists.txt changes for these applications it seems there’s 
>> no way to go back to building individual application bundles for them 
>> without hacking and slashing.
>>
>> Any chance we can get back the ability to make bundles for these?  I’d go so 
>> far as to recommend that the bundles be included wholesale in an 
>> Applications directory int the main bundle, but I’d at least like the option 
>> of building them as bundles separately.
>>
>>
>> Thanks in advance,
>>
>> Garth___
>> 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
> 



___
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] A few issues with new OS X bundles

[Garth Corral]

I’m sure it will get there.  I certainly prefer the approach you are taking of 
eliminating these as standalone application bundles.  There really isn’t a need 
for them with the kicad launcher.  It’s just introduced a couple of minor 
usability nits for me, which I’m sure will be cured over time.  I’ll poke at it 
tomorrow and see if I can get things to work for me without resorting to 
building bundles for them.  Failing that, I will just patch the CMakeLists for 
the time being.

Garth


On Oct 4, 2014, at 2:00 AM, Bernhard Stegmaier  wrote:

> Hi again,
> 
> again for the “dock roulette”… IMHO this is just an inconsistency between how 
> pcbnew/eeschema and gerbview/other apps are started from KiCad launcher. For 
> pcbnew/eeschema no individual icon in the dock is created, but for the others.
> For the other apps you also see a message “kicad.app/Contents/MacOS/pl_editor 
> opened [pid=89027]” in KiCad launcher (even being a .kiface module), you 
> don’t see that for eeschema/pcbnew.
> 
> I guess it should be the same for all apps/modules except bitmap2component, 
> which currently doesn’t have a kiface.
> 
> 
> Regards,
> Bernhard
> 
> 
> On 04.10.2014, at 10:26, Bernhard Stegmaier  wrote:
> 
>> Hi,
>> 
>> most of your observations are as far as I can see not a problem of the 
>> bundles itself, but of the KiCad modular concept (kiface).
>> When you launch pcbnew et al. from KiCad launcher the correct “application” 
>> is only loaded as a module, so the main application is still kicad launcher 
>> and I guess that’s why you for example see the same name, they do not have 
>> their own icon, etc.
>> 
>> For the “dock roulette” there is possibly a way to set the application icon 
>> of window dynamically using wxWidgets.
>> Something to try… I guess behavior is the same on Linux/Windows, so the 
>> might als benefit.
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> On 04.10.2014, at 09:30, Garth Corral  wrote:
>> 
>>> 
>>> Hi all,
>>> 
>>> I finally had a chance to build and try out the new all-inclusive OS X 
>>> application bundles and I’ve encountered a couple of issues that tend to 
>>> reduce the usability a bit for me.
>>> 
>>> First, an observation unrelated to the new bundles.  I noticed with 
>>> mainline builds on OS X, some of the subsidiary applications, specifically 
>>> eeshcema and pcbnew, no longer have their own name in the application menu. 
>>>  Instead they have the name of the main application, KiCad.
>>> 
>>> This is fine and I assumed it’s part of an effort to improve integration 
>>> between the applications.  On OS X, though, it’s a bit weird because the 
>>> application menu still has an entry to “Quit pcbnew” and selecting that or 
>>> Cmd-Q will indeed quit the sub-application, leaving you with a KiCad 
>>> application menu as it switched back the the main app.  Not really a huge 
>>> issue but is can be confusing and if you’re not paying attention you can 
>>> accidentally quit your main app.  Not cool.
>>> 
>>> The additional things I’m seeing with the new bundling is that now the 
>>> applications the previously did launch as separate applications, even when 
>>> launched from the main app, now have no icon of their own.  They get the 
>>> icon of the main kicad.app.  So if I launch, say, gerbview and 
>>> pcb_calculator, I’ve now got three KiCad icons in my dock with no idea 
>>> which one belongs to which application.  I have to play icon roulette to 
>>> find out.  With the new CMakeLists.txt changes for these applications it 
>>> seems there’s no way to go back to building individual application bundles 
>>> for them without hacking and slashing.
>>> 
>>> Any chance we can get back the ability to make bundles for these?  I’d go 
>>> so far as to recommend that the bundles be included wholesale in an 
>>> Applications directory int the main bundle, but I’d at least like the 
>>> option of building them as bundles separately.
>>> 
>>> 
>>> Thanks in advance,
>>> 
>>> Garth___
>>> 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
> 



smime.p7s
Description: S/MIME cryptographic signature
___
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] A few issues with new OS X bundles

[Bernhard Stegmaier]

Hi again,

again for the “dock roulette”… IMHO this is just an inconsistency between how 
pcbnew/eeschema and gerbview/other apps are started from KiCad launcher. For 
pcbnew/eeschema no individual icon in the dock is created, but for the others.
For the other apps you also see a message “kicad.app/Contents/MacOS/pl_editor 
opened [pid=89027]” in KiCad launcher (even being a .kiface module), you don’t 
see that for eeschema/pcbnew.

I guess it should be the same for all apps/modules except bitmap2component, 
which currently doesn’t have a kiface.


Regards,
Bernhard


On 04.10.2014, at 10:26, Bernhard Stegmaier  wrote:

> Hi,
> 
> most of your observations are as far as I can see not a problem of the 
> bundles itself, but of the KiCad modular concept (kiface).
> When you launch pcbnew et al. from KiCad launcher the correct “application” 
> is only loaded as a module, so the main application is still kicad launcher 
> and I guess that’s why you for example see the same name, they do not have 
> their own icon, etc.
> 
> For the “dock roulette” there is possibly a way to set the application icon 
> of window dynamically using wxWidgets.
> Something to try… I guess behavior is the same on Linux/Windows, so the might 
> als benefit.
> 
> 
> Regards,
> Bernhard
> 
> On 04.10.2014, at 09:30, Garth Corral  wrote:
> 
>> 
>> Hi all,
>> 
>> I finally had a chance to build and try out the new all-inclusive OS X 
>> application bundles and I’ve encountered a couple of issues that tend to 
>> reduce the usability a bit for me.
>> 
>> First, an observation unrelated to the new bundles.  I noticed with mainline 
>> builds on OS X, some of the subsidiary applications, specifically eeshcema 
>> and pcbnew, no longer have their own name in the application menu.  Instead 
>> they have the name of the main application, KiCad.
>> 
>> This is fine and I assumed it’s part of an effort to improve integration 
>> between the applications.  On OS X, though, it’s a bit weird because the 
>> application menu still has an entry to “Quit pcbnew” and selecting that or 
>> Cmd-Q will indeed quit the sub-application, leaving you with a KiCad 
>> application menu as it switched back the the main app.  Not really a huge 
>> issue but is can be confusing and if you’re not paying attention you can 
>> accidentally quit your main app.  Not cool.
>> 
>> The additional things I’m seeing with the new bundling is that now the 
>> applications the previously did launch as separate applications, even when 
>> launched from the main app, now have no icon of their own.  They get the 
>> icon of the main kicad.app.  So if I launch, say, gerbview and 
>> pcb_calculator, I’ve now got three KiCad icons in my dock with no idea which 
>> one belongs to which application.  I have to play icon roulette to find out. 
>>  With the new CMakeLists.txt changes for these applications it seems there’s 
>> no way to go back to building individual application bundles for them 
>> without hacking and slashing.
>> 
>> Any chance we can get back the ability to make bundles for these?  I’d go so 
>> far as to recommend that the bundles be included wholesale in an 
>> Applications directory int the main bundle, but I’d at least like the option 
>> of building them as bundles separately.
>> 
>> 
>> Thanks in advance,
>> 
>> Garth___
>> 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

___
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] A few issues with new OS X bundles

[Garth Corral]

Right.  I get that for the loadable bundles the application is still KiCad, but 
for those applications there’s no second icon, which is probably better 
behavior.  Then you only have the problem of them having a Quit menu item that 
does not quit the application but just unloads the bundle, which I’d argue will 
be surprising behavior for most mac users.

The new issue that is bundle related is that for the applications that don’t do 
this, the ones that launch a separate process, the new bundling deprives them 
of their icon and they look indistinguishable from the main application.  
These, I think, should have their icons back until such time as they are 
integrated in the same way as eeschema and pcbnew (or can dynamically change 
their icon).  I’d just like to be able to build bundles for these so that I can 
integrate them into my bundle in a different way.  They don’t have to build 
bundles by default, but it’d be nice if I could build a separate target.


Garth

On Oct 4, 2014, at 1:26 AM, Bernhard Stegmaier  wrote:

> Hi,
> 
> most of your observations are as far as I can see not a problem of the 
> bundles itself, but of the KiCad modular concept (kiface).
> When you launch pcbnew et al. from KiCad launcher the correct “application” 
> is only loaded as a module, so the main application is still kicad launcher 
> and I guess that’s why you for example see the same name, they do not have 
> their own icon, etc.
> 
> For the “dock roulette” there is possibly a way to set the application icon 
> of window dynamically using wxWidgets.
> Something to try… I guess behavior is the same on Linux/Windows, so the might 
> als benefit.
> 
> 
> Regards,
> Bernhard
> 
> On 04.10.2014, at 09:30, Garth Corral  wrote:
> 
>> 
>> Hi all,
>> 
>> I finally had a chance to build and try out the new all-inclusive OS X 
>> application bundles and I’ve encountered a couple of issues that tend to 
>> reduce the usability a bit for me.
>> 
>> First, an observation unrelated to the new bundles.  I noticed with mainline 
>> builds on OS X, some of the subsidiary applications, specifically eeshcema 
>> and pcbnew, no longer have their own name in the application menu.  Instead 
>> they have the name of the main application, KiCad.
>> 
>> This is fine and I assumed it’s part of an effort to improve integration 
>> between the applications.  On OS X, though, it’s a bit weird because the 
>> application menu still has an entry to “Quit pcbnew” and selecting that or 
>> Cmd-Q will indeed quit the sub-application, leaving you with a KiCad 
>> application menu as it switched back the the main app.  Not really a huge 
>> issue but is can be confusing and if you’re not paying attention you can 
>> accidentally quit your main app.  Not cool.
>> 
>> The additional things I’m seeing with the new bundling is that now the 
>> applications the previously did launch as separate applications, even when 
>> launched from the main app, now have no icon of their own.  They get the 
>> icon of the main kicad.app.  So if I launch, say, gerbview and 
>> pcb_calculator, I’ve now got three KiCad icons in my dock with no idea which 
>> one belongs to which application.  I have to play icon roulette to find out. 
>>  With the new CMakeLists.txt changes for these applications it seems there’s 
>> no way to go back to building individual application bundles for them 
>> without hacking and slashing.
>> 
>> Any chance we can get back the ability to make bundles for these?  I’d go so 
>> far as to recommend that the bundles be included wholesale in an 
>> Applications directory int the main bundle, but I’d at least like the option 
>> of building them as bundles separately.
>> 
>> 
>> Thanks in advance,
>> 
>> Garth___
>> 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



smime.p7s
Description: S/MIME cryptographic signature
___
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] A few issues with new OS X bundles

[Bernhard Stegmaier]

Hi,

most of your observations are as far as I can see not a problem of the bundles 
itself, but of the KiCad modular concept (kiface).
When you launch pcbnew et al. from KiCad launcher the correct “application” is 
only loaded as a module, so the main application is still kicad launcher and I 
guess that’s why you for example see the same name, they do not have their own 
icon, etc.

For the “dock roulette” there is possibly a way to set the application icon of 
window dynamically using wxWidgets.
Something to try… I guess behavior is the same on Linux/Windows, so the might 
als benefit.


Regards,
Bernhard

On 04.10.2014, at 09:30, Garth Corral  wrote:

> 
> Hi all,
> 
> I finally had a chance to build and try out the new all-inclusive OS X 
> application bundles and I’ve encountered a couple of issues that tend to 
> reduce the usability a bit for me.
> 
> First, an observation unrelated to the new bundles.  I noticed with mainline 
> builds on OS X, some of the subsidiary applications, specifically eeshcema 
> and pcbnew, no longer have their own name in the application menu.  Instead 
> they have the name of the main application, KiCad.
> 
> This is fine and I assumed it’s part of an effort to improve integration 
> between the applications.  On OS X, though, it’s a bit weird because the 
> application menu still has an entry to “Quit pcbnew” and selecting that or 
> Cmd-Q will indeed quit the sub-application, leaving you with a KiCad 
> application menu as it switched back the the main app.  Not really a huge 
> issue but is can be confusing and if you’re not paying attention you can 
> accidentally quit your main app.  Not cool.
> 
> The additional things I’m seeing with the new bundling is that now the 
> applications the previously did launch as separate applications, even when 
> launched from the main app, now have no icon of their own.  They get the icon 
> of the main kicad.app.  So if I launch, say, gerbview and pcb_calculator, 
> I’ve now got three KiCad icons in my dock with no idea which one belongs to 
> which application.  I have to play icon roulette to find out.  With the new 
> CMakeLists.txt changes for these applications it seems there’s no way to go 
> back to building individual application bundles for them without hacking and 
> slashing.
> 
> Any chance we can get back the ability to make bundles for these?  I’d go so 
> far as to recommend that the bundles be included wholesale in an Applications 
> directory int the main bundle, but I’d at least like the option of building 
> them as bundles separately.
> 
> 
> Thanks in advance,
> 
> Garth___
> 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