KiCAD: Warum Umgebungsvariablen ?

Generell gestatten es Umgebungsvariablen, dass man verschiedene 
Konfigurationen (bspw. verschiedene Bibliothekssammlungen) auf einem 
Computer vorhalten kann und darüber dann entsprechend auswählt.

Normalerweise musst du an diesen Variablen jedoch nichts herumschrauben, 
wenn du nur eine Konfiguration benutzen willst.

Dennoch gebe ich dir Recht, dass auch ich das Handling der 
Bauteilbibliotheken an dieser Stelle nicht sehr geradlinig finde. 
Praktisch jedes Projekt wird mindestens ein paar Bauteile brauchen, die 
man nur dafür am Ende anlegt, also braucht es für nicht-triviale 
Projekte eigentlich immer auch Bibliotheken sowohl für Schaltplan als 
auch Footprints, die lokal im Projekt liegen.

Der erste Pferdefuß: wenn man den Footprint-Editor öffnet, bekommt man 
eine leere Arbeitsfläche, in der man aber nichts machen kann. Erst, wenn 
man File -> New Footprint oder das entsprechende Icon klickt, bekommt 
der Footprint einen Namen, und die Editierfunktionen werden 
freigeschaltet.  Zweiter Haken: es gibt im File-Menü nirgends einen 
Punkt "Save as new library". Den Punkt gibt es natürlich schon, aber 
nur als Icon (Create new library and save current footprint). Dritter 
Punkt: die Library ist danach zwar da, aber trotzdem muss man danach 
noch über Preferences -> Manage Footprint Libraries hingehen und sie dem 
Projekt hinzufügen. Es wäre natürlich schön, wenn man zumindest beim 
Abspeichern innerhalb der Projekthierarchie (was ja zum Glück sogar der 
Standardvorschlag beim vorhergehenden Schritt ist) gleich gefragt würde, 
ob man sie nun auch dem Projekt hinzufügen möchte.  Vierte Unschönheit: 
obwohl man zuvor den Footprint in einer neuen Bibliothek gespeichert 
hat, wird man beim Schließen des Footprint-Editors gefragt, ob man ihn 
jetzt speichern will. Einfach "Ja, speichern" sagen geht allerdings dort 
nicht, denn man hat ja gar keine aktive Bibliothek ausgewählt … wenn man 
das das erste Mal sieht, traut man sich nicht so einfach, auf "Nein" zu 
klicken, was aber völlig ausreicht.

Jörg W. schrieb:
> Der erste Pferdefuß: wenn man den Footprint-Editor öffnet, bekommt man
> eine leere Arbeitsfläche, in der man aber nichts machen kann. Erst, wenn
> man File -> New Footprint oder das entsprechende Icon klickt, bekommt
> der Footprint einen Namen, und die Editierfunktionen werden
> freigeschaltet.  Zweiter Haken: es gibt im File-Menü nirgends einen
> Punkt "Save as new library". Den Punkt gibt es natürlich schon, aber
> nur als Icon (Create new library and save current footprint).

Es gibt Hoffnung, 5.1 soll einen überarbeiteten Footprint-Dialog 
bekommen, u.a. erkennbar ist bereits:

1

- The 3rd icon is "Create a new library and save the current footprint" but it doesn't have any option for that on the File menu.

2

Already fixed in 5.1.

3

4

- can't use "save as" properly with modified footprint

5

status:   In Progress → Fix Committed 

6

milestone:   none → 5.1.0

Mein Eindruck: man hat mit diesen Github-Bibliotheken ja ein bisschen 
das versucht, was "nebenan" Lukas mit seinem "Pool" (in Horizon) 
versucht: jeder Einzelne sollte neue Bauteile einfach beisteuern können, 
und sie werden dann nicht lokal auf der Platte, sondern in einem 
Github-Repository verwaltet.

Klar hat das was, aber projektspezifische Bibliotheken und deren 
Handling sind dabei, naja, wohl ein bisschen auf der Strecke geblieben. 
Sie funktionieren schon noch, nur eben nicht so sehr geradlinig.

Jan L. schrieb:

> Es gibt Hoffnung, 5.1 soll einen überarbeiteten Footprint-Dialog
> bekommen, u.a. erkennbar ist bereits:

Schön. Hatte schon überlegt, ob ich da selbst mal reingucke.

Hallo,

Jörg W. schrieb:
> Sie funktionieren schon noch, nur eben nicht so sehr geradlinig.

Meiner Meinung nach: sie kompletter Murks. Ich beschäftige mich seit 
einiger Zeit mit KiKad und habe auch gerade mit der Footprint-Erzeugung 
"gekämpft", aber etwas derart unintuitives, umständliches und 
unlogisches habe ich schon lange nicht mehr gesehen. Und das dann noch 
nicht mal die Dokumentation zur Programmversion passt ist bezeichnend.

rhf

Roland F. schrieb:
> Und das dann noch nicht mal die Dokumentation zur Programmversion passt
> ist bezeichnend.

Es ist vor allem bezeichnend für die massiven Veränderungen, die Kicad 
in letzter Zeit durchgemacht hat.

Meine Meinung: wesentlicher Punkt, der viele potenzielle Eagle-Umsteiger 
abschreckt ist, dass bei Eagle extrem viele Bauteile bereits fertig als 
Bibliothek vorliegen. (Für alles, was es nicht gibt, gibt's dann hier 
einen Forenthread. :) Irgendwer wollte mit diesem github-Pool nun 
versuchen, dahin aufzuschließen. Aber das ist nur 'ne Vermutung.

Hallo,

Jörg W. schrieb:
> Meine Meinung: wesentlicher Punkt, der viele potenzielle Eagle-Umsteiger
> abschreckt ist, dass bei Eagle extrem viele Bauteile bereits fertig als
> Bibliothek vorliegen.

Ein Grund mehr alles zu tun um es Um- und Einsteigern so leicht wie 
möglich zu machen neue Bauteil-Footprints zu erzeugen und zu verwalten. 
So wie es bisher funktioniert kann es meiner Meinung nach jedenfalls 
nicht bleiben.

rhf

Roland F. schrieb:
> Ein Grund mehr alles zu tun um es Um- und Einsteigern so leicht wie
> möglich zu machen neue Bauteil-Footprints zu erzeugen und zu verwalten.

Der typische 08/15-Eagle-Nutzer konnte da ja auch nicht. :-))

Schau doch einfach mal, viele Eagle-Nutzer fragen selbst nach den 
simpelsten Bauteilen …

Im Prinzip natürlich richtig, das sollte irgendwie einfacher und 
schlüssiger sein.

Holm T. schrieb:
> speziell zu den Footprints gabs mal ein "Wizzard"

Einen "Wizzard" gibt's noch, aber der erstellt mehr oder weniger 
regelmäßige Footprints. Allerdings sind das wahrscheinlich die, die es 
sowieso schon in den Libs gibt. Die, die man selbst erstellt, sind dann 
eher nicht so regelmäßig.

Prinzipiell finde ich die Idee eines solchen "Pools" ja nicht schlecht, 
so richtig wüsste ich auch nicht, wie man das am Ende mit eigentlich 
immer notwendigen lokalen Bibliotheken in Einklang bringt.

Jörg W. schrieb:
> Schau doch einfach mal, viele Eagle-Nutzer fragen selbst nach den
> simpelsten Bauteilen …

Naja, sorry, aber nicht weil es nicht geht oder zu umständlich wäre, 
sondern schlicht aus Faulheit.

Jörg W. schrieb:
> jeder Einzelne sollte neue Bauteile einfach beisteuern können,
> und sie werden dann nicht lokal auf der Platte, sondern in einem
> Github-Repository verwaltet.

Oha, und wenn das Internet down ist, sind meine Bauteile weg oder wie 
stellt man sich das vor?

Ein Pool zum Austausch ist sicher eine gute Idee, aber für meine 
Projekte würde ich dann schon gern lokale Footprints haben.

Karl K. schrieb:
>> jeder Einzelne sollte neue Bauteile einfach beisteuern können,
>> und sie werden dann nicht lokal auf der Platte, sondern in einem
>> Github-Repository verwaltet.
>
> Oha, und wenn das Internet down ist, sind meine Bauteile weg oder wie
> stellt man sich das vor?

Git benutzt doch sowieso eine lokale Kopie des Repositories.

Wenn das Internet down ist, kannst du sie folglich nur nicht zurück 
schieben, aber benutzen kannst du sie natürlich.

Hallo,

Jörg W. schrieb:
> Schau doch einfach mal, viele Eagle-Nutzer fragen selbst nach den
> simpelsten Bauteilen …

Ja, das ist mir auch schon aufgefallen.

> Prinzipiell finde ich die Idee eines solchen "Pools" ja nicht schlecht,...

Damit habe ich mich noch nicht beschäftigt, aber...

> ...so richtig wüsste ich auch nicht, wie man das am Ende mit eigentlich
> immer notwendigen lokalen Bibliotheken in Einklang bringt.

... kann man denn die Bauteile aus diesem Pool nicht lokal sichern?

rhf

Jörg W. schrieb:
> Git benutzt doch sowieso eine lokale Kopie des Repositories.

Aber will ich wirklich das ganze Git-Repo auf der Platte haben? Ich lad 
mir doch auch nicht jede verfügbare Eagle-Lib runter, sondern nur die, 
die mich interessieren.

Karl K. schrieb:
>> Git benutzt doch sowieso eine lokale Kopie des Repositories.
>
> Aber will ich wirklich das ganze Git-Repo auf der Platte haben?

Du musst das ja nicht, du kannst dir auch nach wie vor nur das lokal 
hinlegen, was du haben willst.

Es ist eben nur inzwischen die Voreinstellung, das so zu machen.

Mal ganz ehrlich: Speicherplatz, insbesondere Plattenspeicher (bzw. das, 
was eine Festplatte ersetzt) ist mittlerweile so spottbillig, dass es 
kaum lohnt, darüber zu diskutieren. Wirklich Platz kosten in diesen 
Bauteilen am Ende eigentlich nur die 3D-Modelle, der Rest ist "Peanuts". 
Aber gerade die Integration von 3D-Darstellungen ist natürlich ein 
Feature, auf das wohl niemand mehr verzichten möchte, der damit bereits 
gearbeitet hat.

Hallo Holm, Jörg und Roland.

Holm T. schrieb:

> ..nein, den meinte ich nicht, sondern ein Tool das die Directories und
> Github als Quelle verwaltete und die Pfade entsprechend anpaßte.
> Das betraf also eher nicht die Erstellung sondern die Verwaltung der
> Footprints.

Dann hast Du eine noch wesentlicher neuere Version als ich. Bei mir 
gibts den noch. Ich bin aber nicht an meinem Rechner und kann darum 
nicht sagen, welche Version.

Allerdings habe ich den nur selten verwendet, um darin etwas anderes als 
eine Library einzutragen. Gerade bei den Prettyformaten habe ich die 
Bibliotheksverwaltung immer mit einem ("klassischen" zwei Fenster) 
Dateiverwaltungssystem gemacht (krusader). Das System bietet sich ja 
dazu an.

Das ist aber mit einer der Gründe, warum ich mir um Umgebungsvariablen 
nie so groß einen Kopf gemacht habe, und diese auf "default" gelassen 
habe, oder nur im Notfall verwendet habe. Zumindest bei älteren KiCad 
Versionen konnte ich mich so weitestgehend an den Umgebungsveriablen 
vorbeidrücken.

Ich muss mir bei gelegenheit doch mal eine neue Version compilieren. 3 
Monate sind bei der Entwicklungsgeschwindigkeit eine Menge.

Jörg W. schrieb:

>> Aber will ich wirklich das ganze Git-Repo auf der Platte haben?
>
> Du musst das ja nicht, du kannst dir auch nach wie vor nur das lokal
> hinlegen, was du haben willst.

Richtig.

>
> Es ist eben nur inzwischen die Voreinstellung, das so zu machen.
>
> Mal ganz ehrlich: Speicherplatz, insbesondere Plattenspeicher (bzw. das,
> was eine Festplatte ersetzt) ist mittlerweile so spottbillig, dass es
> kaum lohnt, darüber zu diskutieren. Wirklich Platz kosten in diesen
> Bauteilen am Ende eigentlich nur die 3D-Modelle, der Rest ist "Peanuts".

Richtig.

Wenn ich was suche, lade ich mir das komplette Repo, stöbere mal darin 
herum, nicht nur nach dem was ich suche, sondern was sonst noch darin 
ist, was es neues gibt, und was rausgeflogen ist.
Dann kopiere ich mir dass interessante in mein KiCad Arbeitsverzeichniss 
und lösche den ganzen Rest wieder. ;O)

Tatsächlich braucht man aber nur selten neues. Nach einiger Zeit hat man 
allen Standardkram beisammen, weiss das ddas Symbol und der Footprint so 
stimmt und funktioniert, und letzteres ist der Grund, warum man erstmal 
bei diesem Satz von Symbolen und Footprints bleibt. Nur neues wird 
hinzugefügt.

> Aber gerade die Integration von 3D-Darstellungen ist natürlich ein
> Feature, auf das wohl niemand mehr verzichten möchte, der damit bereits
> gearbeitet hat.

Gerade im Zusammenhang mit 3D-Druck, wenn man testen will, ob auch alles 
wie geplant ins Gehäuse passt, und darum auch ein Modell des Gehäuses 
hat.

Roland F. schrieb:

>> Meine Meinung: wesentlicher Punkt, der viele potenzielle Eagle-Umsteiger
>> abschreckt ist, dass bei Eagle extrem viele Bauteile bereits fertig als
>> Bibliothek vorliegen.
>
> Ein Grund mehr alles zu tun um es Um- und Einsteigern so leicht wie
> möglich zu machen neue Bauteil-Footprints zu erzeugen und zu verwalten.
> So wie es bisher funktioniert kann es meiner Meinung nach jedenfalls
> nicht bleiben.

Das ist leider nur ein halbes Argument, weil die offiziellen 
Bibliotheken auf eine übliche Fabrik Serienproduktion mit den dort 
üblichen Verfahren ausgelegt sind. Für Anfänger und Handverlötung wären 
aber spezielle Footprints sinnvoller. Gleiches gilt für einen 
Prototypen, wo man schon weiss, dass man die Endtransistoren zig mal 
erneuern muss, bis alles so klappt wie man es sich wünscht. Da hätte man 
oft gerne große robuste Pads und bei THT weite Bohrungen. Aber ein 
Anfänger kann überhaupt nicht wissen, dass er mit solchen Footprints 
auch besser fahren würde.

Mal abgesehen davon, dass das erstellen eines Symbols oder eines 
Footprints meist einfacher ist, als das Zeichnen eines Schaltplanes oder 
das routen eines Layouts. Ok, 3D Modelle können zeitaufwändiger werden. 
Aber "schwer" ist das auch nicht.

Ich habe mich in den riesigen Eagle Bibliotheken immer verlaufen, und 
war oft schneller, mir etwas neues zu machen als etwas zu finden. Das 
mag zwar bei großen vielpoligen Controllern anders sein, aber bei Klein- 
und Mittelkram eben auch nicht.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de

Hallo,

Bernd W. schrieb:
> ...weil die offiziellen  Bibliotheken auf eine übliche Fabrik
> Serienproduktion mit den dort üblichen Verfahren ausgelegt sind.

Ja, den Eindruck hatte ich auch schon.

> Für Anfänger und Handverlötung wären aber spezielle Footprints
> sinnvoller.

Das ist richtig, aber auch im üblichen Fabrikumfeld müssen sicherlich 
auch hier und da mal neue Footprints gezeichnet werden. Und dann ist die 
Vorgehensweise für die "Profis" genau so umständlich und undurchsichtig 
wie für Bastler wie mich.

rhf

P.S.:
Ich habe bei KiCad irgendwie den Eindruck als wenn die zu Grunde 
liegenden Datenstrukturen zur Beschreibung von Bauteilen in Eeschema und 
den Footprints in Pcbnew völlig im Vordergrund der Softwareentwicklung 
stehen. Die Art und Weise des Zugriff auf diese Datenstrukturen (also 
die Benutzerschnittstelle) scheint eher ein notwendiges "Übel" 
darzustellen und eher zweitrangig zu sein.
Meiner Meinung nach müsste es genau umgedreht sein: die 
Benutzerschnittstelle sollte absolute Priorität besitzen um eine 
intuitive Bedienung zu ermöglichen.

Hallo Roland.

Roland F. schrieb:

> Das ist richtig, aber auch im üblichen Fabrikumfeld müssen sicherlich
> auch hier und da mal neue Footprints gezeichnet werden. Und dann ist die
> Vorgehensweise für die "Profis" genau so umständlich und undurchsichtig
> wie für Bastler wie mich.

Das erstellen der Symbol- und Footprints ist ja auch einfach und 
unkompliziert.

Bemängelt wurde oben das Wegspeichern bzw. die Verwaltung der Librarys. 
Und die ist in der Tat komisch. Darum habe ich das ja meistens auch 
manuell und nicht über die Umgebungsvariablen gemacht.

Mit den Prettyformaten kannst Du Dein Lieblingsdateiverwaltungsprogramm 
auch zur Verwaltung der KiCad Bibliotheken verwenden. Bleibt das 
Eintragen der bibliotheken in die Bibliotheksliste übrig.....

Darum wundere ich mich ja über den ganzen Heckmeck, der damit getrieben 
wird....

> Die Art und Weise des Zugriff auf diese Datenstrukturen (also
> die Benutzerschnittstelle) scheint eher ein notwendiges "Übel"
> darzustellen und eher zweitrangig zu sein.


Was mich so 2009 dazu bewog, privat von Eagle nach KiCad zu wechseln, 
war unter anderem, dass mir persönlich die Bedienung insgesamt 
handlicher erschien. Und das ist bis heute so geblieben. Es gibt zwar 
Fälle, wo es umgedreht ist, aber das sind deutlich weniger.

> Meiner Meinung nach müsste es genau umgedreht sein: die
> Benutzerschnittstelle sollte absolute Priorität besitzen um eine
> intuitive Bedienung zu ermöglichen.

Es gibt letztlich bei soetwas komplexen wie einer Platinenentwicklung 
nichts wirklich "intuitives". Und dann ist Intuition auch noch etwas, 
was individuell sehr verschieden ist.
Darum ist es ja auch gut, dass es verschiedene Platinenlayoutsoftwaren 
gibt. Da kann sich jeder das aussuchen, was ihm am besten liegt.

Aber ich fände es nett, wenn sie alle ein gemeinsames Austauschformat 
hätten.....Das muss noch nicht einmals optimal sein. Es langt, wenn es 
offen und frei ist, im Klartext lesbar, und sich alle Informationen, 
auch Netzlisten oder dergleichen, daraus herausziehen liessen.


Mit freundlichem Gruß; Bernd Wiebus alias dl1eic
http:/www.dl0dg.de

Bernd W. schrieb:
> Das ist leider nur ein halbes Argument, weil die offiziellen
> Bibliotheken auf eine übliche Fabrik Serienproduktion mit den dort
> üblichen Verfahren ausgelegt sind. Für Anfänger und Handverlötung wären
> aber spezielle Footprints sinnvoller.

Bei SMD-Hühnerfutter gibt's jeweils auch noch ein Pendant des Footprints 
speziell für Handlötung. Habe noch nie eine Notwendigkeit dafür gesehen, 
und ich benutze Kicad ausschließlich für Dinge, die hinterher mit der 
Hand gelötet werden. (In der Firma benutzen wir Altium.)

Roland F. schrieb:
> Ich habe bei KiCad irgendwie den Eindruck als wenn die zu Grunde
> liegenden Datenstrukturen zur Beschreibung von Bauteilen in Eeschema und
> den Footprints in Pcbnew völlig im Vordergrund der Softwareentwicklung
> stehen. Die Art und Weise des Zugriff auf diese Datenstrukturen (also
> die Benutzerschnittstelle) scheint eher ein notwendiges "Übel"
> darzustellen und eher zweitrangig zu sein.

Du hattest wohl noch nicht viel mit der Linux-Community zu tun? Du 
kannst froh sein, dass es überhaupt ein GUI gibt und Du die Schaltpläne 
nicht per Kommandozeile erstellen musst.

Karl K. schrieb:
> Du hattest wohl noch nicht viel mit der Linux-Community zu tun?

Was genau trägt dein Beitrag eigentlich zum Thema des Threads bei?

Falls die Antwortet lautet: „nichts“, dann erspare dem Forum bitte in 
Zukunft derartige Beiträge. Sie sind problemlos verzichtbar.

Jörg W. schrieb:
> Bei SMD-Hühnerfutter gibt's jeweils auch noch ein Pendant des Footprints
> speziell für Handlötung. Habe noch nie eine Notwendigkeit dafür gesehen,
> und ich benutze Kicad ausschließlich für Dinge, die hinterher mit der
> Hand gelötet werden. (In der Firma benutzen wir Altium.)

Jörg W. schrieb:
> Was genau trägt dein Beitrag eigentlich zum Thema des Threads bei?

Bitte um Aufklärung.

Karl K. schrieb:

> Bitte um Aufklärung.

Wofür?  Was dein Beitrag mit dem Thread zu tun hatte?

Nichts, das ist offensichtlich. War nur FUD.

Was mein Beitrag mit dem Thread zu tun hatte?

Lies dir einfach die Kette an Beiträgen durch, auf die ich geantwortet 
habe, dann weißt du es.

Hallo Karl.

Karl K. schrieb:

> Du hattest wohl noch nicht viel mit der Linux-Community zu tun? Du
> kannst froh sein, dass es überhaupt ein GUI gibt und Du die Schaltpläne
> nicht per Kommandozeile erstellen musst.

Das wiederspricht meiner persönlichen Erfahrung. Ich verwende auf der 
Arbeit unter Windows 10 weitaus häufiger die Kommandozeile als privat 
unter Linux (Debian 9 "Stretch"). ;O)

Was allerdings unter Linux durchaus oft anzutreffen ist, sind hübsche 
komfortable Programme mit GUIs, die ein Komandozeilenprogramm bedienen. 
;O)

Die Kommandozeilenzeit ist seit dem letzten Jahrtausend auch bei Linux 
vorbei. Allerdings kannst Du, wenn es denn sein muss, viele Programme 
auch noch unter einer Kommandozeile laufen lassen.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de

Hallo Jörg.

Jörg W. schrieb:

> Bei SMD-Hühnerfutter gibt's jeweils auch noch ein Pendant des Footprints
> speziell für Handlötung. Habe noch nie eine Notwendigkeit dafür gesehen,
> und ich benutze Kicad ausschließlich für Dinge, die hinterher mit der
> Hand gelötet werden. (In der Firma benutzen wir Altium.)

Ich behaupte ja auch nicht, dass es nicht anders geht. Vor allem wenn 
man die nötige Feinmotorik hat. Falls nicht, oder falls man noch ungeübt 
ist, können die vergrößerten Pads schon eine Erleichterung sein. Finde 
zumindest ich persönlich so.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de

Hallo,

Bernd W. schrieb:
> Es gibt letztlich bei soetwas komplexen wie einer Platinenentwicklung
> nichts wirklich "intuitives".

Das sehe ich anders.

> Und dann ist Intuition auch noch etwas, was individuell sehr
> verschieden ist.

Da hast du sicherlich recht, aber es kann nicht schaden wenn sich 
Programme an bestimmte "Bedienabläufe" halten, die sich auch bei 
anderer, thematisch ähnlicher Software so wiederfindet.
Und, um beim Thema dieser Diskussion zu bleiben, der Umgang mit 
Umgebungsvariablen gehört meiner Meinung nach definitiv nicht dazu.

> Darum ist es ja auch gut, dass es verschiedene Platinenlayoutsoftwaren
> gibt. Da kann sich jeder das aussuchen, was ihm am besten liegt.

Ja, auch da stimme ich dir zu. Allerdings wird bei den geforderten 
Preise mancher Pakete die Luft für den Hobbyprogrammierer (und wie ich 
hier schon des Öfteren gelesen habe auch für Profis) die Luft recht 
dünn.

> Aber ich fände es nett, wenn sie alle ein gemeinsames Austauschformat
> hätten.....Das muss noch nicht einmals optimal sein. Es langt, wenn es
> offen und frei ist, im Klartext lesbar, und sich alle Informationen,
> auch Netzlisten oder dergleichen, daraus herausziehen liessen.

Das wäre schön, aber ich denke du bist Realist genug um zu wissen das 
eher der Weltfrieden ausbricht.

rhf

Hallo Roland.

Roland F. schrieb:

>> Und dann ist Intuition auch noch etwas, was individuell sehr
>> verschieden ist.
>
> Da hast du sicherlich recht, aber es kann nicht schaden wenn sich
> Programme an bestimmte "Bedienabläufe" halten, die sich auch bei
> anderer, thematisch ähnlicher Software so wiederfindet.
> Und, um beim Thema dieser Diskussion zu bleiben, der Umgang mit
> Umgebungsvariablen gehört meiner Meinung nach definitiv nicht dazu.

Naja. Ich finde die Verwendung von Umgebungsvariablen generell eher 
problematisch. Bei sehr komplexen Programmen sind sie sicher nötig.
Aber KiCad gehört da definitiv noch nicht zu. Das liesse sich auch noch 
direkt machen. Der Verlust an Komfort würde durch den Gewinn an 
Transparenz ausgeglichen. Immerhin zeigt Dir KiCad ja noch die Pfade 
direkt, so dass man ohne lange Sucherei auch noch direkt auf alles 
zugreifen kann. Da habe ich bei anderen Programmen schon geflucht.

>> Darum ist es ja auch gut, dass es verschiedene Platinenlayoutsoftwaren
>> gibt. Da kann sich jeder das aussuchen, was ihm am besten liegt.
>
> Ja, auch da stimme ich dir zu. Allerdings wird bei den geforderten
> Preise mancher Pakete die Luft für den Hobbyprogrammierer (und wie ich
> hier schon des Öfteren gelesen habe auch für Profis) die Luft recht
> dünn.

Das ist in der Tat war. So manches Unternehmen, das einen imposanten 
Webauftritt hat, ist bei näherer Betrachtung jemand, der das alleine im 
Nebenerwerb macht. Da kann es durchaus oft eng werden.

Keine Ahnung, ob bei Pfändungen Softwarelizenzen z.B. auch gepfändet 
werden (können). Da wäre man bei der Verwendung von GNU Software auch 
auf der sicheren Seite, wenn nicht Festplatte und Rechner auch weg sind. 
Daten kann man natürlich auch auf einem Stick sichern, welcher sich dann 
im privaten Besitz einer von der Pfändung nicht betroffenen Person 
befindet.


Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de

Roland F. schrieb:
> Und, um beim Thema dieser Diskussion zu bleiben, der Umgang mit
> Umgebungsvariablen gehört meiner Meinung nach definitiv nicht dazu.

Wie wir allerdings schon geklärt hatten, sind diese völlig optional. Man 
kann Kicad nutzen, ohne sich um diese Variablen in irgendeiner Form 
kümmern zu müssen. Sie dienen lediglich der potenziellen Verwaltung 
mehrerer paralleler Setups/Konfigurationen – etwas, was viele andere 
vergleichbare Systeme gar nicht erst beherrschen. Insofern hinkt dein 
Vergleich ziemlich stark.

Die angesprochenen Defizite der intuitiven Bedienung haben mit den 
Umgebungsvariablen absolut nichts zu tun.

Hallo Jörg,

> Sie dienen lediglich der potenziellen Verwaltung mehrerer paralleler
> Setups/Konfigurationen – etwas, was viele andere vergleichbare Systeme
> gar nicht erst beherrschen. Insofern hinkt dein Vergleich ziemlich stark.
>
> Die angesprochenen Defizite der intuitiven Bedienung haben mit den
> Umgebungsvariablen absolut nichts zu tun.

Da bin ich anderer Meinung: ich habe mir gerade nochmal den ersten 
Beitrag von Alex durchgelesen. Er ist auf das Thema "Umgebungsvariablen" 
gestoßen weil er versuchte eine eigene Footprintbibliothek für den 
Layouteditor sichtbar zu machen. Es ging dabei nicht die Verwaltung 
unterschiedlicher Setups oder Konfigurationen. Man kommt also recht früh 
mit Thematik in Berührung. Ich stand vor dem gleichen Problem und habe 
auch einige Zeit gebraucht um (zumindest in Ansatz) zu verstehen wie das 
funktioniert. Und intuitiv fand ich das nicht gerade.

rhf

Roland F. schrieb:

> Da bin ich anderer Meinung: ich habe mir gerade nochmal den ersten
> Beitrag von Alex durchgelesen. Er ist auf das Thema "Umgebungsvariablen"
> gestoßen weil er versuchte eine eigene Footprintbibliothek für den
> Layouteditor sichtbar zu machen.

Das ging dabei aber auch immer ohne die Umgebungsveriablen überhaupt zu 
benutzen.

Holms 6. Version möglicherweise ausgenommen. Die kenne ich nicht.

Möglicherweise ist der Kernpunkt der Unintuivität, dass Er/Du unbedarft 
hingest, und versuchst die Umgebungsvariablen zu benutzen, obwohl das 
nicht nötig ist.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de

Roland F. schrieb:
> Da bin ich anderer Meinung: ich habe mir gerade nochmal den ersten
> Beitrag von Alex durchgelesen. Er ist auf das Thema "Umgebungsvariablen"
> gestoßen weil er versuchte eine eigene Footprintbibliothek für den
> Layouteditor sichtbar zu machen.

Ich habe mir die Digikey-Footprints runtergeladen, an einem Ort meiner 
Wahl abgelegt, und kann diese im "Layouteditor sichtbar" und auswählbar 
"machen". Ich habe die "Umgebungsvariablen" nicht angefasst.
Ich glaube, so war das gemeint.

Wie ich das genau gemacht habe, müsste ich neu herausfinden, da gilt 
dann wiederum

Jörg W. schrieb:
> Die angesprochenen Defizite der intuitiven Bedienung haben mit den
> Umgebungsvariablen absolut nichts zu tun.

:)

Roland F. schrieb:
> Er ist auf das Thema "Umgebungsvariablen" gestoßen weil er versuchte
> eine eigene Footprintbibliothek für den Layouteditor sichtbar zu machen.

War er, allerdings ist die Annahme falsch, dass man an diesen irgendwas 
ändern müsste. Man muss an der Stelle, wo auch die Umgebungsvariablen 
zu sehen sind, nur den Tab "Project specific libraries" öffnen und die 
Bibliothek(en) dort hinzufügen. Zuvor muss man die Bibliothek(en) nur 
eben erstmal angelegt haben. (Edit: der TE hatte sich welche 
runtergeladen, insofern hatte er diese Klippe nicht.)

Dass der gesamte Prozess wenig intuitiv ist, steht außer Zweifel.

Außerdem wäre es vielleicht sinnvoll, diese Umgebungsvariablen irgendwie 
unter "Advanced" zu verstecken, damit sie nicht so verwirren. Auch 
sollte man sie vielleicht als "Konfigurationsvariablen" bezeichnen, und 
nur irgendwo in der Doku dann erwähnen, dass diese von 
Umgebungsvariablen importiert werden (können).