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" <stambau...@gmail.com > <mailto:stambau...@gmail.com>> 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.sidebot...@gmail.com <mailto:brian.sidebot...@gmail.com>> > 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.berna...@gmail.com <mailto:cirilo.berna...@gmail.com>> wrote: > >>> > >>> > >>> On Fri, Sep 18, 2015 at 8:20 AM, Brian Sidebotham > >>> <brian.sidebot...@gmail.com <mailto:brian.sidebot...@gmail.com>> > 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@lists.launchpad.net > <mailto:kicad-developers@lists.launchpad.net> > >> Unsubscribe : https://launchpad.net/~kicad-developers > >> More help : https://help.launchpad.net/ListHelp > > > > > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > <mailto:kicad-developers@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp