Further development of Fritzing, open for discussion

[PatrickFranken]

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.

[PatrickFranken]

@rain-1 we are in contact with them but as said during the talk at FOSDEM it's hard to discuss as motivation are not clear. At least not for us at AISLER.

[vanepp]

@poetaster : Linux is fairly easy to get going, there are instructions here:

http://forum.fritzing.org/t/build-instructions-for-linux-and-windows/5528

Windows and the Mac are harder. As noted above with the 40xx parts update from a few days ago the build should should work again (Qt was asserting and crashing Fritzing on tspans in the 40xx parts when with the latest parts repo and at the startup update if you started from the repo in the 9.3b release. They appear to have backported the assert in to Qt5.6, because when I tried to build on a 5.6 install it hit the same assert, which the original code does not. While I have an older version of 5.6 for Linux (that may or may not work) I don't have one for Windows which is the platform that needs fixing (and is hard to get the source to build on.) I'd welcome any help on patching together original Fritzing code, because as noted above one day Fritzing is going to just stop working. As to the captcha issue, Andre eventually fixed it, the delay being lack of time (and possibly that the web site is a mess he said). I think that was probably through a back channel on the Fritzing forum (I private messaged someone who I know has more contact with the administrators than I do). As mentioned, if (and it is a big if!) I can get a fix for Windows compiled from the 0.9.3b code base (because head would require user testing which probably isn't feasable, and there aren't many changes in it now the gerber code has been backed off) then we will see if progress has any hope. I intend to keep working on that along with the Freetzing project. The best solution would be to be able to just replace the libgit2 dll in the distribution, but when I do that it still uses tls1.1 even though a compiled from source version using the same version of libgit2 successfully uses tls1.2 and thus works. I don't know enough about Windows hacking to figure out what needs to change to fix that. I suspect some parameter is being passed to libgit2 is at fault but I don't have a working dev version of 0.9.3b to see what the original one does. It doesn't appear that anyone else does any more either ...

Peter

[KeithSloan]

IMO the best bit about Fritzing is the parts library, and that appears to be an entirely open Creative Commons effort using SVG which is already pretty web-friendly.

Oh Really - Its some time since I tried to define some Fritzing parts and I found it a VERY problematic process.

Unfortunately, I cannot remember the problems, but a quick search of the forum for problems creating part should give you an idea. I had particular problems creating Fritzing parts which were from Eagle.

I was originally trying to use Inkscape to create the SVG and vaguely remember having to give Serif Affinity Designer a try. I am on a Mac and a guy ( Sorry forgot his name ) who was helping me used some other SVG editor on a PC

Not a fan of recreation with Javascript

[BKeyport]

IMO the best bit about Fritzing is the parts library, and that appears to be an entirely open Creative Commons effort using SVG which is already pretty web-friendly.

... and the worst thing about it. The parts library has me using stand in parts 9 times out of 10... for basic stuff - because I can't figure out the parts "Editor" at all. There's no sense to it.

"Generic Female Header - 2 pins" - I use that as a stand in a ton. It would be better to have it as a single pin, then "Stack" the images together to make as many pins as you needed, in whatever configuration desired.

[vanepp]

You can change the Generic Female header to the number of pins you want by dragging it in to any view and then changing it in inspector (joining the Fritzing forum is the best place for help with parts). That said I agree parts creation is hard. That is partly because parts editor was not finished when development stopped. That is the purpose of this discussion to find a way forward, either via the freetzing project or less likely, by getting development going again. The latter is less likely because I have been trying with little success (and no apparent interest that has resulted in any help from anyone else) for a couple of years now.

Peter

[BKeyport]

peter: Every time I change a part, I have to near totally erase and reinstall fritzing. Right now, for instance, I have no search function. It don't produce the search box...

Once Freetzing gets to the point of needing testers, I can help with the project. I'm good at blowing things up (finding odd bugs).

[benreu]

@BKeyport I agree, the parts creator is painful to learn. Mostly because it requires Inkscape or so to edit the svg files. However, part creation is pretty straight forward for me after all the experience I got over the years. I keep meaning to do an in depth tutorial, but time is not in overabundance around here. Neither does it help that the Fritzing community is horribly fragmented. I did a post on the Fritzing forum about part creation a while back and got positive comments about it, but that it's where it stopped (on my part).

[benreu]

@vanepp I am willing to help out. The catch though is that I am pretty set on using Linux while Windows and Mac are what are needed. If you ever need a shoulder to lean on... silrep at emypeople dot net

I have meant a while ago to look into the stagnation of Fritzing, but sigh... Is there some way all the interested parties can get on board this thing? Mailing list, Github repo, forum, something that isn't tied to Fritzing? Fritzing isn't responding, so we have to get a move on. How about we start with vanepp's Github repo and document what we need? Missing features, bugs. And where posts like 'how to install on Linux' gets closed, so the devs can focus on actual problems/progress.

[KeithSloan]

@vanepp I am willing to help out. The catch though is that I am pretty set on using Linux while Windows and Mac are what are needed. If you ever need a shoulder to lean on... silrep at emypeople dot net

I have meant a while ago to look into the stagnation of Fritzing, but sigh... Is there some way all the interested parties can get on board this thing? Mailing list, Github repo, forum, something that isn't tied to Fritzing? Fritzing isn't responding, so we have to get a move on. How about we start with vanepp's Github repo and document what we need? Missing features, bugs. And where posts like 'how to install on Linux' gets closed, so the devs can focus on actual problems/progress.

Would have thought a new Github repro or Wiki would be better than an existing repro. Perhaps a new name Fritzing++?

[benreu]

I meant forking the Fritzing C++ version and getting some stuff going. And yes, possibly doing a rename. Maybe if we could get at least a Linux version that is better than what it stands now, the Windows and Mac guys would chime in. As always, this could be merged back in the original Fritzing if and when the original Fritzing team is still alive.

[vanepp]

@BKeyport : the search box disappearing has a long history in the fritzing forums, there are several reasons, I think one (in windows) was bad permissions on the parts bin. Is the search option there but just greyed out? That is likely permissions. If it isn't showing up at all, check the bottom of the bin listing, it has been known to drop to there from the top (and isn't visible by default). For issues like this the forums are usually a better bet. Usage died down a lot when people couldn't create accounts but usage is growing again.

@benreu : help would be appreciated, I debug on linux because I know gdb (and don't know the windows debugger), but at the moment the challenge is to get all the platforms going linus (done) Windows64 (done) Win32 (Qt broken could maybe be cross compiled from Win64 but I'd rather do native) and Mac (I don't current have one, and someone who tried a week or so ago gave up, it may come to me buying a Mac :-) ). I need to be able to produce distributions for all the supported platforms before even approaching the site administrators about a release. A year or so ago there was reportedly agreement for a new release if there was a tested version available (now testing a version is going to be exciiting, but we need to be able to build one first :-) ) so I think there is some hope. I don't think a fork is going to help in that we don't have the infrastructure (which Fritzing does) to publish a release, and there so far hasn't bee refusal to do a new release (at least that I'm aware of) just no new release to do. I don't think a fork is going to make building any easier and will fragment things even further which isn't desirable. I think a fix for the currently marked critical bug in Windows parts update is the place to start and what I am working towards. If that happens, maybe things will start looking up. One useful thing would be a new "experimental use at your own risk but please try and report bugs" page on the Fritzing download page where a release candidate (assuming we can make one of course) could be distributed for testing. Any new release is going to need wide spread user testing before any one sensible would consider putting up as a new release and there currently isn't a way to do that. That is step 2 after being able to build a release.

Peter

[BKeyport]

New name oughta be Futzing, 'cuz all we do is futz around...

[karpawich]

@benreu

@karpawich Could you explain a bit more on the Freetzing project? Will it be browser or desktop based? A replacement for Fritzing or just a add-in tool of some kind? I can't find any real life examples. Excuse my ignorance...

@el-j and I are still discussing the specifics. However, we are thinking of of starting with a parts editor on the desktop, at least until we can find the resources to put it in the cloud as a website. Once when we build that, we will see the progress of everyone else in trying to save the existing C++ version and decide whether we should go ahead with re-building the Fritzing app itself.

[duff2013]

I have developed for Fritzing in the past (though they scrubbed my name from the contrib page) and found that qt c++ is not a problem but I'm not wetted to any platform going forward being javascript or such. I would just say that we get rid of the Arduino sketch part of Fritzing!!! It is redundant and not even close to what you would expect from the current Arduino IDE and just makes another thing to maintain taking away valuable dev time from things that make Fritzing a great EDA platform for artists and such. Let Arduino worry about programing your microcontrollers!

[karpawich]

For C++ the folks, I suggest that someone creates a fork that everyone can decide on as the temporary home for development until we can have write permission for the actual fritzing-app repo. Several of us are already using the Freetzing org for similar work, so I vote that @vanepp creates a fork there (he is already a member in the org)

I've seen several cite how the Fritzing community is "fragmented". I think that having everyone working under the same Github org would be a definite step towards bring us back together.

Thoughts?

[BKeyport]

duff: Arduino is how I got knowledge of Fritzing in the past - through a sparkfun board. Maybe replace it with a link/launcher to a better sketch program,

[duff2013]

@BKeyport having a button or such to launch Arduino would be fine I guess but I usually have 3 or 4 versions of Arduino on my computer so how would you select which one?

My issue with the development roadmap that Fritzing seemed to take on in the last few years was not fixing anything and adding features that really just got in the way off it's core function, designing circuits. Not every circuit uses a micro controller. Don't get me wrong I see the link between Arduino and Fritzing but I feel if its going successful the Fritzing roadmap needs to be concise to it's core function and not everything to everyone.

[benreu]

Yes, definitely @karpawich . Let's get everybody wanting to work on Fritzing on 1 page. If it takes a fork, then fork it. I for one am waiting to contribute anything until I see a Fritzing project not attached to Fritzing UG. Nothing against them, but we need to go forward, and they are not. See the last comment by @duff2013 . And yes, get rid of the Arduino sketch tab. I already know of 3 or 4 different softwares for Arduino-related, and the Fritzing one is the worst.

[karpawich]

If someone has the time and feels comfortable maintaining the temporary fritzing-app fork, let me know and I'll add you. I've forked it over at

https://github.com/freetzing/fritzing-app

[vanepp]

@duff2013 Currently the Code tab (which I think is what you are referring to) doesn't work for anything except the pikax. It needed a command line interface in to the Arduiino IDE which didn't exist when it was installed. It could now be fixed (assuming we can restart development) and there are occasional users that ask about it in the forums, although I agree it would be better just removed and use a standard IDE. My main question is: can we lure you in to somewhere (the Fritzing forums would be my first choice as I spend a lot of time there, but I'm flexible :-) ) where you would answer questions about the Qt/C++ code? I can figure out some of it, but the lack of context with no one with experience to ask questions of is daunting. As I have said I'm reluctant to make a fork, that is extra administration and further fragmentation in my view. If we can make progress towards a release and can't get the current adminstrators to accept it then maybe a fork would be useful, but I have my doubts. As I said earlier the infrastructure needed to distribute a release is already there, although currently inactive. In my view, (which may well be wrong) it is inactive for the very valid reason that no one has demonstrated a change that is worth making it active. There is currently nothing to release, I currently can not get a development environment for all supported platforms working (although there is progress on that). There is as I noted earlier, the chicken and egg problem of no current way to publish a release candidate for testing and trying to change that (and making such a release candidate) is where I would put the energy that a fork would take. I'm not good enough at github to take responsibility for a fork. I manged to get 3 pull requests against the parts repo, and then wasn't able to make another one. and haven't yet gotten back to figuring out why. So someone else with better github skills would need to administer a fork.

Peter

[KeithSloan]

@el-j and I are still discussing the specifics. However, we are thinking of of starting with a parts editor on the desktop, at least until we can find the resources to put it in the cloud as a website. Once when we build that, we will see the progress of everyone else in trying to save the existing C++ version and decide whether we should go ahead with re-building the Fritzing app itself.

I think the creation of a new fork and effort to create a Part Editor is an excellent idea for the following reasons

1) Development of Fritzing parts editor stopped before the parts editor was complete. 2) It can be completed independently of any new or fixing of Fritzing App. 3) It can always be merged at a later date. 4) Probably most important it is SMALL STEPS, which given the current state of affairs is important. 5) It is way forward

[BKeyport]

Expanding on the code tab a bit, would it be possible to change it to a simulate tab, and import code/xml from the desired programs for the platforms so that we can virtually test circuitry like Yenka does? (Eventually) would love to have that as a eventual feature.

[WimberleyTech]

I have developed for Fritzing in the past (though they scrubbed my name from the contrib page) and found that qt c++ is not a problem but I'm not wetted to any platform going forward being javascript or such. I would just say that we get rid of the Arduino sketch part of Fritzing!!! It is redundant and not even close to what you would expect from the current Arduino IDE and just makes another thing to maintain taking away valuable dev time from things that make Fritzing a great EDA platform for artists and such. Let Arduino worry about programing your microcontrollers!

I second the motion to ditch Arduino support. I never used it, and I reckon that very few did.

[benreu]

@karpawich What would the maintainers reponsibility be? I was around FOSS for a while, but never maintained a project. I have some coding I do for myself and a few friends, but nothing major like Fritzing. I know my way around git and Github.

[karpawich]

@benreu According to the open source principle of meritocracy, you only have as much responsibility as you make for yourself. When I say "maintainer", I do not mean to attach all of the roles that come with being a maintainer, like the type that Patrick is looking for. Out of those who have expressed interest in working with Fritzing as it is now, one of you just needs to take responsibility for managing Issues, checking and analyzing Pull Requests to prevent breaking changes... you can decide between yourselves how you go about making decisions. The only responsibility that you should be aware of is keeping the repo stable, once when you resolve whatever issues you face now.

I would love to take up the role myself, but I'm busy maintaining fritzing-js and other repos at the moment. And as I've mentioned before, C++ and Qt are not my specialty. Let me know if you're interested.

[KingDarBoja]

If anyone with the C++ (and Qt) skills want to contribute at Fritzing development, this is the time to join the fork made by @karpawich and start fixing the current issues of the Fritzing-app. Of course, take your time and effort to make the fixes or manage anything related to control versioning (Pull Requests, Issues, etc).

Cheers!

[boneskull]

To any involved interested in funding the project, you make want to ask sparkfun if they’d be willing to make a recurring donation.

I’d also point those interested in seeking funding to opencollective.com, which streamlines project-level recurring donations. My project receives something like $20k USD yearly through the site. Obviously not enough to sustain much development, but maybe better than nothing. Some projects get upwards of $200k USD / year or more; just depends on how well you get the word out.

Crowdfunding via Kickstarter, Indiegogo etc might be worthwhile.

[HaraldRau]

@boneskull At startnext has Calliope in last year 100.000 € collected. @duff2013 I do not use the code in Fritzing either. I think separation of physical and virtual ist o.k.!

I also wrote to Nancy Birkhölzer. She is in the management of UG Fritzing. So far no answer!

https://www.ixds.com/nancy-birkholzer

[HaraldRau]

Here is the newest about the Fritzing UG: https://www.northdata.de/Fritzing+UG,+Berlin/Amtsgericht+Charlottenburg+%28Berlin%29+HRB+167853+B Nancy Birkhölzer is also a member of IXDS GmbH

[sgparry]

Firstly: @karpawich and @KingDarBoja - I have C++ (GNU and Ms) and some Qt - I may be able to help, my time is very limited as I teach, but I will see what I can do. There are one or two glaring bugs I would love to kick out of Fritz. A big roadblock is the lack of early source, thanks to google burning the whole damn SVN repo - quite a few bugs seem to be regressions of early fixes. @el-j @karpawich etc; I am going to be a bit of a naysayer regarding javascript: Javascript is only most popular because currently it is very difficult to run anything else efficiently in a browser and browser is king nowadays, like it or not. The models in JS suit some developers very well, but many of us feel a language which primarily blows up AFTER you ship your code, (you do jslint and test right?...) rather than before may feel more warm and fuzzy when you are developing, but does not necessarily give you good code. The profusion of frameworks, some of which use code that actually does not look like code at all (promises etc) can be very off-putting especially to the novice programmer. Then there is the browser compatibility issue - not the IE versus Edge versus Chrome versus Firefox one - the Any Browser version x versus Same Browser version x+.0.0.1 problem. I have come across a number of projects which were producing fantastic features in their particular sphere, the developers took a break to actually maybe, you know, have a real life for five minutes and not long after their back was turned, all the projects stopped working, presumably because of some security hysteria or a change in an emerging tech they all relied on. C++ is difficult to port from OS to OS, but generally once it is ported it stays ported, at least in the medium term. Another angle is that webassembly and transpiling are beginning to give us other options for languages. Their is hope, for example, for both C++ and Java again. You would still die before Fritzing got ported though. Also, where do we want to run Frtizing? Yes, a browser based application has loads of advantages and yes you can run JS non-browser, but both have many limitations. Whatever we port to in the long term - there is the risk the project will die because of the port. Logisim is a good example here. Logisim was (and mostly still is) a great project - but the developer opted for a next generation, clean slate approach to redeveloping it, changed languages, got too busy elsewhere and both branches of the project ground to a halt. A number of forks of the 'legacy' version were created and are maintained, but none of the fundamental shortcomings can be resolved because even the original author struggles to remember how the code works. And that is with the full source history. My vote is for evolution rather than revolution.

[poetaster]

@sgparry second these reservations. The main impetus of this discussion is to make progress. A javascript port, whatever its merits, would swallow up too much time just getting us to what we have now. Upvote for evolution.

@vanepp My time is limited, but I can certainly add my reports building on linux. I'm also concerned to get tests through to manufacturing. This is an app that only succeeds in it's task if the boards get built. Which bring me to:

@karpawich Are we all on the same page, build from the Fork in Freetzing? Once a fork is in place, it's a slippery slope ....

@duff2013 Getting rid of the Arduino stuff in Fritzing. Let's simplify first. Jeez. Upvote for devolving that feature. (I use the arduino ide's mostly for ATTINY and Teensy stuff. And they just work(tm). don't reinvent the wheel)

[el-j]

@vanepp i did the last build for the 0.9.3b windows release. I think i have a running dev enviroment on my old pc. I will check this and if so pull the last changes and try to do a build with the new libgit etc. The strange thing: my partsupdate is working on win10 64bit with the downloaded version 0.9.3.b. so maybe there is something on my machine...i will check it.

[BrunoRamalhete]

I want to contribute to the project too. I can try to debug on the Mac version. Do we need Xcode ot just QtCreator works fine? I want to contribute to the project development.

[vanepp]

@el-j That would be great! I know it breaks on Win7, but some Win10 users in the forum have also reported it broken. The fix in libgit2 does specifically say that it fixes Win7 Tls1.2 support so it may not apply to Win10 (I don't like 10 and don't run it). I'll dig up the earliest version of libgit2 that I know works (I remember problems with later versions on 0.9.3b I think) and the build instructions for libgit2 which are somewhat odd (the web posts out there don't work for me, it needs an extra parameter in the cmake call to generate a 64bit binary). The easy test for if you have the problem or not is to start Fritzing and click help->check for updates. My Win7 box reports "Unable to access network site for (parts repo url) Fritzing cannot update the parts folder automatically.". This indicates you have the problem. I should restore one of my Win10 versions and try it and see what it does. The check on startup just silently fails so you don't notice that you aren't getting parts updates (I didn't for months until I tried a manual update and got the message) . The work around if you have this problem is to manually clone the parts repository in to Fritzing and then (in any window but welcome) click on part->Regenerate parts database. This will rebuild the parts data base with the new repo and all is well.

I just changed to my dev disk, and checked the notes, it wasn't 0.9.3b that objected, but the current dll. What I was trying to do is recompile a new libgit2 (libgit2-0.26.3 in this case) and swap it for the current one. Anything later than libgit2-0.26.3 doesn't work at all, but libgit2-0.26.3 works on head compiled from source but still fails when substituted with the 0.0.3 Fritzing binary. I figured that was the minimal possible change that would fix this issue. So compiling with that or a later version and the 0.9.3 release code should fix the issue if we can get someone to do the update. To compile libgit2 under Visual Studio 2017 (I had troubles with 2018 and reverted) , I needed to add -G "Visual Studio 15 2017 Win64" to the cmake command in order to get it to generate a 64bit binary. Without that it generates a X86 binary that won't link. The full sequence that was successful for me is:

mkdir build

cd build

cmake -G "Visual Studio 15 2017 Win64" .. -DBUILD_CLAR=OFF -DTHREADSAFE=ON

cmake --build .

cmake .. -DCMAKE_INSTALL_PREFIX=e:\fritzing_dev\libgit2\

cmake --build . --target install

but I expect you are a lot more familiar with this than I am. If you have an older version of visual studio you will need to select the appropriate generator (something, I don;t remember what, gave me a list of my choices).

Peter

[WimberleyTech]

The easy test for if you have the problem or not is to start Fritzing and click help->check for updates. My Win7 box reports "Unable to access network site for (parts repo url) Fritzing cannot update the parts folder automatically.". This indicates you have the problem. I should restore one of my Win10 versions and try it and see what it does.and got the message) .

Peter I just tested it on Win10. "Check for updates" is greyed out and cannot be selected. On Win7, the error noted above is generated.

[vanepp]

@WimberleyTech Interesting! Did you get a parts update in the last week? @el-j did a commit of a couple of my fixes and two new Sony parts which should have generated a parts update request if the automatic updater is working on Win10.

Peter

[karpawich]

@poetaster Most appear to be in agreement or at least okay with relocating active development temporarily to the freetzing/fritzing-app repo and then merging it with this one once legal issues are handled.

For everyone who has shown interest in fixing Fritzing, we still need someone to take responsibility for reviewing pull requests and managing open Issues. I know @benreu is interested, but is anyone else?

I've seen so many here express interest in contributing. Let's get going on that as soon as we can! I can help whoever volunteers, but as I've mentioned before I am too busy with other projects to be the primary maintainer.

[karpawich]

@boneskull

Thanks for the suggestions! You have got @el-j and I thinking... we'll have to look at your suggestions and other similar avenues.

[duff2013]

So wait is the Freetzing development going to be based on QT C++, JS or both? I don't see any consenses on this yet?

[karpawich]

So wait is the Freetzing development going to be based on QT C++, JS or both? I don't see any consenses on this yet?

As its description says, the Fritzing org is...

A small community of developers working to keep Fritzing alive

It can be home to the temporary fork of fritzing-app and for any JavaScript related development. These two projects are kept in entirely separate repositories though, so you don't have to worry about crossover.

[duff2013]

@karpawich how do you envision the future of Fritzing development, QT C++ or JS. It seems to me that one platform should be picked right? Why would I develop on the C++ side to only find out that JS side is going to be used? Not trying to start battle just need clarity of what this endeavor entails.

On the QT C++ side it is an already working code base, but it seems like most people are having issues getting the build environment going and such.

On the JS side I don't know how far it has progressed? Can we see a video demo where it is now or at least some screen shots. I don't want to build it or whatever you do with JS to get it to run right now.

[vanepp]

@PatrickFranken A big thank you for both the talk and starting this issue! This is more progress on restarting development than I have seen before in two years of trying. It may still fizzle out, but at least there is some progress. If @el-j can get his dev system up we may get a fix to the parts update bug which would be a fine start. If not I may be able to cobble something together.

Peter

[karpawich]

TL;DR I think that both projects can and should peacefully coexist. As @vanepp has said, the amount of progress that we've seen in just the past week has been more than the progress in two years, so I think that we should welcome any sort of development, and anyone interested in contributing to keep Fritzing alive.

---

@duff2013 There are a lot of people interested in fixing the existing code base and build environment, which I'm all for. That's why I'm trying to get everyone to work on the fork over at Freetzing as a team.

As for JavaScript-related development, we only began picking it up last week. Our plan right now is to put together a parts editor, and then decide where we go from there depending on the progress of the folks working on the existing code base. Right now, a few of us are working on fritzing-js, a library that converts Fritzing data files into JavaScript objects. With this library, we can support every existing Fritzing part out there and with the help of @vanepp in deciding the "best practices" for parts, we want to put together a parts editor that can coexist with the Fritzing app as a separate, but related project. That's the start of our work.

[KingDarBoja]

I have another suggestion for a desktop based Fritzing app which doesn't rely on C++ but rather a modern programming language whose purpose is... Replacing C++. It is called Rust.

Its currently among the fastest growing languages as seen at Octoverse 2018 and also on the first place of most loved languages at Stack Overflow Sruvey 2018.

I am not an expert on C++ and have zero knowledge on Rust but after reading some articles, seems that Rust will keep growing as alternative to build apps.

Now my point is: As long as there are developers willing to keep Fritzing alive, the main effort should be porting to a new language and therefore, provide quality improvements to the ecosystem. Freetzing-JS is one of those efforts and we should continue working on it as a team, make decisions that help improve what you have and add new features according to the requirements of users, who are at the forefront of modern interfaces.

[WimberleyTech]

@WimberleyTech Interesting! Did you get a parts update in the last week? @el-j did a commit of a couple of my fixes and two new Sony parts which should have generated a parts update request if the automatic updater is working on Win10.

Peter

Not sure. I am not normally running Win10. So I powered up my laptop which is running Win10 to check. If you will let me know what part(s) updated I could check to verify, I will look.

[benreu]

I have another suggestion for a desktop based Fritzing app which doesn't rely on C++ but rather a modern programming language whose purpose is... Replacing C++. It is called Rust https://www.rust-lang.org/.

Ok, I will try to stay politically/programmically neutral here. But I could argue that Python is going to replace C++. The next guy will argue JS will replace C++. What I am trying to say is, I would vote to keep Fritzing as is (Qt , C++) until we at least get a stable base again. I for one will see if I can learn these two, to keep Fritzing alive, if nothing else.

I will admit I put some push on to create a fork, but I will also push to keep in sync with the original devs. Keeping in sync with the original team means using the original coding platform for now.

Its currently among the fastest growing languages as seen at Octoverse 2018 https://octoverse.github.com/projects#languages and also on the first place of most loved languages at Stack Overflow Sruvey 2018 https://insights.stackoverflow.com/survey/2018/#most-loved-dreaded-and-wanted.

That's what they said about Java years ago. I am not an expert on C++ and have zero knowledge on Rust but after reading some articles, seems that Rust will keep growing as alternative to build apps.

[benreu]

As for JavaScript-related development, we only began picking it up last week. Our plan right now is to put together a parts editor,

I agree a parts editor is high on the pain list of Fritzing. I have seen multitudes of people throw Fritzing away because of the lack of part generation. Custom PCB shape generation also is something that comes up once in a while, so you might want to keep that in mind.

[karpawich]

@benreu @WimberleyTech @vanepp @Spectrum256 @poetaster @KeithSloan @sgparry @BKeyport

Go ahead and start work on the existing code base if you have not already. @el-j and I will maintain the Freetzing fork when we can so that we can all have a central place for development - I ask that you all submit your changes via Pull Request there.

@PatrickFranken most discussion at this point has transitioned to specific issues regarding the work by the folks above to help fix the existing codebase, so feel free to close this Issue. As so many have already said, thanks so much for starting this conversation anew again.

To everyone else, let's get going, and help bring Fritzing back 🚀👍

[karpawich]

If anyone else is interested in our progress, I plan on sending out a monthly update. Shoot me an email at max.karpawich@gmail.com referencing this discussion so I know to include you.

[benreu]

@karpawich @WimberleyTech @vanepp @Spectrum256 @poetaster @KeithSloan @sgparry @BKeyport

I would like a mailing list (or alternative). Where we could post tips, problems, or successes. This thread is getting quite like a pot of alphabet soup. Should we use Github issues? Mailing lists are getting to be viewed as older. What are the preferences/suggestions?