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 <stambau...@verizon.net > <mailto:stambau...@verizon.net>> 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 <gcor...@abode.com >>> <mailto: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> <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> >>>>> <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> >>>>>>> <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> >>>>>>>> <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> >>>>>>> <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> >>>>>> <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> >>>>> <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