kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Hey Brian,

I went ahead an committed my patch to the product branch since you are
on holiday until the 28th.  I want to get an rc2 out soonish and I
didn't want to wait.  Hopefully this resolves the issue.  Enjoy your
holiday.

Cheers,

Wayne

On 9/18/2015 4:51 PM, Brian Sidebotham wrote:
> Hey Wayne,
> 
> Thanks for those. My timescales may not match when you want to achieve
> RC2. Basically I'm on holiday from tomorrow until the 28th so can't work
> on this until then. If RC2 is not planned until after that then I can
> work on this as soon as I get back.
> 
> If you need it done quicker, or are just itching to fix with other path
> fixes please do go ahead, otherwise I'll pick it up as soon as I'm back
> off hols...
> 
> Best Regards,
> 
> Brian.
> 
> On 18 Sep 2015 15:46, "Wayne Stambaugh" <stambaughw@xxxxxxxxx
> <mailto:stambaughw@xxxxxxxxx>> wrote:
> 
>     On 9/18/2015 7:59 AM, Mark Roszko wrote:
>     > Speaking of paths, there's invalid default paths(%PROGRAM
>     > FILES%/KiCad) being used for Save and Open dialogs thoroughout KiCad
>     > which need to be changed to the user's document folder. Wayne said he
>     > was working on it awhile ago but its something to fix.
> 
>     I'm still am working on it.  I hope to commit it tomorrow.  As soon as
>     Brian gets the help search path stuff fixed I'll roll out rc2 unless
>     some other major bug pops up.
> 
>     @Brian, attached are patches for search_stack.cpp and
>     searchhelpfilefullpath.cpp which should solve the help problem.
>     Actually, some of the changes should be moved into the system search
>     stack which should solve all of the search path issues not just the help
>     path.  Feel free to cherry pick these changes or ignore them.  One thing
>     that is broken in both cases is that the KICAD env var is not always the
>     first entry in the search stack when it's defined and it should be.
>     User defined paths should *always* take precedence.
> 
>     >
>     > On Fri, Sep 18, 2015 at 6:03 AM, Brian Sidebotham
>     > <brian.sidebotham@xxxxxxxxx <mailto:brian.sidebotham@xxxxxxxxx>>
>     wrote:
>     >> GetExecutablePath() has a fallback which is poor but not too
>     >> unreasonable:
>     https://github.com/wxWidgets/wxWidgets/blob/master/src/common/stdpbase.cpp#L67
>     >>
>     >> For Linux it grabs /proc/self/exe which seems reasonable(ish):
>     >>
>     https://github.com/wxWidgets/wxWidgets/blob/master/src/unix/stdpaths.cpp#L120
>     >>
>     >> For Windows it uses the Module path which is fine:
>     >>
>     https://github.com/wxWidgets/wxWidgets/blob/master/src/msw/stdpaths.cpp#L343
>     >>
>     https://github.com/wxWidgets/wxWidgets/blob/master/include/wx/msw/private.h#L894
>     >>
>     >> For OSX the code looks ok, though I can't test it at all:
>     >>
>     https://github.com/wxWidgets/wxWidgets/blob/master/src/osx/core/stdpaths_cf.cpp#L142
>     >>
>     >> The only problem I see if the BSD range of OS, which is basically
>     >> where /proc/self/exe is not available because that will fall back to
>     >> the base implementation. Although the base implementation is not too
>     >> bad either. We could do a pull request for wxWidgets to fix up
>     >> GetExecutablePath() for those by testing for /proc/curproc/exe and
>     >> /proc/curproc/file and using if one exists - that should cover
>     most of
>     >> the BSD range better.
>     >>
>     >> I think GetExecutablePath() is accurate enough for us to use without
>     >> problem. It's so common to tie installed files relative the
>     executable
>     >> path it's virtually standard for me. This means we can run sandboxed
>     >> versions, i.e. without having to have a global config file which is
>     >> awkward when you're trying to test different things at once.
>     Otherwise
>     >> a /etc/kicad.conf would be perfect, but has no equivalent on Windows.
>     >>
>     >> Best Regards,
>     >>
>     >> Brian.
>     >>
>     >> On 18 September 2015 at 00:40, Cirilo Bernardo
>     >> <cirilo.bernardo@xxxxxxxxx <mailto:cirilo.bernardo@xxxxxxxxx>> wrote:
>     >>>
>     >>>
>     >>> On Fri, Sep 18, 2015 at 8:20 AM, Brian Sidebotham
>     >>> <brian.sidebotham@xxxxxxxxx <mailto: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
>     >>
>     >> _______________________________________________
>     >> 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
>