kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Whoops, accidentally sent to only Bernhard.  Resending to list. (Btw
Bernhard, I added a line at the end...)

Hi Bernhard,

Thanks for the reply.  I'm definitely not going to stop the Jenkins
stuff--I just have no interest in maintaining a .pkg, because I think it is
a worse user experience.

When I think of packages, I think of things that can't clean up after
themselves, or crap released by companies that don't know what they're
doing Samsung printer drivers.  I definitely trust them much less than
something I install with a DMG.

I agree that not everyone agrees with me--but this is my reasoning for not
wanting to make a pkg.  I don't think users like them, and I definitely
don't like them, so I don't really want to spent hours a week making them
better. :)

I made a bunch of pkgs when I was a full time Linux/Mac sysadmin--you're
right, they're no harder to create.

Right now the KiCad DMG is 30 megs.  I'm willing to concede and include all
of the help files inside, but please note that over 75% of the package size
will be help files.  It certainly does matter on the Jenkins server, but I
can throw money at that problem.

So, here's my proposal.  I include all the help inside the bundle, tripling
the size of the packages.

I set up a DMG with two drag targets.  The first is Kicad/ which contains
Kicad.app and the rest of the .apps, and the drag target is /Applications.
The second is kicad/ and the drag target is ~/Library/Application
Support/.  Inside of kicad/ is libraries, templates, and some config files
(I think).  If the second target doesn't work, we may have to have three
directories that you drag to ~/Library/Application Support/kicad/.  I think
we can make that clear with a background image on the dmg.

How does that sound?

Adam Wolf

Cofounder and Engineer,

W&L

On Tue, Nov 18, 2014 at 1:12 PM, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>
wrote:

> Hi Bernhard,
>
> Thanks for the reply.  I'm definitely not going to stop the Jenkins
> stuff--I just have no interest in maintaining a .pkg, because I think it is
> a worse user experience.
>
> When I think of packages, I think of things that can't clean up after
> themselves, or crap released by companies that don't know what they're
> doing Samsung printer drivers.  I definitely trust them much less than
> something I install with a DMG.
>
> I agree that not everyone agrees with me--but this is my reasoning for not
> wanting to make a pkg.  I don't think users like them, and I definitely
> don't like them, so I don't really want to spent hours a week making them
> better. :)
>
> I made a bunch of pkgs when I was a full time Linux/Mac sysadmin--you're
> right, they're no harder to create.
>
> Right now the KiCad DMG is 30 megs.  I'm willing to concede and include
> all of the help files inside, but please note that over 75% of the package
> size will be help files.  It certainly does matter on the Jenkins server,
> but I can throw money at that problem.
>
> So, here's my proposal.  I include all the help inside the bundle,
> tripling the size of the packages.
>
> I set up a DMG with two drag targets.  The first is Kicad/ which contains
> Kicad.app and the rest of the .apps, and the drag target is /Applications.
> The second is kicad/ and the drag target is ~/Library/Application
> Support/.  Inside of kicad/ is libraries, templates, and some config files
> (I think).
>
> How does that sound?
>
> Adam Wolf
>
> On Tue, Nov 18, 2014, 12:45 PM Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>
> wrote:
>
>> Oh boy, much to read… :)
>> Be prepared, this will be a long reply.
>>
>> First, come on, Adam. You did an awesome job setting up the Jenkins and
>> being willing to provide automated builds. Please don’t throw that away.
>> It’s just a technical discussion…
>>
>> === Is OSX so different than Linux? ===
>> No, it isn’t. On Linux you have:
>>   (1) Binary folder => /usr/bin
>>   (2) Machine data (for all users) => /usr/share
>>   (3) User data => /home/<user>
>>   (4) User specific configs => /home/<user>/.config/...
>> On OSX you have the same with different names:
>>   (1) /Applications
>>   (2) /Library/Application Support
>>   (3) /Users/<user>
>>   (4) /Users/<user>/Library/Application Support/…
>> The only difference is that for (1) in Linux all the app mess is in one
>> folder, whereas in OSX you have much cleaner for each application its own
>> folder and OSX hides everything below it.
>> For Linux, the rules where to put what are made by Debian et.al. and I
>> guess no one would be happy if you create a /usr/help folder for KiCad help
>> files. In Linux things would go to (2), just probably like thy could on
>> OSX.
>> In OSX you additionally can hide mandatory things a user shouldn’t fiddle
>> around with by putting it into the bundle in (1).
>> For me, help files are such things… I don’t see any benefit of having
>> them separate.
>>
>> === Where should go what? ===
>> I think that is easy:
>> (a) Everything that mandatory ships with KiCad and is not intended to be
>> changed by users => (1)
>> (b) Everything else common for all users of the machine => (2)
>> (c) User specific stuff => (3)/(4)
>> That’s exactly how search paths are configured at the moment (at least
>> everything that I found and changed and still exists - as I learned pcbnew
>> doesn’t use search paths at all), just the other way round (c) => (b) =>
>> (a).
>> Normally, in a multi-user environment (a)/(b) will only be writeable by
>> administrators…
>> About libraries you could start another discussion… is this user or
>> machine data?
>> Well, in a company maybe it’s machine data which users can use but
>> mustn’t change… you will however find as many reasons that it is user
>> specific data.
>>
>> === Why I don’t like the help folder parallel to KiCad applications? ===
>> Well, it’s ugly and it imposes a installation structure that I must not
>> break.
>> Think of that:
>> You create a start menu folder “KiCad" in Windows with all the nice icons
>> for the binaries in it and the help folder directly in there (no link or
>> something linke that, but physically located in the start menu folder).
>> I am a naive user and I …
>> * hate this, because the folder is ugly, I want to have a clean start
>> menu, and I delete it ...
>> * drag the KiCad icon to the desktop because I use it every minute…
>> => help doesn’t work any longer… uh, what bad thing did I do? Where is
>> the support forum?
>> Or:
>> Look at your iOS or Android tablet.
>> You see many nice icons for apps in there… I don’t want to see folders
>> for program data in there.
>>
>> === Do we need an installer? ===
>> If you want ultimate flexibility and best user experience, yes.
>> In Linux its nice that almost every distribution has its installer (=
>> package manager), so there is fortunately nothing to do on KiCad side.
>> For OSX as well as Windows this is not true.
>> If you want maximum flexibility you would have to create the usual
>> installer with some nice check-boxes for maybe each language, libraries,
>> 3d-models, templates, etc. and the installer would take care of putting
>> everything into the right spot.
>> Do we need it now? I guess no.
>> First, help is IMHO mandatory for a professional package.
>> I just checked and all pdf’s together are ~10MB. 10 languages? Overall
>> 100MB.
>> I don’t care… do you?
>> If you want to “simulate” an installer by drag&drop from a dmg, then
>> probably yes, you would have to provide one drag&drop path for every
>> option. And I fully agree with you… too many drag&drop paths will confuse
>> more than it helps.
>>
>> === So, my proposal for now ===
>> Keep things simple and be happy with the first automated and official OSX
>> binaries.
>> Put all existing help files into the bundle, so normal OSX user can’t
>> break anything doing whatever is allowed on OSX with the main kicad.app
>> bundle (move around, copy, etc.).
>> Create a dmg with two drag&drop options… one for application, one for
>> libraries.
>>
>> If things really start getting too big, someone may start thinking of how
>> to create an installer.
>> I quickly googled a bit and creating an installer with pkgutil doesn’t
>> seem to be so hard, all the tools needed seem to be provided by Apple. I
>> guess it will be about the same effort than correctly packaging KiCad for
>> Debian or any other Linux distribution...
>>
>>
>> Regards,
>> Bernhard
>>
>>
>> On 18.11.2014, at 17:44, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> Can we do everything that a normal user needs in two locations, or do we
>> need three?
>>
>> For instance, the applications end up in /Applications or
>> /Applications/kicad.  The help files and libraries and modules and
>> templates and KiCad config files end up in *a* Library/Application\
>> Support/kicad.  Should they, by default, for normal users, go to /Library,
>> or ~/Library?
>>
>> If they all go into one location, I should be able to create a single
>> kicad directory with all of those support files that people drag into a
>> symlink to the appropriate Application Support.  Does this create merging
>> difficulties?  Do we need to have a help and library and module and
>> template directory that people drag into the symlink one-by-one?  Do we
>> need to have people drag help and library and module and template into
>> /Library/Application Support/kicad, and configs into ~/Library/Application\
>> Support/kicad?
>>
>> I personally think that dragging two things in a dmg is about the limit
>> before the dmg gets silly.
>>
>> Bernhard?  Garth?
>>
>> Adam Wolf
>>
>> On Tue, Nov 18, 2014 at 10:32 AM, Adam Wolf <
>> adamwolf@xxxxxxxxxxxxxxxxxxxx> wrote:
>>
>>> Garth,
>>>
>>> Sure.  I still don't like it, but I don't have any more time to discuss
>>> this.
>>>
>>> If this ends up mutating into a package installer, I will step back and
>>> let someone else handle Mac builds.  I have absolutely no interest in that.
>>>
>>> The help path doesn't look at /Library/Application Support.
>>>
>>> Adam Wolf
>>> Cofounder and Engineer
>>> W&L
>>>
>>> On Tue, Nov 18, 2014 at 10:19 AM, Garth Corral <gcorral@xxxxxxxxx>
>>> wrote:
>>>
>>>> Comments inline
>>>>
>>>> > On Nov 18, 2014, at 5:15 AM, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>
>>>> wrote:
>>>> >
>>>> > Well, folks, I guess I can put them inside of kicad.app, but I'm not
>>>> really sold on it.
>>>> >
>>>> > 0) To reiterate, I'm suggesting including the help in the dmg, but
>>>> not inside the kicad.app.  The installation process would remain like it is
>>>> today.
>>>> >
>>>> > 1) You already cannot move kicad.app around without moving
>>>> bitmap2component.app, cvpcb.app, eeschema.app, gerbview.app,
>>>> pcb_calculator.app, pcbnew.app, and pl_editor.app or they stop working, so
>>>> I do not think that "you can't just move kicad.app anymore" is valid.
>>>> Also, help doesn't work today, and I didn't even see a bug filed for that,
>>>> so it might be important to distinguish "the help shortcut in the menu bar
>>>> wouldn't work" with "kicad doesn't work."
>>>> >
>>>> Those things at the same level as kicad.app are (or at least should be)
>>>> symlinks.  They’re meant as a convenience for folks that want to run them
>>>> without launching kicad.app, but they’re not needed. The actual application
>>>> bundles are inside the kicad.app bundle.  If you move kicad.app yes, those
>>>> symlinks stop pointing to the right thing but kicad.app and all associated
>>>> sub-applications will continue to work just fine.  You’d just have to
>>>> create new symlinks (or aliases which don’t care if the main bundle is
>>>> moved).
>>>>
>>>> Bernhard and I discussed some various alternatives to symlinks, but
>>>> ultimately symlinks were the simplest.  I was in favor of not including
>>>> them at all as they just add confusion, but others rightly pointed out that
>>>> there are those who still prefer to invoke them separately.  For those that
>>>> don’t, though, simply dragging kicad.app into /Applications (without the
>>>> sub-application symlinks) works just fine.
>>>>
>>>> > 2) I don't think it is uncommon to put help files outside of a
>>>> bundle--then users can delete it easily if they want.  I do not want to say
>>>> "If you want to save space, go inside the bundle and delete the PDFs."
>>>> >
>>>> It’s not uncommon to put things outside the bundle, but you’re
>>>> proposing making a relative path from inside the bundle to outside the
>>>> bundle, and thus imposing an installation structure on people.  It is far
>>>> less common to drag a directory full of support files into the
>>>> /Applications directory than to simply drag a bundle in there.  That’s what
>>>> most people expect, and that’s the intent; /Applications wasn’t meant as a
>>>> place for application support files, there’s already a place for that,
>>>> /Library/Application Support.  If you do wan’t them inside the bundle,
>>>> that’s accounted for in the SharedSupport directory as Bernhard suggested.
>>>>
>>>> https://developer.apple.com/library/ios/documentation/
>>>> CoreFoundation/Conceptual/CFBundles/AboutBundles/AboutBundles.html
>>>>
>>>>
>>>> > 3) While it might make sense to put one set of PDFs inside the
>>>> bundle, I want to have a supplementary dmg of "all the help files for all
>>>> the languages".  If I put the help outside of the bundle, I can expect a
>>>> typical Mac user to change the contents of the help/ directory next to
>>>> kicad.app, but I do not want to write instructions explaining how to put
>>>> the help files inside of the bundle.
>>>> >
>>>> As I said, if you’d prefer them not to be there then I suggest a
>>>> location that is already for this purpose, such as /Library/Application
>>>> Support/kicad.   Please don’t put them in the /Applications directory
>>>> outside the bundle.
>>>>
>>>>
>>>> > 4) This is a search path, not "the only place to put them".  I can
>>>> certainly add a search path inside the bundle and outside the bundle for
>>>> anyone else who wants to store their help inside the bundle, but at this
>>>> point, I think there's a lot of value to keeping help outside the bundle.
>>>> >
>>>> Don’t a lot of the other search paths already look in
>>>> /Library/Application Support?
>>>>
>>>>
>>>> > Adam Wolf
>>>> > Cofounder and Engineer
>>>> > W&L
>>>>
>>>>
>>>> Garth
>>>
>>>
>>>
>> _______________________________________________
>> 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
>>
>>