Chaos mit mehreren EAGLE Instanzen

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

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

Oliver Betz schrieb:

Hans Lederer schrieb:

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.

 

Nein,  Mißverständnis:  Jetzt arbeitet der Eagle-Projektmanager strikt

verzeichnisorientiert,  er nimmt an,  ein Verzeichnis = ein

Eagle-Projekt.  Daher kommt der meiste Ärger und wohl auch die saublöde

Restriktion auf den fixen Namen Eagle.EPF.  Und daher auch,  dass er die

Beschreibung für dieses Projekt als extra Textdatei mit dem fixen Namen

DESCRIPTION in das Verzeichnis schreibt.

Ich meine hier,  dass diese Projektbeschreibung keine extra Datei sein,

  sondern mit im EPF stehen soll,  eben damit keine Zuordnungsprobleme

entstehen.  Sie würde dann zB angezeigt,  wenn man im

Eagle-Projektmanager die EPF markiert (noch nicht öffnet).

Ich möchte,  dass nicht mehr die Verzeichnisse für ein Projekt relevant

sind,  sondern rein nur die EPFs.  Und dazu ist eine freie Pfad- und

Namenswahl sehr wichtig!

Das hätte auch andere nützliche Nebenwirkungen,  zB auf die lästigen

Ladezeiten des Eagle-Projektmanagers -- er bräuchte nicht mehr alle

Verzeichnisse auf enthaltene EPFs abzuklappern,  sondern einfach nur den

Baum an dem einen aktuellen Verzeichnis aufklappen und die dort

enthaltenen EPFs aufzulisten.

--

Grüße,  Hans