Horizon EDA [War: Neues, halbfertiges Elektronik-CAD-Programm]

[Possetitjel (Gast)]

Stefan S. schrieb:

> Sag mal Lukas, hast Du eigentlich schon eine Idee bezüglich
> Simulation?

Worauf zielt die Frage?

Klassische Schaltungssimulation (konzentrierte Bauelemente)
oder Simulation parasitärer Elemente im Layout?

> Mit gEDA war Simulation mit Spice oder GnuCap ja sehr zäh.

Was bedeutet das?

> Ich vermute mal, dass Simulation heute ein entscheidendes
> Kriterium für eine EDA Software ist.

Also irgendwie verstehe ich die Welt nicht mehr... ist
vemutlich eine Altersfrage...

Ich verlange doch von meinem Oszi auch nicht, dass er Kaffee
kocht, Kinderlieder singt, Bratkartoffeln brät und eine
Bandbreite von 1GHz hat.

Wenn ich einen Schaltplan zeichnen will, möchte ich ein
Schaltplanzeichenprogramm nehmen.
Wenn ich ein Layout entwickeln will, möchte ich einen
Layouteditor starten.
Wenn ich simulieren will, starte ich einen Simulator.

[Jörg W. (dl8dtl) (Moderator)]

Possetitjel schrieb:
> Wenn ich simulieren will, starte ich einen Simulator.

Naja, es ist natürlich schon hübsch, wenn man den Schaltplan für
eine Simulation nicht nochmal zeichnen muss, sondern den bereits im
EDA-Tool gezeichneten dafür nehmen kann.  Gleiches fürs Layout
bezüglich einer EM-Feld-Simulation.

Aber ich halte das auch eher für ein untergeordnetes Argument.  Eine
Simulation steht und fällt ohnehin mit den Modellen.

[Hans (Gast)]

Possetitjel schrieb:
> Wenn ich einen Schaltplan zeichnen will, möchte ich ein
> Schaltplanzeichenprogramm nehmen.
> Wenn ich ein Layout entwickeln will, möchte ich einen
> Layouteditor starten.
> Wenn ich simulieren will, starte ich einen Simulator.

full ack!

vor allem ist das schematic für die simulation sicher nicht ident mit 
dem für's layout.

73

[Possetitjel (Gast)]

Jörg W. schrieb:

> Possetitjel schrieb:
>> Wenn ich simulieren will, starte ich einen Simulator.
>
> Naja, es ist natürlich schon hübsch, wenn man den Schaltplan
> für eine Simulation nicht nochmal zeichnen muss, sondern den
> bereits im EDA-Tool gezeichneten dafür nehmen kann. Gleiches
> fürs Layout bezüglich einer EM-Feld-Simulation.

Na klar.

Kompatible DATEIFORMATE setze ich eigentlich voraus; notfalls
tut's ein funktionierender Export/Import.

Aber genau DAS ist ja offensichtlich nicht gegeben.

> Aber ich halte das auch eher für ein untergeordnetes Argument.
> Eine Simulation steht und fällt ohnehin mit den Modellen.

Naja... ich gehe schon soweit mit, dass Software, die praktisch
anwendbar sein will, auch die in der Praxis auftretenden Arbeits-
abläufe unterstützen muss.

Ich vertrete aber die -- offenbar völlig veraltete -- Meinung,
dass die Software MIR dienen soll, und nicht umgekehrt ich die
Software loben, preisen und ihre Schlingen und Windungen besser
und besser studieren muss.

[Michael W. (Gast)]

Jörg W. schrieb:
> aja, es ist natürlich schon hübsch, wenn man den Schaltplan für
> eine Simulation nicht nochmal zeichnen muss,

Das ist mit Verlaub nicht nur "hübsch" sondern essenziell! Bei einer 
größeren Schaltung möchte Ich nicht alles zweimal eingeben. Zumindest 
eine Netzliste muss exportierbar sein und dabei müssen vor allem die 
leeren, nicht vorhanden Bautteile als dummies mit verdrahtet sein, damit 
man sie in der Simulation direkt ersetzen kann.

[Possetitjel (Gast)]

Hans schrieb:

> vor allem ist das schematic für die simulation sicher
> nicht ident mit dem für's layout.

Ja.

Und das geht noch weiter. Viele Schaltpläne, die hier auf
µC.net so vorgestellt werden, sehen einfach besch***en aus
und sind eine Zumutung.

Ich habe mal darüber nachgedacht, warum das so oft so ist, und
bin zu dem Ergebnis gekommen, dass der klassische Schaltplan
aus der Zeit der diskreten Bauelemente stammt: Relativ viele
Bauteile, einfache, klar erkennbare Funktion für jedes Bauteil,
wenige Anschlüsse an jedem Bauteil.

Mikrocontroller oder FPGAs sind aber das genaue Gegenteil von
diskreten Bauelementen. Der klassische Schaltplan ist also für
diese Schaltungsteile vielleicht gar nicht die optimale
Darstellungsform.

Wünschenswert wäre vielleicht, dass man auch Daten in
tabellarischer Form (Pinbelegungen z.B.) in die Software
hineinfüttern kann. Aber damit ist natürlich NICHT gemeint,
dass die EDA-Software ein "Spreadsheet-Plugin" bekommt, das
sich selbstverständlich ganz anders bedient als Excel oder
OOCalc und dessen Datenformat selbstverständlich zu nichts
anderem auf der Welt kompatibel ist.

Notwendig wäre, dass Daten, die heutzutage sowieso schon
irgendwo (außerhalb der EDA-Software) anfallen, vernünftig
weiterverarbeitet werden können.

[Possetitjel (Gast)]

Mar. W. schrieb:

> Jörg W. schrieb:
>> aja, es ist natürlich schon hübsch, wenn man den Schaltplan
>> für eine Simulation nicht nochmal zeichnen muss,
>
> Das ist mit Verlaub nicht nur "hübsch" sondern essenziell!
> Bei einer größeren Schaltung möchte Ich nicht alles zweimal
> eingeben.

Genau mein Reden.

Nur muss das auch für die Schaltung gelten, die der Kollege
vor fünf Jahren mit KiCAD entwickelt hat und die ich heute
mit Horizon weiterentwickeln muss.

Jeder Koch hat einerseits Bratpfannen und andererseits das
Schnitzel.

Nur die so moderne und fortschrittliche Software-Branche hält
es für normal, dass man natürlich Meier-Schnitzel nur mit
Meier-Eiern und Meier-Semmelbröseln verfeinern und auch NUR
in Meier-Bratpfannen auf Meier-Herden mit Meier-Gas braten
darf, wobei die Flamme mit Meier-Hölzern angezündet worden
sein muss.

[Jörg W. (dl8dtl) (Moderator)]

Possetitjel schrieb:
> notfalls tut's ein funktionierender Export/Import.

Darauf wird's hinauslaufen.

[Lukas K. (carrotindustries)]

Simulation unmittelbar in horizon will ich in der Tat nicht haben. 
Horizon soll in erster Linie ein gutes Programm werden um Schaltpläne zu 
zeichnen und damit Boards zu machen. Erstmal nicht mehr. Warum schreit 
keiner, dass ERC noch vollständig fehlt, man keine differentiellen 
Leitungen routen kann, es keine Thermals in Flächen gibt, oder die 
Darstellung von Pad-Namen im Board noch sehr zu wünschen Übrig lässt?

Was ich sagen will: Es mag sinnvoll sein, Simulation in das Tool, mit 
dem man auch Boards macht integriert zu haben. Derzeit gibt es aber noch 
unzählige andere Baustellen, Simulation wäre dann ein doch sehr 
aufwändiges I-Tüpfelchen. Daher spreche ich mich derzeit aktiv gegen 
jegliche Art von Simulations-Integration in horizon aus. Siehe auch:

Wenn andere Programme (z.B. KiCad) nachwievor einen Schaltplaneditor 
haben, der keine Ahnung von Netzen hat und den Anwender Junctions nach 
Gutdünken platzieren lässt, aber schon dabei sind SPICE-Integration zu 
entwickeln liegt meines Erachtens der Fokus bei der Entwicklung falsch.

Ja, Standards wären in der Tat schön, doch abgesehen von recht 
primitiven Spice-Netzlisten und Gerber gibt es in der Branche nichts 
wirklich brauchbares, was auch Anwendung findet.

Possetitjel schrieb:
> Wünschenswert wäre vielleicht, dass man auch Daten in
> tabellarischer Form (Pinbelegungen z.B.) in die Software
> hineinfüttern kann.

Geht schon: 
https://github.com/carrotIndustries/horizon/wiki/Working-with-the-Pool-Manager-and-Part-Wizard#create-all-new-part

Verbindungen nicht nur im Schaltplan zu zeichnen ist in der Architektur 
schon seit Anfang an vorgesehen, da in Horizon die Netzliste und nicht 
der Schaltplan die Primärquelle ist. Wenn z.B. an einem Netz ein Label 
hängt, drückt dieses Label nicht etwa dem Netzegment den eingetippten 
Namen auf, sondern zeigt eben den Name des Netzes an.

[Possetitjel (Gast)]

Lukas K. schrieb:

> Simulation unmittelbar in horizon will ich in der Tat
> nicht haben.

Was bedeutet das? Also: Was soll "unmittelbar in horizon"
bedeuten?

1. Interpretation: "Horizon bringt eigenen Simulator mit".

Naja... also ich weiss nicht, wie KiCAD das tatsächlich macht,
aber wenn die KiCAD-Leute in Anbetracht von gnucap, qucs, Spice,
LTSpice... ihre eigene Numerik schreiben, dann haben sie nicht
mehr alle Tassen im Schrank. Meine Meinung.

Die Numerik komplett neu zu entwickeln, wenn es Simulatoren
mit bereits etablierten und akzeptierten Schnittstellen gibt,
die man integrieren kann, ist komplett dämlich.

2. Interpretation: "Keine Möglichkeit, externen Simulator
auf Knopfdruck aufzurufen".

??? Warum nicht?

Das bekomme ja sogar ich mit Tcl/Tk hin, wenn ich mir Mühe
gebe. Wo ist das Problem?

> Horizon soll in erster Linie ein gutes Programm werden um
> Schaltpläne zu zeichnen und damit Boards zu machen. Erstmal
> nicht mehr. Warum schreit keiner, dass ERC noch vollständig
> fehlt, man keine differentiellen Leitungen routen kann, es
> keine Thermals in Flächen gibt, oder die Darstellung von
> Pad-Namen im Board noch sehr zu wünschen Übrig lässt?

Weil Du auf technische Details fixiert bist, die vom Standpunkt
eines Selbständigen bzw. einer kleinen Klitsche aus völlig
nebensächlich sind.

> Ja, Standards wären in der Tat schön,

Tja, das sehen wir offenbar etwas verschieden. Meiner
Meinung nach sind Standards im industriellen Zeitalter
und im Zeichen des weltweiten Handels nicht "schön",
sondern eine absolute Notwendigkeit.

Was glaubst Du, wie der Maschinenbau ohne Normteile
und ohne Standards für die technischen Zeichnungen
aussähe?

Richtig: Wie im Mittelalter.

Jetzt weisst Du auch, welche Meinung ich zum Stand der EDA-
Software habe (nicht DEINER EDA-Software, sondern DER EDA-
Software ganz allgemein).

> doch abgesehen von recht primitiven Spice-Netzlisten
> und Gerber gibt es in der Branche nichts wirklich
> brauchbares, was auch Anwendung findet.

Richtig.

Warum das bei kommerziellen Programmen so ist, ist augen-
scheinlich: Der Wunsch nach "Kundenbindung" bewirkt das.
(Es gibt da einen hübschen Wikipädie-Artikel dazu. Sinn-
gemäßes Zitat: "Die Hersteller von EDA-Software waren erst
nach massiver Intervention durch große Kunden bereit,
Exportschnittstellen in ihrer Software vorzusehen.")

Warum aber machen FOSS-Programmierer, die frei von vielen
Zwängen der kommerziellen Anbieter sind, diesen Scheissdreck
nach?

> Possetitjel schrieb:
>> Wünschenswert wäre vielleicht, dass man auch Daten in
>> tabellarischer Form (Pinbelegungen z.B.) in die Software
>> hineinfüttern kann.
>
> Geht schon:

Um so besser.
Ändert aber nichts am grundsätzlichen Problem.

> Verbindungen nicht nur im Schaltplan zu zeichnen ist in der
> Architektur schon seit Anfang an vorgesehen, da in Horizon
> die Netzliste und nicht der Schaltplan die Primärquelle ist.

Ich hatte schon damals herausgelesen, dass Du einige sehr
sinnvolle Ansätze verfolgst, die ich von anderen Projekten
nicht kenne.

Trotzdem sehe ich Dein Projekt wie Baumgartners Stratosphären-
sprung: Ich bewundere die persönliche Leistung aufrichtig --
aber es ist letztlich für mich uninteressant, weil nichts
konkret für mein eigenes Leben, mein eigenes Tun daraus folgt.

Bitte nicht falsch versehen: Das ist keine Kritik an Deinem
Tun oder Deinen Entscheidungen. Es ist Dein Projekt (und
schätzungsweise ein Hobby und kein Broterwerb), und Du bist
völlig frei in Deinem Tun und Lassen.

Meine Worte sind keine Kritik an Dir, sondern sollen nur eine
Erklärung meines Verhaltens sein: Obwohl ich auf der Suche
nach für mich geeigneter EDA-Software bin, habe ich (bis jetzt)
nicht den Eindruck, dass Deine Software für mich in Frage kommt.

Die Schwerpunkte, die Du in Deiner Arbeit setzt, scheinen mir
mit meinen Wünschen in keiner Weise kompatibel.

[tester (Gast)]

Hi, ich wollte die aktuelle Version auch mal wieder testen, unter 
Xubuntu 16.04. Problem: imp.cpp bricht ab. Zur Info habe ich noch die 
Versionen der Abhängokgeiten angehängt. Geclont habe ich heute.

tester@HPi7:~/src/horizon/horizon$ sudo apt install libyaml-cpp-dev 
libsqlite3-dev util-linux librsvg2-dev     libcairomm-1.0-dev 
libepoxy-dev libgtkmm-3.0-dev uuid-dev libboost-dev     libzmq5 
libzmq3-dev libglm-dev
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
»libboost-dev« ist bereits die neuste Version (1.58.0.1ubuntu1).
»libcairomm-1.0-dev« ist bereits die neuste Version (1.12.0-1).
»libglm-dev« ist bereits die neuste Version (0.9.7.2-1).
»libgtkmm-3.0-dev« ist bereits die neuste Version (3.18.0-1).
»librsvg2-dev« ist bereits die neuste Version (2.40.13-3).
»libsqlite3-dev« ist bereits die neuste Version (3.11.0-1ubuntu1).
»libyaml-cpp-dev« ist bereits die neuste Version (0.5.2-3).
»libzmq3-dev« ist bereits die neuste Version (4.1.4-7).
»libzmq5« ist bereits die neuste Version (4.1.4-7).
»libepoxy-dev« ist bereits die neuste Version (1.3.1-1ubuntu0.16.04.2).
»util-linux« ist bereits die neuste Version (2.27.1-6ubuntu3.3).
»uuid-dev« ist bereits die neuste Version (2.27.1-6ubuntu3.3).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 47 nicht 
aktualisiert.

g++ -c -I. -Iblock -Iboard -Icommon -Iimp -Ipackage -Ipool -Ischematic 
-Iutil -Iconstraints -g3 -D_USE_MATH_DEFINES -fdata-sections 
-ffunction-sections -pthread -std=c++11 -pthread -I/usr/include/uuid 
-I/usr/include/gtkmm-3.0 -I/usr/lib/x86_64-linux-gnu/gtkmm-3.0/include 
-I/usr/include/atkmm-1.6 -I/usr/include/gtk-3.0/unix-print 
-I/usr/include/gdkmm-3.0 -I/usr/lib/x86_64-linux-gnu/gdkmm-3.0/include 
-I/usr/include/giomm-2.4 -I/usr/lib/x86_64-linux-gnu/giomm-2.4/include 
-I/usr/include/pangomm-1.4 
-I/usr/lib/x86_64-linux-gnu/pangomm-1.4/include 
-I/usr/include/glibmm-2.4 -I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include 
-I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 
-I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 
-I/usr/include/gio-unix-2.0/ -I/usr/include/mirclient 
-I/usr/include/mircore -I/usr/include/mircookie -I/usr/include/cairo 
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz 
-I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo 
-I/usr/include/cairomm-1.0 
-I/usr/lib/x86_64-linux-gnu/cairomm-1.0/include 
-I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include 
-I/usr/include/cairo -I/usr/include/librsvg-2.0 
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 
-I/usr/include/cairo -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 
-I/usr/include/freetype2 -I/usr/include/libpng12 -MP -MMD -pthread -Wall 
-Wshadow -std=c++14 -O3 imp/imp.cpp -o imp/imp.o
imp/imp.cpp: In member function ‘bool 
horizon::ImpBase::handle_click(GdkEventButton*)’:
imp/imp.cpp:498:20: error: ‘class Gtk::Menu’ has no member named 
‘popup_at_pointer’
      context_menu->popup_at_pointer((GdkEvent*)button_event);
                    ^
imp/imp.cpp:516:19: error: ‘class Gtk::Menu’ has no member named 
‘popup_at_pointer’
     context_menu->popup_at_pointer((GdkEvent*)button_event);
                   ^
Makefile:419: die Regel für Ziel „imp/imp.o“ scheiterte
make: *** [imp/imp.o] Fehler 1

[tester (Gast)]

Hm... das Problem ist wohl, dass

context_menu->popup_at_pointer((GdkEvent*)button_event);

erst ab libgtkmm 3.22 dabei ist.

Ich hab' nur libgtkmm3.18.

[Frank K. (frank)]

Selbes Problem habe ich auch, ich versuche es auf openSUSE Leap42.3 zu 
bauen.

[Lukas K. (carrotindustries)]

Hoppla, hab ich das wohl übersehen. Sollte nun funktionieren.

[tester (Gast)]

Es werden wohl noch mehr Funktionen von >gtkmm3.18 verwendet:
GtkFileChooserNative ist erst ab 3.20 dabei

imp/imp_schematic.cpp: In member function ‘void horizon::ImpSchematic::handle_export_pdf()’:
imp/imp_schematic.cpp:123:3: error: ‘GtkFileChooserNative’ was not declared in this scope
   GtkFileChooserNative *native = gtk_file_chooser_native_new ("Save PDF",
   ^
imp/imp_schematic.cpp:123:25: error: ‘native’ was not declared in this scope
   GtkFileChooserNative *native = gtk_file_chooser_native_new ("Save PDF",
                         ^
imp/imp_schematic.cpp:127:13: error: ‘gtk_file_chooser_native_new’ was not declared in this scope
    "_Cancel");
             ^
imp/imp_schematic.cpp:137:54: error: ‘GTK_NATIVE_DIALOG’ was not declared in this scope
   if(gtk_native_dialog_run (GTK_NATIVE_DIALOG (native))==GTK_RESPONSE_ACCEPT) {
                                                      ^
imp/imp_schematic.cpp:137:55: error: ‘gtk_native_dialog_run’ was not declared in this scope
   if(gtk_native_dialog_run (GTK_NATIVE_DIALOG (native))==GTK_RESPONSE_ACCEPT) {
                                                       ^
Makefile:419: die Regel für Ziel „imp/imp_schematic.o“ scheiterte
make: *** [imp/imp_schematic.o] Fehler 1

Brauche wohl ein Ubuntu 17.04 oder 17.10...

[Frank K. (frank)]

Ich baue grade openSUSE rpms, Tumbleweed geht schon, leap 42.3 baut 
gerade, und auch für Raspi (ARM). Unter openSUSE können die Binaries mit

zypper ar https://download.opensuse.org/repositories/home:/frank_kunz/openSUSE_Tumbleweed/ horizon_repo
zypper ref
zypper in horizon

installiert werden. Oder einfach yast nehmen. Zudem versuche ich mich an 
einem Appimage. Damit soll es möglich sein das Programm auf (nahezu) 
beliebigen Distros auszuführen, also so was ähnliches wie das Windows 
Package für Linux. Mal sehen ob es klappt.

Die rpm Packages enthalten nur die kompilierten Binaries, der Pool und 
das Beispielprojekt muss separat von github geladen werden (wie im wiki 
beschrieben).

Gruß,
Frank

ps: Benutzung auf eigene Gefahr.

[Stefan S. (Gast)]

tester schrieb:
> Brauche wohl ein Ubuntu 17.04 oder 17.10...

Ja ist natürlich etwas schade dass es für dich nun nicht funktioniert 
hat.

Aber GTK 3.20 oder 3.22 sollte man schon haben, wenn man denn  testen 
will. Viele Dinge waren vor 3.20 unspezifiziert, und 3.22 ist ja wohl 
nun auch schon seit ca. einem Jahr erhältlich und das ist ja praktisch 
auch die Langzeitversion, bis dann GTK4 kommt.

Einen Hinweis welche GTK Version nötig ist hatte ich auf Lukas Seite so 
auf den ersten Blick auch nicht gesehen.

[tester (Gast)]

Läuft es bei dir durch? Ich habe noch mehr Probleme. Ist mein gcc zu 
alt?

gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)

core/tool_move.cpp: In constructor ‘horizon::ToolMove::ToolMove(horizon::Core*, horizon::ToolID)’:
core/tool_move.cpp:14:58: error: use of deleted function ‘horizon::ToolHelperMove::ToolHelperMove()’
  ToolMove::ToolMove(Core *c, ToolID tid): ToolBase(c, tid) {
                                                          ^
In file included from core/tool_move.hpp:3:0,
                 from core/tool_move.cpp:1:
core/tool_helper_move.hpp:5:8: note: ‘horizon::ToolHelperMove::ToolHelperMove()’ is implicitly deleted because the default definition would be ill-formed:
  class ToolHelperMove : public virtual ToolBase {
        ^
core/tool_helper_move.hpp:5:8: error: no matching function for call to ‘horizon::ToolBase::ToolBase()’
In file included from core/tool_move.hpp:2:0,
                 from core/tool_move.cpp:1:
core/core.hpp:86:4: note: candidate: horizon::ToolBase::ToolBase(horizon::Core*, horizon::ToolID)
    ToolBase(class Core *c, ToolID tid);
    ^
core/core.hpp:86:4: note:   candidate expects 2 arguments, 0 provided
core/core.hpp:84:8: note: candidate: horizon::ToolBase::ToolBase(const horizon::ToolBase&)
  class ToolBase {
        ^
core/core.hpp:84:8: note:   candidate expects 1 argument, 0 provided
core/tool_move.cpp:14:58: error: use of deleted function ‘horizon::ToolHelperMerge::ToolHelperMerge()’
  ToolMove::ToolMove(Core *c, ToolID tid): ToolBase(c, tid) {
                                                          ^
In file included from core/tool_move.hpp:4:0,
                 from core/tool_move.cpp:1:
core/tool_helper_merge.hpp:5:8: note: ‘horizon::ToolHelperMerge::ToolHelperMerge()’ is implicitly deleted because the default definition would be ill-formed:
  class ToolHelperMerge: public virtual ToolBase {
        ^
core/tool_helper_merge.hpp:5:8: error: no matching function for call to ‘horizon::ToolBase::ToolBase()’
In file included from core/tool_move.hpp:2:0,
                 from core/tool_move.cpp:1:
core/core.hpp:86:4: note: candidate: horizon::ToolBase::ToolBase(horizon::Core*, horizon::ToolID)
    ToolBase(class Core *c, ToolID tid);
    ^
core/core.hpp:86:4: note:   candidate expects 2 arguments, 0 provided
core/core.hpp:84:8: note: candidate: horizon::ToolBase::ToolBase(const horizon::ToolBase&)
  class ToolBase {
        ^
core/core.hpp:84:8: note:   candidate expects 1 argument, 0 provided
core/tool_move.cpp: In member function ‘void horizon::ToolMove::expand_selection()’:
core/tool_move.cpp:74:22: warning: unused variable ‘itv’ [-Wunused-variable]
      for(const auto &itv: poly->vertices) {
                      ^
Makefile:419: die Regel für Ziel „core/tool_move.o“ scheiterte
make: *** [core/tool_move.o] Fehler 1

[Frank K. (frank)]

gcc5 hat bei mir auch nicht funktioniert, mit 
gcc6-c++-6.2.1+r239768-6.19 geht es.

Gruß,
Frank

[Helmut S. (helmuts)]

Mar. W. schrieb:
> Das ist ein gutes Argument. Ich bin auch ehe dafür die Simulation mit
> KiCAD weiterzutreiben und dort zu investieren, als noch ein neues
> Programm aufzuziehen.

Eine Simulation die aus dem PCB-Programm kommt und nicht alle benötigten 
SPICE-Modelle bereits kennt hat verloren. Die Pin-Reihenfolge in einem 
SPICE-Modell(subcircuit) hat überhaupt nichts mit der Pin-Reihenfolge 
des realen Bauteils zu tun. Selbst die Anzahl der Pins ist 
unterschiedlich. Ohne dieses Wissen, kann das PCB-Programm keine 
vernünftige Netzliste für SPICE generieren. Man müsste bereits beim 
Aufsetzen der Symbole im Schaltplan-Programm auch die Pins des 
SPICE-Modells definieren. Daran scheitern schon die meisten die wenig 
über SPICE wissen. So etwas kann man z. B. in der Software von Cadence 
und Mentor machen. KiCad hat dazu vermutlich überhaupt nichts 
vorgesehen.

Lukas sollte die komplette Zeit in das PCB-Programm, den 
Schaltplaneditor und in den Bauteileeditor investieren und besser keine 
Zeit für Simulationstools investieren.

[Frank K. (frank)]

Hallo,

mit gcc6-c++-6.2.1+r239768-6.19 bekomme ich den Fehler:

[  341s] core/tool_move.cpp: In constructor 'horizon::ToolMove::ToolMove(horizon::Core*, horizon::ToolID)':
[  341s] core/tool_move.cpp:14:58: error: use of deleted function 'horizon::ToolHelperMove::ToolHelperMove()'
[  341s]   ToolMove::ToolMove(Core *c, ToolID tid): ToolBase(c, tid) {
[  341s]                                                           ^
[  341s] In file included from core/tool_move.hpp:3:0,
[  341s]                  from core/tool_move.cpp:1:
[  341s] core/tool_helper_move.hpp:5:8: note: 'horizon::ToolHelperMove::ToolHelperMove()' is implicitly deleted because the default de
finition would be ill-formed:
[  341s]   class ToolHelperMove : public virtual ToolBase {
[  341s]         ^~~~~~~~~~~~~~
[  341s] core/tool_helper_move.hpp:5:8: error: no matching function for call to 'horizon::ToolBase::ToolBase()'
[  341s] In file included from core/tool_move.hpp:2:0,
[  341s]                  from core/tool_move.cpp:1:
[  341s] core/core.hpp:86:4: note: candidate: horizon::ToolBase::ToolBase(horizon::Core*, horizon::ToolID)
[  341s]     ToolBase(class Core *c, ToolID tid);
[  341s]     ^~~~~~~~
[  341s] core/core.hpp:86:4: note:   candidate expects 2 arguments, 0 provided
[  341s] core/core.hpp:84:8: note: candidate: horizon::ToolBase::ToolBase(const horizon::ToolBase&)
[  341s]   class ToolBase {
[  341s]         ^~~~~~~~
[  341s] core/core.hpp:84:8: note:   candidate expects 1 argument, 0 provided
[  341s] core/tool_move.cpp:14:58: error: use of deleted function 'horizon::ToolHelperMerge::ToolHelperMerge()'
[  341s]   ToolMove::ToolMove(Core *c, ToolID tid): ToolBase(c, tid) {
[  341s]                                                           ^
[  341s] In file included from core/tool_move.hpp:4:0,
[  341s]                  from core/tool_move.cpp:1:
[  341s] core/tool_helper_merge.hpp:5:8: note: 'horizon::ToolHelperMerge::ToolHelperMerge()' is implicitly deleted because the default
 definition would be ill-formed:
[  341s]   class ToolHelperMerge: public virtual ToolBase {
[  341s]         ^~~~~~~~~~~~~~~
[  341s] core/tool_helper_merge.hpp:5:8: error: no matching function for call to 'horizon::ToolBase::ToolBase()'
[  341s] In file included from core/tool_move.hpp:2:0,
[  341s]                  from core/tool_move.cpp:1:
[  341s] core/core.hpp:86:4: note: candidate: horizon::ToolBase::ToolBase(horizon::Core*, horizon::ToolID)
[  341s]     ToolBase(class Core *c, ToolID tid);
[  341s]     ^~~~~~~~
[  341s] core/core.hpp:86:4: note:   candidate expects 2 arguments, 0 provided
[  341s] core/core.hpp:84:8: note: candidate: horizon::ToolBase::ToolBase(const horizon::ToolBase&)
[  341s]   class ToolBase {
[  341s]         ^~~~~~~~
[  341s] core/core.hpp:84:8: note:   candidate expects 1 argument, 0 provided
[  341s] core/tool_move.cpp: In member function 'void horizon::ToolMove::expand_selection()':
[  341s] core/tool_move.cpp:74:22: warning: unused variable 'itv' [-Wunused-variable]
[  341s]       for(const auto &itv: poly->vertices) {
[  341s]                       ^~~
[  343s] Makefile:419: recipe for target 'core/tool_move.o' failed
[  343s] make: *** [core/tool_move.o] Error 1
[  343s] make: *** Waiting for unfinished jobs....

Gruß,
Frank

[Jörg W. (dl8dtl) (Moderator)]

Lukas K. schrieb:
> Warum schreit keiner, dass ERC noch vollständig fehlt,

Weil ein gut durchlaufender ERC aus Sicht eines Anwenders oft mehr
Arbeit macht als er Nutzen bringt.

Was ist denn ein Pin eines Steckverbinders, ist es eine Signalquelle,
eine Signalsenke, oder ist es vielleicht eine daran zugeführte
Versorgungsspannung?  Ist ein Pin an einem Mikrocontroller eine
Signalquelle oder -senke, oder vielleicht beides?

Solange ein 7400 zwei Eingänge und einen Ausgang pro Gatter hatte, war
die Welt da noch einfach.

Wichtig ist, dass man ordentlich erkennt, ob ein Bauteilpin auch
tatsächlich an die Verbindung angeschlossen worden ist oder nicht.  Aus
der Zeit, in der ich mal mit Eagle gearbeitet habe, habe ich noch in
Erinnerung, dass man das dort nicht richtig gesehen hatte und es einem
daher passieren konnte, dass man ein „in der Luft hängendes“ Pin
produziert hat.  (Das ist aber sehr lange her, ich hoffe mal, dass
neuere Eagle-Versionen da besser geworden sind.)  Das war eigentlich
einer der wesentlichen Punkte, wo der ERC mal hilfreich war, einem die
gar nicht angeschlossenen Pins zu benennen.

[Lukas K. (carrotindustries)]

Das mit den Konstruktoren ist repariert, kommt wohl davon, wenn man nur 
auf Arch Linux und MSYS2 baut, die beide doch recht "bleeding edge" 
sind. Mit gcc 7.2 und clang 5 baute es auch schon so...

tester schrieb:
> Es werden wohl noch mehr Funktionen von >gtkmm3.18 verwendet:
> GtkFileChooserNative ist erst ab 3.20 dabei
Uff, ich hatte erst vor kurzem alle Filechooser auf GtkFileChooserNative 
umgebaut, damit die Windows-Fraktion auch ihren gewohnten "Datei 
Öffnen"-Dialog bekommt. Gtk 3.20 ist jetzt auch schon über 1 Jahr alt...

Du könntest mal versuchen, den commit bei dir zu reverten: 
https://github.com/carrotIndustries/horizon/commit/28779193432251564b054de65118561d3575ce84

Re DRC: Mir Schwebte vor im Zuge von DRC zu Implementieren, dass man die 
elektrische Richtung von Pins im Schaltplan überschreiben kann, eben für 
Mikrocontroller und Steckverbinder. Steht und fällt natürlich mit der 
Sorgfalt und Motivation des Anwenders...

Frank K. schrieb:
> Ich baue grade openSUSE rpms, Tumbleweed geht schon, leap 42.3 baut
> gerade, und auch für Raspi (ARM).

Schick, auch wenn es meines Erachtens noch ein wenig zu früh für 
RPM-Pakete ist, aber jeder so wie er will :) Horizon wird wahrscheinlich 
nicht auf dem Raspberry PI laufen, da der Renderer OpenGL 3 braucht.

Jörg W. schrieb:
> Wichtig ist, dass man ordentlich erkennt, ob ein Bauteilpin auch
> tatsächlich an die Verbindung angeschlossen worden ist oder nicht.

Siehe Anhang, sollte deutlich genug sein ;) Eagle, KiCad und bestimmt 
einige andere Programme stellen Verbindung im Schaltplan her, indem Pin 
und Linie auf dem selben Punkt liegen. Damit öffnet man natürlich 
solchen Problemen Tür und Tor. Bei horizon kann das prinzipiell nicht 
auftreten, da die Linie "weiß", mit welchen Pin von welchem Symbol sie 
verbunden ist.

[Jörg W. (dl8dtl) (Moderator)]

Lukas K. schrieb:
>> Wichtig ist, dass man ordentlich erkennt, ob ein Bauteilpin auch
>> tatsächlich an die Verbindung angeschlossen worden ist oder nicht.
>
> Siehe Anhang, sollte deutlich genug sein ;) Eagle, KiCad und bestimmt
> einige andere Programme stellen Verbindung im Schaltplan her, indem Pin
> und Linie auf dem selben Punkt liegen. Damit öffnet man natürlich
> solchen Problemen Tür und Tor.

Naja, solange da so ein kleines Viereck ist, welches beim Anschließen
der Linie verschwindet, funktioniert das durchaus (so kenne ich es von
BAE, so macht es auch KiCad).  Bei Eagle erinnere ich mich dran, dass
es da irgendwie (damals) kein derartiges Kennzeichen gab, damit war
das immer problematisch.

> Bei horizon kann das prinzipiell nicht auftreten, da die Linie "weiß",
> mit welchen Pin von welchem Symbol sie verbunden ist.

Naja, aber irgendwoher muss die Linie das ja "wissen", also irgendwann
muss der Benutzer sie das erste Mal mit dem Pin verbunden haben.  Da
ist ja der springende Punkt.

[J. S. (engineer)]

Ich habe früher mit Protel Advanced Schematic einiges gemacht, da gab es 
eine direkte Integration des PLD-Entwurfs mit Verbindung des Pinnings 
zwischen PLD und PSB, Übergabe an das design tool / den PLD-Compiler und 
vor allem einen Netzlisten-Export im SPICE-Format. Simuliert wurde das 
in MicroSIM pSPICE.

Sicher hat es nicht für alles ein Modell gegeben und nicht bei jeder 
Schaltung macht eine Simulation Sinn, aber der Vorteil eines 
integrierten tools mit Schnittstellen an die einschlägigen Simulatoren 
ist sehr vorteilhaft im Sinne eines Master-Designs. Du konntest also die 
digitale Schaltung komplett in einem tool bauen und Dich dann 
entscheiden, was davon ins PLD gezogen wird. Unschätzbar nützlich, um 
vorhandene Digitalschaltungen zu importieren und auf PLDs zu bringen.

Das war der Stand Mitte/Ende der 90er!

Etwas später wurde dann MicroSIM von Orchad gekauft und die haben ihr 
eigenes SCH drübergestülpt, allerdings ohne einen PLD Entwurf. Parallel 
ist Protel in Altium aufgegangen, wieder ohne PLD oder gar FPGA tool. Ab 
da haben sich auch die FPGA tools losgelöst und verselbständigt und ihre 
eigenen Editoren gehabt. Ich erinnere mich noch gut an mein erstes 
Xilnx4000 design.


Possetitjel schrieb:
> Mikrocontroller oder FPGAs sind aber das genaue Gegenteil von
> diskreten Bauelementen. Der klassische Schaltplan ist also für
> diese Schaltungsteile vielleicht gar nicht die optimale
> Darstellungsform.

Da bin Ich ganz bei Dir und das propagieren FPGA-Entwickler schon seit 
einer Dekade! FPGA Entwicklung passiert 1 Abstraktionsebene und damit 
mindestens einen Layer weiter oben als der Schaltplan. Von daher sind 
Schaltplantools immer eine Beschränkung.

> Wünschenswert wäre vielleicht, dass man auch Daten in
> tabellarischer Form (Pinbelegungen z.B.) in die Software
> hineinfüttern kann.
Genau das passiert auch. Mentor's  HDL-Designer unterstützt das z.B. - 
nennt sich "interface based design", man beginnt mit den Ports. Leider 
ist das nicht integral in beide Richtungen mit der Entity-Verwaltung 
verknüpft.

Da bräuchte man schon was anderes.

Da ist Simulink z.B. weiter, indem es alle denkbaren Blöcke, wie C, 
embedded MATLAB / VHDL jeweils als Design halten kann. Leider hat das 
wieder andere Einschränkungen.

[Stefan S. (Gast)]

Lukas, ich hatte gestern abend auch mal versucht es zu kompilieren.

Leider lässt sich bei mir derzeit zmqpp wegen

https://bugs.gentoo.org/628200

nicht installieren. Ich werde demnächst da mal nachfragen und es dann 
später erneut versuchen.

[Lukas K. (carrotindustries)]

Stefan S. schrieb:
> Lukas, ich hatte gestern abend auch mal versucht es zu kompilieren.
>
> Leider lässt sich bei mir derzeit zmqpp wegen
>
> https://bugs.gentoo.org/628200
>
> nicht installieren. Ich werde demnächst da mal nachfragen und es dann
> später erneut versuchen.

Das sind die falschen C++-Bindings. Ich brauche nur die zmq.hpp aus 
https://github.com/zeromq/cppzmq Bei Arch ist die schon im zeromq-Paket 
mit drin.

[[e-mail] (Gast)]

Weiter vorne im Thread hatte ja schonmal jemand bemängelt, dass keine 
Binary-Pakete verfügbar sind.

Mach bitte nicht den Fehler wie viele andere OSS Entwickler, dass die zu 
sehr auf die Inputs von anderen Entwicklern geben, anstatt die 
Anwender von vorneherein im Focus zu haben.
Ein potentieller Anwender braucht aber niederschwelligen Zugang zu dem 
Programm, indem er sich einfach ein Binärpaket ziehen kann.

GitHub bietet Integration von TravisCI, etc., da kann man leicht 
automatische Builds und Bereitstellung als "Releases" (im Github-Sinne) 
realisieren.
Tu deiner tollen Entwicklungsarbeit diesen Gefallen.

[Stefan S. (Gast)]

Lukas K. schrieb:
> Das sind die falschen C++-Bindings.

Ach.

Erfolgreich installiert hatte ich schon

net-libs/zeromq-4.2.2-r2:0/5::gentoo

und

net-libs/cppzmq-0_pre150606::gentoo

Aber damit bekomme ich

imp/imp.cpp: In constructor ‘horizon::ImpBase::ImpBase(const string&)’:
imp/imp.cpp:24:42: error: no matching function for call to ‘zmq::socket_t::connect(std::__cxx11::basic_string<char>&)’
    sock_broadcast_rx.connect(ep_broadcast);
                                          ^
In file included from imp/imp.hpp:18:0,
                 from imp/imp.cpp:1:
/usr/include/zmq.hpp:405:21: note: candidate: void zmq::socket_t::connect(const char*)
         inline void connect (const char *addr_)
                     ^~~~~~~
/usr/include/zmq.hpp:405:21: note:   no known conversion for argument 1 from ‘std::__cxx11::basic_string<char>’ to ‘const char*’
imp/imp.cpp:36:43: error: expected primary-expression before ‘int’
     int fd = sock_broadcast_rx.getsockopt<int>(ZMQ_FD);
                                           ^~~
imp/imp.cpp: In lambda function:
imp/imp.cpp:41:40: error: expected primary-expression before ‘int’
     while(sock_broadcast_rx.getsockopt<int>(ZMQ_EVENTS) & ZMQ_POLLIN) {
                                        ^~~
imp/imp.cpp:41:40: error: expected ‘)’ before ‘int’
imp/imp.cpp:41:43: error: expected unqualified-id before ‘>’ token
     while(sock_broadcast_rx.getsockopt<int>(ZMQ_EVENTS) & ZMQ_POLLIN) {
                                           ^
imp/imp.cpp:645:1: error: expected ‘}’ at end of input
 }
 ^
imp/imp.cpp: In constructor ‘horizon::ImpBase::ImpBase(const string&)’:
imp/imp.cpp:645:1: error: expected ‘)’ at end of input
imp/imp.cpp:645:1: error: expected ‘}’ at end of input
imp/imp.cpp:645:1: error: expected ‘}’ at end of input
imp/imp.cpp: At global scope:
imp/imp.cpp:645:1: error: expected ‘}’ at end of input
make: *** [Makefile:419: imp/imp.o] Error 1

Deshalb dachte ich, dass vielleicht  net-libs/zmqpp-4.1.2::gentoo fehlt, 
welches ich nicht installieren konnte.

Mit c++ Fehlermeldungen habe ich so meine Probleme, was da z.B. bei CGAL 
kam war für mich nicht nachvollziehbar.

Aber ich will dich nicht von  der Arbeit abhalten, ich habe im moment eh 
nicht die Zeit mich mit Horizon näher zu beschäftigen.

[Lukas K. (carrotindustries)]

Stefan S. schrieb:
> net-libs/cppzmq-0_pre150606::gentoo

In dieser doch recht alten Version ist connect noch nicht für 
std::string überladen, das kam erst in diesem commit: 
https://github.com/zeromq/cppzmq/commit/34c8e4395c94d34a89bbeaaf2b8f9c94a8293c84

Da musst du wohl den Maintainer anstupsen, dass der das mal 
aktualisiert...

[e-mail] schrieb:
> Weiter vorne im Thread hatte ja schonmal jemand bemängelt, dass keine
> Binary-Pakete verfügbar sind.
Für Windows gibt es welche, siehe wiki. Bei den Linuxen scheitert's ja 
mehr daran, dass einige Distros zu alte Versionen von Abhängigkeiten 
mitbringen, da helfen auch Binärpakete nicht viel.

[tester (Gast)]

Lukas K. schrieb:
> tester schrieb:
>> Es werden wohl noch mehr Funktionen von >gtkmm3.18 verwendet:
>> GtkFileChooserNative ist erst ab 3.20 dabei
> Uff, ich hatte erst vor kurzem alle Filechooser auf GtkFileChooserNative
> umgebaut, damit die Windows-Fraktion auch ihren gewohnten "Datei
> Öffnen"-Dialog bekommt. Gtk 3.20 ist jetzt auch schon über 1 Jahr alt...

Das war jetzt eher ein Feedback und keine Kritik. Ich finde es ja toll, 
dass du so ein Projekt stemmst und weiter machst. Feedback halt nur, 
dass z.Zt. die Benutzer von 16.04 LTS außen vor sind, da ich jetzt keine 
sinnvolle Möglichkeit gefunden habe, gtk 3.22 parallel zu installieren. 
Und das ganze gtk Subsystem auszutauschen ist mir zu riskant.

Mein Hauptrechner hat eigentlich immer die LTS drauf, mein Hauptnotebook 
z.Zt. Mint 18.2. Leider ist das auch nicht aktuell genug. Ich habe noch 
ein Core2Duo mit 2 GB, denn könnte ich mal updaten, evtl. sogar mal 
Arch. Aber meine beiden Hauptrechner (beide i7, einmal Desktop und 
einmal Notebook, da will ich nicht unbedingt viel mit dem Core2Duo 
rummachen) sind halt im Moment nicht in der Lage horizon zu kompilieren. 
Gut ich könnte die Windows Version von horizon probieren, aber 
eigentlich will ich das nicht... Linux ist halt meine 
Hauptarbeitsplatform.

[Lukas K. (carrotindustries)]

tester schrieb:
> Lukas K. schrieb:
>> tester schrieb:
>>> Es werden wohl noch mehr Funktionen von >gtkmm3.18 verwendet:
>>> GtkFileChooserNative ist erst ab 3.20 dabei
>> Uff, ich hatte erst vor kurzem alle Filechooser auf GtkFileChooserNative
>> umgebaut, damit die Windows-Fraktion auch ihren gewohnten "Datei
>> Öffnen"-Dialog bekommt. Gtk 3.20 ist jetzt auch schon über 1 Jahr alt...
>
> Das war jetzt eher ein Feedback und keine Kritik. Ich finde es ja toll,
> dass du so ein Projekt stemmst und weiter machst. Feedback halt nur,
> dass z.Zt. die Benutzer von 16.04 LTS außen vor sind, da ich jetzt keine
> sinnvolle Möglichkeit gefunden habe, gtk 3.22 parallel zu installieren.
> Und das ganze gtk Subsystem auszutauschen ist mir zu riskant.

Probier mal den Patch im Anhang anzuwenden, dann sollte es auch mit Gtk 
3.18 funktionieren. Oder du wartest einfach bis zum nächsten LTS, dann 
ist horizon auch schon weiter ;)

[Frank K. (frank)]

Hallo,

Ich habe da noch mal ein build Problem:

[  497s] widgets/parameter_set_editor.cpp: In lambda function:
[  497s] widgets/parameter_set_editor.cpp:135:80: error: 'class Gtk::Popover' has no member named 'popdown'
[  497s]       dynamic_cast<Gtk::Popover*>(popover_box->get_ancestor(GTK_TYPE_POPOVER))->popdown();
[  497s]                                                                                 ^~~~~~~
[  499s] Makefile:419: recipe for target 'widgets/parameter_set_editor.o' failed
[  499s] make: *** [widgets/parameter_set_editor.o] Error 1
[  499s] make: *** Waiting for unfinished jobs....

Gruß,
Frank

[Lukas K. (carrotindustries)]

Frank K. schrieb:
> dynamic_cast<Gtk::Popover*>(popover_box->get_ancestor(GTK_TYPE_POPOVER)) 
->popdown();
> [  497s]
Ist repariert.

[Stefan S. (Gast)]

Ja, für cppzmq hatte ich ein aktuelles ebuild gefunden. Aber nun kommt

canvas/canvas_gl.cpp:243:42: warning: already captured ‘this’ in lambda expression
   auto dfn = [this, target_in_selection, this](const Target &ta) -> float{
                                          ^~~~
canvas/canvas_gl.cpp: In instantiation of ‘horizon::CanvasGL::cursor_move(GdkEvent*)::<lambda(const auto:2&)> [with auto:2 = horizon::Target]’:
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/bits/predefined_ops.h:241:11:   required from ‘bool __gnu_cxx::__ops::_Iter_pred<_Predicate>::operator()(_Iterator) [with _Iterator = std::_Rb_tree_const_iterator<horizon::Target>; _Predicate = horizon::CanvasGL::cursor_move(GdkEvent*)::<lambda(const auto:2&)>]’
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/bits/stl_algo.h:104:42:   required from ‘_InputIterator std::__find_if(_InputIterator, _InputIterator, _Predicate, std::input_iterator_tag) [with _InputIterator = std::_Rb_tree_const_iterator<horizon::Target>; _Predicate = __gnu_cxx::__ops::_Iter_pred<horizon::CanvasGL::cursor_move(GdkEvent*)::<lambda(const auto:2&)> >]’
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/bits/stl_algo.h:161:23:   required from ‘_Iterator std::__find_if(_Iterator, _Iterator, _Predicate) [with _Iterator = std::_Rb_tree_const_iterator<horizon::Target>; _Predicate = __gnu_cxx::__ops::_Iter_pred<horizon::CanvasGL::cursor_move(GdkEvent*)::<lambda(const auto:2&)> >]’
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/bits/stl_algo.h:3817:28:   required from ‘_IIter std::find_if(_IIter, _IIter, _Predicate) [with _IIter = std::_Rb_tree_const_iterator<horizon::Target>; _Predicate = horizon::CanvasGL::cursor_move(GdkEvent*)::<lambda(const auto:2&)>]’
canvas/canvas_gl.cpp:208:139:   required from here
canvas/canvas_gl.cpp:208:109: error: cannot call member function ‘bool horizon::Canvas::layer_is_visible(int) const’ without object
   const auto &f = std::find_if(targets.begin(), targets.end(), [t, this](const auto &a)->bool{return a.p==t && layer_is_visible(a.layer);});
                                                                                                              
make: *** [Makefile:419: canvas/canvas_gl.o] Error 1

Keine Ahnung was das genau ist. Und eigenlich ist mein Gentoo-Linux 
schon recht aktuell.

[Frank K. (frank)]

Selbiges Problem habe ich auch, mit der 
34fc55078949d3b2989deb5abf0b0c27fe355a82 ging es noch.

Gruß,
Frank

Edit: Hatte ich, mit 8e1f6aa geht kompilieren wieder.

[Lukas K. (carrotindustries)]

Jetzt baut's wieder mit gcc 6.2.1

[Helmut S. (helmuts)]

Hallo Lukas,
ich habe Probleme beim Leitungverlegen mit Vias.
Ich bekomme es gerade nicht (mehr) hin an einem Stück Leitung - via - 
Leitung zu ziehen..

x Leitung ziehen
v Via setzen
2 auf Lage 2 gehen

Wie jetzt auf Lage 2 weiter machen?
Bei mir fliegt mit LMB oder RMB das Via weg. Das wars dann leider.

Gruß
Helmut

[W.S. (Gast)]

Possetitjel schrieb:
> Hältst Du es für denkbar, dass Deine Ansicht darüber, was ein
> "free EDA package" können muss, NICHT die einzig richtige ist?

Nö.

> Habe ich das richtig verstanden: Es wäre das Beste für Lukas,
> wenn er die Software programmieren würde, die W.S. gerne haben
> will?

Richtig.
Sowas ist nicht wahlfrei - im Gegensatz zu persönlichen Vorlieben, also 
ob man z.B. Brünette mehr mag als Blondinen.

Hier geht's um Softwarequalität und Benutzbarkeit - und die richtet sich 
danach, wie die Anwender damit klarkommen und was sie damit alles machen 
können ohne an die Grenzen zu stoßen. Also am tragfähigen und richtig 
umgesetzten Konzept. Das ist ein absolutes MUSS, sonst wird bis zu 
Lukas' Rente nix rechtes draus.

Mich graust es bei der Gelegenheit lesen zu müssen, daß Lukas selber 
schreibt, daß er kein Konzept hat, weil dieses ja mit der Zeit veralten 
würde.

Arc N. schrieb:
> Warum? Wenn einem Kicad bspw. nicht gefällt, warum sollte man dann dort
> Zeit investieren?

Weil dort bereits einiges an Konzept und Software vorhanden ist, 
selbiges jedoch noch immer auf falsch gelegten Fundamenten steht.

Es wäre allerdings abzuwägen, wieviel Arbeit inzwischen nötig ist, um 
Kicad in die richtige Richtung zu bringen und ob es nicht evtl. 
einfacher ist, selbiges einfach abzureißen und die Baugrube neu 
auszubaggern. Das ist eventuell dann doch ein Grund, was Neues 
aufzuziehen - aber dazu braucht's mehrere Leute oder nen fetten Sponsor 
- und natürlich das festgenagelte Konzept, sonst ist keine 
Zusammenarbeit möglich und jeder macht, was ihm grad einfällt.


Possetitjel schrieb:
> Ich vertrete aber die -- offenbar völlig veraltete -- Meinung,
> dass die Software MIR dienen soll, und nicht umgekehrt ich die
> Software loben, preisen und ihre Schlingen und Windungen besser
> und besser studieren muss.

Nun, ganz meine Ansicht. In diesem Punkt treffen wir uns.

Lukas K. schrieb:
> Warum schreit
> keiner, dass ERC noch vollständig fehlt, man keine differentiellen
> Leitungen routen kann, es keine Thermals in Flächen gibt, oder die
> Darstellung von Pad-Namen im Board noch sehr zu wünschen Übrig lässt?

Ganz einfach: Weil derartige Details einer späteren Maneuverkritik 
vorbehalten sind. Hier geht es (zumindest mir) zu allererst um die 
wirkliche Basis des Ganzen. Wenn man die systematische Herangehensweise 
nicht einhält, geht es einem wie Kicad: katastrophale 
Bibliotheks-Konzeption, keine Annotationen vor oder zurück, aber nen 
Push&Shove-Router basteln wollen.

Lukas K. schrieb:
> Wenn andere Programme (z.B. KiCad) nachwievor einen Schaltplaneditor
> haben, der keine Ahnung von Netzen hat und den Anwender Junctions nach
> Gutdünken platzieren lässt, aber schon dabei sind SPICE-Integration zu
> entwickeln liegt meines Erachtens der Fokus bei der Entwicklung falsch.

Sag ich doch! Sag ich doch die ganze Zeit.

Ein wirklich gutes Konzept hingegen hält locker 20 Jahre. Man sieht das 
bei Eagle, wo selbst krassesten Einflußnahmen von Farnell und AD es 
schwer haben, das Programm kaputt zu machen. OK, AD hat es auf 
nichttechnische Weise jetzt wohl geschafft.

Aber das ist ne andere Baustelle.

Laß dir das Konzept von Eagle ruhig nochmal ganz gründlich durch den 
Kopf gehen: die innere Datenbank, die Skript/Kommandozeile, die 
Tool-Funktionalität. Ja, das sind alles keine Dinge, die an der 
sichtbaren Oberfläche glänzen, aber sie sind wesentlich für die gute 
Funktionalität.

W.S.

[Jörg W. (dl8dtl) (Moderator)]

W.S. schrieb:
> Weil dort bereits einiges an Konzept und Software vorhanden ist,
> selbiges jedoch noch immer auf falsch gelegten Fundamenten steht.

Wenn du das logisch zu Ende denkst, würde es bedeuten, dass man das,
was da ist, sowieso komplett einreißen müsste, um eben neue Fundamente
zu setzen.

Was ist da eigentlich dann der Unterschied zu einem neuen Programm?

Ach ja, wenn schon neues Programm, dann könnte man ihm ja auch einen
neuen Namen geben … wie wär's eigentlich mit "Horizon"?

:-))

[Lukas K. (carrotindustries)]

Helmut S. schrieb:
> Bei mir fliegt mit LMB oder RMB das Via weg. Das wars dann leider.

Ah, das passiert wenn du in den Via-Rules keine Regel oder keine Regel 
mit Padstack hast. Du solltest mindestens eine Via-Regel haben, die auf 
alles matcht, so wie im Anhang.

[Frank K. (frank)]

Es ist mir nun endlich gelungen mein erstes AppImage zu erstellen :-)

Es kann hier herunter geladen werden: 
https://download.opensuse.org/repositories/home:/frank_kunz/AppImage/

dann ausführbar machen und starten. Ich konnte es nicht auf 
verschiedenen Linux Distributionen testen daher keine Garantie dass es 
überall startet.

Das AppImage ist dazu gedacht um horizon testen zu können ohne die 
Software selber kompilieren zu müssen, also nicht für den 
Produktiveinsatz.

Gruß,
Frank

[Helmut S. (helmuts)]

Hallo Lukas,

danke es klappt jetzt. Ich denke so ungefähr habe ich den "Dreh" jetzt
heraus.

Mist, gerade ESC gedrückt und "alles" ist weg. Ich glaube ich sollte
diese ESC-Taste wegmachen. :-)
Bitte diese Taste entschärfen. Die macht mehr kaputt als sie hilft.


Gruß
Helmut

[Possetitjel (Gast)]

W.S. schrieb:

> Possetitjel schrieb:
>> Hältst Du es für denkbar, dass Deine Ansicht darüber,
>> was ein "free EDA package" können muss, NICHT die einzig
>> richtige ist?
>
> Nö.

Naja, an Selbstbewusstsein mangelt es Dir jedenfalls
nicht... :)

>> Habe ich das richtig verstanden: Es wäre das Beste für
>> Lukas, wenn er die Software programmieren würde, die W.S.
>> gerne haben will?
>
> Richtig.
> Sowas ist nicht wahlfrei - im Gegensatz zu persönlichen
> Vorlieben, also ob man z.B. Brünette mehr mag als Blondinen.

Doch -- aber auf einer anderen Ebene.

> Hier geht's um Softwarequalität und Benutzbarkeit - und die
> richtet sich danach, wie die Anwender damit klarkommen [...]

Ja -- aber wo hat Lukas proklamiert, dass Du seine Software
anwenden können sollst?
Solange Lukas der einzige maßgebliche Anwender ist, ist seine
Ansicht bindend. Das muss weder Dir noch mir gefallen, aber
das ist einfach Fakt.

> Mich graust es bei der Gelegenheit lesen zu müssen, daß
> Lukas selber schreibt, daß er kein Konzept hat, weil
> dieses ja mit der Zeit veralten würde.

Naja ... ICH würde es auch anders machen. Lukas macht es
eben so.

Ich stimme Dir ja in der Sache zu -- aber das alles wird
erst dann interessant, wenn Lukas explizit erklärt, dass
seine Software für die Benutzung durch andere Leute gedacht
ist.
In seinem Vortrag gibt er als Motivation nur an: IHM
gefiel die existierende Software nicht, und deshalb hat
er angefangen, seine eigene zu schreiben. Da ist keine Rede
davon, dass Horizon auch FÜR ANDERE LEUTE irgendwie nützlich
und zweckmäßig sein soll.

> Es wäre allerdings abzuwägen, wieviel Arbeit inzwischen
> nötig ist, um Kicad in die richtige Richtung zu bringen
> und ob es nicht evtl. einfacher ist, selbiges einfach
> abzureißen und die Baugrube neu auszubaggern.

Ich denke, dass diese Radikalität der falsche Ansatz ist.
Die Welt ist nicht schwarz/weiss.

> - und natürlich das festgenagelte Konzept,

Konzept: Ja.
Festgenagelt: Nein.

Das Konzept sollte das Rückgrat des Ganzen sein: Tragfähig,
aber dennoch flexibel.

Das kann man nicht "vorher" ein für alle mal festlegen;
das ist ein "moving target".

> sonst ist keine Zusammenarbeit möglich und jeder macht,
> was ihm grad einfällt.

Hmm. Das kenne ich anders.

> Ganz einfach: Weil derartige Details einer späteren
> Maneuverkritik vorbehalten sind. Hier geht es (zumindest
> mir) zu allererst um die wirkliche Basis des Ganzen.

Ja.
Der Punkt ist: Ich vermute, dass Lukas und Du die "wirkliche
Basis des Ganzen" an völlig verschiedenen Stellen seht.

Für mich wäre entscheidend, ob die Software für den Einsatz
in einem Kleinunternehmen geeignet ist. Ausgangspunkte wären
der Datenfluss und die Arbeitsabläufe.
Konnektivität nach außen ("Interoperabilität") wäre für mich
viel wichtiger als jeder Komfort innerhalb der Software.

> Ein wirklich gutes Konzept hingegen hält locker 20 Jahre.

Ich fürchte, Programmierer und Anwender verstehen unter
"Konzept" VÖLLIG unterschiedliche Dinge. Ich glaube, dass
hier das Grundübel liegt.

[Lukas K. (carrotindustries)]

Helmut S. schrieb:
> Bitte diese Taste entschärfen. Die macht mehr kaputt als sie hilft.

In der aktuellen Version tut nun ESC genau dasselbe wie Rechtsklick in 
Tools.

[Helmut S. (helmuts)]

Lukas K. schrieb:
> Helmut S. schrieb:
>> Bitte diese Taste entschärfen. Die macht mehr kaputt als sie hilft.
>
> In der aktuellen Version tut nun ESC genau dasselbe wie Rechtsklick in
> Tools.

Hallo Lukas,
danke habe es gleich ausprobiert. So gefällt mir die Funktion von ESC.

Die nun mögliche Änderung der Farbe der Lagen und die Wahl zwischen 
Umrandung, schraffiert und gefüllt gefällt mir.

Ist es beabsichtigt, dass beim verlegen von Leitungen die Zählweise 1 
top, 2 bot, 3 inner-1 und 4 inner-2 ist? Ich habe damit kein Problem.

Gruß
Helmut

[Lukas K. (carrotindustries)]

Helmut S. schrieb:
> Ist es beabsichtigt, dass beim verlegen von Leitungen die Zählweise 1
> top, 2 bot, 3 inner-1 und 4 inner-2 ist? Ich habe damit kein Problem.

Jep, das war so beabsichtigt, damit man Top und Bottom immer gleich 
bequem und schnell erreichen kann.

[Helmut S. (helmuts)]

Hallo Lukas,

ich würde gerne mal im PCB die Hintergrundfarbe auf schwarz stellen.
Kann ich das in einer Config-Datei einstellen oder ist das hart kodiert?

Gruß
Helmut

[Lukas K. (carrotindustries)]

Helmut S. schrieb:
> Hallo Lukas,
>
> ich würde gerne mal im PCB die Hintergrundfarbe auf schwarz stellen.
> Kann ich das in einer Config-Datei einstellen oder ist das hart kodiert?
>
> Gruß
> Helmut

Das ist momentan hardcoded.

War nur eine Frage der Zeit, bis sich das jemand wünscht. Ich hab' mir 
das auch schon gelegentlich gewünscht, war bis jetzt aber immer zu faul 
das zu implementieren. Im EEVBlog-Forum wünschte man sich auch noch 
einstellbare Tastenkürzel.

Wird so langsam wohl mal Zeit, dass der interaktive Manipulator einen 
Einstellungsdialog und Config-Datei bekommt...

[Helmut S. (helmuts)]

Lukas K. schrieb:
> Helmut S. schrieb:
>> Hallo Lukas,
>>
>> ich würde gerne mal im PCB die Hintergrundfarbe auf schwarz stellen.
>> Kann ich das in einer Config-Datei einstellen oder ist das hart kodiert?
>>
>> Gruß
>> Helmut
>
> Das ist momentan hardcoded.
> ...
> War nur eine Frage der Zeit, bis sich das jemand wünscht.

Hallo Lukas,

Ich wünsche mir die Möglichkeit eine schwarzen Hintergrund zu haben. Ich 
finde den blauen Hintergrund anstrengend.

Außerdem wünsche ich mir die die Möglichkeit Punkte statt '+' für das 
Grid zu wählen.

Der erste Punkt mit dem schwarzen Hintergrund wäre mir jetzt erstmal 
wichtiger als der mit den Gridpunkten.

Gruß
Helmut

[Stefan S. (Gast)]

Helmut S. schrieb:
> Ich wünsche mir die Möglichkeit eine schwarzen Hintergrund zu haben. Ich
> finde den blauen Hintergrund anstrengend.

Du verwechselst das hier womöglich mit einem Wunschkonzert? Was Lukas 
sich wünscht ist wahrscheinlich eher konstruktive Mitarbeit -- muss ja 
nicht gleich perfekter C++ Code sein, ein paar gute, ausformulierte 
Ideen und Algorithmen könnten wir auch gebrauchen...

[Helmut S. (helmuts)]

Stefan S. schrieb
> Du verwechselst das hier womöglich mit einem Wunschkonzert?

Ich finde die Tester und Anwender sollten auch ihre Erfahrungen und 
Wünsche einbringen dürfen. Natürlich habe ich erst mal kein Problem, 
wenn Lukas seiner Vision die er für dieses Programm hat treu bleibt.

[Stefan S. (Gast)]

Ja gut, ich sollte in der Tat auch nicht für Lukas sprechen...

Allerdings, bevor Dinge wie Farbwünsche wirklich Sinn machen sind wohl 
noch einige Tausend Stunden Arbeit nötig. Und Du hattest ja noch einige 
andere Wünsche geäussert.

Was meinst Du Helmut, sollte man Bauteile tatsächlich in einer Datenbank 
verwalten, oder doch besser als einzelne Dateien? Die Frage stelle ich 
mit gerade, da ich die Kompatibilität mit dem gEDA/PCB Format wohl 
aufgeben werde.

Und dann ist da natürlich die Frage, wie man Bauteile am besten 
definiert. Wie bei gEDA, wo alles mit einem Symbol startet, dem man dann 
u.a. den Footprint hinzufügt --  das gefiel mir nie so recht.

Momentan denke ich an etwas, wo man mit den "Pins" beginnt, also etwa 
"VCC", "VEE", "+", "-", "Out" für einen OP. Dann irgendein Mapping um 
die Pins auf Schaltplansymbole und Footprints abzubilden., wobei 
natürlich Symbol- und Footprint-Varianten möglich sind. Etwa auch 
Symbole mit und ohne Power Pins.

Ah -- Horizon hat gerade erfolgreich zuende kompiliert, hat aber ein 
paar Minuten dedauert. Mal sehen ob ich es starten kann.

[W.S. (Gast)]

Jörg W. schrieb:
> Wenn du das logisch zu Ende denkst, würde es bedeuten, dass...

Tja. Irgendwann ist quasi der PONR überschritten - jedenfalls bei der 
Fliegerei. Auch bei C sieht man das deutlich. Ich hatte das bei Kicad 
schon vor geraumer Zeit angemahnt, denk mal an die ewigen Diskussionen 
mit Bernd Wiebus, der noch immer nicht einsehen will, daß man in 
Schaltplänen logische Symbole hat und nicht Abbilder von DIL-Gehäusen 
und der partout nicht einsehen will, daß die Konsistenz zwischen SCH und 
BRD sowie Symbolen und Footprints was ganz Essenzielles ist. Kann jeder 
nachlesen in der Historie dieses Boards.

Aber gehe du mal lieber nicht einfach nur mal so mit "Wenn..Dann"-Sätzen 
an das Problem heran. Womöglich kann man ne Menge mittleren Zeuges grad 
bei Kicad durchaus retten - aber dazu müßte man die Nase tief in die 
Quellen stecken - und ich tu's nicht, ich hab ja Eagle. Andererseits 
hat man durchaus ein Gefühl von Verantwortung dahingehend daß man den 
Leuten, die grad dabei sind Bockmist zu bauen, der hinterher nur noch 
schwer bis garnicht korrigierbar ist, SAGEN muß, daß sie grad Bockmist 
bauen. OK, manche fühlen sich dabei in ihrer Genialität auf den Schlips 
getreten - aber da muß unsereiner halt durch.

W.S.

[W.S. (Gast)]

Possetitjel schrieb:
> Ich fürchte, Programmierer und Anwender verstehen unter
> "Konzept" VÖLLIG unterschiedliche Dinge. Ich glaube, dass
> hier das Grundübel liegt.

DAS ist eigentlich schon seit langem völlig klar und eigentlich auch 
jedermann bekannt. Geht mir im Prinzip als Programmierer und Anwender 
auch so: Die Sichtweise als Programmierer unterscheidet sich diametral 
von der Sichtweise des Anwenders. Und ganz besonders dann, wenn die 
Logiken auseinanderfallen. Siehe die Programmiersprache C oder der 
"WISSENSCHAFTLICHE" Sozialismus. Wenn man die Fundamente erstmal schief 
und falsch gelegt hat, kann man ganz wunderbar ein ganz schiefes und 
falsches, aber in sich konsistentes und schein-logisches Gebäude drauf 
errichten. Als Anwender (oder Bewohner) sieht man das anschließend sehr 
sehr SEHR viel anders.

Was meinst du, weswegen ich hier so penetrant darauf herumhacke daß es 
allen anderen graust, zu allererst ein wirklich tragfähiges Konzept 
auszuarbeiten und schriftlich zu fixieren? Das ist überhaupt kein Spaß!

W.S.

[Stefan S. (Gast)]

Und es läuft, Lukas! Ich sehe es mir dann in den nächsten Wochen mal 
genauer an.

Ich bin gestern übrigens mal angefangen meinen Schaltplaneditor von Ruby 
nach Nim zu portieren. Sind leider doch ganze 6000 Zeilen, wird also 
etwas dauern.

[W.S. (Gast)]

Lukas K. schrieb:
> Das ist momentan hardcoded.
>
> War nur eine Frage der Zeit, bis sich das jemand wünscht. Ich hab' mir
> das auch schon gelegentlich gewünscht, war bis jetzt aber immer zu faul
> das zu implementieren. Im EEVBlog-Forum wünschte man sich auch noch
> einstellbare Tastenkürzel.
>
> Wird so langsam wohl mal Zeit, dass der interaktive Manipulator einen
> Einstellungsdialog und Config-Datei bekommt...

Merkst du jetzt was?

Mit meinem Rufen nach dem Konzept komme ich mir inzwischen vor wie Cato 
d.Ä.

W.S.

[Possetitjel (Gast)]

Stefan S. schrieb:

> Was meinst Du Helmut, sollte man Bauteile tatsächlich in
> einer Datenbank verwalten, oder doch besser als einzelne
> Dateien?

In einzelnen Dateien.

Wenn die EDA-Software die Bauteildaten aus einzelnen Dateien
im Filesystem liest, gibt es eine Chance, eine externe
Datenbank zu basteln, die die Bauteildaten verwaltet und
passend für mehrere EDA-Pakete exportieren kann.

Wenn jede EDA-Software seine eigene Datenbank mitbringt,
ist Austauschbarkeit der Daten noch weiter erschwert.


> Die Frage stelle ich mit gerade, da ich die Kompatibilität
> mit dem gEDA/PCB Format wohl aufgeben werde.

Schade. Noch jemand, dem Interoperabilität egal ist. Naja.

[Abdul K. (ehydra)]

Im YT-Video erwähnt er eine SQLlite-Datenbank, die er aufbaut aus 
JSON-Dateien.
Hm, also wenn Helmut sich die Sache näher ansieht, scheint es 
interessant zu sein und einen gewissen ersten Fortschritt inne zu haben.
Nur wie lange wird die Sache weiterentwickelt? Lukas ist 23 und in dem 
Alter hat man abwechselnde Interessen.
Ansonsten kann ich nur sagen, zumindest im Video sieht es schon gut aus.

SkyOS war auch mal erwartungsvoll, da scheint die Frau mit Kind alles 
gestoppt zu haben.

Ansonsten ist Entwiclung als Einmann-Team immer die effizienteste Form. 
Bis es dann eine gewisse Größe überschreitet. Falls es zu diesem 
Zeitpunkt dann zu unstruktiert ist, stirbt es unmittelbar.

[Stefan S. (Gast)]

Possetitjel schrieb:
> In einzelnen Dateien.
>
> Wenn die EDA-Software die Bauteildaten aus einzelnen Dateien
> im Filesystem liest, gibt es eine Chance, eine externe
> Datenbank zu basteln, die die Bauteildaten verwaltet und
> passend für mehrere EDA-Pakete exportieren kann.
>
> Wenn jede EDA-Software seine eigene Datenbank mitbringt,
> ist Austauschbarkeit der Daten noch weiter erschwert.
>

Ich hätte jetzt eher erwartet, dass die meisten eine Datenbank 
bevorzugen. Wobei ich bisher wenig Erfahrung mit Datenbanken habe, aber 
so schwierig ist deren Nutzung wohl nicht.

>> Die Frage stelle ich mit gerade, da ich die Kompatibilität
>> mit dem gEDA/PCB Format wohl aufgeben werde.
>
> Schade. Noch jemand, dem Interoperabilität egal ist. Naja.

Nein, Interoperabilität war mir schon wichtig, daher hatte meine Ruby 
Version des Schaltplaneditors ja das gEDA-Format verwendet, und der 
Rubberband-Router das gEDA/PCB Format. Blos, wer benutzt denn momentan 
noch gEDA/PCB? Und selbst den gEDA/PCB Leuten gefiel ihr Format nicht 
wirklich.

Mit einem bestimmten Dateiformat kompatibel zu bleiben ist nunmal ein 
Mehraufwand und eine Einschränkung. Als ich mit den Programmen vor 
einigen Jahren anfing, da gab es noch einige mehr gEDA/PCB Nutzer und 
ich hatte gedacht, dass von deren Seite auch etwas Interesse vorhanden 
wäre.

Das KiCad Format kenne ich nicht. Lukas Dateiformate werde ich mir aber 
mal ansehen.

Und Konverter kann man ja immer Schreiben, wenn es ein offenes Format 
ist. Das können sogar Leute mit wenig Programmierkenntnissen in der 
Sprache ihrer Wahl tun.

Bei dem PCB-Format frage ich mich, wie weit man sich am XGerber-Format 
orientieren sollte. Natürlich nicht 1:1, XGerber ist ein LowLevel 
Format. Aber so ganz grundsätzlich kann man sich schon daran 
orientieren. Dass es etwa im wesentlichen Linien, Kreisbögen und 
Polygone gibt.

[Jörg W. (dl8dtl) (Moderator)]

W.S. schrieb:
> ich tu's nicht, ich hab ja Eagle

Dann bleib doch einfach dabei.

Ob andere „Bockmist“ bauen, diese Einschätzung darfst du gern mehr als
nur dir überlassen.  Auch wenn ich Horizon im Moment noch nicht selbst
ausprobiert habe, scheint mir die Menge an Diskussion, die hier
mittlerweile entsteht, keineswegs in diese Richtung zu gehen …

An deinen Ansprüchen gemessen, würdest du vermutlich auch Altium
Designer als „Bockmist“ abtun, weil es sich nicht so verhält wie Eagle.

[Stefan S. (Gast)]

Abdul K. schrieb:
> Ansonsten ist Entwiclung als Einmann-Team immer die effizienteste Form.
> Bis es dann eine gewisse Größe überschreitet. Falls es zu diesem
> Zeitpunkt dann zu unstruktiert ist, stirbt es unmittelbar.

Man sollte den Code unbedingt klein halten, dann können sich andere im 
Prinzip einarbeiten. KiCad und LibreCad haben wohl etwa beide ca. eine 
Million Zeilen C++ Code. Das ist schon fast Wahnsinn.

Weiter oben hatte wohl jemand geschieben, dass Lukas momentan 27k Zeilen 
hat. Ich denke das geht noch, aber viel mehr sollte es auch nicht 
werden.

[Abdul K. (ehydra)]

Da wird ganz sicher Faktor 10 noch rein gehen. Ein solches Programm ist 
schon heftig, wenn es denn auch die ganzen Feinheiten implementiert.

[Ratzfatz (Gast)]

Stefan S. schrieb:
> Weiter oben hatte wohl jemand geschieben, dass Lukas momentan 27k Zeilen
> hat. Ich denke das geht noch, aber viel mehr sollte es auch nicht
> werden.

Wie soll das denn bitte funktionieren, wenn man die Funktionalität 
erweitern will?

[Stefan S. (Gast)]

Ratzfatz schrieb:
> Wie soll das denn bitte funktionieren, wenn man die Funktionalität
> erweitern will?

Aufräumen!

[Lukas K. (carrotindustries)]

Uff, so viel auf einmal:

Irgendeine Art von "Einstellungen" war früher oder später eh geplant. Im 
letzten Jahr Entwicklung, in dem einziger "Anwender" ich war, war das 
eben nicht so wichtig. Jetzt wo auch andere Leute mit anderen Vorlieben 
das Programm benutzen wollen, braucht's das eben. Wenn Dialog und 
Infrastruktur erstmal da sind, finden sich auch recht schnell weitere 
Zwecke, die sinnvoll zu nutzen.

Einzeldateien oder Datenbank? Beides! Einzeldateien sind gut geeignet um 
versionskontrolliert verwaltet zu werden, allerdings sucht's sich darin 
schlecht. Mit Datenbanken ist es genau umgekehrt. Daher sind die 
Primärquellen Einzeldateien, deren Metadaten dann lokal in eine 
Datenbank importiert werden. Die ganzen "Browser" im pool manager für 
Units, etc. sind dann eine recht dünne Schicht GUI über SQL.

Das Dateiformat ist jetzt nichts besonderes. Die C++-Klassen werden 
einfach nach JSON serialisiert.

Abdul K. schrieb:
> Ansonsten kann ich nur sagen, zumindest im Video sieht es schon gut aus.
Jetzt, einige Monate später, ist's noch besser ;)

[Abdul K. (ehydra)]

Dann müßte er wohl von C++14 auf Forth umsteigen. Könnte mir vorstellen, 
daß er von dieser Sprache bei seinem Alter noch nie hörte.

[Michel M. (elec-deniel)]

Gute Arbeit,
weiter so
... vielleicht noch die Leiterlängen dazunehmen :-)

[Stefan S. (Gast)]

Lukas K. schrieb:
> Das Dateiformat ist jetzt nichts besonderes. Die C++-Klassen werden
> einfach nach JSON serialisiert.

ja, so wollte ich es jetzt auch machen. Damit macht man sich das Leben 
sehr einfach -- aber das ist dann natürlich zu nichts kompatibel.

Eines noch: Die executables sind ja riesig! Gut, da ist wohl sämtlicher 
Debugging-Code enthalten, aber trotzdem:

$ ls -l ../horizon/horizon-prj-mgr 
-rwxr-xr-x 1 stefan stefan 63936488 Oct 28 20:54 ../horizon/horizon-prj-mgr
stefan@nuc ~/pet $ ls -l ../horizon/horizon-imp 
-rwxr-xr-x 1 stefan stefan 176220480 Oct 28 20:53 ../horizon/horizon-imp

[Jörg W. (dl8dtl) (Moderator)]

Stefan S. schrieb:
> Die executables sind ja riesig!

Frag doch mal lieber mit "size" statt "ls -l".  Ansonsten bekommst
du die Größe aller Debug-Symbole (Strings, Namen etc.) mit.

[Stefan S. (Gast)]

Ach so...

$ size ../horizon/horizon-prj-mgr 
   text     data      bss      dec      hex  filename
2624115     9736    11344  2645195   285ccb  ../horizon/horizon-prj-mgr
stefan@nuc ~/pet $ size ../horizon/horizon-imp 
   text     data      bss      dec      hex  filename
5954953    41376    32568  6028897   5bfe61  ../horizon/horizon-imp

[Jörg W. (dl8dtl) (Moderator)]

Immer noch nicht ganz klein, aber drastisch kleiner als die Binaries. ;)

[Possetitjel (Gast)]

W.S. schrieb:

> Ich hatte das bei Kicad schon vor geraumer Zeit angemahnt,
> denk mal an die ewigen Diskussionen mit Bernd Wiebus, der
> noch immer nicht einsehen will, daß man in Schaltplänen
> logische Symbole hat und nicht Abbilder von DIL-Gehäusen

Ja, überwiegend ist das so.

> und der partout nicht einsehen will, daß die Konsistenz
> zwischen SCH und BRD sowie Symbolen und Footprints was
> ganz Essenzielles ist.

Wie das? Das (allgemeine) Symbol eines npn-Transistors hat
keinen Footprint. Und -- nein, ich will NICHT wählen müssen,
ob das ein BF199 oder eine 2N3904 sein soll, wenn ich den
SCHALTPLAN zeichne.

> Womöglich kann man ne Menge mittleren Zeuges grad bei
> Kicad durchaus retten - aber dazu müßte man die Nase tief
> in die Quellen stecken - und ich tu's nicht, ich hab ja
> Eagle.

Naja, das verstehe ich -- aber dann hat es wenig Sinn, zu
meckern.

> Andererseits hat man durchaus ein Gefühl von Verantwortung
> dahingehend daß man den Leuten, die grad dabei sind Bockmist
> zu bauen, der hinterher nur noch schwer bis garnicht
> korrigierbar ist, SAGEN muß, daß sie grad Bockmist bauen.

Das Problem des Rechthabers ist nicht, dass er Unrecht hätte --
das Problem des Rechthabers ist, dass ihm niemand mehr zuhört!

Außerhalb akademischer Kreise will es niemand haben, dass Du
(nur) ein PROBLEM aufwirfst. Entweder Du kannst die Lösung für
das Problem umsetzen, oder Du spielst das Spiel mit, das andere
vorgeben, egal, wie falsch Dir das scheint.
Einen Mittelweg sehe ich nicht.

[Lukas K. (carrotindustries)]

In der aktuellen Version funktioniert nun dank gepatchtem Gtk die 
3D-Vorschau auch auf Windows.

Possetitjel schrieb:
> Und -- nein, ich will NICHT wählen müssen,
> ob das ein BF199 oder eine 2N3904 sein soll, wenn ich den
> SCHALTPLAN zeichne.
Horizon kann genau das. Man kann ohne "Part" anfangen und später mit 
"assign Part" dem "Component" ein "Part" zuweisen. Nachträglich kann man 
natürlich das Part auch austauschen.

[Mac G. (macgyver0815)]

Ich habe hier nicht alles gelesen, aber bezüglich der Simulation wollte 
ich noch kurz was einwerfen:

Obwohl ich Altium zur Verfügung habe und das auch Simulieren kann, nutze 
ich noch immer viel lieber LTSpice für analoge Geschichten.
Man kann sowieso nur selten die komplette Schaltung simulieren - man 
simuliert nur die kritischen Teile davon.
Das sieht dann teilweise auch ganz anders aus als im Schaltplan fürs 
Layout weil man viel experimentiert...

Also es ist absolut nicht essentiell da Spice einzubauen. Das geht auch 
extern.

Für HF-Kram gibts dann wieder andere Tools...

[Possetitjel (Gast)]

Stefan S. schrieb:

> Possetitjel schrieb:
>> In einzelnen Dateien.
>>
>> Wenn die EDA-Software die Bauteildaten aus einzelnen Dateien
>> im Filesystem liest, gibt es eine Chance, eine externe
>> Datenbank zu basteln, die die Bauteildaten verwaltet und
>> passend für mehrere EDA-Pakete exportieren kann.
>>
>> Wenn jede EDA-Software seine eigene Datenbank mitbringt,
>> ist Austauschbarkeit der Daten noch weiter erschwert.
>>
>
> Ich hätte jetzt eher erwartet, dass die meisten eine Datenbank
> bevorzugen.

Das tue ich ja auch.

Ich will nur keine Datenbank, die spezifisch für DIESE EDA-SOFTWARE
ist!

Ich will genausowenig, dass die EDA-Software eine eigene Versions-
verwaltung mitbringt. Ich will, dass die Userdaten, die ich mit
der EDA-Software produziere, mit DER externen Versionsverwaltung
verwaltet werden können, die ICH auswähle.

> Nein, Interoperabilität war mir schon wichtig, daher hatte
> meine Ruby Version des Schaltplaneditors ja das gEDA-Format
> verwendet,

Ohh. Deinen Schaltplaneditor habe ich irgendwie übersehen.

> Mit einem bestimmten Dateiformat kompatibel zu bleiben ist
> nunmal ein Mehraufwand und eine Einschränkung.

Ja:
Kompatibilität ist eine Einschränkung für den Programmierer.
Inkompatibilität ist eine Einschränkung für den Nutzer.

Wenn wir uns die Unmenge inkompatibler Software ansehen, wissen
wir, wer das Sagen hat.

> Als ich mit den Programmen vor einigen Jahren anfing, da gab
> es noch einige mehr gEDA/PCB Nutzer und ich hatte gedacht,
> dass von deren Seite auch etwas Interesse vorhanden wäre.

Ja... das war wohl einfach Pech.

> Und Konverter kann man ja immer Schreiben, wenn es ein
> offenes Format ist. Das können sogar Leute mit wenig
> Programmierkenntnissen in der Sprache ihrer Wahl tun.

Ja, das ist ein Anfang, und darauf wird es wohl vorläufig
hinauslaufen.

Der nächste Schritt wäre aus meiner Sicht, dass es eine
generische Software gibt, die z.B. Schaltplansymbole und
Footprints verwaltet und diese in allen in Frage kommenden
Formaten exportieren kann (gEDA, KiCAD, horizon, Fritzing...:)

> Bei dem PCB-Format frage ich mich, wie weit man sich am
> XGerber-Format orientieren sollte. Natürlich nicht 1:1,
> XGerber ist ein LowLevel Format. Aber so ganz grundsätzlich
> kann man sich schon daran orientieren. Dass es etwa im
> wesentlichen Linien, Kreisbögen und Polygone gibt.

Hauptpunkt ist mMn das abstrakte Datenmodell, das dahinter-
steht. Wenn die einen eine turing-vollstände Beschreibungs-
sprache nehmen und die anderen Bitmaps, dann werden auch
Konverter zur Herausforderung.

[Possetitjel (Gast)]

Jörg W. schrieb:

> Ob andere „Bockmist“ bauen, diese Einschätzung darfst du
> gern mehr als nur dir überlassen.

Nun... W.S. steht zumindest nicht völlig allein mit seiner
Meinung.
Auch Lukas scheint dieser Ansicht zu sein -- sonst hätte er
sein Projekt ja nicht angefangen... :)

> An deinen Ansprüchen gemessen, würdest du vermutlich auch
> Altium Designer als „Bockmist“ abtun,

Zum Teil, ja.

> weil es sich nicht so verhält wie Eagle.

Nee, deshalb nicht.

[Jörg W. (dl8dtl) (Moderator)]

Possetitjel schrieb:
> Auch Lukas scheint dieser Ansicht zu sein -- sonst hätte er sein Projekt
> ja nicht angefangen... :)

W.S. bezog diese seine Kritik allerdings auf Lukas.

> Nee, deshalb nicht.

Bei W.S. schon, ist ja nicht das erste Mal, dass er das propagiert.
Alles, was nicht den gleichen Workflow hat wie Eagle ist bei ihm halt
„Bockmist“.  Das ist zumindest der Eindruck, den ich über die Jahre
gewonnen habe.

[Helmut S. (helmuts)]

Lukas schrieb:
> In der aktuellen Version funktioniert nun dank gepatchtem Gtk die
3D-Vorschau auch auf Windows.


Hallo Lukas,

das sieht ja richtig gut aus. Speziell das "Explode" finde ich cool. Auf 
diese Art, kann man sehr anschaulich zeigen was in der Leiterplatte 
passiert.  Eine echte Bereicherung speziell auch für den 
Ausbildungsbereich. Auf dem Bildschirm sieht das durch die Möglichkeit 
die Platine in 3D zu drehen/kippen/schieben noch viel schöner aus.

Danke nochmals für die Bereitstellung von Binaries für Windows. Damit 
bist du anderen Open-Source Projekten weit voraus. Bei Octave hat es 15 
Jahr gedauert bis es offizielle Windows-Binaries gab.

Gruß
Helmut

[Helmut S. (helmuts)]

Frank K. schrieb:
> Es ist mir nun endlich gelungen mein erstes AppImage zu erstellen :-)
>
> Es kann hier herunter geladen werden:
> https://download.opensuse.org/repositories/home:/frank_kunz/AppImage/
>
> dann ausführbar machen und starten. Ich konnte es nicht auf
> verschiedenen Linux Distributionen testen daher keine Garantie dass es
> überall startet.
>
> Das AppImage ist dazu gedacht um horizon testen zu können ohne die
> Software selber kompilieren zu müssen, also nicht für den
> Produktiveinsatz.
>
> Gruß,
> Frank

Hallo Frank,

Ich habe heute eines deiner Iamges auf Ubuntu 17.10 gestart. Es geht ein 
Fenster von horizon auf und dann kommt in einer box die Fehlermeldung
Gtk-Message: Failed to load module "canberra-gtk-module".

Kann jemand einem Linux-Laien wie mir sagen wie und von wo ich das 
fehlende Gtk installieren kann. Auf der Entwickler-Webseite von Gtk gibt 
es nur "sourcen" zum selber kompilieren.

Gruß
Helmut

[Helmut S. (helmuts)]

Ubuntu 17.10

Bin jetzt einen Schritt weiter.
GTK3 von hier installiert.
https://launchpad.net/ubuntu/bionic/amd64/gir1.2-gtk-3.0/3.22.25-0ubuntu1

Die Fehlermeldung ist jetzt weg.Ich kann das Demo-Layout von Lukas laden 
und bearbeiten.

Neue Probleme:
1.
Die Planes werden trotz "Update Planes" nicht gefüllt dargestellt.
Ist das ein Problem meiner Grafikkarte (GTX260)?

2.
3D Ansicht
Beim Anklicken von 3D zerbröselt es die Grafik im Layoutfenster. Fehlt 
dafür noch eine weitere Software?

[Frank K. (frank)]

Hallo Helmut,

Die Idee der AppImages ist dass Du nichts zusätzlich installieren musst, 
das Image sollte alle nötigen libs, etc. enthalten. Ich habe 
canberra-gtk-module noch hinzugefügt, der Build lauft gerade. Sollte so 
bis in ein paar Minuten fertig sein falls Du es noch mal testen 
möchtest. Zu den neuen Problemen (update planes, 3D zerbröseln) kann ich 
noch nicht viel sagen, vielleicht fehlt noch eine lib welche für die 
korrekte Darstellung benötigt wird. Ich versuche das noch mal mit einem 
ubuntu 17.10 in einer virtualbox nachzustellen.

Gruß,
Frank

[Mike J. (linuxmint_user)]

Leute, Leute schrieb:
> Nach ein paar Jahren ist die Lust
> dann weg und zurück bleibt eine Baustelle

... so wie es auch bei Eagle ist.

Ich dachte echt dass die irgend wann mal ein paar Features hinzutun 
werden, aber da ist ja seit Jahren nichts mehr wirklich passiert.
Die wollen das aktuelle Programm so verkaufen wie es ist weil ihnen die 
Lust fehlt etwas zu verändern.
(die Veränderungen seit 4.16 sind lächerlich)

Ich würde mir gerne auf zwei Monitoren jeweils eine Ebene anzeigen 
lassen und wenn ich auf einer etwas verschiebe, dann sehe ich das auf 
beiden Monitoren.
Wenn man mehrere Lagen hat wäre das eindeutig übersichtlicher.

Wenn ich mit der Maus irgend wo lang gehe wäre es schön wenn die 
entsprechenden Teile, welche reagieren wenn man dann auf die Maustaste 
drückt vorher aufleuchten, dann sieht man schon vorher welche 
Leitung/Bauteil der Mauszeiger im Fokus hat und welche dann beim Klick 
markiert ist.

[Jörg W. (dl8dtl) (Moderator)]

Mike J. schrieb:
> ... so wie es auch bei Eagle ist.

Bitte: das gehört nun wirklich nicht hierher.  Zu Eagle gibt's genug
Threads.

[Stefan S. (Gast)]

Mike J. schrieb:
> Ich würde mir gerne auf zwei Monitoren jeweils eine Ebene anzeigen
> lassen und wenn ich auf einer etwas verschiebe, dann sehe ich das auf
> beiden Monitoren.
> Wenn man mehrere Lagen hat wäre das eindeutig übersichtlicher.
>

Ja, so ist es ja bei vielen Texteditoren, etwa auch bei meinem Nim 
Editor: Man kann den gleichen Text in mehreren Fenstern darstellen, 
ändert man in einem Fenster etwas, wird das auch in den anderen Fenstern 
sichtbar. Das kann man ja auch bei der Platinenansicht machen. Ob man da 
zwei Monitore braucht? Bei den aktuellen 4k Monitoren hat man ja schon 
viel Inhalt auf einem Bildschirm, etwa drei Fenster nebeneinander. Ich 
denke GTK unterstützt auch Mehrmonitorbetrieb, so dass  man das machen 
kann. Ich habe momentan aber nur einen 4K Monitor. Bei mehr als einem 
muss man den Kopf immer so viel drehen, das behagt mir persönlich nicht 
so sonderlich.

> Wenn ich mit der Maus irgend wo lang gehe wäre es schön wenn die
> entsprechenden Teile, welche reagieren wenn man dann auf die Maustaste
> drückt vorher aufleuchten, dann sieht man schon vorher welche
> Leitung/Bauteil der Mauszeiger im Fokus hat und welche dann beim Klick
> markiert ist.

Ja, das würde ich wohl auch so machen. Bei meinem Schaltplaneditor war 
es ja schon so, dass Elemente angehoben mit Schatten dargestellt werden, 
wenn der Mauszeiger über ihnen schwebt.

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Frank K. schrieb:
> Es ist mir nun endlich gelungen mein erstes AppImage zu erstellen :-)

Kannst Du ein kleines Beispielprojekt in dem Appimage versenken, so dass 
man direkt spielen kann ohne sich zunaechst mit den Pools 
auseinandersetzten zu muessen?

Danka

[Mike J. (linuxmint_user)]

:-D

Hab das Programm gerade getestet.

Habe nur den Pool hinzugefügt und dann mein erstes Projekt angefangen.
Es wäre schön wenn dieser Pool sich beim Start automatisch in das 
Verzeichnis lädt aus dem ECAD ausgeführt wird.

home.../Programme/ecad/

In dem Verzeichnis habe ich die App "horizon-...-x86_64.AppImage" und 
den Pool abgelegt.

- Bei der Auswahl der Bauteile wäre es schön wenn man eine Darstellung 
des entsprechenden Schaltsymbols sehen könnte, damit man weiß was man 
gerade in der Hand hält.

- Es ist etwas komisch dass bei den Widerständen schon Werte stehen.
- Die Bauteilliste könnte in Baugruppen unterteilt sein, zum Beispiel 
Transistoren, LEDs, Versorgungssymbole (GND, Vcc, +3.3V ...), 
Steckverbinder, Chips, Widerstände usw.

- Jetzt fehlt die Leiste (mit dem Stift, spiegeln des Bauteils, Move, 
Copy usw.) welche es bei Eagle gibt, momentan verbinde ich die Pins im 
Schaltplan indem ich die Pins aneinander führe. Habe ich da etwas 
übersehen?

- Es ist etwas nervig dass man zum bewegen der Bauteile immer den 
"Move"-Knopf drücken muss.

- Es wäre besser wenn sich das Bauteil nach einem Klick auf Move im 
Schaltungseditor direkt unter dem Mauszeiger befindet. (also die Mitte 
des Bauteils direkt unter dem Mauszeiger plazieren)
Momentan ist das Bauteil dann teilweise noch sehr weit verschoben zum 
Mauszeiger.

[Stefan S. (Gast)]

Uwe B. schrieb:
> Danka

Are you not able to open the example project?

See bottom of this page:

https://github.com/carrotIndustries/horizon/wiki/Getting-started

[Stefan S. (Gast)]

Mike J. schrieb:
> - Bei der Auswahl der Bauteile wäre es schön wenn man eine Darstellung
> des entsprechenden Schaltsymbols sehen könnte, damit man weiß was man
> gerade in der Hand hält.

Ja, aber wie macht man das konkret? Wo soll die Preview-Area angeordnet 
sein? Bei gschem hatten sie den Preview zum Schluss in den 
Dateiauswahldialog integriert, das gefiel mir auch nicht sonderlich.

>
> - Es ist etwas nervig dass man zum bewegen der Bauteile immer den
> "Move"-Knopf drücken muss.

Ist das wirklich noch so? Nach meiner Meinung sollte möglist alles 
funktionieren, ohne das man spezielle Tools anwählen muss. Verschieben 
z.B. einfach: Maus über Bauteil, Knopf Drücken und Bewegen. Oder neue 
Leitung: Maus über Pin, Knopf drücken und loslassen, und die Leitung 
hängt an der Maus. Maus über Text, Mausrad dreht den Text. Maus über 
Bauteil, Mausrad dreht Bauteil. Maurad über freier Fläche: Zoom. Usw. 
Beim Schaltplaneditor hatte ich soweit alles hinbekommen, dass man 
praktisch fast nie das Tool wechseln muss. Beim Layouteditor sollte es 
möglichst ähnlich sein, da müsste man aber über die Konketisierung 
nachdenken.

[Stefan S. (Gast)]

Wobei ich gerade sehe, ich hatte ja sogar die Bedienung aufgeschrieben: 
Unter Usage:

http://ssalewski.de/PetEd.html.en

Soweit ich mich errinnere ging das wirklich recht gut. Die 
Programmierung war zwar etwas kniffelig, aber das sollte Lukas 
hinbekommen.

[Possetitjel (Gast)]

Stefan S. schrieb:

> Wobei ich gerade sehe, ich hatte ja sogar die Bedienung
> aufgeschrieben:
> Unter Usage:
>
> http://ssalewski.de/PetEd.html.en
>
> Soweit ich mich errinnere ging das wirklich recht gut.

Ich bin gerade dabei, das mal auszuprobieren. Allerdings
habe ich das Problem, dass GTK3 notwendig, aber auf meiner
Kiste nicht verfügbar ist; das dauert also noch.
Die Version von 2012 startet.

[Stefan S. (Gast)]

Possetitjel schrieb:
> Ich bin gerade dabei, das mal auszuprobieren.

Das würde ich jetzt nicht unbedingt machen.

Gut, bei mir läuft es noch, ruby-gnome2 gibt aber einige 
Debugging-Meldungen. Und ich kann auch keinen Schaltplan öffnen, da ich 
gEDA nicht mehr installiert habe, und damit die Symbole nicht vorhanden 
sind. Start mit leerem Plan einfach mit "ruby peted.rb" geht bei mir, 
oder auch mit einem der beiliegenden Symbole.

Nun ja, geschrieben hatte ich es 2011 oder 2012 -- ist eben schon lange 
her...

[Lukas K. (carrotindustries)]

Helmut S. schrieb:
> 3D Ansicht
> Beim Anklicken von 3D zerbröselt es die Grafik im Layoutfenster. Fehlt
> dafür noch eine weitere Software?

Kannst du mal einen Screenshot davon machen? Die OpenGL-Unterstützung 
von Gtk ist noch recht neu und recht wenig Software verwendet die 
derzeit ernsthaft. Insofern sind da bugs nicht verwunderlich...

Mike J. schrieb:
> Wenn ich mit der Maus irgend wo lang gehe wäre es schön wenn die
> entsprechenden Teile, welche reagieren wenn man dann auf die Maustaste
> drückt vorher aufleuchten, dann sieht man schon vorher welche
> Leitung/Bauteil der Mauszeiger im Fokus hat und welche dann beim Klick
> markiert ist.

Ist bei horizon so, wenn du im "hover select"-Modus (esc-Taste drücken) 
bist.

Uwe B. schrieb:
> Kannst Du ein kleines Beispielprojekt in dem Appimage versenken, so dass
> man direkt spielen kann ohne sich zunaechst mit den Pools
> auseinandersetzten zu muessen?

Derzeit speichern Projekte ihre Bauteile nicht lokal zwischen, ohne Pool 
kann man das Beispielprojekt nicht aufmachen.

Mike J. schrieb:
> - Bei der Auswahl der Bauteile wäre es schön wenn man eine Darstellung
> des entsprechenden Schaltsymbols sehen könnte, damit man weiß was man
> gerade in der Hand hält.

Das könnte ich dem Part Browser in der Tat noch spendieren.

> - Es ist etwas komisch dass bei den Widerständen schon Werte stehen.
> - Die Bauteilliste könnte in Baugruppen unterteilt sein, zum Beispiel
> Transistoren, LEDs, Versorgungssymbole (GND, Vcc, +3.3V ...),
> Steckverbinder, Chips, Widerstände usw.

Man will keinen generischen 10kOhm-Widerstand im Schaltplan haben, den 
kann man nirgendwo kaufen. Jedes Bauteil im Schaltplan hat Hersteller 
und Teilenummer, sodass man (in Zukunft) direkt die Stückliste bei 
octopart einwerfen kann. Für Hühnerfutter werden die Teilenummern aus 
der CPL von octopart verwendet. Zur suche gibt es die tags. 
Versorgungssymbole sind keine "normalen" Symbole, die sind fest 
eingebaut. Derzeit gibt es nur "GND". Siehe 
https://github.com/carrotIndustries/horizon/wiki/Schematic-editor#power-symbols

> - Jetzt fehlt die Leiste (mit dem Stift, spiegeln des Bauteils, Move,
> Copy usw.) welche es bei Eagle gibt, momentan verbinde ich die Pins im
> Schaltplan indem ich die Pins aneinander führe. Habe ich da etwas
> übersehen?

Leertaste drücken, dann kommt ein Menü mit allen verfügbaren Tools, da 
stehen auch die Tastenkürzel dran. Oder auf "Help" klicken, da steht 
auch was jede Taste macht.

> - Es ist etwas nervig dass man zum bewegen der Bauteile immer den
> "Move"-Knopf drücken muss.

Einfach "m" drücken.

> - Es wäre besser wenn sich das Bauteil nach einem Klick auf Move im
> Schaltungseditor direkt unter dem Mauszeiger befindet. (also die Mitte
> des Bauteils direkt unter dem Mauszeiger plazieren)
> Momentan ist das Bauteil dann teilweise noch sehr weit verschoben zum
> Mauszeiger.

Da unterscheiden sich wohl die Geschmäcker. So lange das Bauteil relativ 
dem Mauszeiger folgt passt für mich alles.

[Mike J. (linuxmint_user)]

Stefan S. schrieb:
> Ist das wirklich noch so? Nach meiner Meinung sollte möglist alles
> funktionieren, ohne das man spezielle Tools anwählen muss. Verschieben
> z.B. einfach: Maus über Bauteil, Knopf Drücken und Bewegen. Oder neue
> Leitung: Maus über Pin, Knopf drücken und loslassen, und die Leitung
> hängt an der Maus. Maus über Text, Mausrad dreht den Text. Maus über
> Bauteil, Mausrad dreht Bauteil. Maurad über freier Fläche: Zoom

Ich nutze das AppImage (unter XUbuntu 17.10):
horizon-1509392238.1462df3-Build44.1.glibc2.14-x86_64.AppImage

[Helmut S. (helmuts)]

Frank K. schrieb:
> Hallo Helmut,
>
> Die Idee der AppImages ist dass Du nichts zusätzlich installieren musst,
> das Image sollte alle nötigen libs, etc. enthalten. Ich habe
> canberra-gtk-module noch hinzugefügt, der Build lauft gerade. Sollte so
> bis in ein paar Minuten fertig sein falls Du es noch mal testen
> möchtest. Zu den neuen Problemen (update planes, 3D zerbröseln) kann ich
> noch nicht viel sagen, vielleicht fehlt noch eine lib welche für die
> korrekte Darstellung benötigt wird. Ich versuche das noch mal mit einem
> ubuntu 17.10 in einer virtualbox nachzustellen.
>
> Gruß,
> Frank

Hallo Frank,

Ich habe gerade mal deine neueste Version auf 17.10 gestartet obwohl ich 
da schon GTK 3 installiert hatte.

Die Planes werden immer noch nicht gefüllt dargestellt!

Beim drücken auf 3D erscheint eine Messagebox: OpenGL context creation 
failed

Danach ist die Grafik im Layoutfenster korrupt/unbrauchbar. Man hat Mühe 
das Layoutfenster im Blindflug zu schließen.

Gruß
Helmut

[tester (Gast)]

Helmut S. schrieb:
> Ich habe gerade mal deine neueste Version auf 17.10 gestartet obwohl ich
> da schon GTK 3 installiert hatte.
>
> Die Planes werden immer noch nicht gefüllt dargestellt!

Ich konnte es nicht lassen und habe auf einem Rechner Xubuntu 17.10 
installiert. Damit konnte ich die aktuelle Version von horizon 
problemlos (nach ein paar apt install ...) übersetzen. Ich musste kein 
gtk aus fremden Quellen (PPA) nachinstallieren, den o.g. Fehler sehe ich 
nicht, ganz fehlerfrei ist die 3d Darstellung aber auch nicht.

[Lukas K. (carrotindustries)]

tester schrieb:
> ganz fehlerfrei ist die 3d Darstellung aber auch nicht.

Kannst du mal einen Screenshot machen? So hilft mir diese Aussage recht 
wenig...

[W.S. (Gast)]

Jörg W. schrieb:
> Dann bleib doch einfach dabei.
>
> Ob andere „Bockmist“ bauen, diese Einschätzung darfst du gern mehr als
> nur dir überlassen.

Manchmal frag ich mich, warum ausgerechnet DU es partout nicht fertig 
bringst, sachlich zu bleiben und dich darum zu bemühen, einen Nutzwert 
in die Diskussionen einzubringen. Ständig wirst du an der unpassendsten 
Stelle persönlich. Brauchst du das mental?

Also: es gibt ne Menge Leute, die ebenso viele Projekte planen und 
anfangen - und nur ein kleiner Teil davon wird sein Zeugs zu Ende 
kriegen und damit einen Erfolg haben. Das ist so und es war schon immer 
so. Die viele Arbeit, die all die anderen in ihr Zeugs gesteckt haben 
ist hingegen für die Katz, denn aus deren Projekten wird zum Schluß 
nichts.

UND DAS IST DERART SCHADE DRUM, daß unsereiner eben nicht schadenfroh 
daneben steht um zuzugucken wie sich jemand verrennt und dann scheitert. 
Jedenfalls mir geht das so und deswegen sag ich jemandem, der grad 
Bockmist baut, daß er es tut. Der Rest liegt dann bei ihm, entweder 
kapiert er es und reißt sein Steuer herum oder er rümpft die Nase und 
macht weiter so wie bisher.

Aber das ist was ganz anderes als deine ständigen Unterstellungen wie 
z.B. hier bezüglich Altium Designer. Abgesehen davon kannst du in den 
Untiefen dieses Forums ne Einschätzung des AD nachlesen, die ich vor 
geraumer Zeit nach einer Vorführ-Erfahrung auf der Embedded verfaßt 
habe. Du hättest nachlesen und schlichtweg sachlich bleiben können.

W.S.

[tester (Gast)]

Hm... mit nicht ganz fehlerfrei meinte ich, dass die Darstellung der 
Solder Mask nach schwarz abgesoffen ist, wenn man die Platine zu sehr in 
die waagrechte gedreht hat. Schaut man mehr aus der Senkrechten drauf, 
wird sie wieder grün. Nichts, was jetzt wirklich entscheidend wäre.

[Mike J. (linuxmint_user)]

Was fehlt bei mir dass das unter Win7 nicht funktioniert?

Fehler:
- Exited with exit status 3
- Runtime Library

[Helmut S. (helmuts)]

Lukas K. schrieb:
> tester schrieb:
>> ganz fehlerfrei ist die 3d Darstellung aber auch nicht.
>
> Kannst du mal einen Screenshot machen? So hilft mir diese Aussage recht
> wenig...


Nach dem Drücken auf 3D kommt ja erstmal eine Fehlermeldung:

OpenGL context creation failed

Von 3D ist dann nichts zu sehen. Wenn amn dann ein resize des 
Layoutfensters macht sieht das aus wie im Anhang (2. Bild, 
Screenshot_from_2017-10-31_19-04-30.png)



Neueste AppImage: Siehe drittes Bild, 
Screenshot_from_2017-10-31_19-10-55.png
Da sind ein Teil der Toolbuttons in dem Button rechts mit den 3 kleinen 
waagrechten Strichen versteckt. Vermutlich wurde das Image mit einer 
anderen Bilschirmauflösung generiert. Ich habe hier HD-Auflösung 
(1920...).

AppImage von gestern und von heute
Im Layoutfenster werden die Planes nicht gefüllt. Ich weiß immer noch 
nicht ob das an meiner Grafikkarte liegt. Ich werde mich jetzt wohl 
wieder der Windows-Version widmen. Die läuft ohne Probleme.


Gruß
Helmut

[Possetitjel (Gast)]

Lukas K. schrieb:

> Man will keinen generischen 10kOhm-Widerstand im
> Schaltplan haben,

Doch, unbedingt.

Es ist in Ordnung, wenn Du Deine Software ausschließlich
an DEINEM Arbeitsablauf ausrichtest.

Aber BITTE sieh von unzutreffenden Verallgemeinerungen
ab.

Ich habe ziemlich oft Bedarf nach "abstrakten" Schaltplänen.
Das Auswählen der (abstrakten) Bauteile und das Definieren
der Schaltungstopologie ist bei mir der erste Schritt.
Die Dimensionierung ist der zweite, und die endgültige
Festlegung der Bauteiltypen (=kaufbare Produkte) der dritte.

--> Deine Software ist für mich nicht geeignet.

(Das ist kein Problem; Du machst nichts falsch. Ich wollte
es nur explizit feststellen.)

> Jedes Bauteil im Schaltplan hat Hersteller und Teilenummer,

Super.
Wenn ich den Hersteller wechsle, müsste ich den Schaltplan
anpassen :/

[tester (Gast)]

@helmut: Verwendest du Wayland oder X11? Xubuntu 17.10 verwendet 
standardmäßig X11, während das "normale" Ubuntu Wayland nimmt. Lt c't 
liegt da noch manches im argen, evtl. rühren hier die Probleme her.

@Lukas: Wie stellt man beim routen die Leiterbahngröße ein?

[Abdul K. (ehydra)]

Possetitjel, sehe ich auch so.


Helmut, du baust ein Ethernet-Interface mit einer Alpha-Software? Hast 
du so viel Zuversicht oder zu viel Freizeit? Soll kein Vorwurf sein.

[Possetitjel (Gast)]

W.S. schrieb:

> UND DAS IST DERART SCHADE DRUM, daß unsereiner eben nicht
> schadenfroh daneben steht um zuzugucken wie sich jemand
> verrennt und dann scheitert. Jedenfalls mir geht das so
> und deswegen sag ich jemandem, der grad Bockmist baut, daß
> er es tut.

Dein Fehler liegt in Deiner (unausgesprochenen) Voraussetzung,
dass DEINE Einschätzung für irgend etwas relevant ist, was
LUKAS tut.

Ist es aber nicht (zumindest nicht automatisch).

> Der Rest liegt dann bei ihm, entweder kapiert er es und
> reißt sein Steuer herum oder er rümpft die Nase und macht
> weiter so wie bisher.

Der Punkt ist, dass es von Lukas' Standpunkt aus kein
Bockmist IST.

Jedes Werturteil (wie Deinst: "Bockmist") setzt einen
Wertmaßstab voraus.
Nicht Dein Urteil an sich ist der Fehler -- sondern die
Tatsache, dass Du Deinen eigenen Wertmaßstab als richtig,
objektiv gegeben und nicht diskutabel ansiehst.
Auf dieser Basis kannst Du natürlich nicht vestehen, was
Lukas tut.

[tester (Gast)]

Abdul K. schrieb:
> Helmut, du baust ein Ethernet-Interface mit einer Alpha-Software? Hast
> du so viel Zuversicht oder zu viel Freizeit? Soll kein Vorwurf sein.

Das ist das Demo-Projekt.

[Helmut S. (helmuts)]

tester schrieb:
> Abdul K. schrieb:
>> Helmut, du baust ein Ethernet-Interface mit einer Alpha-Software? Hast
>> du so viel Zuversicht oder zu viel Freizeit? Soll kein Vorwurf sein.
>
> Das ist das Demo-Projekt.

So ist es. Damit kann man einfach mal Leitungen und Planes zeichnen, 
verschieben und probieren. Das ist keine Schaltung die man jetzt 
aufbauen soll. Ich finde das ist eine gute Sache.

[Abdul K. (ehydra)]

Oben stand, man könne keine Demos mit in die Auslieferung einbinden. 
Daher hat mich das gewundert ich folgerte, Helmut hat gleich mal richtig 
reingehauen.

[tester (Gast)]

@Lukas: Das mit den "Zero lenght track" ist ja ganz nett. Aber warum 
verhinderst du die Entstehung solcher Tracks nicht komplett?

[Jörg W. (dl8dtl) (Moderator)]

W.S. schrieb:

> UND DAS IST DERART SCHADE DRUM, daß unsereiner eben nicht schadenfroh
> daneben steht um zuzugucken wie sich jemand verrennt und dann scheitert.

Im Moment bist du der Einzige hier, der das, was da gerade mit
Horizon passiert, als „Scheitern“ deklariert.  Im Gegenteil, Lukas
hat den Thread Anfang des Jahres gestartet, danach war es recht
lange eher still.  Jetzt dagegen hat zumindest die Diskussion auch
von Leuten, die es getestet haben, doch gut Fahrt aufgenommen.

> Aber das ist was ganz anderes als deine ständigen Unterstellungen wie
> z.B. hier bezüglich Altium Designer.

Das ist einfach mein Eindruck, den ich nach deinen wiederholten
Eagle-Lobpreisungen bekommen habe.  Ich bin weit davon entfernt, Eagle
irgendwie als unbenutzbar hinzustellen, aber dass es im Bereich der
EDA-Programme eher eins ist mit ziemlich vielen Ecken und Kanten, ist
meist auch denjenigen klar, die es aktiv benutzen.  Das ist dann eher
eine „ist gut genug für mich“-Entscheidung als eine „so und nur so
hätte ich mir ein EDA-Programm vorgestellt“.

> Abgesehen davon kannst du in den
> Untiefen dieses Forums ne Einschätzung des AD nachlesen, die ich vor
> geraumer Zeit nach einer Vorführ-Erfahrung auf der Embedded verfaßt
> habe. Du hättest nachlesen und schlichtweg sachlich bleiben können.

Sorry, nach einem Anonymus im Forum zu suchen ist ja schlimmer als
nach einer Nadel im Heuhaufen.  Falls du einen Link hast, lese ich
es mir gern durch und korrigiere diese meine Meinung.

[tester (Gast)]

Oha... der "Interactive Router" kann schon (etwas) Push'n'Shove. Im 
"router" Unterverzeichnis ist einiges an Quelltext vom KiCad PnS Router. 
Ist ja kein Problem, beides ist GPL3.

[Lukas K. (carrotindustries)]

Geht ja richtig rund hier, ich hoff' jetzt nichts wichtiges vergessen zu 
haben:

tester schrieb:
> dass die Darstellung der
> Solder Mask nach schwarz abgesoffen ist, wenn man die Platine zu sehr in
> die waagrechte gedreht hat.

Das ist schlechtes flat shading bei der Arbeit ;) Die 3D-Vorschau 
entstand durch halbes implementieren einiger OpenGL-Tutorials, da ist in 
der Tat noch Luft nach oben. Wenn sich wer da austoben und das schöner 
machen will,  oder einfach umsetzbare Vorschläge hat, gerne doch.

Possetitjel schrieb:
> Super.
> Wenn ich den Hersteller wechsle, müsste ich den Schaltplan
> anpassen :/

Nein. Am Beispiel Widerstand mal erklärt, wie ich mir das vorgestellt 
hab: Horizon unterscheidet "Part" und "Entity". Jeder Widerstand mit 
zwei Beinen, egal welcher Wert und Hersteller ist durch die Entity 
"Two-terminal Resistor" definiert. Das Part fügt dem dann Hersteller, 
Wert, Teilenummer und Package hinzu. Wichtig für die Netzliste ist die 
Entity. Mit dem Tool "Assign Part" kann man ohne den Schaltplan 
anderweitig anzufassen z.B. aus einem 1k 0603 einen 10k 0402 Widerstand 
machen.

tester schrieb:
> @Lukas: Wie stellt man beim routen die Leiterbahngröße ein?

Dazu gibt es zwei Optionen: Zu bevorzugen ist es die Leiterbahnbreite in 
den Regeln festzulegen. Wie bei Altium auch werden die Reglen von oben 
nach unten abgearbeitet und die erste zutreffende wird appliziert. Wenn 
die Leiterbahnen mal anders werden sollen, kann man im Property Editor 
rechts im Bild "Width from Rules" aus machen und eine Leiterbahnbreite 
eintippen. Oder man drückt während des Routens "w" um die Größe 
einzutippen. Mit "W" wird wieder die aus den Regeln ausgewählt. (Hab 
wohl vergessen, das in den Tooltip aufzunehmen, kommt gleich)

tester schrieb:
> @Lukas: Das mit den "Zero lenght track" ist ja ganz nett. Aber warum
> verhinderst du die Entstehung solcher Tracks nicht komplett?

Mit dem Kicad-Router sollten die eigentlich nicht allzu oft entstehen. 
Bis jetzt war der Leidensdruck nicht groß genug, mich darum zu kümmern, 
dass die auch verschwinden.

tester schrieb:
> Oha... der "Interactive Router" kann schon (etwas) Push'n'Shove. Im
> "router" Unterverzeichnis ist einiges an Quelltext vom KiCad PnS Router.
> Ist ja kein Problem, beides ist GPL3.

Ja, ich hab den Router von den CERN-Leuten eingebaut. War einiges an 
Aufwand, hat sich aber definitiv gelohnt. War auch nur möglich, weil der 
Router selber recht unabhängig von KiCad gehalten ist und sein eigenes 
Datenmodell mitbringt. Ich behaupte jetzt mal, dass der Router in 
horizon erst sein wahres Potential entfalten kann, da das was KiCad 
unter "Design Rules" versteht doch sehr zu wünschen übrig lässt.

Helmut S. schrieb:
> Da sind ein Teil der Toolbuttons in dem Button rechts mit den 3 kleinen
> waagrechten Strichen versteckt.

Das ist Absicht ;) In 
https://github.com/carrotIndustries/horizon/commit/1462df3376afdfab499fcf60aaa4c89fe56fa840 
hab ich die Oberflächen der grafischen Editoren ein wenig aufgeräumt und 
nicht allzu oft benötigt Tools in das Hamburger-Menü gestopft.

Helmut S. schrieb:
> Von 3D ist dann nichts zu sehen. Wenn amn dann ein resize des
> Layoutfensters macht sieht das aus wie im Anhang (2. Bild,
> Screenshot_from_2017-10-31_19-04-30.png)

Dann ist das Wohl ein Bug in der Gtk-Version bzw. dem Zusammenspiel mit 
X11/Wayland die Ubuntu beiliegt...

Dass das nicht-füllen der Planes an der GPU liegt kann ich mir gerade 
nicht so richtig ausmalen, da diese (aus OpenGL-Sicht) genau so wie 
gefüllte Pads gezeichnet werden.

[Helmut S. (helmuts)]

>> Helmut S. schrieb:
>> Von 3D ist dann nichts zu sehen. Wenn amn dann ein resize des
>> Layoutfensters macht sieht das aus wie im Anhang (2. Bild,
>> Screenshot_from_2017-10-31_19-04-30.png)
>
> Dann ist das Wohl ein Bug in der Gtk-Version bzw. dem Zusammenspiel mit
> X11/Wayland die Ubuntu beiliegt...
>

Dieses Problem habe ich bei dem selben Rechner auch in Ubuntu 16.04 und 
da ist kein Wayland drin.
Kann natürlich auch an der doch älteren Grafikkarte liegen. Müsste mal 
schauen ob ich noch eine Festplatte opfere und Ubuntu 17.10 auf einenm 
anderen Rechner testen kann.



Helmut S. schrieb:
>> Da sind ein Teil der Toolbuttons in dem Button rechts mit den 3 kleinen
>> waagrechten Strichen versteckt.

> Das ist Absicht ;) In
> https://github.com/carrotIndustries/horizon/commit...
> hab ich die Oberflächen der grafischen Editoren ein wenig aufgeräumt und
nicht allzu oft benötigt Tools in das Hamburger-Menü gestopft.

Mir hatte die ältere Version besser gefallen. Bin da aber flexibel. Wer 
weiß schon wieviel "Knöpfe" da noch kommen. :-)

[Possetitjel (Gast)]

Lukas K. schrieb:

> Possetitjel schrieb:
>> Super.
>> Wenn ich den Hersteller wechsle, müsste ich den Schaltplan
>> anpassen :/
>
> Nein. Am Beispiel Widerstand mal erklärt, wie ich mir das
> vorgestellt hab: Horizon unterscheidet "Part" und "Entity".
> Jeder Widerstand mit zwei Beinen, egal welcher Wert und
> Hersteller ist durch die Entity "Two-terminal Resistor"
> definiert. Das Part fügt dem dann Hersteller, Wert,
> Teilenummer und Package hinzu. Wichtig für die Netzliste
> ist die Entity.

Kein schlechter Ansatz, aber nicht zu Ende gedacht.

[Lukas K. (carrotindustries)]

Possetitjel schrieb:
> Kein schlechter Ansatz, aber nicht zu Ende gedacht.

Was fehlt? Man kann auch erstmal generische Bauteile (nur Entity) ohne 
Part platzieren und erst gegen Ende Parts zuweisen, wenn einem das so 
besser gefällt.

[Possetitjel (Gast)]

Lukas K. schrieb:

> Possetitjel schrieb:
>> Kein schlechter Ansatz, aber nicht zu Ende gedacht.
>
> Was fehlt?

Der Wille zur Beschränkung :)

Ich denke seit einigen Monaten über eine Bauteildatenbank
nach und weiss daher, dass die Relation von Herstellern,
Typen, Footprints usw. kompliziert ist.
Datenblätter (in unterschiedlichen Versionen), SPICE-
Modelle und Lieferanten wollen auch noch verwaltet sein,
von (firmeninternen) Bauteilnummern, Stücklisten und
Bestellungen gar nicht zu reden...

Der Kern einer Layoutsoftware ist, dass man Footprints
platzieren und Leiterzüge verlegen kann. Über den ganzen
Rest soll sie mir so wenig Vorschriften machen wie möglich.

[Jörg W. (dl8dtl) (Moderator)]

Possetitjel schrieb:
> Über den ganzen Rest soll sie mir so wenig Vorschriften machen wie
> möglich.

Vorschriften nicht, aber den Rest mitverwalten ist nicht schlecht.

Bei Altium kann man eine externe Datenbank für die Teileverwaltung
reinhängen, das kann bspw. eine Excel-Tabelle sein.  Die enthält
dann außer Symbol und Footprint noch beliebig weitere Spalten, die
man beim Erstellen der BOM rausdumpen kann.  Damit bekommt man eine
BOM, die man direkt dem Fertiger in die Hand drücken kann.

Excel ist dabei (leider) offenbar ein ziemlicher de-facto-Standard.
Wenn man das nicht direkt erzeugen will, kann man natürlich allemal
auch CSV rauswerfen und das hernach in Excel oder Openoffice Calc
reinziehen.

Als Datenbank sollte sicher auch eine SQL-DB gehen, aber sowas hat
halt nicht jeder, und bis auf sqlite brauchen sie einen Server.  Gibt's
für sqlite ein gescheites Frontend zum Editieren?  Das scheint mir
ansonsten der wesentliche Grund zu sein, warum die Leute da eine
Excel-Tabelle nehmen.  Die ist ansonsten ja eher nachteilig, bspw.
kann man sie nicht im Excel schreibend öffnen, wenn Altium sie gerade
in den Fingern hat.

[Helmut S. (helmuts)]

>>> Helmut S. schrieb:
>>> Von 3D ist dann nichts zu sehen. Wenn amn dann ein resize des
>>> Layoutfensters macht sieht das aus wie im Anhang (2. Bild,
>>> Screenshot_from_2017-10-31_19-04-30.png)
>>
>> Dann ist das Wohl ein Bug in der Gtk-Version bzw. dem Zusammenspiel mit
>> X11/Wayland die Ubuntu beiliegt...
>>

>Dieses Problem habe ich bei dem selben Rechner auch in Ubuntu 16.04 und
da ist kein Wayland drin.
Kann natürlich auch an der doch älteren Grafikkarte liegen. Müsste mal
schauen ob ich noch eine Festplatte opfere und Ubuntu 17.10 auf einenm
anderen Rechner testen kann.


Ich habe jetzt das AppImage auf einem Rechner mit neuerer 
Grafikkarte(GTX560) mit Ubuntu 17.10 (Wayland, X) getestet.
https://download.opensuse.org/repositories/home:/frank_kunz/AppImage/

Die Flächen werden jetzt wie gewünscht auch gefüllt dargestellt.

Der Aufruf von 3D wirft eine Fehlermeldung, aber keine 3D Ansicht.
Fenster: Erstellen des OpenGL-Kontetxts ist gescheitert.
Anschließend kann man auch mit dem PCB nicht mehr vernünftig 
weiterarbeiten da ab da massive Grafikfehler im PCB-Fenster auftreten.

Schade. Für mich steht fest, dass da irgend eine Bibliothek fehlt.

Da werde ich wohl endgültig auf einem WIN-PCB weitertesten. Auspacken -> 
funktioniert.

Hallo Lukas, bitte die WIN-Version aktuell halten.
http://0x83.eu/horizon-zip/

Gruß
Helmut

[Nop (Gast)]

Helmut S. schrieb:

> Schade. Für mich steht fest, dass da irgend eine Bibliothek fehlt.

Das zieht sich doch schon durch den ganzen Thread. Eine typische 
FOSS-Geschichte - einfach alles an Abhängigkeiten reinziehen, was 
irgendwie sexy ist, kost ja nix. Und sich dann wundern, wieso das 
Ergebnis ausschließlich auf dem Dev-Rechner läuft.

Und natürlich bleeding edge, damit man LTS-Anwendern mal gepflegt zeigen 
kann, wie verwerflich es schon rein moralisch ist, einen Linuxrechner 
für etwas anderes als Systemupdates und Alphatests nutzen zu wollen.

[Jörg W. (dl8dtl) (Moderator)]

Nop schrieb:
> Das zieht sich doch schon durch den ganzen Thread.

Nörgeltanten wie du ziehen sich leider auch schon durch den ganzen
Thread.  Ich denke, darauf könnten nicht nur Lukas sondern auch seine
Tester gern verzichten.

[Nop (Gast)]

Jörg W. schrieb:
> Ich denke, darauf könnten nicht nur Lukas sondern auch seine
> Tester gern verzichten.

So, das denkst Du. Shoot the messenger, was? Und was denkst Du sonst 
noch so? Daß die Problematik besser wird, wenn keiner sie anspricht?

[Jörg W. (dl8dtl) (Moderator)]

Nop schrieb:
> Daß die Problematik besser wird, wenn keiner sie anspricht?

Dass bis dann, wenn das Programm für die Massen spruchreif wird, die
derzeit als „verfrüht“ betitelten Versionen irgendwelcher Bibliotheken
sowieso Standard sein werden.

Das schrieb ich übrigens auch schon zu Beginn des Threads.  Über einen
Teil dessen, was damals noch „bleeding edge“ war, diskutiert nun schon
keiner mehr.

Aber Hauptsache, man kann pauschal auf „typisch FOSS“ meckern.  Etwas
Substanzielles beitragen – ничего, nada, wozu auch?

[Nop (Gast)]

Jörg W. schrieb:
> Dass bis dann, wenn das Programm für die Massen spruchreif wird, die
> derzeit als „verfrüht“ betitelten Versionen irgendwelcher Bibliotheken
> sowieso Standard sein werden.

Es ist aber nicht nur ein Problem für die Massen, sondern schon fürs 
Testing. Wie man leicht mitlesen kann, wenn man nicht in einer 
primitiven "shoot the messenger"-Denke festklebt.

> Aber Hauptsache, man kann pauschal auf „typisch FOSS“ meckern.

Diese Problematik IST nunmal typisch für FOSS.

> Etwas Substanzielles beitragen

Substantieller als Du mit "shoot the messenger" wäre ich ja schon, wenn 
ich auch nur die Uhrzeit ansagen würde. Wenn EINES jeder Art von 
vernünftigem testen abträglich ist, dann Jubelperser, die um Himmels 
Willen keine Probleme hören wollen.

Von Profizeug wie Erwägungen, inwieweit Testergebnisse ohne jedes 
Config-Management überhaupt irgendeine Aussage haben, will ich gar nicht 
erst anfangen.

Aber gut, ich bin ja schon ruhig. Keiner hat was gesagt, keiner hat was 
gesehen, HURRAAAAA alles gut. Jetzt zufrieden?!

[Possetitjel (Gast)]

Jörg W. schrieb:

> Vorschriften nicht, aber den Rest mitverwalten ist nicht
> schlecht.

Hmmja.
Der Knackpunkt dabei sind letztlich die Projektdaten: Kann
ich mit denen unabhängig von DIESER konkreten Software etwas
anfangen oder nicht?

Für Datenblätter, SPICE-Modelle und SPICE-Files ist das
gewährleistet; für Gerber-Daten auch. Aber dazwischen?
Ja, gut... Netzlisten. Und sonst?

> Bei Altium kann man eine externe Datenbank für die
> Teileverwaltung reinhängen, das kann bspw. eine
> Excel-Tabelle sein.

Altium scheint allgemein ziemlich viel richtig zu machen,
will mir scheinen.

Nach meinem Eindruck ist das eine zwei-Klassen-Gesellschft:
Einerseits die Anwender, die mehrere Tausend Euro für die
ECAD-Software raushauen können, und andererseits alle die,
die das nicht können und mit Target, Eagle &Co. leben müssen.

> Excel ist dabei (leider) offenbar ein ziemlicher
> de-facto-Standard. Wenn man das nicht direkt erzeugen
> will, kann man natürlich allemal auch CSV rauswerfen
> und das hernach in Excel oder Openoffice Calc reinziehen.

Ein schlechter Standard ist besser als gar keiner. Schlecht
für die Programmierer, gut für die Anwender. Excel verwenden
die Leute sowieso, das ist also erstens vorhanden, und das
können die Leute zweitens halbwegs bedienen.

> Als Datenbank sollte sicher auch eine SQL-DB gehen, aber
> sowas hat halt nicht jeder,

So ganz blicke ich da sowieso nicht durch.

Selbst OpenOffice bringt OOBase mit. Es wäre doch das
Logischste von der Welt, dass man die Daten, die zu komplex
für Excel sind, damit verwaltet. Das scheint aber im großen
und ganzen nicht üblich zu sein.

An der Datenmenge kann's nicht liegen. Selbst heftig
produzierende Kleinunternehmen kommen mit 10'000 Datensätzen
in der Bauteildatenbank aus; da lacht jede Datenbank drüber.
Mysteriös...

[Frank K. (frank)]

Helmut S. schrieb:
> Der Aufruf von 3D wirft eine Fehlermeldung, aber keine 3D Ansicht.
> Fenster: Erstellen des OpenGL-Kontetxts ist gescheitert.

Selbiges Problem sehe ich auch, interessanterweise auch auf meinem 
System auf dem die lokal kompilierten Binaries problemlos laufen.

> Anschließend kann man auch mit dem PCB nicht mehr vernünftig
> weiterarbeiten da ab da massive Grafikfehler im PCB-Fenster auftreten.

Das habe ich auch mit Ubuntu 17.10 beobachtet. Könnte was mit Wayland zu 
tun haben, ist aber nur Spekulation.

Ab diesem Punkt (OpenGL/3D) wird es wohl kompliziert AppImages zu bauen. 
Etwas Google Suche hat da auch mehr Beiträge mit Problemen als Lösungen 
gefunden. Vielleicht könnte Softrendering erzwungen werden, dann würde 
die Arbeit mit horizon aber wohl keinen Spaß mehr machen. Zur Not hilft 
nur selber kompilieren, zum Glück ist das mit FOSS möglich... ;-)

Gruß,
Frank

[Helmut S. (helmuts)]

> Zur Not hilft nur selber kompilieren, zum Glück ist das mit FOSS möglich... ;-)

Das habe ich gleich mal probiert.

Anleitung von hier: 
https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Linux

sudo apt install libyaml-cpp-dev libsqlite3-dev util-linux librsvg2-dev 
\
    libcairomm-1.0-dev libepoxy-dev libgtkmm-3.0-dev uuid-dev 
libboost-dev \
    libzmq5 libzmq3-dev libglm-dev


Dann zip-Datei mit "clone or download" geholt und ausgepackt. Dann make.

make

Das compiliert eine Menge Files und bricht dann ab mit Fehlermeldung 
siehe unten.

make: *** Keine Regel vorhanden, um das Ziel „.git/HEAD“,
  benötigt von „gitversion.cpp“, zu erstellen.  Schluss.


Was muss man da mit "git" vorher machen/installieren?

[Frank K. (frank)]

Hast Du git installiert? Wenn ja, dann versuch mal

git clone https://github.com/carrotIndustries/horizon.git

dann sollte "make" durch laufen. Das Problem ist wohl dass in der *.zip 
Datei keine git Metadaten enthalten sind. Diese werden jedoch benötigt 
um einen git-Versionsstring in die Applikation einzukompilieren.

Gruß,
Frank

[Frank L. (florenzen)]

Wenn man nicht mit git herumhantieren will tut es auch ein

mkdir .git
touch .git/HEAD .git/index

Gruß,
Frank

[Helmut S. (helmuts)]

Hallo Frank,

vielen Dank für deine Hilfe. Ohne deine Anleitung hätte ich das nicht 
geschafft.

Git hatte ich hier schon geholt. Wusste aber dann nicht weiter.
https://www.howtoforge.com/tutorial/install-git-and-github-on-ubuntu-14.04/


git clone https://github.com/carrotIndustries/horizon.git
Gerade ist der Compiler fertig geworden.


Habe dann im Dateimanager auf horizon-prj-mgr Doppelklick gemacht. Dann 
kam eine Fehlermeldung: "horizon-pool-mgr" konnte nicht angezeigt 
werden. Irgendwas mit fehlendem MIME Type kam dann auch noch.

Ich habe dann das Ganze aus einem Terminal gestartet.

./horizon-prj-mgr


Hurra. Es geht, auch 3D geht fehlerlos.


(Inzwischen ist aus meiner Ubuntu 17.10 Wayland zwangsweise ein Ubuntu 
17.10 X geworden nachdem ich versuchsweise den NVIDIA Grafiktreiber 
installiert hatte.)

Ich glaube da bekomme ich jetzt so etwas wie eine Äquatortaufe wie bei 
den Seefahrern, wenn sie das erste Mal den Äquator erreicht haben.

Gruß
Helmut

[Michael W. (Gast)]

Mac G. schrieb:
> Obwohl ich Altium zur Verfügung habe und das auch Simulieren kann, nutze
> ich noch immer viel lieber LTSpice für analoge Geschichten.
Hast Du die Möglichkeiten von Altium und pSpice voll ausgenutzt?

> Man kann sowieso nur selten die komplette Schaltung simulieren - man
> simuliert nur die kritischen Teile davon.
Gut, das ist wahr.

> Für HF-Kram gibts dann wieder andere Tools...
Hyper-Lnyx?

[Uwe S. (steinm)]

Hallo Lukas,

erstmal Danke für die Energie, die du in horizon steckst. Ich habe 
bisher nicht viele EDA Programme genutzt, muss aber sagen, das horizon 
spätestens auf den zweiten Blick recht gut bedienbar ist. Vorallem, weil 
du einige gute Konzepte von Blender übernommen hast.

Ich habe mal Debian-Pakete erstellt, was insgesamt ganz reibungslos 
klappte. Den Pool habe ich auch in ein eigenes Paket gesteckt und dabei 
ist die Frage aufgekommen, ob man mehrere Pools gleichzeitig nutzen kann 
und wo die erstellte
Pool-Datenbank abgelegt wird? Kann man die .json Dateien read-only unter 
/usr/share/horizon ablegen und diesen Pool damit allen Nutzern zur 
Verfügung stellen? Muss die pool.db dann auch dort liegen oder könnte 
die auch unter /var/lib/horizon oder möglicherweise für jeden Benutzer 
in ~/.horizon/ abgelegt werden? Kann ein Benutzer einen eigenen Pool in 
seinem Home ablegen?

  Uwe

PS: Ein eigenes Forum oder eine Mailingliste hat horizon nicht, oder?

[Lukas K. (carrotindustries)]

Ah, du warst also der mit den Issues, auf github letztens. Danke fürs 
Testen, gibt doch immer wieder Dinge die einem durch die Lappen gehen.

Uwe S. schrieb:
> erstmal Danke für die Energie, die du in horizon steckst. Ich habe
> bisher nicht viele EDA Programme genutzt, muss aber sagen, das horizon
> spätestens auf den zweiten Blick recht gut bedienbar ist. Vorallem, weil
> du einige gute Konzepte von Blender übernommen hast.

Danke für die Blumen :) Schön dass das mal jemandem auffällt. Ich hatte 
nur mal kurz Blender benutzt und Dinge wie das Leertaste-Menü und dass 
der Cursor am Canvas-Rand wieder zurückspringt haben mir gefallen und 
waren recht einfach einzubauen.


> Den Pool habe ich auch in ein eigenes Paket gesteckt und dabei
> ist die Frage aufgekommen, ob man mehrere Pools gleichzeitig nutzen kann
> und wo die erstellte
> Pool-Datenbank abgelegt wird? Kann man die .json Dateien read-only unter
> /usr/share/horizon ablegen und diesen Pool damit allen Nutzern zur
> Verfügung stellen? Muss die pool.db dann auch dort liegen oder könnte
> die auch unter /var/lib/horizon oder möglicherweise für jeden Benutzer
> in ~/.horizon/ abgelegt werden? Kann ein Benutzer einen eigenen Pool in
> seinem Home ablegen?

Den Pool zu paketieren halte ich für nicht sinnvoll. Mir schwebte der 
Pool in der Anwendung so vor: Der Anwender klont sich den Pool irgendwo 
in sein Home und macht regelmäßig git pull. Eigene Bauteile sollen dann 
auch in dem Pool angelegt und mit Pull request eingepflegt werden. 
Derzeit ist das ein muss wenn man sein Projekt veröffentlichen will, da 
Projekte die verwendeten Bauteile nicht zwischenspeichern. Steht aber 
auch noch auf meiner todo-Liste, dass sich das ändert. Mal sehen, wie 
die Idee mit dem globalen Pool so in der Praxis bewährt, falls 
tatsächlich mal eine signifikante Anzahl von Leuten horizon ernsthaft 
benutzt.

> PS: Ein eigenes Forum oder eine Mailingliste hat horizon nicht, oder?
Für's Erste müssen der Thread hier und die Issues auf github reichen. So 
groß war der Andrang bis jetzt noch nicht, dass sich das lohnen würde.

Inzwischen gibt's auch einige neue potentiell nützliche Features:
 - Man kann Canvas-Farbe und Grid-Darstellung einstellen
 - "Dimensions" um im Board Abstände zu kennzeichnen
 - Beim Routen wird nun wie bei KiCad oder Altium das Netz hervorgehoben
 - Cross-Probing von Schaltplan zu Board und umgekehrt

[Uwe S. (steinm)]

Lukas K. schrieb:
>
> Uwe S. schrieb:
>> Den Pool habe ich auch in ein eigenes Paket gesteckt und dabei
>> ist die Frage aufgekommen, ob man mehrere Pools gleichzeitig nutzen kann
>> und wo die erstellte
>> Pool-Datenbank abgelegt wird? Kann man die .json Dateien read-only unter
>> /usr/share/horizon ablegen und diesen Pool damit allen Nutzern zur
>> Verfügung stellen? Muss die pool.db dann auch dort liegen oder könnte
>> die auch unter /var/lib/horizon oder möglicherweise für jeden Benutzer
>> in ~/.horizon/ abgelegt werden? Kann ein Benutzer einen eigenen Pool in
>> seinem Home ablegen?
>
> Den Pool zu paketieren halte ich für nicht sinnvoll. Mir schwebte der
> Pool in der Anwendung so vor: Der Anwender klont sich den Pool irgendwo
> in sein Home und macht regelmäßig git pull. Eigene Bauteile sollen dann
> auch in dem Pool angelegt und mit Pull request eingepflegt werden.
> Derzeit ist das ein muss wenn man sein Projekt veröffentlichen will, da
> Projekte die verwendeten Bauteile nicht zwischenspeichern. Steht aber
> auch noch auf meiner todo-Liste, dass sich das ändert. Mal sehen, wie
> die Idee mit dem globalen Pool so in der Praxis bewährt, falls
> tatsächlich mal eine signifikante Anzahl von Leuten horizon ernsthaft
> benutzt.
Dann wird es in der Tat kritisch, wenn Andere Anwender Bauteile ändern 
und ich mir
diese Änderungen auf mein Board hole. Für diesen Fall müsste man die 
verwendeten Bauteile auch im Projekt ablegen und nur auf Wunsch aus dem 
Pool
auf den aktuellen Stand bringen. Ich glaube, dass man auf Dauer nicht um 
einen lokalen Pool herumkommt. Auch, weil für viele Anwender der Umgang 
mit git eine zu große Hürde ist. Ein globaler Pool erfordert vorallen 
genaue Regeln für die Vergabe von Bezeichnern und Dateinamen sowie eine 
sinnvolle Ordnerstruktur, sonst endet das schnell im Chaos.

Eine grundsätzliche Frage zur Erstellung von Bauteilen haben ich auch 
noch.
Wenn man z.B. ein DIP8 Package für einen ATtiny85 erstellt, dann kann so 
ein
Package durchaus unterschiedliche Padstacks verwenden. Beispielsweise 
durchgängig runde Padstacks oder 7 runde und einen eckigen für Pin 1, 
oder
auch ovale Padstacks. Dem Part ordnet man genau ein Package zu. Was ist, 
wenn der Anwender dieses Parts ein anderes Package verwenden möchte, das 
sich nur in den Padstacks unterscheidet? Braucht man dann mehrere Parts? 
In dem Zusammenhang noch eine Frage. Kann man die Zuordnung des Packages 
zum Part nachträglich ändern? Mir scheint als wird diese Zuordnung mit 
der Erstellung des Parts vorgenommen und kann nicht mehr geändert werden 
(es sei denn, man ändert direkt die .json Datei)

> >> PS: Ein eigenes Forum oder eine Mailingliste hat horizon nicht, oder?
> Für's Erste müssen der Thread hier und die Issues auf github reichen. So
> groß war der Andrang bis jetzt noch nicht, dass sich das lohnen würde.
>
> Inzwischen gibt's auch einige neue potentiell nützliche Features:
>  - Man kann Canvas-Farbe und Grid-Darstellung einstellen
>  - "Dimensions" um im Board Abstände zu kennzeichnen
>  - Beim Routen wird nun wie bei KiCad oder Altium das Netz hervorgehoben
>  - Cross-Probing von Schaltplan zu Board und umgekehrt
Stoße ich bestimmt noch drauf, wenn ich mich mal an ein Board mache.

  Uwe

[Mike J. (linuxmint_user)]

Es wäre schön wenn sich die Nutzer mit Benutzernummer und Passwort in 
der Bibliothek einloggen würden.
Wenn sie dann im Programm sind können sie dann ein Bauteil anklicken und 
es auf ihren Account im Internet laden.
Alle anderen Nutzer sehen diese Bauteile dann ebenfalls und können 
darunter Kommentare schreiben oder dieses Bauteil bewerten.
Es wäre schön wenn das alles aus der Anwendung heraus funktionieren 
würde, also ohne Browser.

Für die Bauteile bräuchte man auch eine Versionierung und Mods müssten 
verhindern dass Unfug getrieben wird.

Schön wäre es wenn man eine Favoritenliste anlegen kann in der nur die 
Bauteile sind die man so braucht.
z.B. Widerstände, Kondensatoren, generell den Atmel-Chips-Ordner oder 
man wählt sogar nur den ATmega328P.

Wenn ich nur SMD-Widerstände der Bauform 0603 verwende, dann sollte 
dieser Typ wenn man einen Widerstand einfügt als Voreinstellung 
gespeichert werden.

Wie verändert ihr eigentlich die Breite der Leitungen?

[Jörg W. (dl8dtl) (Moderator)]

Mike J. schrieb:
> Mods müssten verhindern dass Unfug getrieben wird.

Ziemlich viel Aufwand, meinst du nicht?

Industrielle Anwender (falls die jemals im Blickfeld sein sollten)
brauchen das alles nicht.  Die wollen in den meisten Fällen sowieso
alles von A bis Z selbst machen.  OK, Symbole für Widerstände und
Transistoren nimmt man sicher gern mit, aber alles, was nennenswert
komplexer ist, gibt man da nicht aus der Hand.

[Lukas K. (carrotindustries)]

Uwe S. schrieb:
> Dem Part ordnet man genau ein Package zu. Was ist,
> wenn der Anwender dieses Parts ein anderes Package verwenden möchte, das
> sich nur in den Padstacks unterscheidet? Braucht man dann mehrere Parts?

Derzeit ja, mal nachdenken wie man das am sinnvollsten handhaben kann.

> In dem Zusammenhang noch eine Frage. Kann man die Zuordnung des Packages
> zum Part nachträglich ändern?

Eigentlich ist es nicht vorgesehen bereits im Pool vorhandene Bauteile 
zu Verändern. Zeitnah wird es noch ein "Deprectated"-Flag geben.

Rein technisch gibt es hingegen keinen Grund weshalb das Package nicht 
änderbar ist. In einer früheren Version des Part Editors ging das auch 
mal, aber die Logik wurde mir dann für den Nutzen zu komplex und ist 
dann als der Pool Manger kam rausgeflogen.

Mike J. schrieb:
> Es wäre schön wenn sich die Nutzer mit Benutzernummer und Passwort in
> der Bibliothek einloggen würden. [...]
Gibt es doch schon, nennt sich github. Das deckt so ziemlich alle der 
Punkte ab, bis auf vielleicht Integration in die Anwendung. Wem die cli 
von git nicht gefällt, der soll eben einen der Zahlreichen GUI-Clients 
verwenden. Auf Server-Krams mit Benutzerverwaltung hab ich keinen Bock, 
das können und machen andere schon besser. Wenn jemand git-Integration 
in den Pool Manger einbauen will, gerne doch.

Mike J. schrieb:
> Schön wäre es wenn man eine Favoritenliste anlegen kann in der nur die
> Bauteile sind die man so braucht.

Gibt es schon im "Part Browser" im Projektmanager.

Mike J. schrieb:
> Wie verändert ihr eigentlich die Breite der Leitungen?
Wurde  von mir schon weiter oben im Thread ausführlich beantwortet.

Jörg W. schrieb:
> Industrielle Anwender (falls die jemals im Blickfeld sein sollten)
> brauchen das alles nicht.
Genau. Auch wenn das jetzt ein wenig arg ambitioniert klingen mag, sehe 
ich als Zielgruppe Entwickler von Projekten ca. dieser Größenordnung: 
http://hforsten.com/third-version-of-homemade-6-ghz-fmcw-radar.html 
Damit könnte es vielleicht auch für so manche Firma in ferner Zukunft 
interessant werden.

Im Firmeneinsatz ist dann in der Tat vorgesehen, dass man sich seinen 
eigenen Pool pflegt. Der "Community"-Fall ist dann ähnlich, nur dass wir 
eben alle bei der selben Firma sind ;)

[Frank K. (frank)]

Lukas K. schrieb:
> Gibt es doch schon, nennt sich github. Das deckt so ziemlich alle der
> Punkte ab, bis auf vielleicht Integration in die Anwendung.

Bezüglich der Integration würde es ausreichen einen visuellen diff für 
Schaltplan, Board und Packages zu haben. Also einen Viewer der zwei 
Board|Schematic|Package Dateien laden und diese vergleicht indem z.B. 
beide in unterschiedlichen Farben übereinander gelegt werden.

Ich habe so etwas für KiCAD gabastelt, allerdings ist das recht 
unhandlich. Für den Schaltplan checke ich (in git) exportierte PDF 
Dateien mit ein, diese vergleiche ich dann mit diffpdf. Für Board 
Dateien generiere ich Gerber Dateien welche ich mit einchecke, diese 
lege ich dann auf zwei separate Layer (grün/rot) in gerbv, diese werden 
dann, bei Überlappung, gelb angezeigt, sonst in rot oder grün.

[Frank K. (frank)]

Ich habe ein Problem die neueste Version zu kompilieren:

[  478s] imp/imp_schematic.cpp: In lambda function:
[  478s] imp/imp_schematic.cpp:252:27: error: 'void Gio::SimpleAction::set_state(const Glib::VariantBase&)' is protected within this context
[  478s]      cp_action->set_state(v);
[  478s]                            ^
[  478s] In file included from /usr/include/giomm-2.4/giomm/actionmap.h:27:0,
[  478s]                  from /usr/include/giomm-2.4/giomm.h:27,
[  478s]                  from /usr/include/gtkmm-3.0/gtkmm.h:88,
[  478s]                  from imp/main_window.hpp:2,
[  478s]                  from imp/imp.hpp:2,
[  478s]                  from imp/imp_schematic.hpp:2,
[  478s]                  from imp/imp_schematic.cpp:1:
[  478s] /usr/include/giomm-2.4/giomm/simpleaction.h:424:8: note: declared protected here
[  478s]    void set_state(const Glib::VariantBase& value);
[  478s]         ^~~~~~~~~

[Helmut S. (helmuts)]

Mike J. schrieb:
> Wie verändert ihr eigentlich die Breite der Leitungen?

Helmut S. schrieb:
> Warum ist eigentlich im Layout das Feld für Track->width grau(nicht
> änderbar)?

Das liegt daran, dass der Schalter "Width from rules" an ist. Damit
werden die Leiterbahnbreiten entsprechend der Regeln unter "Track Width"
gesetzt. Wie bei allen anderen Regeln auch wird die angewendet, die als
erstes zutrifft.

[Lukas K. (carrotindustries)]

Frank K. schrieb:
> Ich habe ein Problem die neueste Version zu kompilieren:

Ist repariert.

[Enrico W. (Firma: metux IT consult) (nekrad)]

Das Makefile (eines der ersten Dinge auf die ich schaue) sieht schonmal 
ordentlich aus.

Problem: es wird eine neuere gtkmm-Version benötigt, die in vielen
LTS-Distros nicht drin ist (bitte nicht immer auf bleeding-edge
verlassen - das macht grade im Industrie-Bereich Schmerzen ;-)).
Wäre schön, wenns auch ohne GLArea ginge.

gtk(mm) hochziehen macht man auch nicht gerade in der Kaffepause,
zieht einen ziemlich langen Rattenschwanz nach sich.

[Jörg W. (dl8dtl) (Moderator)]

Enrico W. schrieb:
> bitte nicht immer auf bleeding-edge
> verlassen

Diese Diskussion hatten wir schon ganz am Anfang.  Kannst du da
nachlesen, bevor du versuchst, sie hier neu aufzurollen.

[Stefan S. (Gast)]

Enrico W. schrieb:
> Wäre schön, wenns auch ohne GLArea ginge.

Und das schon gar nicht. GLArea kam mit GTK 3.16 -- darauf hatten viele 
gewartet, da es die Interaktion mit GL stark vereinfachen sollte. Und 
GTK 3.16 ist ja schon jetzt extrem alt, GTK3.20 oder 22 sollte heute 
eigentlich jeder haben. Wenn Horizon fertig ist, haben wir eh längst 
GTK4.

[tester (Gast)]

Enrico W. schrieb:
> Problem: es wird eine neuere gtkmm-Version benötigt, die in vielen
> LTS-Distros nicht drin ist

Ich habe extra ein Xubuntu 17.10 aufgesetzt, damit compiliert Horizon 
(nach ein paar apt install) out-of-the-box. Selbst der Fehler von Frank 
K. (am 8.11.) kam bei mir nicht. 17.10 hat gcc 7.2. Ich bin inzwischen 
davon abgewichen, hier Backports zu fordern, weil

1) wenn Horizon für Endanwender benutzbar wird, sind eh die nächsten LTS 
Versionen da. Allerdings hoffe ich, dass dann Horizon nicht immer noch 
bleding edge ist, sondern z.B. mit der Ubuntus LTS 18.4 kompilierbar. 
Darauf sollte man achten

2) so sehr ich KiCad schätze, so nervt mich dann doch auch die 
verschiedenen Canvases. Horizon setzt gleich auf OpenGL, und dass ist 
gut. Ich habe gestern mit der neusten Version (von Horizon) mal eine 
Stunde gelayoutet. Der interaktive Router mit walk-around und PnS ist 
wirklich schon brauchbar!

3) Lukas scheint echt fähig zu sein! (Lob!) Ich will, dass er seine Zeit 
in die Weiterentwicklung (neue Features, Bugfixes) von Horizon steckt, 
nicht in Backports.

Mir macht das Benutzen von Horizon inzwischen fast mehr Spaß als KiCad. 
Abgestürzt ist es mir gar nicht. Auch der Bauteileeditor scheint 
brauchbar zu sein. Alles wichtige scheint da zu sein! Lob!

Wenn ich mehr Zeit habe, werde ich ein paar Bauteile anlegen und mal ein 
Projekt durchziehen. Das Pool Konzept ist (wenn man glaubt, es halbwegs 
verstanden zu haben) von der Idee her nicht schlecht.
https://github.com/carrotIndustries/horizon/wiki/The-Pool
Allerdings wird man wohl für (fertige) Projekte einen lokalen Pool haben 
wollen, oder man freezed die verwendeten Bauteile in der entsprechenden 
Version. Merkt sich der Pool die verwendete Version? Github sollte dies 
ja tun, aber auch der Pool auf meinem Rechner?

Was ich beim layouten am meisten vermisst haben, war eine Option, 
verbundenen Leiterbahnsegmente auf einmal zu selektieren.

Aber nochmal Lob an Lukas, bisher gute Arbeit!

[tester (Gast)]

tester schrieb:
> Merkt sich der Pool die verwendete Version? Github sollte dies
> ja tun, aber auch der Pool auf meinem Rechner?

Dazu noch was: Wenn man ein Bauteil einsetze, dann prüft man ja, ob es 
für die Verwendung im Projekt geeignet, das "Richtige" ist. Nach diesem 
Vorgang möchte man ja keine Änderungen mehr. Wenn nun "jemand" im Github 
Pool das Bauteil ändert, hat man ja möglicherweise ein Problem. Auch 
wenn man ein Projekt weitergibt, sollte der Empfänger ja genau das 
"richtige" Bauteil verwenden.

Mögliche Lösungsansätze:

1) Ein lokaler Pool, der zum Projekt abgespeichert bzw. mitgegeben wird
Problem: Jetzt hat man durch die Hintertür das Libs Konzept wieder 
eingeführt, was zum Chaos führen kann

2) Horizon holt sich vom Github Pool genau das passende Bauteil in der 
damals verwendeten Version. Das sollte möglich sein. Problem: Wenn der 
Server nicht mehr erreichbar ist. Lösung: Auch der lokale Pool (als 
Clone von Github Pool) hat alle Versionen, nicht nur die aktuellste. 
Kann dann natürlich mit der Zeit sehr groß werden.

3) Horizon speichert zusätzlich alle verwendeten Bauteile im Projekt mit 
ab
Bei einer Änderung des Bauteils kommt eine Nachricht, die die 
Unterschiede des lokalen Bauteils und des aktuellen aufzeigt (diff). 
Unterschied zur Lösung 1: Der "lokale" Pool für das Projekt ist hier 
versteckt. Er tritt nur auf, wenn explizit von Horizon eine Veränderung 
in einem bereits verwendeten Bauteil entdeckt wird.

Ach ja: Im Moment sollte man in dieses Problem wohl noch keine größere 
Zeit investieren, es aber im Hinterkopf behalten.

[Cyblord -. (cyblord)]

tester schrieb:
> Dazu noch was: Wenn man ein Bauteil einsetze, dann prüft man ja, ob es
> für die Verwendung im Projekt geeignet, das "Richtige" ist. Nach diesem
> Vorgang möchte man ja keine Änderungen mehr. Wenn nun "jemand" im Github
> Pool das Bauteil ändert, hat man ja möglicherweise ein Problem. Auch
> wenn man ein Projekt weitergibt, sollte der Empfänger ja genau das
> "richtige" Bauteil verwenden.

Sorry aber genau dieser Absatz sollte dir doch zeigen wie abstrus die 
Idee ist, quasi live auf öffentliche Bauteil-Repos zuzugreifen.

NIEMAND der auch nur fortgeschrittener Hobbist ist, tut oder will so 
was.

Ohne lokale Libs ist das ganze im (Semi) Prof. Bereich TOT. Hat von euch 
denn so gar niemand Erfahrung in diesem Bereich?

[tester (Gast)]

Cyblord -. schrieb:
> Sorry aber genau dieser Absatz sollte dir doch zeigen wie abstrus die
> Idee ist, quasi live auf öffentliche Bauteil-Repos zuzugreifen.

Witzbold! Warum schrieb ich denn den Beitrag? Warum habe ich darauf 
hingewiesen und sogar mögliche Lösungsansätze gebracht?

> NIEMAND der auch nur fortgeschrittener Hobbist ist, tut oder will so
> was.

Im Moment interessiert es aber nicht! Außerdem kann man jetzt schon 
Lösung 1 verwenden, also einen lokalen Pool zum Projekt betreiben.

> Ohne lokale Libs ist das ganze im (Semi) Prof. Bereich TOT. Hat von euch
> denn so gar niemand Erfahrung in diesem Bereich?

Du bist wohl wie ein Tierarzt, der bei der geringsten Wunde beim Hund 
als einzige Lösung "einschläfern" bleibt.

[Jörg W. (dl8dtl) (Moderator)]

tester schrieb:
> Witzbold!

Ach, du kennst Cyblord noch nicht?

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Lukas,

wirst Du auf der FOSDEM im EDA Devroom vortragen?

[tester (Gast)]

Lukas K. schrieb:
> Horizon kann genau das. Man kann ohne "Part" anfangen und später mit
> "assign Part" dem "Component" ein "Part" zuweisen. Nachträglich kann man
> natürlich das Part auch austauschen.

Lukas K. schrieb:
> Man will keinen generischen 10kOhm-Widerstand im Schaltplan haben, den
> kann man nirgendwo kaufen. Jedes Bauteil im Schaltplan hat Hersteller
> und Teilenummer, sodass man (in Zukunft) direkt die Stückliste bei
> octopart einwerfen kann.

Hm... irgendwie widersprichst du dir da. Ich kann zwar generische Parts 
plazieren, z.B. den "base 0805 resistor", kann dem aber keine Werte 
zuweisen, also z.B. "10k". So macht das aber IMHO wenig Sinn. Ich will 
ja gerade beim Schaltplanzeichnen erst mal die Grundfunktionalität 
darstellen, ohne mich jetzt schon beim Hühnerfutter um die 
Bestellnummern kümmern zu müssen. Beim "basteln" kümmere ich mich eh 
nicht darum, da wird der vorhandene 0805 10k Widerstand aufgelötet.

Lukas K. schrieb:
> Was fehlt? Man kann auch erstmal generische Bauteile (nur Entity) ohne
> Part platzieren und erst gegen Ende Parts zuweisen, wenn einem das so
> besser gefällt.

Wie geht das? Oder anders formuliert: Wie kann ich im Schaltplaneditor 
einem generischen Bauteil einen Wert zuweisen?

Auch würde dieses Vorgehen die Bauteilebibliotheken gewaltig aufblähen. 
Grad bei Widerständen wird wird oft eine ganze Serie in dem Datenblatt 
über einen Kamm geschert und oft noch nicht mal genaue Abmessungen der 
Lötpads angegeben nur z.B. 0805.

[Stefan S. (Gast)]

tester schrieb:
> Hm...

Gut, dann hast Du es auch noch nicht verstanden :-)

Ich würde einen Auswahlprozess bevorzugen, wo ich zunächst z.B. nur 
"Diode", "Widerstand" oder "OpAmp" wähle. Weil ich ja oft noch gar nicht 
genau weiss was ich später genau haben will. Nachteil ist, dass man 
später sämtliche Elemente exakt spezifizieren muss, also etwa für alle 
Kondensatoren den Footprint eintragen. Wenn man gleich eine Kondensator 
mit Footprint gewäht hätte, hätte man diesen einfach nur kopieren können 
und wäre fertig -- etwa für die Abblockkondensatoren.

Und dann möchte ich, dass man zunächst etwa "Widerstand" wählt, und erst 
dann das Bildchen dazu, also Kästchen oder ZickZack. Und dieses Bildchen 
soll man später auch ändern können.

Bei OpAmp möchte ich OpAmpSingle wählen können, und dann entweder ein 
Bildchen mit VCC/VEE oder zwei separate Bildchen, eins für In+/In-/Out 
und eins für Power.

Grundsätzlich wäre der Dialog bei mir: Bauteil wählen, das durch seine 
Pins spezifiziert ist. Jeder Pin hat einen Namen wie etwa Vcc oder ARef. 
Dann die Bildchen wählen, wobei eine Map_Datei die ursprünglichen Pins 
den Pins des Bildchens zuordnet. Eine weitere Map_Datei ordnet den Pins 
die Pads im  Footprint zu.

Ja, wenn  man selbst überlegt statt irgendeine andere EDA Software 
abzukupfern, dann ist es nicht ganz so einfach.

Na ich werde demnächst erst mal meinen Ruby Schaltplaneditor nach Nim 
portieren, vorläufig bleibe ich beim gEDA Fileformat. Später lese ich 
dann noch mal Lukas Ideen nach.

[Lukas K. (carrotindustries)]

tester schrieb:
> Hm... irgendwie widersprichst du dir da. Ich kann zwar generische Parts
> plazieren, z.B. den "base 0805 resistor"

Du kannst auch Components platziern, "place component" heißt das tool 
dazu. Da ist dann weder Package noch Part noch Wert daran. Die Netzliste 
kennt nur Components mit Entities. Optional kann dann dem Component ein 
Part zugewiesen werden, wobei die Entity des Parts gleich der Entity des 
Components sein muss.



tester schrieb:
> Auch würde dieses Vorgehen die Bauteilebibliotheken gewaltig aufblähen.

Jedes Part im Pool braucht eine MPN, damit man einfach die BOM erzeugen 
kann.

Stefan S. schrieb:
> Ich würde einen Auswahlprozess bevorzugen, wo ich zunächst z.B. nur
> "Diode", "Widerstand" oder "OpAmp" wähle. Weil ich ja oft noch gar nicht
> genau weiss was ich später genau haben will.

Genau so ist es. Siehe oben.

Stefan S. schrieb:
> Grundsätzlich wäre der Dialog bei mir: Bauteil wählen, das durch seine
> Pins spezifiziert ist. Jeder Pin hat einen Namen wie etwa Vcc oder ARef.
So ist es hier auch.

> Dann die Bildchen wählen, wobei eine Map_Datei die ursprünglichen Pins
> den Pins des Bildchens zuordnet.
Theoretisch können einer Unit mehrere Symbole zugeordnet sein.

> Eine weitere Map_Datei ordnet den Pins
> die Pads im  Footprint zu.
Ist bei horizon im Part mit drin.

[Helmut S. (helmuts)]

Hallo Lukas,

was macht denn "smash" mit einem Bauteil im Schaltplan bzw. im 
PCB-Layout?

Ich sehe da keinerlei Änderung des Bauteils, wenn ich "smash" wähle.

[tester (Gast)]

Lukas K. schrieb:
> tester schrieb:
>> Hm... irgendwie widersprichst du dir da. Ich kann zwar generische Parts
>> plazieren, z.B. den "base 0805 resistor"
>
> Du kannst auch Components platziern, "place component" heißt das tool
> dazu. Da ist dann weder Package noch Part noch Wert daran. Die Netzliste
> kennt nur Components mit Entities. Optional kann dann dem Component ein
> Part zugewiesen werden, wobei die Entity des Parts gleich der Entity des
> Components sein muss.

Ok, jetzt wird mir die Vorgehensweise klarer. Aber ist das "zuweisen" 
nicht eher ein "ersetzen"? Wenn ich meinem Component "two terminal 
resistor" ein "base 0805 resistor" zuweise, ist mein Value Wert "10k" 
wieder weg. Also muss letzten Endes genau ein Part mit den nötigen 
Werten existieren.

Ok, das geht schnell, mit "Create Part from Part" im Pool Manager. Ok, 
verstanden, nicht die schnellste Lösung aber machbar.

[Lukas K. (carrotindustries)]

Helmut S. schrieb:
> Ich sehe da keinerlei Änderung des Bauteils, wenn ich "smash" wähle.

Da hat wohl einer nie EAGLE benutzt ;) Smash macht, dass man im 
Schaltplan und Board die einem Symbol/Package zugeordneten Texte 
verschiebbar werden. Braucht man also spätestens wenn man auf dem Board 
die Silkscreen-Texte verschieben will.

tester schrieb:
> Also muss letzten Endes genau ein Part mit den nötigen
> Werten existieren.

Genau, einen Widerstand mit einem Wert den man eintippt kann man nicht 
bei Digikey kaufen.

> Ok, das geht schnell, mit "Create Part from Part" im Pool Manager. Ok,
> verstanden, nicht die schnellste Lösung aber machbar.

Es ist Leuten auch freigestellt, Parts mit Skripten en masse zu 
erzeugen, wenn man z.B. eine ganze Serie von Widerständen einpflegen 
will.

[Jörg W. (dl8dtl) (Moderator)]

Lukas K. schrieb:
> Braucht man also spätestens wenn man auf dem Board die Silkscreen-Texte
> verschieben will.

Eigentlich eins der Features, die ich nach dem Weggang von Eagle nie
vermisst habe – jetzt, wo du es sagst.

Wenn man einen Text verschieben will, fasst man ihn einfach an und
schiebt ihn.  Während des Schiebens wird sinnvoller Weise eine Linie
dargestellt, zu welchem Bauteil der Text denn gehört.  Dabei ist es
ziemlich egal, ob ich nun gerade im Layout oder im Schaltplan bin;
Texte aus dem Weg zu schieben, braucht man in beiden.

Wenn überhaupt, dann braucht man eher das Gegenteil mal: für ein
bestimmtes Bauteil die Texte auf Standardanordnung zurücksetzen. Habe
ich aber, ehrlich gesagt, auch höchst selten Bedarf dafür.

Könnte eigentlich Horizon in einer VMware laufen?  Das wäre eine
Variante, wie ich mir mal sowas wie das genannte Xubuntu 17.10 parallel
zu Produktivsystemen installieren könnte, um Horizon zu testen.
Bezüglich 3D in der VM: Altium Designer hat kein Problem damit, und
läuft durchaus flüssig.

[tester (Gast)]

Ok, jetzt zum Pool Manager. Ich habe versucht, einen 2x2- Pin Header 
anlegen (für den RPi). Es gab ja nur einen Padstack mit Loch, der war 
mir zu klein. Ich wollte einen neuen anlegen, habe aber nicht geschafft, 
ihm einen Namen zuzuweisen.  Edit: Ok, gefunden, man muss im Editor auf 
den "Pfeil nach unten" klicken. Ok, wenn man es nicht weiß... die 
Menüzeilen von Horizon sind nicht gerade intuitiv. Ich hätte jetzt eher 
in einem Menü Datei gesucht, z.B. "Set Name". Dort könnte man auch das 
"Save" unterbringen.

Aber: wie werde ich meine missglückten Versuche wieder los?

[tester (Gast)]

tester schrieb:
> 2x2- Pin Header

Natürlich 2x20.

[tester (Gast)]

Jetzt hänge ich. Was muss ich wo eintragen, damit ich das Part 
erfolgreich speichern kann?

[Lukas K. (carrotindustries)]

Jörg W. schrieb:
> Lukas K. schrieb:
>> Braucht man also spätestens wenn man auf dem Board die Silkscreen-Texte
>> verschieben will.
>
> Eigentlich eins der Features, die ich nach dem Weggang von Eagle nie
> vermisst habe – jetzt, wo du es sagst.

Schön ist's nicht so hat sich das leider ergeben... Mal sehen ob mir in 
Zukunft da noch was besseres einfällt. Man kann ja auch einfach alles 
markieren und smash drücken.

> Könnte eigentlich Horizon in einer VMware laufen?  Das wäre eine
> Variante, wie ich mir mal sowas wie das genannte Xubuntu 17.10 parallel
> zu Produktivsystemen installieren könnte, um Horizon zu testen.
> Bezüglich 3D in der VM: Altium Designer hat kein Problem damit, und
> läuft durchaus flüssig.

Könnte gut funktionieren wenn VMWare OpenGL 3 kann.

tester schrieb:
> Aber: wie werde ich meine missglückten Versuche wieder los?

Im Dateimanager dies JSON-Dateien löschen. Wie oben geschrieben, soll 
was einmal im Pool ist eigentlich drin bleiben, daher kann der Pool 
Manager nichts löschen.

tester schrieb:
> Ok, gefunden, man muss im Editor auf
> den "Pfeil nach unten" klicken.

Seit gerade eben gibt es da nun einen Platzhaltertext.

tester schrieb:
> Der interaktive Router mit walk-around und PnS ist
> wirklich schon brauchbar!

Ich will mich hier jetzt nicht mit fremden Federn schmücken, das ist 
einfach der Router, den Leute am CERN für KiCad gebaut haben. Ich hab' 
den nur eingebaut.

tester schrieb:
> Aber nochmal Lob an Lukas, bisher gute Arbeit!

Danke für die Blumen :)

Uwe B. schrieb:
> wirst Du auf der FOSDEM im EDA Devroom vortragen?

Ist eingereicht, mal sehen ob's akzeptiert wird ;)

tester schrieb:
> Jetzt hänge ich. Was muss ich wo eintragen, damit ich das Part
> erfolgreich speichern kann?

Okay, jetzt wo ich das so seh' ist "Location" der falsche Name für die 
Felder. Filename wäre besser, weil da der volle Dateiname mit 
.json-Endung rein muss.

[Possetitjel (Gast)]

Stefan S. schrieb:

> Ich würde einen Auswahlprozess bevorzugen, wo ich zunächst
> z.B. nur "Diode", "Widerstand" oder "OpAmp" wähle. Weil
> ich ja oft noch gar nicht genau weiss was ich später genau
> haben will.

Ahh. Ich bin also doch nicht GANZ allein. Danke, Stefan.

> Nachteil ist, dass man später sämtliche Elemente exakt
> spezifizieren muss, also etwa für alle Kondensatoren den
> Footprint eintragen.

Um diese Zuordnung zu erleichtern, kann man vom User
wählbare Standardannahmen vorsehen. So kenne ich das
auch aus der Praxis: "Wenn nix anderes gesagt wird, ist
Hühnerfutter immer 0805" -- nur als Beispiel.

> Wenn man gleich eine Kondensator mit Footprint gewäht
> hätte, hätte man diesen einfach nur kopieren können
> und wäre fertig -- etwa für die Abblockkondensatoren.

Naja, das entspricht nicht meiner Denk- und Arbeitsweise.

Wenn ich einen Schaltplan male, will ich nicht darüber
nachdenken müssen, welche Prüfspannung und welche Belast-
barkeit der Widerstand haben muss -- da will ich nur
einen abstrakten, idealen Widerstand in die Schaltung
einfügen.

Wenn die Schaltung dimensioniert ist, guckt man sowieso
häufig nochmal durch, ob sich das benötigte Bauelemente-
sortiment verkleinern lässt.

> Und dann möchte ich, dass man zunächst etwa "Widerstand"
> wählt, und erst dann das Bildchen dazu, also Kästchen
> oder ZickZack. Und dieses Bildchen soll man später auch
> ändern können.

Genau. Das ärgert mich auch immer. -- Dazu braucht man
aber eine Taxonomie für die Bauteile; die Symbole müssten
entsprechende Tags mitbringen, die angeben, in welche
Äquivalenzklasse sie gehören. Rein elektrisch ist ja
scheissegal, ob da ein Ami- oder ein DIN-Widerstand drin
ist.

Eigentlich wünsche ich mir, dass man einen Schaltplan
mit Ami-Symbolen laden und per Knopfdruck alles auf
Euro-Symbole umstellen kann.

> Bei OpAmp möchte ich OpAmpSingle wählen können, und dann
> entweder ein Bildchen mit VCC/VEE oder zwei separate Bildchen,
> eins für In+/In-/Out und eins für Power.

Ahh. Die Idee ist gut. Man bräuchte einen DRC für den Schalt-
plan und entsprechende Entwurfsregeln, die angeben, dass jeder
"abstrakte" OPV auch eine Stromversorgung braucht.

Eigentlich bräuchte man zwei Schaltpläne bzw. zwei Ansichten:
Eine mit der "abstrakten" Schaltung, und eine, aus der die
Zuordnung hervorgeht, welcher abstrakte OPV zusammen mit
welchen anderen in einem Gehäuse steckt. Hier müsste man
festlegen (können), wo Pinswap/Gateswap zugelassen ist und
wo nicht.

> Grundsätzlich wäre der Dialog bei mir: Bauteil wählen, das
> durch seine Pins spezifiziert ist.

Ja -- wobei das "abstrakte" Pins sind, nicht die greifbaren
Anschlüsse am Gehäuse.

> Jeder Pin hat einen Namen wie etwa Vcc oder ARef. Dann die
> Bildchen wählen, wobei eine Map_Datei die ursprünglichen
> Pins den Pins des Bildchens zuordnet. Eine weitere Map_Datei
> ordnet den Pins die Pads im Footprint zu.

Angewandte Graphentheorie.
Die (topologische) Struktur des Schaltplans ändert sich nicht,
wenn ein Bauteil durch ein äquivalentes oder verträgliches
Bauteil ersetzt wird. Ein Festwiderstand lässt sich (topologisch)
äquivalent durch einen anderen Festwiderstand oder einen
ungepolten Kondensator ersetzen; verträgliche Ersetzung geht
durch einen Elko oder eine Diode; Ersetzung durch einen Transistor
geht nicht.
Konkrete Bauteile oder gar Footprints kommen erst viel später
ins Spiel.

> Na ich werde demnächst erst mal meinen Ruby Schaltplaneditor
> nach Nim portieren,

Warum? Ist dir Ruby nicht mehr exotisch genug?

> vorläufig bleibe ich beim gEDA Fileformat.

Schön. -- Totgesagte leben übrigens länger: Im Chat sagte der
Boss von pcb-rnd, dass auch ein Fork für gschem in Arbeit ist.

[Stefan S. (Gast)]

Possetitjel schrieb:
> Warum? Ist dir Ruby nicht mehr exotisch genug?

Ruby mit seinem Bytecode-Interpreter und dynamischer Typisierung wäre 
heute wie auch Python eben nicht mehr meine erste Wahl. 2010 als ich mit 
Ruby anfing war das noch anders, da gab es all die interessanten neuen 
Sprachen noch nicht. Und die GTK3-Unterstützung von Ruby ist wohl auch 
nicht mehr ganz so toll, Ruby-GTK scheint auch kaum jemand noch zu 
verwenden. Und Ruby ist in den letzten Jahren ja (leider) vom Python 
weitgehend abgehängt worden.

Aber bei den neuen Sprachen hat man nahezu die Geschwindigkeit von C und 
die Einfachheit bzw. das Abstraktionsniveau von Ruby/Python. Und für 
grössere Projekte bietet die statische Typisierung Vorteile. Ob nun Nim 
die beste Wahl war wird man dann in 10 Jahren sehen -- mir scheint es 
momentan die universellste Sprache zu sein, und ich habe auch schon 
einige Zeit in die GTK Bindings investiert. Aber ich wüsste fast ein 
Dutzend weiterner sehr interessanter Sprachen -- Crystal hätte sich 
vielleicht noch eher angeboten, da es Ruby sehr ähnlich ist.

[Possetitjel (Gast)]

Stefan S. schrieb:

> Possetitjel schrieb:
>> Warum? Ist dir Ruby nicht mehr exotisch genug?
>
> Ruby mit seinem Bytecode-Interpreter und dynamischer
> Typisierung wäre heute wie auch Python eben nicht mehr
> meine erste Wahl.

Dynamische Typisierung sehe ich ein -- aber wen interessiert
der Bytecode?

Wenn es WIRKLICH nicht schnell genug läuft, muss man über
einen besseren Algorithmus nachdenken oder die kritischen
Teile in eine "richtige" Programmiersprache übertragen.

Scriptsprachen sehe ich als Werkzeug für "Rapid Prototyping".

> Und die GTK3-Unterstützung von Ruby ist wohl auch nicht
> mehr ganz so toll, Ruby-GTK scheint auch kaum jemand noch
> zu verwenden. Und Ruby ist in den letzten Jahren ja (leider)
> vom Python weitgehend abgehängt worden.

Die Logik erschließt sich mir nicht.

Wer auf der Suche nach seiner ersten Scriptsprache ist, ist
natürlich ziemlich frei in seiner Entscheidung -- und wird
sich auch bei sehr neuen Sprachen umsehen.

Wer eine Sprache halbwegs beherrscht und ein konkretes Problem
lösen will -- warum sollte der freiwillig wechseln?

Was der Anwendungssoftware fehlt, ist doch nicht technischer
Schnickschnack, sondern echte Integration in die Arbeits-
abläufe. Das hängt nicht von der Programmiersprache ab.

> Aber bei den neuen Sprachen hat man nahezu die Geschwindigkeit
> von C

Wann braucht man das?
Was C vor 20 Jahren konnte, kann heute eine Scriptsprache.

> Und für grössere Projekte bietet die statische Typisierung
> Vorteile.

Ja -- den Punkt kann ich nachvollziehen.
(Bei dynamischer Typisierung weiss man nicht, wo man die
Kommentare hinschreiben soll -- SCNR)

> Ob nun Nim die beste Wahl war wird man dann in 10 Jahren
> sehen -- mir scheint es momentan die universellste Sprache
> zu sein, und ich habe auch schon einige Zeit in die GTK
> Bindings investiert.

Gerade im Kontext dieses Threads verstehe ich das nicht.

Ich konnte von Deinem Schaltplaneditor nur eine uralte
Version ausprobieren, weil bei mir zufälligerweise nur
GTK2 (und nicht GTK3) installiert ist.
Als Grund für GTK habe ich das Anti-Aliasing beim Rendering
herausgelesen.

Also habe ich experimentiert. Die gEDA-Symbole sehen ohne
Antialiasing übel aus. Man kann Antialiasing mit Standard-Tk
emulieren, wenn man Symbole mit unterschiedlichen Linienbreiten
grau und schwarz übereinanderdruckt. Nicht gerade elegant, aber
es sieht VIEL besser aus -- und funktioniert mit Standard-Tk.

Wozu nochmal genau brauche ich GTK3?

[tester (Gast)]

Noch was zu den Padstacks: Bei den Parametern habe ich den "Text" 
einfach von vorhanden TH Pad kopiert. Das sieht alles nach RPN aus, 
Forth?
Was ist der Hintergrund, hier ein Script einzubauen?

[Stefan S. (Gast)]

Possetitjel schrieb:

>Als Grund für GTK habe ich das Anti-Aliasing beim Rendering
>herausgelesen.

Nein. GTK hat mit dem Rendering nichts zu tun. Ich zeichne derzeit mit 
Cairo, da es einfach zu nutzen ist und sehr gute Qualität liefert. Auch 
Bezier-Kurven, und Backends wie PDF. Vor GTK 3.16 gab es noch keine 
GL-Area, da war die Nutzung von OpenGl in GTK Anwendungen schwierig und 
aufwendig. Ich werde erstmal bei Cairo bleiben. Wirklich schöne Grafiken 
sind mit GL nicht so einfach realisierbar.


> Wozu nochmal genau brauche ich GTK3?

Woher soll ich wissen was Du brauchst. Vielleicht kommst Du ja auch ganz 
ohne Computer aus?

Wenn Du jetzt meinst gegenüber GTK2? Das wird ja seit Jahren nicht mehr 
gepflegt -- will das noch irgendwer nutzen? Und ob Ruby mit GTK2 besser 
funktioniert, weiss ich nicht -- 2011 ging Ruby 1.8 mit GTK2 in der Tat 
recht gut.

Aber Sprachen wie Ruby/Python mit Bytecode-Interpreter sind halt eher 
etwas langsam. Da ist selbst Go und Haskell weit schneller. Tatsächlich 
gibt es nur wenige Fälle, wo Performance egal ist. Bei EDA braucht man 
schon etwas Leistung, und man möchte halt nicht immer den neuesten 
Rechner kaufen müssen, der einem dann mit Volllast den Akku leersaugt.

[Lukas K. (carrotindustries)]

tester schrieb:
> Was ist der Hintergrund, hier ein Script einzubauen?

Horizon kann Padstacks die aus mehreren Shapes zusammengesetzt sind, 
z.B. "SMD half obround". Um Dinge wie Größe, Abstand der Lötstopmaske, 
etc. anzupassen müssen Position und Größe der einzelnen Shapes 
entsprechend angepasst werden. Die simpelste Lösung, die mir dazu 
einfiel, war eben Padstacks ein Skript beizulegen was dies anhand der 
Parameter macht. Eine "richtige" Skriptsprache wie Python oder TCL 
wollte ich an der Stelle nicht haben, da die Skripte nicht beliebig 
lange laufen dürfen. Dokumentiert ist die Sprache an dieser Stelle: 
https://github.com/carrotIndustries/horizon/wiki/Parameter-programs

[Possetitjel (Gast)]

Stefan S. schrieb:

> Possetitjel schrieb:
>
>>Als Grund für GTK habe ich das Anti-Aliasing beim
>>Rendering herausgelesen.
>
> Nein. GTK hat mit dem Rendering nichts zu tun.

Dann verstehe ich's nicht.


>> Wozu nochmal genau brauche ich GTK3?
> [...]
>
> Wenn Du jetzt meinst gegenüber GTK2?

Nein, ich meine z.B. gegenüber Tk.

Tcl/Tk ist der historische Ursprung; Tkinter (Python) ist
mW Standard; Perl/Tk und Ruby/Tk sind zumindest verfügbar.

Wenn man eine ausgesprochene Nischenanwendung (wie EDA) im
Sinn hat, wäre es doch logisch, die rein technischen Hürden
niedrig zu halten, damit von den ohnehin wenigen potenziellen
Mitstreitern nicht auch noch welche durch vermeidbare
Komplikationen abgeschreckt werden.

Davon ist z.B. beim Original-gEDA auch nix zu merken (Scheme?!
Warum denn nicht gleich Brainfuck?); pcb-rnd proklamiert aber,
es besser zu machen.

Du schriebst, Du habest reichlich "Zeit in die GTK-Bindings
investiert" (was immer das heissen mag).
Entschuldige mein tiefgreifendes Unwissen, aber ich habe
(mangels Wissen und mangels Bedarf) noch nie Zeit in irgend
welche Tcl-Bindings investiert. In meinem Script steht etwas
wie "canvas .c; pack .c", und dann kann ich loszeichnen.

Das geht, soweit ich gehört habe, so ähnlich auch in python,
ruby oder perl. Was fehlt noch?

> Aber Sprachen wie Ruby/Python mit Bytecode-Interpreter sind
> halt eher etwas langsam.

Ja und?

Das Problem bei dem ganzen EDA-Krempel liegt doch nicht in der
internen Verwaltung der Daten, sondern in der Wechselwirkung
von GUI und Arbeitsablauf.
Da man sowieso eine Trennung von GUI und Geschäftslogik haben
will, kann man die Datenhaltung auch in irgendwas compiliertes
auslagern, wenn die Zeit dafür reif ist. (Schätzungsweise
könnte man das sogar einer SQL-Datenbank beibringen.)

Niemand sagt, dass die Anwendung vollständig und auf Dauer in
einer Scriptsprache geschrieben sein muss -- aber es ist ein
guter Startpunkt, um das GUI und die eigene Arbeitsweise
aneinander anzupassen.

> Da ist selbst Go und Haskell weit schneller.

Mich würde mal ein detailierter Vergleich zwischen Ruby und
Tcl interessieren -- nicht wegen "Meiner ist länger", sondern
um eine sachliche Entscheidungsgrundlage zu haben.

Da ich ausschließlich Tcl verwende, kann ich nicht vergleichen.

> Tatsächlich gibt es nur wenige Fälle, wo Performance egal
> ist.

Du möchtest doch jetzt nicht ernsthaft behaupten, dass
Graphikkarten mit Füllraten im GPixel/s-Bereich und Prozessoren
mit GFLOPS/s nicht schnell genug sind, ein paar Dutzend
zweidimensionale (!) schwarz-weisse (!) Symbole anständig auf
den Bildschirm zu bringen?

> Bei EDA braucht man schon etwas Leistung,

Das wäre erst noch zu beweisen.

Was schätzungsweise wirklich Leistung braucht, ist diese
schreckliche Zoomerei mit dem Mausrad, die ja leider Standard
ist. Die Schaltplansymbole rendern könnte auch ein Z80, die
Verbindungen legen und auf Mausereignisse reagieren auch.

> und man möchte halt nicht immer den neuesten Rechner kaufen
> müssen, der einem dann mit Volllast den Akku leersaugt.

Natürlich, da sind wir einer Meinung.

Die Kernfrage ist aber, was man mit der verfügbaren Leistung
anfängt.

Beim Herumlesen auf Deiner Homepage hatte ich (schon vor
Jahren) Hoffnung geschöpft, weil Du einige aus meiner Sicht
ziemlich kluge Entscheidungen getroffen hast:
- Du hast Dich auf einen Schaltplaneditor beschränkt,
- Du hast gute Ergonomie als ausdrückliches Ziel formuliert,
- Du hast Dich aus dem Symbolvorrat von gEDA bedient und
- Du hast rapid-prototyping-mäßig eine Scriptsprache verwendet.

Leider ist programmiertechnisch unsere Schnittmenge leer; Du
verwendest Ruby/GTK3 (mit Kurs auf Nim/GTK3), ich bin bei
Tcl/Tk. Bis Ruby/Tk oder Tcl/GTK könnte ich Dir wahrscheinlich
auf längere Sicht entgegenkommen, aber mehr kann ich nicht
leisten. GUI-Toolkit UND Sprache wechseln kann ich nicht.

Also wird es wohl auf dem Stand bleiben, den Du enttäuscht
beklagt hast: Es interessiert sich (scheinbar) niemand für
Deine Software.

[Stefan S. (Gast)]

>Du schriebst, Du habest reichlich "Zeit in die GTK-Bindings
>investiert" (was immer das heissen mag).
>Entschuldige mein tiefgreifendes Unwissen, aber ich habe
>(mangels Wissen und mangels Bedarf) noch nie Zeit in irgend
>welche Tcl-Bindings investiert.

Solche Bindings fallen ja nicht so einfach vom Himmel. Für Nim gibt es 
zwar das Tool c2nim das einem für low-level Bindings viel Arbeit 
abnimmt, aber es bleibt doch viel Arbeit. Und auch mit 
gobject-introspection, mit dessen Hilfe ich die High-Level Bindings 
gemacht habe, bleibt es viel Arbeit.

Aber die Leute, die Bindings für andere Sprachen wie Python, Ruby, Perl, 
C++ usw. gemacht haben hatten wohl noch weit mehr Arbeit.

>Du möchtest doch jetzt nicht ernsthaft behaupten, dass
>Graphikkarten mit Füllraten im GPixel/s-Bereich und Prozessoren
>mit GFLOPS/s nicht schnell genug sind, ein paar Dutzend
>zweidimensionale (!) schwarz-weisse (!) Symbole anständig auf
>den Bildschirm zu bringen?

Ja bei Linux ist das  leider so, sofern die CPU das Rendering macht. 
Cairo wie auch Skia und andere CPU Rendering Bibliotheken sind nicht 
besonders schnell. Daher hat Lukas ja auch gleich OpenGL verwendet. 
Wobei auch OpenGl für hochqualitative Liniengraphiken nicht so 
sonderlich schnell ist. Für Cairo gibt es ein OpenGL Backend, das aber 
langsamer als das CPU Backend ist.

Intel werkelt ja gerade an FastUIDraw, und GTK4 hat ein Vulkan Backend. 
Zusammen mit Wayland wird es dann hoffentlich alles deutlich schneller.

>Was schätzungsweise wirklich Leistung braucht, ist diese
>schreckliche Zoomerei mit dem Mausrad, die ja leider Standard
>ist. Die Schaltplansymbole rendern könnte auch ein Z80, die
>Verbindungen legen und auf Mausereignisse reagieren auch.

Auch wenn Du Dinge verschiebst musst Du ja die aufgedeckte Fläche neu 
Zeichnen, für jeden Maustick neu, also bis zu 60 mal pro Sekunde. Und 
wenn man sich das Leben sehr einfach machen will, zeichnet man jeweils 
den kompletten Screen komplett neu. Mit OpenGL kann man das machen, mit 
CPU-Rendering stösst man da aber schnell an Grenzen. Man kann dann aber 
für Objekte Bounding-Boxen definieren und zeichnet jeweils nur das, was 
unter dem sich bewegenden Object ist neu. Ist aber etwas mehr 
Programmierarbeit.

>ich bin bei Tcl/Tk.

Gibt es denn überhaupt noch ernsthafte Software mit grösserem 
Anwenderkreis die das verwendet? Mir fällt da nicht viel ein.

[Possetitjel (Gast)]

Stefan S. schrieb:

>>Du schriebst, Du habest reichlich "Zeit in die GTK-
>>Bindings investiert" (was immer das heissen mag).
>>Entschuldige mein tiefgreifendes Unwissen, aber ich
>>habe (mangels Wissen und mangels Bedarf) noch nie
>>Zeit in irgend welche Tcl-Bindings investiert.
>
> Solche Bindings fallen ja nicht so einfach vom Himmel.

Nein, natürlich nicht.

Mir dämmert aber langsam, dass wir möglicherweise in
verschiedenen Welten leben.

In Tcl hat man von Hause aus Zugriff auf das Tk, dessen
Canvas komplette Graphik (inklusive PostScript-Export)
bietet. Im Prototyp-Stadium ist also ohnehin klar, dass
die Graphikausgabe von Tk erledigt wird; damit kann man
das GUI, die Benutzerführung usw. erproben und schon
kleinere Projekte bearbeiten.

Falls man später schnellere Graphik braucht (was bisher
bei mir noch nie der Fall war), muss man zu einer externen
Bibliothek übergehen oder die Anwendung portieren -- aber
dann ist die Grundstruktur des Programmes schon in der
Praxis getestet.

Deswegen sind mir die "richtungsweisenden" Diskussionen
über die beste Graphikbibliothek bisher verschlossen
geblieben -- man will sowieso zuerst einen Prototypen in
einer Scriptsprache bauen, und welche Graphik der verwendet,
steht bei mir sowieso fest.

>>Du möchtest doch jetzt nicht ernsthaft behaupten, dass
>>Graphikkarten mit Füllraten im GPixel/s-Bereich und
>>Prozessoren mit GFLOPS/s nicht schnell genug sind, ein
>>paar Dutzend zweidimensionale (!) schwarz-weisse (!)
>>Symbole anständig auf den Bildschirm zu bringen?
>
> Ja bei Linux ist das  leider so, sofern die CPU das
> Rendering macht. Cairo wie auch Skia und andere CPU
> Rendering Bibliotheken sind nicht besonders schnell.

Naja, wie schon gesagt: Tk bietet einen komplett graphik-
fähigen Canvas; um die Benutzerführung usw. zu testen,
war der mir bisher schnell genug.

Da man Programmlogik und Userinterface sowieso programm-
technisch trennen will, sollte die Einbindung einer
externen Graphikbibliothek kein Hexenwerk sein, wenn das
notwendig wird. Habe ich aber noch nie gemacht.

> Auch wenn Du Dinge verschiebst musst Du ja die aufgedeckte
> Fläche neu Zeichnen, für jeden Maustick neu, also bis zu
> 60 mal pro Sekunde.

Naja.

> Und wenn man sich das Leben sehr einfach machen will,
> zeichnet man jeweils den kompletten Screen komplett neu.

Ja -- jetzt kommen wir der Wahrheit näher: Schonender
Umgang mit der Rechenleistung macht den Programmierern
einfach keinen Spaß.

Es ist ja auch viel leichter, die Schuld auf die schlechten
APIs zu schieben, als Algorithmen zu entwickeln, die mit
wenig Rechen-/Graphikleistung auskommen.

> Mit OpenGL kann man das machen, mit CPU-Rendering
> stösst man da aber schnell an Grenzen.

Ja -- wie der Zyniker in mir schon sagte: Software zu
schreiben, die TROTZ beschränkter Ressourcen gut bedienbar
ist, ist einfach nicht hipp. Also macht es keiner.

>>ich bin bei Tcl/Tk.
>
> Gibt es denn überhaupt noch ernsthafte Software

Vereinzelt bin ich über solche gestolpert; kann aber aus dem
Hut keine Namen nennen. Tcl/Tk wird aktiv weiterentwickelt;
Version 8.6 bringt ziemlich viele Erweiterungen.

Ich sehe das auch nicht als Werkzeug, um auf Dauer größere
Applikationen zu entwickeln. Für rapid prototyping finde
ich es ideal.

> mit grösserem Anwenderkreis die das verwendet? Mir fällt
> da nicht viel ein.

Mir auch nicht -- aber ich gestehe, dass mir das VOLLSTÄNDIG
egal ist. Tcl/Tk kann (fast) alles, was ich brauche, um zu
einem für mich akzeptablen Ergebnis zu kommen. (Numerik geht
nicht gut; das ist ein Furunkel am Arsch. Umgang mit Binär-
dateien ist grenzwertig.)

In der alten Firma gab's eine recht lustige Arbeitsteilung:
Unser Programmierer hat kein Tcl verwendet, fand es aber
einfach genug zu lesen, um die von mir zusammengenagelten
Prototypen verstehen und in die offizielle Applikation
integrieren zu können. Das war ziemlich cool.

[tester (Gast)]

So, ich habe mir jetzt mal die Mühe gemacht und einen Schaltplan 
gezeichnet. Dazu noch ein paar Anmerkungen:

- Im Prinzip ist alles da! Manches ist nur etwas umständlich. Horizon 
ist mir dabei aber nicht abgestürzt. Ist also schon relativ stabil!

- Im Schaltplan Editor erkennt Horizon nicht, wenn zwei Pins von 
Bauteilen auf einer Junction liegen. Im angehängten Beispiel ist z.B. C5 
und C6 nicht verbunden. Wenn man das Bauteil verschiebt (vom Juction 
weg), erkennt Horizon, dass es nicht verbunden ist.

- Ich habe ein paar Bauteile angelegt. Am einfachsten geht Hühnerfutter, 
die kann man sehr schön im Horizon Pool Manager durch "Make Part from 
Part" anlegen. Dabei kann man sowohl den Pool Manager als auch den 
Projekt Manager mit Schema und PCB offen lassen. Nach dem Anlegen bzw. 
einem "Update Pool" sind die Bauteile vorhanden

- Etwas komplizierter sind ganz neue Bauteile. Ich bin meist so 
vorgegangen, dass ich erst im Pool Manager ein Package angelegt und dann 
den Part Wizard gestartet habe. Das funktioniert soweit. Nervig sind nur 
die vielen Eintragungen am Ende des Managers. Siehe 
Beitrag "Re: Neues, halbfertiges Elektronik-CAD-Programm"

Oft trägt man doch immer die gleichen Verzeichnisse ein. Z.b. für den 
Wolfson WM8731 Codec:

tester@Yoga:~/horizon/horizon-pool$ find . -iname "*8731*"
./units/ic/codec/wolfson/WM8731.json
./symbols/ic/codec/wolfson/WM8731.json
./entities/ic/codec/wolfson/wm8731.json
./parts/ic/codec/wolfson/WM8731.jsonn

Evtl. könnte man das sinnvoll vorbelegen. Wenn man z.B. des Filenamen 
für die Entity eingegeben hat, dass für Untits, Symbols und Parts das 
automatisch übernommen wird. Wichtig ist dann noch, die Units und 
Entities  durchzugehen, um fehlende Einträge zu ergänzen, wie z. B. den 
Prefix bei Entities.

- Padstack. Ich habe mir alle Pads, die ich benötige, neu angelegt. 
Später bin ich dann drauf gekommen, dass man wohl vorhandene Pads neu 
skalieren kann. Trifft das zu?

- Raster: Beim Bearbeiten von Schaltplänen und Packages kann ich kein 
Raster (mehr) einstellen. Dachte, dass dies schon mal ging. Wenn man 
Objekte mit gedrückter ALT Taste verschiebt, kann man zwar das Raster 
ausschalten, aber beim Versuch, mit der linken Maustaste die neue 
Position festzulegen, hüpft dann das Objekt trotzdem wieder auf einem 
Rastpunkt. Wenn man ALT gedrückt hält, wird der Mausklick nicht 
angenommen.

- Auch das Ausrichten eines neuen Objekts an bestehenden Objekten nervt 
manchmal, z.b. wenn man im Schaltplan Objekte dicht nebeneinander 
platzieren möchte. Kann man dies ausschalten?

- Variabler Text: Gibt es neben $RD bei den Packages und $REFDES und 
$VALUE bei den Symbolen weitere?

- Neue Bauelemente: Ich habe ja nun ein paar angelegt, bin mir aber 
unsicher, ob ich die hochladen soll, da die sicher noch Fehler haben.

Fazit: Auch wenn es noch nicht ganz rund läuft, kann man mit Horizon 
schon arbeiten. Lob!

[tester (Gast)]

Noch was: Horizon meckert ja, wenn man zwei Netze den selben Namen gibt. 
Man muss ja den Namen, wenn er schon mal vorhanden ist, per "Move net 
segment to other net" oder "Move net segment to new net" zuweisen. Was 
spricht dagegen, Horizon dies implizit machen zu lassen, wenn ein 
Netzname eingegeben wird der schon mal vorhanden ist? Weil der Netzname 
intern an einer UUID hängt?

Powersymbole habe ich gar nicht verwendet, sondern bin nur über die 
Netznamen gegangen. Irgend welche Nachteile?

[Lukas K. (carrotindustries)]

tester schrieb:
> So, ich habe mir jetzt mal die Mühe gemacht und einen Schaltplan
> gezeichnet. Dazu noch ein paar Anmerkungen:

Vielen, vielen Dank!

> - Im Prinzip ist alles da! Manches ist nur etwas umständlich. Horizon
> ist mir dabei aber nicht abgestürzt. Ist also schon relativ stabil!
>
> - Im Schaltplan Editor erkennt Horizon nicht, wenn zwei Pins von
> Bauteilen auf einer Junction liegen. Im angehängten Beispiel ist z.B. C5
> und C6 nicht verbunden. Wenn man das Bauteil verschiebt (vom Juction
> weg), erkennt Horizon, dass es nicht verbunden ist.

Okay, die Verbindung so wie im Bild 6 sind in horizon nicht sinnvoll 
möglich. Pins von Symbolen können nur mit Netzlinien verbunden sein, 
nicht direkt mit Junctions oder anderen Pins. Einfach ein bisschen 
vertikal auseinanderschieben, dass an dem Pin ein bisschen Linie 
dranhängt. Aber ja, dass in Bild 6 keine Warnung kommt ist ein bug.

> - Ich habe ein paar Bauteile angelegt. Am einfachsten geht Hühnerfutter,
> die kann man sehr schön im Horizon Pool Manager durch "Make Part from
> Part" anlegen. Dabei kann man sowohl den Pool Manager als auch den
> Projekt Manager mit Schema und PCB offen lassen. Nach dem Anlegen bzw.
> einem "Update Pool" sind die Bauteile vorhanden

Genau so war das gedacht :)

> - Etwas komplizierter sind ganz neue Bauteile. Ich bin meist so
> vorgegangen, dass ich erst im Pool Manager ein Package angelegt und dann
> den Part Wizard gestartet habe. Das funktioniert soweit.

Sehr schön :)

> Evtl. könnte man das sinnvoll vorbelegen. Wenn man z.B. des Filenamen
> für die Entity eingegeben hat, dass für Untits, Symbols und Parts das
> automatisch übernommen wird. Wichtig ist dann noch, die Units und
> Entities  durchzugehen, um fehlende Einträge zu ergänzen, wie z. B. den
> Prefix bei Entities.

Bald kommt ein Knopf, damit man die Einträge vom Part zum Symbol, etc 
kopieren kann.

> - Padstack. Ich habe mir alle Pads, die ich benötige, neu angelegt.
> Später bin ich dann drauf gekommen, dass man wohl vorhandene Pads neu
> skalieren kann. Trifft das zu?

Genau. Padstacks sind parametrierbar. Wenn du z.B. einen rechteckiges 
SMD-Pad brauchst, kannst du den "SMD rectangular" Padstack verwenden und 
dann mit dem Tool "Edit pad parameter set" Höhe und Breite festlegen. 
Derzeit fehlen noch einige wichtige übliche Padstacks, in Zukunft sollte 
man dann für die Mehrzahl aller Bauteile die vorhandenen parametriert 
verwenden können.

> - Raster: Beim Bearbeiten von Schaltplänen und Packages kann ich kein
> Raster (mehr) einstellen. Dachte, dass dies schon mal ging.
Beim Schaltplan ist das Raster festgenagelt, damit's auch zu den 
Symbolen passt. Beim Package funktioniert es bei mir.

> Wenn man
> Objekte mit gedrückter ALT Taste verschiebt, kann man zwar das Raster
> ausschalten, aber beim Versuch, mit der linken Maustaste die neue
> Position festzulegen, hüpft dann das Objekt trotzdem wieder auf einem
> Rastpunkt. Wenn man ALT gedrückt hält, wird der Mausklick nicht
> angenommen.

Im Schaltplan/Board/Package?

> - Auch das Ausrichten eines neuen Objekts an bestehenden Objekten nervt
> manchmal, z.b. wenn man im Schaltplan Objekte dicht nebeneinander
> platzieren möchte. Kann man dies ausschalten?

Derzeit noch nicht. Die aktuelle Lösung ist es weiter ran zu zoomen.

> - Variabler Text: Gibt es neben $RD bei den Packages und $REFDES und
> $VALUE bei den Symbolen weitere?

Nein, geplant ist es aber, Werte aus den parametrischen Daten, wie z.B. 
die Spannungsfestigkeit von Kondensatoren hier verfügbar zu machen.

> - Neue Bauelemente: Ich habe ja nun ein paar angelegt, bin mir aber
> unsicher, ob ich die hochladen soll, da die sicher noch Fehler haben.

Kannst die ja mal irgendwo hochladen, dann kann ich mir's mal ansehen.

tester schrieb:
> Noch was: Horizon meckert ja, wenn man zwei Netze den selben Namen gibt.
> Man muss ja den Namen, wenn er schon mal vorhanden ist, per "Move net
> segment to other net" oder "Move net segment to new net" zuweisen. Was
> spricht dagegen, Horizon dies implizit machen zu lassen, wenn ein
> Netzname eingegeben wird der schon mal vorhanden ist?

Das sind zwei paar Schuhe:
Bei "Move net segment to..." werden keine Netze zusammenlegt. Wie der 
Name des Tools sagt, werden lediglich alle Pins auf dem ausgewählten 
Netzsegment auf das neue Netz verschoben.

Beim Netz umbenennen müsste ein Net merge, ähnlich wie beim Verbinden 
von zwei Netzen mit Netzlinien durchgeführt werden. Es sind dann im 
Gegensatz zu oben alle Netzsegmente betroffen.

Von der Architektur her ist es nicht schön machbar beim Netz Umbenennen 
Netze zusammenzulegen.

> Powersymbole habe ich gar nicht verwendet, sondern bin nur über die
> Netznamen gegangen. Irgend welche Nachteile?
Powersymbole gibt es derzeit eh nur für GND, da würden sie ein wenig 
schöner ausschauen als die Labels. Nachteile ergeben sich daraus keine, 
ist der Netzliste egal.

tester schrieb:
> Fazit: Auch wenn es noch nicht ganz rund läuft, kann man mit Horizon
> schon arbeiten. Lob!

Schön zu hören, dass auch andere Leute ohne, dass ich direkt daneben 
steh was mit horizon anfangen könnnen ;)

[Lukas K. (carrotindustries)]

tester schrieb:
> 3) Horizon speichert zusätzlich alle verwendeten Bauteile im Projekt mit
> ab

Seit gerade eben gibt es das. Windows-Builds dauern noch ein bisschen. 
Mit Fenster im Anhang (zu Erreichen aus dem Projektmager) kann man sich 
dann ansehen, welche Teile sich im Pool gegenüber dem Projekt-Cache 
geändert haben oder im Pool fehlen (z.B. weil man ein Projekt von wem 
anders bekommen hat, der seine Bauteile nicht in den globalen Pool 
merged hat).

Derzeit gibt es als diff nur einen json-Patch. Dass das nicht wirklich 
optimal ist, ist mir klar. Kann in Zukunft ja noch besser werden :)

[tester (Gast)]

Lukas K. schrieb:
> Ah, das passiert wenn du in den Via-Rules keine Regel oder keine Regel
> mit Padstack hast. Du solltest mindestens st eine Via-Regel haben, die auf
> alles matcht, so wie im Anhang.

Ist mir jetzt auch passiert. Evtl. koennte man die Via-Rule als default 
einbauen.

[tester (Gast)]

Lukas K. schrieb:
> Im Schaltplan/Board/Package? [Alt Taste + linke Maustaste]

Gebraucht hätte ichs bei den Symbols. Ich wollte kleine Pfeile an das 
3,5mm Klinkenbuchsensymbol anbringen.

[Jörg W. (dl8dtl) (Moderator)]

Lukas K. schrieb:
>> Wenn man Objekte mit gedrückter ALT Taste verschiebt, kann man zwar das
>> Raster ausschalten, aber beim Versuch, mit der linken Maustaste die neue
>> Position festzulegen, hüpft dann das Objekt trotzdem wieder auf einem
>> Rastpunkt. Wenn man ALT gedrückt hält, wird der Mausklick nicht
>> angenommen.
>
> Im Schaltplan/Board/Package?

Generell: ALT ist ein unglücklicher Modifier für die Maus.

Im fvwm wird der seit Jahren dafür benutzt, dass man Fenster
manipulieren kann, ohne über den Fensterrahmen gehen zu müssen.
ALT+LMB beispielsweise verschiebt dort ein Fenster.

Damit sieht die Applikation ein solches Event dann nie.

[Lukas K. (carrotindustries)]

Jörg W. schrieb:
> Generell: ALT ist ein unglücklicher Modifier für die Maus.

Jetzt wo du es sagst, fällt mir auch wieder ein, dass so ziemlich jeder 
X11-Fenstermanager ALT als Modifier zum Fenster verschieben verwendet. 
Ich verwende schon des längeren i3wm, da hab' ich mir den Modifier auf 
Super eingestellt.

Seit gerade eben kann man den Modifier für feines Grid auch auf Ctrl 
umstellen.

[Lukas K. (carrotindustries)]

tester schrieb:
> Ist mir jetzt auch passiert. Evtl. koennte man die Via-Rule als default
> einbauen.

War ein bisschen mehr Aufwand, als die anderen Rules, ist aber nun drin. 
Pool musst auch noch aktualisieren, damit das tut.

[Uwe S. (steinm)]

Lukas K. schrieb:
> tester schrieb:
>> - Padstack. Ich habe mir alle Pads, die ich benötige, neu angelegt.
>> Später bin ich dann drauf gekommen, dass man wohl vorhandene Pads neu
>> skalieren kann. Trifft das zu?
>
> Genau. Padstacks sind parametrierbar. Wenn du z.B. einen rechteckiges
> SMD-Pad brauchst, kannst du den "SMD rectangular" Padstack verwenden und
> dann mit dem Tool "Edit pad parameter set" Höhe und Breite festlegen.
> Derzeit fehlen noch einige wichtige übliche Padstacks, in Zukunft sollte
> man dann für die Mehrzahl aller Bauteile die vorhandenen parametriert
> verwenden können.

Was mir in diesem Zusammenhang noch nicht einleutet, ist der Button 
"Apply to all pads". Wirkt das mit dem Klick auf den Button oder ist das 
eine Einstellung für den Parameter. Egal was ich mache, ein Pad im 
gleichen Package verändert sich nicht.

  Uwe

[Lukas K. (carrotindustries)]

Uwe S. schrieb:
> Was mir in diesem Zusammenhang noch nicht einleutet, ist der Button
> "Apply to all pads". Wirkt das mit dem Klick auf den Button oder ist das
> eine Einstellung für den Parameter. Egal was ich mache, ein Pad im
> gleichen Package verändert sich nicht.

Mit "All" sind alle alle Pads gemeint, die ausgewählt waren, als du das 
tool gestartet hast. Also alle, die in der Combobox oben im Fenster 
auswählbar sind. Der Knopf macht erstmal nichts weiter, als den Wert 
auch für alle anderen Pads im Fenster einzutragen.

[Uwe S. (steinm)]

Lukas K. schrieb:
> Uwe S. schrieb:
>> Was mir in diesem Zusammenhang noch nicht einleutet, ist der Button
>> "Apply to all pads". Wirkt das mit dem Klick auf den Button oder ist das
>> eine Einstellung für den Parameter. Egal was ich mache, ein Pad im
>> gleichen Package verändert sich nicht.
>
> Mit "All" sind alle alle Pads gemeint, die ausgewählt waren, als du das
> tool gestartet hast. Also alle, die in der Combobox oben im Fenster
> auswählbar sind. Der Knopf macht erstmal nichts weiter, als den Wert
> auch für alle anderen Pads im Fenster einzutragen.

Danke. Jetzt habe ich es verstanden und es funktioniert.

[Helmut S. (helmuts)]

PCB-Layout

Warum werden bei m(ove) die DRCs nicht beachtet?
Vias und Leitungen lassen sich beliebig in Pads schieben obwohl die zu 
einem anderen Netz gehören. So war das doch bestimmt nicht gedacht oder 
doch?
Siehe Bild.

[Lukas K. (carrotindustries)]

Helmut S. schrieb:
> So war das doch bestimmt nicht gedacht oder
> doch?

Leider ja, das Move-Tool hat weiß nichts von Design Rules. Der 
Kicad-Router kann wohl Tracks unter Beachtung von Abständen verschieben, 
mal sehen wie man das am besten eingebaut bekommt.

[Helmut S. (helmuts)]

Lukas K. schrieb:
> Helmut S. schrieb:
>> So war das doch bestimmt nicht gedacht oder
>> doch?
>
> Leider ja, das Move-Tool hat weiß nichts von Design Rules. Der
> Kicad-Router kann wohl Tracks unter Beachtung von Abständen verschieben,

OK. Mit "Run Checks" werden die Fehler angezeigt, aber schöner wäre es 
schon wenn beim verschieben die "design rules" beachtet würden. Ich bin 
wohl zu verwöhnt von einem extrem teuren PCB-Programm.
Gegenüber dem "move" bei Kicad sieht dein "move" ja schon jetzt 
mächtiger aus.

> mal sehen wie man das am besten eingebaut bekommt.
Vielleicht das Ganze dann noch ein/ausschaltbar.

[Stefan S. (Gast)]

Helmut S. schrieb:
> wohl zu verwöhnt von einem extrem teuren PCB-Programm.

Na das sollte man ja hinbekommen. Boundingbox (Rechteck) für Pads, 
Traces usw. RTree aus CGAL um Überlappungen grob zu finden, und dann ein 
wenig Geometrie für die sich überlappenden Boxen.

[Stefan S. (Gast)]

oder war rtree aus der Boost Bibliothek? Na ja, einer von beiden...

[Klaus R. (klausro)]

Ich habe mich jetzt mal angemeldet (tester). Mein Demoprojekt habe ich 
soweit fertig gestellt und wollte mal Gerber erstellen lassen, dabei ist 
der Layout Editor dann abgestürzt und jetzt kann ich das Layout nicht 
mehr öffnen. Es kommt die Fehlermeldung

create proc
spawn /home/klaus/horizon/horizon/horizon-imp -b /home/klaus/horizon/proj/rpi-codec/board.json /home/klaus/horizon/proj/rpi-codec/top_block.json /home/klaus/horizon/proj/rpi-codec/vias 
terminate called after throwing an instance of 'std::runtime_error'
  what():  [Unsupported] Opposing point on constrained edge
end proc 4244
exit stat 134

Evtl. liegt es auch daran, dass ich unmittelbar davor viel geSmashed 
habe.
Ich habe das Projekt mal angehängt...

[Klaus R. (klausro)]

Habe jetzt selbst etwas experimentiert. Durch rausschmeißen der 
folgenden Zeilen (try and error) aus dem via-block von board.json konnte 
ich die Datei wieder laden:

klaus@Yoga:~/rpi-codec$ diff board.json ../horizon/proj/rpi-codec/board.json 
7945,7953d7944
<         "b1107bbe-b51a-4565-9970-b313ae9b559e": {
<             "from_rules": true,
<             "junction": "775a3034-7b80-4c8c-a222-a02a2e99eb66",
<             "padstack": "3c4a52fe-3ae0-4c3e-a108-824b53d6d6da",
<             "parameter_set": {
<                 "hole_diameter": 200000,
<                 "via_diameter": 500000
<             }
<         },

Das Via zeigt auf folgende junction

      "775a3034-7b80-4c8c-a222-a02a2e99eb66": {
            "position": [
                -600000,
                12000000
            ]
        },

Was ist hier falsch?

[Lukas K. (carrotindustries)]

Gerber-Export funktioniert nun, lag daran, dass in einem von deinen 
Padstacks Polygone mit 0 Ecken waren. Die müssen wohl entstanden sein 
beim Löschen von Polygonen mit runden ecken, sollte nun auch nicht mehr 
passieren.

Dass es sich gar nicht mehr öffnen lassen wollte kam daher, das mit der 
3D-Vorschau bereits beim Laden berechnet wurde. Dabei ist poly2tri 
hingefallen, weil beim Quarz ein Loch direkt auf der Kante des 
Silkscreens liegt und dabei ein für poly2tri unverträgliches Polygon bei 
rauskommt. Mal sehen, was sich da machen lässt... Jetzt stürzt es erst 
beim Öffnen der 3D-Vorschau ab wenn das Via so liegt.

[Klaus R. (klausro)]

Ja, läuft! Super! Anbei das Projekt + ein paar Bilder.

[Klaus R. (klausro)]

Noch ein paar Vorschläge:

1) Schaltplan + Layout als .png exportieren (so werden mehr Details als 
bei Bildschirmfotos sichtbar)

2) Die Fenster sollten sich ihre Größe merken

3) Im Layout wäre es sehr hilfreich, wenn man nicht nur ein einzelnes 
Segment sondern ein ganze Kette von Segmenten (Leiterbahnzug) 
selektieren könnte. Wenn man merkt, dass ein Leiterbahnzug völlig falsch 
liegt und man ihn komplett löschen muss, nervt es, wenn man jedes 
Segment einzeln anwählen muss.

4) Was ich an KiCad zu schätzen gelernt habe, war, dass man temporär den 
Ursprung des Zeichenblattes verlegen kann.

Aber bis jetzt eine super Arbeit. Beim letzten "git pull" kam neuer 
Programmcode für differentielle Leiterbahnen mit...

[Mampf F. (mampf)]

Klaus R. schrieb:
> Ja, läuft! Super! Anbei das Projekt + ein paar Bilder.

Ich muss sagen, ich bin beeindruckt :)

Klaus R. schrieb:
> 4) Was ich an KiCad zu schätzen gelernt habe, war, dass man temporär den
> Ursprung des Zeichenblattes verlegen kann.

Jau, diese Funktion braucht man ständig!

Bau auch noch gleich ein, dass man einen selektierten Block um genau x/y 
verschieben kann^^

[Lukas K. (carrotindustries)]

Klaus R. schrieb:
> Noch ein paar Vorschläge:
>
> 1) Schaltplan + Layout als .png exportieren (so werden mehr Details als
> bei Bildschirmfotos sichtbar)
Den Schaltplan kann man bereits als mehrseitiges PDF exportieren. 
Board-als-PDF kommt dann im Zuge mit Assembly Diagram export.


> 2) Die Fenster sollten sich ihre Größe merken
Du meinst die Fenster des interaktiven Manipulators? 
(Schaltplan/Board/...-Editor)
Mal nachdenken, wie das am Sinnvollsten umsetzbar ist. Für jede Datei 
einzeln merken? Für jeden Dateityp?

> 3) Im Layout wäre es sehr hilfreich, wenn man nicht nur ein einzelnes
> Segment sondern ein ganze Kette von Segmenten (Leiterbahnzug)
> selektieren könnte. Wenn man merkt, dass ein Leiterbahnzug völlig falsch
> liegt und man ihn komplett löschen muss, nervt es, wenn man jedes
> Segment einzeln anwählen muss.
Seit soeben gibt es zwei Tools dazu:
Select More: Wählt alle Tracks bis zum nächsten Pad  aus
Select net segment: Wählt alle zusammenhängenden Tracks aus

> 4) Was ich an KiCad zu schätzen gelernt habe, war, dass man temporär den
> Ursprung des Zeichenblattes verlegen kann.

Mir wollte nie so recht einleuchten, wozu das im Detail gut sein soll. 
Kannst mir auf die Sprünge helfen?

Mampf F. schrieb:
> Bau auch noch gleich ein, dass man einen selektierten Block um genau x/y
> verschieben kann^^

Gibt's schon: "Move exactly"

Klaus R. schrieb:
> Aber bis jetzt eine super Arbeit. Beim letzten "git pull" kam neuer
> Programmcode für differentielle Leiterbahnen mit...

Erwarte nicht zu viel, der Router ist ein wenig hakelig zu bedienen, 
aber iirc. war das auch schon in KiCad so.

[Mampf F. (mampf)]

Lukas K. schrieb:
> Mir wollte nie so recht einleuchten, wozu das im Detail gut sein soll.
> Kannst mir auf die Sprünge helfen?

Der Ursprung des Zeichenblatts legt auch fest, wo das Grid beginnt.

Beispielweise möchte man eine LED-Platine designen und die 10*10 LEDs 
sollen alle im Abstand 400mil sein, während aber die Platinenkante 
selbst in mm gezeichnet ist.

Irgendwas passt ja dann zwangsläufig nicht ins Raster ... Man würde dann 
einfach den Ursprung auf die Mitte der Platine setzen und auf 100mil 
umstellen und alles wäre super :)

Das geht nicht mit Relativ-Koordinaten direkt - da müsste man die 
Platine sonst wirklich um den Ursprung herum zeichnen, weil 
relativ-Koordinaten nicht das Grid ändern - bzw den Grid-*Ursprung*

[Klaus R. (klausro)]

Lukas K. schrieb:
> Den Schaltplan kann man bereits als mehrseitiges PDF exportieren.
> Board-als-PDF kommt dann im Zuge mit Assembly Diagram export.

PNG wäre interessant wegen den "Screenshots" fürs Forum :-). Dank FullHD 
Monitor gehen schon echte Screenshots, aber wenn man einen Schaltplan 
detailliert zwecks Diskussion einstellen möchte... PDF sind ja nur b/w.

> Du meinst die Fenster des interaktiven Manipulators?

Ja... anbei zwei Std Fenster Größen, wie sie bei mir aufgehen. Man 
beachte das Symbol Fenster...

> Mal nachdenken, wie das am Sinnvollsten umsetzbar ist. Für jede Datei
> einzeln merken? Für jeden Dateityp?

Ja... eine .horizon Datei im Home Directory?

> Select More: Wählt alle Tracks bis zum nächsten Pad  aus
> Select net segment: Wählt alle zusammenhängenden Tracks aus

Ja super! Danke!

> [diff pairs] Erwarte nicht zu viel, der Router ist ein wenig hakelig zu
> bedienen, aber iirc. war das auch schon in KiCad so.

Ich wollte es nur erwähnen. Diff-Pairs brauche ich eher selten.

[Klaus R. (klausro)]

Noch eine Frage: Während ich langsam eine Idee von den "Rules" bekomme 
(und die meisten Fehler wegbekommen habe), sind mir die Fehler mit den 
NTPH Löchern noch ein Rätsel.

[Lukas K. (carrotindustries)]

Klaus R. schrieb:
> sind mir die Fehler mit den
> NTPH Löchern noch ein Rätsel.

Das Problem ist, dass die Löcher NPTH, also nicht platiert sind. Solche 
Löcher werden üblicherweise für mechanische Befestigungsbohrungen 
verwendet. Die Löcher für Pads sind normalerweise immer platiert. (Kann 
im Padstack in den Eigenschaften vom Loch eingestellt werden)

Du hast dir ja eigene Padstacks für deine Pads gemacht? Warum hast du 
nicht die vorhanden benutzt und parametriert?

Mit dem Tool "Edit Pad" (war mal "Edit Pad parameter set") kannst du nun 
auch den Padstacks von Pads austauschen. Pad löschen und neu anlegen 
wird nicht funktionieren, da sich dann die UUID vom Pad ändert.