Re: [Kicad-developers] [PATH] kicad app icons spacing + better icons + kicad left tree spacing
On 09/12/2011 06:44 PM, jean-pierre charras wrote: Le 12/09/2011 18:02, fabrizio a écrit : Hello, the following patch does the following: - fix spacing between app icons in kicad right bar - several .svg icons were update (better look and coherence) - hotkey list window now has the right colour and better size (it would be good to automatically resize this window with its content but I do not know how to do it) - fix kicad left menu spacing and icon size (now 26pt) Not 100 % sure if this will create a problem for other OSs but I would propose to consider deleting the following folders: - artwork - bitmaps_xpm and maybe: - resources Regards Fabrizio PS all icons need to be rebuilt (sorry for this but when I start modifying .svg files it is not easy, for me, to be smarter than CMake) Some thoughts: 2 kicad icons ( icon_kicad.svg and icon_kicad2.svg ) are confusing. One is enough. Remove icon_kicad.svg and keep new icon_kicad2.svg is better Do not forget to rename icon_kicad2.svg to icon_kicad.svg. icon_kicad2.svg is better because it is more readable in 16x16 or 32x32 pixels formats, i.e. when this icon appears in menus or task bar. artwork is now not needed, but I am thinking it is used by MacOSX folks. So I ask for them to remove this folder and use new .svg icons. The folder artwork was created by me and can be removed, but the icns (mac icon files) in the application folders should be left alone. bitmaps_xpm contains old icons. Before removing it, the Kicad doc must be updated, and it is a lot of work. (otherwise it is not understandable if we use new icons in a stable release, and the current doc, at least for new users) An it will be updated only when new icons are stable. Maybe there is a option to fully move all the kicad documentation to wikibooks (wikipedia books) because it is more distributed and you don't need a editor except for a webbrowser. And you can create a nice PDF out of it. And is far more consisted than all those ugly word-processor templates. Just my 2uF. In Eeschema, the icon used for annotation tool is not self explanatory. Can you create a better icon ( like the netlist icon for instance) ? The icon used to add an image in Eeschema is not good (I am not clever to do icons). Can you create a better icon ? Thanks. I appreciate all your time and effort guys! ___ 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] [OSX] Zoom and Verticalscroll events triggerd on mousescroll event
Dear All, On OS X I face a problem when zooming/scrolling, because it is the same event that is triggered in kicad. Or the zooming or scrolling needs a modifier key before the operation can occur. Else it will queue zoom and scroll at the same time which is very annoying. We should have a look at: common/drawpanel.cpp: 289 void EDA_DRAW_PANEL::OnScroll( wxScrollWinEvent event ) 758 void EDA_DRAW_PANEL::OnMouseWheel( wxMouseEvent event ) I'm not sure how I get a modifier key inside the mouse/scroll events. Kind regards, Jerry ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad new look - new icons and new buttons
On 8/25/11 8:18 PM, Fred Cooke wrote: The mac native variant doesn't have them anyway. Nor do any other mac apps. Apple, love or hate them, know UI design. Looking at acrobat on linux, it uses them, but only for some items, such as copy and paste but not cut or clear, and it gives the menus an unbalanced look. If all were there it would likely look cluttered. Only the toolbar icons remain to exist. This wine/windows kicad on mac, thing that I've got has them, but they overlap the text and look awful. I already did some work on this, to remove all the menubar icons like gnome does. My vote: adios menu icons! Fred. On Thu, Aug 25, 2011 at 7:54 PM, Dick Hollenbeck d...@softplc.com mailto:d...@softplc.com wrote: On 08/24/2011 06:13 PM, Wayne Stambaugh wrote: On 8/24/2011 5:04 PM, hauptmech wrote: 16x16 was just a vote, not a demand :). Screen space is the reason. I like jerry's suggestions. I agree with him that all functionality should be in the menus, so that hiding the toolbars does not hurt functionality. Regarding icons in the menus, I think it's fine to remove them. We now have 2 votes for removing the menu images. Wayne, I am reluctant to burn the bridge, even if we stop using it. The reason I say this is because we can quite easily have multiply sized images, and there will be some image size that will not screw popup menu texts. So as a path forward, what I suggest is to strive for encapsulation, where we can control policy in a few lines of code. Get a menu utility function which makes this decision, and put a single #if #endif in there, with a build option to control that. Notice I do not have these sprinkled through the code, only a single policy point. 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
Re: [Kicad-developers] KiCad new look - new icons and new buttons
It would be much better if all the toolbar options also in the menus, eventually with (configurable) hotkeys. Then there should be a option to disable the toolbar(s) :-). Also enabling the AUI to move the toolbars to a other screen with overflow would be good to overcome the problem if one screen is to small. I was not able to get it fixed that the toolbars put the entries that overflow if it is rescaled under the overflow arrow. Hope this is clear enough. Jerry On Wed Aug 24 22:25:34 2011, Wayne Stambaugh wrote: On 8/24/2011 3:41 PM, Dick Hollenbeck wrote: On 08/24/2011 02:07 PM, Wayne Stambaugh wrote: On 8/24/2011 2:12 PM, fabrizio wrote: Hi, thanks, I am glad you like them. may I ask why you want the buttons size to stay at 16pt? is it only a matter of space? if so, how? For toolbar images, 26 or 24 pixels is fine for all platforms. On some platforms (read Windows) the larger icons will make the menu spacing much wider than the menu text (assuming your not using a 26 pixel font). Menu images are disabled by default on Linux with the latest Gnome 2 (not sure about Gnome 3) so it wont effect Linux users. If the user enables the Gnome menu images, the same problem will exist on Linux. I'm not an OSX user so I cannot comment on how the larger menu images will look. I could personally live without images in the menu bar. I would prefer to use the space taken by the image for more descriptive menu text but I'm sure there are plenty of folks who would disagree with me on that one. Wayne Guys, I committed to write an automation script which generates all the bitmaps from *.svg to *.cpp. I believe it will be possible to parameterize the target image size(s). I am now only waiting for the *.svg s. This *.svg - *.cpp automation is to live outside the normal Kicad build process. However, it can be done twice, or three times, resulting in multiply sized PNG containing *.cpp directories. Each of these directories can be checked into the source tree. Then, the master CMakeList.txt file for the Kicad project can dynamically pick which one gets chosen, based on a parameterized *.cpp containing directory name. I won't take it that far, only to the point of having parameterized build automation, with a specific view to reward Fabrizio for his efforts, meaning I intend to honor whatever bitmap size he wants, as payment for his efforts. Others can cater to the hobbyist computers, later. This infra-structure will at that point be easy to extend, but I personally will not have time for that 2nd stage effort. 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 Dick, I appreciate your and Fabrizio's efforts on this and think the new images will give the Kicad user interface a much needed face lift. I was merely pointing out the potential pitfalls of using the larger images in the menu bar. I was hoping someone would take my hint and suggest removing the images from the menu bar altogether. I would be willing to do this if we can get a consensus among the Kicad users and developers. As it currently stands, they are only displayed on Windows by default. Wayne ___ 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] KiCad new look - new icons and new buttons
On Tue Aug 23 08:14:26 2011, Dick Hollenbeck wrote: On 08/23/2011 01:05 AM, Dick Hollenbeck wrote: On 08/23/2011 01:02 AM, Dick Hollenbeck wrote: http://docs.wxwidgets.org/stable/wx_wxbitmap.html says PNG format is not supported on Windows version of wxWidgets, but I would not walk away without consulting the sources. More below. PNG can be in the flow of information as an intermediate (man in the middle) technology. But I would like to treat it as almost a *.o file in a build process. Our real source file should be the *.svg file. So I would like to see us find a cross platform tool, and I think you have found that already, which can be run from the command line to build the *.png files from the *.svg files. I propose that we agree never to post edit the PNG files, and that they must come from the *.SVG files. I suggest we have a separate CMakeLists.txt file to build the *.PNG files from the *.SVG files automatically, but perhaps not make it a mandatory part of the build process, on the theory that some builders will not want to have the tool which converts from *.SVG to *.PNG installed. *.SVG - *.PNG Therefore this means distributing both the *.PNG and the *.SVG files as part of the source tree. That is, unless you want to burden every builder with the need to have this tool installed. Then we have to decide on how to load the PNG files into the programs, and there seem to be at least two ways to do this: A) read the *.PNG files into memory from disk at program start time. B) convert the *.PNG files into a BYTE array which is compiled into the respective program. But the byte array is definitely a PNG format, meaning we get the advantage of the alpha channel support, which we do not currently have. If B) is the chosen path. This entails yet another step that we need to add to the build path, meaning it needs to go into a CMakeLists.txt file and needs to be able to happen from a commandline tool. *.PNG - *.cpp http://www.libpng.org/pub/png/book/chapter09.html Although we are going with larger ICONs, I believe there may be no real memory penalty since the PNG byte array is essentially be the PNG file in RAM, and it is in a compressed format already. So I think sticking with a BYTE array is the best path, because it will lead to faster loading and we can continue to maintain the bitmap collection as a library, and applications can continue to link against that. I'm just proposing that we put some of the build paths into a well documented CMakeLists.txt file, one that does not necessarily run all the time as part of the normal compilation process. And if you are really paying attention, you recognize that the byte array containing *.cpp files for the bitmaps would also need to be distributed as part of the source tree also. A reasonable tool to convert the *.PNG files into *.CPP is a cmake script itself. In doing so, it can also write code to generate a global wxBitmap from the filename of the PNG file. The cmake script can be chain loaded from a CMakeLists.txt file which builds the bitmap library. So I rescind my proposition that the *.cpp files must be distributed as part of the source tree. They can be generated by a *.cmake script. I totaly agree with building the png's by CMake out of the svg's. It saves alot of pain in the end. Maybe a better approach is that the png's are shipped with kicad as resources and load at runtime. Maybe we should have a look at the wxwidgets examples and http://zetcode.com/tutorials/wxwidgetstutorial/menustoolbars which uses the wxBitmap with PNG. Kind regards, Jerry ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad new look - new icons and new buttons
On Mon Aug 22 21:10:00 2011, fabrizio wrote: Dear All, I have spent some time trying to put together a new set of icons and buttons that might make KiCad look a little better. Here you have an example of where I am so far: http://www.vincentresearch.com/tmp/ Would it be possible: - to know if there is anybody interested in helping me out I'm willing to help, i'm very experienced with inkscape. - to know if there is anybody willing to help me to modify the current code in order to accommodate the new icons/buttons. The only code we need to change is to move it to PNG, because no vectorial format is supported (as far as I know). - to have the .svg files (or some equivalent vectorial format) of the current buttons set - I do not want to try to undo anything that somebody has done so far and for this it would be great to have some feedback on the current status and some opinions on where I am heading. I'd like to propose to use PNG format for all icons and buttons and 64px for the KiCad buttons to start the 6 current programs. Also I'd like to propose to drop the 16pt buttons used everywhere for a larger 24px buttons. That includes top bar buttons as well as lateral (left and right bars). How does it sound? I did put some svg rework in the artwork in the sourcetree of the main applications. Mainly I did it for use with Mac OS X because 32x32 was way to small for most purposes. See here: http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/files/head:/artwork Kind regards, Jerry Best regards Fabrizio ___ 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] New utility: PcbCalculator
Maybe you should have a look at http://mcalc.sourceforge.net and http://wcalc.sourceforge.net also. On 05/08/2011 22:02, jean-pierre charras wrote: I added a new utility in Kicad: PcbCalculator It can be used to calculate transmission lines impedances, or resistors to set the value of the output of a regulator. Please, feel free to add features to this utility (It is not a finished work, but is it very usable). This is easy because the code do not use the existing Kicad code, so no need to know the internal Kicad code. And I need your opinion about the interest of this kind of tool. ___ 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] Mac OS X Performance Questions
Hello Fred, There are not so many people (yet) which run KiCad on Mac OS X, I build it regular and also with latest development version of wxWidgets. The underlaying graphics layer is not the most efficient/fastest in kicad. The scrolling/zooming with the touchpad on the macbook zooms and scrolls at the same time and needs to be fixed. More testing is needed on OS X but there is only a small group of users and developers on this platform. Kind regards, Jerry On 7/15/11 3:39 PM, Fred Cooke wrote: Hello All, A few weeks ago I tried KiCad on OS X and although eeschema appeared to work OK, pcbnew was unusably slow (0.3fps scrolling or zooming in 2d, 3d, which I just, tried is acceptable). I assume that you're already aware of this, and as such I have the following questions: Is the cause known? If not, is it being looked for? If so, is it being worked on? If so, estimated date of completion? If my assumption about this being a known issue was wrong, can I do something to provide feedback more formally? Thank you for your time! Regards, Fred. ___ 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] FindwxWidgets.cmake
On 4/5/11 3:44 PM, Wayne Stambaugh wrote: We currently use a custom(?) version of FindwxWidgets.cmake that was cherry picked from a more current version of CMake than we were using at the time. The problem is our version of FindwxWidgets is suffering from bit rot. The version in CMake 2.8.4 ( and possibly earlier ) has some enhances that make it more usable when you have multiple versions wxWidgets installed on your system. I would like to remove our local version of FindwxWidgets.cmake and use the one that ships with CMake. Does anyone have any objections or reasons not to do this? This sounds more elegant than our current solution, CMake 2.8 is not hard to install even if it doesn't exist on a system. Also from sourcecode (which I did a couple of times). Jerry ___ 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] bzr rev 2945 commit: a file change breaks Kicad
On 4/4/11 9:41 PM, jean-pierre charras wrote: Jerry, Your last change in rev 2945 in file: common/hotkeys_basic.cpp breaks Kicad. The reason is when a key is added in a menu, with a \t before it, it become a shortcut. Therefore type is key is exactly equivalent to click on this menu, and this key is no more sent to the kicad key handler.. I don't know for sure, but for me on OS X all the Placement hotkeys which I tested (in EESchema) works as expected. With wxWidgets 2.9.2 svn. And don't break the hotkey internals, correct me if I'm wrong. This break Kicad, because many hotkeys does not the same thing as you are click on menus. Mainly because hot keys use current mouse cursor position (start a wire, zoom, ...) and obviously this is not possible when clicking on a menu. This is true for menus in frame menu bar, not pop up menus, because they are not active. So in many cases keys added in menus in the menu bar are only comments, not shortcuts. This bad comments break the Mac UI policy and are a bit ugly compared to the defaults. Please, unless you known (with wxWidgets) how to see the difference between click on a menu and click on the corresponding hotkey, (I do not know how to do that, and if this is possible, because the same event is sent, perhaps try to use wxEvent::GetEventType() to do that, but this needs a lot of changes), go back to the previous version of common/hotkeys_basic.cpp. Aesthetic reason to this change is not a good reason, if this change breaks the previous behavior. Currently, most of hotkeys are not working properly. It is no problem to revert back to the previous version of this file. ___ 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] bzr rev 2945 commit: a file change breaks Kicad
On 4/4/11 10:43 PM, Wayne Stambaugh wrote: On 4/4/2011 3:51 PM, Jerry Jacobs wrote: On 4/4/11 9:41 PM, jean-pierre charras wrote: Jerry, Your last change in rev 2945 in file: common/hotkeys_basic.cpp breaks Kicad. The reason is when a key is added in a menu, with a \t before it, it become a shortcut. Therefore type is key is exactly equivalent to click on this menu, and this key is no more sent to the kicad key handler.. I don't know for sure, but for me on OS X all the Placement hotkeys which I tested (in EESchema) works as expected. With wxWidgets 2.9.2 svn. And don't break the hotkey internals, correct me if I'm wrong. Jerry, It is important understand that hot keys are not the same as menu or tool bar short cuts. The menu and tool bar commands require an extra left mouse click to create the object associated with the current tool. Hot keys on the other hand, create the object immediately at the current cursor position. While your change may work, it had to change the behavior of the hot key. Your change would have remapped the hot key to the equivalent place menu command. This break Kicad, because many hotkeys does not the same thing as you are click on menus. Mainly because hot keys use current mouse cursor position (start a wire, zoom, ...) and obviously this is not possible when clicking on a menu. This is true for menus in frame menu bar, not pop up menus, because they are not active. So in many cases keys added in menus in the menu bar are only comments, not shortcuts. This bad comments break the Mac UI policy and are a bit ugly compared to the defaults. I do agree with you assessment about the comments. Not as much from a UI policy standpoint as from a behavior standpoint. Pressing the W key to begin drawing a wire is not the same as selecting the wire tool and left clicking to begin drawing a wire. They are not the same thing so adding the comment is confusing. Please, unless you known (with wxWidgets) how to see the difference between click on a menu and click on the corresponding hotkey, (I do not know how to do that, and if this is possible, because the same event is sent, perhaps try to use wxEvent::GetEventType() to do that, but this needs a lot of changes), go back to the previous version of common/hotkeys_basic.cpp. Aesthetic reason to this change is not a good reason, if this change breaks the previous behavior. Currently, most of hotkeys are not working properly. It is no problem to revert back to the previous version of this file. If that is what you are going to do, please let me know as I have a commit ready to submit. I hold off until I hear otherwise. I would love to uncommit the change on common/hotkeys_basic.cpp but still the devil hides behind Bazaar. @Wayne, maybe you could revert this file to the state of rev 2944 which doesn't break. Then the commits can carry on. Still I'm trying to learn the bzr way of doing SCM, sorry guys! Wayne ___ 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] Line drawing problem under OS X
Dear all, I figured out that kicad under OS X has problems with hairline drawing not only with the sheet frame. Also with the hairline width text in gerbview DCode circles and the sketch mode in pcbnew. I tried digging in the sourcecode for the penwidth but did not yet figured out where I need to change to make it work. Kind regards, Jerry Jacobs ___ 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] pcbnew --plot=gerber bug and workaround (was Re: first mail, introducing command line options for eeschema and pcbnew)
The stange extensions refer to the layer that is plotted to gerber. Look at http://wiki.altium.com/display/ADOH/Gerber+Output+Options The names are aliases for the corresponding layers: gbl = Gerber bottom layer (solder) gbs = Gerber bottom silkscreen (mask) gto = Gerber top overlay gbr = Gerber (generic) gts = Gerber top silkscreen (mask) gtp = Gerber top layer (solder) Correct me if I'm wrong. On 02/19/2011 03:36 PM, Werner Almesberger wrote: Wolfgang Spraul wrote: -p, --plot=str plots the board [hpgl|gerber|ps|ps_a4|dxf] -l, --layers=str comma separated list of layer names (default: all enabled layers) I'm getting a bit of strangeness with the automatic layer selection and pcbnew --plot=gerber: When I plot my atben project [1] manually from pcbnew, the Gerber files are named atben-Back.gbl atben-Comments.gbr atben-Front.gtl atben-Mask_Back.gbsatben-Mask_Front.gts atben-PCB_Edges.gbr atben-SilkS_Front.gto atben-SoldP_Front.gtp I never investigated what the last letter in the extension meant, but the second one seem to consistently indicate front (top) or back. Now, with pcbnew --plot=gerber --fill-all-zones -l I get these strange extensions: atben-Back.gbr atben-Comments.gbr atben-Front.gba atben-Mask_Back.gtsatben-Mask_Front.gbr atben-PCB_Edges.gbr atben-SilkS_Front.gbs atben-SoldP_Front.gbo If I specify the layers explicitly with -l, I get the normal result again: pcbnew --plot=gerber \ -l `pcbnew --list-layers atben.brd | tr '\012' ,` \ --fill-all-zones atben.brd atben-Back.gbl atben-Comments.gbr atben-Front.gtl atben-Mask_Back.gbsatben-Mask_Front.gts atben-PCB_Edges.gbr atben-SilkS_Front.gto atben-SoldP_Front.gtp If the default worked too, this already wonderful defense against unpleasant surprises would be even less surprising :) [1] http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/atben Thanks, - Werner ___ 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] Sourceforge Wiki Broken
On 02/14/2011 01:40 PM, Dick Hollenbeck wrote: On 02/14/2011 04:07 AM, Jerry Jacobs wrote: Dear all, When I try to load the sourceforge wiki/site then it only shows a white empty page. I think it is broken since the new update of sourceforge services. Maybe we need to update mediawiki :-), this is more secure and has better features. Kind regards, Jerry Jacobs I think I can grant sourceforge ADMIN privileges to any volunteer that wants to be a wiki maintainer, or administrator. I would like to be a administrator to make it more usable and keep it up-to-date if you agree with it. Certainly I will have no time to maintain the wiki myself, so others will have to decide how that is to be done. This is no problem as you already offer some time on other things :-) ___ 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] More OSX developer help
On 02/11/2011 03:42 PM, Wayne Stambaugh wrote: Jerry, Thanks for testing this out for me. Now the grid draws as expected, there are still some issues left on OSX for the drawing code: - When moving a object you can't see where it is while moving Which application? EESchema, PCBNew or all of them? EESchema works just fine, with PCBNew it is broken. - The pen-width of the sheetframe is very thin (almost invisible) This one is odd. On Windows and Linux the sheet frame line width looks fine. Marco Serantoni tried to fix this some long time ago which is not upstream. - The outline modes in pcbnew are broken I'll take a look a these issues when I get a chance to see if I figure out what is wrong. Thank you. Thank you for fixing this, i have the feeling that the drawing code is a bit faster than before. This is good because it will still take some time to move to the GAL. It should be faster due the the number of intermediate function calls that have been eliminated. Hopefully, the drawing code is cleaned up enough that when we finally get around to implementing the GAL code it will be a much more manageable task. Better make it clean and easy to understand than hacking new features in and make a mess again. When I find some time I try to integrate some more Mac features so it will feel real native. I'm still struggling to find out how I can catch CMD+W for closing every window. The CMD key is the apple key to almost all shortcuts. On linux and windows this is the Ctrl key. I like to use the keyboard shortcuts but still kicad lacks the window closing hotkey. ___ 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] OSX developer help.
On 2/8/11 11:29 PM, Dick Hollenbeck wrote: On 02/08/2011 03:46 PM, Wayne Stambaugh wrote: On 2/8/2011 4:27 PM, Dick Hollenbeck wrote: On 02/08/2011 01:15 PM, Wayne Stambaugh wrote: I just committed (r2800) a fix for a rendering bug in the optional drawing modes in GerbView that I caused when I removed the old scaling code. I have it working on Linux and Windows. I need one an OSX developer to verify this works on OSX. Load a couple of layers (preferably at least one negative layer) and select the two optional rendering modes on the left vertical tool bar to make sure there are no rendering errors. Zoom in and out and scroll around a few times just to be sure there is no unexpected behavior. You may get an assertion on debug builds when zooming all the way out due to an invalid wxBitmap. It only happens on Linux so it may or may not be an issue on OSX. There's no hurry, I just want to make sure I have caused any other issues. Thanks in advance for the help. It seems not to work very bad, only the pads and tracks in outline mode goes to no display at all. There is no outline drawn then. Maybe Marco Serantoni should test also if his time permits. I only build in non-debug mode most of the time. Wayne How do we repay this guy? Open source is so un-fair. Wayne deserves both his own Mac, and his own Mac terminal driver, which is you sitting at the keyboard helping him. :) He can hold my mac for a few secs ! Thanks, but I'll pass on having my own Mac. Two OSes are more than my poor brain can handle. :) You guys just dream to have a Mac to do more usefull things :-) I knew you'd say that, that's why I said you deserve your own terminal driver also. That's like having both a car and a driver at your disposal. Except in this case the driver takes the car home with him. So it just feels like you have your own Mac. You only love the fat pinguin right? ;-) 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] [PATCH] Saving plot dialog settings
For me the dialog is very very good, and works as expected. Still the issue remains that the dialog can't be closed with the window button and the cancel button. I hacked a class function DIALOG_PLOT_BASE::OnQuit with EndModal(0); and it worked. Maybe the virtual functions need be implemented? I saw also the eeschema postscript dialog is derived from the wxFormBuilder base class and there are the virtual functions implemented and have not problem with this. Sorry, but I'm not to got yet with C++ so don't blame my bad thinking. Jerry On 2/2/11 8:26 AM, jean-pierre charras wrote: Le 02/02/2011 00:15, Marco Mattila a écrit : Now there should be a little something for everyone in the latest revision. It was possible to make the plot dialog a little smaller by getting rid of the radio buttons and moving the output directory field (although I'm not sure it's in the right place now...). I also agree that the dialog is a bit too square. It's hard to make the height smaller. And it doesn't make sense to make the window wider than necessary. I can later take a look at how using wxCheckListBox affects the layout. Wayne, you did mean that widthheight, right? Jerry asked about saving the outputdirectory in the board file. That's the way it has been for a few revisions already. marco Plot dialog looks good! Is the dialog is a bit too square ? Remember it size depend on platform: You cannot have *exactly* the right size, because the actual size of a dialog depend on system settings and the system itself (Language, font size, how widgets are drawn by the window manager...) ___ 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] Rev 2784 broken
My build fails with: In file included from /Users/jerry/Projects/kicad/testing/include/wxBasePcbFrame.h:14, from /Users/jerry/Projects/kicad/testing/include/pcbstruct.h:43, from /Users/jerry/Projects/kicad/testing/3d-viewer/3d_viewer.h:24, from /Users/jerry/Projects/kicad/testing/3d-viewer/3d_aux.cpp:22: /Users/jerry/Projects/kicad/testing/include/richio.h: In member function ‘std::string OUTPUTFORMATTER::Quoted(const wxString)’: /Users/jerry/Projects/kicad/testing/include/richio.h:508: error: call of overloaded ‘Quoted(const char*)’ is ambiguous /Users/jerry/Projects/kicad/testing/include/richio.h:503: note: candidates are: virtual std::string OUTPUTFORMATTER::Quoted(const std::string) /Users/jerry/Projects/kicad/testing/include/richio.h:505: note: std::string OUTPUTFORMATTER::Quoted(const wxString) make[2]: *** [3d-viewer/CMakeFiles/3d-viewer.dir/3d_aux.cpp.o] Error 1 make[1]: *** [3d-viewer/CMakeFiles/3d-viewer.dir/all] Error 2 make: *** [all] Error 2 I saw Dick changed some of this code and now the OS X build is broken with wxWidgets 2.9.2 svn Regards, Jerry Jacobs ___ 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] Rev 2784 broken
On 2/2/11 8:50 PM, Dick Hollenbeck wrote: make: *** [all] Error 2 I saw Dick changed some of this code and now the OS X build is broken with wxWidgets 2.9.2 svn Regards, Jerry Jacobs $ wx-config --list Default config is gtk2-unicode-release-2.8 Default config will be used for output Alternate matches: base-unicode-debug-2.8 base-unicode-release-2.8 == Jerry, Every so often this is going to pop up as long as you continue to use the 8 bit wxString. I don't mind it if you don't. It is a result of wxString() honoring a constructor in one mode that it does not in another build mode. Jean-Pierre says we should only support UNICODE mode. I do not agree with him on that subject, mostly because the default build mode of wxWidgets 2.9.x on Linux is UTF8 encoded 8 bit mode, and this is a new schmancy mode other than ANSI mode, and other than UNICODE mode. We definitely need as many wxString build modes as we they can think of. Someone once said that hindsight is 20/20, but here I doubt that. Another 6 or 8 wxString modes would be even better :) If you can occasionally ring this bell, and not get frustrated, we will always be able to work through it. I note that this is the 2nd time this month you've had to ring the bell. Again, I don't mind if you don't. Dick white:~ jerry$ wx-config --list Default config is osx_cocoa-unicode-static-2.9 Don't scream to soon that it is a compiler problem... maybe it is a real wxWidgets problem (again), and we have to poke the people at wx maybe? I only build in Unicode mode. Thanks, Jerry ___ 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] Saving plot dialog settings
Hello Marco, I like it but it has still some issues with wxWidgets on Mac with version 2.9.2 from svn (rev 66766). I put a screenshot on my server over here: http://kicad.xor-gate.org/screenshots/new-plot-screen-issues.png The issues are the format frame, and the gerber options entries labels overlap. Also I can't close the window with the exit button on the window border, and the same goes for the close button. So I have to kill pcbnew to quit the application. A suggestion would also be to display the cwd in the Output directory line if the user opens the dialog, and maybe this output directory can be saved/loaded from the pcbfile/project. On 2/1/11 7:10 AM, jean-pierre charras wrote: Le 31/01/2011 21:55, Marco Mattila a écrit : Jean-Pierre, I have yet another suggestion for the layout of the plot dialog (see attachment). The width would be the same as in your recent patch, but the height would be smaller. What do you think? marco I like it! ___ 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] Interesting idea to make money with open-source
Dear all, I bumped on a very nice article which can also be used in the KiCad project. Or any other open-source project. http://fsmsh.com/3439 Kind regards, Jerry Jacobs ___ 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] eeschema object selection and block commands
On 09/14/2010 08:42 PM, Wayne Stambaugh wrote: On 9/14/2010 7:28 AM, Lorenzo wrote: Dear developers, I'm an electronic developer and I found in the Kicad project an extremely interesting EDA suite. Even it is obvious that (in this moment) it cannot compete in productivity with most important EDA systems (e.g. Altium, OrCAD, PADS...), it is growing fast and it has the power to be used in production environments proportionally to its growth. It is probably the only industrial EDA application that is multi-platform, open source, and released in a stable version. It's about two years I'm trying to give my small contribute to this project; we had a discussion about additional features some time ago, and I was probably too enthusiast to identify and imagine a proper implementation work flow for my ideas. The first time I saw the code I was discouraged not only by the lack of comments and the French language used to write the application, but also by the dirty folder structure, file names, and function positions. This is pretty changed now, and the code looks generally better. *** SNIPPED OUT SOME STUFF *** Hope to “hear” from you what you think about that. Hi Lorenzo, I would also thank you for you time and effort you put in KiCad to improve it. Especially because you also use it at work and normal at work there is not much time to fix things. The code is improved very much compared from two years ago. When I joined KiCad as a translator. Since then there are many good new features and enhancements added. Maybe nice to know that I give a 50 minutes talk at a Tdose in The Netherlands again. Almost the same as previous year which you can still look on a recorded movie. http://kicad.sourceforge.net/wiki/index.php/Press Jerry Jacobs ___ 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] OSX Installer debate
On 09/13/2010 05:01 PM, Martijn Kuipers wrote: On Sep 13, 2010, at 15:20 PM, Dick Hollenbeck wrote: On 09/13/2010 08:53 AM, Martijn Kuipers wrote: How do we want the OSX packages to look like (installer) ? At the moment we have a DMG-generated from scripts and one generated with CPack (I patched my CMakeList.txt with the patch from Jerry floating around on the list). Neither are satisfactory, in my opinion. Let me explain: If we add docs and libraries to the DMG file, then it is no longer DragDrop. Normally you drag the application (on our case the Kicad folder with all applications) to the Applications link, which are both shown by the installer in the finder. However, if we also include libraries in the DMG, then these need to be installed in /Library/Application Support/kicad or in $HOME/Library/Application Support/kicad (according to Marco). We don't want the user to drag them into the applications. I see 2 posible solutions: 1. Use packagemanager, which allows more complex installs. Disadvantage is that you have no clue what is installed where and since there is no uninstall I think it's rather messy. 2. Split the libraries and applications in separate DMGs. I personally like this option, since it allows you to easily update either Kicad or the Libraries. Not sure what to do with docs. Can we put them in a sub-folder in the Kicad folder under applications? Same with scripts ? I would love to hear your opinions on this. /Martijn There are two classes of users: 1) those that install from a pre-built package. 2) those that install by building the source themselves. In the linux world there is a package manager person for each distro, and he is responsible for users in class 1) on his distro. So I actually think you should be talking to those people for that category of user. Sure. For Kicad who is the OSX package manager? I hope (s)he is reading this list. As for Linux, I think Kicad ought to provide a static-version (should fit most distros). Of course, if someone wants to add deb, rpm, etc., then that is fine with me, it is just more work because of the version dependancies between the different components. Wrapping a static-package inside deb or rpm is not a good solution (my personal opinion). There is no official OSX package manager (yet). Marco Serantoni did a good job to add some work to the kicad code-base for compiling and packing it. Then after some time I decided to also buy a macbook for personal reason and wrote some documentation about compiling and tried to improve it together with Marco. Also there are still some odd things when using Kicad on OSX for example the viewport is damn slow of PCBnew. But it is usable and functional. For category 2) users, I see no reason why cmake and/or one of its sibling programs cannot be used. This makes it easier for those of use that do not use OSx to stay in the conversation. I don't object to cmake at all. I think the DMG is not as nice as it could be, but I have not spend much time looking at all the options CPack gives you. If there is an area where Win/Linux/OSX can be different, it is in the installers. And my questions were solely related to the OSX installer, where I don't think the split I mentioned is so different from what we have now. I don't think there are libraries included in the kicad source, they are in kicad-lib-committers/kicad/library. The DragNDrop is preferred for applications. And a installer or a lose package with symbols/footprints/3d modules and documentation is shipped seperated. The odd on OSX is that if you did ran a installer and it dumps all the files and folders somewhere that there is no uninstaller like under linux package managers or windows installers. But the installer can be made smart so it will remove old folder of a previous install. My suggestion would be to create 2 installers; - Kicad application - Libraries (with Libraries I mean eeschema components, footprints, packages3d and modules). The name is confusing, but I did not mean things like wxWidgets, Boost, etc. For me this idea is good enough, we should not forget the Mac UI/Packaging guidelines else it will be different from other macified software! I am a User 1 type, if I can find a recent enough version, otherwise I am User 2. But even as User 2 I prefer to create packages and then install those. As Kicad is getting more users and some people who write patches/join the mailing list it is better that there will be a official Mac OS X group within Kicad. This because things are very different on a Apple machine than on a PC (*Win, *NIX) with user interface. ___ 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] OSX Installer debate
On 13-09-10 20:18, Dick Hollenbeck wrote: Is there a way to run OSx on a virtual machine on Ubuntu? If not, then I'm afraid I cannot be part of the Mac group, until somebody buys me a Mac. I saw a guy at school past week running OS X in a virtual machine. After surfing google about installing OS X 10.6 in virtualbox I found some very nice pages, still you need a Snow Leopard install DVD and test it for yourself. It should not be that hard to get it working as more people want to run it on normal hardware under a virtual machine. 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
Re: [Kicad-developers] Menu item images on OSX
On 25-08-10 21:55, Wayne Stambaugh wrote: On 8/25/2010 11:21 AM, Jerry Jacobs wrote: On 08/24/2010 08:50 PM, Wayne Stambaugh wrote: During my resent journey though the Kicad source I notice quite a few instances of the following in the menu creation code: #if !defined( __WXMAC__ ) item-SetBitmap( save_project_xpm ); #endif /* !defined( __WXMAC__ ) */ Yes this is far from optimal and the better solution is to have a option to hide the icons in the menubars with a setting for all apps. I was primarily thinking about the readability of the code rather than user preference. Not that the user preference isn't important. I think compiling for the intended platform makes sense in this case. I also don't have the time to commit to as user selectable solution at this time. Creating a simple macro that expands to nothing on OSX builds is something I can knock out in an hour or two. Is there a specific reason why images should be excluded or included from Mac menu items? The problem is there doesn't seem to be any consistency in it's use.On some of the applications it's used on almost all of the menu items (Kicad) and some applications virtually none at all (EESchema). In any event this screams creating a macro that expands to nothing on Mac builds to rid of all of the #if/#endif statements. Any insight from the OSX folks would be appreciated. http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGMenus/XHIGMenus.html Here you can see the Apple UI guidelines for menus. I'm only a OS X user for just about a year now and find that kicad eda the only application is that has imho to many icons in the menubar on OS X. All the other applications that run on my apple machine don't have any menubar icons or maybe a few. Some people prefer to have icons and some people don't like me. And then the best of both world would be disabling it by default and if people prefer they can set a checkbox in the preferences. If menu images are not used in OSX menu entries, than it makes sense to at least be consistent in all of the Kicad applications and not use them on OSX builds. I'll take a look at the OSX UI Guidelines to see if it mentions images in menu entries specifically and use that as my guide. Also thunderbird doesn't have any menu icons I just figured out. Jerry Jacobs ___ 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] Compiling fails on XML class on Apple OS X with wxWidgets 2.9-svn
Dear all, I tried compiling the latest revision of wxWidget and KiCad on my Macbook with Apple OS X and it failed on the XML library that Dick is using now. I recompiled again and the option to enable the XML library is the --enable-expat but still it fails. The weird thing is that there are some function symbols in the static monolithic library in the wxXmlDocument class. So that means it is enabled. Below there is my wxWidgets configuration of configure and the error I get during linking. Maybe some people have suggestions or ideas. The point is I want to test the latest stuff and need to compile it myself then. Kind regards, Jerry Jacobs - http://www.xor-gate.org ./configure --enable-unicode=yes --enable-shared=no --enable-monolithic --with-opengl --enable-universal_binary --enable-aui --enable-debug --with-osx_cocoa --with-macosx-sdk=/Developer/SDKs/MacOSX10.5.sdk/ --prefix=/opt/wxwidgets/rev-65251 --enable-expat Linking CXX executable eeschema.app/Contents/MacOS/eeschema Undefined symbols: _XML_SetCharacterDataHandler, referenced from: wxXmlDocument::Load(wxInputStream, wxString const, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o) _XML_SetCommentHandler, referenced from: wxXmlDocument::Load(wxInputStream, wxString const, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o) _XML_SetCdataSectionHandler, referenced from: wxXmlDocument::Load(wxInputStream, wxString const, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o) _XML_SetUserData, referenced from: wxXmlDocument::Load(wxInputStream, wxString const, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o) _XML_ParserFree, referenced from: wxXmlDocument::Load(wxInputStream, wxString const, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o) _XML_ParserCreate, referenced from: wxXmlDocument::Load(wxInputStream, wxString const, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o) _XML_SetElementHandler, referenced from: wxXmlDocument::Load(wxInputStream, wxString const, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o) _XML_SetUnknownEncodingHandler, referenced from: wxXmlDocument::Load(wxInputStream, wxString const, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o) _XML_GetErrorCode, referenced from: wxXmlDocument::Load(wxInputStream, wxString const, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o) _XML_SetDefaultHandler, referenced from: wxXmlDocument::Load(wxInputStream, wxString const, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o) _XML_Parse, referenced from: wxXmlDocument::Load(wxInputStream, wxString const, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o) _XML_GetCurrentLineNumber, referenced from: _StartCdataHnd in libwx_osx_cocoau-2.9.a(monolib_xml.o) wxXmlDocument::Load(wxInputStream, wxString const, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o) _CommentHnd in libwx_osx_cocoau-2.9.a(monolib_xml.o) _TextHnd in libwx_osx_cocoau-2.9.a(monolib_xml.o) _StartElementHnd in libwx_osx_cocoau-2.9.a(monolib_xml.o) _XML_ErrorString, referenced from: wxXmlDocument::Load(wxInputStream, wxString const, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [eeschema/eeschema.app/Contents/MacOS/eeschema] Error 1 make[1]: *** [eeschema/CMakeFiles/eeschema.dir/all] Error 2 make: *** [all] Error 2 ___ 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] pcbnew module editor toolbar items now in menubar -- patch
On 21-07-10 14:38, Dick Hollenbeck wrote: On 07/21/2010 02:52 AM, Jerry Jacobs wrote: See the attached patch, it applies to rev 2418 without problems. For future patch attachments, can you keep your email client from base64 encoding these attachments? Thanks. This way we can see the patch without saving it to disk first. No need to resend this one, just tweak your settings please, if you can. The email content includes: === Kind Regards, Met vriendelijke groet, Jerry Jacobs - http://www.xor-gate.org --00151750e3b8a1e816048be1142d Content-Type: application/octet-stream; name=pcbnew_module_editor_extended_menubar.patch Content-Disposition: attachment; filename=pcbnew_module_editor_extended_menubar.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_gbvvjf330 PT09IG1vZGlmaWVkIGZpbGUgJ3BjYm5ldy9tZW51YmFyX21vZGVkaXQuY3BwJwotLS0gcGNibmV3 L21lbnViYXJfbW9kZWRpdC5jcHAJMjAxMC0wNC0yMCAxMToyMzo1OSArMDAwMAorKysgcGNibmV3 : : --00151750e3b8a1e816048be1142d Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline This seems a problem with the webclient from gmail. I hope thunderbird does it well or maybe you guys have a hint to make it work the way you want to receive it in the mailing list. ___ 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] CPack integration for crossplatform creation of binary and source archives -- patch
Dear all,
As I was trying to find a neat way to create mac packages on the fly I
bumped to CPack. This application is shipped with CMake and can be used
inside the existing CMakeLists.txt configuration. For mac I enabled for
now only DragNDrop packages which are like zip archives instead of
full-fledged PackageMaker installers. The most neat thing is it creates
the archives by itself without using any external script or utility.
Then the packaging/mac-osx/dmg-generator directory can be removed from
the source-tree if this patch is applied.
If you look deeper at CPack or CMake CPack module it also integrates
generation of NSIS installer for windows and self-extracting shell
script for *NIX. This takes us a whole bunch of work from our hands if
other people want to do snapshots/nightly builds or actual releasing the
software.
A console output on my mac when creating source archives (make sure you
do a out of source build or else all the CMake cache stuff will also be
in the source archive!)
white:darwin jerry$ sudo make package_source
Run CPack packaging tool for source...
CPack: Create package using TGZ
CPack: Install projects
CPack: - Install directory: /Users/jerry/Work/kicad/repository
CPack: Compress package
CPack: Finalize package
CPack: Package
/Users/jerry/Work/kicad/build/darwin/kicad-2010.07.23-Source.tar.gz
generated.
When creating binary package(s) which can be selected with the
CPACK_GENERATOR variable they can be build with the *make package* command.
For more information see cmake --help-module CPack
I attached the main CMakeLists.txt patch. Only maybe other people have
a suggestion to extract the date from BZR or system when building
instead of changing the 3 variables BUILD_ YEAR, MONTH, DAY.
Kind regards,
Jerry Jacobs
=== modified file 'CMakeLists.txt'
--- CMakeLists.txt 2010-06-13 04:10:16 +
+++ CMakeLists.txt 2010-07-23 16:45:09 +
@@ -1,5 +1,11 @@
project(kicad)
+# Set build date for automated builds and packages
+# This needs to be done in a automatic way some day
+set(BUILD_YEAR 2010)
+set(BUILD_MONTH 07)
+set(BUILD_DAY 23)
+
# test the minimum Cmake version requirement (could be different under unix or
Windows
if(WIN32)
cmake_minimum_required(VERSION 2.6.4 FATAL_ERROR)
@@ -263,4 +269,32 @@
PATTERN .svn EXCLUDE)
endif(UNIX)
+###
+# Package binarie and source builds with CPack
+# for help about this variables see cmake --help-module CPack
+###
+
+# Set package resource files
+set(CPACK_RESOURCE_FILE_LICENSE ${CMAKE_SOURCE_DIR}/COPYRIGHT.txt)
+set(CPACK_RESOURCE_FILE_README ${CMAKE_SOURCE_DIR}/README.txt)
+set(CPACK_RESOURCE_FILE_WELCOME ${CMAKE_SOURCE_DIR}/README.txt)
+
+# Exclude files when building the Source package
+set(CPACK_SOURCE_IGNORE_FILES /.bzr/;/.swp/)
+
+# Set package version
+set(CPACK_PACKAGE_VERSION_MAJOR ${BUILD_YEAR})
+set(CPACK_PACKAGE_VERSION_MINOR ${BUILD_MONTH})
+set(CPACK_PACKAGE_VERSION_PATCH ${BUILD_DAY})
+
+# Set APPLE configuration for CPack usage
+if(APPLE)
+ set(CPACK_DMG_FORMAT UDBZ)
+ set(CPACK_GENERATOR DragNDrop)
+endif(APPLE)
+
+# Load the CPack module for CMake
+include(CPack)
+
+# Load the CTest module for CMake
include(CTest)
___
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] pcbnew module editor toolbar items now in menubar -- patch
Because almost all toolbar items are not in the menubar of the module editor I wrote a small patch. Maybe someone can take care of the few TODO's inside the patch which I was not able to get. The File - Close needs a ID handler and need's to be fixed. And maybe some entries should not be selectable in some cases like undo,redo and the placement of components if there is no module loaded or new module created. Maybe all the *modedit* files can better be moved to a subdirectory if the code will be growing. And also moving the dialog_* files. Because we get already a nice amount of files and directories are handy to sort things up. See the attached patch, it applies to rev 2418 without problems. -- Kind Regards, Met vriendelijke groet, Jerry Jacobs - http://www.xor-gate.org pcbnew_module_editor_extended_menubar.patch Description: Binary data ___ 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] feedback on launchpad
On Wed, Jul 21, 2010 at 11:31 PM, Dick Hollenbeck d...@softplc.com wrote: Are people happy with launchpad? 10 = extremely happy : : 1 = extremely dissatisfied I think you mean in the context of the KiCad project hosted and maintained on launchpad system? For me i'm more happy and see more progress and better management than on the services sourceforge can give us. Only i'm not to happy with bzr for revision control and as a personal matter of taste I prefer Git. I give it a 8 = very happy. Keep it up guys, We are moving forward. (sorry Dick I need to reply to all instead of only to the one who put it on the mailinglist :-) ) ___ 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
