I am creating a family of parts. In the process, I am setting up several properties that allow the user to switch between the parts from the inspector. I have a size that switches between 4 sizes, a pcb pad that switches between 2 pcb footprints, a variant that switches between 2 polarities. That is all working. I also included a part number without any value, that allows a value to be entered in the inspector. Also working. Then the part that does not work. I wanted to have another property that, like part number, creates a text box in inspector to let the user fill in a value. I tried color and led color names, setting them up the same as part number. However, inspector just shows them as a read only empty value. No box, no drop down. Is there something more I need to do to create a property name that acts like part number? Are the rules for using fzp properties and property names documented somewhere?
Assuming you want led colors that should be possible (although not user settable) by coping the layout of a standard LED. The color is set by the fzp file for the part, not the user but it should work that far (although it multiplies the number of fzp files needed, one per color.)
i.e from the blue led fzp file:
<property name="color" showInLabel="yes">Blue (470nm)</property>
presumably trips a special case in the code to do the work which you can reuse.
Not that I am aware of, you either need to experiment or read the source code (which is not easy 
.) Many of the fields are implemented by special case code in the app, and can sometimes be warped to do what you want. In the long term an api that would allow user created fields in Inspector is probably the way to go, but it isn’t there currently. Documentation (assuming we can find someone to figure it out and write it ) would also be useful, but at present it has mostly been passed around in here and is becoming increasingly lost (most of the folks I learned from are no longer posting.)
Peter
@vanepp that is similar to what I am doing for size and pcb pad properties. I really want to avoid doing it that way though. Going from 16 fzp files to (at least) 80, where the differences are exactly the one property line does not sound like any fun at all. And that would be for generic colors. As your example shows, that could be expanded to include specific wave lenghts. I want the user to be able to fill in what makes sense for their project, just as you can for part number.
<property name="part number"></property>
What I was hoping for, was something like that showInLabel attribute, that would get the property treated like part number. For now I guess, anybody that really wants it will have to overload either the part number or label, and supply the color as a component of the other data. Not optimal.
For the documentation, I was afraid that was the case. My searching was not finding the details. There are other xml tags and attributes in the fzp file that I would like to know the intended use for. taxonomy for starters. I see examples usage in some of the existing files, but not enough consistency to determine how to properly user them. Even the referenceFile attribute is not making much sense. Your part check code expects it to match the fzp part it is in, but that is redundant. If you have the file to read, you have the name. There is no point in putting the name inside the file, unless you want to track renames. Which would then make your check code complain again. I would expect that to reference some external source information what was used to create the information for the part. Like a datasheet. Or a different fzp file that was used as a model for the current one.
Would the wiki for the application be the proper place for that sort of documentation, or the wiki for the parts library repository?
I did pull down the code for a quick look / search, but without some information about the code structure (more documentation), it will take significant effort to locate the section of the code that would be expected to handle the inspector and properties. I did find where part number was being moved to the last entry, and family to the first, but no information on why, or what additional capabilities are being implied.
Unfortunately I suspect there isn’t anyone that knows who is commenting anywhere any more. I don’t know of anything that happens if you have a taxonomy field, so I usually delete them, but there could be something happening I’m not aware of. It could also be part of the long term plan for future development (there are indications of that in the source in places.) The project appears to have been very well thought out, in terms of where it should go in the future, with the foundations for stuff not yet implements in place. The original developers have pretty much either all left or are not communicating, and as I said many of the folks that were here when development was still active (I only came upon Fritzing in 2016 after development had stopped) aren’t posting any more so we are losing expertise. There are few comments in the source, and it is complex. I usually find a message in the area I’m interested in and then search the source for the message (which is hard since many of them are created, so you have to search for boiler plate text that will be present in all messages and search for that) and then use gdb to trace the code to figure out what is going on.
When (and hopefully not if ) I manage to finish the update to the check part script. The intent is to have a check only version that will be in the part submit tool chain so new parts need to pass the script. However that means the false positives that I currently leave to human decision need to be dealt with in some manner suitable to automation. It is going slow. Next task on my list is documenting the part obsoleting code (needed when replacing parts in core parts which is going to need to be done to clean up core parts to pass the script), then cleaning up core parts (a big job!) Somewhere after that is figuring out what all the possible fzp tags mean and documenting them is on the list. If you would like to start that, more the power to you I expect that will take reading the source to figure out (if possible) what it is supposed to do. Sometimes just experimenting with parts may be enough (change the value, see what happens) and may be much easier!
Doesn’t to me either. I’m not aware of anything in Fritzing that cares about it, so it may be part of the svg standard (I’m not really svg aware either, only as much as Fritzing uses.) Setting it to the current file name while redundant, seemed the best choice. Deleting it entirely may be the better choice (reduces file size and increases performance by a tiny fraction), but I’d need to know more to do so, like so many things.
@KjellM who leads the development team would probably have the best answer to that. I usually use the tutorials and howtos section of the forums, but either place on the wiki should be fine, the existence somewhere of documentation is the important part rather than where it is as far as I am concerned .
I haven’t had occasion to look for Inspector, I’ve poked at the parts factory (which makes headers and ICs in various sizes) somewhat. A search for “Inspector” should turn up the code that writes the window which is likely in the window manager and not what you want, but may provide a pointer to the code you do want (the names are reasonably descriptive.) There may even be a separate directory for Inspector code if you are lucky.
That unfortunately is all too common. I suspect the original team asked the more experienced team members for help. There may be internal documentation somewhere, but if so I’ve never heard of it (although that doesn’t mean anything.) We don’t have that luxury and have to guess or trace the code to see what it does which I find extremely difficult.
Peter
It is the things that you don’t know about that cause problems. I’m trying to populate (correctly) as much as practical, so that all of the designed functionality is available going forward. Like the <spice> tags. I understand what they are for. For specific components the information works well, but generic parts need to be able to provide instance specific values from external information. I see the syntax for providing substitutions, but everything seems to come from property values. If the user can not set them (like the part number), then it is very limited.
We really need access to those historical design notes. Having some of that high level intent would making understanding implementation a lot easier. Even if that implementation ended up branching away from the original design.
I’ve been using that python checking script as a lint check for my parts. It would be helpful to be able to turn off some of the warning messages. From the command line. I already know that I am working with through hole parts, so I do not need to be told how to switch to surface mount. Same for the svg already processed messages. With what I am doing, reuse is the expected case. More useful would be an orphan check, reporting any svg files that did not get referenced by any of the fzp files. Or delay reporting the already processed message until something in the svg requires reporting in the current context.
Knowing more about what the tags (are intended do) do could help in that cleanup process. Or point to other validations to add to the checking script.
The part set I am creating obsoletes 1 core part. The information I found is “How to contribute a fix” on page fritzing-parts/CONTRIBUTING.md at master · fritzing/fritzing-parts · GitHub. That seems to be incomplete, or changed. I did a bulk cleanup to adjust the family names in the obsolete parts cleanup obsolete family text prefixes by mMerlin · Pull Request #158 · fritzing/fritzing-parts · GitHub. To match the partial information I had found then. The latest information does not say anything about modifying the family name. I think it is necessary to change the family name, so that the obsolete part does not show up as available in the selectable options in Inspector. For the part that replaced it. Code could handle that instead.
referenceFile attribute is in the fzp files, not svg. It is not part of svg. There is no reference I can find for it in the svg attribute documentation.
I need to put creating a complete build environment for Fritzing back on my todo list. I successfully built 0.9.2b on a Ubuntu 12.04 VM a couple of years ago. After a lot of work to get all of the correct dependency versions together. Then priorities changed again.
We need to get a discoveries section started someplace. One if the wikis is an obvious choice. To record some of this information. As a substitute for the full documentation that does not yet exist. Or use as the WIP documentation. Initially could be some cut and paste from the forum threads. But gathered together, and potentially updated with the most recent/complete details.
The new version dumps that and has a ton of command line options (and more can be added easily now the mechanism is in place.)
Yes, I agree. AFAIK the current modifiable fields are handled by hard coding in the app. I would much rather see an api that would let the user be able to specify modifiable fields from the fzp file. However, someone has to write that code in the app, and at present we have a lot of bugs that need fixing and almost no one working on any of it, so that is fairly far down my list (but is on my list!). I did manage to get my top two bugs (invalid parts crashing Fritzing and corrupting the parts database and Parts Editor not registering its fzp and svg files with the main window, meaning you can’t reload a part even if you say “don’t save” on exit, fixed and in the 0.9.4 release, but that took me about 2 or 3 months or work for each to figure out the fixes, and even then it is only because the crash was a worse outcome, that it was reasonable to include them. I have no idea if they are entirely correct, they fix what I wanted done but may affect something else I’m not aware of.
@KjellM is the best chance of that. He is (I think anyway) in Berlin and in contact with the remains of the original developers. If such notes exist, he will have the best chance of finding them, but I suspect they may not exist.
Yep, the ones that are there are ones I have run into myself or when fixing other people’s parts. The ones that create Errors will break Fritzing in some manner, the rest are Warnings because they are unusual and may be wrong (but sometimes are intended.) They are nowhere near complete because I don’t know enough, and trying to restart development was the more important task. Luckily the Ansler folks stepped in and restarted development, because I was getting nowhere for a couple of years .
That is likely to be a problem. There is a part obsoleting mechanism (it is referred to in the part file format document like this:
Obsolete parts use a special version syntax <version replacedby=""> The value of the replacedby attribute is the moduleId of the part which replaces the obsolete part. There are many examples of this in the pdb/obsolete folder. The replacedby attribute can also be applied to individual connectors; see the Connectors section below.
AFIK this is the only documentation on how to obsolete parts. There used to be a section in the CONTRIBUTING document (or perhaps somewhere else) but its entire content was “tbd” and as far as I know it has never been done/documented. I expect that the parts maintainer knew how it worked and did it when required, but I think he may no longer be with the project. So you probably need to figure out how to obsolete the current part with your new one. Figuring this out and documenting it is on my todo list because it will be needed to clean up core parts once the script is done. I of course am no where near that far ahead yet though. The mechanism is intended to replace obsoleted parts in old sketchs with the new one. The one time I tried that it screwed up, so I just reloaded the .fzz and said “no don’t update”, so I think it (or possibly some of the obsoleted parts) have problems.
This should (note the weasel word ) be dealt with by either of both of the part being in the obsolete folder and/or the “Obsolete parts use a special version syntax `” in the pars file format document. One or the other of those should block it from showing in Inspector.
It is actually in both. In the svg it is in the desc field of the metadata (I don’t know whether that is an svg standard field or a Fritzing convention.) In an svg it looks like this:
<desc
id="desc2">
<referenceFile>PIC24FJ128GA204_8903ac93cd3db0fdd1143f9428ed518e_1_breadboard.svg</referenceFile>
</desc>
which the script checks for and corrects as necessary. Again I know of nothing that cares about it (because many of them are wrong with no known ill effects)
I expect @KjellM is the best one to decide on an appropriate place. I certainly have no objections, I don’t use the wiki because I don’t know anything about wikis (along with a lot of other things like github )
Peter
I thought I had the latest version (as of a week ago) from the repository. Is the new one in a different place, or just not pushed to gethub yet?
So we also need some (an expanding set of) automated regression tests.
I’ve seen that, and have a few notes from when I did the bulk family cleanup on obsolete parts a couple of years ago. There were no complaints on the pull request, and it went in fairly quickly, so who ever was doing the work then was satisfied that it was correct. Or at least better than what was there at the time.
That should be as simple as moving the fzp and svg file into the obsolete folder structure, adding that mentioned replacedBy entry, and maybe changing the family name per my older notes. Already on my list, once I do a bit more testing of the new parts. They all seem to be minimally functional at this point. If I push it to my fork of the parts library on github, can you pull it down and do some cross checks? From comments, you are not really comfortable with git and github, but I can walk through the steps needed. It will also need the redirect of the parts library, and database rebuild I have been doing here, and talked about in another thread.
I’ll have to test that carefully. My last round was just to cleanup things already in obsolete, and I did not have any information then about the semi-automatic replaced of obsolete parts in existing projects.
Agreed, should. From a quick visual scan of
grep -Ei "property.*family" obsolete/*.fzp
everything currently in obsolete has the prefix matching what I did 2 years ago. It is not hard to do an initial test without that, to see what Inspector shows.
I do not remember seeing that. Can you provide a link to the document? But using, that, or even that replacedBy attribute COULD be used by the code to filter obsolete parts. Don’t know if at actually DOES.
Mixing terms a bit. In the fzp file, referenceFile is an attribute of the module element. In the example svg, referenceFile is an element, with a parent element of desc. Searching the online svg documentation does not show any reference to either a referenceFile element, or any element with a referenceFile attribute. The information for the desc element shows <desc> - SVG: Scalable Vector Graphics | MDN effectively free form text. Both svg and fzp files are xml based, which can be extended readily. Parsers are generally supposed to just ignore things they do not understand. So it is quite possible that Fritzing is using an extension that recognizes these. But best I can tell, it is not true svg.
There are other capabilities as well, but, just like posting here, it is mostly just text. Most things posted here could be pasted into a wiki page, and work just fine. Again like here, there is a toolbar available to help out with common things. Github wiki handles several different text entry formats (markup languages). It converts automatically. I can work with others, but tend to stick with markdown, because it is what is generally used for README files (README.md), and displays correctly in gh_pages. And I use it a lot in other places. Again, like here, there is preview available to see if you get what you expect. The wiki data entry screen acts like not much more than a simple text editor. Or very simple word processor. The page (document) title is something that can be referenced (linked to) from other wiki pages.
Not pushed to github yet (nor finished which is why.)
I don’t think there currently are any regression tests (but I could be wrong)
I should be able to clone and install your fork without problem. My usual problem with github is not being able to sync my fork on github to the parts master. The last time submitted a part, I ended up deleting my fork on github and re doing the fork then cloned the new fork locally. When I try the fetch or fetch all commands, my github fork gets out of sync with the master (or at least it appears that way). A clone of an existing repo and replacing the local version of the parts library shouldn’t be a problem.
The part file format doc on the wiki here:
it is just after the author, version etc xml. I remember another comment somewhere that I can’t find right now that said something like “there are lots of parts to use as examples in the obsolete folders”
Peter
I am coming to the conclusion that the best way forward here may be to go back to basics. By that I mean do a revision of the part file format document to make a specification document for parts (preferably one that is easy to automatically check.) and that is more complete than the present document. If possible, documenting all the properties that can be set and what they do (although that is likely to be time consuming.) From there, the check script needs to match the new document and once that is done, core parts needs to be converted to match the new document (which will be a lot of work.) I am somewhat concerned that there are no longer some of the dissenting voices from when the parts checking script was written a couple of years ago posting any longer. The discussion could occur here, on github in the fritzing-app issues or on the slack channel (although that is a much narrower audience and this probably wants to be as public as possible!) @KjellM is probably who should decide if this is a good idea, and if so, where the discussion should take place. At a minimum there should be a post here in the forums directing anyone interested to where the discussion is taking place, because we want as much input as possible assuming this goes ahead. As noted here:
What I consider to be a bug: an apparent hard coded svg in the code that substitutes for the schematic svg if editable pin labels is true exists. I had not run across this issue before, and it took me a while to figure out what was going on. The format of the hard coded svg is poor in my view as schematic pin lengths are .2 in long, rather than the .1 in long suggested in the template files and possibly the part format file document. Space in schematic is precious, in that if the pins are short more parts can fit in a given space and you can fit a larger schematic in (for instance) a 8.5 by 11in page. I would like to see that set as the standard for most parts. As well in my view it is desirable to set a common width for lines (probably the same as the size of a created wire so the connections match in size), but as noted in the past there were people that didn’t want the level of constraint. Thoughts?
Peter
More complete would be good. More structured / segmented too. Not a single document. A series that is linked together. We have the technology, let’s use it.
Being cautious of the intent. One way to read that, would be say create a new format to replace the old. Which would of course require breaking code changes. Which would likely break the application, (at least library access) for anyone unable to upgrade. Good idea, but add caution.
Some levels of hard-coding have their place. Here, I think, it should be more of a hard-coded default. I have seen some template files in the source code folders. I do not consider those to be really hard-coded, since they could potentially be modified without touching or rebuilding the code. Assuming they are used as a run time resource, not compiled into the code. Not following the published rules is a separate problem, hard-coded or not.
Screen space is always at a premium. The actually dimensions do not matter though, as long as things are consistent. Double the dimensions (of everything), halve the screen scaling, and you are back where you started. Individual parts that are different are a problem.
I like the schematic connection point lines thicker than the wires. Or some other presentation difference, to make the boundary between part and wires visually distinct. But that is just me.
Constraint for some things is good. Consistency is important. Which exact rule is less important. Artistic license gets tossed out, when it gets in the way of functionality. Which included being to tell at a glance what type of things are being worked on.
Not necessarily breaking code changes, there is capability to check the Frtizing version number in a part and apply previous behaviour to parts so as to not break older parts. We just have to keep that in mind with non compatible changes.
True, and that is what I would like to avoid. At present parts in core are different sizes, what I would like to see is as you say is consistent size / spacing rules for parts in core (for those not wanting rules, anything goes in user provided parts because there is no way to control it, but we have control of what gets added to core parts.)
Color is another option. A change to the graphic standards for pin names would I think be another way to do the same thing by making the color of a part pin a different color than that of the wires. I don’t know if that is true at present though, or if it would be enough.
Peter
But what would older code do with a part from the updated library that had the newer version number? It would not know how to handle it, and likely not work. From the user perspective, the library is now broken. You would have to maintain a complete copy of the older version of the parts library until everyone (which never happens) is using the newer code that understands the new version.
The version number by itself supports backward compatibility. But not forward compatibility. The only way I see to do it, without breaking things for existing (non-upgraded) users, is a separate ‘version 2’ library repository that the new code would look for on install. That would start as a clone of the existing library, but then have the changes proposed incorporated. Either in bulk, or over time.
EDIT: Or a version 2 branch in the same repository
Current part, Fritzing version 0.9.4 (current version) with Edit pin labels true set in the fzp file. Because of Fritzing version 0.9.4, the code acts as now, substitutes the boiler plate svg (which breaks header parts for instance.) as now and the part works. New part, Fritzing version 0.9.5 (not yet released) uses the new mechanism to find the position of the labels (which is I suspect why the overlaid svg) and does not break if applied to a header, and does not break older parts that do not recognize the new functionality because their Fritzing version is less the 0.9.5. If the version number is less than the Fritzing version the change is made in (likely not 0.9.5 since this work hasn’t started yet), the current code is used, if the version number is later than that, the new code is used (a simple if statement and some additional code bulk because of the two code streams, but easily doable.) If the part is in core parts, the obsoleting mechanism will allow the new part and new functionality to work by swapping out the old part (or not as the user chooses, as it should be). The designers thought ahead when designing the code base and similar things are already there (the format of parts has changed over the years such as the nested copper layers in pcb, but old parts still work fine in old sketches.) We need to be careful to test old parts when making such changes but it should be possible to do if we are careful. No need for different repositories (which is a maintenance nightmare.) unless I am missing something.
Peter
That is not quite the scenario I was trying to describe. Let’s try a hypothetical example. That family of parts I am working on could be described to Fritzing in a much more condensed format. It is really only one part with selection of different image files based on the selection of the size, polarity, and footprint. Those 16 fzp files I created are identical except for:
- module id attribute
- referenceFile attribute
- title
- property values for ‘size’, ‘pcb pad’, ‘variant’
- image attribute of layers element for each view
Those are the ONLY differences.
So, suppose I propose a change to allow that to all be described as a single part. One moduleId, referenceFile, title. With an adjusted element and attribute syntax to supply and select all the alternate information. Like this.
There are many other ways of implementing the same concept. This is not optimized in any way, just a quick description of what I can visualize, and should be an obvious extension of what is currently being used.
<properties>
<property name="size" type="condition">
<value sort="1">20mm (0.8in)</value>
<value sort="2">32mm (1.2in)</value>
<value sort="3">38mm (1.5in)</value>
<value sort="4">60mm (2.4in)</value>
</property>
<property name="pad type" type="condition">
<value sort="1">standard</value>
<value sort="2">narrow</value>
</property>
</properties>
<views>
<breadboardView>
<layers condition="size='20mm (0.8in)'" image="breadboard/20mm_example_breadboard.svg">
<layer layerId="breadboard">
</layers>
<layers condition="size='32mm (1.2in)'" image="breadboard/32mm_example_breadboard.svg">
<layer layerId="breadboard">
</layers>
<layers condition="size='38mm (1.5in)'" image="breadboard/36mm_example_breadboard.svg">
<layer layerId="breadboard">
</layers>
<layers condition="size='60mm (2.4in)'" image="breadboard/38mm_example_breadboard.svg">
<layer layerId="breadboard">
</layers>
</breadboardView>
<pcbView>
<layers condition="size='20mm (0.8in)' and 'pad type'=narrow" image="pcb/20mm_example_narrow_pad_pcb.svg">
<layer layerId="copper0"/>
<layer layerId="silkscreen"/>
<layer layerId="copper1"/>
</layers>
…
</pcbView>
</views>
Since it jumped out at me as I was writing the above, here is an extension/variation I like better, taken from the substitution done for spice entries. It reduces the duplication even more, by getting rid of the separate conditional layers element entries for each view. Closer to the current usage.
<generatedValues>
<value name="size_in_image" condition="size='20mm (0.8in)'">20mm</value>
<value name="size_in_image" condition="size='32mm (1.2in)'">32mm</value>
…
<value name="footprint_in_image" condition="'pad type'=narrow">_narrow_pad</value>
<value name="footprint_in_image" condition="'pad type'=standard"></value>
</generatedValues>
<pcbView>
<layers image="pcb/{gen size_in_image}_example_description{gen footprint_in_image}_pcb.svg">
<layer layerId="copper0"/>
<layer layerId="silkscreen"/>
<layer layerId="copper1"/>
</layers>
</pcbView>
The newer code would see that as equivalent to 8 parts in the older format. 16 parts, if I had added in the polarity variation that only affects the schematic view, but the point is, what would Fritzing 0.9.4b or earlier do if it saw that in a library part? Regardless of the version number in the part? When the user tried to drag it from the parts library to a view.
This particular case could be handled by the library update process. It could automatically generate the 8 or 16 parts, and store them in the parts library in the older format, instead of this condensed version that is easier to maintain. Easier because there is only a single copy of all of the rest of the part information that is the same, and should STAY the same, if a detail changes. Like adding another tag. Or spice information. Which would also need to support some form of the conditional syntax.
Very likely screw up. It is too large a change from the current implementation (which assumes a single part to a single moduleId by and large, with variants having a different moduleId.) I’m not being that ambitious , only considering things I think can be fitted in to the current constraints. The idea of an external script or program that converts this format to the multiple standard parts is probably the way to go here as that won’t break backwards compatibility. This does however bring up a good point, I hadn’t considered, a part that depends on new functionality won’t work in an older version of Fritzing which may be a problem. One way around that is to advise the user to upgrade to a newer version, but I don’t know if that is acceptable or not. If I am lucky, there might be a test for version of part higher than current version of Fritzing, that triggers a warning the part may not work, but I don’t think so.
Peter
Any documentation around on the variations for the current and older code? This comes from what should I put in the fritzingVersion attribute for the set of parts I am working on, to make them most widely usable? I was going to put 0.9.4b, since that is what I am using, but there is nothing special, that I know of, that should prevent them from being used with older versions of Fritzing. I saw reference to the change of color for silkscreen. Will the wrong color break older versions of Fritzing? With minimal work, I can test against 0.9.2b, and I think 0.9.3b using an appimage. But that is not very fine grained. I believe there were multiple smaller releases that all used those prefixes. The part intended to be obsoleted is marked with version 0.2.2.b.03.04.2550.
As usual no documentation that I am aware of. I usually use 0.9.4 as the Fritzing version because that is what it was made on. AFAIK there is only special code for some older versions of Fritzing where functionality has changed in the latest version and there haven’t been any such changes that I know of in the last two versions so your part should work in older versions. I don’t think there are a lot of older versions around any more. Some of the Linus folks are on 0.9.2 because that is what is in the app stores. The main change there is no parts editor I think (and possibly not copper1 within copper0 as well) which were added in 0.9.3b.
Peter
Exactly. But your earlier post about a new specification document would have allowed it.
For that particular case. I actually have some python code that comes close to doing just that. Because I have a different family I would like to do similar extension to that would be something like 144 fzp files. But other changes that fit in the part file format revision might not be so easy to work around.
That idea for a revised part format document needs some additional constraints to prevent this situation.
I doubt it. Not all users have the right knowledge to upgrade to a version that is not provided by the standard software management programs.
Or in the case of Fedora linux, what the package manager has. Unless you meant app store in a more general sense.
That possibility, or worse, silently failing, is why I want to know what fritzingVersion to put in the parts. My understanding from your usage descriptions says I want to put the lowest possible version that makes sense. In other words, the fritzingVersion value should be first/lowest fritzing version that the part is compatible with. Lower run time versions beware. The specified version or newer can safely process.
Again with lack of documentation, I’ll need to do some testing, to see what Fritzing does when that version number is higher than the currently running program. I can clone one of my parts to force a 0.9.9 version into the library, and try to run with 0.9.4b, or run 0.9.2b code against the library with 0.9.4b version parts.
@KjellM Do you have a suggestion where to dump some initial discovery information that will be collected doing that? Or better, reference to documentation that says what it should do.
Or maybe I can short cut the testing, with good confidence.
% grep -ri "fritzingVersion" * on the fritzing-app repository only found references in a few files. Ignoring the resource files, which are just data, most did not work with value variations. The exceptions are:
tools/scripts/resetversion.py does a bulk replace to change version numbers from 0.8.6 to 0.8.5 (probably for the schematic template change seen below).
src/autoroute/panelizer.cpp handles GroundPlane::fillTypeGround only for versions before 0.7.0
src/sketch/pcbsketchwidget.cpp only shifts pcb vias and holes after 0.7.2.b
‘src/model/modelbase.cpp’ has alternate processing for several cases. Quoting the comments:
// with version 0.4.3 ratsnests in fz files are obsolete
// with version 0.6.5 traces are copied to all views
// with version 0.7.6 mystery part spacing implementation changes
// with version 0.8.0 flipSMD is horizontal
// with version 0.8.6 we get a new schematic template
// with version 0.9.3 we don't have to worry about reversed wires
None of which seems to overlap with my parts. I can safely set the version the same as the single part I want to obsolete. 0.2.2.b.03.04.2550
And that points to another small 
project. The part check (or other validation code) should check the fzp and svg content against the rules for the specified version. Even better, parse against all rule sets, to figure out what the (minimum) version should be. Bonus if it can report the part content and rule that results in not being compatible with an older version.
From that search, no check or warning. It just silently does alternate processing for a few cases. Which could of course result in real error messages, or unexpected output, if the content contains features that do no match the specified version.
I did not see anything related to that in search results.
A new spec isn’t in the cards, my intention was to specify some of the things that aren’t clearly stated in the part file format such as stroke-width on lines in the svgs, length of connector pins, using the minimum space possible for parts to provide more room (and consistency between parts in core) to constrain already working function to a smaller more consistent subset, not add new function. My intent is to get agreement on a desired or at least acceptable outcome and then work on fixing the current core parts to match, which in itself going to be a lot of work. Some parts in core parts are just plain broken right now. Some are odd sizes, that is more than enough work for some time to come. Many of the changes I intend are already in places like the template files (which are also wrong in that they are 72dpi with px as dimensions currently and scale incorrectly in Fritizing if used as a template in modern Inkscape versions.
I think silently failing is unlikely, unless the part is
invalid. I think (but don’t know for sure) there are
relatively few special cases. I believe separate copper0 and copper1 (as was the original standard) is about the only one I’m sure of. I’ve made lots of parts and other than obvious invalid xml errors never had one fail by tripping over a special case in the code. There are a bunch of special cases around making breadboards, but they are specific to how a breadboard needs to operate (always on the bottom for instance.)
You should be able to just create a part as an fzpz file, and change the version and load it. No need to put it in core parts. The only difference with an fzpz file is that is is in the mine parts bin, not core otherwise it is processed the same.
Someone lately referred to the package manager (possibly in Fedora, perhaps one of the others) as the “app store” and I reused the term probably incorrectly.
It may be that the original code was just left in as copper1 not a group of copper0 still works fine and is useful for things like edge connectors that need different pads on top and bottom of the pcb which the copper0 inside copper1 can’t do.
Peter
Hi there,
I agree that we need a good reference documentation for the parts format.
I even see this documentation as a precondition, before we can even think
about improving the parts format.
This documentation should be made available
- on the website fritzing.org
- from within the desktop application
- as a printable cheat sheet (single page pdf with two or three columns)
Maybe the printable cheat sheet would be a good start?