kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

On Fri, Sep 18, 2015 at 8:20 AM, Brian Sidebotham <
brian.sidebotham@xxxxxxxxx> wrote:

> As mentioned in the bug report here
> https://bugs.launchpad.net/kicad/4.0/+bug/1496049 there's a problem
> with paths on the Windows 4.0.0-RC1.
>
> So far the paths that don't work:
>
>     (1) Searching for help files fails
>     (2) Default paths in the "Path configuration" dialog all point to
> places in c:\msys64\mingw64, etc.
>     (3) Python footprint wizards don't load
>
> and probably more. Needless to say, the KiCad experience out of the
> box because of this is very poor.
>
> We need to fix up the path search which started with the help in the
> bug report. The current consensus is to have (yet another) env var
> called something like KIHELP which can default on Windows to the
> literal string "${KICAD}\share\doc\kicad\help" which alleviates the
> previous problem of trying to guess the install path at compile time
> which is clearly flawed.
>
>
There are problems for sure but I don't believe in adding yet another
env var if it can be helped, but this may be a complex enough issue that
an env var would be the best option for the release. On MSWin documents
and such should go into an appropriate one of MSWin's Known Folders -
the question then is can we access these folder names via some library
in MSys/MinGW?


My personal preference would have just to have checked
> "BINDIR\..\share\doc\kicad\help" where BINDIR is gathered from
> ::wxStandardPaths::Get().GetExecutablePath();
>
>
I have my doubts here; there are too many ways that GetExecutablePath()
can give you the wrong result - certainly on *NIX there is no guarantee
what result you will get (but on Linux there are tricks to get it right -
assuming wxWidgets has a good implementation), but I'm not so sure of
the behavior on MSWin. Short story: inspect the wx implementation
before believing the results.


> However, the decision appears to be to add another configurable path.
>
> While adding the new KIHELP env var solves part of the problem, the
> Windows installer should be updated to set the KICAD env var to the
> chosen install path while installing. et. voila, paths fixed.
>
> Best Regards,
>
> Brian.
>
>
 I think a well-known path is preferable to yet another configurable path;
this is true for all platforms. In my 3D refactoring branch there is some
code which attempts to find a plugins directory using a number of
known paths. I think for all items specifically associated with the
kicad install, known paths should be used. For other items like
3D models some user configuration should be supported (though
any 3D models installed by a kicad installer should be put into a
known path).

- Cirilo