kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #05128
Re: BOM support
On 08/05/2010 01:53 PM, Lorenzo Marcantonio wrote:
> On Thu, 5 Aug 2010, Dick Hollenbeck wrote:
>
>
>> The more I look at PyQt4, the better it looks. It has a python layer on
>> top of a decent Qt XML library. How's your python?
>>
> Are you sure we aren't imposing too much dependencies?
>
Good question! We were told recently that there are a number of
projects "out there" that might come under an umbrella of contrib. I
wonder if we opened that gate how many would arrive carrying their own
language and tool requirements? Own programming styles, own tool-sets,
own user interface standards?
*** I think we share the same concern, if we open the gates. I don't
want to even look at C code written by somebody that thinks the linux
kernel source looks good, complete with tabs. I would not want to have
my grep tools even go down in there while searching for a function name.
*** Sometimes a tool does not reach critical mass unless there is more
than one set of eyes on it, using it and supporting it. So unless it
becomes part of a community, then it can die. Frank said he left it out
there at sourceforge.net. I once left some 8th grade art projects
outside, and eventually forgot about them.
So those are your two extremes, a) pull everyone's work in, even if
half-baked, or b) ignore it.
I was thinking there was a middle ground somewhere, using something more
relaxing than C++, and relatively easy to learn and to conform to.
I am not aware of a decent python UI library that comes as standard.
Naturally this is simply a brainstorming process here. I don't view it
as anything other than a discussion.
I would also add that for a free tool, asking the user to pay some
price, is not unreasonable. In this case, that price would be to do an
installation of other free software in order to support this project's
free software. If the return on investment is there, what's to complain
about? Your point about too many dependencies is something to be
weighted as greater than zero, it is valid, but we should be careful
when we assign that weight.
Had we had a tool/utility language standard in place, then perhaps
things like Oyvind's part library would have been done in that up front,
rather than in perl. The speculation is that with an published open
door policy, then folks could work in a particular scripting language
under the advance understanding that the tool has a place to live later,
and not die on the vine.
No standards, means no conformance.
And yes, Java needs to be on the table too, at least until a decision is
made, if only because of the platform independence of the JVM and all
the languages that run on top of it.
Frankly, I cannot see why cvpcb could not be written entirely in PyQt4,
and be a central ram resident real-time interface between eeschema and
pcbnew, like we talked about for D-BUS. Also, I am not sure why a
person needs both kicad AND cvpcb programs. Seems that one could do the
role of both, app launcher, communicator and part picker? OK, the
brainstorming is getting the better of me, I will never live long enough
to do all that work for free.
Bye,
Dick
> We have wxWindows (and that's ok, the primary toolkit);
> then python (reasonably diffused, with issues about which version to use
> - I'd go with python 2 if you want a vote)
> Now PyQt4 which in turns requires Qt... (and Qt isn't exactly light:P)
>
> You could always add a Java part to a Gnome program using KDE libs, at
> this rate:P (obviously it's a joke otherwise I could try to fit a .NET
> component somewhere in there :D)
>
> I don't know python but isn't there 'standard' toolkit for it? like
> something already included with the python install. Since we're talking
> about utility scripts I guess we wouldn't need very sophisticated UI...
>
>
Follow ups
References