It finally dawned on my pathetically dim mind why I'm having such a hard time preventing people from making drastic changes to the electronics simulation prior to the KDE4 port. =\
That reason is that while everyone sees the same needs I do, they do not understand how I wish to approach them. This is because I have not taken the time to explain myself. The problem is that people crawl into the mighty temple of the CPU on their hands and knees, and beg the CPU to compute for them. The CPU responds THOU SHALT PROGRAM ME IN C++. And the pathetic suplicants rejoice and say "Yes, master, we shal program you in C++. We will turn all our problems into C++ programs for your pleasure.". Now here's what you should be saying: "Listen up slave. I have some things for you to simulate. Here the facts, now compute!!" If he says anything other than "yes master, anything you say, master." you take out your whip and beat him. That's how you treat a computer. C++ is a very difficult language. It takes no less than seven years to master. Furthermore, the API's for linking in runtime modules are obscure if not undocumented. If ktechlab is to take off, we need to provide the user the tools to add his own components without venturing within ten miles of a C++ compiler. To allow the user to add components, we should not be thinking in terms of plugins, because plugins are lame. We should be thinking in terms of declarative programs which the ktechlab engine will interpret and/or compile itself. -- A new, easier, form of SPICE. The user will have several options for creating componenets: -- He can create components as subcircuits in the GUI from circuit elements and/or anything else and add them to the component library. -- he can create components by using a part editor to create a library configuration for one of the built-in models such as for transistors or triodes. -- the system will hold this as a database item. -- or he can write a program which describes the matrix and other equations he needs to create a new model. To make this work, we need to continue my efforts to streamline and minimize the code throughout the system. We then need to refactor the components and simulations such that each part of the simulation represents, as best as possible, an atomic concept. For example the Current Source should actually be composed of two elements, a pin that sources current and a pin that sinks current. By doing this the flexability and power of the engine will improve radically. Another long-term headache of mine is the modeling of logic Outs, I've put a great deal of time into refactoring those classes. Effectively a rewrite at this point. I had this problem that I wanted to create a matrix which represented a fixed voltage say 4.8 volts or 0.2 volts, and a source impedance. Well, I spent days and days, weeks even, going about it the wrong way. I should have simply linked in a voltage source and an impedance and called it a day!! =P Another example. One very accurate way of modeling a diode is as a diode with a second, very weak, diode pointing the other way. So you get one set of parameters I_S, and N for the forward diode, and another for the reverse diode: I_SR, N_R. The previous code computed both of these in one go. The current code has one diode junction which might be used twice to compute the reverse part of the diode. In summary, plugins are the wrong way to approach the problem of letting the user program ktechlab. We want the user to program ktechlab strictly through the GUI, both graphically and through the part editor, with the ability, eventually, of parsing a new part description language file with an internal compiler. -- DO NOT USE OBAMACARE. DO NOT BUY OBAMACARE. Powers are not rights. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
