One more note;

I checked out the last released build instead of Master or Develop.

and then copy the commit hash a1ffcea08814801903b1a9515b18cf97067968ae
and run

git checkout a1ffcea08814801903b1a9515b18cf97067968ae

I haven’t had a look if this hash is also the latest one in the master branch but i have a feeling it isntt

I can probably add some information to this. I had the same issue running the flatpak stable release from flathub also on Fedora 31. Which is 0.9.4b. I reported that (only) on the fritzing section of flathub at https://github.com/flathub/org.fritzing.Fritzing/issues/8

The problems seems to be QT and Wayland not mixing well yet. The solution (actually work around) was to tell flatpak to run Fritzing with --env=QT_QPA_PLATFORM=xcb, which overrides the default (new) wayland with the older x11. Problem solved.

Now, I do no know for sure what it would take to get Fedora to run a single application under x11. Flatpak is a wrapper/container, so is easier to specify. There have been notes on the net about running newer Fedora versions under x11 instead of wayland, as a global solution. I do not think much of that, since it affects too many other things. This MIGHT be as simple as (from the command line)

QT_QPA_PLATFORM=xcb Fritzing

If 0.9.4b is good enough, you could use the flatpak + flathub version. Or learn how to turn your own build into a flatpak, then try the xcb/x11 override. There are a couple of gotchas getting Fritzing up on flatpak. Especially if you are not running other flatpak applications. One of the dependency needs a manual install. The following (from my notes) should work.

flatpak remote-add --user --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
flatpak install --user flathub org.freedesktop.Platform
flatpak install --user flathub org.fritzing.Fritzing

I prefer to do the installs in the user instead of system environment. If you get a multiple versions message for the platform, pick the latest (currently 19.08). Then to run

flatpak run --env=QT_QPA_PLATFORM=xcb org.fritzing.Fritzing

which I put in a 2 line fritzing script

#! /bin/sh
flatpak run --env=QT_QPA_PLATFORM=xcb org.fritzing.Fritzing "$@" &

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?

I updated and lost all my projects

the fritzing map on windows documents is empty

Is there a way to get them back?

Which operating system and what did you update (presumably the fritzing app, if so which versions from and to)? By projects do you mean your custom parts in the mine parts bin or something else? In general Fritzing preserves the user directories during an upgrade and the mine parts bin should be there and be recoverable (they are in different places depending on operating system though.) If you mean the recent sketches window on the welcome page, yes as I recall that gets cleared in an upgrade, but the projects are still present in the file system and will populate the recent sketches window when you open one via file->open then navigate to the .fzz file for the sketch and click on it.

Peter

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

Peter

I actually only changed 2 files

1. The pcb svg file. The pcb svg looks ok to me but agree that in inkscape the schematic svg looks ok but in fritzing schematic it does not. I did not change the schematic. Also not sure what you meant by copper1. Anyway I ungrouped the entire image in the pcb svg but have not tested further.

2, I changed the FZP file ie QFN TQFP package in the XML.

I am not all that familiar with editing these file and need some help to clean it up as I am not sure how to proceed in getting an FZPZ file that I can use when requesting board manufacture.

Thanks

Ian

Besides the support for ~300dpi, there are also the issues of broken dpi configuration on user system, and dual screens with differing dpi settings.

My development system has about 150dpi… seems there are not many external monitors that go higher than 185dpi, at least not from the brand I checked. @120thingsin20years I guess you are on a notebook?

I’ve been distracted trying to reproduce a bug (found 2 more, not related but still not the original one) so I’ll try and figure out why schematic is wrong, it shouldn’t be.

You need the silkscreen and copper1 groups or pcb won’t be correct. A through hole part has copper1 with copper0 as a group under that, for SMD (which this is) only copper1 is needed. Removing copper1 should have removed the translates, now you need to select all the pins and group them and name that group copper1 (and all the black silkscreen lines in a group called silkscreen if you also ungrouped them.)

If you post the .fzz file for the final sketch (which will include your part as it isn’t in core) I’ll check it over. Normally the final step is in pcb view File->Export->for Production->Extended gerber. Which will ask for a directory. When you click OK it writes the gerber files which the board house then accepts to make boards. It is a good idea to use a gerber viewer (I use gerbv from the geda project, but there are lots of them) to read and display the gerber files so you are sure the gerbers reflect the real board (there are a number of gerber related bugs in Fritzing.) Then you zip up all the gerber files and send that zip file to the board house.

edit:

My original part has the same schematic problem (I’m not sure how I missed that when I tested it), but I can’t figure out why or how it is making the changes. I have verified (by changing text) that is loading the supplied schematic svg, but I can’t see anything wrong with the svg and have never seen Fritzing do this before. I’ll keep poking.

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 https://github.com/fritzing/fritzing-parts/blob/master/CONTRIBUTING.md. That seems to be incomplete, or changed. I did a bulk cleanup to adjust the family names in the obsolete parts https://github.com/fritzing/fritzing-parts/pull/158. 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

how can i find the lm383 in fritzing
or anyone got a download file which i can import in lm383
that how it usually looks like

NS_LM383T_IC-1200x9001200×900 91.1 KB

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 https://developer.mozilla.org/en-US/docs/Web/SVG/Element/desc 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

A google search for “fritzing part lm383” doesn’t turn one up, so there likely isn’t one. It is easy enough to make one though, although the footprint is a little odd. Probably tomorrow some time.

Peter

Found the problem. With “editable pin labels” set to true Fritzing substitutes a hard coded svg internally for schematic (presumably so it knows where the pin labels are.) I replaced my original part with one that has the schematic svg modified (and which looks invalid but isn’t as it will be substituted) to match the substitute svg so the labels and outline are in the correct place. Long term, I would like to remove that hard coded svg from the code because as noted it is ugly and violates the rule of least astonishment.

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.