On 09/25/2013 08:04 AM, Wayne Stambaugh wrote: > On 9/24/2013 9:29 PM, Dick Hollenbeck wrote: >> On 09/24/2013 07:14 PM, Wayne Stambaugh wrote: >>> On 9/24/2013 6:40 PM, Dick Hollenbeck wrote: >>>> >>>> On Sep 24, 2013 5:29 PM, "Wayne Stambaugh" <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> >>>>> On 9/24/2013 6:17 PM, Dick Hollenbeck wrote: >>>>>> >>>>>> On Sep 24, 2013 5:14 PM, "Wayne Stambaugh" <[email protected] >>>> <mailto:[email protected]> >>>>>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>>>>>> >>>>>>> On 9/24/2013 5:15 PM, Dick Hollenbeck wrote: >>>>>>>> On 09/24/2013 03:14 PM, Wayne Stambaugh wrote: >>>>>>>>> On 9/24/2013 3:34 PM, Lorenzo Marcantonio wrote: >>>>>>>>>> Premise: I don't get why this was done, since I find the existing >>>>>>>>>> library-order search perfectly adequate, however it's an >>>> interesting >>>>>>>>>> idea and obviously must have its merits (simply I can't see them, >>>>>> I need >>>>>>>>>> better glasses or a different workflow :P). Also I use the >>>> 'board as >>>>>>>>>> a library' approach suggested in the manual i.e. I never use the >>>>>> library >>>>>>>>>> related operations in the module editor. Create footprint >>>> archive does >>>>>>>>>> the library creation step for everything (for now it supports >>>> only the >>>>>>>>>> legacy mod files, will that change with the new file-for-module >>>>>>>>>> libraries?) >>>>>>>>>> >>>>>>>>>> First of all: very good the environment variable replacement idea; >>>>>> a lot >>>>>>>>>> of symlinks trickery was required to make it work for different >>>> users. >>>>>>>>>> >>>>>>>>>> Tried to play with the library path dialog and it's good. I >>>>>> presume that >>>>>>>>>> the 'path' column changes significance depending on the plugin >>>> (a .mod >>>>>>>>>> file for legacy, a directory for the new format and so on); >>>> that plus >>>>>>>>>> the path substitution makes impossible a 'browse' button for the >>>>>>>>>> path...however I think that nearly immediately users will ask >>>> for it! >>>>>>>>>> In fact I have many libs and I generated the fp file with a >>>> shell one >>>>>>>>>> liner:P >>>>>>>>> >>>>>>>>> The ability to use any footprint library that is supported by a >>>> plugin >>>>>>>>> without having to convert them to one of Pcbnew's formats is >>>> important >>>>>>>>> for some users and certainly is more convenient. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Has the description column some significance or it's only a remark? >>>>>>>>> >>>>>>>>> It's just a remark that gets saved in the footprint library table >>>>>> entry. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Possibly useful enhancement: while playing I added an inexistant >>>>>> pathname... the >>>>>>>>>> next cvpcb run it said: >>>>>>>>>> >>>>>>>>>> Some files are invalid! >>>>>>>>>> IO_ERROR: Footprint library path does not exist <<< here the >>>>>> missing file would be useful >>>>>>>>>> from /home/lomarcan/cvswork/kicad-bzr/pcbnew/kicad_plugin.cpp : >>>>>> Load() : line 214 >>>>>>>>> >>>>>>>>> I'll take a look at it. I did fix a few bugs in r4345 so I may have >>>>>>>>> already fixed it. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Another thing trapped by my wx debug build: >>>>>>>>>> >>>>>>>>>> ASSERT INFO: >>>>>>>>>> ./src/generic/listctrl.cpp(3063): assert "col >= 0 && col < >>>>>> GetColumnCount()" failed in SetColumnWidth(): invalid column index >>>>>>>>>> >>>>>>>>>> BACKTRACE: >>>>>>>>>> [1] wxOnAssert(char const*, int, char const*, char const*, wchar_t >>>>>> const*) >>>>>>>>>> [2] wxGenericListCtrl::SetColumnWidth(int, int) >>>>>>>>>> [3] FOOTPRINTS_LISTBOX::SetFootprints(FOOTPRINT_LIST&, wxString >>>>>> const&, COMPONENT*, int) >>>>>>>>>> [4] CVPCB_MAINFRAME::BuildFOOTPRINTS_LISTBOX() >>>>>>>>>> [5] CVPCB_MAINFRAME::ReadNetListAndLinkFiles() >>>>>>>>>> >>>>>>>>>> It does so often (every time it repopulates the right column), and >>>>>> I see >>>>>>>>>> no sign of column resizing... I have seen the bug comment in >>>> the code >>>>>>>>>> and it trips even on wx 2.9 with gtk-2.0. That's just for >>>> information. >>>>>>>>> >>>>>>>>> This one should be fixed in r4345. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Then I tried to 'update' a couple of components: it was C0805 (old >>>>>>>>>> package), then become smd:C0805. Everything fine till now, saved >>>>>> the cmp >>>>>>>>>> file without problems. Maybe one day the cmp file will go away and >>>>>> only >>>>>>>>>> the netlist will survive :D (the problem is when a part is >>>> deleted and >>>>>>>>>> a new one get its refdes... from the cmp file it takes the *old* >>>>>>>>>> package, which is bad) >>>>>>>>> >>>>>>>>> At some point, I plan on doing away with the cmp file. I have >>>> to write >>>>>>>>> the code so Pcbnew can save the new s-expr netlist file. Once >>>> that's >>>>>>>>> done, cmp files will go away as will the legacy netlist files. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Backannotation in eeschema, it works as expected. However there is >>>>>>>>>> a catch: the 'qualified' names are usually way too long to be >>>> shown in >>>>>>>>>> the drawing. Maybe an option to display only the 'short' name >>>> would be >>>>>>>>>> useful (only display, the attribute must remain intact). >>>>>>>>> >>>>>>>>> You might want to have a talk with library folks about the length >>>>>> of the >>>>>>>>> file and footprint names. Is it really necessary to have a library >>>>>>>>> named Allegro_ACS754_ACS755_ACS756_HallCurrentSensor_RevA with a >>>>>>>>> footprint named Allegro_HallSensor_Package-CB-PFF_24Oct2012? I >>>> would >>>>>>>>> think allegro_hall_current_sense and package_cb_pff would be plenty >>>>>>>>> readable without wrapping on a 1920X1200 monitor. You can always >>>>>> change >>>>>>>>> the library nicknames to something shorter. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Back to pcbnew... tried to refresh the netlist. As expected it >>>> noticed >>>>>>>>>> a mismatch (names from cmp, keep modules), however it says: >>>>>>>>>> >>>>>>>>>> Warning: component `C8` has footprint <C0805> and should be >>>> <C0805> >>>>>>>>>> >>>>>>>>>> I'd expected to read "should be <smd:C0805>", or am I wrong? during >>>>>>>>>> actual replacement the message is correct, anyway: >>>>>>>>> >>>>>>>>> You are correct. I missed that. I'll add it to the list. At >>>> least it >>>>>>>>> replaces with the correct footprints. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Replacing component "C8:/4BA0B4A0" footprint "C0805" with >>>> "smd:C0805". >>>>>>>>>> >>>>>>>>>> (is that timestamp really useful? maybe when selecting using >>>>>> timestamps >>>>>>>>>> and not references... but then it would be useful in the previous >>>>>>>>>> message too) >>>>>>>>>> >>>>>>>>>> Editing the replaced component shows the qualified name in the >>>>>>>>>> 'footprint name in library'... I think this need a little caution, >>>>>>>>>> however; this is because of how libraries are made. >>>>>>>>>> >>>>>>>>>> - In a project board that value represents from which library the >>>>>>>>>> component came from and the module name. >>>>>>>>>> >>>>>>>>>> - In a master board for library creation that is the module name >>>>>> but, in >>>>>>>>>> fact, the library has not significance (since we are going to >>>>>> write in >>>>>>>>>> a specific, maybe new, library). In fact during the archival >>>> process >>>>>>>>>> the library nick is simply stripped (I'd have done the same). >>>> Still >>>>>>>>>> I don't get *why* it takes so long:P >>>>>>>>>> >>>>>>>>>> Maybe would be probably better to split the field in the module >>>>>>>>>> properties? It needs some more thinking. >>>>>>>>> >>>>>>>>> I still have some testing to do with the footprint editor. I'll >>>> see if >>>>>>>>> I can make it more user friendly in this regard. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> All in all it seems to work... I'm using it and if something >>>> else pops >>>>>>>>>> up I'll let you know. Having the multiple library backend and >>>> variable >>>>>>>>>> substitution is surely an improvement from the previous >>>>>> implementation. >>>>>>>>>> >>>>>>>>>> One last thing: I think we should stop polluting the home >>>> directory. >>>>>>>>>> With non-dot files, even! By the way, why are lock files there >>>> instead >>>>>>>>>> of aside the original files like before? it is an accepted practice >>>>>>>>>> (like the .*.swp files for vi) and doesn't pollute the home. >>>> Frankly >>>>>>>>>> I find all these _home_lomarcan*lock files quite ugly. Now there >>>>>> is the >>>>>>>>>> fp-lib-table which is a permanent file too... why not allocate a >>>>>> .kicad >>>>>>>>>> or a .config/kicad directory and put all that cruft there (with the >>>>>>>>>> individual .eeschema, .pcbnew files and so on, too)? (Application >>>>>> Data >>>>>>>>>> would be the equivalent for Windows systems) >>>>>>>>>> >>>>>>>>> >>>>>>>>> I agree. This is already on my list as well. At some point, I >>>> plan on >>>>>>>>> moving all the KiCad config files into the .kicad folder in the >>>> user's >>>>>>>>> home folder on Linux. Unfortunately, there is no easy way to do >>>> this >>>>>>>>> for Windows users. Converting the KiCad configuration settings >>>> in the >>>>>>>>> registry to config files is not trivial. I may make Windows user's >>>>>>>>> reconfigure KiCad rather than try to convert the registry entries >>>>>> when I >>>>>>>>> get around to this. >>>>>>>> >>>>>>>> Where does the project specific table get saved to when I have to >>>>>> establish a project, but >>>>>>>> rather have simply started pcbnew from the command line without a >>>>>> filename? >>>>>>>> >>>>>>>> Otherwise I assume it is saved in the same dir as the *.kicad_pcb? >>>>>>>> >>>>>>>> >>>>>>>> Dick >>>>>>>> >>>>>>>> >>>>>>> That is how it's supposed to work unless there is some issue that I >>>>>>> missed. The few projects that I tested it on seemed to work fine. Let >>>>>>> me know if it's getting saved somewhere else and I will fix it. >>>>>> >>>>>> You did not answer my first question, I don't know where it gets saved >>>>>> if no project. But it is. >>>>> >>>>> Sorry about that. >>>>> >>>>>> >>>>>> I like what I see, but wanted to examine the project table. Can not >>>>>> find it for case when no project. >>>>> >>>>> That would be a bug on my part. It should not save the project >>>>> fp-lib-table if no board file is loaded. Is there a way to not show the >>>>> project specific tab in the footprint table edit dialog. That seems >>>>> like a reasonable indicator to the user that no project footprint >>>>> library table is not available. I'll take a look at the project >>>>> footprint library table save code and make the necessary fixes. >>>> >>>> Quite mutiny is not desired. So simply not saving it is worse. >>>> >>>> If this is not something we can agree on, we should keep talking. Can >>>> we explore some more ideas. Please? >>>> >>>> I think saving it in home directory and loading from home directory WHEN >>>> NO PROJECT DEFINED is best. This lets the command line user start a new >>>> project by inheriting the project table from home. >>> >>> Just so I'm clear, are you talking about adding entries from the project >>> specific table the global footprint table when no board file is loaded? >>> The global table is always loaded, board file or no board file and is >>> the fallback table to either the project specific table or and empty one >>> if it doesn't exist or no board file is loaded. >> >> >> No. This is a far less radical idea. Simpler. We cannot be changing the >> global table >> like your incorrect clarification request. >> >> Now, for clarification: along side the fp-lib-table which is global, have a >> template or >> default project table also in the home directory or ~/.kicad/. This project >> table only >> gets loaded when pcbnew is loaded with no project, basically only from the >> command line. >> >> $ pcbnew >> >> (This is how I run the software. I never use the project manager.) When the >> program is >> invoked this way, that project table from home gets loaded, and you can edit >> and save it, >> and put environment variables in the lib_paths. >> >> >> >> At the moment a board is "saved as", then you have a project directory. >> Since the user >> did not load the board, but created it anew, there is no existing project >> table in the >> project directory. This is how I work, again, from the command line. If I >> then edit fp >> lib tables, and save, I would expect that template which was initially >> loaded from home to >> be saved into the new project directory. Because between starting pcbnew >> and editing the >> fp lib tables, I have mated with a BOARD and CWD (i.e. a project directory). >> >> Thats all it is, very simple. If I don't ever load a board or do a save as, >> then when I >> do edit fp lib table (project directory still unset) the Save (OK BUTTON), >> puts the >> project table back into home. > > This makes sense to me. > >> >> >> Now onto additional justification: >> >> Remember just last week we talked about having environment variables in the >> project table. >> You wanted to set a known variable, I said don't bother. Both of us agreed >> that the >> project table can *reference* env-variables even if we put the burden of >> *setting* them >> onto the user. >> >> Since it has environment variables in it, e.g. ${PROJ_LIB_DIR} I could >> actually use the >> same ROW for all projects. >> >> (name project)(uri ${PROJ_LIB_DIR}/project.pretty)(type Kicad)) >> >> I have a project.pretty, I am free to put that where I want by setting >> env-var PROJ_LIB_DIR. > > I'm assuming that you prefer the environment variable to be set > internally by Pcbnew per my original suggestion. I'll go ahead and set > the path to the project footprint table to the cwd when a board file is > loaded, set it to ~/ when no board is loaded, and change it to the new > cwd on a save as. > > I should be able to get these changes done over the weekend.
You da man. Thanks. BTW, I am not sure about the future of wxApp, as we move to main-module DLL-ization. Don't know yet. Might be prudent to establish an interface for "current project" identification (or none) as a separate entity. It could be made responsible for all the tasks associated with a project change. Don't know, many correct ways to do things. Brain cycles exhausted. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
