kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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 <gcorral@xxxxxxxxx
> <mailto:gcorral@xxxxxxxxx>> 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
>> <stegmaier@xxxxxxxxxxxxx <mailto:stegmaier@xxxxxxxxxxxxx>> 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 <stambaughw@xxxxxxxxxxx
>>> <mailto:stambaughw@xxxxxxxxxxx>> 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 <gcorral@xxxxxxxxx
>>>>> <mailto:gcorral@xxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxx
>>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>