← Back to team overview

kicad-developers team mailing list archive

Re: suggested resolution (and other specs)

 

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 <reportingsjr@xxxxxxxxx> 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 <mah@xxxxxxxxxxx> 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
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-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>

Follow ups

References