Re: [Kicad-developers] Jenkins halted?
On Mon, Jun 02, 2014 at 11:04:21PM +1200, Blair Bonnett wrote: > For anybody wanting to use GitHub, I also have a mirror at > https://github.com/blairbonnett-mirrors/kicad which is updated every 10 > minutes. Henner Zeller used it to fork from for his contributions a couple > of months back so I assume it is usable :). Hello to all the list and many thanks for this mirror. What about to write about these mirrors somewhere? -- Marco Ciampa "L'utopia sta all'orizzonte. Mi avvicino di due passi, lei si allontana di due passi. Faccio dieci passi e l'orizzonte si allontana di dieci passi. Per quanto cammini, non la raggiungerò mai. A cosa serve l'utopia? A questo: serve a camminare." Eduardo Galeano ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] a way to handle translations
Hello, hope topic not too boring for you serious devs ... :-) I am a translator and started to look at kicad because of many untranslated strings in italian I saw in it. Looking at the translation strings (in it.po file) I have seen that many are missing. I mean that, for example, I see that "Open Text Editor" or "Open Project" is not translated and is not present in kicad-doc.bzr/internat/it/kicad.po. >From this fact a couple of questions: - how is handled the translation update process in kicad? - why not using po/POTFILES.in and leave the burden to intltool-update that is made for this? TIA -- Marco Ciampa ___ 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] a way to handle translations
On Fri, Jun 06, 2014 at 08:10:01AM +0200, jp charras wrote: > Le 06/06/2014 01:18, Marco Ciampa a écrit : > > Hello, hope topic not too boring for you serious devs ... :-) > > > > I am a translator and started to look at kicad because of many > > untranslated strings in italian I saw in it. Looking at the translation > > strings (in it.po file) I have seen that many are missing. > > I mean that, for example, I see that "Open Text Editor" or "Open Project" > > is not translated and is not present in kicad-doc.bzr/internat/it/kicad.po. > >>From this fact a couple of questions: > > - how is handled the translation update process in kicad? > > - why not using po/POTFILES.in and leave the burden to intltool-update that > >is made for this? > > > > TIA > > > > Thanks for you interest about Kicad. > > Kicad uses .mo and .po files and the tool to build and maintain > translation files is Poedit (multiplatform tool). > Poedit is designed to easily maintain translations in applications using > wxWidgets library (this is the case for Kicad). > the kicad.po file is the file used by Poedit to manage translations, and > the kicad.mo is the translation created by Poedit. > > Please, read the doc file GUI_Translation_HOWTO.pdf (in kicad sources), > which explains how to maintain translations. > > You need the latest Kicad sources to build/maintain translations, but > translation files are always fully outside sources. I've always used emacs's po-mode for traslations and I thought that poedit was only another poedit-or. Now I see (after trying it) that it is in fact much more than that: it handles po updates too so there is no need of a separated updating tool. I personally continue to use emacs for translations (habits are hard to change...) and use poedit just for updating strings catalog. A small note: IMHO the decision to keep documentation separated from program logic brings to some (small?) problems. Poedit have to have a sources catalog for translatable strings, as was with intltool-update, to know were actual program sources are kept in your local disk. It just keep it in the .po file headers. Now translations are kept separated from the program, in a different repository (why?), so software paths must be absolute. Of course every contributor works in a different way with a different OS etc. so this leads to that every contributor rewrites this path to second to his/her personal taylored system. If these docs (that are version dependent!) are kept into the main source tree, paths could be relative (but I do not know how poedit handles inter-platform dir-separator-char conversion, if any is in place...). Anyway I will always prefer and suggest to keep different functions separated (KISS) and have a (c)make driven translation catalog update. That would open the door to a procedure that can handle the automatic update of all language strings at every recompilation, via intltool-update or other tools, enabling an easier translation of all platform programs even by means of a web translation platform. PS: when I finished translating the strings, since doc source tree is not mirrored into git, how is the preferred/best way to post the finished .po file? May I post it as an attached file here in this list or it is better in another way? I would perfer to commit directly into the repo though I am not used to bazaar. If I can write to the repo directly I would update all languages catalogs and strings, though manually. This could be useful to check the translation progress for every foreign language after string freeze and before the commit of a new stable release. bye PS: forgive my bad English, my Italian is much better... ;-) -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] small error in text string, please fix
in kicad.bzr/pcbnew/class_pcb_layer_widget.cpp line 68: RR( _( "Pads Front" ), PAD_FR_VISIBLE, WHITE, _( "Show footprint pads on board's front" ) ), RR( _( "Pads Back" ), PAD_BK_VISIBLE, WHITE, _( "Show footprint pads on board's back" ) ), RR( _( "Text Front" ), MOD_TEXT_FR_VISIBLE,WHITE, _( "Show footprint text on board's back" ) ), RR( _( "Text Back" ), MOD_TEXT_BK_VISIBLE, WHITE, _( "Show footprint text on board's back" ) ), bye -- Marco Ciampa "L'utopia sta all'orizzonte. Mi avvicino di due passi, lei si allontana di due passi. Faccio dieci passi e l'orizzonte si allontana di dieci passi. Per quanto cammini, non la raggiungerò mai. A cosa serve l'utopia? A questo: serve a camminare." Eduardo Galeano ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] small error in text string, please fix
On Sat, Jun 07, 2014 at 01:15:45PM +0200, Nick Østergaard wrote: > 2014-06-07 11:54 GMT+02:00 Marco Ciampa : > > in > > > > kicad.bzr/pcbnew/class_pcb_layer_widget.cpp > > > > line 68: > > > > > > RR( _( "Pads Front" ), PAD_FR_VISIBLE, WHITE, _( > > "Show footprint pads on board's front" ) ), > > RR( _( "Pads Back" ), PAD_BK_VISIBLE, WHITE, _( > > "Show footprint pads on board's back" ) ), > > > > RR( _( "Text Front" ), MOD_TEXT_FR_VISIBLE,WHITE, _( > > "Show footprint text on board's back" ) ), > > > > > > RR( _( "Text Back" ), MOD_TEXT_BK_VISIBLE,WHITE, _( > > "Show footprint text on board's back" ) ), > > > > bye > > > It is easier to make a patch file with 'bzr diff > > correct-string.patch' or similar. I had a hard time noticing the > error, because the hats do not align up, because I did not view your > mail in a monospace font. Right, thanks! See patch attached... -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ === modified file 'pcbnew/class_pcb_layer_widget.cpp' --- pcbnew/class_pcb_layer_widget.cpp 2014-05-21 21:13:30 + +++ pcbnew/class_pcb_layer_widget.cpp 2014-06-07 12:33:34 + @@ -67,7 +67,7 @@ RR( _( "Pads Front" ), PAD_FR_VISIBLE, WHITE, _( "Show footprint pads on board's front" ) ), RR( _( "Pads Back" ), PAD_BK_VISIBLE, WHITE, _( "Show footprint pads on board's back" ) ), -RR( _( "Text Front" ), MOD_TEXT_FR_VISIBLE,WHITE, _( "Show footprint text on board's back" ) ), +RR( _( "Text Front" ), MOD_TEXT_FR_VISIBLE,WHITE, _( "Show footprint text on board's front" ) ), RR( _( "Text Back" ), MOD_TEXT_BK_VISIBLE,WHITE, _( "Show footprint text on board's back" ) ), RR( _( "Hidden Text" ), MOD_TEXT_INVISIBLE, WHITE, _( "Show footprint text marked as invisible" ) ), ___ 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] hide the cheese! ;-)
please fix: pcbnew/edit.cpp:1495 "rats nets" ... or hide the cheese! ;-) -- Marco Ciampa ___ 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] hide the cheese! ;-)
On Sun, Jun 15, 2014 at 06:55:47PM +0200, Lorenzo Marcantonio wrote: > On Sun, Jun 15, 2014 at 06:48:48PM +0200, Marco Ciampa wrote: > > please fix: pcbnew/edit.cpp:1495 "rats nets" ... > > or hide the cheese! > > > Rat nest *is* the proper term! Since the wires are tangled... > > Arguably the pluralization is wrong, it should be "rat nests", not "rats nest" that is what I meant .. but sometimes I am really silly and I found this stupid error funny... sorry for the noise! -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Linux target
On Sat, Jun 28, 2014 at 09:47:18AM -0400, Michael McCormack wrote: > This might be a bit off topic - I would like to know what distro and what > branch is used to Kicad development. > > Background - I use Linux only for development of embedded systems, and > would like to get relatively recent copies of Kicad, Spice, Code::Blocks, > OpenOCD, GDB, etc. But every off the shelf distro seems to only have two > year old releases of at least one of these packages and as a result, when I > try to install from source I run into innumerable library problems because > of the old libraries that are invariably required. I will say at the > moment, I'm not sure that Kicad is one of the packages I use that requires > cutting edge libraries; but, I am trying to get ready for the next rebuild > of my PC. > > I don't want to become a Linux systems guru, I want to remain an embedded > developer; so is there an off the shelf distro that is used for development > of Kicad? I agree 100% with you. Besides I think that using Linux should never a pain in the ass like being able to recompile kernel by yourself and so on. I am not a Linux expert and _love_ Ubuntu for being so easy (and hate it for Unity but that's another story...) my 0.1 euro cent Anyway I can only testify that using a decent Kicad is a matter of using the script that you find in the download section. The only problem I found was that for some reason (why? is it possible to have it fixed?) some obscure cmake options are disabled by default and you have to manually enable to have the module browser enabled. And no, specifying the option manually to the script does _not_ work. I have been helped by irc to find the way to circunvent this problem (thanks again) and now I update my kicad copy every now and then and it continue to work well. I also suggest _not_ to use the ppa since that code is experimental and never worked well. Another solution, that I must admit it worked, is using the Windows version with Wine, though the script version is much more updated. Hope it helps you. -- Marco Ciampa "L'utopia sta all'orizzonte. Mi avvicino di due passi, lei si allontana di due passi. Faccio dieci passi e l'orizzonte si allontana di dieci passi. Per quanto cammini, non la raggiungerò mai. A cosa serve l'utopia? A questo: serve a camminare." Eduardo Galeano ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Linux target
PS: I use Ubuntu 14.04 - 64 -- Marco Ciampa "L'utopia sta all'orizzonte. Mi avvicino di due passi, lei si allontana di due passi. Faccio dieci passi e l'orizzonte si allontana di dieci passi. Per quanto cammini, non la raggiungerò mai. A cosa serve l'utopia? A questo: serve a camminare." Eduardo Galeano ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Linux target
On Sat, Jun 28, 2014 at 05:04:30PM +0200, Nick Østergaard wrote: > What option are you talking about exactly? I may be wrong because it was a couple of months ago but off the top of my head it was this: OPTS="$OPTS -DBUILD_GITHUB_PLUGIN=ON" I do not know why but I found it disabled as this: #OPTS="$OPTS -DBUILD_GITHUB_PLUGIN=ON" and it seemed that once it was disabled during the first compilation re-enabling (decommenting in the script) it will not suffice if you try to update, because cmake "remembers" this option and you (I) was forced to tell cmake that it was indeed changed. I simpler method could be to remove entirely the kicad local repo copy (rm -F ~/kicad_sources) and re-run the script. -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Linux target
On Tue, Jul 01, 2014 at 08:29:07AM +0200, Lorenzo Marcantonio wrote: > On Mon, Jun 30, 2014 at 03:28:32PM -0700, Cirilo Bernardo wrote: > > Oh yes, the OMAP ones can be worse. A huge section of the chip errata > > have to do with USB issues, and I'm not happy with the length of > > TI's chip errata either. Some faults have persisted across 2 > > chip revisions. Sometimes I get the impression that TI has no interest in > > creating a working processor. > > OMAP == consumer, don't be so surprised... another TI errata which is > absurdly fun is for an NFC controller/transceiver (don't remember the > part number). It can be used with parallel, 3-wire SPI or 4-wire SPI. > Errata #1: 3-wire SPI doesn't work. Workaround: Use 4-wire SPI :D:D > > Not that other manufacturers are better; a dsPIC33 errata substantially > says: don't ever *hope* to get the part programmed over JTAG, we left > that part out (were they out of silicon area?!). And don't care to trap > DMA conflicts either since they trigger whenever they want (if they > trigger at all). > > Seems that the whole industry is plagued by too short development > cycles... That's astonishing! Thanks for sharing these info guys! Are there any article/blog/anything about this topic (issues, errata and reability in general in microcontroller/ARM world you know of? TIA -- Marco Ciampa "L'utopia sta all'orizzonte. Mi avvicino di due passi, lei si allontana di due passi. Faccio dieci passi e l'orizzonte si allontana di dieci passi. Per quanto cammini, non la raggiungerò mai. A cosa serve l'utopia? A questo: serve a camminare." Eduardo Galeano ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] git repository for eeschema lib files ?
Please note: I am not a dev, just my 2 euro cent thoughts... On Wed, Aug 27, 2014 at 12:11:07AM +0200, yann jautard wrote: > Hi > > Good to know. I think I will submit some parts in the next days. > > In fact I feel a little stupid now because I used the library > downloader script, but I never noticed there was a "library" folder > in the resulting files :P ... only used the footprints. > And so, I wonder why some library files are installed by the > kicad-build.sh script ? Because it is assumed that you are not always connected? > Shouldn't be more logical if that script > installed only the program itself ? Because people not always "on-line" would soffer from this design? bye -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Project proposal
On Mon, Sep 01, 2014 at 11:17:04AM +0200, Javier Serrano wrote: > On Sat, Aug 30, 2014 at 8:47 PM, Wayne Stambaugh > wrote: > > 3) Documentation > [snip] > > There has been a suggestion of moving our documentation to a text base > > layout format to make it more version control and translation friendly. > > I'm all for that. > > How is the current documentation effort being handled? Is there a > separate mailing list for it? If there is, I would like to be subscribed to it. > I don't recall seeing much documentation discussion here. > What do the main people involved think about changing > to a markup text-based format? First consensus, then we will find a way. I volunteer by now to the conversion effort. -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Project proposal
On Mon, Sep 01, 2014 at 09:54:21PM +0100, Brian Sidebotham wrote: [...] > Latex I'm sure is definitely > out - it's hard to see the content for the formatting, so it's not > easy to work with. Most of all, it is really hard to _automatically_ (I do not know of a tool that is able to do it) extract chapters to create .po file to help maintain automated internationalization of the documentation. > We want to create a situation where documentation > writers can use text diffs to update their language's documentation. _THIS_ is what I meant! Using one of these tools: * xml2po (to use with docbook-xml) * publican (better) - please - take a look at this wonderful tool https://fedorahosted.org/publican/ * ... there must be other tools out there ... (markdown + po4a?) > So something like restructured text may work well because it has some > image formatting capabilities. > > Plain HTML can actually do the job too, although most people use a > language that compiles to html to make the formatting even cleaner. > > Markdown has books written in it too. Well markdown is wonderful and so is docbook-xml (although slightly harder to write) and using tools like pandoc (http://johnmacfarlane.net/pandoc/), for example, it is easy to create automatically HTML, PDF, ODT, EPUB(!) or even DOC(X) (gosh!) files. This is all good to write single language (english) doc. For writing manageable internationalized docs we have create (or use a specialized tool in) an automated chain like this: 1) write template doc (english) in (for example) docbook-xml (use the xml editor that you wish: emacs, gedit, eclipse, vi 2) use a tool to check structure validity of the template source file (some editors like emacs and eclipse are able to check xml validity as you type...) command: make validate 3) automatically extract all chapters from the template xml source file(s) creating a/some .pot file(s) for every language (typically the list of languages are in the LINGUAS file) command: make pot command: make po-NN where NN is the language code 4) eventually update the existing .po file(s) with new strings, fuzzying changed strings, and obsolete old strings. This is done through standard gettext utility commands like msgmrg ... command: make status-NN 5) merge template file with .po files to create many nationalized xml files, one for language command: make xml-NN 6) create the output file as you like: command: make html-NN command: make pdf-NN command: make odt-NN -- The advantages are: 1) In this way, doc authors and doc translators are completely indipendent from each other. Doc authors can make changes in doc anytime and those changes propagate automatically to all the languages. 2) A really nice side effect is that if a chapter is missing or obsolete, doc default automatically to english, so the book is always complete, even if not completely translated. 3) To translate, translators do not have to know docbook-xml sintax since they work always with .po files using standard gettext tools like poedit 4) web translation platforms are possible / enabled (like launchpad web translation support) through standard .po files 5) using HTML as standard output format it is possible (in the future) to enable even context sensitive help like is already done in the GIMP PS: in the examples above, those are the actual commands used to build the GIMP multilanguage documentation. PPS: forgive my bad english. -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Project proposal
On Wed, Sep 03, 2014 at 10:28:09AM -0400, Wayne Stambaugh wrote: > Marco, > > Thank you for stepping up to help fix our documentation. It's obvious > from you detailed description that you have an excellent understanding > of the issues. I _have_ to be honest. I actually do not know the inner workings of all this chain. I am mainly a translator, not a programmer, but I am not completely unaware of programming though. I do not know at all Cmake and just basic commands (before using Kicad never had any occasion to use) bazaar and merely I know what is docbook-xml, just used it as a doc writer. Anyway, so many years are now that I have taken the burden to maintain the translation updated of some free software projects, that I think I know now very well (as a translator) what have to be done. So, even though I haven't build up this mechanism myself, I have used it so much that I can imagine how it should be working underneath and maybe (I hope) I should be able to build up one for kicad. This could be the bigger effort I ever done to some free software project and I am eager and, to be honest, a little afraid to do it at the same time. So this is not "do it for me" but instead, "yes, I will do it by myself ... with a little help from my friends" SO please, be patient with me because I am not young chronologically (I am 48) but in this case I feel like a young newbie (do not laugh at me, please) and I do not want to do it all by myself but I will be glad if someone would like join me in this effort. > Here are the steps I would like to see you take to move forward: > > 1) Choose a format that meets the documentation requirements and > satisfies the platform availability requirements that I've already > commented on. I'm comfortable with DocBook and mark down so I'll leave > the details up to you and the folks doing most of the documentation work. I would really like to discuss about this, the text source format to choose, with someone or just here in the list, if you do not mind I clutter the list with such mundane discussions. I would really like to have some other opinion because I am not really sure about it and I do want to avoid big mistakes especially at this early stage. In particular, I really like the semplicity and elegance of markdown but I do not know if the tools previously mentioned (maybe po4a? or something other?) are able or suitable to extract the text paragraphs and then re-merge translated. With docbook-xml format I am sure that with xml2po or publican I can do it. So for me, docbook-xml could be the first choice if it does not jump out any way to manage the extraction and reintegration of translated strings in markdown. > 2) Create you own branch of lp:~kicad-developers/kicad/doc, convert one > of the smaller user guides (cvpcb) to the new format (preferably in a > new folder), and update the CMake files to check if the required tools > are installed and the necessary make commands to build the html (at a > minimum) documentation. Once you have this working, push your branch to > launchpad so other developers can test your changes. Ok. > 3) Once other developers have had a chance to test your changes and we > have a consensus that this is the way to go, convert the remaining > documentation to the new format and commit the changes to > lp:~kicad-developers/kicad/doc. Ok. > 4) When all the documentation is converted to the new format, remove the > legacy odt files from the repo. Ok. > 5) Add the CMake code to build the translation po files and any > additional output formats we want to support. Since IMHO this is the most important feature and reason for the change of the whole doc project, I think it would be better if it was done (or just checked) before point 3) > There is a lot of work to be done to make this happen so let's support > Marco as best we can. I really count on this. Just it will not so quick, so do not hold your breath! ;-) Many thanks for the opportunity and for the trust you place in me, hope it is not misplaced. -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Fwd: Project proposal
On Tue, Sep 02, 2014 at 08:03:00PM -0400, Wayne Stambaugh wrote: > It would be nice if we could take advantage of CPack for this purpose. > It's one of those things I'ld like to take a look at if I had the time. > This would allow us to set up builders to create packages for all > platforms. Seems that proposals of exciting new features/enancement are flourishing all together kindled by the new management course! Every proposal seems sensible and interesting, please do not stop and continue this wonderful trend. I am afraid that something could be forget/missed buried in the mail thread. Why not summarize all these ideas into a wiki? Almost every project has a dev wiki just for these kind of problematics... BTW IMHO CPack is a great idea... -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Project proposal
On Sat, Aug 30, 2014 at 02:47:02PM -0400, Wayne Stambaugh wrote: > Since Javier sort of let the cat out of the bag, I thought now would be > a good time as my first official announcement as project leader to talk > about creating a stable release of KiCad. As you may have read in > Javier's post that this stable release would be a light weight release > in that there would not be bug fix back ports. mmm this I do not understand. Several other projects I know of have some kind of backporting of bugs discovered during development in the dev branch, at least the trivial ones. Git cherry pick command comes handy in this respect... by the way, why not instead having two different DCSes converge all to the actively developed (git)? bye -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Announcement - Decision needed
On Sat, Sep 20, 2014 at 02:39:50PM +0200, Kerusey Karyu wrote: > All the Polish help docs has been ported/converted to HTML format and > committed. Now you have to decide to keep, archive or remove their PDF > editions and ODF sources. Please, don't for now, be patient. I am tryng to convert all ODF docs in a more manageable format. The HTML format IMHO should be obtained by automatic compilation like other useful formats for the documentation. > By the way. My friend ask me: "Why don't you use a Compiled HTML Help > (CHM) system? I saw a Linux client for that..." You correctly said "compiled". If you "compile" something you must have somewhere some sort of "source". Using that source you can, easily and in a maintainabile manner, manage automatically the format conversion. Nowadays, documentation is rarely directly written in HTML. Usually docs are created automatically by conversion from another more standard and/or manageable format like SGML, XML-DOCBOOK, Markdown, Asciidoc, Rest or the like, and then converted automatically (and correctly) into HTML, odt, pdf, CHM, rtf, LaTex or even epub. And, as a "bonus track" you gain an easy manageable and maintainable method for handling multilanguage doc translations With such a method it is straitforward to obtain and update all translated docs that are changed in the source reference language and format and propagate such changes into all languages sources. > As a "bonus track" you can take a look at English KiCad Manager doc > using my style sheet. > https://github.com/keruseykaryu/kicad-kerusey-doc-html/tree/master/doc/help/en That could be reused, so it will not be a waste of time. Likewyse the translation sources, with a little bit of effort of cut & paste... but please wait because I do not want you to waste time into unneeded conversions. Many thanks! -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] building kicad with wxWidgets on Linux
On Mon, Sep 29, 2014 at 09:37:38PM -0500, inkblotter wrote: > I have very recently built a new 64-bit linux system, with a new GPU. > Of course, I wanted to build kicad on this new system. > I have installed cuda and built wxWidgets 3.0.1 and I really look > forward to to running the push-and-shove router. > > But I never make it past the wxWidgets test in cmake. > My system has wxWidget 2.8.12-9 installed and I get the complaint > that 3.0 is required. > I built wxWigets 3.01 and installed it in $(HOME)/wx and used the > flag -DwxWidgets_ROOT_DIR=$(HOME)/wx with cmake. I thought this > would work but it does not and fails on the same complaint about > finding 2.8 and requiring 3.0 (or better), but it also says that it > found my $(HOME)/wx wxWidgets. > > That is, it fails on the version complaint first and then finds the > wxWidgets 3.0.1 in $(HOME)/wx, or it seems to fail first and then > find newer wxWidgets but cmake fails overall. > > The system cmake version is 2.8.12.2. > g++ 4.8.3 > kernel 3.16.3 > > I am not very familiar with kicad cmake. Is there some trick > others have found to accomplish building with wxWidgets not in > either /usr/local nor installed in the system paths? Same problem here. I do not know CMake and being a little stupid I've erased my local copy of the repository. Dowloaded from scratch e recompiled. I do not know why but it worked. -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Need help finding a git mirror for kicad/doc
On Mon, Oct 06, 2014 at 12:13:30PM -0400, Wayne Stambaugh wrote: > On 10/5/2014 11:26 PM, Mitch Davis wrote: > > Hi, > > > > On Mon, Oct 6, 2014 at 1:46 PM, Blair Bonnett > > wrote: > >> On 6 October 2014 14:33, Mitch Davis wrote: > >>> > >>> Is there a git mirror for lp:~kicad-developers/kicad/doc? > >> > >> There is now: > >> > >> https://github.com/blairbonnett-mirrors/kicad-doc > > > > Thanks very much! > > > > I just did a git clone. Under 3 minutes. I think bzr would still be > > going... > > > >> NB it is big (~800 MB) as most of the files are stored in binary form. > >> There > >> has been talk about switching to a text-based documentation source. > >> Hopefully when this happens a new repository can be started (freezing the > >> old one to retain the history) so its much smaller to obtain. > > > > Sounds good. I've been following the debate. +1 for Sphinx and > > reStructuredText. > > Sphinx looks like a reasonable candidate. It satisfies the criteria of > being available on Linux, Windows, and OSX and there is even a link to > an odt to Sphinx converter. Sphinx looks one of the few complete documentation packages I have tried. I onestly I do not like rest and prefer asciidoc instead but I think that sphinx is a wonderful piece of code and I have seen that most of the people that use rest use it because of sphinx and not viceversa. Besides asciidoc is only slightly different and simpler than rest so it is not so crucial choosing rest instead of asciidoc or markdown. See: - http://blog.ser1.net/2011/06/restructuredtext-vs-asciidoc.html - http://asciidoctor.org/docs/what-is-asciidoc/ (<- this site is written in asciidoc!) > I did a quick scan of the documentation and it seems like it provides > all the features we would need to create high quality documentation. > I don't know anything about Sphinx but I do like the fact that is markdown > rather than docbook. Actually it is not markdown but rest (RE-Structured-texT) but it is just the same: a simpler and human readable format (like markdown or asciidoc) that could be converted into docbook easily and automatically. > I've never found XML to be very readable. I agree, not at all. You have to have the assistance of powerful editors like emacs or eclipse to be able to be a docbook prolific writer. > I'm depending on the experience of others to make this documentation > conversion happen so all other interested parties > please step forward with comments so that we can get this moving forward. I ask you all to please have the patience to wait just a little more. I have successfully and satisfactory converted the cvpcb manual either in asciidoc, markdown and rest and tested with various platforms (pandoc, asciidoc, asciidoctor, sphinx). BTW I haven't found an easy/satisfactory way to format the source file to obtain a pdf with the kicad logo image in the front cover ... if someone know how to do it I'm all ears... I just want to finish experimenting with what I care most: multilanguage support. I want to produce multilanguage versions of the manual creating various .po gettext files and re-merge those versions into many nationalized versions. I want to test it _before_ making the final decision about the tool to use. Do we have to choose this important tool quickly? I hope not... Thanks! -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Need help finding a git mirror for kicad/doc
On Tue, Oct 07, 2014 at 08:23:40AM -0400, Wayne Stambaugh wrote: > > Do we have to choose this important tool quickly? I hope not... > > No, we do not have to hurry. I prefer that we take our time and make a > choice that works the best for the project. I think you are going about > it the right way by testing the various alternatives. I just don't want > us holding off keeping the current documentation up to date waiting for > the decision on the new format. I guess that is not an issue as long as > there is a decent converter from odt to whatever format we choose. Yes, there is no need to stop documenting kicad for now. When all tools will be ready and in place I'll ask for a freeze period to convert the existent doc since all automatic tools that I have tested (included sphinx odt to rest converter) are buggy and output files have to be adjusted (wrong unrecognized headings, random spaces into text, image not recognized, etc). Thanks! -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] [PATCH] Rename instances of "module" to "footprint" for consistency
On Wed, Oct 08, 2014 at 11:38:34AM +0200, Benoît Roehr wrote: > Hello dear developers. > > Le 08/10/2014 10:08, Andrew Zonenberg a écrit : > >Second the vote for consistency, no matter which way it goes. > > > >Personally, I have a slight preference for "footprint" over "module" as > >well. > > > >On Wed, 2014-10-08 at 18:56 +1100, Mitch Davis wrote: > >>On Wed, Oct 8, 2014 at 5:47 PM, Mark Roszko wrote: > >>>Hehe, well, I guess everything can be renamed in the opposite > >>>direction. But consistency is needed. > >>YES PLEASE! A number of people I've spoken to were really confused by > >>this inconsistency. > >> > >>I use footprint myself. Though footprint seems to imply what a PCB > >>must have in order to accommodate a part, eg, pads, silk. Are the 3d > >>models part of this? If they are, then footprint might not be the > >>best term. > I agree with this. What you want to rename "Footprint" is more or > less a container unifying different PCB objects (pads, lines, 3d > model...), but may not be a footprint (logos, mounting holes, > screws...) > > Altium folks use the "Component" term both in Schematic libraries > and PCB libraries. You know what you are looking at knowing what > type of library is browsed. I don't remember for Proteus. These are my quick thoughts and I hope they make sense: 1) I personally have taken the freedom to translate footprint / footprint module / module in Italian as "modulo" for module. I think that the best name in English is module and all occurrences should be converted into module for consistency. 2) I think that it is better to have "component" for schema and "module" for pcb so there is no confusion when talking about component - module association. 3) I think that translations should be put inside of the main source tree. If someone wants to keep translations into a separate package it is simple to do it anyway. Take a look at other programs: documentation is usually kept separate but translations are always part of the program. Why do I think this is important? Because translators usually play a big part in clearing reference source strings from small errors, typos and inconsistency because they have to read all strings together and thus are in the best position to detect errors and typos. Those small errors usually are left unchanged because it seems always not worth the patch or the burden to disturb a dev to apply the fix. bye -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] [RFC] BOM Editor
On Tue, Feb 14, 2017 at 05:20:23PM +1100, Oliver Walters wrote: > So, thoughts? One from a non-dev: very nice, very good work! -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] Stable release 4.0.6
On Tue, Feb 14, 2017 at 09:26:21AM -0500, Wayne Stambaugh wrote: > Are there any outstanding issues to prevent rolling out a 4.0.6 stable > release? If not, I will set the version string and tag that commit as > 4.0.6. How much time do our source translators, doc devs, and library > devs need to have everything ready? For these minor stable releases, concerning the i18n stuff, I think that a couple of days will suffice... -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] [miguelan...@ajo.es: Build failed in Jenkins: any-kicad-doc-stable #57]
ed build as failure [WARNINGS] Skipping publisher since build result is FAILURE Archiving artifacts - End forwarded message - -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] [miguelan...@ajo.es: Build failed in Jenkins: any-kicad-doc-stable #57]
On Thu, Feb 16, 2017 at 02:31:58PM +0100, Nick Østergaard wrote: > It looks like it can not find the lang-id.conf file. Maybe that is > present in a newer asciidoc, but to not break the build for others, > can't we just commit this in your repo as we have for some other > languages? > > Can you do that Marco? I already asked the Indonesian guy to try and contribute directly to asciidoc a few days ago... > > Scanning dependencies of target getting_started_in_kicad_html_id > > asciidoc: WARNING: getting_started_in_kicad.adoc: line 7: missing language > > conf file: lang-id.conf > > asciidoc: WARNING: getting_started_in_kicad.adoc: line 7: missing section: > > [footer-text] These are just warnings. The error is below... > > Built target getting_started_in_kicad_html_id > > Scanning dependencies of target getting_started_in_kicad_pdf_id > > a2x: ERROR: "dblatex" -t pdf -p > > "/etc/asciidoc/dblatex/asciidoc-dblatex.xsl" -s > > "/etc/asciidoc/dblatex/asciidoc-dblatex.sty" -P latex.output.revhistory=0 > > -P doc.publisher.show=0 -s > > <http://ci.kicad-pcb.org/job/any-kicad-doc-stable/ws/CMakeSupport/pdf-cover-dblatex.sty> > > -b xetex -p > > <http://ci.kicad-pcb.org/job/any-kicad-doc-stable/ws/src/getting_started_in_kicad/../../xsl/dblatex-pdf-ru.xsl> > > -o > > <http://ci.kicad-pcb.org/job/any-kicad-doc-stable/ws/build-cmake/src/getting_started_in_kicad/id/getting_started_in_kicad.pdf> > > > > "<http://ci.kicad-pcb.org/job/any-kicad-doc-stable/ws/build-cmake/src/getting_started_in_kicad/id/getting_started_in_kicad.xml";> > > returned non-zero exit status 1 My local build compiles just fine so probably it is missing some (fonts?) for the indonesian language in latex. Did you install latex-cjk-all and texlive-lang-all ? > > src/getting_started_in_kicad/CMakeFiles/getting_started_in_kicad_pdf_id.dir/build.make:49: > > recipe for target > > 'src/getting_started_in_kicad/CMakeFiles/getting_started_in_kicad_pdf_id' > > failed > > make[2]: *** > > [src/getting_started_in_kicad/CMakeFiles/getting_started_in_kicad_pdf_id] > > Error 1 > > CMakeFiles/Makefile2:9939: recipe for target > > 'src/getting_started_in_kicad/CMakeFiles/getting_started_in_kicad_pdf_id.dir/all' > > failed > > make[1]: *** > > [src/getting_started_in_kicad/CMakeFiles/getting_started_in_kicad_pdf_id.dir/all] > > Error 2 > > Makefile:127: recipe for target 'all' failed > > make: *** [all] Error 2 > > Build step 'Execute shell' marked build as failure > > [WARNINGS] Skipping publisher since build result is FAILURE > > Archiving artifacts -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] Torrents for KiCad distribution
On Thu, Feb 23, 2017 at 11:50:59AM -0500, Mark Roszko wrote: > > I have no issue with that but there is no way for KiCad to control > > what is uploaded to a torrent so I really don't want the project to be > > responsible for it > > The torrent could be autogenerated by the download server when the > files are transferred over, the download server would act as the > initial seed server. The torrent once created could be shared on the > website and then thats it. The contents of the torrent cannot change > without it being a completely different hash and thus invalid for the > torrent. Agree. Actually using torrent is _more_ secure than downloading via ftp or http. Said with different words, having "official" torrents is just like having a download with md5 integrated that assure the validity of what you download. I usually use official torrents download for: * Libreoffice * GIMP * Ubuntu Linux ... > > >Does our website not have enough bandwidth for downloading KiCad packages? > > Actually simultaneous downloads from multiple users do seem to slow it > down quite a tad bit. It's not like the files are hosted on a CDN like > other projects may have or even github. > > The theory with torrents is the download server would consume the > same bandwidth during initial seed but then others could then "donate" > their bandwidth afterwards to continue sharing (the initial seed is > still there too). > Torrents is like having a auto download balancer that uses the bandwidth of other clients instead of saturating the servers download bandwidth. > Not advocating for this but just throwing my two cents in Well, if you ask me, in my humble opinion (not having set any any torrent seed in my life) setting up torrent seeds for main kicad downloads could be a worthwhile job. -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] Torrents for KiCad distribution
On Fri, Feb 24, 2017 at 08:01:38AM +0100, Nick Østergaard wrote: > 2017-02-24 7:59 GMT+01:00 Marco Ciampa : > > On Thu, Feb 23, 2017 at 11:50:59AM -0500, Mark Roszko wrote: > > > >> > I have no issue with that but there is no way for KiCad to control > >> > what is uploaded to a torrent so I really don't want the project to be > >> > responsible for it > >> > >> The torrent could be autogenerated by the download server when the > >> files are transferred over, the download server would act as the > >> initial seed server. The torrent once created could be shared on the > >> website and then thats it. The contents of the torrent cannot change > >> without it being a completely different hash and thus invalid for the > >> torrent. > > > > Agree. > > Actually using torrent is _more_ secure than downloading via ftp or http. > > > > Given that you got the correct torrent or magnet link in the first place. Yes, this is why official torrents seeds from an https site is important... -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] UI improvements
On Thu, Mar 23, 2017 at 01:41:05PM +1100, Oliver Walters wrote: > No matter what they are called, it should be *one* thing. Currently there > seems to be a few options. > > Schematic items - symbol / chip / component > PCB item - footprint / module / package > >From the documentation point of view, the coherence is key to improve readibility. Why should we call the same things with three di different names? Please settle for a pair of keywords and stick with those at least in the gui. OR We should insert a little terminology somewhere in the docs to clarify the use and meaning of those terms. IMHO of course, Regards, -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] [PATCH] better UI experience (properties window)
On Tue, Mar 28, 2017 at 10:06:42AM +0200, Fabrizio Tappero wrote: > In my opinion, I think "(degrees)" should not be plural and should not > between brackets but if you like it this way so be it. Wikipedia uses degrees: https://en.wikipedia.org/wiki/Gradian#Conversion hope it helps -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] [RFC] Application naming
On Thu, Feb 02, 2017 at 05:59:00PM -0500, Chris Pavlina wrote: > On Thu, Feb 02, 2017 at 11:54:09PM +0100, Kristoffer Ödmark wrote: > > Why dont keep it dead simple, but still keeping the KiCAD brand? > > > > I suggest prefix every subprogram with kicad- and then use a either > > extremely well known abbreviation (PCB) or a descriptive english word. > > > > Examples: > > > > eeschema-> kicad-schematics > > pcbnew -> kicad-layouts > > 3d-viewer -> kicad-3d > > gerb-viewer -> kicad-gerbers > > whatever-> kicad-whatever > > > > > > Self explaining names that are easy to use standalone as well as names that > > will not make a new users scoff and works well as binary filenames. > > Yes, I like this. I was talking about the names in the UI, mostly - this > is a good companion to that. > > > > > I really dislike having entirely different names for the binary and the > > shortcut-key/desktop-shortcut like ubuntu and their decision to have > > "Document Viewer" as the name for evince etc. > > Agreed. > Sorry for being so late... For what is worth my opinion, I strongly agree to both. BTW: apart from screenshots texts, search & replace can do miracles on all documentation in every language... -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] please make ruler tool translatable
Please apply this trivial patch:
diff --git a/pcbnew/onleftclick.cpp b/pcbnew/onleftclick.cpp
index 38b9ef0..2707fe1 100644
--- a/pcbnew/onleftclick.cpp
+++ b/pcbnew/onleftclick.cpp
@@ -440,7 +440,7 @@ void PCB_EDIT_FRAME::OnLeftClick( wxDC* aDC, const wxPoint&
aPosition )
break;
case ID_PCB_MEASUREMENT_TOOL:
-DisplayError( this, wxT( "This tool is not available in the legacy
canvas" ) );
+DisplayError( this, _( "This tool is not available in the legacy
canvas" ) );
SetToolID( ID_NO_TOOL_SELECTED, m_canvas->GetDefaultCursor(),
wxEmptyString );
break;
TIA
--
Marco Ciampa
I know a joke about UDP, but you might not get it.
GNU/Linux User #78271
FSFE fellow #364
___
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] [FEATURE] Partial selection in pcbnew
On Thu, May 04, 2017 at 02:36:06PM +0200, Kristoffer Ödmark wrote: > Personally I would like the box select to update selections online while > dragging, this would be very informative. I also think that maybe this > functionality would be better with a modifier button now that I think about > it, since sometimes I cannot starta a drag move in one corner due to a large > footprint residing there and then getting selected. +1 I like the GIMP way: - CTRL+drag means substract objects from the selecion and appears little minus symbol near the pointer to feedback this - SHIFT+drag means add objects to the selection and appears little plus symbol near the pointer to feedback this > But the hidden features problem is one that is starting to affect more and > more of pcbnew since functionality is added continuosly. agree > I know there is a manual for pcbnew, maybe tools should have some shortcut > to go to the relevant section of that manual? Or the tools have a shortcut > to go a "tool manual" I have no clue on how to achieve this, but It would be > nice. again this would be very handy as it is already present for instance in GIMP. We should figure out how to obtain this, at least for HTML... I have some ideas about how it can be obtained but I have to check for those feasibility... Regards, -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] Component table improvements
On Fri, May 12, 2017 at 10:25:49AM +0200, Kristoffer Ödmark wrote: > Just to generate a .csv or a rahter a .tsv as the default. May I suggest a .?sv where the ? character is a "user defined character" that defaults to ... comma (or tab or what you want) Separated Values list? TIA -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] Untranslatable strings
On Mon, Jun 05, 2017 at 12:38:45PM -0400, Wayne Stambaugh wrote: > Would one of our internationalization experts take a look at this > please? It seems odd to me the the ellipses would prevent the strings > from be translatable. Interesting... I wonder why we should use an UTF-8 char instead four simple full-stops... anyway for a quick and dirty solution why not use three dots instead? Regards, -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] menu icons
I work under Linux. I do not see any menu icon, either with the git compiled version or the snpy one. Is this normal? TIA Regards, -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] menu icons
On Mon, Jun 05, 2017 at 05:37:32PM -0500, José Ignacio wrote:
> Menu icons are disabled by default in gnome 3 in an effort to make it look
> more like an Apple product. You can enable them (on gtk 3.10+) with:
>
> gsettings set org.gnome.settings-daemon.plugins.xsettings overrides
> "{'Gtk/ButtonImages': <1>, 'Gtk/MenuImages': <1>}"
So the
Preference->Icon options->Icons in menu
is there for what?
TIA
Regards,
--
Marco Ciampa
I know a joke about UDP, but you might not get it.
GNU/Linux User #78271
FSFE fellow #364
___
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] menu icons
On Tue, Jun 06, 2017 at 09:46:42AM -0400, Wayne Stambaugh wrote:
> On 6/6/2017 3:14 AM, Marco Ciampa wrote:
> > On Mon, Jun 05, 2017 at 05:37:32PM -0500, José Ignacio wrote:
> >> Menu icons are disabled by default in gnome 3 in an effort to make it look
> >> more like an Apple product. You can enable them (on gtk 3.10+) with:
> >>
> >> gsettings set org.gnome.settings-daemon.plugins.xsettings overrides
> >> "{'Gtk/ButtonImages': <1>, 'Gtk/MenuImages': <1>}"
> >
> > So the
> >
> > Preference->Icon options->Icons in menu
> >
> > is there for what?
>
> This controls the menu icon visibility at the application level.
Yes sorry, I was too precipitous as always... it works...
> The solution above applies to all applications build with gtk.
> I don't understand why the gnome project made it so difficult
> to enable them.
> This seems like a perfectly valid user preference.
Yes and the whole "registry" concept copied from the Windows world that
seems to me awkward at best...
As always, thanks for your patience,
Regards,
--
Marco Ciampa
I know a joke about UDP, but you might not get it.
GNU/Linux User #78271
FSFE fellow #364
___
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] [PATCH] Reunion of zoom toolbar buttons
On Tue, Jun 06, 2017 at 04:07:09PM +0200, Fabrizio Tappero wrote: > Hi Wayne, > there are some little tiny quirks like this in kicad. It is just > matter of time and we will fix them all ! Perhaps also the two very similar hirarchy buttons could be grouped together on the main bar? TIA -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] Proposal to change "Copy" to "Duplicate"
On Thu, Jun 15, 2017 at 10:17:54AM +0200, Fabrizio Tappero wrote: > hello, > inside the schematic editor, this is the right click menu when a group of > component is selected > > [image: Inline image 1] > I would like to propose to rename the "Copy Block" into "Duplicate Block" > and add to it the shortcut D. Possible? does it make sense? the shortcut D > seems available but better ask first? > > Also, again in the schematic editor, this is the right click menu when > hovering on one component. > > [image: Inline image 2] > > here again I'd like to propose to rename "Copy" with "Duplicate" and change > its shortcut to D. > > As many, I constantly use these right click menus and I am trying to make > them better. +1 for Duplicate copy is a more common term for copy+paste clipboard function nowadays... -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] some menu icons are always displayed
Hi devs, just a small heads-up for a very uninportant thing. Under Linux, when you manage to enable icons menu in the gtk/gnome settings, some menu icons are always displayed even if the "show menu icons" option is unselected. TIA -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] how to know that which string item have been removed in po file
On Tue, Jun 20, 2017 at 10:08:42AM +0800, liyoubdu wrote: > i am doing some translation. i notice that some strings in kicad.po are > redundant since they have been removed from cpp code files. as a result, > the po file is bigger and bigger. why not reduce the file, and i want to > do that. but questions is in my mind. how can i know that which string > items have been removed. is there some good measure to reduce po file > automatically. Dear liyoubdu, the translation strings update & removal is handled automatically by the gettext suite commands. These commands are launched by poedit or by the source supplied script update-po-files.sh (for Linux). I can update your strings for you if you need so. Just tell me if you need it and I will update stable/master strings for you. Regards, -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] please fix trivial error
Please fix this trivial error:
pcbnew/tools/edit_tool.cpp:95: warning: Empty msgid. It is reserved by GNU
gettext:
gettext("") returns the header entry
with
meta information, not the empty string.
TIA
--
Marco Ciampa
I know a joke about UDP, but you might not get it.
GNU/Linux User #78271
FSFE fellow #364
___
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] [RFC] Proof of concept of mathematical expression input for text fields.
On Sun, Aug 27, 2017 at 04:06:50PM -0400, David Novak wrote: > On 8/27/2017 11:03 AM, Russell Oliver wrote: > >Hi all, > > > >Attached is a patch that allows for the use of a mathematical expression > >when editing the value field of components in Eeschema. > > > >If editing the value field and the entered string begins with an equals > >sign "=" as you would when entering a formula into an Excel spreadsheet > >cell, it is compiled and parsed when the Enter button is pressed while the > >text entry is in focus. > > > >A valid expression is returned as a double value which is then printed > >with a format to remove trailing zeroes. An invalid expression will not > >change the text value. > > > >The expression parser is simple wrap of the C++ Mathematical Expression > >Toolkit Library (ExprTk) written Arash Partow and is under the MIT > >licence [1]. > > > >I think this provides a template for other numerical input fields within > >Kicad. > > > >[1] http://www.partow.net/programming/exprtk/index.html > > > >Kind Regards > >Russell > > > You might consider muparser. > > David > +1 muparser is already present in many distros: apt-cache search muparser libmuparser-dev - fast mathematical expressions parse library (development) libmuparser-doc - fast mathematical expressions parser library (documentation) libmuparser2v5 - fast mathematical expressions parser library (runtime) -- Marco Ciampa I know a joke about UDP, but you might not get it. GNU/Linux User #78271 FSFE fellow #364 ___ 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] web eda tools: adapt or die
On the geda-user mailing list started a _very_ interesting discussion about the future of open source EDA tools and openhardware trends. See: http://comments.gmane.org/gmane.comp.cad.geda.user/44049 The event that kindled the discussion is the eruption of new web tools like these: http://www.digikey.com/en/resources/scheme-it https://upverter.com/ There is a big mediatic pressure to use this kind of web/cloud tools http://electronicdesign.com/products/still-drawing-circuits-napkin-try-scheme-it-instead And someone see these as what really are: a new and powerfull kind of lock-in. The real problem? As always: the document format. Adapt or die. How to remedy? - unite the scarce resurces: you may say I am a bit naive but I always wondered the reason of the existence of two so similar (at aim) projects like geda and kicad. What about to keep in touch more and try to, if not coalesce, integrate better what can be easiling united like component libs? - try to create a common format to use or try to consider the other free formats more in a way to make easier to import/export from/to these sibling projects with the goal to be able, one day, to use a unique common source What do you think? -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Linux bundle (was: kicad on Mac OS)
On Mon, Oct 20, 2014 at 04:19:06PM +0200, Bernhard Stegmaier wrote: > KiCad carries every library it depends on in the bundle (in contrast to > e.g., linux). [...] Since there are so few linux distros with the brand new python-wxgtk3.0 installed, not even last Ubuntu LTS (so no-go for two years at least...), why not consider an installer that installs all needed libraries in one comfortable /opt/kicad subdir? bye -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] kicad-install.sh requiring python-wxgtk3.0
On Mon, Oct 20, 2014 at 05:07:05PM +0200, Jean-Samuel Reynaud wrote: > Hi Nick, > > Currently kicad-install.sh script does not have "python-wxgtk3.0-dev" in > "prerequisite_list". > This packages is needed to be able to compile. Please find attached a > small to patch for that... > > Regarding your question I don't know if kicad-install.sh should add the PPA. Why not? That's a great idea! If unsecure you just have to add a question yes/no to the script... -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Stable release version numbers.
On Mon, Oct 20, 2014 at 08:47:54AM -0400, Carl Poirier wrote: > I feel like we wouldn't use the last digit much in a triplet number > because, IIRC, backporting of fixes is not planned. That being said, I > would also begin with at least 2.1, as Cirilo said. > > However, I personally vote for numbering the versions a la MATLAB. I am not a dev, I know, so my 0.002 cents on N.N numbering starting from 2.0 or 2.1 ... -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] new documentation format
Hello, talking about the project of switching the KiCad documentation to an easier to maintain and translate format, after some experiments, (I know, I am slow ... I am not a real programmer) I have produced something to check. This is in effect something like an RFC: I need your comments, suggestions, improvements (and patches are welcome). I started writing an email, this: https://github.com/ciampix/kicad-doc/blob/master/doc/kicad-doc-doc.adoc it got bigger and bigger and it is not finished, but I though that it could be useful to publish it before being closed because I do not want to write it all alone. Along with this text there are two dirs in src: asciidoc and rest. Basically these folders contain the cvpcb manual converted into asciidoc and rest and the small example scripts to create docs into html/pdf/epub. The complete cycle is: (odt->)asciidoc/rest ->translation extraction ->(translation) ->merge->nationalized pdf/html/epub The examples are in asciidoc and rest but the asciidoc toolchain is almost the same for markdown. I have reported some comments about txt2tags, textile and sisu but I do not have studied these tools enough to have a clear idea about. So I ask you to: - have a say about the work - try my examples - express your preferences about: a. the documentation text format b. the data organization of the manuals, in particular: - file name/extension conventions - source files folders, - image folders - makefiles/cmake configuration (I do not know anything about cmake...) - any other thing If you have any doubt or problem about anything please express yourself. I do not think we are in a hurry so I think that we can our time to decide and clear out any quandary. When we will have decided the source text format we will start converting all the manuals. Please bear in mind that *anything written in a foreign language that is not strictly adherent to the english reference manual will have to be removed*. So, if you think that something you have written in a localized manual is not present in the reference, try to translate it in English for the inclusion in the reference: doing this may save your translation and give a hand to the whole project. PS: ... and please forgive my terrible English. -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] new documentation format
On Wed, Oct 22, 2014 at 05:57:22PM +0200, Kerusey Karyu wrote: > To: kicad-developers > From: Marco Ciampa > Date: Tue, 21 Oct 2014 23:58:17 +0200 > > > If you have any doubt or problem about anything please > > express yourself. > > > > I consider that the use of formats to create documentation using > translations in the form of translation database (.po files) will, > despite the many advantages, also some disadvantages for translators. > > While the use of such forms of translations for the UI is quite > comfortable, the use of that form for translating a continuous text > (which is result of the train of thoughts) can be very uncomfortable > for translators. > > Why? The main difficulty will be limited visibility of the logic of the > text and its layout (indentation, spacing). There will be situations > where we will need to translate a fragment out of context. I as a > translator prefer also see more of the text to be able to, among > others, eliminate repetition of words and the use of synonyms. My > native language is very flexible in this topic. > > Taking also the specificity of translated texts, unfortunately, it is > in so many cases impossible to translate word for word. Sometimes you > have to break down complex sentence into two (or even three) sentences > that the reader can easily assimilate them. > By translating KiCad user manual I had to just do that many times. > Sometimes adding something from each other to avoid ambiguity. > > So. That’s my (maybe wrong) doubts. Good point but I think that it is more a theoretical problem than a real one since such tools such as po4a, xml2po, etc. do not break paragraphs and in fact aggregate contiguous paragraphs. See for example the GIMP manual that is actually translated in these languages: Catalá, Dansk, Deutsch, English, Español, Ελληνικά (Greek) Français, Italiano, 日本語(Japanese), 한국어(Korean) Nederlands, Norwegian, Português, Pусский, Slovenščina Svenska, 中文 (Chinese). A manual of about 800 pages long. That kind of problem, for what I may know, never arised. I hope I have unraveled some doubt. -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Fwd: Re: new documentation format
On Wed, Oct 22, 2014 at 10:50:38PM +0100, Brian Sidebotham wrote: > -- Forwarded message -- > From: "Brian Sidebotham" > Date: 22 Oct 2014 22:50 > Subject: Re: [Kicad-developers] new documentation format > To: "Marco Ciampa" > Cc: > > On 22 Oct 2014 22:02, "Marco Ciampa" wrote: > > > > On Wed, Oct 22, 2014 at 05:57:22PM +0200, Kerusey Karyu wrote: > > > To: kicad-developers > > > From: Marco Ciampa > > > Date: Tue, 21 Oct 2014 23:58:17 +0200 > > > > > > > If you have any doubt or problem about anything please > > > > express yourself. > > > > > > > > > > I consider that the use of formats to create documentation using > > > translations in the form of translation database (.po files) will, > > > despite the many advantages, also some disadvantages for translators. > > > > > > While the use of such forms of translations for the UI is quite > > > comfortable, the use of that form for translating a continuous text > > > (which is result of the train of thoughts) can be very uncomfortable > > > for translators. > > > > > > Why? The main difficulty will be limited visibility of the logic of the > > > text and its layout (indentation, spacing). There will be situations > > > where we will need to translate a fragment out of context. I as a > > > translator prefer also see more of the text to be able to, among > > > others, eliminate repetition of words and the use of synonyms. My > > > native language is very flexible in this topic. > > > > > > Taking also the specificity of translated texts, unfortunately, it is > > > in so many cases impossible to translate word for word. Sometimes you > > > have to break down complex sentence into two (or even three) sentences > > > that the reader can easily assimilate them. > > > By translating KiCad user manual I had to just do that many times. > > > Sometimes adding something from each other to avoid ambiguity. > > > > > > So. That’s my (maybe wrong) doubts. > > > > Good point but I think that it is more a theoretical problem than a real > > one since such tools such as po4a, xml2po, etc. do not break paragraphs > > and in fact aggregate contiguous paragraphs. See for example the GIMP > > Excellent, that was the answer I was hoping for! So long as that's true, > which I'm sure it should be, we should be on to a winner with the workflow. Sorry I forgot to show directly the .po files. See by yourself: https://github.com/ciampix/kicad-doc/blob/master/src/asciidoc/cvpcb/po/cvpcb.pot You will see that there are many big paragraphs... -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] new documentation format
On Sat, Oct 25, 2014 at 10:52:54AM -0400, Wayne Stambaugh wrote: > Marco, > > Great work on the conversion analysis. I finally go around to testing > this and I have to say that I prefer the asciidoc format better than the > markdown and rst formats for plain text readability. Almost everyone does it but please consider that readability is not the most important factor. As I said many people use rest because of sphinx. Please consider that sphinx integrate a search javascript function into the html generated, although maybe not so important. > I also could not convert the asciidoc format to pdf using your example. > I always get an error about dblatex failing even though I have it > installed on my Debian partition. I use Ubuntu 14.04. Maybe Debian asciidoc or dblatex packages are bit older? 1. Please print the output error strings eventually augmenting verbosity. 2. try -L or --no-xmllint option, to disable xmllint check for sometimes xmmlint is too picky 3. try using asciidoctor to convert into xml first, exec a2x with -n or --dry-run to see the command line it execs to try to do it manually substituting ascidoc with asciidoctor TIA > None of the section headers or table of contents were > converted so there would obviously be some hand work involved. That's > not a big deal for the cvpcb documentation but for all of the > documentation there is a lot of work to do. Windows support is iffy. > Even though MSYS2 has an asciidoc package, the optional bits to create > pdfs is missing so that is an issue. > > I guess the next steps are: > > * Make the final decision on the format. ok > * Pick a VCS and a host server. Obvious choices are bzr/launchpad > and git/github. I am for git... > * Convert all of the documentation over to asciidoc. I can do it... no problem. > * Write CMake build configuration support to handle dependency > checking, out building, translation file creation, and installation. I do not know cmake at all > * Create initial repo and let the document fixing begin. ok > Any volunteers? Count on me of course. -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] problems running kicad-install.sh
On Sun, Oct 26, 2014 at 10:59:20PM -0700, Jake wrote: [...] > So i deleted the folder entirely with rm -rf ~/kicad_sources/kicad-lib.bzr/ > > and when i ran the script again, now it seems to be working. > > i don't know anything about how bzr works, i am just competent with > git, so hopefully some bash scripting and bzr experts can think of a > way to restructure the install script to more consistently deal with > incomplete installations. I think that a less intrepid user than me > (imagine!) would either have to delete all of ~/kicad_sources and > start over, or give up entirely. > > please let me know if i should post this problem in the bugtracker > or something else to make it easier to deal with, or if i have done > it right. Bazaar is virtually dead. Its userbase decrease day by day. There are some bugs in it that presumably will never be fixed. For example, and this seems to be this case, if you stop a "bzr up" command abruptly, chances are that it will not be able to recover by himself, and you have to delete all and restart downloading afresh. I keep on thinking that a git migration of all kicad project repos should be considered for sometime in the (near?) future... bye -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] new documentation format
On Tue, Oct 28, 2014 at 12:12:52AM +0100, Guilherme Brondani Torri wrote: > On 10/26/14, 12:17 AM, Marco Ciampa wrote: > >On Sat, Oct 25, 2014 at 10:52:54AM -0400, Wayne Stambaugh wrote: > >>Marco, > >> > >>Great work on the conversion analysis. I finally go around to testing > >>this and I have to say that I prefer the asciidoc format better than the > >>markdown and rst formats for plain text readability. > >Almost everyone does it but please consider that readability is not the > >most important factor. As I said many people use rest because of sphinx. > >Please consider that sphinx integrate a search javascript function into > >the html generated, although maybe not so important. > > > > > Hi there! Just a few comment of a casual user... > > I am also looking for alternatives for the Qucs documentation. Our > manuals are in mostly in LaTex which is amazing for what it does, > but is a bit of a pain to translate. I understand... > I found the approach taken by OpenMOC rather interesting [1]. They > use Sphinx and Doxygen combined. The whole documentation is > automatically (re)generated at every commit, directly from the > GitHub repository. These examples are _very_ interesting indeed. We could definitely build something similar. > There is also this demo, [2] which combines Sphinx, Github, > Transifex and publish in the Read the Docs. Apparently anyone with > access to the fork can edit directly on the GitHub web editor and > the documentation is rebuild. I never used Transifex, but it seems > to work very well if someone takes responsibility to sync the > translation files from time to time. > > I have yet to look for similar thinks with AsciiDoc... Me neither but, all in all, is just html pages automatically generated and commited into a git repo. Nothing that we couldn't afford with some simple scripting... > Best regards, > Guilherme > > [1] https://mit-crpg.github.io/OpenMOC/devguide/documentation.html > http://masaori-sphinx-internationalization-example-en.readthedocs.org/en/latest/# Anyway I will take a look at it to see if there are some interesting details that I haven't seen... Many thanks! -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] [PATCH] Rename instances of "module" to "footprint" for consistency
On Wed, Oct 08, 2014 at 02:37:40AM -0400, Mark Roszko wrote:
> So from what I remember, Kicad used to call alot of pcb footprints as
> "modules". Sometimes it was "module", other times "footprint module"
> and now "footprint". Footprint seems to have picked up in usage so
> let's use it everywhere!
> Right now new users just get confused and its a popular compliant. I
> don't blame them, the inconsistency is annoying.
[...]
I see that in all this source the reference is on a "module" so I think
the programmer got tricked by this name and used it also for the message
strings, despite the source file name explicitely refers to "footprints"
and not "modules".
Please apply this patch...
bzr diff
=== modified file 'pcbnew/autorouter/auto_place_footprints.cpp'
--- pcbnew/autorouter/auto_place_footprints.cpp 2014-10-06 01:18:24 +
+++ pcbnew/autorouter/auto_place_footprints.cpp 2014-10-29 15:54:50 +
@@ -278,7 +278,7 @@
while( ( Module = PickModule( this, DC ) ) != NULL )
{
// Display some info about activity, module placement can take a while:
-msg.Printf( _( "Place module %d of %d" ), cnt, moduleCount );
+msg.Printf( _( "Place footprint %d of %d" ), cnt, moduleCount );
SetStatusText( msg );
double initialOrient = Module->GetOrientation();
=== modified file 'pcbnew/autorouter/spread_footprints.cpp'
--- pcbnew/autorouter/spread_footprints.cpp 2014-03-05 17:57:13 +
+++ pcbnew/autorouter/spread_footprints.cpp 2014-10-29 15:52:07 +
@@ -174,7 +174,7 @@
if( aFootprintsOutsideBoardOnly && !edgesExist )
{
DisplayError( this,
- _( "Could not automatically place modules. No board
outlines detected." ) );
+ _( "Could not automatically place footprints. No board
outlines detected." ) );
return;
}
--
Marco Ciampa
I know a joke about UDP, but you might not get it.
++
| Linux User #78271 |
| FSFE fellow #364 |
++
___
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] [PATCH] Rename instances of "module" to "footprint" for consistency
Another patch:
=== modified file 'pcbnew/class_pcb_layer_widget.cpp'
--- pcbnew/class_pcb_layer_widget.cpp 2014-09-14 15:34:37 +
+++ pcbnew/class_pcb_layer_widget.cpp 2014-10-29 22:52:43 +
@@ -73,8 +73,8 @@
RR( _( "Anchors" ), ANCHOR_VISIBLE, WHITE, _( "Show
footprint and text origins as a cross" ) ),
RR( _( "Grid" ),GRID_VISIBLE, WHITE, _( "Show
the (x,y) grid dots" ) ),
RR( _( "No-Connects" ), NO_CONNECTS_VISIBLE,UNSPECIFIED_COLOR, _(
"Show a marker on pads which have no net connected" ) ),
-RR( _( "Modules Front" ), MOD_FR_VISIBLE, UNSPECIFIED_COLOR, _(
"Show footprints that are on board's front") ),
-RR( _( "Modules Back" ),MOD_BK_VISIBLE, UNSPECIFIED_COLOR, _(
"Show footprints that are on board's back") ),
+RR( _( "Footprints Front" ), MOD_FR_VISIBLE, UNSPECIFIED_COLOR,
_( "Show footprints that are on board's front") ),
+RR( _( "Footprints Back" ),MOD_BK_VISIBLE, UNSPECIFIED_COLOR,
_( "Show footprints that are on board's back") ),
RR( _( "Values" ), MOD_VALUES_VISIBLE, UNSPECIFIED_COLOR, _(
"Show footprint's values") ),
RR( _( "References" ), MOD_REFERENCES_VISIBLE, UNSPECIFIED_COLOR, _(
"Show footprint's references") ),
};
=== modified file 'pcbnew/menubar_modedit.cpp'
--- pcbnew/menubar_modedit.cpp 2014-10-15 11:40:38 +
+++ pcbnew/menubar_modedit.cpp 2014-10-29 22:52:56 +
@@ -273,7 +273,7 @@
// Anchor
AddMenuItem( placeMenu, ID_MODEDIT_ANCHOR_TOOL,
_( "A&nchor" ),
- _( "Place footprint module reference anchor" ),
+ _( "Place footprint reference anchor" ),
KiBitmap( anchor_xpm ) );
// Menu Help:
=== modified file 'pcbnew/muonde.cpp'
--- pcbnew/muonde.cpp 2014-08-24 07:05:07 +
+++ pcbnew/muonde.cpp 2014-10-29 22:52:53 +
@@ -1075,7 +1075,7 @@
if( pad == NULL )
{
-DisplayError( this, _( "No pad for this module" ) );
+DisplayError( this, _( "No pad for this footprint" ) );
return;
}
@@ -1083,7 +1083,7 @@
if( next_pad == NULL )
{
-DisplayError( this, _( "Only one pad for this module" ) );
+DisplayError( this, _( "Only one pad for this footprint" ) );
return;
}
--
Marco Ciampa
I know a joke about UDP, but you might not get it.
++
| Linux User #78271 |
| FSFE fellow #364 |
++
___
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] [PATCH] Rename instances of "module" to "footprint" for consistency
On Thu, Oct 30, 2014 at 01:22:34AM +0100, Benoît Roehr wrote: > Beware here, they are not footprint anymore when they are on the > board, have a value, a reference and so on... They are components. > > Footprint is the right term for the standalone "print" a component > will drop on a PCB. You can name them so in the footprint library, > in the component propriety and so on... In the PCB editor, this > object is a Components and should be named so. Ok, clear, thank you very much for the explanation. So we have: a symbol = a generic graphic for schematic a component = a graphic with a meaning (value, reference, etc.) for schematic a footprint = a generic graphic for pcb a module = a graphic with a meaning (value, reference, etc.) for pcb right? -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] [PATCH] Rename instances of "module" to "footprint" for consistency
On Thu, Oct 30, 2014 at 08:37:35AM -0400, Wayne Stambaugh wrote: > Marco, > > In the future, please send patches as attachments rather than in-line. > It makes it easier for me view and apply them. My mail client is not a > very good diff file viewer. > > Thanks, > > Wayne I'll keep it in mind, thanks! -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] [PATCH] Rename instances of "module" to "footprint" for consistency
On Thu, Oct 30, 2014 at 03:10:04PM +0100, Marco Ciampa wrote:
> On Thu, Oct 30, 2014 at 08:37:35AM -0400, Wayne Stambaugh wrote:
> > Marco,
> >
> > In the future, please send patches as attachments rather than in-line.
> > It makes it easier for me view and apply them. My mail client is not a
> > very good diff file viewer.
Patch attached, should be the last.
Please check it, I do not want to rename some python module with python
footprint :-)
With this, _every_ reference to a footprint as a "module" should be removed.
Hope this is will make things clearer...
bye
--
Marco Ciampa
I know a joke about UDP, but you might not get it.
++
| Linux User #78271 |
| FSFE fellow #364 |
++
=== modified file 'pcbnew/autorouter/autorout.cpp'
--- pcbnew/autorouter/autorout.cpp 2014-06-24 16:17:18 +
+++ pcbnew/autorouter/autorout.cpp 2014-10-31 07:59:38 +
@@ -95,7 +95,7 @@
Module = (MODULE*) GetScreen()->GetCurItem();
if( (Module == NULL) || (Module->Type() != PCB_MODULE_T) )
{
-wxMessageBox( _( "Module not selected" ) );
+wxMessageBox( _( "Footprint not selected" ) );
return;
}
break;
=== modified file 'pcbnew/autorouter/move_and_route_event_functions.cpp'
--- pcbnew/autorouter/move_and_route_event_functions.cpp 2014-10-06 01:18:24 +
+++ pcbnew/autorouter/move_and_route_event_functions.cpp 2014-10-31 07:59:00 +
@@ -136,7 +136,7 @@
case ID_POPUP_PCB_SPREAD_NEW_MODULES:
if( GetBoard()->m_Modules == NULL )
{
-DisplayError( this, _( "No modules found!" ) );
+DisplayError( this, _( "No footprint found!" ) );
return;
}
=== modified file 'pcbnew/class_text_mod.cpp'
--- pcbnew/class_text_mod.cpp 2014-10-04 15:15:38 +
+++ pcbnew/class_text_mod.cpp 2014-10-31 08:37:56 +
@@ -384,7 +384,7 @@
};
Line = module->GetReference();
-aList.push_back( MSG_PANEL_ITEM( _( "Module" ), Line, DARKCYAN ) );
+aList.push_back( MSG_PANEL_ITEM( _( "Footprint" ), Line, DARKCYAN ) );
Line = GetShownText();
aList.push_back( MSG_PANEL_ITEM( _( "Text" ), Line, BROWN ) );
=== modified file 'pcbnew/dialogs/dialog_netlist.cpp'
--- pcbnew/dialogs/dialog_netlist.cpp 2014-08-24 07:05:07 +
+++ pcbnew/dialogs/dialog_netlist.cpp 2014-10-31 08:36:18 +
@@ -209,7 +209,7 @@
{
if( m_parent->GetBoard()->m_Modules == NULL )
{
-DisplayInfoMessage( this, _( "No modules" ) );
+DisplayInfoMessage( this, _( "No footprints" ) );
return;
}
@@ -268,7 +268,7 @@
// Search for missing modules on board.
if( missing.size() == 0 )
-list << wxT("") << _( "No missing modules." ) << wxT("");
+list << wxT("") << _( "No missing footprints." ) << wxT("");
else
{
list << wxT("") << _( "Missing:" ) << wxT("");
@@ -287,7 +287,7 @@
// Search for modules found on board but not in net list.
if( notInNetlist.size() == 0 )
-list << wxT( "" ) << _( "No extra modules." ) << wxT( "" );
+list << wxT( "" ) << _( "No extra footprints." ) << wxT( "" );
else
{
list << wxT( "" ) << _( "Not in Netlist:" ) << wxT( "" );
@@ -319,7 +319,7 @@
<< wxT( "" );
}
-HTML_MESSAGE_BOX dlg( this, _( "Check Modules" ) );
+HTML_MESSAGE_BOX dlg( this, _( "Check footprints" ) );
dlg.AddHTML_Text( list );
dlg.ShowModal();
}
=== modified file 'pcbnew/exporters/gen_modules_placefile.cpp'
--- pcbnew/exporters/gen_modules_placefile.cpp 2014-10-26 13:59:01 +
+++ pcbnew/exporters/gen_modules_placefile.cpp 2014-10-31 08:05:17 +
@@ -554,9 +554,9 @@
wxString msg;
if( success )
{
-msg.Printf( _( "Module report file created:\n'%s'" ),
+msg.Printf( _( "Footprint report file created:\n'%s'" ),
GetChars( fn.GetFullPath() ) );
-wxMessageBox( msg, _( "Module Report" ), wxICON_INFORMATION );
+wxMessageBox( msg, _( "Footprint Report" ), wxICON_INFORMATION );
}
else
=== modified file 'pcbnew/loadcmp.cpp'
--- pcbnew/loadcmp.cpp 2014-10-08 05:50:56 +
+++ pcbnew/loadcmp.cpp 2014-10-31 08:03:22 +
@@ -415,10 +415,10 @@
{
wxArrayString headers;
-headers.Add( _( "Module" ) );
+heade
Re: [Kicad-developers] [PATCH] Rename instances of "module" to "footprint" for consistency
On Fri, Oct 31, 2014 at 09:47:16AM +0100, Marco Ciampa wrote: > On Thu, Oct 30, 2014 at 03:10:04PM +0100, Marco Ciampa wrote: > > On Thu, Oct 30, 2014 at 08:37:35AM -0400, Wayne Stambaugh wrote: > > > Marco, > > > > > > In the future, please send patches as attachments rather than in-line. > > > It makes it easier for me view and apply them. My mail client is not a > > > very good diff file viewer. > > Patch attached, should be the last. > Please check it, I do not want to rename some python module with python > footprint :-) > > With this, _every_ reference to a footprint as a "module" should be removed. > Hope this is will make things clearer... Last patch I sent got unnoticed, there was something wrong in it or I have to have patience? :-) BTW: english language specification is not translated, I do not know why. Attached a patch to fix it, please check it. bye -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ === modified file 'common/pgm_base.cpp' --- common/pgm_base.cpp 2014-10-17 17:45:33 + +++ common/pgm_base.cpp 2014-11-01 20:04:25 + @@ -109,8 +109,7 @@ wxLANGUAGE_ENGLISH, ID_LANGUAGE_ENGLISH, lang_en_xpm, -wxT( "English" ), -true +_( "English" ) }, // French language ___ 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] [PATCH] Rename instances of "module" to "footprint" for consistency
On Sat, Nov 01, 2014 at 09:48:51PM +0100, jp charras wrote: > Le 01/11/2014 21:10, Marco Ciampa a écrit : > > On Fri, Oct 31, 2014 at 09:47:16AM +0100, Marco Ciampa wrote: > >> On Thu, Oct 30, 2014 at 03:10:04PM +0100, Marco Ciampa wrote: > >>> On Thu, Oct 30, 2014 at 08:37:35AM -0400, Wayne Stambaugh wrote: > >>>> Marco, > >>>> > >>>> In the future, please send patches as attachments rather than in-line. > >>>> It makes it easier for me view and apply them. My mail client is not a > >>>> very good diff file viewer. > >> > >> Patch attached, should be the last. > >> Please check it, I do not want to rename some python module with python > >> footprint :-) > >> > >> With this, _every_ reference to a footprint as a "module" should be > >> removed. > >> Hope this is will make things clearer... > > > > Last patch I sent got unnoticed, there was something wrong in it or I > > have to have patience? :-) > > > > BTW: english language specification is not translated, I do not know why. > > > > Attached a patch to fix it, please check it. > > > > bye > > No. > > This is not an error, this is a feature. > > If you want to know why, when a developer switches to an other language > for testing purposes mainly, he need to know how to switch back to the > reference language , which is the English language. > > Therefore, translate this line is a bad idea, from my point of view. Well, sorry I though was a bug because usually there is the first choice that is the string translated as "System language" but you can't go wrong because it is the first (top) of the list. Then are listed the other languages. Some use to translate the languages into the current language (as Inkscape) some prefer using to type the language name in its own language (as GIMP: so Italiano, Deutsch, English, Français, and so on). But in any case the system is coherent, there is no "special" language. Anyway it is not so important... -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Translation bugs
On Fri, Nov 14, 2014 at 05:52:10PM +1300, Blair Bonnett wrote: > Hi, > > Do the translators monitor this mailing list, or is there somewhere else I > should post? I have come across three old bugs (dating to 2010 and looking > like they were imported into Launchpad from elsewhere) detailing errors in > three of the translations. I don't speak any of the languages in question, > so if anybody can confirm whether or not the bugs are still valid that > would be appreciated. > > Russian: https://bugs.launchpad.net/kicad/+bug/594098 > Portuguese: https://bugs.launchpad.net/kicad/+bug/594105 > Spanish: https://bugs.launchpad.net/kicad/+bug/599520 BTW the list of translators, hard coded into kicad (why?) is really old... -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] New documentation format.
On Mon, Nov 24, 2014 at 07:19:02PM -0500, Wayne Stambaugh wrote: > It's been a few weeks and I haven't heard anything so I'll assume > everyone who is interested has looked at Marco's evaluation. The only > folks I didn't hear from were the translators. I would be nice to know > what their preferences are with regard to the new format. I would like > to get this moving so the first order of business is to decide on a > format. Thanks Wayne for raising this topic, if it was for me I'll be evaluating forever... > Looking at the different formats, it seems to me that either > asciidoc (easiest to read text format) or reStructuredText (full > implementation) be the new format. Please note that actually it is somehow viceversa: asciidoc is easier to read _and_ more complete, almost comparable to docbook as copleteness, see table formatting for example (complete in asciidoc and absolutly absent in rest) > Given the differences between > markdown implementations (which there seems to be quite a few of), I > would rather not depend on it since it seems to straddle the fence > between asciidoc and rst. Well this is one of my fault. I never obtained to get a complete try of a markdown test. The thing is that I got stuck into choosing the md "flavour" and real life burden too slowed me down. I am dissadisfacted to the fact of not have being able to produce almost one single test conversion. If you can manage to wait for just another week I can try to create one for the purpouse to see at the results. I am resolved to use git-hub version just to see how a good english version appear "live"... The thing that made me not to discard md at all from the "competition" is that I've discovered that the documentation tool that we already use is oxygen and oxygen already creates md output, so using one format for all docs is not at all a bad idea... > I've personally played around with asciidoc > and rst and to be honest I didn't find rst all that bad Apart from table formatting and some other "quirks" like not being able to produce bold _and_ italics together... > once I cleaned > up the formatting of the documentation converted from the odt file some > I'm currently leaning that way at the moment since it supports almost > all of the elements of docbook. ok > Lets see if we can come to a consensus over the new few weeks. Very well, it is time. Many thanks! -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] small bugs reports
Small bugs report, such as this:
#: pcbnew/dialogs/dialog_freeroute_exchange_base.cpp:45
m_buttonLaunchFreeroute = new wxButton( this, wxID_BUTTON_LAUNCH,
_("Launch FreeRouter and Launch FreeRouter"), wxDefaultPosition,
^^^ repetita iuvant?
wxDefaultSize, 0 );
where is the right place to report?
--
Marco Ciampa
I know a joke about UDP, but you might not get it.
++
| Linux User #78271 |
| FSFE fellow #364 |
++
___
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] support for Ubuntu LTS
Please disable the dependecies to libwxgtk-webview3.0-dev in the kicad-install.sh script if that package is not available, as with Ubuntu 14.04 LTS, if not strictly necessary. Ubuntu 14.04 LTS is an important distro so Kicad should work with it if possible. When will be in place a ppa with all wxgtk libs packaged for 14.04 we could safely re-enable those dependencies... My 2 eurocent... -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] coherence in messages
pcbnew/menubar_pcbframe.cpp:508 eeschema/menubar.cpp:416 pcbnew/menubar_pcbframe.cpp:509 eeschema/menubar.cpp:417 pcbnew/menubar_pcbframe.cpp:513 eeschema/menubar.cpp:422 pcbnew/menubar_pcbframe.cpp:514 eeschema/menubar.cpp:423 use either read/write or load/save, avoid read / save, please. Usually translators help pointing out these trivial incoherencies in text messages... hope you appreciate... -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] documentation format
On Wed, Feb 04, 2015 at 01:31:25AM +, John Beard wrote: [...] Well, I could not have said it better. We can choose a format now, knowing that eventually it will not be so difficult to change again into another format in the future if we decide to do so. And if I have done some work I have to thank those people that helped me like John, Alexander and others. Having said so I would like to express my preference to maintain the multiple output format. That could help greatily to lower the barrier to diffuse our beloved CAD. Of course I will be doing my best to maintain the toolchain neccessary to this aim nevertheless the html format alone is easier to use (by just substitute the pdf viewer with a browser) and to maintain (html generation is less error prone than docbook->latex->pdf|ebook). I LOVE read technical books away from the distracting keyboard of a PC and pdf and ebook are perfect for those handy ebook readers like Kindle and iPad. I have seen that there are more and more IT manuals and guides developed with similar toolchains; that could a day produce (why not?) some serious KiCad manual on the shelf of an electronic bookstore. For now I have to port the rest of the docs into the choosen format and to format / improve the existing docs. So lets choose the format and go on! -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] documentation format
On Fri, Feb 06, 2015 at 11:55:58AM +1300, Blair Bonnett wrote: > On 6 February 2015 at 02:52, Wayne Stambaugh wrote: > > > > Marco, you may want to enlist some help. Once all of the documentation > > and build configuration is ready to go, I expect that there will be a > > lot of pull requests to get the documentation ready for the stable > > release. > > > > Some form of task list will be vital here. good idea > Even something like getting a > list of all chapter (or section?) titles and putting them into a wiki page. as you suggest... (see below) -> > Then get people to put their name beside what they are working on. Being a > text format, merging edited sections from different people *shouldn't* be > too tricky, but we don't want multiple people working on the same thing. right > For simplicity, I'd put it on the GitHub wiki for the documentation project > and stick a link to it in the readme. That way, anybody who has a GitHub > account (i.e., anybody who can send a pull request to the project) can edit > the list. -> ...here. It is just a very good idea! Cheers -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] on documentation format ...
Hi all. It seems that it is time to choose a format for good. I am insecure by nature so I am stuck on this quandary: asciidoc or rest? I was almost making up my mind when Alexander Golubev rightly asked me how to split big documents as the pcbnew and eeschema ref manuals into many, one for chapter, files. It turned out that while sphinx is perfectly capable of updating the po files that refers to the multiple splitted chapter files, po4a on which asciidoc relies for i18n, does not "understand" the asciidoc include file macro. This fact means that po4a is not able, by itself, to build a single big or multiple .po files (one for chapter) files from any asciidoc with include macro by itself (that means without the help of some makefile/script magic). And above all, this means that po4a is not able to update the included files with the correct strings from the correct .po file, again without any external (=scripts) help. So we have to: - get rid of the inclusion of multiple chapter files and collect all chapters into one single, one for manual, big file for asciidoc. Simple solution but not very nice. or - try to find a solution via makefile/scripts to obtain one po file per chapter (may be the best solution) for asciidoc, recreate/updated all chapter files using the po files like we are doing now with the single file documents we have now (if you have already a simple solution, please fork & commit! :-) or - get rid of asciidoc altogether and use sphinx that does not have this problem. Apart from being slightly simpler & less sophisticated format it is not a big change from asciidoc. We lose some formatting options on tables and we gain support from https://readthedocs.org/, very interesting platform. But if we may be concerned on rely on github for just the git repo (not a big problem IMHO) maybe this could not a very wise decision... I am investigating the second option. In the meantime please say what you think about the format to choose. Cheers -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] on documentation format ...
On Sat, Feb 07, 2015 at 09:56:36AM +1100, Cirilo Bernardo wrote: > What a nuisance that po4a does not recognize "include". Maybe we should > submit a patch to po4a? That would be the best thing to do. > Otherwise my own preference would be to continue to use individual text > files for chapters and to use other tools to glue them together before > invoking asciidoc. I think that that would resolve the problem in the meantime that po4a devs patch the program. That would be the simpler thing to do, but we could have to introduce the convention of, for example, call the docs with include directive in it docname-master.adoc to obtain a "fusion" of docname_master.adoc+docname_chapter_01.adoc+docname_chapter_02.adoc... into ->docname.adoc nevermind... I've already resolved with some makefile+scripting+sed magic :-) pushing it in a few minutes... We just have to follow the convention of calling the chapters DOCNAME_chapter_NN.adoc etc. as we already do. > UNIX systems usually have several tools installed > which can do the job of stringing the files together (even most shell > environments have such built-in facilities). MinGW/MSys would also have > such facilities. sed you mean? -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] on documentation format ...
On Sat, Feb 07, 2015 at 01:02:20AM +0100, Nick Østergaard wrote: > I think Marco mentioned on IRC that you could provide multiple files to > po4a and solve it with the make scripts. Of course this should not hold > anyone back at patching. > > Is this correct Marco? Yes! See the other mail ... ;-) -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] on documentation format ...
On Sat, Feb 07, 2015 at 10:22:00AM +0400, Fat-Zer wrote: > 2015-02-07 3:11 GMT+03:00 Marco Ciampa : > > On Sat, Feb 07, 2015 at 01:02:20AM +0100, Nick Østergaard wrote: > >> I think Marco mentioned on IRC that you could provide multiple files to > >> po4a and solve it with the make scripts. Of course this should not hold > >> anyone back at patching. > >> > >> Is this correct Marco? > > > > Yes! See the other mail ... ;-) > > > About your Makefile, instead of sed'ing the files you may store them > in the different dir... > > As a propose, have you considered if it would be better to have > multiple po files, one for each *.adoc? As a criterion I want to make the Makefile behave in a way that will be consistent with the behaviour of a new, corrected version of po4a. Let me think about it, I am open to suggestions. If you think there could be a better way to handle it, please try to explain it in all the details so we can see if there are any flaws in it. Using a .po file for file would mean that we cannot maintain the current structure to have a .po file for language: it.po, fr.po, etc. That it means that they should be in a form like: locales/it/LC_MESSAGES/ Pcbnew.po Pcbnew_chapter_01.po Pcbnew_chapter_02.po Pcbnew_chapter_03.po ... that could be a great idea and consistent with other toolchains (see sphinx). Do you prefer this way? Do you think it would be better in this way? PS: hope you do not mind I bounce this email also into devs ml, I do not see any problem on making this discussion public... Thank you very much for sharing me your thougths. I am _not_ a programmer. If someone has some suggestion on how to improve this mechanism, please send suggestions! -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] on documentation format ...
On Mon, Feb 09, 2015 at 10:09:04AM +, Brian Sidebotham wrote: > On 7 February 2015 at 00:09, Marco Ciampa wrote: > > On Sat, Feb 07, 2015 at 09:56:36AM +1100, Cirilo Bernardo wrote: > >> What a nuisance that po4a does not recognize "include". Maybe we should > >> submit a patch to po4a? > > > > That would be the best thing to do. > > > >> Otherwise my own preference would be to continue to use individual text > >> files for chapters and to use other tools to glue them together before > >> invoking asciidoc. > > > > I think that that would resolve the problem in the meantime that po4a devs > > patch the program. > > > > That would be the simpler thing to do, but we could have to introduce the > > convention of, for example, call the docs with include directive in it > > docname-master.adoc to obtain a "fusion" of > > docname_master.adoc+docname_chapter_01.adoc+docname_chapter_02.adoc... > > into ->docname.adoc > > > > nevermind... I've already resolved with some makefile+scripting+sed magic > > :-) pushing it in a few minutes... > > > > We just have to follow the convention of calling the chapters > > > > DOCNAME_chapter_NN.adoc > > > > etc. as we already do. > > > >> UNIX systems usually have several tools installed > >> which can do the job of stringing the files together (even most shell > >> environments have such built-in facilities). MinGW/MSys would also have > >> such facilities. > > > > sed you mean? > > We definitely won't be using sed, Why not? Sed is nearly ubiquitous in the Unix environment... > so don't worry too much about the building of the docs. I find that building the docs is useful to check the results... > We don't need sed 'foo' or anything as we have > CMake and it can do everything we need *cross platform*. We already settled for not caring too much for the doc building *cross platform* since actually there is no (even using sphinx) tool able to build docs *cross platform*. This is due to the fact that the majority of the tools use docbook as an intemediate format, that use xml stylesheets transformations, latex and other tricks to produce pdf and epub. > CMake can read files into variables and it can process configure > files[1] which can produce any intermediate file we require for > processing. ok but I am not using and I am not able to use cmake anyway. I will try to port all the docs into this new format. When the port will be complete cmake people can (if they will) step in. I do not mean to be rude, mind me, just keep on discussing since I am not sure to see your point and that is probably my fault anyway... > Personally I really dislike documentation that's chopped up into > separate pages, not pages, chapters. So for this point we have find an agreement. See below...[XX] > the old CMake documentation is much better than the > new (presumably Sphinx generated) documentation for me. I do not have access to the CMake docs, I do not know and I cannot adjudicate. > One search of > the page always results in me getting results, whereas it doesn't in > the newly separated docs. Uhm that could be really a point to unite all the docs into one big file but perhaps it can be circunvented using the trick to unite all the docs into one big format before compiling... [XX] I am sure I am not the onlyone that find handier to have the big docs separated into chapters ... that could really kill two birds with one stone... > I'll start the CMake and will try and make use of Fat-Zer's starting > point. We have to test for a lot of features though to make it easy > for documentation builders. do you have a git report to follow your work? > I assume that translators will simply use something like poedit which > they'll be used to on the po files, is that right? right > So really, unless they're keen to see the built output, > the documentation build system shouldn't really trip them up anyway. well, seeing the output finished *before* committing the work is a really *plus* that I am not willing to renounce without a very good reason. > Hopefully we'll get CI building > of the docs and an automatic upload of at least one format to the web. That would be nice. Html output is the perfect format for the web, and it could easily be cross platform since it does not need any of the all other tools (docbook/latex/etc.) that complicate the toolchain. Thank for sharing your thoughts -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] on documentation format ...
On Mon, Feb 09, 2015 at 09:35:34AM -0500, Wayne Stambaugh wrote: > On 2/9/2015 6:43 AM, Nick Østergaard wrote: > > 2015-02-09 12:01 GMT+01:00 Marco Ciampa : > >> That would be nice. Html output is the perfect format for the web, and it > >> could easily be cross platform since it does not need any of the all > >> other tools (docbook/latex/etc.) that complicate the toolchain. > > > > Yes, I intend to make the CI do that. I am not sure where if the files > > should be hosted (chached) somewhere out of the Jenkins workspace. I > > was thinking pushing them to http://downloads.kicad-pcb.org/, but I > > will wait fixing that untill we have cmake for the docs. Thank you. > > HTML docs should be pushed to the "Documentation" page on kicad-pcb.org. > PDFs will be required for KiCad binary packages. One thing to consider > is versioning. As KiCad gains new features, the documentation will get > updated accordingly. However, pushing the latest docs to kicad-pcb.org > may confuse stable release users who do not yet have these features. > It's not a major issue right now but it's something we should be > thinking about. Other software projects use the main version number to distiguish main feature version, so the documentation should follow those numbers. For example GIMP v2.4 had a GIMP manual v2.4, 2.6->2.6, 2.8->2.8 and so on... In this way, doc versioning is easier... -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Build options for asciidoc documentation
On Fri, Feb 13, 2015 at 11:17:24AM +, Brian Sidebotham wrote: > Hi Guys, > > I was going to start the CMake stuff soon for the asciidoc > documentation, but I'd like to know what toolchains people want to > support. I'll start a Github repo and we can get stuck in. I'll try > and base it on Fat-Zer's starting point where possible. > > HTML can be done via: > > asciidoc (python) > asciidoctor (ruby) Please note that i18n in asciidoctor is not in place so some items will not be nationalized. For instance the toc title or the special note/warning/tips will always be in English. It seems that asciidoctors devs know about the problem and in a near future that could be resolved. So, for now, I suggest to stick with asciidoc. If we manage to filter the output substituting the untranslated sections, that command could be used anyway. > PDF can be done via: > > a2x > a2x --fop (useful toolchain on Windows) Another method is to convert the document into docbook first and then use pdflatex to obtain the pdf output. Follow a command example: dblatex -b xetex -P latex.output.revhistory=0 -P doc.publisher.show=0 -P doc.collab.show=0 -s pdf-cover-dblatex.sty document.xml bye -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Build options for asciidoc documentation
On Fri, Feb 13, 2015 at 08:52:28PM +, Brian Sidebotham wrote: > Hi Marco, > > To bring more people in on the documentation effort, I'd like to > create a GitHub repo under the KiCad organisation so that people know > it's the official place to work on the documentation. > > Do you think that's a good idea too? No problem for me as long as I have direct write access to it for convenience (=speed) and to continue my port. > Do you want me to do recruitment for translation or documentation > conversion or do you want me to just let you carry on doing the > conversion and italian translation for a while? Well if it will be placed into an "official" place, during the announcement could be a good idea to stress to the fact that anyone is willing to help is welcome (but of course this is always true, isn'it? There is always paucity of hands in the open/free source world... ;-) > It's up to you, I don't want to step on your amazing documentation > effort. >From the start I said that I will be grateful for every help I receive... and this is not amazing if you understand my motivation... 1) First of all I am lazy 2) I was willing to start translating in Italian KiCad docs because a) I was willing to know more about KiCad and this is a good method to read all docs throughly, b) I find that translating into my native language all the KiCad docs, I understand them better. 3) updating a translation from ODT is a nightmare and I am not willing to wasting my time translating something that in a few months could become obsolete and not easy to update so my motivations comes down to spare my time (and yes, hoping at the same time to do the same for other people too). > I'm just going to be adding a CMake build system to it. I know, and I thank you since I really do not know anything about CMake (and my knowledge of make is scarce too anyway...) > I'd like the repo to be under the KiCad organisation umbrella though > so people know it's now official. Don't worry I understand and agree. I have only one concern: I reckon (but I could be totally wrong) that converting a makefile into CMake could be difficult for you if you do not understand completely why it works the way it does. My stupid toolchain with just make and a few scripting is working in a satisfactory way for my goal to have it working on my Ubuntu. I really do not know how to convert it into CMake without breaking its functionality and I am going to miss it if I want to continue updating it while you are working on it. I am afraid that could not be possible to mix and match two build sistems (make and CMake) without affecting the functionality of one or the other. So, maybe its better for you to just try and make a toolchain working for just a little document, say CvPcb, (that I already have completely translated into Italian), in the same way as I have done myself from the start. When it fully works, producing multiple language and multiple format versions correctly, it will be really easy to add all the other docs to your CMake toolchain. So for now you can start an unofficial dev branch with the CMake toolchain and CvPcb and its translation(s) with it. When it works I will add all the other docs that I can continue update in the meantime. We can test it with all the docs and if it works satisfactorily we can "bless" it and merge it into the official git doc repo. What do you think about it? -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Build options for asciidoc documentation
On Sat, Feb 14, 2015 at 07:58:11PM +0300, Fat-Zer wrote: > 2015-02-14 1:36 GMT+03:00 Marco Ciampa : > > On Fri, Feb 13, 2015 at 08:52:28PM +, Brian Sidebotham wrote: > > > > From the start I said that I will be grateful for every help I receive... > > and this is not amazing if you understand my motivation... > > > > 1) First of all I am lazy > > 2) I was willing to start translating in Italian KiCad docs > > because > > a) I was willing to know more about KiCad and this is a good method > > to read all docs throughly, > > b) I find that translating into my native language all the KiCad docs, > > I understand them better. > > 3) updating a translation from ODT is a nightmare and I am not willing to > > wasting my time translating something that in a few months could become > > obsolete and not easy to update > > I was wondering how you have gettextized the translations? > Converted both them to asciidoc? If so, what toolchain you have used > for that and have you do some manual actions? It is all described here: https://github.com/ciampix/kicad-doc/blob/master/doc/kicad-doc-doc.adoc I have used po4a. The toolchain was done with the method of trial-and-error. PS: I have discovered that the epub generation is broken since something in the asciidoc tool a2x does not permit to have references to files (images) outside the build dir ... this disable the ../common images reference. PDF and HTML generation are ok. -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] how to get removed from this list
On Wed, Feb 18, 2015 at 08:33:19AM +, Simon Turner wrote: > Hello > > I'm not sure how and who to ask but I'd like to be removed from this > mailing list please. > > Kind regards > Simon > > > ___ > 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 Just read your own message ^^^^^ Hint: unsubscribe ... -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] before filing a bug report/improvement suggestion
I am here to ask for a suggestion before (if ever) filing a bug that could be a matter of personal taste. I found strange tha the kicad project manager have not a hotkey list. I mean, whenever I see a toolbar I think that I do not want to leave the keyboard to just press a button on the screen, having many key under the hands already. I would suggest to create a hotkey for every button on the toolbar, such as "p" for pcb, "c" for cvpcb, "g" for gerberview, "e" for eeschema and so on. And "?" for the hotkey list window, as in the other kicad ancillary programs. And the hotkey window should be (i18n) translated, as it is missing it all the kicad programs, but for this I already filed a bug report, this: https://bugs.launchpad.net/bugs/1424946 what do you think about? -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Polish support file for asciidoc
On Sat, Mar 07, 2015 at 07:29:14AM +0100, Kerusey (Do odczytu) wrote: > W dniu 2015-03-06 o 23:22, Marco Ciampa pisze: > > > >Many thanks! I finally have produced Polish pdf (attached) ;-) > > > I forgot to ask in my previous mail. > > I have read the created PDF file. It does not look the best, but > it's probably a matter of improving the style (if any). In a few > places I need to improve translated sentences to better connect it > to the whole. I will improve it in the near future. great! > But back to the point. What about the drawings in the translated > documents? In my previous translations of LibreOffice files and > their HTML/asciidoc editions I used localized drawings. > > https://github.com/keruseykaryu/kicad-kerusey-doc-html > > Is there any plan to systematize this point too, so that the reader > of Polish manual had screenshots of the Polish version of the > program? Absolutely YES, you see, in the gettext there are the image links too, and BTW that is handy to signal of a screenshot change in the original doc too. I just haven't make up my mind about where to put i18n screenshots. What do you think is better? Inside the images dir like this: images (for common images like icons) images/it images/pl images/en etc. or instead with a localized images dir like this: images (for common images like icons) images-it images-pl images-en etc. or something else? PS: I will forward to the dev list because perhaps there could be good advices missing if we keep this quandary just between us two ... -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Polish support file for asciidoc
On Sun, Mar 08, 2015 at 01:04:12PM +0100, LordBlick wrote: > In response to a message written on 07.03.2015, 11:49, from Marco Ciampa: > >I just haven't make up my mind about where to put i18n screenshots. What > >do you think is better? Inside the images dir like this: > > > >images (for common images like icons) > >images/it > >images/pl > >images/en > > > >etc. > > > >or instead with a localized images dir like this: > > > >images (for common images like icons) > >images-it > >images-pl > >images-en > > > >etc. > > > >or something else? > IMO tree hierarchy is better choice, but my personal preference is > „pictures/…” > or shortly „pic/…”, because „images” is wider meaningful word, which can cause > some mistakes in future. I am sorry I was not clear. I was not talking about personal preference but instead about better file handling for packaging or other means that I cannot imagine now. BTW the "images" dir name come out from the automatic converter from odt to rest, it was not my choice, I just left it because changing meant search/replace all image links in all converted docs... and in asciidoc image links command is "image", so not at all a bad name... For example packaging. If we are about to prepare some deb packages for nationalized docs, is it better to have a gerarchical format? I think that the "base" package should contain the common and english images (icons, screenshots and diagrams) because of the icons and fallback untranslated images links. So since the "images" dir should always be present it comes down to just a matter of taste... -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Polish support file for asciidoc
On Sun, Mar 08, 2015 at 06:57:19PM +0100, Marco Ciampa wrote: > So since the "images" dir should always be present it comes down to just > a matter of taste... I meant, since "images" dir should always be present, as a it must be part of the base i18n package, it should be just a matter of taste to have the other languages dirs inside or outside it or am I missing something? -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Polish support file for asciidoc
On Sat, Mar 07, 2015 at 11:49:21AM +0100, Marco Ciampa wrote: > I just haven't make up my mind about where to put i18n screenshots. What > do you think is better? Inside the images dir like this: > > images (for common images like icons) > images/it > images/pl > images/en > > etc. > > or instead with a localized images dir like this: > > images (for common images like icons) > images-it > images-pl > images-en > > etc. > > or something else? Since evidently it is not coming out any critical issues regarding this choice, I am keeping the gerarchical structure like this: images/it images/pl images/en etc. and images/common for common images like icons so translators know that they can simply copy image link strings without any need for translation. thanks! For package maintainers: nationalized packages should always depend on en package since en is a fallback for images links. -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Announcing work on providing windows nightlies
On Fri, Mar 13, 2015 at 01:06:16PM +0100, Nick Østergaard wrote: [...] > Also, I wonder why the compiled po files are in the repo also (the .mo > files). Is there a reason for this? Why not just do this as a build > step? Looking at the i18n procedure it rely on poedit reading the headers of the .po file just to update and collect the strings from sources. Since this is done by means of a manual procedure started by humans and not updated automatically, it is necessary to save with the sources even the .mo files that are binary compiled from .po files that are the real source files. I already said that IMNSHO I consider this done badly if not totally wrong. -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] [ciam...@libero.it: Re: Announcing work on providing windows nightlies]
Sorry I erroneously sent this to Nick and not to the list... - Forwarded message from Marco Ciampa - Date: Fri, 13 Mar 2015 18:23:13 +0100 From: Marco Ciampa To: Nick Østergaard Subject: Re: [Kicad-developers] Announcing work on providing windows nightlies User-Agent: Mutt/1.5.21 (2010-09-15) On Fri, Mar 13, 2015 at 05:21:05PM +0100, Nick Østergaard wrote: > 2015-03-13 16:29 GMT+01:00 Marco Ciampa : > > On Fri, Mar 13, 2015 at 01:06:16PM +0100, Nick Østergaard wrote: > > [...] > >> Also, I wonder why the compiled po files are in the repo also (the .mo > >> files). Is there a reason for this? Why not just do this as a build > >> step? > > > > Looking at the i18n procedure it rely on poedit reading the headers of > > the .po file just to update and collect the strings from sources. > > > > Since this is done by means of a manual procedure started by humans and > > not updated automatically, it is necessary to save with the sources even > > the .mo files that are binary compiled from .po files that are the real > > source files. > > > > I already said that IMNSHO I consider this done badly if not totally > > wrong. > > Marco, I don't quite understand your point here. The po files are the > sources, the mo files are the binaries. so far so good > For any source it should only > be nessesary to keep the sources (po files) versioned, whilst the > binaries should be compiled. that is exactly my point > I don't see what you think is done manually. I mean: - where is the catalog file, the file that contains list of sources from which the translatable strings are extracted? Actually there is no such file (IIRC) but a list of reference in the .po files headers - usually there is a file, usually named POTFILES that contains the references to such source files - usually compilation scripts use such POTFILES file to create a .pot catalog file that is then used to automatically update the .po files - usually compilation script (make/cmake and such) keeps .mo files compiled into .mo files - having such mechanism in-place there is no use to commit binary files with source .po files > What I really ask is; is there a use for the mo files to be precompiled? normally not. But our workflow depends on poedit .mo compilation, update and and catalog handling. .mo files are not automatically compiled by any cmake script (if I am not totally wrong) nor .po files are automatically updated/merged by the gettext tools. Usually such task is handled by intltool-update script that is not part of cmake or kicad. If we want to automate the .po file generation/update/handling we should create such a mechanism or adopt some ready made tool such GNU intltool. bye -- Marco Ciampa I know a joke about UDP, but you might not get it. +----+ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ - End forwarded message - -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] Stable release update.
On Sat, Mar 14, 2015 at 02:47:45PM -0400, Wayne Stambaugh wrote: > As you all know we are currently working towards a stable release. I > need to get and idea of what open items are left before I declare a > feature freeze. Here is the list of things I know about: > > * Environment variable path edit dialog (me, in progress). > * Add bitmaps and missing entries to GAL canvas context menu (CERN). > * Python API (Miguel). > * OSX track pad (Garth). > > Are there any other features that are on the radar for the next stable > release? I will make exceptions on a case by case basis after the > freeze but I don't want to get blind sided by any unexpected feature > requests the week before the stable release. These are my suggestions for new features for this stable release or the next, whatever you think is better. * new documentation access in place I mean, you know, the new documentation format is able to produce: 1) nationalized output 2) more than one format output: html, pdf, epub and more Now the program use a pdf reader for consulting the documentation. We can: 1) switch to html format for the default documentation format to be more easily consulted (so no pdf reader but an html browser instead) 2) enable a fallback to let people do not install kicad doc package and read the docs direcly on line 3) let the program switch the language docs automatically using the program language preference (if I use the program in Italian I would probably prefer to read the docs in Italian too) 4) in the future this switch will enable us to have even a "context sensitive help command" in which a user will be able to open the user (reference) manual directy in the page describing the command icon under which the mouse pointer is in that moment. To make sure that this happens the docs should be edited by inserting references to the right places. * move the .po files from the docs tree to the main source tree This to manage automatically during compilation process: 1) the production of the binary .mo files 2) update automatically the .po files from the sources without relying on an external program (poedit) features and having to commit the binary .mo files together with the source .po files ... Bear in mind that I am not a programmer, and these are suggestions that I am not able to do by myself. I really wish I were able to attach a patch for this! -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] [RFC] Footprint wizard
On Fri, Mar 20, 2015 at 01:00:19PM +0100, jp charras wrote: > If the full set of libraries is not included in the package, many issues > will be removed, namely: > - overwriting existing libs by new libs. > - The distribution file could be smaller (libs are more than 50% of the > size of compressed distribution file) > - and, trust me, remove a lot of mistakes when building the distrib file. > > Ultimately, schematic library files could be removed from the kicad > distribution file when such a way to download them exists. I have proposed something similar for docs but received no feedback. I though it was a good idea... -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] [PATCH] Assertion failure and can't close Hotkeys List
On Fri, Mar 20, 2015 at 08:12:36PM +0100, jp charras wrote: > Le 20/03/2015 19:15, Chris Pavlina a écrit : > > When the Hotkeys List was changed to non-modal, its OnCloseButtonClick() > > was not changed to reflect the fact that modal and modeless dialogs have > > to be closed differently in wx. Here's a patch to fix that, which should > > work for all HTML_MESSAGE_BOXes whether or not they're modal. > > > > Chris > > Damn! > you are right. > > I committed your patch. thanks. And, BTW, why the hotkey list is not i18n? Using a HELP Window that do not help you in your tongue, meanwhile all the program dialogs are translated, is bizarre at least... -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] [PATCH] Assertion failure and can't close Hotkeys List
On Sat, Mar 21, 2015 at 02:38:36PM +0100, jp charras wrote: > Le 21/03/2015 14:05, Marco Ciampa a écrit : > > On Fri, Mar 20, 2015 at 08:12:36PM +0100, jp charras wrote: > >> Le 20/03/2015 19:15, Chris Pavlina a écrit : > >>> When the Hotkeys List was changed to non-modal, its OnCloseButtonClick() > >>> was not changed to reflect the fact that modal and modeless dialogs have > >>> to be closed differently in wx. Here's a patch to fix that, which should > >>> work for all HTML_MESSAGE_BOXes whether or not they're modal. > >>> > >>> Chris > >> > >> Damn! > >> you are right. > >> > >> I committed your patch. thanks. > > > > And, BTW, why the hotkey list is not i18n? Using a HELP Window that do > > not help you in your tongue, meanwhile all the program dialogs are > > translated, is bizarre at least... > > > > Well: > - Most of hotkeys are the first letter of the command name (in English) That is _not_ a problem, especially when translating a tutorial, having the same keys. > - These strings are also used as keywords in hotkey config file. > Keep them in English is not so bad. No, believe me. Either use the program in English or traslate _all_. In this case IMHO a compromise is not accettable > (this is also the case for .kicad_pcb files which are using English > layers names for non copper layer.) And I agree here. A document format/content is _not_ a help window. I espect it to be read by different kind of people, not beginners anyway... -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] [PATCH] Assertion failure and can't close Hotkeys List
...and IMHO the list is a little too big. With a small screen it goes out of the screen border. Why not: 1) use a smaller default font 2) make it in two columns I am afraid to be boring you all with my usability/i18n feedback, hope someone will appreciate it. -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] [proposal] pcbnew/eeschema save/copy/duplicate consistency and customary definitions
On Sat, Mar 21, 2015 at 11:48:44AM -0400, Chris Pavlina wrote: > Possible drawbacks: > > 1. Existing tutorials/unofficial docs will not match. Not such a big > deal in this case as 'duplicate' is quite obvious. > 2. Existing tutorials/unofficial docs will not match. Bit more > important for save vs. copy. IMHO not a real problem since docs are to be revised anyway because: 1. there are some inconsistency about the term module (deleted from the program) and footprint. Docs here and there talk about modules in the descriptions and program messages/menu. 2. new functions are to be added to the docs. 3. docs are now in a more manageable and community frendly format (asciidoc) and I invite all to revise them and ask for pull or suggest error fix / improvement. https://github.com/ciampix/kicad-doc/tree/master/src/asciidoc bye -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] [PATCH] Assertion failure and can't close Hotkeys List
On Sun, Mar 22, 2015 at 03:11:30PM +0100, jp charras wrote: > These hotkey strings info are now translated in dialogs in rev 5530. Many thanks! Starting translating right now! PS: #: pcbnew/hotkeys.cpp:96 msgid "Save Module" is this right or you meant a "Save footprint"? -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] [PATCH] Assertion failure and can't close Hotkeys List
On Mon, Mar 23, 2015 at 09:29:37AM +0100, jp charras wrote: > I mean "Save Footprint" > Modified in rev 5531. Thanks! During translation you encounter many small typo and such, it is like an involuntary revision. Perhaps here there is another: #: pcbnew/pad_edition_functions.cpp:217 #, c-format msgid "Delete Pad (module %s %s) " apart from the "module" again, perhaps there is a question mark missing? -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] thoughts on dependency on SISL library
IANAL... On Fri, Mar 27, 2015 at 04:42:24PM +0100, Miguel Ángel Ajo wrote: > I’m not sure it fits all use cases I could think of, for example, > let’s think you’re a board assembler/manufacturer, and you setup > a site that accepts KiCad designs, and processes the files > automatically via scripting to send you a cost estimation, > and other information. > > Having SINTEF as AGPL could require them to publish their > website scripts?, or their processing scripts? I do not think so since AGPL do not automatically extend over external scripts... > , it would be nice > by the way, since other assemblers could have the chance to > start doing the same, but… it’s probably an entry barrier for > this ti happen. > > opinions?, See these already answered related questions: http://stackoverflow.com/questions/12165092/agpl-license-and-non-disclosed-user-scripts-like-blender-python-scripts http://programmers.stackexchange.com/questions/236184/do-i-need-to-publish-deployment-scripts-for-deploying-agpl-licensed-work-mongod bye -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] thoughts on dependency on SISL library
On Fri, Mar 27, 2015 at 10:28:43PM -0500, inkblotter wrote: > Does the AGPL allow me to modify the library and distribute the > modified library? IANAL, yes as GPL does, mantaining the same license. AGPL is just a more web-aware copyleft license. -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] help on docs
Hi everybody, I am writing here to ask a clarification on a term. I was translating in Italian and trying to understand the meaning to strings/commands/chapters works in a way like a revision. The Interactive Router manual states: #Interactive_Router.adoc:174 "*Automatic neckdown* - when enabled, the router tries to break out\n" "pads/vias in a clean way, avoiding acute angles and jagged breakout\n" "traces.\n" Seeing some videos on the Altinum Automatic neckdown feature, this seems to mean a shrinking of traks between pads/vias but the KiCad manual explanation seems to say something different. Am I wrong? Could be improved/changed the description? In the Italian string on the program I also translated the term with "Restringimento automatico" that means something like "Automatic shrinking". Is this correct or not? I am sorry I am not an expert on PCBs nor an expert on KiCad so I have to ask for clarification when I have doubts. PS: actually the only contribution on the translation of the docs is from a Polish guy (thanks!). If some other people want to translate the KiCad docs in some other language I am here to help. Please ask and contribute! https://github.com/ciampix/kicad-doc -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] missing i18n on Interactive Router
I found missing the i18n messages on the contextual (right mouse clic) window of Interactive Router. Or am I missing something? TIA -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] missing i18n on Interactive Router
On Mon, Mar 30, 2015 at 06:34:16PM +0200, Maciej Sumiński wrote: > On 03/30/2015 06:29 PM, Tomasz Wlostowski wrote: > > On 30.03.2015 18:26, Marco Ciampa wrote: > >> I found missing the i18n messages on the contextual (right mouse clic) > >> window of Interactive Router. > >> > >> Or am I missing something? > > You're not missing anything. The router is not translated. Feel free to > > do so. > > I think it might be untranslatable now, because wxWidgets do not > generate appropriate files to be used for translations. If that is the > case, then I will have a look at the problem this week. Yes and I will translate it as soon as it is i18n-enabled. I appreciate your effort, many thanks in advance. -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] another i18n problem
Opening an old schematic, popped up this message (untranslated): "Some of the assigned footprints are legacy entries (are missing lib nicknames). Would you like CvPcb to attempt to convert them to the new required FPID format? (If you answer no, then these assignments will be cleared out and you will have to re-assign these footprints yourself.)" Please i18n it and I will promptly translate it. Hope you appreciate my i18n meticulosity... TIA -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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] please add i18n info (patch)
This patch should add i18n ability to the new add library wizard.
Please apply (and check it before!)
TIA
--
Marco Ciampa
I know a joke about UDP, but you might not get it.
++
| GNU/Linux User #78271 |
| FSFE fellow #364 |
++
=== modified file 'pcbnew/dialogs/wizard_add_fplib_base.cpp'
--- pcbnew/dialogs/wizard_add_fplib_base.cpp 2015-03-30 16:42:39 +
+++ pcbnew/dialogs/wizard_add_fplib_base.cpp 2015-03-31 09:54:29 +
@@ -28,14 +28,14 @@
fgSizer112->SetFlexibleDirection( wxBOTH );
fgSizer112->SetNonFlexibleGrowMode( wxFLEX_GROWMODE_SPECIFIED );
- m_staticText1 = new wxStaticText( m_wizPage1, wxID_ANY, wxT("Welcome to the Add Footprint Libraries Wizard!\n\nPlease select the source for the libraries to add:"), wxDefaultPosition, wxDefaultSize, 0 );
+ m_staticText1 = new wxStaticText( m_wizPage1, wxID_ANY, _( "Welcome to the Add Footprint Libraries Wizard!\n\nPlease select the source for the libraries to add:" ) , wxDefaultPosition, wxDefaultSize, 0 );
m_staticText1->Wrap( -1 );
fgSizer112->Add( m_staticText1, 1, wxALL|wxEXPAND, 5 );
wxBoxSizer* bSizer19;
bSizer19 = new wxBoxSizer( wxVERTICAL );
- m_radioAddLocal = new wxRadioButton( m_wizPage1, wxID_ANY, wxT("Files on my computer"), wxDefaultPosition, wxDefaultSize, 0 );
+ m_radioAddLocal = new wxRadioButton( m_wizPage1, wxID_ANY, _("Files on my computer"), wxDefaultPosition, wxDefaultSize, 0 );
bSizer19->Add( m_radioAddLocal, 0, wxALL|wxEXPAND, 5 );
wxBoxSizer* m_sizerGithub;
@@ -55,10 +55,10 @@
m_githubSizer->SetFlexibleDirection( wxBOTH );
m_githubSizer->SetNonFlexibleGrowMode( wxFLEX_GROWMODE_SPECIFIED );
- m_radioAddGithub = new wxRadioButton( m_wizPage1, wxID_ANY, wxT("Github repository"), wxDefaultPosition, wxDefaultSize, 0 );
+ m_radioAddGithub = new wxRadioButton( m_wizPage1, wxID_ANY, _("Github repository"), wxDefaultPosition, wxDefaultSize, 0 );
m_githubSizer->Add( m_radioAddGithub, 0, wxALL|wxEXPAND, 5 );
- m_textCtrlGithubURL = new wxTextCtrl( m_wizPage1, wxID_ANY, wxT("http://github.com/KiCad";), wxDefaultPosition, wxDefaultSize, 0 );
+ m_textCtrlGithubURL = new wxTextCtrl( m_wizPage1, wxID_ANY, "http://github.com/KiCad";, wxDefaultPosition, wxDefaultSize, 0 );
m_textCtrlGithubURL->SetMinSize( wxSize( 300,-1 ) );
m_githubSizer->Add( m_textCtrlGithubURL, 1, wxALL|wxEXPAND, 5 );
@@ -66,7 +66,7 @@
m_githubSizer->Add( 0, 0, 1, wxEXPAND, 5 );
- m_downloadGithub = new wxCheckBox( m_wizPage1, wxID_ANY, wxT("Save a local copy to:"), wxDefaultPosition, wxDefaultSize, 0 );
+ m_downloadGithub = new wxCheckBox( m_wizPage1, wxID_ANY, _("Save a local copy to:"), wxDefaultPosition, wxDefaultSize, 0 );
m_downloadGithub->SetValue(true);
m_githubSizer->Add( m_downloadGithub, 0, wxALL, 5 );
@@ -82,7 +82,7 @@
bSizer9->Add( m_downloadDir, 1, wxALIGN_CENTER_VERTICAL|wxALL, 5 );
- m_btnBrowse = new wxButton( m_wizPage1, wxID_ANY, wxT("Browse"), wxDefaultPosition, wxDefaultSize, 0 );
+ m_btnBrowse = new wxButton( m_wizPage1, wxID_ANY, _("Browse"), wxDefaultPosition, wxDefaultSize, 0 );
bSizer9->Add( m_btnBrowse, 0, wxALL, 5 );
@@ -91,7 +91,7 @@
m_githubSizer->Add( 0, 0, 1, wxEXPAND, 5 );
- m_invalidDir = new wxStaticText( m_wizPage1, wxID_ANY, wxT("It is not possible to write in the selected directory.\nPlease choose another one."), wxDefaultPosition, wxDefaultSize, 0 );
+ m_invalidDir = new wxStaticText( m_wizPage1, wxID_ANY, _("It is not possible to write in the selected directory.\nPlease choose another one."), wxDefaultPosition, wxDefaultSize, 0 );
m_invalidDir->Wrap( -1 );
m_invalidDir->SetForegroundColour( wxColour( 255, 0, 0 ) );
@@ -108,14 +108,14 @@
fgSizer12->SetFlexibleDirection( wxBOTH );
fgSizer12->SetNonFlexibleGrowMode( wxFLEX_GROWMODE_SPECIFIED );
- m_staticText8 = new wxStaticText( m_wizPage1, wxID_ANY, wxT("Visit the official"), wxDefaultPosition, wxDefaultSize, 0 );
+ m_staticText8 = new wxStaticText( m_wizPage1, wxID_ANY, _("Visit the official"), wxDefaultPosition, wxDefaultSize, 0 );
m_staticText8->Wrap( -1 );
fgSizer12->Add( m_staticText8, 0, wxALIGN_CENTER_VERTICAL|wxTOP|wxBOTTOM|wxLEFT, 5 );
- m_hyperlink1 = new wxHyperlinkCtrl( m_wizPage1, wxID_ANY, wxT("Kicad repository on Github"), wxT("https://github.com/KiCad";), wxDefaultPosition, wxDefaultSize, wxHL_DEFAULT_STYLE );
+ m_hyperlink1 = new wxHyperlinkCtrl( m_wizPage1, wxID_ANY, _("Kicad repository on Github"), "https://github.com/KiCad";, wxDefaultPosition, wxDefaultSize, wxHL_DEFAULT_STYLE );
fgSizer12->Add( m_hyperlink1, 0, wxTOP|wxBOTTOM, 5 );
- m_staticText9 = new wxStaticText( m_wizPage1, wxID_ANY, wxT("to find numerous
