Chaos mit mehreren EAGLE Instanzen

Heiko Schedletzky schrieb:

Für jede Platine gibt es ein eigenes Verzeichnis mit eigener

Projektdatei (*.epf).

 

Wenn nun zur Zeitersparnis die benötigte .sch oder .brd Datei über den

Explorer geöffnet wird, vermerkt EAGLE deren Pfad im zuletzt aktivierten

Projekt.

bei mir nicht, obwohl die Dateien alle in der eaglerc.usr stehen.

Die epf liegen hier in beliebigen Verzeichnissen, die in Eagle nicht

konfiguriert sind.

Ich starte Eagle mit einer Verknüpfung auf *.epf bzw. eine

vorgeschaltete CMD-Datei zur automatischen Auswahl der passenden

Eagle-Version (ich will kein Eagle 3 Projekt mit Eagle 5 öffnen). Die

Datei habe ich hier schon gelegentlich gepostet.

Eagle erhält beim Start einen Pfad zur eagle.epf.

In Eagle ist das EPF-Verzeichnis deshalb auf "." konfiguriert

(Directories.Epf = "."). Damit erspar(t)e ich mir auch, daß Eagle beim

Start lange irgendwelche Dateibäume durchsucht.

Ich mag das "Control Panel" nicht zur Auswahl eines Projektes

verwenden. Dafür gibt es bessere Dateimanager.

.sch und .brd öffne ich mit Links zu den verschiedenen Adler-Versionen

im Sendto-Verzeichnis.

Das heißt: Wenn im EAGLE ein Projekt aktiviert wird (grüner Ball im

Control Panel) werden u.U. Dateien eines anderen Projekts geöffnet.

Somit muss dann manuell die richtige Datei geladen werden, was bei 4-5

parallelen Instanzen erheblich Zeit kostet.

 

Das Verhalten ist reproduzierbar.

Welche Möglichkeiten gibt es dieses Problem zu vermeiden?

"Eagle Control Panel nicht zur Auswahl des Projektes verwenden" wäre

ein Versuch.

In diesem Zusammenhang:

Wenn man eine .sch oder .brd Datei über den Explorer öffnet, erhält man

ja eine Warnung "Wollen Sie auch ... öffnen?

Diese Frage erhalte ich nicht, wenn ich Eagle beim Start den Namen

eines .sch oder .brd übergebe - da wird das Pärchen kommentarlos

geöffnet.

Soweit ich sehe, fragt Eagle nur dann, wenn eine andere Datei schon

geöffnet ist, also "edit foo.brd" wenn "bar.sch" schon geöffnet ist.

Das ist bei Start über den Explorer aber kaum möglich, oder?

Servus

Oliver

Oliver Betz schrieb:

Heiko Schedletzky schrieb:

 

Für jede Platine gibt es ein eigenes Verzeichnis mit eigener

Projektdatei (*.epf).

 

Wenn nun zur Zeitersparnis die benötigte .sch oder .brd Datei über den

Explorer geöffnet wird, vermerkt EAGLE deren Pfad im zuletzt aktivierten

Projekt.

 

bei mir nicht, obwohl die Dateien alle in der eaglerc.usr stehen.

 

Die epf liegen hier in beliebigen Verzeichnissen, die in Eagle nicht

konfiguriert sind.

 

Ich starte Eagle mit einer Verknüpfung auf *.epf bzw. eine

vorgeschaltete CMD-Datei zur automatischen Auswahl der passenden

Eagle-Version (ich will kein Eagle 3 Projekt mit Eagle 5 öffnen). Die

Datei habe ich hier schon gelegentlich gepostet.

 

Eagle erhält beim Start einen Pfad zur eagle.epf.

 

In Eagle ist das EPF-Verzeichnis deshalb auf "." konfiguriert

(Directories.Epf = "."). Damit erspar(t)e ich mir auch, daß Eagle beim

Start lange irgendwelche Dateibäume durchsucht.

 

Ich mag das "Control Panel" nicht zur Auswahl eines Projektes

verwenden. Dafür gibt es bessere Dateimanager.

 

.sch und .brd öffne ich mit Links zu den verschiedenen Adler-Versionen

im Sendto-Verzeichnis.

 

Das heißt: Wenn im EAGLE ein Projekt aktiviert wird (grüner Ball im

Control Panel) werden u.U. Dateien eines anderen Projekts geöffnet.

Somit muss dann manuell die richtige Datei geladen werden, was bei 4-5

parallelen Instanzen erheblich Zeit kostet.

 

Das Verhalten ist reproduzierbar.

Welche Möglichkeiten gibt es dieses Problem zu vermeiden?

 

"Eagle Control Panel nicht zur Auswahl des Projektes verwenden" wäre

ein Versuch.

 

In diesem Zusammenhang:

Wenn man eine .sch oder .brd Datei über den Explorer öffnet, erhält man

ja eine Warnung "Wollen Sie auch ... öffnen?

 

Diese Frage erhalte ich nicht, wenn ich Eagle beim Start den Namen

eines .sch oder .brd übergebe - da wird das Pärchen kommentarlos

geöffnet.

 

Soweit ich sehe, fragt Eagle nur dann, wenn eine andere Datei schon

geöffnet ist, also "edit foo.brd" wenn "bar.sch" schon geöffnet ist.

Das ist bei Start über den Explorer aber kaum möglich, oder?

 

Servus

 

Oliver

Hallo Oliver,

danke für die Tipps.

Das sind aber eher Workarounds für daheim mit ein paar kleinen Projekten.

Für bei uns mittlerweile mehrere hundert Projekte (ohne Revisionen) im

Professionellen Bereich ist das leider keine akzeptable Lösung.

Gruss Heiko

Hallo Heiko,

Das sind aber eher Workarounds für daheim mit ein paar kleinen Projekten.

Für ein paar kleine Projekte zuhause hätte ich mir die Arbeit nicht

gemacht.

Für bei uns mittlerweile mehrere hundert Projekte (ohne Revisionen) im

Professionellen Bereich ist das leider keine akzeptable Lösung.

Und was genau findest Du an der von mir aufgezeigten Lösung

unakzeptabel?

Und wie arbeitest Du "professioneller" mit Eagle?

Vielleicht kann ich ja noch etwas lernen - auch wenn nach den vielen

Jahren nicht mehr viel Potential vorhanden ist (wie man das jetzt auch

immer auslegen mag ).

Servus

Oliver

Hallo Oliver,

die von dir genannte Lösung ist natürlich nicht falsch. Löst aber nicht

unser Problem.

> Ich mag das "Control Panel" nicht zur Auswahl eines Projektes

> verwenden. Dafür gibt es bessere Dateimanager.

1. Seit es in Eagle möglich ist, werden in unserem Unternehmen Zweck und

    Funktionsdetails zum Projekt abgelegt (Also Beschreibung in Package,

    Device, Projekt). Das Control Panel ist sicher nicht die perfekte

    Lösung aber es erfüllt den Zweck. Mir fällt kein

    Dateimanager ein, der EAGLE Projektbeschreibungen direkt darstellt.

    Ohne das Control Panel müsste man eine Parallelwelt schaffen, die

    nix anderes machen würde wie das Control Panel selbst.

    Die Frage ist wozu? Mal abgesehen von der kürzeren Ladezeit.

2. In unserer Stücklistenverwaltung gibt es eine Referenz auf die

    entsprechende brd Datei. Das Layout kann also direkt geöffnet werden.

> Ich starte Eagle mit einer Verknüpfung auf *.epf bzw. eine

> vorgeschaltete CMD-Datei zur automatischen Auswahl der passenden

> Eagle-Version (ich will kein Eagle 3 Projekt mit Eagle 5 öffnen). Die

> Datei habe ich hier schon gelegentlich gepostet.

> Eagle erhält beim Start einen Pfad zur eagle.epf.

Ist eine Möglichkeit. Aber wer öffnet - im Fertigungsprozess - eine

.epf Datei, wenn er z.B. einen Fehler im Board sucht.

Es wird in nahezu 100% der Fälle die brd Datei der entsprechenden

Revision über den Explorer / die Stückliste geöffnet.

Ich will deine Lösung KEINESFALLS kritisieren oder abwerten.

Ich unterstelle mal, du bist der einzige, der mit deinen Projekten

arbeitet.

Bei uns greifen derzeit über 25 Mitarbeiter täglich auf unsere

Projekte zu. Diese wissen oft nicht hinter welcher Projektnummer welches

Projekt steckt. Die Funktionsbeschreibung im Control Panel hilft beim

Finden des gesuchten Projekts mehr als eine epf Datei im Verzeichnis.

Das ursprünglich von mir geschilderte Verhalten bezieht sich aber nicht

auf die Vor- und Nachteile des Projektverwaltungskonzepts von Eagle.

Vielmehr soll von mir auf das Chaos hingewiesen werden, was seit

längerem beim Arbeiten mit Eagle entsteht.

Ich hatte es in der ersten Mail schon mal versucht zu beschreiben

Aber hier nochmal etwas genauer:

Eagle öffnet beim Start automatisch das zuletzt aktive Projekt.

Das ist soweit ja gar nicht verkehrt, solange man sequentiell ein

Projekt nach dem anderen realisiert.

Nun haben wir im speziellen aber das Problem, dass zeitgleich 2-4

Projekte parallel zu entwickeln sind.

Öffnet man Eagle aus dem Startmenü ist alles Ok (brd und sch an den

letzen Positionen, wunderbar!)

Öffnet man z.B. eine brd Datei über den Explorer wird trotzdem zuerst

das zuletzt aktive Projekt geladen. Danach wird die brd Datei geladen.

Eagle stellt fest, dass die geladene brd Datei nicht zur schon offenen

sch Datei passt und fragt. Wollen Sie auch blabla.sch öffnen?

Ich antworte mit ja und hab was ich eigentlich will.

Schließt man jetzt Eagle werden die zuletzt geöffneten Dateien dem

aktiven Projekt zugeordnet. Das ist das Problem. Wenn an einem anderen

Arbeitsplatz das erwähnte Projekt aktiviert wird, werden u.U

projektfremde Dateien geladen! => Es müssen die richtigen Dateien

manuell geladen werden.

Ich kann mir fast nicht vorstellen, das wir die einzigen sind, die

dieses Problem haben. Zumal wir Projektmäßig Eagle im von CadSoft

geplanten Sinn verwenden. Das Verhalten ist definitiv reproduzierbar

Meine Frage an CadSoft: Wäre es nicht zweckdienlich, das letzte aktive

Projekt beim Start nur dann zu aktivieren, wenn nichts per

Startparameter übergeben wird?

Gruss Heiko

Eagle 5.6pro @ WinXP SP3

Heiko Schedletzky schrieb:

Wäre es nicht zweckdienlich, das letzte aktive

Projekt beim Start nur dann zu aktivieren, wenn nichts per

Startparameter übergeben wird?

Ja, bitte! Durch meine Haende gehen die Platinen ALLER Mitarbeiter

unseres Instituts, die ich u.a. zur Fertigung aufbereite (die Platinen,

nicht die Mitarbeiter). Da der Aufruf von EAGLE mit einer solchen

Platine als Startparameter dazu fuehrt, dass diese "Fremd"-Platine

automatisch MEINEM zuletzt geoeffneten Projekt zugeordnet wuerde, habe

ich die gesamte Projektverwaltung schon vor Jahren komplett aufgegeben.

Das aktuelle Verhalten von EAGLE bei der Verwendung von Projektdateien

ist fuer unsere Zwecke reichlich kontraproduktiv...

Andreas Weidner

Heiko Schedletzky schrieb:

Hallo Oliver,

 

die von dir genannte Lösung ist natürlich nicht falsch. Löst aber nicht

unser Problem.

 

Ich mag das "Control Panel" nicht zur Auswahl eines Projektes

verwenden. Dafür gibt es bessere Dateimanager.

 

1. Seit es in Eagle möglich ist, werden in unserem Unternehmen Zweck und

   Funktionsdetails zum Projekt abgelegt (Also Beschreibung in Package,

   Device, Projekt). Das Control Panel ist sicher nicht die perfekte

   Lösung aber es erfüllt den Zweck. Mir fällt kein

   Dateimanager ein, der EAGLE Projektbeschreibungen direkt darstellt.

   Ohne das Control Panel müsste man eine Parallelwelt schaffen, die

   nix anderes machen würde wie das Control Panel selbst.

   Die Frage ist wozu? Mal abgesehen von der kürzeren Ladezeit.

naja, i.d.R. besteht ein "Projekt" aus weit mehr als einer

Leiterplatte mit Schaltplan. Selbst ohne Microcontroller gibt es da

verschiedenste Arten von Dokumentation (entwicklungsbegleitend,

Fertigung, Kunde...), Simulationen etc. Meistens git es noch einen

Softwarezweig. Das alles kann das Eagle Control Panel ohnehin nicht

verarbeiten, und ich will auch nicht den siebzehnten Dateimanager von

Cadsoft bekommen.

Aber das mag auf beginnenden Altersstarrsinn zurückzuführen sein.

2. In unserer Stücklistenverwaltung gibt es eine Referenz auf die

   entsprechende brd Datei. Das Layout kann also direkt geöffnet werden.

(Eagle  immer über epf öffnen)

Ist eine Möglichkeit. Aber wer öffnet - im Fertigungsprozess - eine

.epf Datei, wenn er z.B. einen Fehler im Board sucht.

Es wird in nahezu 100% der Fälle die brd Datei der entsprechenden

Revision über den Explorer / die Stückliste geöffnet.

Aha, Eagle als Viewer. Dazu hilft seit Version 5 der

Komandozeilenschalter -C.

Abgesehen davon: "Mitarbeiter im Fertigungsprozess" sollten keinen

Zugriff auf die Quellen haben.

Ich will deine Lösung KEINESFALLS kritisieren oder abwerten.

Ich unterstelle mal, du bist der einzige, der mit deinen Projekten

arbeitet.

Falsch unterstellt.

Bei uns greifen derzeit über 25 Mitarbeiter täglich auf unsere

Projekte zu. Diese wissen oft nicht hinter welcher Projektnummer welches

Projekt steckt. Die Funktionsbeschreibung im Control Panel hilft beim

Finden des gesuchten Projekts mehr als eine epf Datei im Verzeichnis.

Das ist m.E. ein Organisationsproblem. "Mitarbeiter im

Fertigungsprozess" erhalten kontrollierte Kopien (z.B. aus einem

Revisionskontrollsystem). Den Weg zu diesen Kopien vom Eagle Control

Panel abhängig zu machen, würde ich nicht verantworten wollen.

Erhalten die Produktionsleute denn die anderen Dokumente, die sie zur

Arbeit brauchen, auch aus dem Control Panel?

Irgendwie verstehe ich nicht so ganz. Einerseits wird "in nahezu 100%

der Fälle die brd Datei der entsprechenden Revision über den Explorer

/ die Stückliste geöffnet.", andererseits sieht der Anwender die

"Funktionsbeschreibung im Control Panel".

Das ursprünglich von mir geschilderte Verhalten bezieht sich aber nicht

auf die Vor- und Nachteile des Projektverwaltungskonzepts von Eagle.

 

Vielmehr soll von mir auf das Chaos hingewiesen werden, was seit

längerem beim Arbeiten mit Eagle entsteht.

 

Ich hatte es in der ersten Mail schon mal versucht zu beschreiben

Aber hier nochmal etwas genauer:

 

Eagle öffnet beim Start automatisch das zuletzt aktive Projekt.

Das ist soweit ja gar nicht verkehrt, solange man sequentiell ein

doch, ich (und nicht nur ich!) halte das für grundsätzlich verkehrt.

Es gab zu dem Thema schon viele Diskussionen, die letztlich auch zum

Schalter "-C" geführt haben.

Keine ideale Lösung, aber ein kleiner Fortschritt.

Projekt nach dem anderen realisiert.

Das wird in der Praxis ja nur selten passieren.

Nun haben wir im speziellen aber das Problem, dass zeitgleich 2-4

Projekte parallel zu entwickeln sind.

 

Öffnet man Eagle aus dem Startmenü ist alles Ok (brd und sch an den

letzen Positionen, wunderbar!)

Öffnet man z.B. eine brd Datei über den Explorer wird trotzdem zuerst

das zuletzt aktive Projekt geladen. Danach wird die brd Datei geladen.

darüber ärgerten sich schon viele Anwender.

Eagle stellt fest, dass die geladene brd Datei nicht zur schon offenen

sch Datei passt und fragt. Wollen Sie auch blabla.sch öffnen?

Ich antworte mit ja und hab was ich eigentlich will.

 

Schließt man jetzt Eagle werden die zuletzt geöffneten Dateien dem

aktiven Projekt zugeordnet. Das ist das Problem. Wenn an einem anderen

Arbeitsplatz das erwähnte Projekt aktiviert wird, werden u.U

projektfremde Dateien geladen! => Es müssen die richtigen Dateien

manuell geladen werden.

Deshalb macht man das ja nicht.

Den ganzen Krampf mit "anderer Arbeitsplatz" kann man außerdem

umgehen, wenn man die Eagle-Projekte nicht direkt öffnet, sondern nur

Arbeitskopien, die man aus einer Projektverwaltung bezieht.

Es gibt ja noch andere Probleme beim Zugriff von verschiedenen

Arbeitsplätzen aus, z.B. die Bildschirmauflösung.

Und ich würde niemals 25 Leute ohne Kontrolle auf die Eagle-Projekte

zugreifen lassen (schauder).

Ich kann mir fast nicht vorstellen, das wir die einzigen sind, die

Nein. Es gab darüber auch schon Diskussionen, liegen alle noch auf dem

Cadsoft-Newsserver.

dieses Problem haben. Zumal wir Projektmäßig Eagle im von CadSoft

geplanten Sinn verwenden. Das Verhalten ist definitiv reproduzierbar

M.E. ist "die von Cadsoft geplante Methode" nicht praxisgerecht für

den realen Betrieb. Und mit der Ansicht bin ich nicht alleine.

Meine Frage an CadSoft: Wäre es nicht zweckdienlich, das letzte aktive

Projekt beim Start nur dann zu aktivieren, wenn nichts per

Startparameter übergeben wird?

Ich denke, daß es nicht mal dann sinnvoll wäre.

Servus

Oliver

Die Eagle-Projektverwaltung ist hier ja immer wieder ein heißes Thema

und auch ich bin nicht recht glücklich damit.  Mein Eindruck ist,  dass

die Entwickler hier etwas zu betriebsblind / Eagle-zentriert gedacht

haben.

Tatsache ist aber,  dass für uns in der gewerblichen Praxis Eagle nur

ein Werkzeug unter vielen ist und sich in den gesamten Arbeitsfluss und

die übliche EDV-Praxis einpassen sollte.  Zudem wird Eagle nicht nur vom

eingefuchsten Entwickler genutzt,  sondern auch (eher als Viewer) von

"Laien"-Kollegen in der Fertigung oder Reparatur.  Und üblich ist nun

mal,  Dokumente aller Art aus irgend einem Dateimanager über ihre

Verknüpfung oder über anderweitige Hyperlinks zu öffnen.

Über den Projektmanager kann man geteilter Meinung sein,  aber ein

Grundproblem bei Eagle ist ja,  dass ein Projekt (wenigstens) zwei

Dokumente umfasst (SCH und BRD),  die aus durchaus guten Gründen

getrennte Dateien sind,  aber sehr eng zusammen gehören.  Also ist eine

Projektdatei EPF zur Organisation prinzipiell sehr nützlich

(Programmierer sind ja zB auch Projekte mit etlichen Dateien und

Makefiles gewöhnt).  Man sollte generell vermeiden,  SCH/BRD direkt zu

öffnen.

Dabei fehlt eigentlich IMHO gar nicht viel für einen praktischeren

Umgang.  Mein Vorschlag:

1. Eagle.exe soll wie alle üblichen Programme Startparameter erkennen:

    Mit Pfad\Name.epf natürlich das angegebene EPF und die darin

referenzierten anderen Dateien öffnen.

    Mit -view die Dateien schreibgeschützt nur zum Betrachten öffnen.

Eine Schaltfläche soll diesen Modus umschalten können (analog zB zu

Datei Bearbeiten in OpenOffice).

    Mit Pfad\Name.sch bzw. .brd nur diese angegebene Datei öffnen und

eine Warnung ausgeben,  dass der zugehörige Zwilling nicht geöffnet ist.

  Vielleicht dann per Default im View-Modus.

    Ganz ohne Startparameter nichts öffnen oder (einstellbar) eine

Default.EPF .

    Vor dem Schließen fragen,  ob die EPF gespeichert werden soll.

2.  Für EPFs sollen beliebige Namen und Pfade zulässig sein.  (Für

sprechende Bezeichnungen oder firmenspezifische Konventionen,  und damit

auch mehrere im selben Verzeichnis sein können.  Es gibt ja auch nicht

nur "Word.doc"!)  Das ist eine sehr wichtige Änderung,  der jetzige Usus

verwirrt jeden Neuen.  Das les- und editierbare Textformat des EPF

beibehalten!

Auch die EPF-Endung soll variabel zulässig sein,  zB *.epf414 oder

*.epf516 -- damit könnte man zu verschiedenen Versionen verknüpfen.

(Wobei ich ehrlich gesagt nicht ganz einsehe,  warum man alte

Programmversionen haben wollte -- nur zum Betrachten geht auch die neue,

  und bei Änderungen scheint mir unbedingt sinnvoller,  gleich auf

aktuellen Stand aufzusteigen.  Außer wenn man als Dienstleister für

konservative Kunden arbeitet.)

3.  Für SCH und BRD sollen auch beliebige und unterschiedliche Namen und

Pfade zulässig sein.  Ihre Verknüpfung erfolgt nur noch im EPF.  Die

Verknüpfungspfade sollen absolut und relativ und auch übers Netz möglich

sein.

4. Der View-Modus sollte auch im EPF für die dort referenzierten Dateien

notiert sein und auch fürs EPF selber möglich sein.

5. Im EPF sollen die sichtbaren Layer notiert sein (vorrangig vor denen

im SCH / BRD).

6. Im EPF soll die Eagle-Version für die referenzierten Dateien notiert

sein.  Wird mit einer neueren gearbeitet,  dann warnen und die Dateien

zunächst im View-Modus öffnen.

7. Eagle soll mehrere Projekte parallel öffnen können,  um zB

verschiedene Versionen vergleichen zu können oder für Copy/Paste.  So

dass beim wiederholten Aufruf von Dokumenten alle in verschiedenenen

Fenstern der einen laufenden Instanz geöffnet werden.  (Könnte evtl.

auch wie jetzt mit mehreren Instanzen gehen,  wenn sie sich den

Paste-Puffer teilen)

8. Der Eagle-Projektmanager sollte sich etwas mehr an den gewohnten

Explorer anlehnen.  Der Projektpfad soll nur ein anfängliches

Arbeitsverzeichnis sein,  man soll auch daraus hochsteigen können.  Der

Hauptnutzen gegenüber anderern Explorern liegt in der zusätzlich

angezeigten Description -- die sollte aber in die EPF hinein verlegt

werden;  und im Stöbern in den Bibliotheken / Design Rules.

   Das Verzeichnis erst auf Klick auf '+' aufklappen,  nicht schon beim

Öffnen der EPF.

   Beim Öffnen eine EPF hier zum fraglichen Verzeichnis gehen,  aber

noch nicht aufklappen.

9. Im Zusammenhang mit dem View-Modus könnte ein Passwort zur

Dokumentbearbeitung nützlich sein.

Damit wäre der Zugang zu Eagle-Daten bevorzugt über EPFs gesteuert.  Wir

Entwickler könnten für uns für unsere Projekte eine Sammlung von EPFs

nach eigenem Geschmack anlegen und anderseits bequem für unsere Kollegen

spezifische EPFs erzeugen,  zB Dimmer_Schaltplan.epf und

Dimmer_Bestueckung.epf und Dimmer_Layout.pdf,  die jeweils im View-Modus

die fraglichen Sichten öffnen und auf die in Stücklisten / Datenbanken

etc. einfach verlinkt wird.  (Jetzt erzeuge ich für solche Doku-Zwecke

noch mühsam PDFs,  auf die ich verlinke und muss auf deren

Aktualisierung selber achten.)

Wie steht die Gemeinschaft zu diesem Vorschlag?

--

Liebe Grüße,  Hans Lederer

Oliver Betz schrieb:

Abgesehen davon: "Mitarbeiter im Fertigungsprozess" sollten keinen

Zugriff auf die Quellen haben.

 

 

Das ist m.E. ein Organisationsproblem. "Mitarbeiter im

Fertigungsprozess" erhalten kontrollierte Kopien (z.B. aus einem

Revisionskontrollsystem). Den Weg zu diesen Kopien vom Eagle Control

Panel abhängig zu machen, würde ich nicht verantworten wollen.

 

 

Und ich würde niemals 25 Leute ohne Kontrolle auf die Eagle-Projekte

zugreifen lassen (schauder).

 

Hmmm...  Schon richtig,  aber noch lang nicht jeder kleinere Betrieb hat

eine universelle Versionsverwaltung / Revisionskontrollsystem.

Geregelte Dateizugriffsrechte schon eher.  Mit lediglich Leserechten

oder einem Bearbeitungs-Passwort scheint mir das schon akzeptabel und

der kleinere Overhead.

Es gibt ja noch andere Probleme beim Zugriff von verschiedenen

Arbeitsplätzen aus, z.B. die Bildschirmauflösung.

Oh ja.  Eagle sollte beim Öffnen die im EPF notierten Fenstergrößen auf

die aktuellen Bildschirmgrenzen limitieren.

Grüße,  Hans Lederer

Oliver Betz schrieb:

Aha, Eagle als Viewer. Dazu hilft seit Version 5 der

Komandozeilenschalter -C.

danke, das werde ich mal probieren.

Gruss Heiko

Hans Lederer schrieb:

Die Eagle-Projektverwaltung ist hier ja immer wieder ein heißes Thema

und auch ich bin nicht recht glücklich damit.  Mein Eindruck ist,  dass

die Entwickler hier etwas zu betriebsblind / Eagle-zentriert gedacht

haben.

Mittlerweile ist Cadsoft ja in der Hinsicht etwas offener als früher.

Tatsache ist aber,  dass für uns in der gewerblichen Praxis Eagle nur

ein Werkzeug unter vielen ist und sich in den gesamten Arbeitsfluss und

das ist z.B. schon mal ein wesentlicher Punkt, dem das Control Panel

bzw. die Vorgabe von Eagle nicht gerecht wird.

die übliche EDV-Praxis einpassen sollte.  Zudem wird Eagle nicht nur vom

eingefuchsten Entwickler genutzt,  sondern auch (eher als Viewer) von

"Laien"-Kollegen in der Fertigung oder Reparatur.  Und üblich ist nun

statt "eher" gilt bei uns "nur".

mal,  Dokumente aller Art aus irgend einem Dateimanager über ihre

Verknüpfung oder über anderweitige Hyperlinks zu öffnen.

 

Über den Projektmanager kann man geteilter Meinung sein,  aber ein

Grundproblem bei Eagle ist ja,  dass ein Projekt (wenigstens) zwei

Dokumente umfasst (SCH und BRD),  die aus durchaus guten Gründen

getrennte Dateien sind,  aber sehr eng zusammen gehören.  Also ist eine

Projektdatei EPF zur Organisation prinzipiell sehr nützlich

(Programmierer sind ja zB auch Projekte mit etlichen Dateien und

Makefiles gewöhnt).  Man sollte generell vermeiden,  SCH/BRD direkt zu

öffnen.

Mit Eagle 5 und -C geht das notfalls.

Dabei fehlt eigentlich IMHO gar nicht viel für einen praktischeren

Umgang.  Mein Vorschlag:

 

 

1. Eagle.exe soll wie alle üblichen Programme Startparameter erkennen:

 

   Mit Pfad\Name.epf natürlich das angegebene EPF und die darin

referenzierten anderen Dateien öffnen.

das geht jetzt schon - es ist halt kein abweichender Name für das epf

möglich.

   Mit -view die Dateien schreibgeschützt nur zum Betrachten öffnen.

ja.

Eine Schaltfläche soll diesen Modus umschalten können (analog zB zu

Datei Bearbeiten in OpenOffice).

 

   Mit Pfad\Name.sch bzw. .brd nur diese angegebene Datei öffnen und

jetzt wird halt der Partner automatisch geöffnet. Finde ich nicht

weiter schlimm.

eine Warnung ausgeben,  dass der zugehörige Zwilling nicht geöffnet ist.

Vielleicht dann per Default im View-Modus.

 

   Ganz ohne Startparameter nichts öffnen oder (einstellbar) eine

Default.EPF .

Genau. Kein Parameter, nichts offen. Geht auch schon halbwegs.

   Vor dem Schließen fragen,  ob die EPF gespeichert werden soll.

Das ist jetzt so eine Sache. Während der normalen Arbeit möchte ich

schon die letzten Einstellungen gespeichert haben. Auf Wunsch auch

automatisch. Aber wenn ich eine Datei nur angeschaut habe, ist das

eher selten der Fall.

Also: Wenn an sch/brd/lbr etwas geändert wurde, kann das epf

gespeichert werden, wenn ein entsprechender Schalter gesetzt ist.

Sonst sollte Eagle davon ausgehen, daß der Anwender nur einen Blick

ins Projekt werfen wollte und nichts verändern.

2.  Für EPFs sollen beliebige Namen und Pfade zulässig sein.  (Für

Das habe ich ja schon x-mal geschrieben, seit Jahren (seit ich Eagle 4

benutze). Hier verstehe ich nicht ganz, was Cadsoft dagegen

einzuwenden hat.

sprechende Bezeichnungen oder firmenspezifische Konventionen,  und damit

auch mehrere im selben Verzeichnis sein können.  Es gibt ja auch nicht

nur "Word.doc"!)  Das ist eine sehr wichtige Änderung,  der jetzige Usus

verwirrt jeden Neuen.  Das les- und editierbare Textformat des EPF

beibehalten!

 

Auch die EPF-Endung soll variabel zulässig sein,  zB *.epf414 oder

Dann wird es aber mit den Dateiverknüpfungen unter Windows schwierig.

*.epf516 -- damit könnte man zu verschiedenen Versionen verknüpfen.

Die Version steht schon im epf. Das nutze ich ja in der Windows

CMD-Datei, mit der ich den passenden Eagle starte.

(Wobei ich ehrlich gesagt nicht ganz einsehe,  warum man alte

Programmversionen haben wollte -- nur zum Betrachten geht auch die neue,

und bei Änderungen scheint mir unbedingt sinnvoller,  gleich auf

aktuellen Stand aufzusteigen.  Außer wenn man als Dienstleister für

konservative Kunden arbeitet.)

...oder wenn man an einem alten Projekt nur eine Kleinigkeit ändern

muß. Auch das wurde schon öfters diskutiert.

Besonders bei Eagle 3.* -> 4 oder 5 gibt es das Problem mit dem

Bibliothekskonzept. Ein sauberer Umstieg auf Eagle 4 oder 5 ist mit

sehr viel Aufwand verbunden.

3.  Für SCH und BRD sollen auch beliebige und unterschiedliche Namen und

Pfade zulässig sein.  Ihre Verknüpfung erfolgt nur noch im EPF.  Die

Verknüpfungspfade sollen absolut und relativ und auch übers Netz möglich

sein.

Das wäre mir nicht sehr wichtig.

4. Der View-Modus sollte auch im EPF für die dort referenzierten Dateien

notiert sein und auch fürs EPF selber möglich sein.

Da bin ich mir nicht sicher.

5. Im EPF sollen die sichtbaren Layer notiert sein (vorrangig vor denen

im SCH / BRD).

Ack. Wenn man ein EPF als "Ansichtsoptionsdatei" verwendet, ist das

nützlich.

6. Im EPF soll die Eagle-Version für die referenzierten Dateien notiert

sein.  Wird mit einer neueren gearbeitet,  dann warnen und die Dateien

zunächst im View-Modus öffnen.

Die Versionen sind doch aus den Dateien selbst erkennbar.

7. Eagle soll mehrere Projekte parallel öffnen können,  um zB

verschiedene Versionen vergleichen zu können oder für Copy/Paste.  So

Ja! Auch schon oft gefordert. Oder die "Zwischenablage" des

Betriebssytems unterstützen oder einen anderen effizienten Weg für

cut/paste zwischen Dokumenten anbieten.

dass beim wiederholten Aufruf von Dokumenten alle in verschiedenenen

Fenstern der einen laufenden Instanz geöffnet werden.  (Könnte evtl.

auch wie jetzt mit mehreren Instanzen gehen,  wenn sie sich den

Paste-Puffer teilen)

 

8. Der Eagle-Projektmanager sollte sich etwas mehr an den gewohnten

Explorer anlehnen.  Der Projektpfad soll nur ein anfängliches

Arbeitsverzeichnis sein,  man soll auch daraus hochsteigen können.  Der

Hauptnutzen gegenüber anderern Explorern liegt in der zusätzlich

angezeigten Description -- die sollte aber in die EPF hinein verlegt

werden;  und im Stöbern in den Bibliotheken / Design Rules.

Die Description muß schon in der betroffenen Datei bleiben. Sonst gibt

es verschiedene Probleme.

Servus

Oliver