kicad-developers team mailing list archive

[Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>]

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 <stambaughw@xxxxxxxxxxx> 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 <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