kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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 <stambaughw@xxxxxxxxxxx
> <mailto: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>
>>> <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> <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>
>>>>> <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>
>>>>>>> <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>
>>>>>>>> <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>
>>>>>>> <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>
>>>>>> <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>
>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>