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 > _______________________________________________ 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
