Using property names in part creation

[microMerlin]

@vanepp

@microMerlin

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.

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.

Confirmed that it IS necessary to change the family property in the obsoleted part. If it is not changed, inspector offers it as a selection in the drop downs for other parts in the same family. Or more accurately, includes the property value from the obsoleted part in the drop downs for any matching property name, which when selected switches to the obsoleted part.

So should, but does not. In version 0.9.4b, commit c595162a1d06

Technically, it is not necessary to use that prefix I bulk sanitized previously. All that is needed, is to have the family of the obsolete part different from the family of any part that is not obsolete.

@microMerlin

@vanepp

So you probably need to figure out how to obsolete the current part with your new one.

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,

There was a sequencing problem in the old part, so I needed to add a replacedBy attribute to most of the connections as well. Doing the replace go the schematic view right. There were bogus wires added for (it looks like) all of the connectors with the replacedBy attribute. The way the showed up, it was easy to bulk select and delete those. Then a move (jiggle: move off and back) of the part on the breadboard got it to reconnect to the proper wires. That ended up deleting a bunch of traces on the pcb view though. Moving the part found bogus doubled pads under most of the connections. NOT the first couple of pins, which had a full replace. The names changed from “pin1” to “pin 1” and “pin2” to “pin 2”. Pin 3, 4, 5 were correct, and did not need replacing, but they did get the bogus pads. Starting at pin 6, all of the connector were being replaced by the same name, because the connector number was wrong (one off). Replacing “pin 6” with “pin 6” looks like a good opportunity for something to break. Doing the substitutions using the id instead of name got the the same (or at least very similar) result. Again though the replacements were overlaping. Change connector8 to connector7, change connector9 to connector8, etc. I also tried modifying the new part, changing the connector ids so that they do not overlap with ids in the obsoleted part. FritzingCheckPart complained about that, though I think it is technically valid (I changed the “connector” prefix on all of the connector ids to “cnnector”). Did not help though. Results looked a little different but basically the same problems. Just a couple of different traces on the pcb were messed up.

So either I am missing something for properly making a part obsolete, or there is a problem with replacedBy for connectors. I expect it is the same code, but to be complete, I said “no” on the initial replace requestor, then did the update from the part menu. Same results.

[microMerlin]

@KjellM

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?

For collaboration, the wiki for either fritzing-app or fritzing-parts would be convenient … for anyone with a github account at least.

[KjellM]

At some point, this documentation is as important as the implementation of the app. If enough parts just follow it, we will have to adapt the code. Of course it would have to be in document management (meaning, git). But with wiki, do you mean public write access, bypassing code reviews?
I’d like to automate syncing the documentation to the app and the website. With a public write access, this would require permanent monitoring…

[microMerlin]

@KjellM The wiki was an idea for collaboration, collecting, merging, referencing sources for related information. If needed, snapshots could be copy/pasted to more stable locations. That said, the wiki is itself a git repository, so it is under version control too. It is possible to git clone the wiki, just like the main repository, and push changes back. To really mess it up requires a lot more than just write access. An owner could force push completely new content, throwing out all of the history. Standard git commands work normally on the cloned wiki repository, so commits, when/who did, what changes are easy to check.

[microMerlin]

@vanepp

I should be able to clone and install your fork without problem.

The parts are up. Clone GitHub - mMerlin/fritzing-parts: Electronic components for use in the Fritzing app (aka the parts library) and switch to the “8x8_led_matrix” branch. The original (obsoleted in that repo) part was LBT2088AH. The new parts are «xx»mm_8x8_dot_matrix_«xxxx»_cathode_led_display«_narrow_pad». Once the database is regenerated, a search for “8x8” will find them all, and not much else. As mentioned a few posts back, the outdated part update process seems borked. At least for that part. Working on gathering the information for reporting that as a bug, but it is 4AM my time. Need to shut down for awhile before I start making silly mistakes.

[KjellM]

I know how github wikis work . Maybe I didn’t understand you suggestion about using the wiki, because that is what we already have; https://github.com/fritzing/fritzing-app/wiki/2.1-Part-file-format, you have contributed to that before. I am suggesting to raise the importance of this document: Making it the master for documentation on fritzing.org and the desktop application, and having it more complete to serve as specification.

[vanepp]

@microMerlin

Confirmed that it IS necessary to change the family property in the obsoleted part. If it is not changed, inspector offers it as a selection in the drop downs for other parts in the same family. Or more accurately, includes the property value from the obsoleted part in the drop downs for any matching property name, which when selected switches to the obsoleted part.

I would expect that that may break (but doesn’t necessarily seem to, if that is what was done) old sketches. Someone (when we find Someone of course ) needs to figure out and document the obsoleting stuff. From my single experience a couple or 3 years ago I suspect there are problems, but have never gotten far enough ahead to get back to it.

@microMerlin

So should , but does not . In version 0.9.4b, commit c595162a1d06

Thus the "(note the weasel word ) " comment above. I had a feeling there are problems in this area, just not the time to look at them.

@microMerlin

So either I am missing something for properly making a part obsolete, or there is a problem with replacedBy for connectors. I

From what I remember about how the part I tried screwed up I’d bet on either bugs or someone didn’t know how to do the replacement correctly (with my bet on bug )

@microMerlin

he parts are up. Clone GitHub - mMerlin/fritzing-parts: Electronic components for use in the Fritzing app (aka the parts library) and switch to the “8x8_led_matrix” branch.

I’ll grab a copy and have a bash at it.

@KjellM

I am suggesting to raise the importance of this document: Making it the master for documentation on fritzing.org and the desktop application, and having it more complete to serve as specification.

This is why I originally suggested revising the parts file format document. At present it is spread out between the template files (which as noted are wrong) the parts file format and the graphics standards with large grey areas that would be (in my view anyway) tightened down to make parts more consistent in appearance. I think none of it has been revised since the early years of Fritzing as well (certainly the templates.)

edit:

@KjellM

as a printable cheat sheet (single page pdf with two or three columns)

I’m liking this idea, that is probably a good place to start as it is more free form than the documents. If we can get that together and agreed on it should be able to drive the changes to the documents and provide context to why the document changes were made. I’ll start documenting the things I consider when making a part as a start to this (and probably post it in tutorials here, in text because pdf is yet another thing I haven’t done .)

Peter

[vanepp]

I have probably just figured out how to correctly fix the “editable pin labels”>true issue. The problem is likely they need to know where the pin label is to substitute the text. That is currently done by substituting a known svg (which has problems when the input svg doesn’t match a dip outline such as headers.) A solution to that is to require the pin labels in the schematic svg to have a specific label such as connector0pinlabel, if you want to set editable pin labels to true. If such a label does not exist, revert to the current code and substitute the svg (which may be wrong, but is now anyway.) If the label exists, then the code modifies the text in that existing label, without otherwise modifying the schematic svg (which is my desired outcome!) If one of the labels in the part doesn’t exist, output an error message that the part is misconfigured and the label can’t be changed. This needs a code change, but does not break backwards compatibility. I suspect with enough thought we can usually find a way to add functionality without breaking backwards compatibility.

Peter

[vanepp]

@microMerlin

The parts are up. Clone https://github.com/mMerlin/fritzing-parts.git and switch to the “8x8_led_matrix” branch.

As usual git has bit me. I cloned your repo, but

owner@owner-PC /cygdrive/d/repos/dMerlin/fritzing-parts
$ git branch

• master

No branches. I remember running in to this before but I don;'t remember how to get the branch tags. I’ll try switching to that branch on github and cloning that first.

Peter

[microMerlin]

git branch -r

will let you see the branches on github

git fetch
git checkout -t origin/8x8_led_matrix

or

git fetch
git checkout --track origin/8x8_led_matrix

should get you into that branch locally.

A web search for git checkout branch from origin got the answer as the first result. But that assumed knowing that origin was what remote was called by default.

I suspect your previous problems with getting updates from the master have similar simple solutions. Things get easier when you know the right words to use when asking the question. I suspect the word master is part of the problem. As you saw, master is the name of a branch. But the context I saw in your older post indicated you actually meant getting updates from the official fritzing-parts library repository. Searching for upstream in the question probably gets closer. I have some notes. Going away now to dig that out

[vanepp]

As usual StackOverFlow had the answer:

git clone https://github.com/mMerlin/fritzing-parts.git --branch 8x8_led_matrix

got the correct branch down. That said I don’t understand why cloning the repo doesn’t get the branches, that would seem to me to be an obvious feature. As to the three way sync, it has to be very common (clone a repository on github, clone that writable repo locally, then make a pull request and resync them all. All the examples I can find are for a remote to/from a single local, not to a “my remote” on github and then the master. Kjell suggested a bunch of fetch all --remote --upstream (don’t remember the exact syntax) commands but even with them my writable repository on github ends up several commits ahead and several commits behind fritzing-parts development. For instance now my fritzing-parts repo says

This branch is 4 commits ahead, 9 commits behind fritzing:develop.

when the two (I think) should be in sync. The only way I have found to get it in sync is to destroy my clone and re clone it. That is obviously wrong, but I can’t figure out how to do it, nor find any tutorial that explains how to do that exact thing (as I said all the ones I have found are local to a single remote, none with a write permissioned clone in the middle.) This is what keeps me from pushing parts to core most of the time, it is just too much hassle. With your repo in hand I’m just making a test sketch of the original part so I can substitute in your repo and see what happens.

Peter

[microMerlin]

@vanepp

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).

Here is the situation I am guessing you started from.

• You forked the GitHub - fritzing/fritzing-parts: Electronic components for use in the Fritzing app (aka the parts library) to your own github account
• You cloned your forked repository to your local machine
• you did some work, probably in the master branch, on the local machine
• you wanted to get more recent changes from the GitHub - fritzing/fritzing-parts: Electronic components for use in the Fritzing app (aka the parts library) repository

From the wording in your post, I’ll start by clarifying what actually happens in those steps. Forking fritzing/fritzing-parts takes a snapshot copy of the repository and puts in your own github accounts (vanepp/fritzing-parts). Cloning that snapshot to your local machine makes another copy, but maintains a link back to github (the remote) about where the copy came from, and where to send (push) information back to. That is the origin remote that git remote (or git remote -v) will show. The cloned repository on your local machine does not start out knowing anything about the fritzing/fritzing-parts repository. It has no path to get there. There is no (automatic) process to get any changes from fritzing/fritzing-parts into either vanepp/fritzing-parts or your local working repository. To get updates from fritzing/fritzing-parts, you first need to add that as another remote to your local clone.

git remote add upstream https://github.com/fritzing/fritzing-parts
git fetch upstream
git fetch upstream --tags

In that, upstream is whatever name you want to use to reference that repository. upstream is just a convention for the parent of the origin repository. The fetch commands gather some information about the remote, and add it to the local repository. Now, git remote «-v» will show both remotes, and git branch -r will show branches that existing in each remote repository.

Getting synchronized (caught up) with the changes data in the master branch of fritzing/fritzing-parts takes a few steps. If you have changes in the master branch of your local copy, additional work may be needed to merge the 2 of them. The basic steps are:

git fetch upstream
git checkout master
git merge upstream/master
git push

The fetch just makes sure the local information is current about the remote repository. Checkout makes the master branch active in the local repository. If you only been using the master branch, it will already be active. merge says to actually get the changes in the upstream remote, master branch, and add them to your local copy. push then sends those changes to the origin remote. Or where ever the local master branch is configured to push them.

If you have changes in your local master branch that are not in upstream, you could get conflicts that require manual intervention to get the merge to complete. That is a whole other topic. The way to avoid the problem before it can even start, is to NOT make any changes in the local master branch. Instead, do any work in a separate project specific working (and probably temporary) branch. Like the 8x8_led_matrix branch I pointed you to for the parts. To do that

git checkout master
git checkout -b «projectName» --track origin/«projectName»

That creates a new «projectName» branch locally based on what is currently in the (local) master branch, and tells git that it is to be synchronized with the same branch name on the origin remote. When git push is used. Linking the local branch with the remote could be done later, but if the intent is to push it up to github, in preparation for a sending a pull request to fritzing/fritzing-parts, might as well do it when the branch is created.

There are multiple branches in fritzing/fritzing-parts, and probably in vanepp/fritzing-parts. Each of which can be brought up to date (somewhat) similarly. If you already have the branch in your local clone,

git checkout «branchName»
git merge upstream/«branchName»
git push origin «branchName»

will synchronize «branchName» in upstream, origin, and the local repository. If «branchName» exists in upstream and origin, but not locally, replace the checkout with

git checkout --track origin/«branchName»

If «branchName» exists in upstream, but not in origin or locally, change checkout to

git checkout --track upstream/«branchName»

That should provide the basic commands needed for the common situations.

@vanepp

That said I don’t understand why cloning the repo doesn’t get the branches,

Cloning a repository (without extra arguments) gets the data about the branches, or at least a link that can get them, but only pulls the data for the master branch. Or actually the main branch as configured on the remote repository. What I provided first time, was how to tell git that we are interested in another branch once the initial clone is done.

@vanepp

As to the three way sync, it has to be very common (clone a repository on github, clone that writable repo locally, then make a pull request and resync them all.

Yes. See notes above. Handled one branch at a time, not for the whole repository.

@vanepp

This branch is 4 commits ahead, 9 commits behind fritzing:develop.

when the two (I think) should be in sync.

That happens all the time. The “4 commits ahead” are the changes you did locally, committed, and pushed back to github (origin), but have not (yet) been merged (you did a pull request right?) with upstream. The “9 commits behind fritzing:develop” are because of someone else changes that have been merged into the github repository, after you did the fork (or after the last time it was synchronized).

From that, I assume you are working with the “develop” branch. If you use the separate working branch I suggest above, that sort of message can be totally ignored. The branch can just be deleted (from local and vanepp/fritzing-parts) once the pull request has been completed. Instead, just resync the develop branch, that does not have any of your local commits in it, and create another project branch from that for the next batch.

If there are no conflicting changes between your “4 commits ahead” and the other “9 commits behind”, you can get rid of the 9 commits behind by doing a merge. Assuming upstream is stetup

git checkout develop
git merge upstream/develop
push origin/develop

@vanepp

With your repo in hand I’m just making a test sketch of the original part so I can substitute in your repo and see what happens.

I expect that to break all over the place, especially in PCB view. The original idea was to exercise my new parts a bit, and check for anything I missed, and the part checker did not complain about. I did not put the cleaned svg files back in the repository. The hand crafted svg files I used are fairly clean, and structured with a few comments. From other posts, you/Fritzing have had issues with transforms. I use them (sparingly) so that some blocks of svg can be directly cloned when the same thing appears in multiple locations, or to provide an offset so that the coordinates are simple multiples of 0.1 inch.

[microMerlin]

@KjellM

Maybe I didn’t understand you suggestion about using the wiki, because that is what we already have; 2.1 Part file format · fritzing/fritzing-app Wiki · GitHub, you have contributed to that before. I am suggesting to raise the importance of this document: Making it the master for documentation on fritzing.org and the desktop application, and having it more complete to serve as specification.

That works for me. Your previous post said fritzing.org. Nothing there mentioned the wiki, which is on github, not frizting.org.

@KjellM

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?

So I added wiki as a place to do the work. Yes I contributed there before, but it was to add one line that was obviously missing. I did not feel official enough to do much more. If WE are going to be expanding that, the first thing I would like to do is add some more navigation and cross referencing. That is written like a hard copy book. At least like a chapter in a book. With web and links, some table of contents and other links can make locating information a lot easier.

If that is the direction forward, unless there are objections, we could also use a thread (or several) in the repository issues for discussion about organizing, missing content, other references, etc the wiki page content.

@vanepp

@vanepp

I have probably just figured out how to correctly fix the “editable pin labels”>true issue.
…
A solution to that is to require the pin labels in the schematic svg to have a specific label such as connector0pinlabel

Or have an id, then reference that in the schematicview section of the fzp file. Add a labelId attribute to go alongside terminalId. That by itself could be enough to enable editing, and also provide a fine grained method of selecting only specific connectors for label editing.

Whoever is doing the work on the svg better consider what placement is going to look like if the string length changes. Set the appropriate text alignment.

[vanepp]

@microMerlin

I expect that to break all over the place, especially in PCB view. The original idea was to exercise my new parts a bit, and check for anything I missed,

Actually it seems to work fine. The update went in without problems and everything appears to work. Started with this test sketch with the original part:

test-orig-master.fzz (8.6 KB)

Then installed your new repo, regenerated the database and loaded the sketch:

yes

Compressed a bit as you moved schematic back to .1 boundaries, but handled fine (so possibly the problems in update I remember seeing are bad part configuration, not a bug.)

Setting dot size narrow via inspector moves in breadboard, but a reposition fixes everything:

Then I ran through all the combinations in Inspector and checked DRC and appearance, and except for sometimes having to move things everything looks fine. One thing I did notice is when changing matrix size in any view I get a message on the bottom of the screen “No exactly matching part found: fritzing chose the closest match” but the change appears to work correctly. So I’d say this looks fine so far.
As to github, I started from a clone of the parts development repo, in to my fork on github, cloned that locally, created a branch and made and pushed a part. It got merged, but Kjell made a few changes, so I tried to resync my repo with those changes but wasn’t successful. As part of that I did set an upstream value (I currently don’t remember how to display it) and did fetches of various kinds without success. I’ll try your command set and see if I can get the three ins sync and do another pull request and see what happens.

Peter

[KjellM]

The referenceFile attribute seems only to be used by the parts editor.
I read it as “as long as the part does not have its own svg, use that of the referenceFile”.
I don’t think we need to warn it the referenceFile does not exist.

 ...
 2880:  QString PEMainWindow::getSvgReferenceFile(const QString & filename) {
 2881:  	QFileInfo info(filename);
 2882: 	QString referenceFile = info.fileName();
 2883  
 2884  	QFile file(filename);
 2885: 	if (!file.open(QFile::ReadOnly)) return referenceFile;
 2886  
 2887  	QString svg = file.readAll();
 2888: 	if (!svg.contains(ReferenceFileString)) return referenceFile;
 2889  
 2890  	QXmlStreamReader xml(svg.toUtf8());
 ...

[microMerlin]

@KjellM

The referenceFile attribute seems only to be used by the parts editor.
I read it as “as long as the part does not have its own svg, use that of the referenceFile”.
I don’t think we need to warn it the referenceFile does not exist.

So having the refenceFile point to the file it is in does not actually make any sense. To be at all useful, it needs to point to a different fzp file, and even then it is useless unless the current fzp file is missing references to svg files. I did not know that last qualifier was even valid.

[vanepp]

I wonder if this is intended to allow reuse of svgs already in core parts (although I don’t necessarily see how?) One thing on my list of enhancements is a way to specify in the layers section an svg already in core parts so (for instance) pcb footprints can be reused. 10s of copies of the 14/16/20 dip svg as current is wasteful of disk space and network bandwidth when using a single copy in core parts makes more sense. As usual nothing has happened about this other than it being on my list of things to do at some time in the future …

Peter

[fai]

@microMerlin

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?

Long thread, so I did not read all of the messages. Apologies if this has already mentioned or I missed somthing.
I think one way of achieving this is to edit the resources/properties.xml file. There you can specify if a field is editable (and other properties of the field). The only problem is that it will only work if the part is based on the Capacitor class.
You can check the src/items/partfactory.cpp code. If a custom version of Fritzing is a ok for you, you could add the moduleId of your part in line 195 of partfactory.cpp. Or even better, address the TODO that is just above (line 194) and implement a way to do this for all the moduleId that are in the properties file.