kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

The component and 3D model libraries are a good idea.  If the user
doesn't like the github plugin, then you could also include the
footprint libraries.  One thing I didn't see in Bernhard's patch was the
Documentation.  That is definitely a must at some point in order to have
a stable release.  I figure one step at time and we'll get there.  I
think this is a good first step.

On 10/2/2014 2:52 PM, Adam Wolf wrote:
> No problem--I certainly can't look at it until Saturday or Sunday, but
> I'm seriously very excited about this!
> 
> When I pointed a few users at the bundle, they said "Where are the
> libraries?"
> 
> I will probably look at what the damage would be to pull in the Github
> libraries into the bundle and point the tools at it, unless someone has
> already started.
> 
> Adam Wolf
> 
> Ad
> 
> On Oct 2, 2014 1:45 PM, "Wayne Stambaugh" <stambaughw@xxxxxxxxxxx
> <mailto:stambaughw@xxxxxxxxxxx>> wrote:
> 
>     Sorry guys.  I got sidetracked last night with some 3D stuff and I
>     didn't get it committed.  I've already tested to make sure it didn't
>     break windows or linux builds so it's ready to commit.  I will do my
>     best to get it committed this evening when I get home from work.
> 
>     Wayne
> 
>     On 10/2/2014 2:38 PM, Bernhard Stegmaier wrote:
>     > Hi Adam,
>     >
>     > it’s already on Wayne’s desk to commit…
>     >
>     >
>     > Regards,
>     > Bernhard
>     >
>     > On 02.10.2014, at 20:37, Adam Wolf <adamwwolf@xxxxxxxxx
>     <mailto:adamwwolf@xxxxxxxxx>
>     > <mailto:adamwwolf@xxxxxxxxx <mailto:adamwwolf@xxxxxxxxx>>> wrote:
>     >
>     >> Hi Bernhard,
>     >>
>     >> Sorry to threadjack, but do you have any ETA on the patch that
>     created
>     >> that bundle?  I'm extremely excited to release nightlies...
>     >>
>     >> Adam Wolf
>     >> Cofounder and Engineer
>     >> Wayne and Layne LLC
>     >>
>     >> On Oct 2, 2014 1:29 PM, "Bernhard Stegmaier"
>     <stegmaier@xxxxxxxxxxxxx <mailto:stegmaier@xxxxxxxxxxxxx>
>     >> <mailto:stegmaier@xxxxxxxxxxxxx
>     <mailto:stegmaier@xxxxxxxxxxxxx>>> wrote:
>     >>
>     >>     Hi Garth,
>     >>
>     >>     see below.
>     >>
>     >>
>     >>     Regards,
>     >>     Bernhard
>     >>
>     >>     On 02.10.2014, at 18:23, Garth Corral <gcorral@xxxxxxxxx
>     <mailto:gcorral@xxxxxxxxx>
>     >>     <mailto:gcorral@xxxxxxxxx <mailto:gcorral@xxxxxxxxx>>> wrote:
>     >>
>     >>>     Hi Bernhard,
>     >>>
>     >>>     I looked around through the application bundle you posted
>     and had
>     >>>     some questions about the proposed layout.  It seems there is
>     some
>     >>>     arbitrary placement of files in the bundle.  I know it
>     ultimately
>     >>>     doesn’t matter to most users as long as it runs and behaves
>     >>>     properly but it doesn’t really follow the usual guidelines for
>     >>>     layout.
>     >>     Well… it is like CMake BundleUtilities do it out of the box. I
>     >>     didn’t implement that.
>     >>
>     >>>     Is there any chance that the dylibs could not be dumped in the
>     >>>     MacOS directory?  They really don’t belong there, as is the case
>     >>>     for most everything in there.  I think these should be in a
>     >>>     Frameworks directory at the very least.  Also, and this is
>     just a
>     >>>     point of curiosity, but why is libX11 included in these
>     >>>     libraries?  What requires that to run?
>     >>     I will check that. There is one parameter for CMake’s
>     >>     fixup_bundle() that might do the trick, but it is not really
>     >>     documented.
>     >>     I will have to check the code what it does exactly and if/how it
>     >>     could be changed.
>     >>     BundleUtilities just include what is not standard. Obviously the
>     >>     cairo which got picked up was built by MacPorts and has some
>     >>     transitive dependencies to the libX11 also built by MacPorts
>     - all
>     >>     the libs that are in the bundle come from my /opt/local
>     folder, so
>     >>     this is fine. Things may be different with other setups.
>     >>
>     >>>     Same for the command line binaries, they are things that are not
>     >>>     required for the application to run so belong out in a support
>     >>>     directory of some kind.
>     >>     I also thought about not putting them into the bundle at all, but
>     >>     I did because it doesn’t hurt and some people might still use
>     them
>     >>     directly.
>     >>     The command line binaries of .kiface applications must be in the
>     >>     same folder as the .kiface - or you again have to link stuff.
>     >>
>     >>>     I’m not familiar with the kiface files, but they appear to be
>     >>>     loadable bundles, which also don’t belong there.  Probably
>     belong
>     >>>     in a PlugIns directory
>     >>     Yes, maybe… but the same as above. As it is currently implemented
>     >>     they must be in the same folder as the main kicad application,
>     >>     otherwise they won’t be loaded.
>     >>
>     >>>     It looks like the remainder of the applications are in there as
>     >>>     well, albeit not integrated into application bundles themselves.
>     >>>     Not really sure how those should be integrated, but putting
>     their
>     >>>     pieces in the MacOS directory doesn’t seem ideal.  Any chance
>     >>>     these applications could just be consumed whole in an
>     >>>     Applications directory inside the main app?  Apple does this for
>     >>>     some of their own applications.  It doesn’t provide much in the
>     >>>     way of additional functionality but it does allow things to be
>     >>>     organized in a cleaner way, and as a side effect the
>     applications
>     >>>     could still be run standalone in a pinch.
>     >>     Well, yes, maybe it is not ideal to have the idf* tools in there.
>     >>     But, at least they are there and can be used. Some other project
>     >>     like for example Calibre also just put them into the bundle
>     as I did.
>     >>     Normally, that stuff probably should go directly to the
>     >>     filesystem, but then you have to write an installer, or some
>     >>     script that does copying.
>     >>
>     >>>     Obviously the intent going forward is to have only the one main
>     >>>     application, but it doesn’t seem like the current structure of
>     >>>     the project is quite there yet.
>     >>     The main intent was to *not* bundle all dependencies in *every*
>     >>     individual bundle for pcbnew, eeschema, etc. as it was before and
>     >>     to remove the dependencies between the bundles that were imposed
>     >>     by symlinks to the kifaces.
>     >>     Further, also one main intent was to use default tools to create
>     >>     the bundle like CMake’s BundleUtilities.
>     >>
>     >>>     Anyway, I know that not all applications follow the model,
>     but it
>     >>>     seems like it would be good to try to lay things out in as
>     >>>     standard a way as possible, accounting for application needs, of
>     >>>     course.
>     >>     You’re welcome to continue my work and make the internals more
>     >>     Apple-like - this would probably impose some more changes not
>     only
>     >>     to build process, but also the code.
>     >>     For me, it’s more important that an application behaves and feels
>     >>     more OSX like from a users point of view than to have every
>     >>     internal thing the right way Apple said it had to be.
>     >>
>     >>>     Here’s Apple’s guidelines.  Again, I know not everything fits.
>     >>>
>     >>>   
>      https://developer.apple.com/library/ios/documentation/CoreFoundation/Conceptual/CFBundles
>     >>>
>     >>>     Garth
>     >>>>     Hi all,
>     >>>>
>     >>>>     as Wayne already mentioned below I made some major changes
>     to the creation of OSX application bundles in the build process.
>     >>>>     The most obvious is that now only one application bundle is
>     created which starts the kicad launcher.
>     >>>>     From there you can go anywhere else.
>     >>>>     The created bundle now is (should be) completely
>     relocatable, so you can just put it anywhere you want as with other
>     OSX apps.
>     >>>>     All the pre-delivered templates, etc. have been moved into
>     the bundle and should be found from there.
>     >>>>     Command-Line tools are still contained (and accessible via
>     e.g. /Applications/kicad.app/Contents/MacOS/idf…).
>     >>>>
>     >>>>     I have uploaded a sample dmg image here:
>     >>>>       http://ul.to/ypsk7m41
>     >>>>     What you see in the dmg is 1:1 what is created in the build
>     process now… this should make packaging and distributing automated
>     builds very easy in future.
>     >>>>
>     >>>>     I am still doing some final touches to the patch before it
>     gets submitted.
>     >>>>     So, feel free to test and comment…
>     >>>>
>     >>>>
>     >>>>     Regards,
>     >>>>     Bernhard
>     >>>
>     >>>     _______________________________________________
>     >>>     Mailing list: https://launchpad.net/~kicad-developers
>     >>>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto: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
>     <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
>