Re: [Kicad-developers] CERN work package 4 (Extend number of layers)
On 06.06.2014 07:57, Lorenzo Marcantonio wrote: On Fri, Jun 06, 2014 at 01:15:28AM +0200, Tomasz Wlostowski wrote: I can't agree here. One of the main reasons why we did the P&S router was lack of quality interactive router *integrated* in Kicad. We'd like to achieve the same with STEP support. I would have no problem with an external program; I personally prefer the unix 'lot of small programs' philosophy. I'd actually like to have all the postprocessors (plot, drill, reports and so on) as separate programs. Lorenzo, I'm not against unix philosophy. I'm against making core Kicad features rely *exclusively* on command line tools. Having an additional command line PCB plotter/reporter is great for advanced users, but don't expect someone who freshly installed Kicad to be productive with such tools. Most of new people get stuck even with setting env variables... Cheers, Tom ___ 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] CERN work package 4 (Extend number of layers)
On Fri, Jun 06, 2014 at 09:53:39AM +0200, Tomasz Wlostowski wrote: > I'm not against unix philosophy. I'm against making core Kicad features rely > *exclusively* on command line tools. The whole Xilinx ISE works on command line tools, for example. It simply calls the tools in the right order with the right parameters. More or less like the eeschema BOM plugins. Anyway let's stop this here, we should be talking about layers:P -- Lorenzo Marcantonio Logos Srl ___ 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] [OFFTOPIC] CERN work package 4 (Extend number of layers)
On 06.06.2014 10:28, Lorenzo Marcantonio wrote: On Fri, Jun 06, 2014 at 09:53:39AM +0200, Tomasz Wlostowski wrote: I'm not against unix philosophy. I'm against making core Kicad features rely *exclusively* on command line tools. The whole Xilinx ISE works on command line tools, for example. It simply calls the tools in the right order with the right parameters. More or less like the eeschema BOM plugins. And every program spends few minutes just parsing and saving intermediate files. Besides, ISE is a programming environment, not a graphical editing tool. Vivado doesn't work this way anymore. Tom ___ 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] .POS export file format
Le 05/06/2014 23:58, Jake a écrit : > just to be a bit more specific, here is a link to the kicad .POS file > importer as it stands now. You can see that it is designed for the old > file format. > > https://github.com/openpnp/openpnp/blob/develop/gui/src/main/java/org/openpnp/gui/importer/KicadPosImporter.java > > > here is a .POS file exported recently, which as you can see has a > different format. > > http://spaz.org/~jake/stl/bumps-F.Cu.pos > > thank you > -jake Sorry, but I do not remember there is a change. What do you mean by "old format"? -- Jean-Pierre CHARRAS ___ 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] Bug #1003859
Hi, I have been heavily affected by launchpad bug #1003859 ( https://bugs.launchpad.net/kicad/+bug/1003859) for quite some time. I can't make schematics on my desktop and am forced to use a much older laptop I have that really slows me down. I would love to try to help fix it, but I don't think I have the skills or time for this. Anyone on here willing to at least look at it and see what can be done about it? If it would help this bug get fixed faster I would be willing to put a $50 bounty on it getting fixed (this is probably inadequate, but I don't have too much spare money as a student, sorry). I would love to see this fixed soon! Thanks, Jon Neal ___ 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] Bug #1003859
I too am running on Brazos. I have no problems in Ubuntu 14.04, open-source driver. What is your setup? On Fri, Jun 6, 2014 at 11:07 AM, Jon Neal wrote: > Hi, > > I have been heavily affected by launchpad bug #1003859 ( > https://bugs.launchpad.net/kicad/+bug/1003859) for quite some time. I > can't make schematics on my desktop and am forced to use a much older > laptop I have that really slows me down. > > I would love to try to help fix it, but I don't think I have the skills or > time for this. > > Anyone on here willing to at least look at it and see what can be done > about it? If it would help this bug get fixed faster I would be willing to > put a $50 bounty on it getting fixed (this is probably inadequate, but I > don't have too much spare money as a student, sorry). > > I would love to see this fixed soon! > > Thanks, > Jon Neal > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Bug #1003859
Just to be sure, did you try the solution that helped the last few commenters at that bug report? The solution they say works is adding 'Option "EXAPixmaps" "False"' to the radeon section of xorg.conf . -Ian On Fri, Jun 6, 2014 at 8:07 AM, Jon Neal wrote: > Hi, > > I have been heavily affected by launchpad bug #1003859 ( > https://bugs.launchpad.net/kicad/+bug/1003859) for quite some time. I > can't make schematics on my desktop and am forced to use a much older > laptop I have that really slows me down. > > I would love to try to help fix it, but I don't think I have the skills or > time for this. > > Anyone on here willing to at least look at it and see what can be done > about it? If it would help this bug get fixed faster I would be willing to > put a $50 bounty on it getting fixed (this is probably inadequate, but I > don't have too much spare money as a student, sorry). > > I would love to see this fixed soon! > > Thanks, > Jon Neal > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Bug #1003859
I should have specified more, sorry! fedora 19, kernel 3.14, gnome, radeon open source drivers uname -r: 3.14.4-100.fc19.x86_64 radeon 7850 hd graphics card. Any more info that would be useful? The comments in the bug have a good bit more information. Jon On Fri, Jun 6, 2014 at 11:14 AM, Carl Poirier wrote: > I too am running on Brazos. I have no problems in Ubuntu 14.04, > open-source driver. What is your setup? > > > On Fri, Jun 6, 2014 at 11:07 AM, Jon Neal wrote: > >> Hi, >> >> I have been heavily affected by launchpad bug #1003859 ( >> https://bugs.launchpad.net/kicad/+bug/1003859) for quite some time. I >> can't make schematics on my desktop and am forced to use a much older >> laptop I have that really slows me down. >> >> I would love to try to help fix it, but I don't think I have the skills >> or time for this. >> >> Anyone on here willing to at least look at it and see what can be done >> about it? If it would help this bug get fixed faster I would be willing to >> put a $50 bounty on it getting fixed (this is probably inadequate, but I >> don't have too much spare money as a student, sorry). >> >> I would love to see this fixed soon! >> >> Thanks, >> Jon Neal >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> >> > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Bug #1003859
Ian, I didn't want to try to use that as the solution since that makes everything in the OS use software rendering. Was really hoping for a better solution than that. >From my reading it looks like kicad is doing a bunch of context switches between software rendering and hardware rendering which causes gnome, etc to go amazingly slow (i.e. takes 30s to minimize chrome). Jon On Fri, Jun 6, 2014 at 11:16 AM, Ian wrote: > Just to be sure, did you try the solution that helped the last few > commenters at that bug report? The solution they say works is adding > 'Option "EXAPixmaps" "False"' to the radeon section of xorg.conf . > > -Ian > > > On Fri, Jun 6, 2014 at 8:07 AM, Jon Neal wrote: > >> Hi, >> >> I have been heavily affected by launchpad bug #1003859 ( >> https://bugs.launchpad.net/kicad/+bug/1003859) for quite some time. I >> can't make schematics on my desktop and am forced to use a much older >> laptop I have that really slows me down. >> >> I would love to try to help fix it, but I don't think I have the skills >> or time for this. >> >> Anyone on here willing to at least look at it and see what can be done >> about it? If it would help this bug get fixed faster I would be willing to >> put a $50 bounty on it getting fixed (this is probably inadequate, but I >> don't have too much spare money as a student, sorry). >> >> I would love to see this fixed soon! >> >> Thanks, >> Jon Neal >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> >> > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] a way to handle translations
Le 06/06/2014 15:54, Marco Ciampa a écrit : > 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. No problem. But try to use Poedit, it is a *very powerful* tool to manage translations. It can do *much more* than update files. > > 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?), Mainly because criteria to gain write access to each repository are very different. But there are some other issues to use only one repository. 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. Yes, but (Alas!) there are not a lot of volunteer to translate Kicad. Therefore the count to rewrites this path is very low. Thanks to these volunteers. 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. I do not understand your recompilation problem. There are no translation strings in binaries. The right translation (the .mo file, depending on the default language, or the selected language inside Kicad) is loaded by Kicad at run time, on the fly and translations are platform independent. > > 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? Files are a bit large ( roughly 1MB for the set of .mo and .po files) to be sent to the ML. You can send me the 2 files: the .po and the .mo files. > > 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... ;-) > -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help
[Kicad-developers] dyn_cast and ClassOf
Why reinventing the wheel? AFAIK C++ has a pretty good RTTI... Doing it by hand seems to me quite error prone and distracting (and I don't want to know what happens when subclassing). Had to do that in the old borland C++ days (no templates, Borland intrusive containers), didn't like it:D In fact good design practices (at least in OO) would condemn the whole KICAD_T enum :P I think that instead of using such kind of expedient better (virtual) interfaces (in the java sense, pure abstracts to be implemented) should be designed with a refactoring. That is, if you want to use C++ in the OO way (in imperative style I'd simply have checked the type member, without all that template fluff). I guess it's made for performance reason; in the past I actually checked the dynamic_cast implementation and it involves a call and some traversing; probably that's inevitable for supporting correctly the mess of inheritance supported by C++. Given the templating of both dyn_cast and ClassOf, code would be pretty tight; too bad it's horrible to write and read:P My opinion, of course (and as you know I'm not exactly a fan of OOP :D). (yes, it would break the routines and split them all over the singular object and you'll take forever to follow the flow; one of the reasons for me not liking OO) -- Lorenzo Marcantonio Logos Srl ___ 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] Copper layer count
Noticed a thing during today merge... There is at least a check for BOARD::GetCopperLayerCount being < 2 (i.e. a single side board) Since when that's allowed? I remember that the layer setup dialog only goes from 2, it doesn't allow to set only one layer (not a problem really, just don't use the top one...) -- Lorenzo Marcantonio Logos Srl ___ 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] Copper layer count
Le 06/06/2014 19:38, Lorenzo Marcantonio a écrit : > Noticed a thing during today merge... > > There is at least a check for BOARD::GetCopperLayerCount being < 2 (i.e. > a single side board) > > Since when that's allowed? I remember that the layer setup dialog only > goes from 2, it doesn't allow to set only one layer (not a problem > really, just don't use the top one...) > I am pretty sure this is a very old legacy code. It is now allowed. Were is this code? Until now I never see a board which have *really* only one side (however, could be a very interesting board, if exists). -- Jean-Pierre CHARRAS ___ 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] Copper layer count
Le 06/06/2014 19:50, jp charras a écrit : > Le 06/06/2014 19:38, Lorenzo Marcantonio a écrit : >> Noticed a thing during today merge... >> >> There is at least a check for BOARD::GetCopperLayerCount being < 2 (i.e. >> a single side board) >> >> Since when that's allowed? I remember that the layer setup dialog only >> goes from 2, it doesn't allow to set only one layer (not a problem >> really, just don't use the top one...) >> > > I am pretty sure this is a very old legacy code. > It is now allowed. It is *not* allowed. Sorry! > Were is this code? > Until now I never see a board which have *really* only one side > (however, could be a very interesting board, if exists). > -- Jean-Pierre CHARRAS ___ 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] Copper layer count
On Fri, Jun 06, 2014 at 07:50:50PM +0200, jp charras wrote: > I am pretty sure this is a very old legacy code. > It is now allowed. If it's allowed then no issue at all. It made me curious since the layer setup dialog doesn't allow it (and once I tried to do a one layer board and I searched for it). Actually it's very new code. PCBNEW_CONTROL::LayerPrev, for the new GAL interface. Maybe he's simply been cautious. > Were is this code? > Until now I never see a board which have *really* only one side > (however, could be a very interesting board, if exists). There are a lot of THT boards that could be done on only one layer :D -- Lorenzo Marcantonio Logos Srl ___ 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] Copper layer count
On 06/06/2014 07:58 PM, Lorenzo Marcantonio wrote: On Fri, Jun 06, 2014 at 07:50:50PM +0200, jp charras wrote: I am pretty sure this is a very old legacy code. It is now allowed. If it's allowed then no issue at all. It made me curious since the layer setup dialog doesn't allow it (and once I tried to do a one layer board and I searched for it). Actually it's very new code. PCBNEW_CONTROL::LayerPrev, for the new GAL interface. Maybe he's simply been cautious. It was taken from pcbnew/hotkeys_board_editor.cpp:243. I assumed that if it is checked there, then there is a reason for that. Good that there are vigilant code reviewers here, thank you. Regards, Orson ___ 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] dyn_cast and ClassOf
On 06.06.2014 19:33, Lorenzo Marcantonio wrote:
Why reinventing the wheel? AFAIK C++ has a pretty good RTTI...
Doing it by hand seems to me quite error prone and distracting (and
I don't want to know what happens when subclassing). Had to do that in
the old borland C++ days (no templates, Borland intrusive containers),
didn't like it:D
Let's not get back to these dark, ancient times.
Either use only C++ RTTI or a type ID field. Mixing both is ugly.
In fact good design practices (at least in OO) would condemn the whole
KICAD_T enum :P
I think that instead of using such kind of expedient better (virtual)
interfaces (in the java sense, pure abstracts to be implemented) should
be designed with a refactoring.
This means a pretty much complete rewrite of Kicad...
That is, if you want to use C++ in the OO way (in imperative style I'd
simply have checked the type member, without all that template fluff).
I was reading Clang/LLVM source code and found this dyn_cast/isa pattern
very elegant and lightweight. It's a mine of practical OO design ideas.
This template stuff has some advantages:
- it's much faster than C++ dynamic_cast,
- you don't have to remember the type ID <> class association (e.g.
PCB_LINE_T vs class DRAWSEGMENT)
- can be implemented without disrupting the code
- saves a line (or three lines) of code on every down-cast:
Instead of:
if(item->Type() == something)
{
DERIVED *x = static_cast item;
single-line-action
}
all you need is:
if ( SOMETHING *x = dyn_cast(item) )
single-line-action
Regards,
Tom
___
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] Copper layer count
Le 06/06/2014 19:58, Lorenzo Marcantonio a écrit : > On Fri, Jun 06, 2014 at 07:50:50PM +0200, jp charras wrote: >> I am pretty sure this is a very old legacy code. >> It is now allowed. > > If it's allowed then no issue at all. It made me curious since the layer > setup dialog doesn't allow it (and once I tried to do a one layer board > and I searched for it). > > Actually it's very new code. PCBNEW_CONTROL::LayerPrev, for the new GAL > interface. Maybe he's simply been cautious. > >> Were is this code? >> Until now I never see a board which have *really* only one side >> (however, could be a very interesting board, if exists). > > There are a lot of THT boards that could be done on only one layer :D > No. In this case you are talking about one *routing* layer, not a board layer. A board has always 2 * n layers ( You know that). And has at least always 2 sides, therefore 2 layers (like a rope has always 2 ends). THT boards (and not only THT boards) that could be done on only one *routing* layer, but this layer could be the back layer or the front layer. Many time, Guys who make micro-wave boards use only the front layer, and the back layer is a ground plane (not routed, but needed by micro-wave requirements). Other guys often use the back layer to route only one layer. This is a matter of routing constraint, not a matter of layer count. Do not become confused by a layer count and a layer routing constraint. Only one routing layer does not mean one layer, and obviously not only on side. -- Jean-Pierre CHARRAS ___ 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] Copper layer count
On Fri, Jun 06, 2014 at 08:31:33PM +0200, jp charras wrote: > A board has always 2 * n layers ( You know that). > And has at least always 2 sides, therefore 2 layers (like a rope has > always 2 ends). Well, if there isn't copper (or jumpers) it's not a layer for me. And I pay less for the board. But obviously the board is not a moebius strip, so it has two sides :P > THT boards (and not only THT boards) that could be done on only one > *routing* layer, but this layer could be the back layer or the front layer. Another very important case is boards with THT on one side and SMD on the other. Countless power supplies are done that way. Either way, it's not a problem. If I want to do a one layer board I just use one and hide the other. -- Lorenzo Marcantonio Logos Srl ___ 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] Copper layer count
How do you route 3 layer boards? Top layer (components), 2 inner layers and no bottom layer is one configuration that come to mind? Those are not common, but they exist out there. Jean-Paul On Jun 6, 2014, at 2:40 PM, Lorenzo Marcantonio wrote: > On Fri, Jun 06, 2014 at 08:31:33PM +0200, jp charras wrote: >> A board has always 2 * n layers ( You know that). >> And has at least always 2 sides, therefore 2 layers (like a rope has >> always 2 ends). > > Well, if there isn't copper (or jumpers) it's not a layer for me. And > I pay less for the board. But obviously the board is not a moebius > strip, so it has two sides :P > >> THT boards (and not only THT boards) that could be done on only one >> *routing* layer, but this layer could be the back layer or the front layer. > > Another very important case is boards with THT on one side and SMD on > the other. Countless power supplies are done that way. > > Either way, it's not a problem. If I want to do a one layer board I just > use one and hide the other. > > -- > Lorenzo Marcantonio > Logos Srl > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Copper layer count
On Fri, Jun 06, 2014 at 03:50:11PM -0400, Jean-Paul Louis wrote: > How do you route 3 layer boards? Top layer (components), 2 inner layers and > no bottom layer is one configuration that come to mind? Those are not common, > but they exist out there. I suppose in the same way... just ignore one of the layers. BTW what would the benefit for not having the bottom layer? Just curious -- Lorenzo Marcantonio Logos Srl ___ 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] Copper layer count
The bottom was glued with thermal glue to a large heatsink not grounded for various reasons. Jean-Paul AC9GH On Jun 6, 2014, at 3:55 PM, Lorenzo Marcantonio wrote: > On Fri, Jun 06, 2014 at 03:50:11PM -0400, Jean-Paul Louis wrote: >> How do you route 3 layer boards? Top layer (components), 2 inner layers and >> no bottom layer is one configuration that come to mind? Those are not >> common, but they exist out there. > > I suppose in the same way... just ignore one of the layers. BTW what > would the benefit for not having the bottom layer? Just curious > > -- > Lorenzo Marcantonio > Logos Srl > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Copper layer count
I forgot to mention that the other side was filled with potting compound loaded with silica to equalize the heat. The heatsink was the box for the whole circuit. Jean-Paul AC9GH On Jun 6, 2014, at 4:08 PM, Jean-Paul Louis wrote: > The bottom was glued with thermal glue to a large heatsink not grounded for > various reasons. > > Jean-Paul > AC9GH > > On Jun 6, 2014, at 3:55 PM, Lorenzo Marcantonio > wrote: > >> On Fri, Jun 06, 2014 at 03:50:11PM -0400, Jean-Paul Louis wrote: >>> How do you route 3 layer boards? Top layer (components), 2 inner layers and >>> no bottom layer is one configuration that come to mind? Those are not >>> common, but they exist out there. >> >> I suppose in the same way... just ignore one of the layers. BTW what >> would the benefit for not having the bottom layer? Just curious >> >> -- >> Lorenzo Marcantonio >> Logos Srl >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] dyn_cast and ClassOf
On Fri, Jun 06, 2014 at 08:30:59PM +0200, Tomasz Wlostowski wrote:
> Either use only C++ RTTI or a type ID field. Mixing both is ugly.
Or better yet trust your interfaces:P if you need to know the kind of
object you have, then there is a design issue, usually. Also type ID
doesn't handle inheritance easily, which is bad.
> This means a pretty much complete rewrite of Kicad...
Of course. That was meant for *new* code.
> I was reading Clang/LLVM source code and found this dyn_cast/isa pattern
> very elegant and lightweight. It's a mine of practical OO design ideas.
I could argue about the elegance of the whole template cruft:P it seems
that in 'modern' C++ you need to write more boilerplate/magical
definition than actual 'work' code.
> - it's much faster than C++ dynamic_cast,
Same analysis I did.
> - you don't have to remember the type ID <> class association (e.g.
> PCB_LINE_T vs class DRAWSEGMENT)
Have you looked for using typeid? could be an interesting alternative
(altough I don't seen any obvious advantage over the kicad type tag,
other than being a standard construct)
> - can be implemented without disrupting the code
Other than all these ugly things around :D
> - saves a line (or three lines) of code on every down-cast:
Agree with that. Still I found that usually you need to check the type
before the downcast anyway, so you have to do the if statement... also
the downcasted pointer has reduced scope which is IMHO a big advantage.
The common pattern I've found is:
if (stuff->type is CLASS_T) {
CLASS *ptr = static_cast(stuff);
// do things with ptr
}
with your solution the pattern would be:
CLASS *ptr = dyn_cast(stuff); // More or less
if (ptr) {
// do thing with ptr
}
When you expand the template the resulting code is pretty much the same:
CLASS *ptr = (stuff->type is CLASS_T) ? static_cast(stuff) : NULL;
if (ptr) {
// do thing with ptr
}
In the end it's down to individual preference, almost like indentation
conventions...
For the other people however I'd add a big comment explaining how it
works and the limitations (i.e. you need to define the correct ClassOf
statics and maybe other things). I guess it *could* handle inheritance,
putting the closure of the derived classes in the parent (so that an
hypotetical EDA_ITEM::ClassOf would contain almost all of the class
tags:P)
I've had bad experiences wrestling with the TRACK/VIA/SEGZONE class
branch virtuals...
--
Lorenzo Marcantonio
Logos Srl
___
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] bug: MM_PER_IU definition
Current definition: convert_from_iu.h:#define MM_PER_IU 1.0 / 1e5 // Gerbview uses 10 micrometer. convert_from_iu.h:#define MM_PER_IU 1.0 / 1e6 // Pcbnew in nanometers. The current definition should be enclosed in () to ensure correct interpretation when dividing. X / MM_PER_IU = X / 1.0 / 1e6 = X / 1e6 (wrong - user wants X * 1e6) Forms for acceptable definitions: #define MM_PER_IU 1e-5 #define MM_PER_IU ( 1.0 / 1e5 ) I didn't look into usage throughout the code - correcting the definition might break some things which currently work by accident. - Cirilo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] IDF export rewritten
- Original Message - > From: jp charras > To: Cirilo Bernardo ; Ki Cad Developers > > Cc: > Sent: Friday, June 6, 2014 4:39 AM > Subject: Re: [Kicad-developers] [PATCH] IDF export rewritten > > Le 05/06/2014 08:30, Cirilo Bernardo a écrit : > >> I have rewritten the IDF export code to use the new IDF library. > Unfortunately the library is static at the moment since I can't get cmake to > link it and I just can't work out what's going wrong. >> >> Changes: >> + export_idf.cpp now uses the newer IDF code base. Except for better error >> reporting the users should not see anything new. However, the new code > base >> makes it trivial to extend the export routine if users have a need for >> exporting more IDF entities. This could be useful if/when other technical >> layers are implemented. >> >> + the old code (idf_common.cpp/h, idf.cpp/h) has been removed >> >> + some bugs in the IDF code have been fixed, including the map/multimap >> bug reported a few days ago. >> >> Testing: >> The export code was tested on 7 different existing projects of mine and > the >> output compared to the older code to ensure there were no unintended > differences. >> >> >> The patch name is 'kicad_idf_export.patch' and is available from: >> >> https://github.com/cbernardo/kicad-patches >> >> Next step: make the VRML exporter use the improved code in the idftools >> directory. >> >> cheers, >> Cirilo > > Committed. > Please, verify if this is OK. > Thanks Jean-Pierre, I've built and tested the code and as far as I can see it behaves as expected. I will continue to check the code for a few more weeks; it is vital that it works correctly since I rely on it for my own work. - Cirilo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] CERN work package 4 (Extend number of layers)
- Original Message - > From: Tomasz Wlostowski > To: Cirilo Bernardo ; > "kicad-developers@lists.launchpad.net" > Cc: > Sent: Friday, June 6, 2014 9:15 AM > Subject: Re: [Kicad-developers] CERN work package 4 (Extend number of layers) > > On 06.06.2014 00:58, Cirilo Bernardo wrote: >> >> I remember your earlier work with importing STEP model data for the VRML >> viewer. My opinion on using STEP models + 3D view is that we should use >> a separate tool for that job. This avoids adding yet another monstrous >> dependency to KiCad (OpenCascade) and avoids the expensive operations to >> convert the model on-the-fly. > > Hi Cirilo, > > I can't agree here. One of the main reasons why we did the P&S router > was lack of quality interactive router *integrated* in Kicad. We'd like > to achieve the same with STEP support. > > Including OCC as a dependency won't be a problem anymore once we have > DLL/DSO plugins. > > Regards, > > Tom > Hi Tom, If people want to pull in OCC I won't object. What I want to know is if you think it is sensible to convert STEP to VRML on the fly or if we should make a separate tool for this. I prefer a separate tool so that we can continue to use the current 3D model scheme without any confusion about which tool or exporter will use each format of file. If STEP can be used both in 3DView and a mechanical assembly exporter there will be fringe cases where the user is not able to work the way they want. - Cirilo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
