-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
There are still a lot of things missing in KDE 4.1. There appears to be
no way to put a random app from the menus into a panel; apparently they
all have to be plasmoids, and you cant use a random plasmoid. The
wireless / network monitor cannot be moved to a different panel... in
fact, more than half the default icons cant be moved. I cant change my
keyboard layout. Im stuck with deadkeys I cant use... hence no quotes in
this message and no apostrophes.
Positive: intrepid has kernel 2.6.27. My wireless works beautifully now.
Serious negative: KTechLab will not compile. My bad, I likely dont have
the KDE3 dev libs installed anymore.
Getting back to the discussion though, I want to see the simulator have
its computation built in (even so far as replacing a subcircuit with an
expression if not on the same sheet if desired to speed up computation),
so it will need an equation editor. These equations could be saved in
the subcircuit file. The XML is strictly a simple way of organizing the
file format IMO, so that the component attributes, the SVG, the
footprint, and if need be a (simple!) 3D model of the component can be
included in the library.
When KTechLab saves a circuit file, I like the idea of taking the
component definitions with it. This functionality could be user-option
to keep the file size small, i.e., ´Save Stuffed Circuit´ or ´Save
Simple Circuit.´
So I have been imagining:
component format:
* component name, id, etc.
* component reference header
* component attributes (these are what are acted upon by simulator,
i.e., R, C, L, W, V, or whatever else this component needs.)
* component symbol SVG
* component PCB footprint (if defined, also SVG)
* component rough 3D shape (if defined)
a Library would contain:
* library symbol (SVG, for the list to the left)
* component1
* component2
* ... etc.
The library file would of course be shipped compressed and with a
component manifest that could be searched, so that when looking for a
component within the software it could check its local libraries first,
and if it is not there, search our component library database on the web
and automatically download the compressed file with the manifest. Add a
user-submitted section and a symbol / footprint / simple model designer
and we have an extensible library system on par with anything else out
there, including the Big Expensive Guys, except people dont have to go
looking all over the web. We´ll have it all in one place, and have a
couple of mirrors just in case.
Component formats for custom versions of simple items can still use
inheritance. A really simple example:
class resistor
class 1/4_100 resistor (R 100m W .25)
Still the same thing, just different numbers. Where we get into a
difficult spot is where we need to use other components to make a new
one. Iĺl call it a compound component for lack of a better word:
compound component transformer
*(all normal component attributes.. name, ref, etc.)
*component inductor (primary)
*component inductor (secondary1)
*component inductor (secondary2)
*equation secondary1 = primary V/2
*equation secondary2 = primary V/2
... and so on. The entire operation of the device could be specified in
the equation, or in the case of multiple equations, for example the Z of
the transformer, can have multiple named equations that can all be
solved for at run-time depending on what data the user is actually
asking for.
The FlowCode and the PIC processing... I see absolutely no reason to
change these one bit. I honestly cant think of anything that should be
added, with the exception of a ´processor class´ that all have FlowCode
containers. Im not a digital guy so if anyone has a feature request,
speak up...
- --G
Julian Bäume wrote:
> On Saturday 08 November 2008 23:31:04 Glen wrote:
>> I'm upgrading to ubuntu 8.10 as I write this to make dealing with the
>> KDE stuff better and to fix a few things I've torn apart. I had KDE 4.0,
>> not 4.1 Classic wasn't available in 4.0 and that's a large part
>> wasn't enjoying the experience.
> Just a short answer here: I can now understand your rants about KDE4 ;) I can
> tell you: it really got better since then and will even be more powerful,
> when
> 4.2 will be released in January. I have to admit, that I'm quite impatient,
> too ;)
>
> julian
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ktechlab-devel mailing list
> Ktechlab-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkkXJWoACgkQLstl3vProOCKWACgnmZ+IcU+GNQjXqZJw6WRpus2
nwsAn0sZFv66AovX4doNvNfXrTTw/8bQ
=F5TV
-----END PGP SIGNATURE-----
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Ktechlab-devel mailing list
Ktechlab-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
