← Back to team overview

kicad-developers team mailing list archive

Re: suggested resolution (and other specs)

 

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 <reportingsjr@xxxxxxxxx <mailto: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
    <mailto: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
        <https://launchpad.net/%7Ekicad-developers>
        Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
        <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
        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@xxxxxxxxxxxxxxxxxxx
    <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
    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@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


References