Dear Henner, I appreciate your answer. Even though I don't think this will take years, you are probably right here.
If you choose to not positively contribute to KiCAD with patches or > suggestions then why are you here? > I subscribed to the list about 2 years ago, there are 1800+ unread messages in my mailbox in total. I had decided to contribute at first (obviously), so subscribed to the list, then that total misunderstanding has happened in the Kicad Forum as I was /thinking/ the developers were using that forum and those people were developers. (That's an embarrassing situation for me because I could have easily verified that those people are really developers or not. These lost 1.5 years is partly my fault.) So being here was the natural step in the first place. > > All software has issues, and the only way to fix them is to get involved > and contribute code. Spewing vitriol does _not_ fix code and also makes it > hard to retain developers once you do consider leading a project, just > saying. > Maybe. Think that the new project is kind of a "Proof Of Concept" work. That would still serve to the development of Kicad. For example, I have a function (which took my whole month to develop) for the component based design approach: https://github.com/aktos-io/aktos-dcs-node/blob/dev/lib/merge-deps.ls#L145-L712 I /think/ that will resolve the "Broken by design" statement of mine ( https://github.com/ceremcem/aecad/blob/master/problems-with-others.md#what-is-wrong-with-kicad) about the hierarchical sheet's file format . Obviously porting that into Kicad requires lots of change in the Kicad source code where it would take a huge time of mine because I don't know C++ (well enough). It would still remain unknown that porting that function to Kicad would solve the issue or not. So I might quickly prototype the idea in another project and once it solved the problem, porting that solution to C++ (thus to Kicad) would be way easier. (like prototyping a code for microcontroller in Python. It would be easier to prototype an algorithm in Python, and once it works, we can port the code to C for the embedded device) > > As for technology, I am glad that EDA tools are not running in the > browser, JavaScript is a mess to maintain. So if you go that route, make > sure to have only the presentation in "web technology"; still 95% of your > code will be in the backend and be C, C++, Go or whatever you choose. > > This statement is still true. I don't think it is worthwhile nor > useful to try to redo the UI to run in the browser, but there are many > other things to work on. That would be true if there weren't some great UI frameworks, compile-to-javascript languages and bundlers in Javascript. Javascript is not Javascript now :) In fact, the first language I've learned was C++ after Qbasic and I always wanted to think in OOP paradigm. The problem was the UI part for me, because you have to design every widget separately. They won't inherit the others. I've built some applications by QtDesigner and Kivi (has an object oriented widget design) with Python backend but these UI solutions were not satisfying because creating new widgets based on current one or more widgets was either impossible or too hard. Now I use web technologies (https://github.com/aktos-io/scada.js) and the component based approach (of Ractive, for example) makes such UI work a breeze. I didn't think about creating a web UI for Kicad in the first place, but that sounds like it's more applicable. > So I think I have to retract a little of my statement here. Re-reading > it does sound like the vitriolic the "Kicad sucks and developers are > arrogant" attitude was meant to be an impression in the past and a 1.5 > year misunderstanding while Cerems mail here is more like "ah, now I > discovered the developer list and would like to rather contribute, but > don't know C++, and I am wondering if a web-UI makes sense". > I was reading the mail after having read the Kicad user forum post > which was showing an attitude so apologies if I misread your first > mail to the mailing list,l Cerem. It is not very clearly coming > through though. It is /like/ "ah, now I discovered the developer list" (remember the 1800+ unread mails) and exactly "ah, now I discovered that developer list is a way different place than the forum". I thought that you all developers were already in the forum and those people who rejects the ideas (with that attitude) were you, developers. So I didn't find it necessary to look through here for these kind of suggestions and reports (and didn't read the mails at all). Send a link once you have code. Looking forward to :) Good luck H On Dec 25, 2017 08:03, "Cerem Cem ASLAN" <cerem...@ceremcem.net> wrote: > Hello everyone, > > I'm the founder and project engineer of my current company. We are > developing open source web based realtime SCADA solutions with or without > custom open source hardware. We are using Kicad for our hardware > development, and thank you for your hard work. > > Before the main subject, let me clear an issue: > > There are a few problems between Kicad and us (me). First, you developers > are too arrogant. And your software, Kicad, sucks in many aspects. I can > build my own EDA, better than yours, there is no need for Kicad. > > Yeah, that was what I was thinking for the last 1.5 years and that's > corrected a few days ago: https://forum.kicad.info/ > t/kicad-from-scratch-with-web-technologies/8962 I realized that "those > people" were not developers at all, so there was a total misunderstanding > on my side. "Kicad sucks"? Nope, every application might have problems. I'm > a developer, an engineer, I know that. Sending bug reports and/or sending > patches is one of our responsibility as a user (and this is what I did for > our workflow: https://github.com/aktos-io/kicad-tools, https://g > ithub.com/aktos-io/kicad-install) . > > Real problem between Kicad an me: > > There is a "lost" 1.5 years for me because of the above misunderstanding > and I have a long wish list. Plus, I don't write C++ applications, which > will force me diverging my own effort if I want to dive into Kicad codes. > In addition, I feel like a web application might be useful in many cases. > Additionally, such a drawing ability will be used for our SCADA product. > That's why I've initiated the following project: https://github.com/ce > remcem/aecad > > Above forum thread is too long to be read easily, but I would like to > quote one of my thoughts from there: > > I have a question: Is KiCAD a tool, or an idea with a physical evidence? >> If it's a tool, you are justified "defending" it to the end. If it is an >> idea with physical product, then the physical product may change slightly. >> Like an airplane. It's an idea about flying. There are many different >> airplanes. They share the same knowledge, but these teams can not work on >> the same plane. Important part is to keep these teams in touch to let them >> chat and share their experiences. >> > > Based on this logic, I would like to get your opinions. What design > decisions should be taken into account in this step? What would you do > differently if you were at the time you started coding Kicad? What are the > dead valleys? What would you expect from such a project? > > > Regards. > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
