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 <gcor...@abode.com > <mailto:gcor...@abode.com>> 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 >> <stegma...@sw-systems.de <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, 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 <stambau...@verizon.net >>> <mailto:stambau...@verizon.net>> 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 <gcor...@abode.com >>>>> <mailto:gcor...@abode.com>> 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 >>>>>> <mailto: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 >>>>> <mailto: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 >>>> <mailto: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 >>> <mailto: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