Re: [Kicad-developers] Paths on the Windows 4.0.0 RC1

[Wayne Stambaugh]

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"  > 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
> > >
> 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
> >> > wrote:
> >>>
> >>>
> >>> On Fri, Sep 18, 2015 at 8:20 AM, Brian Sidebotham
> >>> >
> 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 

Re: [Kicad-developers] Paths on the Windows 4.0.0 RC1

[Jason Whiteman]

I had written up a bug tracker item for paths on the 9/17 and the machine
hard-locked before sending it.   Looks like Win paths were in the sights
for everyone.   The issues are well known and my writeup was about the
problems associated with 3d models but also pointed out templates and other
default paths do not point to their installed locations in the Kicad
install ("root") directory which, for me, is C:\Program Files (86)\Kicad\
for the install root (may vary according to install options or Win OS
version).   Most of the default directories live here under \share\kicad (where template, modules\packages3d, etc. live).

The suggestion was (on a "clean install") either to change the default envs
to match the install paths for these items or change the install paths to
match what the env variables point to (this doesn't make a lot of sense due
to the sprawl of directories - but at least would provide a functional
system).

For an upgrade, existing directories should be preserved as to not mess up
someone who's either chosen to create the previous default paths and placed
files there or changed the directories to be something custom.  Should
leave that alone.   But on a fresh install, directories need to sync up
with install paths.

My last comment in the bugreport (not sent due to crash) - was that perhaps
all the mechanism exists in Kicad to set this correctly and it's "simply"
an issue with those who generate the binaries/installer packages.   If so,
the burden of supporting the intended method may be too high as installers
from official distribution servers have not been correctly setting the
environmental variables.   Suggestion would be to fix this upstream (Kicad
source/makefiles/etc) to assume correct paths without need for override.

This is slim on any new content - the executive summary is "I concur".


On Thu, Sep 17, 2015 at 6:40 PM, Cirilo Bernardo 
wrote:

>
>
> On Fri, Sep 18, 2015 at 8:20 AM, Brian Sidebotham <
> 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
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>

Re: [Kicad-developers] Paths on the Windows 4.0.0 RC1

[Brian Sidebotham]

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
 wrote:
>
>
> On Fri, Sep 18, 2015 at 8:20 AM, Brian Sidebotham
>  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
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Paths on the Windows 4.0.0 RC1

[Brian Sidebotham]

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"  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
> >  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
> >>  wrote:
> >>>
> >>>
> >>> On Fri, Sep 18, 2015 at 8:20 AM, Brian Sidebotham
> >>>  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 

Re: [Kicad-developers] Paths on the Windows 4.0.0 RC1

[Mark Roszko]

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.

On Fri, Sep 18, 2015 at 6:03 AM, Brian Sidebotham
 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
>  wrote:
>>
>>
>> On Fri, Sep 18, 2015 at 8:20 AM, Brian Sidebotham
>>  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 : 

Re: [Kicad-developers] Paths on the Windows 4.0.0 RC1

[Wayne Stambaugh]

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
>  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
>>  wrote:
>>>
>>>
>>> On Fri, Sep 18, 2015 at 8:20 AM, Brian Sidebotham
>>>  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

Re: [Kicad-developers] Paths on the Windows 4.0.0 RC1

[Cirilo Bernardo]

On Fri, Sep 18, 2015 at 8:20 AM, Brian Sidebotham <
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
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp