kicad-developers team mailing list archive

[Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>]

Yes, I didn’t do anything about documentation yet.
It should be pretty easy to add if there is a way to copy/fetch/build it from CMake and put it to the bundle - just like the templates, etc.

Same for the libraries/footprints.
Speaking about releases, maybe there should be two in future (build option for CMake, sth. like OSX_BUNDLE_INCLUDE_LIBMOD3D)… one with libraries, one without. I have all my libs/footprints/3d-models in my own local repository. I don’t care about wasting some bits and having default things in the bundle (if it doesn’t get too big), but I guess I don’t want them to show up and mix with my stuff.

I will (hopefully) fix scripting stuff at the weekend, I already made some first steps for that.
Then, I found some ideas to try to place libraries in the right spot inside the bundle so that it will be more conform to Apple standards (as Garth noted previously - it will be only internal cosmetics, though).

I am open for above ideas then, if not anybody else already did it… I still have some other OSX things to provide (but need to be rebased first), e.g. I have some more eeschema redraw fixes that I think need to be included and I still have a patch open for more OSX-like X-Y touchpad scrolling (I couldn’t live without that one… :) ).


Regards,
Bernhard

On 02.10.2014, at 21:08, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:

> 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
>> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp