Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Further development of Fritzing, open for discussion #3435

Open
PatrickFranken opened this Issue Feb 4, 2019 · 157 comments

Comments

Projects
None yet
@PatrickFranken
Copy link
Contributor

PatrickFranken commented Feb 4, 2019

At FOSDEM 2019 I gave a short talk on the challenges of the Fritzing development. For everyone who wasn't live, here is a link to the recording.
https://video.fosdem.org/2019/AW1.125/fritzing.mp4

More details to follow.

@falkorichter

This comment has been minimized.

Copy link

falkorichter commented Feb 4, 2019

👍

@vanepp

This comment has been minimized.

Copy link

vanepp commented Feb 4, 2019

First off, good to see someone else interested in keeping Fritzing alive. As you should see from issue 3418 there has been talk but essentially no action about restarting development. I agree there is little point to a fork, in my opinion a fork isn't going to help, what is needed is people willing to help and they appear to be in short supply. I have been trying to restart development for more than a year now with little success. Currently (reference issue 3422 which I opened in September) Fritzing part update on Windows is broken. That is due to bit rot as was referred to in your talk. I have a fix: update the libgit2 lilbrary to a later version that supports tls1.2 on Windows (the version used only supports tls1.1 which github no longer supports). Sounds easy, just compile and go. However not so, as the development environment (which is poorly documented, which I am trying to change by documenting what I am doing to get an environment running.) As far as I can see no one else has a working development environment any more for Fritzing or this issue would have been fixed, as a simple (or as I have found, not so simple) rebuild with a later version of libgit2 will fix the problem. I am currently working on fixing that, but there is a way to go. At present the latest version of Qt asserts and crashes Fritzing due to tspans in some parts in the parts repository. I am just about to file a pull request to fix the 8 parts involved (just finished testing last night). Unfortunately Qt appears to have back ported the assert to Qt5.6 (which Fritzing 0.9.3b was compiled with) so just rebuilding with the previous version and a new libgit2 also doesn't work. In addition as of last summer (I haven't checked lately) the open source Qt version for Win32 wouldn't install (and hadn't for several months) so creating a 32 bit version may require a cross compile environment which I at present don't know how to do (I have no previous experience with Qt). This issue only (as far as I know anyway) affects Windows, Linux (and probably the Mac which is Unix as well) used tls1.2 from the start and still work fine. The largest segment of the user base however is likely Windows and they are also likely unaware that parts update is broken as no error message comes up, it fails silently. That hasn't been all that important because there also haven't been any parts updates since last June (I suspect largely because new parts are being submitted mostly in the fritzing forum rather than as pull requests here which is the only way part update happens any more). Once (or more correctly given progress so far if) I get the windows bug fixed, then comes the issue of finding or buying a Mac to build and test new releases for the Mac on. At worst I could buy a Mac and it may well come to that. Then we will see if we can convince anyone to commit to a new release. I think there is still interest from some of the original developers in seeing Fritzing continue, but their time is limited. What is mostly needed as indicated in your talk is people capable of development with the time and interest to do it. I have the time (I am retired, and my time is my own) and the interest but perhaps not the skill, but I so far seem to be the only one. I will post a link to this discussion in the Fritzing forum developer section, as there may be some people there that are interested as well (I normally don't pay that much attention to this forum for instance). In addition some history (although it was before my time with Fritzing): Fritzing originally started out as a funded research project which meant the development team was full time committed to funded development. When the funding ran out it became an open source project with the two entities you mentioned. I have heard that the funding goal to continue development is 40K euros and the pot is currently around 6K euros. I suspect that the developers have gone on to other things by now and even if the money should appear (which seems unlikely) development is unlikely to be able to restart. That means it is up to us if we want to see Fritzing continue.

Peter

@ILYB

This comment has been minimized.

Copy link

ILYB commented Feb 6, 2019

I am one who has benefited from using Fritzing as a novice in the world of PCB design and manufacturing. I applaud the effort to keep Fritzing alive so that others may benefit from it's unique interface and functionality. I wish there was something I could do to contribute to its ongoing availability.

I'm not clear if using Fritzing Fab helps to accomplish this goal or if the royalties are being directed to some other entity and therefore not helping to pay the bill so to speak.

@el-j

This comment has been minimized.

Copy link
Member

el-j commented Feb 8, 2019

thanks @PatrickFranken for this talk! so, from my point of view we need a change to a new way of writing fritzing. the build environment is to complicated as well as coding in c. i think we should build a fritzing-js webservice that is independent and running on open-providers. we can do this with very low cost. i just finish my thesis about fritzing and the future, i even have ideas for a new view...

so:
there are already steps to bring fritzing to js. a few days ago i started the freetzing organisation here on github. together with @karpawich @paulvollmer
i think splitting form this old software, the bugs and the fritzing name will help the project to grow in future.

cheers + thanks
fabian

ps: anyone who wants, please like this, i will invite you

@HaraldRau

This comment was marked as off-topic.

Copy link

HaraldRau commented Feb 8, 2019

I use fritzing in school to teaching children. The Calliope Mini is currently being introduced in many schools. It is a micro controller with a CORTEX M0 prozessor.
I have tried to integrate the component in the library. I succeeded with medium success.
We look forward to the future development of Fritzing and hope for success.
I offer training for Calliope Mini and Fritzing for teachers in Brandenburg. This is the only thing that I can do.
I also asked the University of Potsdam for an opinion. I did not get an answer. This is verry pity

Excuse my bad English,
Harald!

@vanepp

This comment was marked as off-topic.

Copy link

vanepp commented Feb 8, 2019

@HaraldRau : If you would like some help with your Calliope Mini Fritzing part please feel free to post it on the fritzing forums and I will give you a hand with it.

@el-j : Sorry, but I'm poor at github, how do I "like this" (i.e like t this post or more probably the freetzing post, and how do I "like")? I'm interested but utterly ignorant of java script , and thus most likely to be of help with fixing up the parts repository.

Peter

@el-j

This comment was marked as off-topic.

Copy link
Member

el-j commented Feb 8, 2019

@vanepp ah sorry for this confusion... all these different ways platforms work, i totally understand you...first i wanted to get a pm ... but this is not possible on github anymore ;)
anyway: if you look there is a little smiley on the top right corner of every post. ;)
image

@el-j

This comment was marked as off-topic.

Copy link
Member

el-j commented Feb 8, 2019

@HaraldRau i made an issue for the part in the fritzing-parts repo, if you need any help ...
fritzing/fritzing-parts#171

for later purposes: i thought of making the parts an own organisation too. so every parts is a repository, and we could maintain every part individualy and keep track of the inventions or development of the part - what do you think about that idea?

@WimberleyTech

This comment has been minimized.

Copy link

WimberleyTech commented Feb 8, 2019

Thanks Patrick, for the presentation. It was very informative. Thanks Peter for all you do on the Fritzing forum. I have never asked for help but I often see you helping others with parts issues primarily. You are a saint.
I am a professional--retired (40+ years in the semiconductor business), but I use Fritzing for my hobbies and have used Aisler for fab four or five times (excellent!). I have also used Fritzing to mentor young budding engineers! I think it is a wonderful tool and it needs a new life or maybe just a shot of adrenaline. I am not a programmer (not at this level anyway) so I cannot help in that regard, but I would like to help in some way. The bucket of money that was once allocated to developers (goal never reached) seems amazingly small to me. Could progress really be made with such a small investment??
The legal issues seem a little daunting. Patrick loves the name, but if progress could be made by severing the Fritzing link, then so be it. In terms of funding...if the entity/legal aspects could be resolved so that when money comes in, it is used for the "real" effort, then I bet you would be able to get investors...I would invest.
Thanks again for getting this discussion started!!

@vanepp

This comment has been minimized.

Copy link

vanepp commented Feb 9, 2019

@el-j wrote: "for later purposes: i thought of making the parts an own organisation too. so every parts is a repository, and we could maintain every part individualy and keep track of the inventions or development of the part - what do you think about that idea?"

I'm not clear how this would work, if every part is its own repository how do the projects (current Fritizing and the new one) find the parts? This has the potential to break the current fritzing or at least freeze its parts inventory which is depending on the parts being in a single repository (at least I think that is the case). I expect lots of people are going to still use the current Fritzing at least until something totally breaks it (such as a fatal api incompatability due to OS changes such as libgit2 on Windows currently). If something can be worked out where individuals own repositories so you don't have the entire burden of maintaining the parts repo that would of course be good. It could also allow (probably via the release or tag mechanisms here although I can't say I really understand either of them) maintaining older versions of parts for old sketches which would be useful I expect.

Peter

@PatrickFranken

This comment has been minimized.

Copy link
Contributor Author

PatrickFranken commented Feb 9, 2019

Dear all, sorry for the radio silence!
I totally agree on the technical debt explained by @vanepp et. al., this is something I'd love to work on, too. But first there has to be someone who really kicks ass and gives a straight development roadmap. There is no doubt that we've some great developers around here but the effort has to be focused otherwise it'll just go down the drain. From my own experience I can tell that just organizing requirements, issues, pull requests, feature requests, media requests, public relations and such is a full time job by it's own. Because of this such a person should have some basic development knowledge but should not code on her or his own.
If someone knows someone shout out @el-j @falkorichter @WimberleyTech @HaraldRau
As said during the talk AISLER shares this vision why they would give part of Fritzing Fab earnings to fund a maintainer. That should be enough to pay at least a part time person.

Patrick

@vanepp

This comment has been minimized.

Copy link

vanepp commented Feb 9, 2019

My sense of the problem (which may well be wrong, since I am just someone interested in Fritzing) is that there isn't agreement from whoever controls the Fritzing brand on a way forward. What I would like to see is the Javascript project proceed as part of Fritzing rather than in a seperate project. I gather (again perhaps incorrectly) there isn't agreement from who ever controls Fritzing to do that. I have a short term roadmap of what needs to happen to support the current version: first a part repository fix to remove tspans from some parts, which I made a pull request for yesterday (that has taken me the last couple of months to arrange), to avoid Qt asserting and crashing Fritzing. Following that configure a working development environment for all platforms (Linux is easy, Windows and apparently the Mac less so) then document that so other people can do it (assuming we can find anyone interested, which hasn't happened so far). Then compile for both Windows 64 and 32 a copy of the 0.9.3b release with a new copy of libgit2 to fix the current bug that automatic parts updating is silently failing. Once that is done, then we will see if a new release for at least Windows of either head or (more likely due to lack of testing on head) the stable 0.9.3b code can be done. I can't do it, I don't have access (nor probably the necessary skills). Another short term goal is to arrange for a development release download on the web site (which of course presupposes a working dev environment) so we could publish a version of the current head for people to test to find out if it is stable enough to release. I think at present there aren't enough changes in head to make a release worthwhile, but there is currently a chicken and egg problem because of no way to get a development release to users for testing. As a data point, in the Fritzing forums over the last couple of days a Mac developer with experience in Qt tried to get a development environment going. He was unsuccessful and I believe has currently given up. This is a major problem, as even when we have someone interested in maybe helping they are unable to do so. Better documentation may help we will have to see.

Peter

@karpawich

This comment has been minimized.

Copy link

karpawich commented Feb 9, 2019

@PatrickFranken

Introduction

First off, that talk was great. I am from America, so I never understood the context behind why Fritzing development died. Now I do!

Second, in both your talk and your comments here, you emphasize the need for a clear direction, or a "straight development roadmap", as you called it. As @el-j mentioned, there are a few of us in the Fritzing community who have a direction like that in mind. Right now, that includes @el-j, @paulvollmer , and me.


A new direction

1. Fresh start

I'm glad to see from your talk that I am not alone in my shock at the over 1100 open Issues on the fritzing-app repository. Instead of bothering with a fork, we created Freetzing as the home for the future of Fritzing-related work.

2. JavaScript

According to the Stack Overflow Developer Survey 2018 and Github's State of The Octoverse 2017, it is no surprise that the most popular programming language today in the open source community is Javascript. As a member of this community, I can tell you that another key reason why Fritzing development has slowed is because of the entry-level knowledge base required by C++ and Qt.

TL; DR Any future iteration of Fritzing almost has to be written in Javascript if it has a chance of sustained maintenance.

3. Modularity

In addition to the barriers imposed by C++, navigating your way through the Fritzing source code and documentation is no walk in the park. The cause of this issue lies in Fritzing's monolithic architecture. While the developers did attempt to segment their code according to the MVC (Model-View-Controller) model, the magnitude of the application still prevents new developers from understanding how Fritzing works to start fixing it.

TL; DR Any future iteration of Fritzing must therefore be broken down into separate and distinct modules that can be maintained by smaller groups of developers.

4. Immediate next steps

Right now, we are already beginning our mission to keep Fritzing alive. That starts with fritzing-js, a Javascript library and npm module that will act as the bridge between Freetzing and Fritzing through importing Fritzing data files into the Javascript environment. From there, we plan to develop a new data model that will help simplify current Sketch and Part data so that we can lower the entry level for new developers interested in working with us on the project. We have the rest generally planned out, too - this is a just a taste of whats to come for the future. If you're interested in talking more, you can reach me at my email..

max.karpawich@gmail.com

The same goes for anyone else interested in keeping Fritzing alive. You can find our current work over at Freetzing.

@karpawich

This comment has been minimized.

Copy link

karpawich commented Feb 9, 2019

@vanepp I have been working on the JavaScript port for a few months now, and from my experience, attempting to stay inside the Fritzing organization just won't work in the short-term. I have no issue with eventually migrating back over to Fritzing, but for right now I think that there is no harm in working under a different name while a new version is still under development. See my comment above for more details about the Freetzing project.

@vanepp

This comment has been minimized.

Copy link

vanepp commented Feb 10, 2019

Fair enough, I will admit the current state of things is pretty non functional, but I'm concerned about fragmenting the user base even further. The forums being dead to new users for close to 6 months due to capacha problems has already driven forum usage down a fair bit, it is slowly picking up again after that got fixed. I think a large part of the user base doesn't use the foruns. anyway. I did download the early versions of the javascript code but couldn't even figure out how to install it and never did figure out how to run it (possibly because it wasn't installed correctly). I'm old, I know C and C++ the modern stuff not so much. I've currently done something so github won't let me (or I have forgotten how I did the first couple, I remember doing something somewhat odd, but not exactly what) make pull requests against the parts repo.

Edit: I should have added that I worked in a university data center for 20+ years before retirement so I can make a good guess about where the problem lies ...

Peter

@karpawich

This comment has been minimized.

Copy link

karpawich commented Feb 10, 2019

@vanepp Which parts repo are you speaking of? I might be able to help.

@KingDarBoja

This comment has been minimized.

Copy link

KingDarBoja commented Feb 10, 2019

@vanepp Glad to see some familiar face around this discussion. So basically there is some folks that want the project to stay alive as I did way back at 2018 (Yeah, been a long time). I am glad that Javascript can be used as the base language for this new fork(?) so Fritzing idea can be available to any developer.

I have nothing against C++ but the fact that Fritzing requires Qt to be built is already a pain for most of us. If there is anything I can do, I am willing to help with the cause, my only downside is related to my current Job as Front End Dev using Angular 2+ (I am not an expert at JS but more like at TS?) so probably don't have too much time right now.

@vanepp

This comment has been minimized.

Copy link

vanepp commented Feb 10, 2019

@karpawich "Which parts repo are you speaking of? I might be able to help.": fritzing-parts, it is just ignorance on my part :-) , I managed to initiate a couple of pull requests, but on the third I've forgotten how I made the first two work (and failed to write it down). It does the compare between my fork and the nightly-build repo, says it can't automatically merge (which is odd because it is a new part) but I can still make a pull request. The problem is there isn't a pull request button there. I think I had to change to somewhere else to get the pull request button and now can't remember nor figure out where that was.

Peter

@el-j

This comment has been minimized.

Copy link
Member

el-j commented Feb 11, 2019

@vanepp i will check this

@el-j

This comment has been minimized.

Copy link
Member

el-j commented Feb 11, 2019

@vanepp so i merged most of your pull-request because "i trust you" about your parts. this opens a new world here that has to be solved: PARTS_CREATOR
it is really necessary to build a parts-creator so creating and contributing parts gets more straight forward for all users. i see the parts-creation as one of the main "pain" points.

@vanepp

This comment has been minimized.

Copy link

vanepp commented Feb 11, 2019

Thank you, now I can see if something about unmerged pulls was blocking further requests (there is a second board for the Sony part that I can't make a pull request for) or I'm doing something wrong. My bet is I'm doing something wrong. As I said, I think the parts creation area is where I can be the most help. I know part creation fairly well now, and the FritzingCheckPart python script is getting some additional checks added (to remove tspans for one). I'd like to get it to the point of being able to remove translate/transforms because I think (without any proof yet until i can insert timing code in to Fritzing which requires the dev environment to run ...) they are a performance problem. A transform or translate I think causes a matrix multiply at every render. If you pre apply the transform / translate at part creation time, you should save that multiply on every render. That is only somewhat possible with Inkscape though, ungrouping wiill remove many transforms but not all (rotation in text and polygons and often paths are some that don't get removed for some reason.) I would actually think this would be an important optimization fro web pages too, because they should face the same issue. Whether it is a signfigant saving or not I don't know yet. I do know that parts using subparts cause Fritzing to slow down noticeably when there are 8 or 10 of them present. It should also be possible to rapid prototype a simpler part creation process in python, then when I have something work able recode it in the language of the day. I guess we will see as this progresses.

Peter

@karpawich

This comment has been minimized.

Copy link

karpawich commented Feb 11, 2019

@vanepp What is your email? I'd like to talk with you a little more in detail about your knowledge of Fritzing parts.

@vanepp

This comment has been minimized.

Copy link

vanepp commented Feb 11, 2019

vanepp@sfu.ca will find me.

Peter

@karpawich

This comment has been minimized.

Copy link

karpawich commented Feb 12, 2019

@PatrickFranken are you aware of any legal restrictions on developing a spin-off of Fritzing? Patents, etc..

@Marco-exports

This comment has been minimized.

Copy link

Marco-exports commented Feb 13, 2019

I am in awe of the whole Fritzing initiative !
As a veteran developer of desktop and client/server apps, I was able to shift out to cloud computing and hardware IoT solutions, learning Arduino, using Particle.io devices, and now an ambitious RPi project for home automation. I've built 0-10v control devices that can speak to Arduino and RPi, to control Sabiana fan coils and Rockwell valves for A/C chillers in homes. I built 0-12v switches for door security, also to turn down A/Cs when guests leave doors open. I made tiny distance sensors to turn LED strips on/off inside cabinets. I'm now designing boards to control cistern tank with alert-low and alert-high magnetic sensors, using "latching-relays" to turn on cistern 220v 3/4hp pressure pump. All of these will be on my future web site, offering Fritzing files with logic diagrams that tie entire house into Node/React apps that you can manage from an iPhone or iPad.
Bravo to the entire team behind Fritzing, and thank you for making all of this "open source" for us to learn and develop from. I hope to contribute back soon.
Marcus

@benreu

This comment has been minimized.

Copy link

benreu commented Feb 13, 2019

I use Fritzing for my one man PCB production business (operating since 2013). I would like to help with coding or wherever I can. I am fluent in Python, Gtk and Inkscape, but have very little experience in C++ and Qt.

One question is, if we are going to use JavaScript, what GUI toolkit is going to be used? Does Qt have JS support?

At this time, I do not have the capability to help with funding. I do have quite a bit of parts that I use (created with Inkscape) that should be with the Fritzing parts.

I am very glad to see somebody pick up this project. Cheers!

@Quidtie

This comment has been minimized.

Copy link

Quidtie commented Feb 13, 2019

I’m a new user. I had Some trouble with this issues:

  • Importing a pcb-design from Inkscape. There should be an easier way (a 1 layer design on wich you can later (in fritzing decide how many layers you realy want)
  • exporting gerber files. Especialy the outline file was not as it should be! Missed circle- and rectangler-shaped cut-outs in the PCB. Also Some file extensions were in the wrong format (but changing the file extensions fixed the problems)
@BKeyport

This comment has been minimized.

Copy link

BKeyport commented Feb 13, 2019

I consider the project dead, buried, and done, along with my use of computers to help work with the limited electronics I do. All the design tools suffer the same fate.. Either extremely complex that you can't get started unless you have a doctorate in CAD, or so simple they have no way to expand..

I'm a hobbyist. I want to design from breadboard (without super large "3d" part pictures) or schematics, test (Yenka style), and if I like the design, transfer it to either perfboard, etchboard, or maybe order one pcb and related parts....

@PatrickFranken

This comment has been minimized.

Copy link
Contributor Author

PatrickFranken commented Feb 13, 2019

@karpawich Good point! To fully understand the legal restrictions I've to explain a bit more about the legal structure first.

First of all:
We, i.e. AISLER BV, entered into an agreement with Fritzing UG, to become the official Fritzing FAB in February 2017. How did this happen? We approached André, the chief maintainer, in late 2016, and asked him whether we could become the Fab. We believed in making fabbing as easy as to use as Fritzing was for designing. We had shown him a prototype of the native Fritzing integration and then negotiated that we would contribute 10% of our Fritzing-based revenue back to Fritzing. We intended that this money go back into the future development of the software, allowing both Fritzing and AISLER to grow with this collaboration. Whether our contribution was used for this purpose, we don’t know. In hindsight we should’ve made a background check on the legal structure and maybe be more explicit in the contract that our money should be spent on the further development (and even if it was just a paid project manager/maintainer that brings the project forward).

As far as I know, the critical infrastructure is completely owned by Fritzing UG: this includes the forum, the website where you download Fritzing (even though the imprint tells you otherwise), domain name, etc This is where users go to when they google Fritzing. Hence access to that requires the collaboration of the legal entity Fritzing UG. Also, the users of the Fritzing web presence (including the forum) seem to close a contract with Fritzing UG, so we assume its legally their customer database.

The other entity, the German Verein “Friends of Fritzing e.V.” however owns this repository (or it is at least ambiguously stated), the wordmark in Europe under the number 010990802 (https://euipo.europa.eu/eSearch/#basic/1+1+1+1/010990802) and the trademark in the US under the number 79122280 (http://tsdr.uspto.gov/#caseNumber=79122280&caseType=SERIAL_NO&searchType=statusSearch).

What I don’t know however, is how these two entities are connected or whether there is a contractual agreement between the two that allows the UG to use and sub-license the trademarks. The Verein, even though in theory everybody could become a member, I have not seen anyone being able to become a member in the past two years. I also don’t know who actually is a member.

All in all, I believe that the original creators of Fritzing, coming from a publicly funded project, did not have any bad intentions but rather didn’t know how to make it sustainable project. Creating a profit making arm was a great idea, but this attempt died when the creators followed other projects that made more money (I really don’t envy André, he’s still fixing some things in the background even though he has other fulltime obligations and a family to take care of).
Yet, I still believe it is better to get the creators to cooperate rather than forking the project because Fritzing is a global name that will be hard to replace: it has a long history and will be googled by new beginners as all reference and education material includes Fritzing. A fork would mean a lot of promotion and effort would have to go into getting new users, as the forks potential sustainable model also needs to rely on users coming to that fork.

@sgparry

This comment has been minimized.

Copy link

sgparry commented Feb 19, 2019

@KeithSloan

This comment has been minimized.

Copy link

KeithSloan commented Feb 19, 2019

https://github.com/adafruit/eagle2fritzing

MMMh Well the recent update 10 days ago is changes to the Eagle ULP that is used. As far as I can see there has not been much for at least a year.

@PatrickFranken

This comment has been minimized.

Copy link
Contributor Author

PatrickFranken commented Feb 19, 2019

I wonder if we could contact Ada and Spark to see if they still have staff that could help? @PatrickFranken does this sound doable? I mean, not to offload work but at least get some feedback and perhaps materials (postscript/bitmaps, etc) ...

poetaster
I'd be more interested to know if Sparkfun & Adafruit are somehow interested in funding a kind of Fritzing Foundation. No matter if that one would support the original Fritzing or the fork. We at AISLER would attend to. Such a foundation would give Fritzing an open and democratic way to further fund development.

Could someone here give a warm introduction to Adafruit and / or Sparkfun? That'd be great

@sgparry

This comment has been minimized.

Copy link

sgparry commented Feb 19, 2019

MMMh Well the recent update 10 days ago is changes to the Eagle ULP that is used. As far as I can see there has not been much for at least a year.

Yes brd2svg is quiet but the rest of the project has had about 20 updates in twelve months including the last 24 hours, which must mean some interest in keeping it alive. More interesting though is that PaintYourDragon has made contributions - s/he was the one within Adafruit credited with keeping eagle2fritzing working - if s/he is still working there than that is good.

@BKeyport

This comment has been minimized.

Copy link

BKeyport commented Feb 19, 2019

Like I said previously - the ball is clearly within their court at this point. They're both aware of the revival project, where it goes from there, it's really up to them to interact how they choose. I would love to see them both get involved in some way - I believe it would add so much help to the project.

@BKeyport

This comment has been minimized.

Copy link

BKeyport commented Feb 19, 2019

FYI, I just links to a few other maker companies to make them aware of the project as well.

@KeithSloan

This comment has been minimized.

Copy link

KeithSloan commented Feb 19, 2019

MMMh Well the recent update 10 days ago is changes to the Eagle ULP that is used. As far as I can see there has not been much for at least a year.

Yes brd2svg is quiet but the rest of the project has had about 20 updates in twelve months including the last 24 hours, which must mean some interest in keeping it alive. More interesting though is that PaintYourDragon has made contributions - s/he was the one within Adafruit credited with keeping eagle2fritzing working - if s/he is still working there than that is good.

Well, it was PaintYourDragon that made the change to the Eagle ULP and before that a couple of fixes to parts. BUT I CANNOT see any changes to brd2svg or lbr2svg which are the two utilities used, so nobody is fixing the problems or developing the utilities.

@PatrickFranken

This comment has been minimized.

Copy link
Contributor Author

PatrickFranken commented Feb 20, 2019

FYI, I just links to a few other maker companies to make them aware of the project as well.

Which companies do you have in mind?

@KingDarBoja

This comment has been minimized.

Copy link

KingDarBoja commented Feb 20, 2019

@sgparry Which OS are you using to run the Eagle2Fritzing Code?

I remember making a tutorial (small one) 1 year ago about it: Eagle2Fritzing For Windows. Haven't tried again since some months ago but probably can try on the weekend on the Arduino Board.

Cheers!

@karpawich

This comment has been minimized.

Copy link

karpawich commented Feb 20, 2019

@BKeyport Definitely reach out to Instructables if you can. Fritzing is a fundamental part of so many projects there.

@HaraldRau

This comment was marked as off-topic.

Copy link

HaraldRau commented Feb 20, 2019

@vanepp

I also just discovered that the part template files on the Fritzing web site are a disaster. They are original Illustrator (72dpi) svgs with the drawing dimensions in px (a no no).

I made parts by Inkscape-xml-editor and Fritzing-Editor. I was looking for a template of svg-files. I posted one Verion here:

fritzing/fritzing-parts#176 (comment)

Are thise syntax correctly?

@vanepp

This comment was marked as off-topic.

Copy link

vanepp commented Feb 20, 2019

@HaraldRau Sorry, I have been paying attention to this thread and missed your thread (although @el-j is probably a better bet for parts help even than me), I'll have a look at your part and see if I can help as well. As to the templates they are not bad, but not entirely as desired either. I'll fix them up along with an explanation of what I changed and why in a bit (I'm currently generally waiting while one part or another of the development build is doing large downloads so I have free time).

Peter

@HaraldRau

This comment was marked as off-topic.

Copy link

HaraldRau commented Feb 20, 2019

I have a question. Does Fritzing change my original svg-file?
I try hard to logically choose the ID's. For example, "ID = connectorC01pin". C01 is in the documenttation the name for thise connector. Fritzing makes it out "ID = connector ??? pin"

@benreu

This comment was marked as off-topic.

Copy link

benreu commented Feb 20, 2019

Fritzing changes my svg files just like you described. I stopped giving the elements specific names and just set the connectors in the Parts Editor. Make sure the connectors are on the top of the other elements, so you can select them in the Parts Editor.

@vanepp

This comment was marked as off-topic.

Copy link

vanepp commented Feb 21, 2019

@HaraldRau Yes Fritzing (at least parts editor) will change your svg. Fritzing wants the connectors to start at 0 and go up in sequence. If they do not (as in your part) the hover on a pin to get the description breaks. Fritzing seems to assume the next pin number and will display wrong values for two pins before getting back in sync if the pins are not in sequence. This is why the parts check script bitches about pins not being in sequence. It is unfortunately common because both the Arduinos and the Raspberry PIs have not sequential pins and many people copy them. I usually ignore parts editor (except to create new moduleIds, and mostly to format the metadata in the format it wants) and edit the svg and fzp files directly. That requires that you know what they want, but after writing the parts check script I am quite familiar with what it is expecting. Others use the parts editor exclusively, I find it rarely works for me. To each his or her own.

Peter
Peter

@poetaster

This comment has been minimized.

Copy link

poetaster commented Feb 21, 2019

@PatrickFranken I think it'll be difficult to get any other company involved until it's clear what the Verein (the existing foundation) and company are willing to do. I'm in Berlin and will see if I can get anyone by phone, perhaps meet in person.

But maybe I overstate the 'property' issues? The source is available and perhaps a name (TM) change isn't such a big deal? Still I'll see if I can get someone on the phone....

@poetaster

This comment has been minimized.

Copy link

poetaster commented Feb 21, 2019

Apropos parts: @sgparry @KeithSloan

Since it seems efforts on my parts vis. Linux might not be a prio (since it's a less problematic build) ... maybe I'll look at the parts converters. Discrete programming tasks. Just my thing.

@sgparry

This comment has been minimized.

Copy link

sgparry commented Feb 21, 2019

@sgparry

This comment has been minimized.

Copy link

sgparry commented Feb 21, 2019

@poetaster

This comment has been minimized.

Copy link

poetaster commented Feb 21, 2019

Ok, I'll have a look at the adafruit changes. Any significant task (artifact building) involving physical artifacts (from many manufacturers) is gonna be hairy :)

@poetaster

This comment has been minimized.

Copy link

poetaster commented Feb 21, 2019

First thing to do is probably move to just converting eagle xml to fritzing xml. the old converters are pre eagle 6. Does anyone use a version older than 6? (I'm using 9.x)

Revise that. I first need to compare recend versions of the .brd files and I'll move from there.

@poetaster

This comment has been minimized.

Copy link

poetaster commented Feb 21, 2019

@vanepp I'm asking myself if I should dive into parts editing in Fritzing, rather than spending time on something like the eagle imports ...

On the one hand, we can be sure of the integrity of eagle parts (and the relative pain of transforming them). On the other hand the approach of fritzing (ie. standard svg parts that can be created externally) is really different.

What is unclear to me is whether or not the eagle approach yields more reliable parts (from the vantage point of accurate measures for pcbs).

It could be that the effort to translate parts from eagle's non-svg format to propoer svg makes sense, since the parts are 'correct' where measurement is concerned.

Hmmm. In any case, when one considers the added complexity (external urn imports for eagle parts) as of eagle 8 (in the real world 9.x) it might just not be worth the effort.

For my part, I've often gotten past Fritzing parts problems by using generics that work, but that make the layouts on breadboard less useful for novices (since they cannot see what parts are 'really' involved) ...

Oh, boy. Tin of worms open.

@sgparry

This comment has been minimized.

Copy link

sgparry commented Feb 21, 2019

@vanepp

This comment has been minimized.

Copy link

vanepp commented Feb 21, 2019

@poetaster If the eagle to fritzing conversion can be made to work (even just for pcb) that would be useful. There is a company (SamacSys) that has a footprint library on the Mouser site. Somewhere (I don't see it in this thread in a quick look, may have been the Fritzing forums) they expressed interest in adding Fritzing to their tool (which would be win-win for us, many more part footprints available to modify). Since they already do eagle footprints, the converter would make it easy for them to do this. If we can get a stable version of the brdtofritizng script working it would be worth reaching out to them. I've seen comments that it is very complex (and a comment somewhere from one of the original Fritzing developers somewhere, that there are constants in there that he no longer remembered what they were for) although I haven't done more than download the repo so far. One of the things on my todo for efficiency list is to change the code to be able to specify a footprint already in core. That would be a big win, as it would reduce the size of the parts repo considerably (many redundant copies of 14 dip pcb file for instance). It is a long way down the list and requires a code change but it is there. Be warned the Qt down load that I understand it requires (probably just for Qt header files since it is said to not use Qt) is about 8 hours (if all goes well) on my adsl line (and things rarely go well) and eats 40 to 50gigs of disk space (so have lots before downloading, as I don't think it checks first).

@poetaster

This comment has been minimized.

Copy link

poetaster commented Feb 22, 2019

@vanepp In the main, I'm thinking about what versions of eagle to support. Starting with 6, much of the job can been done with little more than clever XSLT (xml transformations), but with Eagle 9 they introduce external URN and so make things more complicated.

I'll think I'll being by taking apart some Eagle 6 brds but it would be nice to know where I should start. Maybe go right to Eagle 9 ?

@vanepp

This comment has been minimized.

Copy link

vanepp commented Feb 23, 2019

@poetaster I'm probably a poor one to ask because I don't use eagle. I suspect supporting the older versions would be valuable because I expect many eagle boards were probably done in them, but that said, I expect the new versions will still process the old boards, so as long as the script does too that should be fine. Hopefully someone with more experience in eagle will join in with a better opinion.

Peter

@HaraldRau

This comment has been minimized.

Copy link

HaraldRau commented Feb 24, 2019

I wrote an e-mail to the editors of the magazine 'MAKE'. Maybe they will report on the Further development of Fritzing!

@vanepp

This comment has been minimized.

Copy link

vanepp commented Mar 4, 2019

@poetaster A late suggestion on eagletofritzing: I'm working on the calliope part in another thread, and the Fritzing part came from eagletofritzing, but the svg height/width are defined in px (no units which defaults to px), so it is desirable that eagletofritzing use either "in" or "mm" for document height/width so we don't run in to scaling problems. On my current (Inkscape 0.92.4) the svgs are the wrong scale (actually all three, the original eagle files, the eagletofrtizing file and the Inkscape file I am working on have different sizes for the board, and I don't know which is correct, presumably the eagle file). This is because px could be 72dpi (old illustrator), 90dpi the old svg standard, and likely what the board is, or 96dpi which is the latest svg standard. Inches or mm are the same at any dpi and thus not a problem.

Peter

@poetaster

This comment has been minimized.

Copy link

poetaster commented Mar 7, 2019

@vanepp got it. mm is the way to go. I'm a bit in over my head at the moment, but will take a look next week....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.