Re: [Kicad-developers] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)
Hi Dick, > You have twice as many in a > >>> std::list, I will use std::deque. Its ten minutes to change it. > >> Yes, I agree - this was just an initial choice - I've changed some > types already to std::vector but the std::deque is also a good idea. > >> > > std::vector is better than std::list. std::deque and std::vector are > both > > OK. The only difficulty with std::vector is if you hundreds of > thousands of > > points in a polyline, in which case the backbone array needs to be very > > large. std::deque uses a segmented backbone, and could be slower than > > std::vector for smaller numbers of points. Yes, I've read as well, that at certain conditions the std::deque is faster. Especially for our cases it should be the best solution; so I changed anything to the deque. > virtual ~VECTOR2 > > Just let anyone deriving from VECTOR2<> add in virtual destructors, you > don't need it at this level. It causes the virtual function table to be > copied and constructed, both of which cost time, for large numbers of > points. That's right; it was mainly a stub that Eclipse creates automatically. I've commented it out; if it should be used later, the comment just needs to be removed. -- I had to apply some different changes for wxWidgets 2.8; now it should be run there as well. The problem is that I've changed to the image backend of Cairo and the blitting doesn't work like I'd like. So I'm using the code from wxCairo; but it's much slower than a direct access with wxNativePixelData that 2.9 provides. I think it is even there room for impovements. The rubberbanding demo is still bit stupid; at the moment it displays only a QFN footprint (you can zoom with the mouse wheel and pan with the right mouse button). I'll implement dragging of some objects later and seperate the classes in different files. There is still much in progress; also I have to add more documentation. I've changed the branch owner to kicad-testing-committers. You should be able now to commit changes. Bye .. Torsten -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl ___ 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
On 01/05/2011 11:23 AM, Marco Mattila wrote: > If you think that the plotting requirements vary from one project to > another (the number of needed technical layers maybe?), saving them > outside the config system makes sense. Since there can be multiple > boards in a project, maybe the SETUP section of a board file is the > correct place for this. I wonder if all plot settings should be saved > in the board file. For example, it would be nice if the output > directory was saved, too. > > marco If you were to write a Parse() and Format() function for your PLOT settings object, similar to those in new/sch_lib_table.cpp or class TEMPLATE_FIELD_NAMES, then you could stuff or retrieve the data almost anywhere, and it would be re-usable moving forward. This includes the ability to: 1) save it in the current board file, all on one line. 2) read it from the current board file format, all from one line. 3) save it to any new S-EXPRESSION based board file in the future. 4) read it from any new S-EXPRESSION based board file in the future. 5) Save/read it to the clipboard. For 1) and 2) you would need an "old school" prefix on the BOARD file line, such as: // for current board file format, all on one LONG line: PlotConfigs: (plot_conf () () ()) For an example, see what I did for eeschema, TEMPLATE_FIELD_NAMES: *) eeschema_config.cpp, line 711, where I save the s-expression. *) eeschema_config.cpp, line 628, where I read the s-expression. If any new data structure were to have these Parse() and Format() functions, it becomes really pretty easy to serialize these things almost anywhere, including to the clipboard, or nested in side another S-EXPRESSION. This would give you an intro to the make_lexer support in the CMake files. If you were going to parse everything off of a single line, then probably the STRING_LINE_READER constructor of the DSNLEXER derivative is what could be used for stuffing this stuff all on one line in a current board file. This is what I did for TEMPLATE_FIELD_NAMES. The storage location is almost a separate discussion from the storage format. I like the s-expression direction we have, obviously, and I don't see any big problems putting it into a BOARD file, but I could be wrong. The only concern is maximum line length, but if the BOARD reader were to use a FILE_LINE_READER, then that concern goes away, since FILE_LINE_READER will read single lines of up to 100,000 bytes. Or you can simply not inject FILE_LINE_READER into the BOARD loader, but verify that its fgets() buffer is big enough to handle your new long single line. Jean-Pierre, what do you think of this as a migration path, or even as a middle term destination? 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] [PATCH] Saving plot dialog settings
If you think that the plotting requirements vary from one project to another (the number of needed technical layers maybe?), saving them outside the config system makes sense. Since there can be multiple boards in a project, maybe the SETUP section of a board file is the correct place for this. I wonder if all plot settings should be saved in the board file. For example, it would be nice if the output directory was saved, too. marco On Wed, Jan 5, 2011 at 6:29 PM, jp.charras wrote: > Le 05/01/2011 16:10, Dick Hollenbeck a écrit : >> >>> > From a usability standpoint, i.e. user experience, I have a concern >>> > about >>> saving the desired layers, as if I was only ever going to work on one >>> board. >>> >>> Now that you have a compact bitmap, would it make sense to prefix the >>> Config >>> key for layers, with the boardname? Although this might eventually >>> pollute >>> the configuration space, you'd have to do a lot boards to get there. >>> This >>> way it remembers what layers you want for what boards. >>> >>> The >> >> alternative >>> >>> idea would be to put this information in the board, no preference here. >>> >>> Is this anything worth considering? >>> >>> Dick >> > > An other idea is to use the .pro file to store layers. > So, no config polluted. > Currently Pcbnew already updates the corresponding .pro file when it is > closed. > ___ 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
Le 05/01/2011 16:10, Dick Hollenbeck a écrit : > From a usability standpoint, i.e. user experience, I have a concern about saving the desired layers, as if I was only ever going to work on one board. Now that you have a compact bitmap, would it make sense to prefix the Config key for layers, with the boardname? Although this might eventually pollute the configuration space, you'd have to do a lot boards to get there. This way it remembers what layers you want for what boards. The alternative idea would be to put this information in the board, no preference here. Is this anything worth considering? Dick An other idea is to use the .pro file to store layers. So, no config polluted. Currently Pcbnew already updates the corresponding .pro file when it is closed. -- Jean-Pierre CHARRAS KiCad Developers team. KiCad Developers ___ 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
On 01/05/2011 09:10 AM, Dick Hollenbeck wrote: >> >From a usability standpoint, i.e. user experience, I have a concern about >> saving the desired layers, as if I was only ever going to work on one board. >> >> Now that you have a compact bitmap, would it make sense to prefix the Config >> key for layers, with the boardname? I have a couple of 2 layer boards and a 4 layer board I work on, intermittently. I can tolerate all the same settings for both boards at gerber generation time, but the number and types of layers are the main difference. The proposed solution handles my situtation, which is why I suggested it. :) And it has hi return on investment, because it's easy to do. 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] [PATCH] Saving plot dialog settings
> >From a usability standpoint, i.e. user experience, I have a concern about > saving the desired layers, as if I was only ever going to work on one board. > > Now that you have a compact bitmap, would it make sense to prefix the Config > key for layers, with the boardname? Although this might eventually pollute > the configuration space, you'd have to do a lot boards to get there. This > way it remembers what layers you want for what boards. > > The alternative > idea would be to put this information in the board, no preference here. > > Is this anything worth considering? > > Dick Dick, English please. ___ 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
On 01/05/2011 07:47 AM, Marco Mattila wrote: > Damn. I always struggle the most with the comments for Doxygen... > > I think that we may be able to get rid of the global variable. I'll > take a look. I'll fix the comments in the next patch, too. > > marco >From a usability standpoint, i.e. user experience, I have a concern about saving the desired layers, as if I was only ever going to work on one board. Now that you have a compact bitmap, would it make sense to prefix the Config key for layers, with the boardname? Although this might eventually pollute the configuration space, you'd have to do a lot boards to get there. This way it remembers what layers you want for what boards. The idea would be to put this information in the board, no preference here. Is this anything worth considering? 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] [PATCH] Saving plot dialog settings
Damn. I always struggle the most with the comments for Doxygen... I think that we may be able to get rid of the global variable. I'll take a look. I'll fix the comments in the next patch, too. marco On Wed, Jan 5, 2011 at 3:24 PM, Wayne Stambaugh wrote: > > This is a nice patch so I'm all for committing it. I would have liked it even > more if there was a way to avoid using a the global variable g_PcbPlotOptions. > Thanks Marco for your help. ___ 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
On 1/4/2011 10:31 PM, Dick Hollenbeck wrote: > >> The previous patch has a bug. It incorrectly complains about no layers >> being selected. This patch works better. >> >> marco >> >> On Sun, Jan 2, 2011 at 11:40 PM, Marco Mattila wrote: >>> Hi, >>> >>> During previous discussions about subtracting masks from silkscreen >>> layers when plotting gerbers, Dick mentioned that saving plot settings >>> is not quite up to date. Currently some plot settings to be >>> saved/loaded are defined in pcbnew_config.cpp. However, that requires >>> that corresponding variables in the PCB_PLOT_PARAMS class are public. >>> My proposal is to let the class itself take care of saving/loading the >>> settings. That's mainly what the attached patch changes. In addition, >>> all plot dialog settings should now be included. The wxConfig key >>> names are also edited to start with "Plot", and layer selections are >>> combined into a single bit mask. Moreover, some global variables in >>> pcbplot.cpp have been moved into the class, too. g_PcbPlotOptions >>> itself is still global. However, I think that it could be moved to be >>> a member of the WinEDA_BasePcbFrame. That way it should be accessible >>> where needed without being global. And if necessary, plot settings >>> could still be loaded only once when pcbnew starts (now they are >>> loaded every time the plot dialog constructor is called). In addition >>> drill file generation settings could be included into PCB_PLOT_PARAMS. >>> I can continue working on this if my approach sounds reasonable. >>> >>> marco > > I would say the patch looks like an improvement worth committing. > > Thanks. If anyone has concerns they should voice them. This is a nice patch so I'm all for committing it. I would have liked it even more if there was a way to avoid using a the global variable g_PcbPlotOptions. Thanks Marco for your help. Wayne > > This little bit here is goofy though, for a function comment: > > PCB_PLOT_PARAMS(); > +/** > + Function LoadSettings > + loads plot settings from wxConfig system. > + @param aConfig is a pointer to a wxConfig. > + */ > +voidLoadSettings( wxConfig* aConfig ); > +/** > + Function SaveSettings > + saves current plot settings to wxConfig system. > + @param aConfig is a pointer to a wxConfig. > + */ > +void > > In the future, please leave a space between these like the coding standard > says, and fill in the vertical stars. > > My vote is to commit. > > 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
