Re: [Kicad-developers] Paths on the Windows 4.0.0 RC1
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
On 9/17/2015 6:20 PM, 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.
Agreed. The current situation is unacceptable and will need to be
resolved before the stable release.
>
> 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.
>
> My personal preference would have just to have checked
> "BINDIR\..\share\doc\kicad\help" where BINDIR is gathered from
> ::wxStandardPaths::Get().GetExecutablePath();
I'm fine with this. It used to be that way at one point but I'm not
sure what happened.
>
> However, the decision appears to be to add another configurable path.
In the name of expediency, I recommend using the binary path fix above
if it resolves all of the issues.
>
> 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.
>
> ___
> 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
>
___
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
[Kicad-developers] Paths on the Windows 4.0.0 RC1
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.
My personal preference would have just to have checked
"BINDIR\..\share\doc\kicad\help" where BINDIR is gathered from
::wxStandardPaths::Get().GetExecutablePath();
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.
___
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] Making translation easier: Any non-developer non-geek friendly approach?
> once this is all up & running (we are almost done) we can start think on > how to integrate it in a web tool or other means to easy translation > tasks for non-devs. >The website is not translatable as of now, but hugo the tool we use to >generate the site has some features for translations, I have not >really investigated it, but I guess it we should be able to apply the po files concept to the website oo I don't think he was talking about the website. Its the tools suggested that are web apps so that people can freely contribute without having to install or download anything. Translating a website with po files is really incredibly bad idea. Its massive paragraphs, we edit one small word of a page in English and suddenly the entire page revert backs to English. The GUI translation stuff works because its all phrases and short strings that are independent. IF you want website translations, the proper procedure person has to create a copy of the page content rewritten from English. It may get out of sync with the english content then, but it prevents the clusterfuck of simple edits. I could go on and on about how its a bad idea. ___ 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
[Kicad-developers] GUI translations and the stable release
In response to a message written on 17.09.2015, 09:14, from Nick Østergaard: I guess we should motivate our most active translators to make sure the translations are complete for their language[…] My commit messages have not doubts about which revision are related, so for Polish translations I'm so sure very much. For stable release it will be useful to start new repository with *.po tree. -- Best Regards, LordBlick ___ 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] Making translation easier: Any non-developer non-geek friendly approach?
2015-09-17 8:54 GMT+02:00 Marco Ciampa : > On Thu, Sep 17, 2015 at 02:49:59AM +0200, timofonic timofonic wrote: >> Hello. >> >> Currently, there are some .po files and instructions to translate KiCad, >> among other things. While this can be easy to developers, I believe it can >> be very painful to non-developers. >> >> I want to help translating all of KiCad to Spanish, even the main website >> and translate news (blogs?). I'm unfortunately having some IRL issues that >> are still making me unable to start on it, but I'm sorting them. >> >> These days I did remember about the following software or SaaS could help a >> lot in crowdsourcing translation efforts though a web interface. >> snip >> I have no idea about what's the better tool, the feasibility of it and if >> it deserves the effort. I just want to send this message so contributors >> could debate about it. >> >> Kind regards! > > Well this is planned. These are the steps followed so far: > > 1. convert all docs in an easy to manage and versioning format > (odt->asciidoc): done > 2. add tools and files to make docs translatable (gettext & .po files): done > 3. adapt & integrate the build & packaging scripts to the KiCad system > (cmake): 99.9% done > > once this is all up & running (we are almost done) we can start think on > how to integrate it in a web tool or other means to easy translation > tasks for non-devs. The website is not translatable as of now, but hugo the tool we use to generate the site has some features for translations, I have not really investigated it, but I guess it we should be able to apply the po files concept to the website oo. It will of course require some effort, but that I would like to postprone untill after the release or anyone picks up the task. But for the docs, and GUI translations. I think you failed to find https://poedit.net/. But anyway, multiple translators will no call them selves software developers... I think we should start with trying to use transifex.com for the GUI translations at least, but we also have a task of getting that stuff out of the old kicad doc repo. I am trying to work on this. But I have created an org on https://www.transifex.com/kicad/. But it is not really used yet. Nick ___ 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
