The developers have worked hard on KiCad and there is momentum to add
what is necessary.
The users have a certain responsibility too:
If KiCad supports their particular assemblage of hardware - fine.
However, if KiCad has moved on, it is the users responsibility to add
hardware to catch up, rather than the developers having to support
ancient iron with momentum killing work.
Thanks much - Bob G
On 10/15/2015 05:58 PM, Stefano Rossi wrote:
I'll try to be as helpful as I can. I share the opinion about having
KiCad support a minimum set of hardware.
I believe that one must set the bar. If those who develop the OpenGL
canvas with X or Y hardware. Then that should be the tested hardware,
but include that minimum require GL version, such as v2.1. Leaving the
choice of the user to risk it with some unsupported hardware. Users
will form a community and eventually will lead to a pruned out list of
user sought out minimum/cheap hardware that supports such operations
at an acceptable level.
Developers should/could intervene when X or Y hardware that is OpenGL
2.1 compliant but doesn't work on it. I say this because, as pointed
out by Adam, I suspect developers would rather be implementing
features, ironing out bugs, and moving the software forward to the
greatness it can and will be.
Just picking out a set of operating systems where it is currently
being developed on, and support it. As said earlier, X version of
Windows, Y version of Mac, and Z version of Linux distro (pick the
linux distro out of popularity, some will be against this).
If one goes on chasing the hares tail in the support all and be all,
developers will burn out seeing all their effort going into bug
fixing. Once a version is released then effort can go into testing X
or Y systems, but shouldn't be the main focus.
As for the displays, I believe that 1024x768 is too small. Aim for
higher. A resolution at which for example all menus are visible as
intended, tool bars are not cut and cramped or hidden. I am sure that
when adding buttons/features to the toolbar, someone had a monitor
where it all fit, and if it doesn't some industrial engineering must
go into usability. I know supporting hardware is all the rage for open
source tools. Limits must be set. FAQs can be added for the
adventurers to tinker with.
To be honest, even the novice user will be glad that if he or she has
at least the minimum required hardware, KiCad will run at decent and
useful speeds. Uphold the decisions and don't be lax. I have seen
threads where the discussion was about if python 2.x or 3.x should be
needed to work, if it is needed to get a working software then ask for
it as a system requirement. As an example, it is the same as asking
that glibc is needed to run the software.
I don't know how much of my opinion is listened too, but having the
experience of being: a novice of Ares, moderate user of Eagle (even if
paid for, free version lets students as I was develop interesting
things), moderate user of OrCAD and advanced user of Altium; have at
least an idea of what is needed. Users don't want a software package
that must be guessed at if it will work or not on a system. Users
usually start as a hobby or some project, but eventually start
demanding more and more out of the software. I see KiCad as a
potential suitor for the novice up to the professional. This is why I
parted from Eagle and Ares, compared to OrCAD and Altium feature wise
there's no contest in usability after one gets accustomed to the
quirks and ways of the individual package.
I know all developers don't have the same systems, but I somehow see
progress in uniformity and working towards the same goal, but never
trying to go backwards. There's no point in supporting hardware older
than, for example, 10 years because next year the hardware of 9 years
ago will be cheaper. Test driven development should help out with non
uniform systems where a build machine does the tests. I am an
programmer than thought TDD was rubbish and a waste of time, its more
fun to jump into the solution of problems, but once the system gets
too complicated one sees themselves backtracking each change.
I should shut up, rambling to much.
On Thu, Oct 15, 2015 at 3:14 PM, Jon Neal <reporting...@gmail.com
<mailto:reporting...@gmail.com>> wrote:
I would really like to see KiCad work better on 1366x768 screens.
This was pretty much the de facto standard laptop screen
resolution until the last year or two.
The laptop I currently use daily is this resolution and I expect
to get another few years out of it at least. I realize it is a
fairly small resolution, but it is what I have and I know is still
super, super common.
Jon
On Thu, Oct 15, 2015 at 1:05 PM, Markus Hitter <m...@jump-ing.de
<mailto:m...@jump-ing.de>> wrote:
Am 15.10.2015 um 17:29 schrieb Adam Wolf:
> 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.
Adam,
thanks for explaining what the motivations are. I have to
admit that I
almost get into a rage when I read all this cheering about how
foolish a
user working on simple hardware would be. A large screen is
entirely
fine (I have one, too) for those who enjoy them, but declaring
somebody
as dumb who has choosen to not use one is certainly not
respectful.
Especially in the hobbyist area most people do very simple
things, so
there is simply no need for rendering 10'000 tracks at 60 fps.
These
users are perfectly fine with much less, so I try to put in a
vote for them.
> Opportunity cost and focus, mostly.
[...]
> 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.)
I'd be entirely fine with stating exactly this. "Graphics is
tested with
1024x768 and larger, your mileage may vary with smaller
screens". Sounds
much much better than "only a fool would try on 800x600".
[...]
> 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."
Also a good, helpful description. It makes clear that nobody
tries to
stop users from using the software. Actually it sounds very
positive,
because it describes that KiCad is capable of taking advantage of
accelerated hardware.
[...]
> 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.
While I'm new to KiCad, I'm not new to Open Source development in
general. Yes, there are always users which try to get
developers into
additional work. Asking is cheap, after all. Experience is,
this never
stops, no matter where one draws the line. If you claim to
fully support
800x600 they'll ask for support on their phone. If you support
phones
they'll ask for these 384x240 embedded displays. And so on, to
no end.
Still it's not helfpul to rigorously show them the door.
A simple and, to my experience, well working solution is to
ask these
people for their code. Along the lines of "We currently have no
developer being interested in writing such code, but if you
contribute
it, we'll likely accept it". 9 of 10 people will walk away
after such a
statement, without being miffed. If the tenth user actually
comes up
with code, all the better!
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help : https://help.launchpad.net/ListHelp
--
<a
href="http://wikimediafoundation.org/wiki/Support_Wikipedia/en";><img
border="0" alt="Support Wikipedia"
src="http://upload.wikimedia.org/wikipedia/commons/d/d3/Fundraising_2009-square-share-en.png";
/></a>
_______________________________________________
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
![http://upload.wikimedia.org/wikipedia/commons/d/d3/Fundraising_2009-square-share-en.png"](http://upload.wikimedia.org/wikipedia/commons/d/d3/Fundraising_2009-square-share-en.png"){kind=link}