Markus, I appreciate your enthusiasm, but I do not think saying "KiCad works on computers" is going to help our users or our developers. I think this is actually a question of opportunity cost and focus, similar to your other posts from the last few days.
I've come to learn a lot of things during the last 5 years on the KiCad list, and I hope this email can help explain how I view things. KiCad has a lack of qualified developer time, and many of our decisions are made with opportunity cost in mind. KiCad has a large number of users, and a small number of developer-hours. This has been a concern for a while. There are a variety of things that can be done (and are being done), like lowering the barriers to entry, being nicer on the mailing lists, increasing the quality of KiCad, and making it easier for people to get up-to-date builds. All of these are things that attract developers, help them get good at developing on KiCad, and also help keep the developers that are working on KiCad already, happy and not burned out. (Coincidentally, all of these things directly help KiCad's users as well, how convenient!) I think we're actually doing a pretty good job of that, especially historically speaking. However, it is 2015, and we only have the barest of automated testing. This has been on my list for quite some time, and is at the top of my list for after KiCad 4.0.0. Why isn't it done, if I've been around for 5+ years and have had this as a priority? Opportunity cost and focus, mostly. I have a wife, a kid, a day job and a side business, and I choose to give away my time to make KiCad better, nearly every single day, because I think KiCad is really, seriously, important. On the other hand, I can only spend a little bit of time each day. I try to balance my time between user support and KiCad quality improvement. I think it's very important for developers to maintain a good connection with users. It's easy to do things "the developer way" and miss huge usability issues for users. At the same point, it is very easy for me to spend 100% of my KiCad time dealing with support, at which point I cannot contribute to any sort of longer-term KiCad strategy. For instance, yesterday, I spent almost an hour talking with a user trying to figure out why he thought the 4.0.0 release was out, searching through the website, seeing if I can fix the misunderstanding at the source, drafting an email to the list... I haven't seen any way in which we actively stop users or developers from doing anything, and I don't see that changing. With that in mind, minimizing the support emails and questions means I have more time to make KiCad better, and presumably other people do as well. Designing KiCad with focus means that we have more developer time to make KiCad better. If we have to design KiCad so it works great on 800x600 screens, for example, is that extra *manual* testing on every single GUI change for developers? (today, yes.) Does that help or hurt the KiCad effort, if we go out of our way to support and maintain a quality GUI that works well at 800x600, *at the expense of other things those developers could be doing with that time?* If we say "KiCad supports computers with operating systems" are we going to have happier users and am I going to get more or less email than if we have a webpage that says "KiCad tries to work on most systems, but it is packaged and has been nominally tested on Windows X-Y, OS X 10.X-10.Z, and many Linux distributions, like Fancy Feast and Candy Corn" On the other hand, if we put up a webpage that says, "KiCad tries to work with every configuration, but we suggest you use a 1024x768 graphical display for best results", does that help or hurt the support load? Does it help or hurt if we say "KiCad can use the GPU to make PCB editing of larger boards more responsive. Nicer GPUs, like the Frobnitz Zorkmid EXTREME, work better than software GPUs like the Foobar H3." To me, I think statements like that would help establish user expectations, lower the developer support load, and ultimately make KiCad better. The effort to "just" maintain a graphical, user-oriented program suite (that never changes) on new versions of Windows, Mac and Linux should not be underestimated. Add in the fact that we're trying to fix bugs and add new features, and it becomes an actual serious effort. I think almost all the devs here that have been around for any length of time have found, patched, and reported bugs in our dependencies. This might just be my proverbial neckbeard or getting old, but I really do try to think of the opportunity cost, focus, and support load when evaluating pretty much anything related to KiCad. If I end up spending 100% of my time supporting users who expect KiCad will work amazingly on their 200 mhz Cyrix, they're going to have a bad time, and I'm going to have a bad time. If the dev mailing list is full of people yelling at each other, like it used to be quite often, personally, I'm going to find less time to spend on making KiCad better. If the required dependencies change all the time and I have to spend all my dev time getting my builds working, once again, that's more time I can't spend on making KiCad better. (I am not the Lorax, I do not speak for all the devs, but I've been around for quite a while and help out where I can.) Adam Wolf Cofounder and Engineer W&L On Thu, Oct 15, 2015 at 9:58 AM, Markus Hitter <[email protected]> wrote: > Am 14.10.2015 um 19:47 schrieb Wayne Stambaugh: > >> As for 1024 x 768 and lower resolutions, are we kidding? Who has a 1024 > x 768 monitor that gets regular use? That’s crazy. After all, the second > syllable of Kicad is CAD, and CAD applications want as much screen real > estate as possible! You’re a masochist if you’re trying to run Kicad on an > 800 x 600 display. Gotta draw a line in the concrete somewhere. > > > > Thank you! I could not have said it any better myself. > > With all this boasting about screen resolutions I start to wonder wether > moving to KiCad was a wise move. > > > Am 14.10.2015 um 21:54 schrieb Marco Ciampa: > > I just want to compile a _reasonable_ system-requirements list, > > nothing more, nothing less. > > Good point. > > > > - Up to 500 MB available hard disk space; > > Likely not sufficient. All these libraries take a lot of space. Recently > my package manager reported 1.4 GB required space for the packages. Half > the 3D models I currently have add 1.1 GB on top. > > 2 GB without 3D and 5 GB with 3D is probably closer to the truth. > > > > - 1280x1024 resolution (higher resolution recommended), with at least > 16K colors. > > I just tried with a small window on a larger screen, sizes around > 1024x768 work ok. It's not ample, of course, but perfectly usable. > > Even 800x600 basically works, but about half the toolbar buttons > disappear then. One can use the regular menus, of course, still not good > for a "recommended" setup. > > > - Graphic card with at least OpenGL 2.0, with hardware shaders. Check > > the opengl specs of the card: > > > > - Intel: Intel cards are reported working from model HD2000 and higher. > > No pre-HD models. > > A pre-HD model works just fine. With the default/Cairo canvas and with > software emulated OpenGL canvas. The latter is simple, just run with > LIBGL_ALWAYS_SOFTWARE=1. > > BTW., the OpenGL canvas asks for v2.1, not v2.0. > > > Minimum system requirements? Uhm, how about simply stating "A computer > running one of the supported OS's, see the download section". > > > Markus > > -- > - - - - - - - - - - - - - - - - - - - > Dipl. Ing. (FH) Markus Hitter > http://www.jump-ing.de/ > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
