kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 12/14/2010 03:22 AM, Martijn Kuipers wrote:
> On Dec 14, 2010, at 2:55 AM, Dick Hollenbeck wrote:
>
>> On 12/13/2010 01:48 PM, Dick Hollenbeck wrote:
>>> Wayne and Torsten,
>>>
>>> Here is a patch that allows the GAL to compile and run on Ubuntu Lucid x86_64
>>>
>>> with *version wxWidgets 2.8.x*
>>>
>>> The key thing is the wxWidgets version.  The repo seems to be dependent on 2.9.
>>>
>>>
>>> Moving forward, we're going to need write access to a branch holding this stuff.  I
>>> think we should keep it a separate branch.  Kicad's Cmake can be told to do a checkout
>>> later.
>> If the *community* decision is to move forward with it.  (Seems that could have been a
>> point of mis-understanding.)  I am only one voice, but I should get a good look at it
>> over the Christmas break.
> Great, for me an example (just like you planned) might show me the value of Torstens' work. Not saying there isn't any, I am just not seeing it (my fault really).

I had a cathartic moment this weekend when the BLIT operations under wxwidgets on
linux flunked in the extreme.
I don't yet know what the better alternative is yet, just know we need one.  For
gerbview, cairo and pixman are in my scope, and some research can be put into
techiques in gerbv and its graphical foundations, which I think are cairo and pixman.

> If I understand correctly you (DIck) are proposing to maintain 2 branches for a while:
> - Kicad as we know it
> - Kicad Next Generation

I personally am only committing to a design, and to code only a new EESCHEMA
foundation.  I won't live long enough to create a new Kicad, inclusive of PCBNEW,
since I only have several hundred hours to donate each year.  I hope it is not just me
and Wayne working on this.   Wayne is already on board to write critical portions of
it, others are welcome.


Once the new foundation is poured, pieces of the old EESCHEMA can come over on top of
the new foundation, one by one, and during that time we can get a look at each piece
separately, to see if it is worth keeping or re-writing.  Obviously the old library
editor and manager will all go away.  The parts list concept is not going to be easy
to implement, and the chief struggle there will be providing a user friendly interface
experience.  That is why I wanted to do that very early, to prove the *UI* and
usability experience concepts early in the game. 

The remote aspects of some of the LIB_SOURCEs don't currently seem as difficult, and
they can be implemented incrementally over a long period of time, by any number of
people at any time.  The design enables that.  Some of them will require servers on
the back end, and much help is needed to write those, if they are to get done at all. 
Those servers are not cast in stone, other than they have to work with the LIB_SOURCE
running on the client, which is in C++.  But the servers themselves can be in any
language, could be python, or an apache module, whatever.


> If the next generation is as promising as is foreseen, then one day we (Jean-Pierre) will just bless the next generation branch as the stable one. Right ?

Yes some time will be needed.  The real EESCHEMA switch happens when folks start using
it, and they will cast that vote when and if they find it superior.

Dick


> Thanks for all the effort people are putting into Kicad.
>
> /Martijn 
>