> On 23 September 2010 17:26, Kuba Ober <> wrote: >> I don't think I want to support TCL at all. If someone else will contribute >> code -- fine, >> but I won't touch it. Python seems a best match, especially since you can get >> nearly native performance using LLVM, CLR and JVM-based implementations. >> Only cPython is using bytecode interpretation, other implementations I >> mention >> are using an optimizing JIT. > > > Hello there, > > I think it is a very bad idea to drop tcl. > > first from the user's point of view, > - all their custom scripts will be useless.
That's true. Now the question is: how many xcircuit users are there with such scripts? Another question: does one want to alienate the few users xcircuit currently has? And yet another: does one count on those users to be significant, with expectation that perhaps a better, portable schematic/pcb package will gather larger userbase. It's not all cut-and-dried. I hate to disappoint users, since they are the ones who make it a worthwhile endeavor. I'm a user too, of course. But sometimes it's all about the resources. So here's what I propose: it may be less work for me to translate someone's, even many-ones tcl scripts to python, and post them online as examples of how to do it. Would that satisfy you? > - less real engineers will be interested to spend time learning other > languages which most certainly they are not using at work. Are there really that many engineers who use TCL? I'd think anyone "new" who graduated in the last few years would be looking at python for general-purpose engineering scripting? > - features such as launching ngspice within xcircuit via tclspice will > entirely be broken. I plan to have native integration with ngspice and ltspice, too, so that shouldn't be a problem. > I think the main benefit xcircuit or other opencircuitdesign tools can > benefit is rather to focus on the real features which are missing > compared to proprietary solutions. The GUI can look good and sexy, > however doesn't provide additional benefits with respect to the actual > xcircuit's version. It's not about the GUI, that's a side effect that's completely free in this case. Free as in beer. No work, big payoff. But what it's really about is slashing the codebase down by a big factor, and making it manageable, while adding features. Qt is an application development framework, not merely a GUI toolkit. It implements containers, runtime introspection and inter-object connectivity, network access, file access, process management, threading, synchronization ... It's all cross-platform. It's a huge productivity booster. I know, I develop daily in C for embedded applications, so I can see the difference quite well. xcircuit was written in C. The language is inherently less expressive than C++, and even more so compared to C++ with a introspecting preprocessor (moc). Moc -- meta object compiler -- reads the C++ headers of classes deriving from QObject in your project, and generates static classes that document the signals and slots QObjects. Cheers, Kuba _______________________________________________ Xcircuit-dev mailing list [email protected] http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
