Re: [Kicad-developers] The KiCad GAL new release
The display work fine on my platform for cairo and opengl backend, I don't see other rendering issue (bzr 4225). Nice work, Camille 2013/7/30 Maciej Sumiński maciej.sumin...@cern.ch On 07/29/2013 04:11 PM, Camille Delbegue wrote: Cairo backend doesn't work properly, it is like if the old buffers are not deleted. But sometimes the buffer is correctly refreshed. I attached a picture resulting of a zoom out action. I also encountered this issue with rev 4211 Could you check it again? It seems to be fine now, using the configuration that gave me the same erroneous Cairo output, so it should work on your platform too. Hopefully I have finally got rid of all the display issues. Still, if you find one - do not hesitate to inform me, you are a good tester. Kind 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] The KiCad GAL new release
On 2 August 2013 11:32, Camille Delbegue camille.delbe...@gmail.com wrote: The display work fine on my platform for cairo and opengl backend, I don't see other rendering issue (bzr 4225). Nice work, Camille Just to say, thanks so much for this work from me too Orson! It is really important work for KiCad and it's great to see that branch finally coming through to fruition. Thanks! Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] The KiCad GAL new release
On 07/29/2013 04:11 PM, Camille Delbegue wrote: Cairo backend doesn't work properly, it is like if the old buffers are not deleted. But sometimes the buffer is correctly refreshed. I attached a picture resulting of a zoom out action. I also encountered this issue with rev 4211 Could you check it again? It seems to be fine now, using the configuration that gave me the same erroneous Cairo output, so it should work on your platform too. Hopefully I have finally got rid of all the display issues. Still, if you find one - do not hesitate to inform me, you are a good tester. Kind 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] The KiCad GAL new release
Hi Camille, On 07/19/2013 11:08 PM, Camille Delbegue wrote: It is better but not perfect. Now netnames show on multilayers pads and bottom pads but not on top pads. Could you test the current version? I have managed to fix the problem on my machine, so hopefully it should be fine with yours too. BTW: can you also try Cairo backend and test if it is still fine? Which version of Cairo do you use? Kind 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] The KiCad GAL new release
Hi Lázló, It's me the webserver maintainer right now. The problems come from confluence taking too many resources from it's openvz container (it's a OS level linux virtual machine). Well, that was the usual problem until now, but last time now resource was exhausted and yet it hanged up. Could you please setup a pingdom anywhere to my account miguelan...@nbee.es ? This way next time I could go fast and find where the problem is exactly. 2013/7/25 László Monda l...@monda.hu On Thu, Jul 25, 2013 at 2:13 PM, Adam Wolf adamw...@feelslikeburning.com wrote: Mac and Windows are getting there. I fully expect that by the end of 2013, Kicad'll have daily builds for a few varieties of Linux, OS X, and Windows. Excellent news, Adam! It'd be great to create a download page for the daily releases featuring the daily download links along with daily commits in an easy-to-read manner. Of course this will truly make sense when all the platform-specific builds will be ready. Speaking of the site, it's down. Am I right that it's pretty usual? I'd like to contact with whoever is responsible and offer my help. As a first step Pingdom should be set up to get notified. Just instructed Netcraft to monitor site uptime: http://uptime.netcraft.com/up/graph?site=http%3A%2F%2Fwww.kicad-pcb.org I can't say I'm entirely pleased that Dick thinks the package maintainers should simply retire. Could you clarify , Dick? Adam Wolf Wayne and Layne LLC On Jul 25, 2013 4:27 AM, László Monda l...@monda.hu wrote: On Thu, Jul 25, 2013 at 4:28 AM, Alex G. mr.nuke...@gmail.com wrote: On 07/24/2013 08:51 PM, Dick Hollenbeck wrote: On Jul 24, 2013 4:26 PM, Alex G. mr.nuke...@gmail.com mailto:mr.nuke...@gmail.com wrote: On 07/24/2013 03:41 PM, Dick Hollenbeck wrote: On Jul 24, 2013 3:05 PM, Alex G. mr.nuke...@gmail.com mailto:mr.nuke...@gmail.com P.S. I can't emphasize enough how much I like the new rendering modes. To hear this is good news, I have yet to spend this time to review the intermediary work. But I am extremely happy to hear that someone finds this massive body of work promising. I think your opinion of releases may be overrated however. What is a release wrt kicad? Its fools gold IMO. Just use your own build, you obviously know how to build it. A release or stable branch in distro packager terms is code that the developers, to the best of their ability certify is stable and good for production use. In fact distros have specific guidelines about not packaging development code. What this usually means is distros want a tarball without the terms rc, nightly, devel, alpha, beta, etc (a release). If that is not available, distros are also willing to accept a snapshot of the repository, but strongly encourage (gun-aimed-to-your-head type encouragement) a stable branch is packaged. What this usually means is, as long as GAL is just another branch, it won't get into the hands of the majority of users. There are also a few things that make merging GAL non-trivial. First of all, the tools do not (yet) work in OpenGL/Cairo modes. This will require a smarte(er) merge strategy. In merge ASCII art, it would look something like: - (devel) |---* | / - (gal_merge) | *---(make tools work, etc) * | / - (gal) |*--(continue normal GAL cycle)- (You'll need to read this in monospace for it to make sense) Now this requires some work. I am not qualified to operate the Kicad source tree, but I'm willing to bet it should be doable in a reasonable timeframe. Is it worth it? I vote yes. Distro kicad packages are not even worth the effort in several of the distros, they are so far behind current code as to be irrelevant for a serious kicad user. DISCLAIMER: Skip to third paragraph if you are not interested in discussions about releases. I won't mind. DISCLAIMER2: I'm perfectly fine with the current no-release philosophy. And distro packages being so far behind is partly due to the release-less philosophy. First of all you lose all the bells and whistles of a release (blog posts, articles, users seeing a higher number). You lose, all the publicity, and you lose the users saying My kicad is newer than yours, and hence you lose pressure on the packagers to update. There's no concept of newness. A Kicad branch from two years ago is just as good as today's Kicad (1) (exceptions exist). I speak from the perspective of a packager who is not necessarily a serious kicad user. Not all packagers are. PR is one of the strongest reasons, I believe. Something like http://kernelnewbies.org/LinuxChanges
Re: [Kicad-developers] The KiCad GAL new release
On Thu, Jul 25, 2013 at 4:28 AM, Alex G. mr.nuke...@gmail.com wrote: The release discussion aside, what I was focusing on in the previous email was getting kicad GAL into mainline and getting it to be fully functional -- where getting is to be understood as someone please come do this. I define fully-functional as being able to design a board in the new rendering modes. If you'll try laying a track in non-default mode you'll see what I'm saying. The functional part you mention is all in our agenda at CERN [1]. Next up is the Tool Framework and then the Push Shove Router. Stay tuned! Cheers, Javier [1] http://www.ohwr.org/projects/cern-kicad/wiki/WorkPackages ___ 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] The KiCad GAL new release
On Thu, Jul 25, 2013 at 4:28 AM, Alex G. mr.nuke...@gmail.com wrote: On 07/24/2013 08:51 PM, Dick Hollenbeck wrote: On Jul 24, 2013 4:26 PM, Alex G. mr.nuke...@gmail.com mailto:mr.nuke...@gmail.com wrote: On 07/24/2013 03:41 PM, Dick Hollenbeck wrote: On Jul 24, 2013 3:05 PM, Alex G. mr.nuke...@gmail.com mailto:mr.nuke...@gmail.com P.S. I can't emphasize enough how much I like the new rendering modes. To hear this is good news, I have yet to spend this time to review the intermediary work. But I am extremely happy to hear that someone finds this massive body of work promising. I think your opinion of releases may be overrated however. What is a release wrt kicad? Its fools gold IMO. Just use your own build, you obviously know how to build it. A release or stable branch in distro packager terms is code that the developers, to the best of their ability certify is stable and good for production use. In fact distros have specific guidelines about not packaging development code. What this usually means is distros want a tarball without the terms rc, nightly, devel, alpha, beta, etc (a release). If that is not available, distros are also willing to accept a snapshot of the repository, but strongly encourage (gun-aimed-to-your-head type encouragement) a stable branch is packaged. What this usually means is, as long as GAL is just another branch, it won't get into the hands of the majority of users. There are also a few things that make merging GAL non-trivial. First of all, the tools do not (yet) work in OpenGL/Cairo modes. This will require a smarte(er) merge strategy. In merge ASCII art, it would look something like: - (devel) |---* | / - (gal_merge) | *---(make tools work, etc) * | / - (gal) |*--(continue normal GAL cycle)- (You'll need to read this in monospace for it to make sense) Now this requires some work. I am not qualified to operate the Kicad source tree, but I'm willing to bet it should be doable in a reasonable timeframe. Is it worth it? I vote yes. Distro kicad packages are not even worth the effort in several of the distros, they are so far behind current code as to be irrelevant for a serious kicad user. DISCLAIMER: Skip to third paragraph if you are not interested in discussions about releases. I won't mind. DISCLAIMER2: I'm perfectly fine with the current no-release philosophy. And distro packages being so far behind is partly due to the release-less philosophy. First of all you lose all the bells and whistles of a release (blog posts, articles, users seeing a higher number). You lose, all the publicity, and you lose the users saying My kicad is newer than yours, and hence you lose pressure on the packagers to update. There's no concept of newness. A Kicad branch from two years ago is just as good as today's Kicad (1) (exceptions exist). I speak from the perspective of a packager who is not necessarily a serious kicad user. Not all packagers are. PR is one of the strongest reasons, I believe. Something like http://kernelnewbies.org/LinuxChanges is badly needed for KiCad because users have zero high-level visibility regarding new features. For example the middle button panning feature might seem like a minor change development-wise but it's extremely useful for users. I agree that the no release philosophy directly contributes to outdated packages on distros but seeing the resistance on the development side this can't be expected to change. A part of me can understand it because backporting shit is no fun. As an alternative it'd be extremely useful to provide daily releases to the community. Something like what Adam Wolf does but for all the 3 major platforms. The version string could be updated to the current day, this way users could see who runs the most recent version. This and the news section could boost adoption significantly. Another thing to keep in mind is packager lazyness may hurt Kicad. I often hear things like I can't use kicad because it has [this] and [that] problem; kicad sucks [blablabla], when the problem they describe had been fixed months or even years ago. *** Third paragraph: *** The release discussion aside, what I was focusing on in the previous email was getting kicad GAL into mainline and getting it to be fully functional -- where getting is to be understood as someone please come do this. I define fully-functional as being able to design a board in the new rendering modes. If you'll try laying a track in non-default mode you'll see what I'm saying. You cannot vote action in this project, [...] I can tell you now that I will never make a single commit to the stable branch, ever. Not what I was voting on. Anyhow, I withdraw my (invalid) vote. Anyway, sorry to raise the undead army. Peace out! Alex
Re: [Kicad-developers] The KiCad GAL new release
Mac and Windows are getting there. I fully expect that by the end of 2013, Kicad'll have daily builds for a few varieties of Linux, OS X, and Windows. I can't say I'm entirely pleased that Dick thinks the package maintainers should simply retire. Could you clarify , Dick? Adam Wolf Wayne and Layne LLC On Jul 25, 2013 4:27 AM, László Monda l...@monda.hu wrote: On Thu, Jul 25, 2013 at 4:28 AM, Alex G. mr.nuke...@gmail.com wrote: On 07/24/2013 08:51 PM, Dick Hollenbeck wrote: On Jul 24, 2013 4:26 PM, Alex G. mr.nuke...@gmail.com mailto:mr.nuke...@gmail.com wrote: On 07/24/2013 03:41 PM, Dick Hollenbeck wrote: On Jul 24, 2013 3:05 PM, Alex G. mr.nuke...@gmail.com mailto:mr.nuke...@gmail.com P.S. I can't emphasize enough how much I like the new rendering modes. To hear this is good news, I have yet to spend this time to review the intermediary work. But I am extremely happy to hear that someone finds this massive body of work promising. I think your opinion of releases may be overrated however. What is a release wrt kicad? Its fools gold IMO. Just use your own build, you obviously know how to build it. A release or stable branch in distro packager terms is code that the developers, to the best of their ability certify is stable and good for production use. In fact distros have specific guidelines about not packaging development code. What this usually means is distros want a tarball without the terms rc, nightly, devel, alpha, beta, etc (a release). If that is not available, distros are also willing to accept a snapshot of the repository, but strongly encourage (gun-aimed-to-your-head type encouragement) a stable branch is packaged. What this usually means is, as long as GAL is just another branch, it won't get into the hands of the majority of users. There are also a few things that make merging GAL non-trivial. First of all, the tools do not (yet) work in OpenGL/Cairo modes. This will require a smarte(er) merge strategy. In merge ASCII art, it would look something like: - (devel) |---* | / - (gal_merge) | *---(make tools work, etc) * | / - (gal) |*--(continue normal GAL cycle)- (You'll need to read this in monospace for it to make sense) Now this requires some work. I am not qualified to operate the Kicad source tree, but I'm willing to bet it should be doable in a reasonable timeframe. Is it worth it? I vote yes. Distro kicad packages are not even worth the effort in several of the distros, they are so far behind current code as to be irrelevant for a serious kicad user. DISCLAIMER: Skip to third paragraph if you are not interested in discussions about releases. I won't mind. DISCLAIMER2: I'm perfectly fine with the current no-release philosophy. And distro packages being so far behind is partly due to the release-less philosophy. First of all you lose all the bells and whistles of a release (blog posts, articles, users seeing a higher number). You lose, all the publicity, and you lose the users saying My kicad is newer than yours, and hence you lose pressure on the packagers to update. There's no concept of newness. A Kicad branch from two years ago is just as good as today's Kicad (1) (exceptions exist). I speak from the perspective of a packager who is not necessarily a serious kicad user. Not all packagers are. PR is one of the strongest reasons, I believe. Something like http://kernelnewbies.org/LinuxChanges is badly needed for KiCad because users have zero high-level visibility regarding new features. For example the middle button panning feature might seem like a minor change development-wise but it's extremely useful for users. I agree that the no release philosophy directly contributes to outdated packages on distros but seeing the resistance on the development side this can't be expected to change. A part of me can understand it because backporting shit is no fun. As an alternative it'd be extremely useful to provide daily releases to the community. Something like what Adam Wolf does but for all the 3 major platforms. The version string could be updated to the current day, this way users could see who runs the most recent version. This and the news section could boost adoption significantly. Another thing to keep in mind is packager lazyness may hurt Kicad. I often hear things like I can't use kicad because it has [this] and [that] problem; kicad sucks [blablabla], when the problem they describe had been fixed months or even years ago. *** Third paragraph: *** The release discussion aside, what I was focusing on in the previous email was getting kicad GAL into mainline and getting it to be fully functional -- where getting is to be understood as
Re: [Kicad-developers] The KiCad GAL new release
On Jul 25, 2013 4:27 AM, László Monda l...@monda.hu wrote: On Thu, Jul 25, 2013 at 4:28 AM, Alex G. mr.nuke...@gmail.com wrote: On 07/24/2013 08:51 PM, Dick Hollenbeck wrote: On Jul 24, 2013 4:26 PM, Alex G. mr.nuke...@gmail.com mailto:mr.nuke...@gmail.com wrote: On 07/24/2013 03:41 PM, Dick Hollenbeck wrote: On Jul 24, 2013 3:05 PM, Alex G. mr.nuke...@gmail.com mailto:mr.nuke...@gmail.com P.S. I can't emphasize enough how much I like the new rendering modes. To hear this is good news, I have yet to spend this time to review the intermediary work. But I am extremely happy to hear that someone finds this massive body of work promising. I think your opinion of releases may be overrated however. What is a release wrt kicad? Its fools gold IMO. Just use your own build, you obviously know how to build it. A release or stable branch in distro packager terms is code that the developers, to the best of their ability certify is stable and good for production use. In fact distros have specific guidelines about not packaging development code. What this usually means is distros want a tarball without the terms rc, nightly, devel, alpha, beta, etc (a release). If that is not available, distros are also willing to accept a snapshot of the repository, but strongly encourage (gun-aimed-to-your-head type encouragement) a stable branch is packaged. What this usually means is, as long as GAL is just another branch, it won't get into the hands of the majority of users. There are also a few things that make merging GAL non-trivial. First of all, the tools do not (yet) work in OpenGL/Cairo modes. This will require a smarte(er) merge strategy. In merge ASCII art, it would look something like: - (devel) |---* | / - (gal_merge) | *---(make tools work, etc) * | / - (gal) |*--(continue normal GAL cycle)- (You'll need to read this in monospace for it to make sense) Now this requires some work. I am not qualified to operate the Kicad source tree, but I'm willing to bet it should be doable in a reasonable timeframe. Is it worth it? I vote yes. Distro kicad packages are not even worth the effort in several of the distros, they are so far behind current code as to be irrelevant for a serious kicad user. DISCLAIMER: Skip to third paragraph if you are not interested in discussions about releases. I won't mind. DISCLAIMER2: I'm perfectly fine with the current no-release philosophy. And distro packages being so far behind is partly due to the release-less philosophy. First of all you lose all the bells and whistles of a release (blog posts, articles, users seeing a higher number). You lose, all the publicity, and you lose the users saying My kicad is newer than yours, and hence you lose pressure on the packagers to update. There's no concept of newness. A Kicad branch from two years ago is just as good as today's Kicad (1) (exceptions exist). I speak from the perspective of a packager who is not necessarily a serious kicad user. Not all packagers are. PR is one of the strongest reasons, I believe. Something like http://kernelnewbies.org/LinuxChanges is badly needed for KiCad because users have zero high-level visibility regarding new features. For example the middle button panning feature might seem like a minor change development-wise but it's extremely useful for users. I agree that the no release philosophy directly contributes to outdated packages on distros but seeing the resistance on the development side this can't be expected to change. A part of me can understand it because backporting shit is no fun. As an alternative it'd be extremely useful to provide daily releases to the community. Well yes, that is one of two remaining alternatives after discounting distro packages: daily builds or build your own. Either of these is not only best for the user, but also best for the project because regressions are caught faster and features flow faster. Something like what Adam Wolf does but for all the 3 major platforms. The version string could be updated to the current day, this way users could see who runs the most recent version. This and the news section could boost adoption significantly. Another thing to keep in mind is packager lazyness may hurt Kicad. I often hear things like I can't use kicad because it has [this] and [that] problem; kicad sucks [blablabla], when the problem they describe had been fixed months or even years ago. *** Third paragraph: *** The release discussion aside, what I was focusing on in the previous email was getting kicad GAL into mainline and getting it to be fully functional -- where getting is to be understood as someone please come do this. I define
Re: [Kicad-developers] The KiCad GAL new release
On Thu, Jul 25, 2013 at 2:13 PM, Adam Wolf adamw...@feelslikeburning.com wrote: Mac and Windows are getting there. I fully expect that by the end of 2013, Kicad'll have daily builds for a few varieties of Linux, OS X, and Windows. Excellent news, Adam! It'd be great to create a download page for the daily releases featuring the daily download links along with daily commits in an easy-to-read manner. Of course this will truly make sense when all the platform-specific builds will be ready. Speaking of the site, it's down. Am I right that it's pretty usual? I'd like to contact with whoever is responsible and offer my help. As a first step Pingdom should be set up to get notified. Just instructed Netcraft to monitor site uptime: http://uptime.netcraft.com/up/graph?site=http%3A%2F%2Fwww.kicad-pcb.org I can't say I'm entirely pleased that Dick thinks the package maintainers should simply retire. Could you clarify , Dick? Adam Wolf Wayne and Layne LLC On Jul 25, 2013 4:27 AM, László Monda l...@monda.hu wrote: On Thu, Jul 25, 2013 at 4:28 AM, Alex G. mr.nuke...@gmail.com wrote: On 07/24/2013 08:51 PM, Dick Hollenbeck wrote: On Jul 24, 2013 4:26 PM, Alex G. mr.nuke...@gmail.com mailto:mr.nuke...@gmail.com wrote: On 07/24/2013 03:41 PM, Dick Hollenbeck wrote: On Jul 24, 2013 3:05 PM, Alex G. mr.nuke...@gmail.com mailto:mr.nuke...@gmail.com P.S. I can't emphasize enough how much I like the new rendering modes. To hear this is good news, I have yet to spend this time to review the intermediary work. But I am extremely happy to hear that someone finds this massive body of work promising. I think your opinion of releases may be overrated however. What is a release wrt kicad? Its fools gold IMO. Just use your own build, you obviously know how to build it. A release or stable branch in distro packager terms is code that the developers, to the best of their ability certify is stable and good for production use. In fact distros have specific guidelines about not packaging development code. What this usually means is distros want a tarball without the terms rc, nightly, devel, alpha, beta, etc (a release). If that is not available, distros are also willing to accept a snapshot of the repository, but strongly encourage (gun-aimed-to-your-head type encouragement) a stable branch is packaged. What this usually means is, as long as GAL is just another branch, it won't get into the hands of the majority of users. There are also a few things that make merging GAL non-trivial. First of all, the tools do not (yet) work in OpenGL/Cairo modes. This will require a smarte(er) merge strategy. In merge ASCII art, it would look something like: - (devel) |---* | / - (gal_merge) | *---(make tools work, etc) * | / - (gal) |*--(continue normal GAL cycle)- (You'll need to read this in monospace for it to make sense) Now this requires some work. I am not qualified to operate the Kicad source tree, but I'm willing to bet it should be doable in a reasonable timeframe. Is it worth it? I vote yes. Distro kicad packages are not even worth the effort in several of the distros, they are so far behind current code as to be irrelevant for a serious kicad user. DISCLAIMER: Skip to third paragraph if you are not interested in discussions about releases. I won't mind. DISCLAIMER2: I'm perfectly fine with the current no-release philosophy. And distro packages being so far behind is partly due to the release-less philosophy. First of all you lose all the bells and whistles of a release (blog posts, articles, users seeing a higher number). You lose, all the publicity, and you lose the users saying My kicad is newer than yours, and hence you lose pressure on the packagers to update. There's no concept of newness. A Kicad branch from two years ago is just as good as today's Kicad (1) (exceptions exist). I speak from the perspective of a packager who is not necessarily a serious kicad user. Not all packagers are. PR is one of the strongest reasons, I believe. Something like http://kernelnewbies.org/LinuxChanges is badly needed for KiCad because users have zero high-level visibility regarding new features. For example the middle button panning feature might seem like a minor change development-wise but it's extremely useful for users. I agree that the no release philosophy directly contributes to outdated packages on distros but seeing the resistance on the development side this can't be expected to change. A part of me can understand it because backporting shit is no fun. As an alternative it'd be extremely useful to provide daily releases to the community. Something like what Adam Wolf does but for
Re: [Kicad-developers] The KiCad GAL new release
On 07/08/2013 02:35 PM, Maciej Sumiński wrote: Ladies and Gentlemen, [...] Thanks in advance for your feedback. I've just tested this on a 9800GT with nouveau drivers. Default rendering mode is really laggy (as is in the vanilla pcbnew). On the other hand OpenGL mode is much better, and OpenGL with shaders is super-smooth. Is there any chance GAL can be incorporated into a Kicad release, even if GAL development will continue to be branched? I'd love to be able to design my PCBs in one of the new graphic modes. Also, this would bring a lot more bug reports. Alex P.S. I can't emphasize enough how much I like the new rendering modes. ___ 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] The KiCad GAL new release
On Jul 24, 2013 3:05 PM, Alex G. mr.nuke...@gmail.com wrote: On 07/08/2013 02:35 PM, Maciej Sumiński wrote: Ladies and Gentlemen, [...] Thanks in advance for your feedback. I've just tested this on a 9800GT with nouveau drivers. Default rendering mode is really laggy (as is in the vanilla pcbnew). On the other hand OpenGL mode is much better, and OpenGL with shaders is super-smooth. Is there any chance GAL can be incorporated into a Kicad release, even if GAL development will continue to be branched? I'd love to be able to design my PCBs in one of the new graphic modes. Also, this would bring a lot more bug reports. Alex P.S. I can't emphasize enough how much I like the new rendering modes. To hear this is good news, I have yet to spend this time to review the intermediary work. But I am extremely happy to hear that someone finds this massive body of work promising. I think your opinion of releases may be overrated however. What is a release wrt kicad? Its fools gold IMO. Just use your own build, you obviously know how to build it. I regret ever creating the stable release. It is simply fools gold. The testing tree almost always has fewer bugs simply because they get fixed faster. Dick ___ 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] The KiCad GAL new release
On 07/24/2013 03:41 PM, Dick Hollenbeck wrote: On Jul 24, 2013 3:05 PM, Alex G. mr.nuke...@gmail.com P.S. I can't emphasize enough how much I like the new rendering modes. To hear this is good news, I have yet to spend this time to review the intermediary work. But I am extremely happy to hear that someone finds this massive body of work promising. I think your opinion of releases may be overrated however. What is a release wrt kicad? Its fools gold IMO. Just use your own build, you obviously know how to build it. A release or stable branch in distro packager terms is code that the developers, to the best of their ability certify is stable and good for production use. In fact distros have specific guidelines about not packaging development code. What this usually means is distros want a tarball without the terms rc, nightly, devel, alpha, beta, etc (a release). If that is not available, distros are also willing to accept a snapshot of the repository, but strongly encourage (gun-aimed-to-your-head type encouragement) a stable branch is packaged. What this usually means is, as long as GAL is just another branch, it won't get into the hands of the majority of users. There are also a few things that make merging GAL non-trivial. First of all, the tools do not (yet) work in OpenGL/Cairo modes. This will require a smarte(er) merge strategy. In merge ASCII art, it would look something like: - (devel) |---* | / - (gal_merge) | *---(make tools work, etc) * | / - (gal) |*--(continue normal GAL cycle)- (You'll need to read this in monospace for it to make sense) Now this requires some work. I am not qualified to operate the Kicad source tree, but I'm willing to bet it should be doable in a reasonable timeframe. Is it worth it? I vote yes. I regret ever creating the stable release. It is simply fools gold. The testing tree almost always has fewer bugs simply because they get fixed faster. As a Fedora package maintainer, I can vouch that lacking a stable branch would be a headache hell for a packager. A stable branch prevents cases where a deadly bug is introduced, and very quickly fixed, but a distro taking the source snapshot right in-between. Fool's gold or not, it serves its purpose. DISCLAIMER: I am not involved in packaging Kicad for Fedora. Alex ___ 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] The KiCad GAL new release
On Jul 24, 2013 4:26 PM, Alex G. mr.nuke...@gmail.com wrote: On 07/24/2013 03:41 PM, Dick Hollenbeck wrote: On Jul 24, 2013 3:05 PM, Alex G. mr.nuke...@gmail.com P.S. I can't emphasize enough how much I like the new rendering modes. To hear this is good news, I have yet to spend this time to review the intermediary work. But I am extremely happy to hear that someone finds this massive body of work promising. I think your opinion of releases may be overrated however. What is a release wrt kicad? Its fools gold IMO. Just use your own build, you obviously know how to build it. A release or stable branch in distro packager terms is code that the developers, to the best of their ability certify is stable and good for production use. In fact distros have specific guidelines about not packaging development code. What this usually means is distros want a tarball without the terms rc, nightly, devel, alpha, beta, etc (a release). If that is not available, distros are also willing to accept a snapshot of the repository, but strongly encourage (gun-aimed-to-your-head type encouragement) a stable branch is packaged. What this usually means is, as long as GAL is just another branch, it won't get into the hands of the majority of users. There are also a few things that make merging GAL non-trivial. First of all, the tools do not (yet) work in OpenGL/Cairo modes. This will require a smarte(er) merge strategy. In merge ASCII art, it would look something like: - (devel) |---* | / - (gal_merge) | *---(make tools work, etc) * | / - (gal) |*--(continue normal GAL cycle)- (You'll need to read this in monospace for it to make sense) Now this requires some work. I am not qualified to operate the Kicad source tree, but I'm willing to bet it should be doable in a reasonable timeframe. Is it worth it? I vote yes. Distro kicad packages are not even worth the effort in several of the distros, they are so far behind current code as to be irrelevant for a serious kicad user. You cannot vote action in this project, except when you have a volunteer that is soliciting opinion and willing to do what is decided by others according to vote. I can tell you now that I will never make a single commit to the stable branch, ever. I think it is a dilution of testing and development resources that keeps folks from testing the testing branch. The end result is both branches are of reduced quality relative to a scheme where bugs were smoked out faster because everyone is using the same tree. Again, the stable branch is fools gold. True gold is rapid fixing of breakage in one branch. Package maintainers can establish their own policies, but they need not have an effect on my opimions, any more than my opimions affect their policies. I regret ever creating the stable release. It is simply fools gold. The testing tree almost always has fewer bugs simply because they get fixed faster. As a Fedora package maintainer, I can vouch that lacking a stable branch would be a headache hell for a packager. A stable branch prevents cases where a deadly bug is introduced, and very quickly fixed, but a distro taking the source snapshot right in-between. Fool's gold or not, it serves its purpose. DISCLAIMER: I am not involved in packaging Kicad for Fedora. Alex ___ 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] The KiCad GAL new release
On 07/24/2013 08:51 PM, Dick Hollenbeck wrote: On Jul 24, 2013 4:26 PM, Alex G. mr.nuke...@gmail.com mailto:mr.nuke...@gmail.com wrote: On 07/24/2013 03:41 PM, Dick Hollenbeck wrote: On Jul 24, 2013 3:05 PM, Alex G. mr.nuke...@gmail.com mailto:mr.nuke...@gmail.com P.S. I can't emphasize enough how much I like the new rendering modes. To hear this is good news, I have yet to spend this time to review the intermediary work. But I am extremely happy to hear that someone finds this massive body of work promising. I think your opinion of releases may be overrated however. What is a release wrt kicad? Its fools gold IMO. Just use your own build, you obviously know how to build it. A release or stable branch in distro packager terms is code that the developers, to the best of their ability certify is stable and good for production use. In fact distros have specific guidelines about not packaging development code. What this usually means is distros want a tarball without the terms rc, nightly, devel, alpha, beta, etc (a release). If that is not available, distros are also willing to accept a snapshot of the repository, but strongly encourage (gun-aimed-to-your-head type encouragement) a stable branch is packaged. What this usually means is, as long as GAL is just another branch, it won't get into the hands of the majority of users. There are also a few things that make merging GAL non-trivial. First of all, the tools do not (yet) work in OpenGL/Cairo modes. This will require a smarte(er) merge strategy. In merge ASCII art, it would look something like: - (devel) |---* | / - (gal_merge) | *---(make tools work, etc) * | / - (gal) |*--(continue normal GAL cycle)- (You'll need to read this in monospace for it to make sense) Now this requires some work. I am not qualified to operate the Kicad source tree, but I'm willing to bet it should be doable in a reasonable timeframe. Is it worth it? I vote yes. Distro kicad packages are not even worth the effort in several of the distros, they are so far behind current code as to be irrelevant for a serious kicad user. DISCLAIMER: Skip to third paragraph if you are not interested in discussions about releases. I won't mind. DISCLAIMER2: I'm perfectly fine with the current no-release philosophy. And distro packages being so far behind is partly due to the release-less philosophy. First of all you lose all the bells and whistles of a release (blog posts, articles, users seeing a higher number). You lose, all the publicity, and you lose the users saying My kicad is newer than yours, and hence you lose pressure on the packagers to update. There's no concept of newness. A Kicad branch from two years ago is just as good as today's Kicad (1) (exceptions exist). I speak from the perspective of a packager who is not necessarily a serious kicad user. Not all packagers are. Another thing to keep in mind is packager lazyness may hurt Kicad. I often hear things like I can't use kicad because it has [this] and [that] problem; kicad sucks [blablabla], when the problem they describe had been fixed months or even years ago. *** Third paragraph: *** The release discussion aside, what I was focusing on in the previous email was getting kicad GAL into mainline and getting it to be fully functional -- where getting is to be understood as someone please come do this. I define fully-functional as being able to design a board in the new rendering modes. If you'll try laying a track in non-default mode you'll see what I'm saying. You cannot vote action in this project, [...] I can tell you now that I will never make a single commit to the stable branch, ever. Not what I was voting on. Anyhow, I withdraw my (invalid) vote. Anyway, sorry to raise the undead army. Peace out! Alex (1) This is a great thing actually. It demonstrates the quality of the Kicad code base is very high ___ 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] The KiCad GAL new release
From: Dick Hollenbeck d...@softplc.com To: Alex G. mr.nuke...@gmail.com Cc: KiCad Developers kicad-developers@lists.launchpad.net Sent: Thursday, July 25, 2013 11:51 AM Subject: Re: [Kicad-developers] The KiCad GAL new release On Jul 24, 2013 4:26 PM, Alex G. mr.nuke...@gmail.com wrote: On 07/24/2013 03:41 PM, Dick Hollenbeck wrote: On Jul 24, 2013 3:05 PM, Alex G. mr.nuke...@gmail.com P.S. I can't emphasize enough how much I like the new rendering modes. To hear this is good news, I have yet to spend this time to review the intermediary work. But I am extremely happy to hear that someone finds this massive body of work promising. I think your opinion of releases may be overrated however. What is a release wrt kicad? Its fools gold IMO. Just use your own build, you obviously know how to build it. A release or stable branch in distro packager terms is code that the developers, to the best of their ability certify is stable and good for production use. In fact distros have specific guidelines about not packaging development code. What this usually means is distros want a tarball without the terms rc, nightly, devel, alpha, beta, etc (a release). If that is not available, distros are also willing to accept a snapshot of the repository, but strongly encourage (gun-aimed-to-your-head type encouragement) a stable branch is packaged. What this usually means is, as long as GAL is just another branch, it won't get into the hands of the majority of users. There are also a few things that make merging GAL non-trivial. First of all, the tools do not (yet) work in OpenGL/Cairo modes. This will require a smarte(er) merge strategy. In merge ASCII art, it would look something like: - (devel) |---* | / - (gal_merge) | *---(make tools work, etc) * | / - (gal) |*--(continue normal GAL cycle)- (You'll need to read this in monospace for it to make sense) Now this requires some work. I am not qualified to operate the Kicad source tree, but I'm willing to bet it should be doable in a reasonable timeframe. Is it worth it? I vote yes. Distro kicad packages are not even worth the effort in several of the distros, they are so far behind current code as to be irrelevant for a serious kicad user. You cannot vote action in this project, except when you have a volunteer that is soliciting opinion and willing to do what is decided by others according to vote. I can tell you now that I will never make a single commit to the stable branch, ever. I think it is a dilution of testing and development resources that keeps folks from testing the testing branch. The end result is both branches are of reduced quality relative to a scheme where bugs were smoked out faster because everyone is using the same tree. Again, the stable branch is fools gold. True gold is rapid fixing of breakage in one branch. Package maintainers can establish their own policies, but they need not have an effect on my opimions, any more than my opimions affect their policies. Ah, 'stable' release ... I thought the software world threw out that notion years ago - everything is simply branded Beta software these days, even the stuff I pay $$$ for. From the user's manager's distorted point of view, software should simply work and if there are bugs then the vendor should provide a fix. From the user's point of view, they don't want to learn to compile software. Neither the user nor any managers would want someone to waste time when something breaks and neither would want an incompatible change in file formats. Personally I think that with some software the package maintainers simply have to deliver scripts which build the package as needed. With 'git' this is utterly trivial - the package maintainers can associate a version with a git tag and allow the users to update to the latest in the repository. If the user encounters bugs in the new build they can reinstall the older version, and if they have thrown out the installer package then they can simply rebuild the older version from its git tag. This scheme would be similar to (but much better) than what people currently do on MSWin: (1) install update, (2) scream and tear out hair, (3) uninstall, (4) reinstall older version. So the package maintainer needs to act a bit like a release manager. Although I agree that the packaging is not KiCAD's problem, the question remains: is there anything we can do to help promote KiCAD? - 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] The KiCad GAL new release
On Jul 24, 2013 10:14 PM, Cirilo Bernardo cirilo_berna...@yahoo.com wrote: From: Dick Hollenbeck d...@softplc.com To: Alex G. mr.nuke...@gmail.com Cc: KiCad Developers kicad-developers@lists.launchpad.net Sent: Thursday, July 25, 2013 11:51 AM Subject: Re: [Kicad-developers] The KiCad GAL new release On Jul 24, 2013 4:26 PM, Alex G. mr.nuke...@gmail.com wrote: On 07/24/2013 03:41 PM, Dick Hollenbeck wrote: On Jul 24, 2013 3:05 PM, Alex G. mr.nuke...@gmail.com P.S. I can't emphasize enough how much I like the new rendering modes. To hear this is good news, I have yet to spend this time to review the intermediary work. But I am extremely happy to hear that someone finds this massive body of work promising. I think your opinion of releases may be overrated however. What is a release wrt kicad? Its fools gold IMO. Just use your own build, you obviously know how to build it. A release or stable branch in distro packager terms is code that the developers, to the best of their ability certify is stable and good for production use. In fact distros have specific guidelines about not packaging development code. What this usually means is distros want a tarball without the terms rc, nightly, devel, alpha, beta, etc (a release). If that is not available, distros are also willing to accept a snapshot of the repository, but strongly encourage (gun-aimed-to-your-head type encouragement) a stable branch is packaged. What this usually means is, as long as GAL is just another branch, it won't get into the hands of the majority of users. There are also a few things that make merging GAL non-trivial. First of all, the tools do not (yet) work in OpenGL/Cairo modes. This will require a smarte(er) merge strategy. In merge ASCII art, it would look something like: - (devel) |---* | / - (gal_merge) | *---(make tools work, etc) * | / - (gal) |*--(continue normal GAL cycle)- (You'll need to read this in monospace for it to make sense) Now this requires some work. I am not qualified to operate the Kicad source tree, but I'm willing to bet it should be doable in a reasonable timeframe. Is it worth it? I vote yes. Distro kicad packages are not even worth the effort in several of the distros, they are so far behind current code as to be irrelevant for a serious kicad user. You cannot vote action in this project, except when you have a volunteer that is soliciting opinion and willing to do what is decided by others according to vote. I can tell you now that I will never make a single commit to the stable branch, ever. I think it is a dilution of testing and development resources that keeps folks from testing the testing branch. The end result is both branches are of reduced quality relative to a scheme where bugs were smoked out faster because everyone is using the same tree. Again, the stable branch is fools gold. True gold is rapid fixing of breakage in one branch. Package maintainers can establish their own policies, but they need not have an effect on my opimions, any more than my opimions affect their policies. Ah, 'stable' release ... I thought the software world threw out that notion years ago - everything is simply branded Beta software these days, even the stuff I pay $$$ for. Each software project has different dynamics of evolution. Bunching them all into one broad statement is incorrectly crude. From the user's manager's distorted point of view, software should simply work and if there are bugs then the vendor should provide a fix. From the user's point of view, they don't want to learn to compile software. Neither the user nor any managers would want someone to waste time when something breaks and neither would want an incompatible change in file formats. The builder simply rebuilds, usually within a half day of when the broken code is fixed by a project developer. Its simpler than you describe. Personally I think that with some software the package maintainers simply have to deliver scripts which build the package as needed. Kicad package maintainers can retire as far as I am concerned. Their work is not relevant to the optimal kicad experience. With 'git' this is utterly trivial - the package maintainers can associate a version with a git tag and allow the users to update to the latest in the repository. If the user encounters bugs in the new build they can reinstall the older version, and if they have thrown out the installer package then they can simply rebuild the older version from its git tag. This scheme would be similar to (but much better) than what people currently do on MSWin: (1) install update, (2) scream and tear out hair, (3) uninstall, (4) reinstall older version. So the package
Re: [Kicad-developers] The KiCad GAL new release
- Original Message - From: Rick Walker wal...@omnisterra.com To: KiCad Developers kicad-developers@lists.launchpad.net Cc: Sent: Thursday, July 25, 2013 12:52 PM Subject: Re: [Kicad-developers] The KiCad GAL new release [snip] kind regards, -- Rick Walker I've done several dozen boards in Kicad, so I am a motivated and experienced user. I'm able to make a go of it, but even though I got my work team to do several boards in Kicad, they have since switched to Allegro and abandoned Kicad. What are their reasons for switching to Allegro? - 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] The KiCad GAL new release
On 07/19/2013 11:08 PM, Camille Delbegue wrote: It is better but not perfect. Now netnames show on multilayers pads and bottom pads but not on top pads. The two other issues are resolved. I have managed to recreate the bug. The strange thing is - even within the same machine, but on two different Linux operating systems (ie. exactly the same hardware, but different kernels, graphics driver versions and libraries) it may occur or not. Could you do me a favor and try it out with the proprietary drivers too? I use Intel open source drivers, which does not have a proprietary version, so I cannot test it this way. Anyway, I will try to find a workaround, but it may take some time, as right now I am focused on a different task. Kind 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] The KiCad GAL new release
On 07/08/13 22:35, Maciej Sumiński wrote: Thanks in advance for your feedback. Thanks for your great work. One thing to consider is rendering the netname as it gets covered with wire. The example of the issue is attached and that is reproducible on all new rendering backends. OpenGL renderer string: Gallium 0.4 on AMD RV610 OpenGL version string: 3.0 Mesa 9.1.3 OpenGL shading language version string: 1.30 Application: Pcbnew Version: (2013-07-17 BZR 4198)-testing Build: wxWidgets 2.9.5 (wchar_t,compiler with C++ ABI 1002,GCC 4.7.3,wx containers,compatible with 2.8) Platform: Linux 3.8.0-26-generic x86_64, 64 bit, Little endian, wxGTK Boost version: 1.53.0 Options: USE_PCBNEW_NANOMETRES=ON KICAD_GOST=OFF USE_WX_GRAPHICS_CONTEXT=OFF USE_WX_OVERLAY=OFF KICAD_SCRIPTING=OFF KICAD_SCRIPTING_MODULES=OFF KICAD_SCRIPTING_WXPYTHON=OFF -Vesa attachment: Kicad_GAL_feature.png___ 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] The KiCad GAL new release
Hi Vesa, On 07/22/2013 07:56 PM, Vesa Solonen wrote: Thanks for your great work. One thing to consider is rendering the netname as it gets covered with wire. The example of the issue is attached and that is reproducible on all new rendering backends. Thanks for pointing this out. But in this case the wire means a silkscreen drawing? As the color of the line suggests it is not a usual copper trace. I was thinking of different solutions for layer organization and I stayed with having a netname layer right over every copper/pad layer. In the case shown on the picture, I could move the netname layer to the top and it would be fine, but it will not work for layers other than top/multilayer pads. In case of PCBs containing a few power planes it would be a bit confusing to have netnames regarding bottom layers on the top, as probably the bottom traces would not be even visible, leaving the netname label popping out of nowhere. Of course, I am still open to new ideas - the most important is the user friendliness of the new interface. Moving the multilayer pads netname layer to the top seems sensible and probably will be introduced in one of the next commits. Kind 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] The KiCad GAL new release
2013/7/16 Maciej Sumiński maciej.sumin...@cern.ch On 07/16/2013 12:03 PM, Camille Delbegue wrote: This seems strange to me too. This problem apears only with demo boards and not with my projects (6 boards). I try to zoom more but nothing change, netnames show on tracks but not on pads. Is there someone who experiment the same issue ? I have changed a bit organization of layers - maybe it will solve the problem, as I could not reproduce the bug to test if it is already gone. It is better but not perfect. Now netnames show on multilayers pads and bottom pads but not on top pads. The two other issues are resolved. The second issue is about high contrast mode. The netnames are draw under the highlighted layer (see screenshot of comlex_hierarchy.kicad_pcb). I have just observed that too, I will fix it soon. The fixed version should be already in the repository. I remark some difference between Cairo backend and OpenGL backend. With OpenGL backend, netnames are covered by the other tracks or copper zone, whereas with Cairo, netnames are mixed up with over item. I attached pictures of the different backends results. Thanks for clarifying that, it was hard for me spot the difference. It should be also fixed too. By the way - I have also noticed that there were some layers missing in the high contrast mode (eg. pads vias). Now it looks like I really desired. Kind regards, Orson __**_ Mailing list: https://launchpad.net/~kicad-**developershttps://launchpad.net/~kicad-developers Post to : kicad-developers@lists.**launchpad.netkicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-**developershttps://launchpad.net/~kicad-developers More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp -- Camille Delbegue Élève ingénieur à l'ENSSAT ___ 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] The KiCad GAL new release
On 07/16/2013 12:03 PM, Camille Delbegue wrote: This seems strange to me too. This problem apears only with demo boards and not with my projects (6 boards). I try to zoom more but nothing change, netnames show on tracks but not on pads. Is there someone who experiment the same issue ? I have changed a bit organization of layers - maybe it will solve the problem, as I could not reproduce the bug to test if it is already gone. The second issue is about high contrast mode. The netnames are draw under the highlighted layer (see screenshot of comlex_hierarchy.kicad_pcb). I have just observed that too, I will fix it soon. The fixed version should be already in the repository. I remark some difference between Cairo backend and OpenGL backend. With OpenGL backend, netnames are covered by the other tracks or copper zone, whereas with Cairo, netnames are mixed up with over item. I attached pictures of the different backends results. Thanks for clarifying that, it was hard for me spot the difference. It should be also fixed too. By the way - I have also noticed that there were some layers missing in the high contrast mode (eg. pads vias). Now it looks like I really desired. Kind 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] The KiCad GAL new release
Hi Camille, Thanks for the tests and the bug report. On 07/13/2013 02:04 PM, Camille Delbegue wrote: I tested GAL with all demo board in the repository and netnames on pads are visible only with 3 boards. It woks only with: - flat_hierarchy.kicad_pcb - interf_u.kicad_pcb - pic_programmer.kicad_pcb This seems strange to me - I have just tried out all of board included in the demo folder and everything was fine. Netnames show up, when the zoom is big enough - maybe try zooming even more? The second issue is about high contrast mode. The netnames are draw under the highlighted layer (see screenshot of comlex_hierarchy.kicad_pcb). I have just observed that too, I will fix it soon. There is also a transparency problem with the OpenGL backend and netnames, netnames under tracks are not draw (see screenshot). It is not very clear to me - could you describe the problem with more details? Is it about the case shown on the picture in the attachment? If yes - then it was done on purpose. Netnames are shown directly over tracks, so there are no situations when there is a track, a zone over the track and a netname is shown on the zone. Also, having semitransparent netnames blending into each other makes them hard to read, I think it is better when one is covered by another than when they are mixed up. Kind regards, Orson attachment: cross_tracks.png___ 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] The KiCad GAL new release
Hi Alex, Thank you for reporting the bug, the fix is already included in the repository and your PCB file made the fixing process as easy as it could be. By the way, as you have already run some tests - would you share some thoughts? I am also quite interested in what kind of system (OS GPU, proprietary/open source drivers in case of Linux) you are using, so I could know that this type of setup works with GAL. Kind regards, Orson On 07/09/2013 06:07 AM, Alex G. wrote: On 07/08/2013 02:35 PM, Maciej Sumiński wrote: I invite you to take it for a test drive with the most complex PCBs you have. Hi Me again. This is my most complex PCB: http://g-tech.no-ip.org/~mrnuke/kicad_gal_test/vultureprog.brd It's not as impressive as your FPGA oscilloscope (I assume that's what it is), but it was able to uncover a little bug. Observe the PRELIMINARY DESIGN text on the front silkscreen. When you switch from the default rendering mode to any of the new modes, those two words display overlapped. Hope this helps, Alex ___ 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] The KiCad GAL new release
On 07/09/2013 03:08 AM, Maciej Sumiński wrote: Hi Alex, Thank you for reporting the bug, the fix is already included in the repository and your PCB file made the fixing process as easy as it could be. By the way, as you have already run some tests - would you share some thoughts? I am also quite interested in what kind of system (OS GPU, proprietary/open source drivers in case of Linux) you are using, so I could know that this type of setup works with GAL. Right now I can't seem to be able to lay tracks or do anything useful with the non-default mode. There isn't much I can test unless I lay down an actual PCB. I like the new rendering. It's much easier on the eyes, and much more (gEDA)PCB like, but with full kicad features. OpenGL with shaders is the fastest rendering mode for me. I don't like that OpenGL modes do not have antialiasing. I've tried to force my driver to do antialiasing, but does not work for pcbnew (works in the #D viewer though). Cairo made has AA, but it's extremely slow, even with my little board. I'd like to see the rendering quality of cairo with the performance of OpenGL. That would be awesome. I'm on Fedora 19 with a 9800GT under the control of the proprietary nvidia drivers. Also, I have a little issue with the way zone edges are rendered. If you look on the leftmost connector, between pins PB4 and PA5. To the left of those, the ground plane ends, but the way it is rendered gives the illusion that it shorts with the PA6 track. Does this make sense? Anyway, pretty awesome job. Oh, and the middle click to drag -- very intuitive and nice. Alex ___ 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] The KiCad GAL new release
On 07/09/2013 11:49 AM, Alex G. wrote: Right now I can't seem to be able to lay tracks or do anything useful with the non-default mode. There isn't much I can test unless I lay down an actual PCB. Yes, it is still not editable version, I should mention this in the release notes. Editing will be possible after implementation of the tool framework (http://www.ohwr.org/projects/cern-kicad/wiki/WorkPackages#5-Tool-framework), which is the next goal after the GAL. I don't like that OpenGL modes do not have antialiasing. I've tried to force my driver to do antialiasing, but does not work for pcbnew (works in the #D viewer though). Cairo made has AA, but it's extremely slow, even with my little board. I'd like to see the rendering quality of cairo with the performance of OpenGL. That would be awesome. I will put it on the to-do list, especially that I can recall having it working some time ago. And I also consider this as a nice feature to have. Also, I have a little issue with the way zone edges are rendered. If you look on the leftmost connector, between pins PB4 and PA5. To the left of those, the ground plane ends, but the way it is rendered gives the illusion that it shorts with the PA6 track. Does this make sense? In fact - not much, it is going to be fixed together with outline modes, when a single line will have a width of 1px without depending on the scale of the view. 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] The KiCad GAL new release
On 07/08/2013 02:35 PM, Maciej Sumiński wrote:
Ladies and Gentlemen,
Today you can see another release of the KiCad GAL, that can be
considered as a release candidate 1. It may still contain some bugs and
is still missing some minor features, but the main purpose of the
release is to make some tests and receive a feedback. I will be grateful
for every opinion that I receive.
The way of compilation changed a little, but now it is more like an
usual KiCad build (I removed the KICAD_GAL switch from CMake):
bzr branch lp:~cern-kicad/kicad/kicad-gal
mkdir build
cd build
cmake -DKICAD_TESTING_VERSION=ON -DCMAKE_BUILD_TYPE=RELEASE ..
make
Hi, I tried to build it, but I'm getting a bunch of errors.
First, the !WIN32 evaluated to 0, so the include dirs for cairo
evaluated to
$ENV{GTK_ROOT_DIR}/include/cairo which is just /include cairo, an
inexistent directory.
This resulted in the following error:
[...]/gal/cairo/cairo_gal.h:46:19: fatal error: cairo.h: No such file or
directory
#include cairo.h
^
I changed the !WIN32 to 1 (1), but then CMake picked up my wxGTK 2.8
installation, not the correct 2.9.4 one (I have both installed in
parallel). As you can imagine, this results in a ***load of errors. I
haven't figured out how to fix this one.
Come on guys, making CMake work is not hard. This isn't autohell. Let's
get this working out-of the box.
(1) NOT WIN32 produces the expected results.
Alex
___
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] The KiCad GAL new release
On 07/08/2013 10:15 PM, Alex G. wrote:
On 07/08/2013 02:35 PM, Maciej Sumiński wrote:
Ladies and Gentlemen,
Today you can see another release of the KiCad GAL, that can be
considered as a release candidate 1. It may still contain some bugs and
is still missing some minor features, but the main purpose of the
release is to make some tests and receive a feedback. I will be grateful
for every opinion that I receive.
The way of compilation changed a little, but now it is more like an
usual KiCad build (I removed the KICAD_GAL switch from CMake):
bzr branch lp:~cern-kicad/kicad/kicad-gal
mkdir build
cd build
cmake -DKICAD_TESTING_VERSION=ON -DCMAKE_BUILD_TYPE=RELEASE ..
make
Hi, I tried to build it, but I'm getting a bunch of errors.
First, the !WIN32 evaluated to 0, so the include dirs for cairo
evaluated to
$ENV{GTK_ROOT_DIR}/include/cairo which is just /include cairo, an
inexistent directory.
This resulted in the following error:
[...]/gal/cairo/cairo_gal.h:46:19: fatal error: cairo.h: No such file or
directory
#include cairo.h
^
I changed the !WIN32 to 1 (1), but then CMake picked up my wxGTK 2.8
installation, not the correct 2.9.4 one (I have both installed in
parallel). As you can imagine, this results in a ***load of errors. I
haven't figured out how to fix this one.
Come on guys, making CMake work is not hard. This isn't autohell. Let's
get this working out-of the box.
(1) NOT WIN32 produces the expected results.
Alex
Umh, my apologies for jumping the gun. For some reason bzr failed to
update my local branch. I was able to re-pull and it's all good now.
Alex
P.S. You all now have a green light to make fun of me :)
___
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] The KiCad GAL new release
On 07/08/2013 02:35 PM, Maciej Sumiński wrote: I invite you to take it for a test drive with the most complex PCBs you have. Hi Me again. This is my most complex PCB: http://g-tech.no-ip.org/~mrnuke/kicad_gal_test/vultureprog.brd It's not as impressive as your FPGA oscilloscope (I assume that's what it is), but it was able to uncover a little bug. Observe the PRELIMINARY DESIGN text on the front silkscreen. When you switch from the default rendering mode to any of the new modes, those two words display overlapped. Hope this helps, Alex ___ 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
