Super! Geht wieder! Danke! Das ging aber fix...
Helmut S. schrieb: > Hallo Lukas, > > habe die neueste kompilierte Version für WIN heruntergeladen. > Dann habe ich horizon-eda.exe gestartet. Darin kann ich aber nur den > Pool-Manager starten und den Pool updaten aber nicht das Projekt > (Schaltplan, Layout) starten. Weder "Open" noch Doppelklick in "Recent > Projects" auf das Projekt hilft. Da passiert einfach gar nichts. Danke Lukas, Schaltplan und Layout starten jetzt wieder mit deiner neuesten Version.
Angehängte Dateien:
-
program-icon.PNG
54 KB
Hallo Lukas, mir fällt da gerade auf, dass jetzt das horizon-Icon bei horizon-eda.exe fehlt. Siehe screenshot - links neu, rechts alt. Das Icon hilft, dass man leichter die wichtige .exe findet.
Helmut S. schrieb: > das horizon-Icon bei horizon-eda.exe > fehlt. War so nicht beabsichtigt, ist repariert.
Hallo Lukas, ich habe gerade die Funktion "Flip view" in der neuesten Version vom 7.7.2018 probiert. (In Mentor Xpedition heißt diese Funktion "Mirror".) Space bar -> Doppelklick auf "Flip view" geht. Die Altrenative mit CTRL-f macht aber gar nichts. Liegt das jetzt an Windows7. "Select only on work layer" Wenn ich das anmache dann kann ich Leitungen/Polygone selektieren aber keine Bauteile. Ist das wirklich so gedacht? Gruß Helmut
Helmut S. schrieb: > CTRL-f macht aber gar nichts. Das ist Ctr-F, also Ctrl-Shift-f. Ctrl-f wird mal irgendwann die Suchfunktion. Helmut S. schrieb: > "Select only on work layer" > Wenn ich das anmache dann kann ich Leitungen/Polygone selektieren aber > keine Bauteile. Ist das wirklich so gedacht? Ja, weil die nicht auf einem Layer im engeren Sinn liegen. Lang- Mittelfristig wird sich an dem eh noch was ändern.
Hallo Lukas, der Windows-build von horizon scheint nicht mehr zu funktionieren. https://ci.appveyor.com/project/carrotIndustries/horizon/build/artifacts Selber kompilieren schlägt auch fehl. Ist das ein bekanntes Problem? Gruß Helmut
Angehängte Dateien:
-
remote_selfcompiled_version.PNG
26 KB -
AppVeyor_version.PNG
8,7 KB
Helmut S. schrieb: > Hallo Lukas, > > der Windows-build von horizon scheint nicht mehr zu funktionieren. > https://ci.appveyor.com/project/carrotIndustries/horizon/build/artifacts > > Selber kompilieren schlägt auch fehl. > > Ist das ein bekanntes Problem? > > Gruß > Helmut Hallo Lukas, selber kompileren geht jetzt wieder, aber man kann den Pool nicht updaten. Sobald ich "Remote" klicke kommt eine Fehlermeldung über ein fehlendes Zertifikat. Siehe Anhang. Die neueste Version von AppVeyor geht übrigens gar nicht. Die meckert über eine fehlende DLL. Gruß Helmut
Angehängte Dateien:
Hallo Lukas, an den Problemen hat sich aber nichts geändert. Die selber kompilierte Vresion hat immer noch das Problem mit dem Zertifikat und die AppVeyor Version startet schon gar nicht richtig wegen der immer noch fehlenden dll. Helmut
Helmut S. schrieb: > Die neueste Version von AppVeyor geht übrigens gar nicht. Die meckert > über eine fehlende DLL. https://ci.appveyor.com/project/carrotIndustries/horizon/build/1.0.267 behebt das Helmut S. schrieb: > Sobald ich "Remote" klicke kommt eine Fehlermeldung über ein > fehlendes Zertifikat. Siehe Anhang. Beim selber bauen muss man sich das Zertifikatsbündel noch selber an die richtige Stelle kopieren: https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Windows#running
Lukas K. schrieb: > Helmut S. schrieb: >> Die neueste Version von AppVeyor geht übrigens gar nicht. Die meckert >> über eine fehlende DLL. > > https://ci.appveyor.com/project/carrotIndustries/horizon/build/1.0.267 > behebt das > > Helmut S. schrieb: >> Sobald ich "Remote" klicke kommt eine Fehlermeldung über ein >> fehlendes Zertifikat. Siehe Anhang. > > Beim selber bauen muss man sich das Zertifikatsbündel noch selber an die > richtige Stelle kopieren: > https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Windows#running Danke. Jetzt laufen beide Versionen wieder.
Angehängte Dateien:
-
fame.PNG
3,7 KB
Hallo Lukas, was soll denn im PCB-layout in "Fame" mal stehen oder ist das ein Tippfehler? Gruß Helmut
Helmut S. schrieb: > was soll denn im PCB-layout in "Fame" mal stehen oder ist das ein > Tippfehler? Ja, und eigentlich sollte das da gar nicht auftauchen. Ist repariert.
Hallo Lukas, habe nach längerer Zeit mal wieder die aktuelle Version im git unter Debian Sid kompiliert. Das ging soweit glatt, die Anwendung lässt sich starten und auch ein Projekt auswählen. Wenn ich dann den Schaltplan, das Board oder den Part browser aufrufe, startet dieser, aber an den Stellen, an denen Bedienelemente sind, ist nur eine schwarze Fläche. Der Schaltplan oder das Board selbst werden korrekt angezeigt. Wenn man weiß, wo man in der schwarzen Fläche klicken muss, lässt sich das Programm sogar bedienen. Also z.B. ein Klick rechts oben im Fenster schließt dieses wieder. Was könnte ich den tun, um diesen Fehler wieder abzustellen? Uwe
Uwe S. schrieb: > startet dieser, aber an den > Stellen, an denen Bedienelemente sind, ist nur eine schwarze Fläche. Der > Schaltplan oder das Board selbst werden korrekt angezeigt. Das ist eine Regression in mesa, hatte ich auch. Nach Downgrade auf 18.0.4 tat es bei mir wieder. Man müsste mal ein bug in deren Bugzilla aufmachen... Du hast auch eine Intel GPU?
Lukas K. schrieb: > Uwe S. schrieb: >> startet dieser, aber an den >> Stellen, an denen Bedienelemente sind, ist nur eine schwarze Fläche. Der >> Schaltplan oder das Board selbst werden korrekt angezeigt. > > Das ist eine Regression in mesa, hatte ich auch. Nach Downgrade auf > 18.0.4 tat es bei mir wieder. Man müsste mal ein bug in deren Bugzilla > aufmachen... > Du hast auch eine Intel GPU? Ja, Intel GPU. Zu blöd. Danke trotzdem für die Info. Uwe
Hallo Lukas, vor ein paar Wochen habe ich horizon ausprobiert. Leider war ich mitten in einem größeren Projekt, das ich schon mit Kicad begonnen hatte.. Jetzt aber gerne eine Rückmeldung was mir dabei aufgefallen ist: Als allererstes ganz großes Lob! Eine wunderbar klare, aufgeräumte Oberfläche. Der Schaltplaneditor der endlich mal seine "Junctions" aufräumt und Netzsegmente die zu einem Stück zusammengefasst werden. Wenn man einmal die ?-Taste gefunden hat ist alles gut. Nicht zuletzt die Videos sind extrem hilfreich. Ein paar Fragen habe ich auch: Ich glaube, daß ich das Konzept zu dem Pool einigermaßen verstanden habe. Aber vielleicht auch nicht ganz. * Warum gibt es die Unterscheidung in Unit und Symbol? Gibt es Units die kein Symbol haben oder andersherum? Auf den ersten Blick ist es eine 1:1 Abbildung und mir nicht klar warum nicht jedes Symbol gleichzeitig auch Unit ist. * Warum gibt es im Pool, sowohl bei den Units als auch bei den Symbolen die "Manufacturer" Spalte? Das hat mich irritiert. Ich dachte ich bewege mich auf einer rein abstrakten Ebene wenn ich eine Unit oder Symbol anlege.. Klar gibt es Symbole oder Entities die ein von einem bestimmten Hersteller produziertes Bauteil symbolisieren. Aber müsste dann nicht der beim Entity hinterlegte Hersteller beim Symbol auftauchen? Im Moment kann man sowohl für Unit als auch Symbol als auch Entity verschiedene Hersteller angeben.. * Bei der 3D-Ansicht sehe ich keine Platine (Substrat). Auch wenn ich eine Outline angebe. Nur Leiterbahnen und den ganzen Rest.. Dann habe ich auch noch ein paar Anregungen: * Mehrere Pools pro Projekt. Während des Schaltplanens mache ich mal schnell ein Symbol, welches nicht in den Pool gehört. Entweder weil ich es nur ganz schnell zeichne oder weil es ein spezielles Symbol ist, daß nie wieder jemand anderer verwenden wird (zB. ein eigenes Aufsteck-Board o.a.). Außerdem habe ich gerne eine Sammlung von eigenen Symbolen und Packages die von mir überprüft sind und auf die ich schnellen Zugriff möchte.. Mir ist klar, daß das das Konzept des Pool etwas aufweichen würde .. * Mehrere Boards pro Projekt. Die meisten meiner Projekte haben mehr als ein Board. Z.B. noch ein Aufsteckboard fürs Display oder ein Breakout-Board o.ä. Es wäre schick die alle in Form eines Projekt-Explorers zusammengefasst zu haben. * Zoomen. Beim Zoomen (mit dem Mausrad) finde ich es bei anderen Programmen sehr praktisch, wenn die Stelle des Cursors in die Mitte rückt. Bei Kicad ist das beispielsweise so.. Danke jedenfalls schonmal für das schöne Programm und schönen Abend und entschuldige wenn ich die eine oder andere Antwort auf die eine oder andere Frage überlesen habe. Flo
Flo G. schrieb: > Der Schaltplaneditor der endlich mal seine "Junctions" > aufräumt und Netzsegmente die zu einem Stück zusammengefasst werden. Sollte eigentlich selbstverständlich sein, inzwischen kann KiCad das auch... > Wenn man einmal die ?-Taste gefunden hat ist alles gut. Nicht zuletzt > die Videos sind extrem hilfreich. Sehr schön :) Flo G. schrieb: > * Warum gibt es die Unterscheidung in Unit und Symbol? Gibt es Units die > kein Symbol haben oder andersherum? Auf den ersten Blick ist es eine 1:1 > Abbildung und mir nicht klar warum nicht jedes Symbol gleichzeitig auch > Unit ist. Idee dahinter ist es, Darstellung im Schaltplan (Symbol) und in der Netzliste (Unit) zu trennen, damit nicht der Schaltplan, sondern die Netzliste die Primärquelle für Konnektivität ist. Nebenbei kann man für eine Unit mehrere Symbole in verschiedenen Geschmacksrichtungen haben. Flo G. schrieb: > * Warum gibt es im Pool, sowohl bei den Units als auch bei den Symbolen > die "Manufacturer" Spalte? Die Spalte "Manufacturer" bei den Symbolen ist identisch mit der bei den Units, damit man besser erkennt was man vor sich hat. > Das hat mich irritiert. Ich dachte ich bewege > mich auf einer rein abstrakten Ebene wenn ich eine Unit oder Symbol > anlege.. Klar gibt es Symbole oder Entities die ein von einem bestimmten > Hersteller produziertes Bauteil symbolisieren. Das ist mehr so als Gedankenstütze, denn die Teilenummern sind ja manchmal recht wenig aussagekräftig. > Aber müsste dann nicht > der beim Entity hinterlegte Hersteller beim Symbol auftauchen? Im Moment > kann man sowohl für Unit als auch Symbol als auch Entity verschiedene > Hersteller angeben.. Kann man, am Ende vom Tag zählt das, was im Part eingetragen ist. Flo G. schrieb: > * Bei der 3D-Ansicht sehe ich keine Platine (Substrat). Auch wenn ich > eine Outline angebe. Nur Leiterbahnen und den ganzen Rest.. Dann hast du wahrscheinlich die Kontur als Linien und nicht als Polygon gezeichnet. Mit dem tool "Line loop to polygon" kannst du's umwandeln. Flo G. schrieb: > * Mehrere Pools pro Projekt. Seit kurzem geht das: Du legst dir einen eigenen Pool an, und fügst im Tab "Settings" den globalen Pool hinzu. Damit hast du einen Pool, in dem alles aus dem globalen Pool eingeblendet ist und du zusätzlich deine eigenen Bauteile hinzufügen kannst. Flo G. schrieb: > * Mehrere Boards pro Projekt. Das Passt nicht wirklich ins Konzept. Was für Vorteile versprichst du dir davon? Flo G. schrieb: > * Zoomen. > Beim Zoomen (mit dem Mausrad) finde ich es bei anderen Programmen sehr > praktisch, wenn die Stelle des Cursors in die Mitte rückt. Bei Kicad ist > das beispielsweise so.. Ist wohl Geschmackssache, ich finde das überaus irritierend. Mit Wayland wird das ohnehin nicht mehr funktionieren, da Applikationen dann nicht mehr den Cursor positionieren können. Ist denen bei Kicad auch aufgefallen: https://bugs.launchpad.net/kicad/+bug/1725920
Flo G. schrieb: > * Zoomen. > Beim Zoomen (mit dem Mausrad) finde ich es bei anderen Programmen sehr > praktisch, wenn die Stelle des Cursors in die Mitte rückt. Bei Kicad ist > das beispielsweise so.. Das stelle ich immer als erstes ab :) Ich liebe es, wenn der der Punkt unter der Maus beim Zoomen gleich bleibt. Das irre rumgespringe macht mich ganz wirr^^
Lukas K. schrieb: > Mit Wayland > wird das ohnehin nicht mehr funktionieren, da Applikationen dann nicht > mehr den Cursor positionieren können. Endlich! ENDLICH! Es geschehen also doch noch Zeichen und Wunder! Ein Zeitalter in dem diese UX-Vergewaltigung endlich nicht mehr möglich ist bricht an, daß ich das noch erleben darf!
Angehängte Dateien:
Hallo Lukas, die neueste Version von horizon läuft nicht wegen mindestens einer fehlenden DLL - "libthai-0.dll". Siehe Anhang. Gruß Helmut
Hallo Lukas, wenn ich selber einen "build" für Windows mache, dann läuft das Programm obwohl es gar keine libthai-0.dll baut. Damit ist das ein reines Problem des von AppVeyor CI gebauten Programms. Gruß Helmut
Hallo Lukas, danke für neueste AppVeyor Version. Die funktioniert. Gruß Helmut Die WNODOWS-Version von horizon gibt es hier. https://github.com/carrotIndustries/horizon/wiki/Getting-started
Helmut S. schrieb: > danke für neueste AppVeyor Version. Die funktioniert. Jetzt ist auch ein Test drin, der nachsieht, ob auch alle benötigten DLLs mit dabei sind. Damit sollte sowas in Zukunft nicht mehr unbemerkt bleiben. Helmut S. schrieb: > wenn ich selber einen "build" für Windows mache, dann läuft das Programm > obwohl es gar keine libthai-0.dll baut. Wann hast du bei deinem msys2 das letzte mal Updates gemacht? Gtk und andere Libraries scheinen von Version zu Version mehr Abhängigkeiten zu bekommen. Zum Updates installieren mehrfach "pacman -Syu" in der mingw-shell ausführen.
Lukas K. schrieb: > Helmut S. schrieb: >> wenn ich selber einen "build" für Windows mache, dann läuft das Programm >> obwohl es gar keine libthai-0.dll baut. > > Wann hast du bei deinem msys2 das letzte mal Updates gemacht? Gtk und > andere Libraries scheinen von Version zu Version mehr Abhängigkeiten zu > bekommen. > > Zum Updates installieren mehrfach "pacman -Syu" in der mingw-shell > ausführen. Danke. Jetzt generiert das "make" auch auf meinem PC die libthai-0.dll".
Hallo Lukas, in einem thread um KiCad ging es um die Frage wie man zwei traces für ein Netz legen kann ohne dass der bereits vorhandenene trace gelöscht wird. Beitrag "KiCAD Leitungen auf Top UND Bottom" ----- > Wie mache ich es in KiCAD, dass ich sowohl auf Top und auf Bottom > Leiterbahnen gleichen Netzes routen kann? der Default unter "Interactive Router Settings" ist "remove redundant tracks". Kann man ausschalten... ----- Horizon löscht immer/meistens den alten trace, wenn man parallel einen neuen trace routet. Das entsprciht der Default-Einstellung von KiCad. Ich sehe in horizon bisher keine Möglichkeit dieses Verhalten auch mal abzuschalten wie das in KiCad möglich ist. Hast du das auf deiner ToDo-Liste oder übersehe ich eine Einstellmöglichkeit in horizon?
Hallo Lukas, hier noch ein Nachschlag zu meinem letzten Beitrag/Wunsch. Diese Funktion mit Auswahlmöglichkeit gibt es nicht nur in KiCad sondern vermutlich in vielen Layout-Programmen die einen online-DRC haben. KiCad: Remove redundant tracks Altium: Automatically remove loops (E)Xpedition: Prevent loops Diskussion im Forum KiCad, Beitrag "KiCAD Leitungen auf Top UND Bottom" Altium, Beitrag "Altium mehrere Leiterbahnen an ein SMD Pad"
Das abstellbar zu machen, wäre auf die schnelle kein großer Aufwand, doch platzt die Statuszeile beim Routing Tool mittlerweile schon aus allen Nähten und die Übersichtlichkeit derer lässt auch zu wünschen übrig. Mittelfristig wird für Tools die mehr Einstellmöglichkeiten haben, als sinnvoll in die Statuszeile passen eine Seitenleiste, an der Stelle an der sonst der Properties sind, geben.
Angehängte Dateien:
-
prevent_loops.PNG
16 KB
Wie wäre es das in "Rules" unter einer neuen Rubrik "Route" unterzubringen. Da könnte ja noch mehr kommen. Route -> Prevent loops
Angehängte Dateien:
-
3d.png
360 KB
Sodele, nun gibt's dank meiner Masterarbeit auch endlich ein vorzeigbares Demoprojekt für horizon EDA: https://github.com/carrotIndustries/x-band-tx
Lukas K. schrieb: > Sodele, nun gibt's dank meiner Masterarbeit auch endlich ein > vorzeigbares Demoprojekt für horizon EDA: > https://github.com/carrotIndustries/x-band-tx Hallo Lukas, vielen Dank für die CAD-files. Das PCB sieht sehr gut aus. Nach dem Starten deines Layouts bekommt man eine Menge "air wires". Erst nach dem Plane-update sind die "air wires" weg. Ist es gewollt, dass die Planes nach dem Laden des Projects immer erst mit "Update all planes" aktiviert werden müssen? Warum sehe ich die grünen LEDs in meiner 3D-Ansicht nicht? Gruß Helmut
Helmut S. schrieb: > Nach dem Starten deines Layouts bekommt man eine Menge "air wires". Erst > nach dem Plane-update sind die "air wires" weg. > Ist es gewollt, dass die Planes nach dem Laden des Projects immer erst > mit "Update all planes" aktiviert werden müssen? Aktuell ja, die Füllung der Planes wird nicht gespeichert. > Warum sehe ich die grünen LEDs in meiner 3D-Ansicht nicht? Einige Packages (z.B. die LEDs) habend 3D-Modelle, deren Lizenz die Weiterverbreitung explizit verbietet, manche haben auch gar keine wirkliche Lizenz. Diese Modelle landen daher nicht im git. Wenn man die 3D-Modelle haben will muss man die sich selber von irgendwo runterladen und an die richtige Stelle kopieren.
Angehängte Dateien:
-
kicad_schieben.PNG
6,7 KB -
kicad_schieben1.PNG
3,3 KB
Hallo Lukas, Beim lesen einer Diskussion über push and shove in Kicad habe ich mir das mal genauer in Kicad angesehen. Es gibt dort ein Menu in dem man einstellen kann ob der interactive router um andere Leitungen herumfährt oder ob Leitungen weggeschoben werden. Siehe die zwei Bilder. Im zweiten Bild hat Kicad die bestehende Leitung weggeschoben um Platz zu machen. Diese Möglichkeit des wegschiebens beim verlegen einer Leitung (Befehl x) scheint es in horizon nicht zu geben oder übersehe ich etwas?
Lukas K. schrieb: > Einige Packages (z.B. die LEDs) habend 3D-Modelle, deren Lizenz die > Weiterverbreitung explizit verbietet Warum nimmst Du nicht einfach die 3d-Modelle von KiCAD, die sind frei nutzbar, so verstehe ich die LICENSE.md Datei die sich in deren übergeordnetem Ordner befindet: https://github.com/KiCad/kicad-packages3D/blob/master/LICENSE.md
Helmut S. schrieb: > Diese Möglichkeit des wegschiebens beim verlegen einer Leitung (Befehl > x) scheint es in horizon nicht zu geben oder übersehe ich etwas? Wenn das Router-Tool aktiv ist, aber man noch keinen Track routet kann man mit 's' zwischen push/shove und walkaround umschalten. Bernd K. schrieb: > Warum nimmst Du nicht einfach die 3d-Modelle von KiCAD Wenn KiCad welche hat, nehme ich die, nur bei exotischen Bauteilen hat's in der KiCad-Library nichts.
Hallo Lukas,
> Wenn das Router-Tool aktiv ist, aber man noch keinen Track routet kann
man mit 's' zwischen push/shove und walkaround umschalten.
Danke, das hatte ich in der Statuszeile übersehen.
Jetzt ist mir aber moch etwas anderes wichtiges aufgefallen. Wenn ich
ein trace-segment mit "drag track" oder "drag keeping slope" schiebe,
kann ich das Leitungsstück über andere Leitungen schieben (Kurzschluss).
Es werden also keine interaktiven Checks gemacht. Ist das immer so oder
übersehe ich da schon wieder etwas?
(In Kicad wird da die andere Leitung weggeschoben damit die nicht
übereinander liegen.)
in welcher Sprache ist es jetzt eigentlich programmiert worden? Ahhh..ich sehe gerade c++-richtig?
Hallo Lukas, die neueste Version von horizon (horizon-2018-10-03-1629.zip) für WINDOWS läuft nicht. https://ci.appveyor.com/project/carrotIndustries/horizon/build/artifacts Es fehlen die beiden DLLs libssl-1_1-x64.dll und libcrypto-1_1-x64.dll. Wenn man die zwei fehlenden Dateien aus MSYS64 dazukopiert, dann läuft das Programm. Die Ursache liegt also nur an der Batchdatei die die WIN-Files zusammenkopiert. Gruß Helmut
Helmut S. schrieb: > Es fehlen die beiden DLLs libssl-1_1-x64.dll und libcrypto-1_1-x64.dll. > Wenn man die zwei fehlenden Dateien aus MSYS64 dazukopiert, dann läuft > das Programm. Die Ursache liegt also nur an der Batchdatei die die > WIN-Files zusammenkopiert. Hmm, mal sehen weshalb das mein Test nicht erkannt hat... Im aktuellen Build sollten die jetzt drin sein.
Angehängte Dateien:
-
3D_failed.PNG
5,6 KB
Hallo Lukas, in der neuesten Version von horizon geht die 3D-Ansicht nicht mehr. Es geht überhaupt kein Fenster für die 3D-Ansicht auf. Im Anhang die Fehlermeldung beim klicken auf den 3D-button, wenn man horizon-eda im mysys gestartet hat. Das war jetzt mit der selbstkompilerten Version. In der Appveyor-Version geht 3D auch nicht mehr.
Helmut S. schrieb: > in der neuesten Version von horizon geht die 3D-Ansicht nicht mehr. Es Danke für's Testen, ist repariert.
Helmut S. schrieb: > die neueste Version von horizon (horizon-2018-10-03-1629.zip) für > WINDOWS läuft nicht. Nun ja, auch bei der "horizon-2018-10-23-2257.zip" läuft's hier nicht: "gl error 1281 in src/canvas/canvas_gl.cpp:87" System: Thinkpad T410s, Intel-HD Grafik, OpenGL 2.1 und ein Update auf die neueste OpenGL Version ist dafür nicht verfügbar. Es ist wie bei Kicad: jede Begegnung mit Horizon ist mir wie ein Schlag ins Gesicht. W.S.
W.S. schrieb: > OpenGL 2.1 Genügt nicht, stand schon ganz am Anfang fest, und Lukas hat ausführlich erklärt, warum er davon nicht abgehen möchte. OpenGL 3 ist Pflicht. Allerdings hat selbst mittlerweile schon recht betagte Hardware damit kein Problem mehr, ein T410 ist mit 8 Jahren ja schon ein Großvater.
Jörg W. schrieb: > Genügt nicht, stand schon ganz am Anfang fest Lukas K. schrieb: > OpenGL 3.2 ist leider Pflicht Tja, i5, 4 Kerne, 8 GB RAM, Intel-HD bis >2000x2000, DirectX-10 genügt so einem Programm nicht. Toll. Ist ne klasse Zielstellung. Manchmal frag ich mich, warum. Ich kann's mir nur mit überschäumendem Hormon erklären. Etwa so wie im Straßenverkehr, wo mir oft genug Leute auffallen, die aus lauter Lust nochmal Vollgas geben, wohl wissend, daß sie nach 300m dann ne Vollbremsung hinlegen müssen, weil sie dort links abbiegen müssen. Kluge Entscheidungen vor dem Schreiben der ersten Codezeile sehen anders aus. Aber diesen Punkt hatte ich dem Lukas ja schon vor langer Zeit dringendst angeraten und er hat ihn in den Wind geschlagen. W.S.
W.S. schrieb: > Manchmal frag ich mich, warum. Das hat Lukas ausführlich begründet. Im Gegensatz zu deinem Gemuffel war es eine kluge Designentscheidung von ihm, damit er sich eben bei einer kompletten Neuentwicklung, die ohnehin erst ein paar Jahre nach Designgstart irgendwann "ready for the masses" sein wird, den Aufwand für irgendwelche Rückwärtskompatibilität bis zur Jungsteinzeit sparen kann und sich stattdessen auf die gewünschten Features konzentriert. Die Kiste hier in der Firma hat nun auch schon 4 Jahre auf'm Buckel, ist ein i5, und genügt vollauf für Horizon. Nur dein knapp 10 Jahre alter Laptop genügt eben nicht mehr, aber der genügt sicher auch nicht mehr für eine halbwegs aktuelle Windows-Version, oder?
W.S. schrieb: > DirectX-10 genügt > so einem Programm nicht DirectX ist was Windows-spezifisches, die Software soll aber bewusst plattformunabhängig sein, ist also völlig irrelevant. OpenGL 3.2 ist aus dem Jahre 2009. https://de.wikipedia.org/wiki/OpenGL#Versionsgeschichte Selbst Grafikkarten aus dem Jahr 2008 haben (später) OpenGL 3.2 und mehr unterstütz, z.B. die GeForce 200er-Serie oder die alte 9000er-Serie https://de.wikipedia.org/wiki/Nvidia-GeForce-200-Serie#Grafikprozessoren https://de.wikipedia.org/wiki/Nvidia-GeForce-9-Serie#Grafikprozessoren Eventuell läuft es auch auf noch älteren Grafikkarten, das hab ich jetzt nicht überprüft. Intel war mit seinem internen "Grafikbeschleuniger" (in der Vergangenheit) immer sehr stiefmütterlich umgegangen. Meist war Intel auch DirectX Support wichtiger wie OpenGL. W.S. schrieb: > Manchmal frag ich mich, warum. Ich kann's mir nur mit überschäumendem > Hormon erklären. Irgendwann muss man die Altlasten auch mal loswerden, und OpenGL 3.2 ist echt keine große Hürde, jede nVidia oder AMD Karte der letzten 10 Jahre kann das. W.S. schrieb: > Kluge Entscheidungen vor dem Schreiben der ersten Codezeile sehen > anders aus. Doch die sehen genauso aus, nämlich das man Altlasten größer 10 Jahre irgendwann mal loswird. Oder willst du noch Standards untersützen W.S. schrieb: > System: Thinkpad T410s, Intel-HD Grafik Hättest du damals die "NVIDIA Quadro NVS 3100M" mitkaufen sollen, die untersützt alles bis OpenGL 4.3 ;-) http://www.gpuzoo.com/GPU-NVIDIA/Quadro_NVS_3100M.html Zudem ist auch nur die alte Westmere-Generation (also Core i erste Generation) auf OpenGL 2.1 hängen geblieben, alle anderen gehen ab 3.3 unter Linux los https://en.wikipedia.org/wiki/Intel_Graphics_Technology#Capabilities
Kein win95, win98, ME, XP --> also schrott? Nicht ganz, auch wenn ich auch heute fast alles noch mit XP mache. Liegt teilweise an der Software darauf. Leider bin ich aktuell bei horizon auch raus, mein I3 mit WIN7 will halt nicht so richtig. Der wird auch noch einige Jahre laufen. Dabei würde ich sehr gerne zu horizon wechseln, weil es jetzt schon einen super Eindruck macht.
Jörg W. schrieb: > W.S. schrieb: >> Manchmal frag ich mich, warum. > > Das hat Lukas ausführlich begründet. Im Gegensatz zu deinem Gemuffel > war es eine kluge Designentscheidung von ihm, damit er sich eben bei > einer kompletten Neuentwicklung, die ohnehin erst ein paar Jahre nach > Designgstart irgendwann "ready for the masses" sein wird, den Aufwand > für irgendwelche Rückwärtskompatibilität bis zur Jungsteinzeit sparen > kann und sich stattdessen auf die gewünschten Features konzentriert. ...das überhaupt "ausführlich begründen" zu müssen halte ich schon für sehr konziliant, weil offensichtlich... > > Die Kiste hier in der Firma hat nun auch schon 4 Jahre auf'm Buckel, ist > ein i5, und genügt vollauf für Horizon. Nur dein knapp 10 Jahre alter > Laptop genügt eben nicht mehr, aber der genügt sicher auch nicht mehr > für eine halbwegs aktuelle Windows-Version, oder? da wiederum wäre ich nicht so sicher, nicht unwahrscheinlich dass Microsoft ein Extra-Team nur für die Gate-A20-Emulationen unterhält ;-) (zumindest auf meiner 2009er-Kiste z.B. läuft Win10 unauffällig)
Jörg W. schrieb: > Nur dein knapp 10 Jahre alter > Laptop genügt eben nicht mehr, aber der genügt sicher auch nicht mehr > für eine halbwegs aktuelle Windows-Version, oder? Der stammt aus 2011 und du schmeißt mal wieder mit beleidigenden Sprüchen um dich. Muß man ein etwa 8 Jahre altes Notebook wegschmeißen, obwohl es immer noch tadellos funktioniert? Das Ganze ist ne generelle Frage, nämlich die nach der heutigen Wegwerf-Gesellschaft. Muß man sein Auto alle 4.1 Jahre wechseln? Und sein Mobiltelefon alle 2.4 Jahre und sein Notebook alle 3 Jahre? Tatsächlicher Verschleiß ist ein echter Grund, aber gedankenlos oder mit Mutwillen programmierte Software ist was Anderes. Ach, Schwamm drüber. W.S.
W.S. schrieb: > Muß man ein etwa 8 Jahre altes Notebook wegschmeißen, obwohl es immer > noch tadellos funktioniert? Muss man nicht, ich benutze auch noch mein >10 Jahre altes Thinkpad - für Browser, Doku und µC-Flashen z.B. Ich käme aber nicht auf die Idee, damit ein aktuelles EDA nutzen zu wollen, oder mich dann gar noch über damit verbundene Probleme zu beschweren...
Ich denke eure Erwartungen sind zu hoch, ich würde nicht mal im Traum daran denken eine (noch nicht mal fertige) Software zu kritisieren weil sie auf 10 Jahre alten Gurken nicht läuft, selbst ein 2009er MacBook (nicht Pro) unterstützt OpenGL 3.3. Also irgendwo muss man mal auch die Reissleine ziehen... Was kommt als nächstes? Die Software taugt nichts weil Opas Windows 3.11 Rechner nicht mit Horizon zusammen spielt? Ich benutze selbst noch ein 2010er MacBook und 2010er HP Notebook, mit den Gurken würde ich aber nie auf die Idee kommen ein CAD Programm produktiv einzusetzen... Wenn die Software Produktivstand erreicht hat werden die genannten Modelle welche nicht unterstützt werden auch ihre 10 Jahre erreicht haben. Ich bin ebenfalls kein Befürworter von dauernd neukaufen, ich fahre auch ein 15 Jahre altes Auto aber ich denke einen Computer aus dem Consumer-Bereich kann man ohne schlechten Gewissens nach 8 Jahren in den Ruhestand schicken oder zumindest anderweitig einsetzen, ich habe auch ein Thinkpad T23 mit Windows XP hier, das Teil wird halt angeschmissen wenn ich eine echte parallele oder serielle Schnittstelle benötige (und ich kann mich ehrlich gesagt auch nicht mehr daran erinnern wann dass das letzte mal war)
Jan L. schrieb: > Muss man nicht, ich benutze auch noch mein >10 Jahre altes Thinkpad - > für Browser, Doku und µC-Flashen z.B. > Ich käme aber nicht auf die Idee, damit ein aktuelles EDA nutzen zu > wollen, oder mich dann gar noch über damit verbundene Probleme zu > beschweren... Stop mal. Ich benutze dieses knapp 7 Jahre alte Notebook eben auch wie du, um z.B. hier in diesem Forum herumzudaddeln. Und ich komme genau wie du auch nicht auf die Idee, ein EDA-System auf diesem Teil benutzen zu wollen. Allerdings läuft die aktuelle Eagle-Bastler-Version 9.2 problemlos auf diesem Notebook. So viel zum Thema "aktuelles EDA". Ich sag's mal so: Jörg und andere haben einfach den Mund zu voll genommen - und es ist wohl eher nicht sehr klug, die Systemvoraussetzungen zu hoch zu schrauben. Dann fehlen nämlich viele Tester und übrig bleiben nur die Fanboys. Ihr hättet meine Fehlermeldung auch ganz einfach so stehen zu lassen wie sie ist. Schließlich ist mir die Version 2.1 schon zuvor klar gewesen. Aber aus eigener Erfahrung weiß ich, daß gelegentlich aus einer einigermaßen detaillierten Fehler-Rückmeldung und einer kleinen Änderung im Quellcode etwas Gutes werden kann, z.B. bessere Kompatibilität und geringere HW-Anforderungen ohne daß man sich viel an Performance vergibt. Kann, nicht Muss. Und was macht ihr, wenn Lukas übermorgen auf die Idee kommt, ein nettes Feature aus OpenGL 4.6 zu benutzen? W.S.
W.S. schrieb: > Allerdings läuft die aktuelle Eagle-Bastler-Version 9.2 problemlos auf > diesem Notebook. Ich habe von einem aktuellen Windows gesprochen, nicht von Eagle (oder einem anderen EDA-Programm). Mein Sohn hat billig ein ähnlich altes Thinkpad bekommen, daher habe ich durchaus ungefähr ein Gefühl dafür, wie performant oder lahm so'n Ding ist. Fürs gelegentliche Arbeiten sicher OK, als primäre Maschine will das heute wohl keiner benutzen. Wenn du Horizon dort sowieso gar nicht verwenden willst, ist die Lamentiererei doppelt unsinnig, zumal du ja ganz genau wusstest, dass es aufgrund der eingangs genannten Systemvoraussetzungen gar nicht gehen kann. > Und was macht ihr, wenn Lukas übermorgen auf die Idee kommt, ein nettes > Feature aus OpenGL 4.6 zu benutzen? Er hat sich zum Projektstart auf Mindestanforderungen seines Zielsystems festgelegt (und diese auch begründet). An die hat er sich bislang gehalten.
Angehängte Dateien:
-
horizon.png
14 KB
Also ich habe mich jetzt mal entschlossen das Programm auszuprobieren. Bisher leider nur mit mäßigem Erfolg. Ich bekomme es noch nicht einmal gestartet. Es poppen sofort 2 Fehlermeldungen auf. Die erste Meldung lautet "No pools setup ....". Was das auch immer sein mag. Gleichzeitig mit dieser Meldung popt noch die im Anhang gezeigte Fehlermeldung auf. Ich habe gar kein Laufwerk B. Immerhin die erstere von beiden Meldungen kann ich schließen, während die zweite (die mit dem Laufwerk B) sich hartnäckig weigert. Keine der Funktionen "Abbrechen", "Wiederholung" oder "Weiter" führt zu einem sichtbaren Ergebnis. Auch das Beenden des Programmes mit dem Taskmanager funktioniert nicht. Braucht es denn noch weitere Voraussetzungen, damit das Programm lauffähig ist? Ich befürchte, W.S. hat wieder mal mit seiner Einschätzung recht. So wie es momentan ist, ist es leider unbrauchbar. Pulsonix 9.0, Eagle und auch einige andere CAD-Programme laufen völlig problemlos auf dem Rechner.
Zeno schrieb: > Die erste Meldung lautet "No pools setup ....". Was das auch immer sein > mag. Lies mal den Rest des Threads bzw. Lukas' Dokumentation (die URL seines Projekts steht ja im einleitenden Beitrag, dort gibt es auch ein Wiki). Einen Pool musst du erstmal einrichten, der ist Grundvoraussetzung. Möglicherweise erledigt sich ja dann die Frage nach dem ominösen Laufwerk B.
Jörg W. schrieb: > Einen Pool musst du erstmal einrichten, der ist Grundvoraussetzung. > Möglicherweise erledigt sich ja dann die Frage nach dem ominösen > Laufwerk B. Wie mache ich das? Keines der Programme im Horizonordner zeigt nachvollziehbare Reaktion. Dachte das ich diesen ominösen Pool hiermit horizon-pool.exe bzw. diesem horizon-pool-update-parametric.exe erzeugen kann. SEhe bei diesen Programmen außer einem kurzen Blinkern keine wirkliche Reaktion.
Weiß ich auch gerade nicht mehr, müsste ich nachlesen. Meine Binaries zu Hause funktionieren auch im Moment nicht mehr, weil irgendwelche Systembibliotheken neu gebaut worden sind. Schau mal durch den Thread.
Zeno schrieb: > Wie mache ich das? Keines der Programme im Horizonordner zeigt > nachvollziehbare Reaktion. ...aus "getting started" im Wiki:
1 | Get the pool |
2 | Don't know how to git? No problem! Double-click horizon-eda.exe or launch > ./horizon-eda from your shell and click on 'Download...' to download the pool. The default pool carrotIndustries/horizon-pool is the one you want to use. |
möglich, dass man da inzwischen oben links auf den Button "New..." klicken muss - aufgerufen aber wird nur "horizon-eda.exe". Kommt schonmal vor, dass auch das nicht klappt - es ist halt "work in progress", und ab und zu "vergisst" der Paketierer da wohl mal eine Library... Ich hatte zufällig gestern mal aktualisiert, und die Version läuft - da ich aber eine alte Version vorher hatte, ist das nicht unbedingt aussagekräftig...
@Jan, Jörg Habe Eure Hinweise beherzigt aber funktionieren tut es immer noch nicht. Die im Anhang meines obigen Post gezeigte Fehlermeldung kommt immer noch, immerhin kann ich jetzt den ominösen Pool einlesen. Er rödelt ne Weile und dann ist eine 2. Fehlermeldung da (s. Anhang). Die untere kann ich mit OK wegklicken. Danaach kann ich dann wenigstens das Programm schließen, allerdings bleibt die obere Fehlermeldung jetzt stehen. Diese läßt sich auch mit dem Taskmanager nicht wirklich schließen. Wenn ich die Meldung versuche mit dem Taskmanager zu schließe, dann erhalte ich die aus meinem ersten Post. Wenn ich diese über den Taskmanager schließe kommt diese wieder und so kann man lustig hin un her schalten. Wenn es schon daran scheitert das Programm zu starten, dann ist das Teil für mich unbrauchbar und damit raus. Vielleicht probier ich es später noch einmal. Schade eigentlich, denn ich hatte durchaus den Eindruck das es Lukas besser machen wollte (als KiCAD). Leider ist das bisher aus meiner Sicht schon im Ansatz stecken geblieben. KiCAD ließ sich bisher bei mir wenigsten starten. Das Erzeugen eines PCB's ist dann wieder eine andere Sache, da hat sich KiCAD bisher aber auch nicht mit Ruhm bekleckert. Dennoch habe ich mich entschlossen es noch einmal zu probieren und lade mir grad mal die aktuelle Version herunter. Befürchte aber es wieder im Disaster enden, da sich der Workflow von KiCAD mir nicht wirklich erschließt. Noch einmal kurz zu Horizon. Ich ziehe durchaus den Hut vor Lukas der sich an so eine Aufgabe herantraut, aber in dem gegenwärtigen Zustand ist Programmpaket für den geneigten User leider unbrauchbar. Ich bin schon der Meinung es wäre gut gewsen den einen oder anderen Rat von W.S. zu beherzigen, denn ganz so unrecht hat er nicht. Und ja Kritik schmerzt immer, aber wenn man ein Programm veröffentlicht und darum bittet das es die Allgemeinheit testet, dann muß man halt auch Kritik aushalten und annehmen. Noch habe ich die Hoffnung nicht ganz aufgeben das bei dem Projekt was Benutzbares herauskommt, aber das wird noch eine Weile dauern. Ein gutes Konzept zu Anfang hätte dem Projekt mit Sicherheit sehr gut getan. Ein KOnzept bedeutet ja nicht, das danach alles in Stein gemeißelt ist. Man kann es sehr wohl immer wieder (mit den gewonnenen Erfahrungen) erweitern. Aber es gibt erst mal eine Richtung und Prämissen vor die man der Reihe nach abarbeiten kann. Lukas hat die Planung leider versäumt und gleich in die Tasten gehauen. Wichtig wäre jetzt, das Lukas mal ein Paket baut, welches alles enthält was erforderlich ist - auch diesen ominösen Pool -, damit man erst einmal damit arbeiten kann und nicht rumfrickeln muß.
Zeno schrieb: > Sorry habe im letzten Post die Bildanhänge vergessen. ...wenn ich diese Fenster so sehe - worauf probierst du das (OS, OpenGl)? Ansonsten - vielleicht mal nicht Äpfeln mit Birnen vergleichen, KiCad ist ja schon relativ gut ‚abgehangen‘, und du benutzt sicherlich eine *Release*-Version. Horizon dürfte hingegen ‚alpha‘ sein. Leider ist der ‚offizielle‘ Stand nicht klar gekennzeichnet, und ein Changelog scheint‘s auch nicht zu geben. Und m.E. wäre es auch bestimmt nützlich, in der Wiki-Doku auf Stand und vor allem die Voraussetzungen hinzuweisen, um Missverständnissen wie hier vorzubeugen...
Jan L. schrieb: > ...wenn ich diese Fenster so sehe - worauf probierst du das (OS, > OpenGl)? Das ist Win7 prof. 64Bit. Open GL müßte ich noch prüfen. Wenn es wirklich an OpenGl liegen sollte, dann wäre eine passende Fehlermeldung schon hilfreich. Die Fehlermeldung deutet aber auf ein ganz anderes Problem hin. Zu KiCAD: Ja natürlich habe ich eine Release Version benutzt. Ich wills ja auch noch mal probieren, derzeit scheitert es noch am Download der aus irgendwelchen Gründen derzeit schnarchlangsam ist (andere Downloads funktionieren normal). Wobei ich sagen muß Knapp 1GB für den KiCAD Installer ist schon heftig, zumal der gepackt sein dürfte. Pulsonix ist da deutlich sparsamer. Das bringt es installiert, also ausgepackt, auf knapp 400MB. Da fragt man sich schon wie die das hinbekommen.
Zeno schrieb: > Wobei ich sagen muß Knapp 1GB für den KiCAD Installer ist schon heftig, > zumal der gepackt sein dürfte. Das sind vor allem 3D-Modelle, die sowas fett machen. Bei mir hier liegen über 4 GiB an 3D-Modellen in ${INSTALLDIR}/share/kicad herum. Zeno schrieb: > Wenn es schon daran scheitert das Programm zu starten, dann ist das Teil > für mich unbrauchbar und damit raus. Ist halt im Moment wirklich Entwicklersoftware und eigentlich besser, wenn man es sich tatsächlich selbst compiliert. Die eine Fehlermeldung ("kein Datenträger im Laufwerk") sieht aber schon etwas seltsam aus, das dürfte eher ein Artefakt dessen sein, was dein System sonst so bereits hinter sich hat. Vielleicht ja auch irgendwas, was aus dem System stammt, auf dem die Windows-Version gebaut wird. Ich weiß schon, warum ich die Windows-Binaries für AVRDUDE lieber auf meinem FreeBSD mit einem Crosscompiler baue und nicht irgendwo auf einem tatsächlichen Windows :), aber das ist natürlich von der Komplexität her mit Horizon nicht vergleichbar.
Jörg W. schrieb: > Die eine Fehlermeldung ("kein Datenträger im Laufwerk") sieht aber schon > etwas seltsam aus, das dürfte eher ein Artefakt dessen sein, was dein > System sonst so bereits hinter sich hat. Das System dürfte so sehr gestresst worden sein. Bisher habe ich das System nur genutzt um ein 32Bit Programm, welches ich für die Firma geschrieben habe, auf einem 64Bit System zu testen. Das System ist quasi noch jungfreulich. Bis auf einen Virenscanner, MSWord und Visualstudio 2015 habe ich da keine weitere Software installiert. Das Problem liegt schon im Horizonkompilat, das mit irgendeiner Systemeinstellung nicht klar kommt und sich verrennt.
...Lukas kompiliert gerade, life zu sehen: https://ci.appveyor.com/project/carrotIndustries/horizon Vielleicht gibt‘s dann gleich ein neues Binary... ;)
Jan L. schrieb: > ...Lukas kompiliert gerade, life zu sehen: > https://ci.appveyor.com/project/carrotIndustries/horizon > > Vielleicht gibt‘s dann gleich ein neues Binary... ;) Hab diese neue Version gerade angetestet. Die Methode "Drag track" beim verschieben einer Leitung funkioniert wieder. Die Methode schiebt andere Leitungen weg, wenn die im Weg sind. Allerdings verschiebt die auch Vias die im Weg sind und sie schiebt auch weiter entfernte Leitungsstücke. Da hätte ich gerne die Wahl mit oder ohne andere Vias schieben. Ob das der Cern-router kann?
Zu den OpenGL-Anforderungen wurde hier ja schon fast alles gesagt, was es zu sagen gibt. Meine Windows-Testhardware ist ein ca. 10 Jahre alter Plastiklaptop mit Core 2 Duo und Nvidia GeForce 9650M GT. Darauf läuft horizon problemlos. Mittlerweile benutze ich einige OpenGL-Funktionen, wie z.B. glDrawElementsInstancedBaseInstance, die es offiziell erst seit OpenGL 4.0 gibt, aber bis jetzt von allem auf dem horizon überhaupt startet unterstützt wird. Das schöne an dieser Funktion ist, dass so mit einem einzigen Drawcall alle Instanzen des selben 3D-Modells auf dem Board gerendert werden können. Zeno schrieb: > Es poppen sofort 2 Fehlermeldungen auf. > Die erste Meldung lautet "No pools setup ....". Was das auch immer sein > mag. Das "No pools setup" ist weniger eine Fehlermeldung als mehr ein Hinweis, was man als nächstes tun könnte. Ohne die würde man mit einem ganz leeren Fenster dastehen. Aber ja, ein freundliche Begrüßungseite beim ersten Start ist durchaus sinnvoll. > Gleichzeitig mit dieser Meldung popt noch die im Anhang gezeigte > Fehlermeldung auf. Ich habe gar kein Laufwerk B. Ehrlich gesagt, keine Ahnung wie es dazu kommt. Die Fehlermeldung kommt von Windows selber, nicht von horizon. Wenn du magst, kannst du dem mit dem Process Monitor nachgehen und rausfinden worauf horizon hier genau zugreifen Will und wie der Stack an der Stelle ausschaut. Für die Runtime-Exception ist es hilfreich, wenn du horizon selber baust und aus der Msys-Shell startest: https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Windows Jan L. schrieb: > Leider ist der ‚offizielle‘ Stand nicht klar gekennzeichnet, und ein > Changelog scheint‘s auch nicht zu geben. Der offizielle Stand ist der master-branch im git, bzw. das letzte zip aus der Appveyor CI. Changelog sind die commit messages: https://github.com/carrotIndustries/horizon/commits/master Helmut S. schrieb: > Da hätte ich gerne die Wahl mit oder ohne andere Vias schieben. Ob das > der Cern-router kann? Unterstützt wird es vom router scheinbar, nur von horizon noch nicht. Der Titel "Halbfertig" hat sich in den letzten 1.5 Jahren doch sehr stark gewandelt, da horizon bereits für mittelgroße Projekte, wie z.B. Beitrag "Re: Neues, halbfertiges Elektronik-CAD-Programm" gut einsetzbar ist.
Lukas K. schrieb: > Der Titel "Halbfertig" hat sich in den letzten 1.5 Jahren doch sehr > stark gewandelt Vielleicht solltest du ja mal einen Fahrplan für eine Version 1.0 machen, sonst läufst du Gefahr, dass dein "halbfertiges" Horizon am Ende mehr kann als manches als "ganz fertig" verkaufte Werkzeug. :) Bei mir zu Hause (FreeBSD) habe ich leider im Moment link errors, da sind wohl ein paar Bibliotheken gerade inkonsistent (glibmm und Konsorten). Muss mal einen Rundum-Update-Schlag machen, damit ich wieder mal reinschauen kann.
Jörg W. schrieb: > Bei mir zu Hause (FreeBSD) habe ich leider im Moment link errors, da > sind wohl ein paar Bibliotheken gerade inkonsistent Zum Beispiel:
1 | dialogs/map_pin.cpp:10: error: undefined reference to 'Glib::operator<<(std::ostream&, Glib::ustring const&)' |
nm -D sagt mir, dass es in der Bibliothek gibt:
1 | 0000000000069520 T Glib::operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, Glib::ustring const&) |
Es dürfte die Diskrepanz zwischen "std::__1::basic_ostream" und "std::ostream" sein, vermute ich mal. Vielleicht hat ja jemand eine schnelle Idee, an welcher Stelle da was veraltet ist. Vermutung: glibmm ist mit einem älteren Compiler compiliert worden, Horizon braucht einen relativ neuen. Irgendwie hasse ich diese Umbenennerei in std::__1 …
Lukas K. schrieb: >> Leider ist der ‚offizielle‘ Stand nicht klar gekennzeichnet, und ein >> Changelog scheint‘s auch nicht zu geben. > > Der offizielle Stand ist der master-branch im git, bzw. das letzte zip damit war eher gemeint, welchen "groben Reifegrad" der Autor seiner Software zuordnet. Derzeit könnte ein geneigter Wiki-Besucher dank der netten Bildchen etc. auf die Idee kommen, es handele sich hier um eine "langjährig ausgereifte und abgehangene Produktivsoftware". Und "wundert" sich dann vielleicht doch, dass da je nach Wochentag halt schonmal eine DLL fehlen könnte, oder etwas, was gestern noch ging, heute nichtr mehr tut. Stünde da aber z.B. klar "hey, hot stuff, bleeding edge, work in progress" bzw. "das ist hier alpha- oder beta-Status", dann weiss jeder Interessierte, was ihn erwarten kann - behaupte ich mal... :) Natürlich könnte ich auch völlig auf dem Holzweg sein, und der Autor geht von einer "bereits ausgereiften Produktivsoftware" aus - dann, äh, würde ich mich natürlich umorientieren müssen... ;-) > aus der Appveyor CI. Changelog sind die commit messages: > https://github.com/carrotIndustries/horizon/commits/master Ja, ok, das stimmt natürlich - allerdings kann der geneigte Programminteressierte damit aber womöglich weniger anfangen, als mit einem "Meta-Changelog", aus dem die für den User relevanten Änderungen wie "Push-and-shove-Router eingebaut" nicht untergehen zwischen 100erten gleichartigen Einträgen der Art "missing DLL xy added" etc. Aber vermutlich spielt sowas erst dann eher eine Rolle, wenn es mal "offizielle Releases" gegeben hat, und man dann evtl. doch die relevanten Unterschiede zum Folgerelease dokumentieren möchte...
Hallo W.S. W.S. schrieb: > Ich benutze dieses knapp 7 Jahre alte Notebook eben auch wie du, um z.B. > hier in diesem Forum herumzudaddeln. Ich benutze ein altes Netbook von 2006. Es war schon vor jahren nicht mehr möglich, darauf ein aktuelles Windows zu installieren.... > Und ich komme genau wie du auch > nicht auf die Idee, ein EDA-System auf diesem Teil benutzen zu wollen. > Allerdings läuft die aktuelle Eagle-Bastler-Version 9.2 problemlos auf > diesem Notebook. Ich schon. Die Grafik kann zwar kein openGl, aber mit Mesa lässt sich openGL emulieren. Das ist schnarchlangsam, aber um mir unterwegs mal einen Schaltplan oder ein Layout/Bestückung anzusehen langt es. > Und was macht ihr, wenn Lukas übermorgen auf die Idee kommt, ein nettes > Feature aus OpenGL 4.6 zu benutzen? Nichts. Das ganze ist ja noch tief in der Betaphase. Da müssen halt radikale Schnitte noch möglich sein. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic.de http://www.dl0dg.de
Bernd W. schrieb: > Das ist schnarchlangsam, aber um mir unterwegs mal > einen Schaltplan oder ein Layout/Bestückung anzusehen langt es. Genau für so etwas verwende ich auch ein Notebook. Es ist sehr praktisch, es direkt neben Lötkolben und Mikroskop liegen zu haben, um einen direkten Blick auf die EDA-Daten werfen zu können.
W.S. schrieb: > Ich benutze dieses knapp 7 Jahre alte Notebook eben auch wie du, um z.B. > hier in diesem Forum herumzudaddeln. Und ich komme genau wie du auch > nicht auf die Idee, ein EDA-System auf diesem Teil benutzen zu wollen. > Allerdings läuft die aktuelle Eagle-Bastler-Version 9.2 problemlos auf > diesem Notebook. Interessant, dass dieser Betrag ein -1 bekommt.
Holm T. schrieb: > M. W. schrieb: > [..] >> >> Interessant, dass dieser Betrag ein -1 bekommt. > > ...wirklich? > > Gruß, > > Holm Auf die -1 würde ich pfeifen. Ich habe auch einen alten Laptop auf dem horizon nicht mehr läuft. Da mus halt ein neuerer her oder den Desktop nehmen der eine nicht so alte Grafikkarte hat. Meiner Meinung nach geht es bei Desktops ab GTX560 und höher oder neuer. Die Idee von Lukas ist es möglichst viel von der Grafikkarte selber zeichnen zu lassen. Dinge wie zoomen im PCB-layout gehen dann rasend schnell. Dazu werden natürlich bestimmte Fähigkeiten der Treiber der Grafikkarte benötigt.
W.S. schrieb: > Manchmal frag ich mich, warum. Ich kann's mir nur > mit überschäumendem Hormon erklären. Aber was soll denn das. Ist das nicht schon vor Monaten in epischer Breite diskutiert worden? Man nimmt so ein Riesenprojekt wie z.B. ein EDA-System nur in Angriff, wenn man sehr gern, gut und viel programmiert. Menschen, die gern, gut und viel programmieren, wollen PROGRAMMIEREN -- und nicht endlos über Datenmodellen, Userinterfaces, Dateiformaten und sparsamem Umgang mit den Ressourcen grübeln. Die Datenmodelle, Userinterfaces und Dateiformate sind aber das, was die Benutzbarkeit der Software für den Endanwender ausmacht. Es gibt deswegen überhaupt keine Garantie, dass selbst der begnadetste Superprogrammierer Software erschafft, die die Benutzer gern nutzen wollen. Das mag man zu Recht bedauern, aber das ergibt sich einfach daraus, dass Lukas durch keinerlei Vertrag verpflichtet ist, eine Software mit bestimmten Leistungsmerkmalen zu schaffen. > Kluge Entscheidungen vor dem Schreiben der ersten > Codezeile sehen anders aus. Klugheit bemisst sich an der Tauglichkeit, einem bestimmten Ziel näherzukommen. Ob Lukas seinen Zielen näher kommt, kannst Du überhaupt nicht beurteilen. Du kannst lediglich feststellen, dass er nicht die Software erschafft, die DU (oder ich) gern verwenden würde -- aber DAS ist nun keine echte Überraschung. Lukas' Klugheit wird nicht daran gemessen, inwieweit er DEINEN Zielen näherkommt :) Ich gebe Dir ja in einigen Sachfragen durchaus Recht, ich verstehe nur nicht, warum Du von jemandem, der Drechseln zu seinem neuen Hobby erkoren hat, erwartest, er würde jetzt zur Zimmerei wechseln, nur weil Du einen neuen Dachstuhl brauchst. Das muss doch nicht jedesmal neu durchgekaut werden.
Jan L. schrieb: > ...das überhaupt "ausführlich begründen" zu müssen halte > ich schon für sehr konziliant, weil offensichtlich... Was ist denn daran offensichtlich? Die (wenigen) EDA-Systeme, die ich (mehr oder weniger) kenne, kranken primär an: - einer Bedienung, die zwischen "eigenwillig" und "gehirnkrank" einzuordnen ist, - einem übergreifenden Datenmodell, das durch komplette Abwesenheit glänzt und - mangelnder Interoperabilität. Inwieweit hilft da eine egoshooter-taugliche Graphik weiter?
Egon D. schrieb: > Jan L. schrieb: > >> ...das überhaupt "ausführlich begründen" zu müssen halte >> ich schon für sehr konziliant, weil offensichtlich... > > Was ist denn daran offensichtlich? Dass eine nicht-kommerzielle one-man-show es weder leisten kann noch höchstwahrscheinlich Lust dazu verspürt, Flohmarkt-Hardware zu unterstützen. Wie da der Bezug zur "egoshooter-tauglichen Graphik" reingerät, verschliesst sich mir.
Egon D. schrieb: > Du kannst lediglich feststellen, dass er nicht die > Software erschafft, die DU (oder ich) gern verwenden > würde Also damit beschreibst du genau DAS, was ich mit "Hormon" schon gesagt habe. Das Beipiel von Autofahrern, die kurz vor dem Abbiegen ihrem Motor nochmal so richtig die Sporen geben, weil ihnen eben das Mütchen danach ist, hatte ich ja schon genannt. Aber sag mal, findest du denn nicht, daß das Programmieren eines derartigen Projektes OHNE Anzielen einer breiten Verwendung irgendwie.. nun ja, eher etwas eigentümlich ist? Oder nennen wir es mutwillig? Etwa vergleichbar mit dem zweiten Gang bis Anschlag "una musica dolce suonava soltanto per me"? W.S.
W.S. schrieb: > Aber sag mal, findest du denn nicht, daß das Programmieren eines > derartigen Projektes OHNE Anzielen einer breiten Verwendung irgendwie.. > nun ja, eher etwas eigentümlich ist? Das ist doch nur deine Wahrnehmung, dass er keine breite Verwendung anzielen würde. Selbst du gibst ja zu, dass du diesen ältlichen Computer nur ausgekramt hast, damit du eine reale Hardware vorweisen kannst, auf der das nicht läuft – obwohl du diese Hardware am Ende nicht tatsächlich dazu benutzen wölltest, EDA damit zu machen. Weil sie eben auch für Software, die darauf noch läuft, lahm genug ist, als dass das gar keinen Spaß macht, das wirklich darauf zu tun.
Helmut S. schrieb: > Holm T. schrieb: >> M. W. schrieb: >> [..] >>> >>> Interessant, dass dieser Betrag ein -1 bekommt. >> >> ...wirklich? >> >> Gruß, >> >> Holm > > Auf die -1 würde ich pfeifen. Exakt! >Ich habe auch einen alten Laptop auf dem > horizon nicht mehr läuft. Da mus halt ein neuerer her oder den Desktop > nehmen der eine nicht so alte Grafikkarte hat. Meiner Meinung nach geht > es bei Desktops ab GTX560 und höher oder neuer. Es ist völliger Blödsinn sich bei Mikeysoft darüber beklagen zu wollen das irgend ein Programm von denen auf einem Alten Topplappen nicht mehr läuft, hier meint man aber damit Eindruck schinden den zu können. > > Die Idee von Lukas ist es möglichst viel von der Grafikkarte selber > zeichnen zu lassen. Dinge wie zoomen im PCB-layout gehen dann rasend > schnell. Dazu werden natürlich bestimmte Fähigkeiten der Treiber der > Grafikkarte benötigt. Das ist ja auch vernünftig. In allererster Linie schreibt er das Programm für sich selbst, nach seinen Bedürfnissen. (alle Achtung!!) Ich halte es für absolut nicht verwunderlich wenn er da nun nicht die Befindlichkeiten jeder religiösen Minderheit berücksichtigt die sich gerade für am Wichtigsten hält. Die Bewertung? Drauf geschi..... Gruß, Holm
Jan L. schrieb: > Egon D. schrieb: >> Jan L. schrieb: >> >>> ...das überhaupt "ausführlich begründen" zu müssen >>> halte ich schon für sehr konziliant, weil >>> offensichtlich... >> >> Was ist denn daran offensichtlich? > > Dass eine nicht-kommerzielle one-man-show es weder > leisten kann noch höchstwahrscheinlich Lust dazu > verspürt, Flohmarkt-Hardware zu unterstützen. Verstehe ich nicht. Software, die auf einer alten Mühle anständig läuft, tut es ganz sicher auch auf einer aktuellen Maschine. Software, die auf einer aktuellen Maschine nur anständig läuft, ist auf einer alten Mühle nicht verwendbar -- dazu müsste sie auf einer aktuellen Maschine irrsinnig schnell sein :) Es geht überhaupt nicht darum, besondere, nicht leistbare Aufwendungen zu tätigen, um uralte, exotische Hardware zu unterstützen -- es geht nur darum, mit den Ressourcen nicht um sich zu werfen. > Wie da der Bezug zur "egoshooter-tauglichen Graphik" > reingerät, verschliesst sich mir. Der kommt durch Helmuts Bemerkung über "rasend schnelles zoomen" zustande. Ich sage es gerne nochmal, auch wenn Du es nicht hören willst: An der EDA-Software, die ich kenne, hat mir NIE irgend eine Graphikfähigkeit gefehlt, sondern immer nur Dinge, die man auch auf Hardware von vor 20 Jahren hätte realisieren können. Sie sind aber (vermutlich) deshalb nicht realisiert worden, weil das (zumindest bei der preiswerten Software) ökonomisch einfach nicht drin war.
Egon D. schrieb: > Verstehe ich nicht. Dann geh' mal paar Postings zurück: Beitrag "Re: Neues, halbfertiges Elektronik-CAD-Programm" Dort hat Helmut noch einmal kurz zusammengefasst, warum Lukas sich so entschieden hat. Man könnte es auch noch kürzer zusammenfassen: Konzentration auf das Wesentliche, statt sich in Nebenschauplätzen zu verlieren, nur um Hardware aus dem letzten Jahrhundert auch noch unterstützen zu können. Als One-Man-Show muss man halt sehen, wo man seine Ressourcen investiert. > Dinge, die man auch auf Hardware von vor 20 Jahren hätte realisieren können. Dann hast du wohl noch nie mit einem EDA-System mit 3D-Darstellung gearbeitet – egal, ob nun Kicad oder Altium. Das hätte man nämlich auf der Hardware von vor 20 Jahren einfach nicht machen können, ist aber eine wirklich gute Hilfe, wenn man das einmal benutzen durfte. Kann einem gut und gern mal einen Prototypenzyklus einsparen, bei dem man sonst nur festgestellt hätte, dass Bauteil xyz am Ende doch mit einem Gehäusevorsprung kollidiert … Möchte ich nicht mehr missen, ehrlich.
Egon D. schrieb: > Jan L. schrieb: > >> Egon D. schrieb: >>> Jan L. schrieb: >>> >>>> ...das überhaupt "ausführlich begründen" zu müssen >>>> halte ich schon für sehr konziliant, weil >>>> offensichtlich... >>> >>> Was ist denn daran offensichtlich? >> >> Dass eine nicht-kommerzielle one-man-show es weder >> leisten kann noch höchstwahrscheinlich Lust dazu >> verspürt, Flohmarkt-Hardware zu unterstützen. > > > Verstehe ich nicht. > > Software, die auf einer alten Mühle anständig läuft, > tut es ganz sicher auch auf einer aktuellen Maschine. > > Software, die auf einer aktuellen Maschine nur anständig > läuft, ist auf einer alten Mühle nicht verwendbar -- > dazu müsste sie auf einer aktuellen Maschine irrsinnig > schnell sein :) Dein Denkfehler liegt nicht in der Hardware, sondern in der Software begründet. WS Rechner funktioniert nicht, weil seine Treibersoftware auf diesem Rechner unzureichend ist. Das hat mir Recourcenverschwendung nicht viel zu tun und wenn es das hat, dann ist Lukas der falsche Ansprechpartner. Läufst denn auf diesem Rechner mit Linux und Mesa? Wen ja: bitte sehr. Wenn langsam: Du wolltest das Ding verwenden. Wenn nicht: der Taschenrechner ist wirklich zu alt. Keine Hände, keine Kekse! Gruß, Holm
W.S. schrieb: > Egon D. schrieb: >> Du kannst lediglich feststellen, dass er nicht die >> Software erschafft, die DU (oder ich) gern verwenden >> würde > > Also damit beschreibst du genau DAS, was ich mit > "Hormon" schon gesagt habe. Nicht ganz. Dein "hormongesteuert" drückt eine negative Wertung aus, die meiner Formulierung (hoffentlich) fehlt. Auch wenn ich betrübt über Lukas' Entscheidung bin, so muss ich ihn deshalb nicht gleich beleidigen. > Aber sag mal, findest du denn nicht, daß das > Programmieren eines derartigen Projektes OHNE Anzielen > einer breiten Verwendung irgendwie.. nun ja, eher etwas > eigentümlich ist? Nein -- und zwar aus zwei Gründen. Zum einen: "Breit" liegt im Auge des Betrachters. Selbst wenn von den -- aus der Luft gegriffen -- 10 Millionen EDA-Leuten nur eine verschwindenden Minderheit von 0.1% horizon verwenden, wären das 10'000 Nutzer. Wenn solche verbitterten Rentner wie Du und ich nicht zu diesen 0.1% gehören, so wird das für Lukas kein Problem sein... :) Zum zweiten: Wer die Diskussionen in Newsgroups und Foren kennt, der weiss, dass man sich keinesfalls von der "öffentlichen Meinung" abhängig machen darf. Es ist ratsam, auf fundierte Kritik zu hören -- aber mehr auch nicht, ansonsten kommt man zu gar nichts. Es ist also durchaus eine gute Idee, selbst ein klares, an den eigenen Bedürfnissen orientiertes Konzept zu haben, an dem man sich orientiert. Wenn dann noch andere Nutzer dazukommen, die mit den eigenen Grundwerten übereinstimmen -- um so besser. Du kritisierst meiner Meinung nach Lukas auf einer Ebene, auf der er nichts falsch macht.
Leute, das hier jemand (Lukas) nicht nachgedacht hat und einfach das neueste benutzt was ihm untergekommen ist kann ich verstehen. Auch wenn ich es sehr bedauere, weil ich mit meiner Onboard Grafikkarte nicht teilhaben kann. Eine 2. Karte kann ich nicht mehr einbauen, weil kein Platz. Ein neuer Rechner kommt mir nur wegen einem CAD System nicht ins Haus. Ich kenne noch andere Projekte wo ich schon dem Entwickler vor 10 Jahren gesagt hatte das seine Entscheidung (.NET + XNA) eine Dummheit ist. Nun heute ist sein Produkt zwar fertig, aber er hat sich selber in die WINDOWS Ecke gedrückt wobei alle mitbewerber auch Linux und MAC können. QT und Konsorten, sind da halt einfach besser porttierbar. Achso, ratet mal was öfter benutzt wird.
Klaus schrieb: > Leute, das hier jemand (Lukas) nicht nachgedacht hat und einfach das > neueste benutzt was ihm untergekommen ist kann ich verstehen. Ist allerdings nicht der Fall. Er hat nachgedacht – und deshalb das benutzt, was seit 10 Jahren (inzwischen) am Markt verfügbar ist.
Jörg W. schrieb: > Dann hast du wohl noch nie mit einem EDA-System > mit 3D-Darstellung gearbeitet – egal, ob nun Kicad > oder Altium. ... oder Target. -- Doch, das habe ich. > Das hätte man nämlich auf der Hardware von vor 20 Jahren > einfach nicht machen können, ist aber eine wirklich gute > Hilfe, wenn man das einmal benutzen durfte. Kann einem > gut und gern mal einen Prototypenzyklus einsparen, bei > dem man sonst nur festgestellt hätte, dass Bauteil xyz > am Ende doch mit einem Gehäusevorsprung kollidiert … > Möchte ich nicht mehr missen, ehrlich. <Seufz> Ich weiss wirklich nicht, was daran so schwer zu verstehen ist: Natürlich das das Feature SINNVOLL -- aber es ist mir nicht wichtig genug, um andere Eigenschaften der Software dafür zu opfern. Ist das so schwer zu begreifen?
Holm T. schrieb: > Dein Denkfehler liegt nicht in der Hardware, sondern > in der Software begründet. WS Rechner funktioniert > nicht, weil seine Treibersoftware auf diesem Rechner > unzureichend ist. Es geht (mir) nicht um W.S.'s Rechner, sondern um die Graphik-Fixierung von horizon. Mir hat bei den EDA-Systemen, mit denen ich bisher zu tun hatte, NIE irgend eine Graphikfähigkeit gefehlt. Ergo sind alle Argumente, die auf die überlegenen Graphikfähigkeiten von horizon zielen, für mich gleichwertig zu leeren Zeichenketten. Das hat einfach keine Priorität. Wenn etwas, was ich nicht brauche, einfach so dabei ist, dann stört das nicht. Wenn ich aber für etwas, das ich nicht benötige, zusätzliche Komplikationen in Kauf nehmen muss, dann ist der Spaß zu Ende.
Egon D. schrieb: > <Seufz> Ich weiss wirklich nicht, was daran so schwer zu verstehen ist: > Natürlich das das Feature SINNVOLL -- aber es ist mir nicht wichtig > genug, um andere Eigenschaften der Software dafür zu opfern. Naja, was genau „opferst“ du denn? Aber eigentlich ist das jetzt so langsam egal, dreht sich eh' nur alles im Kreise. Zum Glück arbeitet Lukas unabhängig von all diesem Palaver daran wohl weiter. ;-) Das ist das beste, was er tun kann. Im Gegensatz zu W.S. sehe ich sowieso nicht, dass nur deshalb, weil Horizon sich auf einen Mindeststandard an OpenGL-Level festgelegt hat, ihm die Nutzer ausbleiben würden. Die meisten potenziellen Nutzer werden das vermutlich nicht einmal bemerken, dass diese Anforderung existiert, und sie werden Horizon nach ganz anderen Kriterien bewerten, ob sie damit dann arbeiten möchten oder nicht.
Jörg W. schrieb: >> Dinge, die man auch auf Hardware von vor 20 Jahren hätte realisieren können. > > Dann hast du wohl noch nie mit einem EDA-System mit 3D-Darstellung vor allem - er hat sicherlich auch noch nie eines programmiert. Würde ich heute mit der Erstellung irgendeiner Anwendung anfangen, dann würde ich ganz sicher die APIs von heute nehmen, die mir Basisfunktion X und Y abnehmen, und nicht die APIs von vorgestern, bei denen ich womöglich noch langweilige Dinge wie Bresenham zu Fuss basteln müsste, nur damit's auch auf Herkulesgrafik noch täte... :-)
Jan L. schrieb: > Jörg W. schrieb: >>> Dinge, die man auch auf Hardware von vor 20 Jahren >>> hätte realisieren können. >> >> Dann hast du wohl noch nie mit einem EDA-System mit >> 3D-Darstellung [gearbeitet] > > vor allem - er hat sicherlich auch noch nie eines > programmiert. Wird schätzungsweise auch nie passieren. Unwahrscheinlich, aber dennoch möglich wäre immerhin, dass ich mal an einem EDA-System arbeite. Das bekommt mit hoher Wahrscheinlichkeit einen 3D-Export, so dass man einen externen Viewer aufrufen kann, wenn einem das wichtig ist. Das EDA-System ist natürlich auch ohne 3D-Viewer benutzbar.
Jörg W. schrieb: > Egon D. schrieb: >> <Seufz> Ich weiss wirklich nicht, was daran so >> schwer zu verstehen ist: Natürlich das das Feature >> SINNVOLL -- aber es ist mir nicht wichtig genug, >> um andere Eigenschaften der Software dafür zu opfern. > > Naja, was genau „opferst“ du denn? Modularität beispielsweise. Aber das ist vor Monaten alles schon durchgekaut worden. > Aber eigentlich ist das jetzt so langsam egal, Eigentlich nicht. Es ist nicht egal -- man kann es nur nicht ändern. Das ist nicht dasselbe. > Im Gegensatz zu W.S. sehe ich sowieso nicht, dass nur > deshalb, weil Horizon sich auf einen Mindeststandard > an OpenGL-Level festgelegt hat, ihm die Nutzer > ausbleiben würden. Nein, deshalb nicht. Die OpenGL-Sache ist nur das Symptom, nicht die Ursache. > Die meisten potenziellen Nutzer werden das vermutlich > nicht einmal bemerken, dass diese Anforderung existiert, > und sie werden Horizon nach ganz anderen Kriterien > bewerten, ob sie damit dann arbeiten möchten oder nicht. Richtig. Sie werden sie nach den Kriterien bewerten, die sie an x-beliebige fertige Software anlegen: Entweder sie gefällt ihnen, dann werden sie sie verwenden, oder sie gefällt ihnen nicht, dann verwenden sie sie eben nicht. Eine Möglichkeit, diese Software grundlegend mitzugestalten, hatten sie ja nicht. Und -- nein, das ist keine echte Kritik. Es ist nur eine etwas enttäuschte Feststellung.
Egon D. schrieb: > Eine Möglichkeit, diese Software grundlegend mitzugestalten, hatten sie > ja nicht. In Teilen schon, allerdings nicht im Konzept. Aber das ist OK für eine One-Man-Show. Lukas wollte ja in erster Linie etwas für sich machen, weil er mit dem Existierenden unzufrieden war. Er stellt es außerdem allen zur Verfügung.
Egon D. schrieb: > Das bekommt > mit hoher Wahrscheinlichkeit einen 3D-Export, so dass > man einen externen Viewer aufrufen kann, wenn einem > das wichtig ist. > > Das EDA-System ist natürlich auch ohne 3D-Viewer > benutzbar. "3D-Export", "3D-Viewer"... klingt, als würdest du davon ausgehen, dass die Festlegung auf OpenGL 3.2 als Mindeststandard irgendwie mit "3D" zu tun hat. Hat es aber eher nicht... Ob du nun den "3D-Viewer" weglässt, oder nicht - OpenGL3.x malt dir halt ohne Krücken automatisch hübsche runde Ecken (und vieles andere) ins Canvas... :)
Jörg W. schrieb: > Egon D. schrieb: >> Eine Möglichkeit, diese Software grundlegend >> mitzugestalten, hatten sie ja nicht. > > In Teilen schon, allerdings nicht im Konzept. Tja... ich hatte mal so einen Chef. Der Mann war fachlich gut und sehr vielseitig, aber er hatte die Macke, das Grundkonzept für unsere Geräte in seiner kompletten Breite festlegen zu wollen -- also das physikalische Prinzip, die Werkstoffauswahl, die Mechanik, die analoge Hardware, die Software. Völlig unnötig zu erwähnen, dass der Mann zwar besser war als jeder Einzelne von uns Technikern -- aber er war nicht besser als wir alle zusammen. Folge: Seine Konzepte waren i.d.R. untauglich; die Geräte nur verkaufbar, weil die Techniker massiv Arbeit in die Verbesserung gesteckt haben. > Aber das ist OK für eine One-Man-Show. Ich kritisiere den Verlauf dieser Ein-Mann-Show nicht. Ich bin enttäuscht davon, dass es erklärtermaßen eine solche bleiben soll.
Jan L. schrieb: > Egon D. schrieb: >> Das bekommt >> mit hoher Wahrscheinlichkeit einen 3D-Export, so dass >> man einen externen Viewer aufrufen kann, wenn einem >> das wichtig ist. >> >> Das EDA-System ist natürlich auch ohne 3D-Viewer >> benutzbar. > > "3D-Export", "3D-Viewer"... klingt, als würdest du > davon ausgehen, dass die Festlegung auf OpenGL 3.2 als > Mindeststandard irgendwie mit "3D" zu tun hat. Hat es > aber eher nicht... Ach ja, richtig, da war was... > Ob du nun den "3D-Viewer" weglässt, oder nicht - OpenGL3.x > malt dir halt ohne Krücken automatisch hübsche runde Ecken > (und vieles andere) ins Canvas... :) Ja, naja, und genau das ist der Punkt: Die hübschen runden Ecken mögen zwar hübsch sein -- aber sie sind völlig verzichtbar. Ich würde auch eine Xlib-basierte Software verwenden, wenn sie das macht, was ich brauche. Eine Bauteilbibliothek, die den Namen verdient, ist aber NICHT nur hübsch, sondern essenziell. Da die Prioritäten auf "hübsch aussehen" liegen und nicht auf "essenziell", taugt die Software für mich nicht, und da Mitarbeit, die über Kosmetik hinausgeht, nicht gewünscht ist, muss ich mich halt anderweitig umsehen.
Egon D. schrieb: > Ja, naja, und genau das ist der Punkt: Die hübschen runden > Ecken mögen zwar hübsch sein OMG, das war doch nur ein Beispiel; hier (für dich) substantieller vielleicht: OGL3.x malt dir das Grid automatisch. Und sicherlich noch einiges an "Routine" mehr... > Eine Bauteilbibliothek, die den Namen verdient, ist aber > NICHT nur hübsch, sondern essenziell. wo kommt denn jetzt die "Bauteilebibliothek" auf einmal her? Da geht ja Flöhe hüten einfacher... > Da die Prioritäten auf "hübsch aussehen" liegen und nicht > auf "essenziell", taugt die Software für mich nicht, und > da Mitarbeit, die über Kosmetik hinausgeht, nicht gewünscht > ist, muss ich mich halt anderweitig umsehen. jetzt wird's aber etwas wunderlich, finde ich - das Ding liegt im Github, und erst wenn dein dritter brauchbarer Pullrequest abgelehnt wird, gäbe es überhaupt mal Anlass, über der Grad der gewünschten Mitarbeit zu spekulieren. Und dann gehst du eben hin und klonst das Repo, und stellst deine Version der Allgemeinheit zur Verfügung...
Egon D. schrieb: > Da die Prioritäten auf "hübsch aussehen" liegen und nicht auf > "essenziell", Das ist allerdings eine recht unfaire Unterstellung. Lukas hat klar und deutlich Konzepte hinter seiner Implementierung, das ist nicht „irgendwie drauf los programmiert“. Die Konzepte gehen auch deutlich über eine zeitgemäß aussehende Grafik hinaus. > taugt die Software für mich nicht Das ist eine Schlussfolgerung für dich, aber hat mit „hübsch aussehen“ nun nichts zu tun. Es heißt lediglich, dass Lukas' Konzepte nicht die sind, die du von so einer Software erwarten würdest. Andere Anwender können das völlig anders sehen.
Jörg W. schrieb: > Lukas hat klar und deutlich Konzepte hinter seiner > Implementierung, Das habe ich nirgendwo bestritten. > das ist nicht „irgendwie drauf los programmiert“. War nie meine Behauptung. Verwechselst Du mich mit W.S.? > Die Konzepte gehen auch deutlich über eine zeitgemäß > aussehende Grafik hinaus. Mag sein. Als das vor Monaten hier diskutiert wurde, hieß es z.B. "SPICE-Export ist nicht vorgesehen." Auch wenn ich kein großer SPICE-Fan bin -- aber das geht mir etwas zu weit. Austauschbarkeit von Symbolen, Footprints, Schaltplänen und Layouts mit anderer Software hatte, soweit ich mich entsinne, auch keine Priorität. Von projektübergreifend kompatiblen Schnittstellen, so dass man den horizon-Schaltplaneditor mit pcb-rnd kombinieren kann, ist sowieso keine Rede. Also: Das übliche. Alles, was mit herkömmlicher Software nicht geht, geht mit horizon auch nicht. >> taugt die Software für mich nicht > > Das ist eine Schlussfolgerung für dich, aber hat mit > „hübsch aussehen“ nun nichts zu tun. Es heißt lediglich, > dass Lukas' Konzepte nicht die sind, die du von so einer > Software erwarten würdest. Andere Anwender können das > völlig anders sehen. Ich verstehe nicht ganz, warum Dich meine Einschätzung so aufbringt. Jedermann hat nur eine begrenzte Arbeitskraft. Was ich von außen sehe, das ist: Das GUI von horizon sieht ziemlich geil aus. Funktionalität, die ich für wichtig halte, spielt keine Rolle. Ob das nur Korrelation oder schon Kausalität ist, will ich nicht beurteilen -- es ist aber auch egal.
Jörg W. schrieb: > Im Gegensatz zu W.S. sehe ich sowieso nicht, dass nur deshalb, weil > Horizon sich auf einen Mindeststandard an OpenGL-Level festgelegt hat, > ihm die Nutzer ausbleiben würden. Jörg, versuche doch bitte mal ganz einfach ruhig mitzulesen, ohne auf alles allergisch zu reagieren. Egon hat lediglich das gesagt: Egon D. schrieb: > Du kannst lediglich feststellen, dass er nicht die > Software erschafft, die DU (oder ich) gern verwenden > würde -- aber DAS ist nun keine echte Überraschung. Eben, es ist für niemanden eine Überraschung, insbesondere nicht für mich - siehe meine früheren Einlassungen. Dennoch frage ich mich nach dem WARUM. Irgend ein 'warum' muß es ja geben. ODER ETWA NICHT? Ich habe mein ganzes Leben lang meine Entwicklungen genau SO betrieben, daß ich mit einer möglichst großen Käuferschicht rechnen kann. Sowas ist derart lebensnotwendig, daß allenfalls jemand aus dem öff.Dienst es nicht versteht. Aber jeder, der seine Brötchen selbst verdienen muß, versteht das sofort. Warum also macht Lukas das so wie er es macht? Ich sehe da zwei Gründe: die pure Lust am Programmieren (die ich in jungen Jahren ebenfalls in den Knochen gespürt habe) und das Bestreben, mal was vorzulegen, womit man am Beginn seines Berufslebens Eindruck machen kann und folglich schneller und höher hinaus kommt. Beides sind wirklich ernsthafte und zu akzeptierende Beweggründe - wenn man mal drüber nachdenkt! Aber bei beiden Gründen tritt die tatsächliche Verbreitung des Produkts in den Hintergrund - das wäre mein Punkt, den du jedoch indirekt in Frage gestellt hast. Es gäbe auch noch einen anderen Grund: die innere Verärgerung darüber, wie es andere Hersteller machen und daraus der Ansporn, eben die Punkte, die einem selber mißfallen mal exemplarisch besser zu machen. Aber dann sind Hardwareangelegenheiten wie OpenGL eher nebensächlich. Also: Ich gönne dem Lukas die beiden ersten Gründe voll und ganz, da hat er meine Sympathie. Ich kann auch Grund #4 verstehen. Aber Grund #3 sollte dabei nicht untergehen, möglicherweise bedarf es nur eines kleinen Kringels im Programm. Es wäre jedenfalls SCHADE. Bedenke mal, daß es auch Rückwärts-Inkompatibilitäten zwischen OpenGL 3 und 4 gibt, so daß Lukas in jedem Falle irgendwann eine Abstraktion oberhalb OpenGL und darunter eine Versionsbehandlung wird einführen müssen. Da ist 2.1 versus 3.3 nur die Spitze des Eisberges. So, denk mal ganz ruhig drüber nach. W.S.
Egon D. schrieb: > Als das vor Monaten hier diskutiert wurde, hieß es z.B. "SPICE-Export > ist nicht vorgesehen." Auch wenn ich kein großer SPICE-Fan bin -- aber > das geht mir etwas zu weit. „nicht vorgesehen“ heißt ja erstmal nicht, dass man das nicht haben kann, sondern nur, dass er sich darum (zumindest derzeit) nicht kümmert. Wäre ein Punkt, wo jemand anders eingreifen könnte, wenn er möchte, denn dass es konzeptionell gar nicht möglich ist, das zu realisieren, vermute ich zumindest nicht. So ein Export ist ja erstmal nur eine Datenkonvertierung, das kann man am Ende sogar in einer Scriptsprache hinlegen. > Austauschbarkeit von Symbolen, Footprints, Schaltplänen und Layouts mit > anderer Software hatte, soweit ich mich entsinne, auch keine Priorität. Hätte ich mir an seiner Stelle auch nicht als Priorität gesetzt. Das ist nämlich ein Fass ohne Boden. Habe sowas schon mal bei BAE gesehen, welches Eagle-Import-Scripte hat. Diskutiert hatten wir darüber auch schon, kann ich mich erinnern. > Von projektübergreifend kompatiblen Schnittstellen, so dass man den > horizon-Schaltplaneditor mit pcb-rnd kombinieren kann, ist sowieso keine > Rede. Wäre die Frage, wofür man sowas braucht. Und falls es jemand braucht, was derjenige denn an Horizon ändern müsste, um so eine Schnittstelle zu haben. Die einzige Schnittstelle, die ich mir „projektübergreifend kompatibel“ jemals bei EDA-Software gewünscht hätte, wäre ein mögliches Anflanschen des BAE-Autorouters … der ist wirklich gut. Kann man aber vergessen, denn die BAE-Schnittstelle ist nicht offengelegt. Ansonsten ist es mir lieber, wenn der Board-Editor eines Systems sinnvoll und gut zum Schaltplaneditor passt.
Jan L. schrieb: > Egon D. schrieb: >> Ja, naja, und genau das ist der Punkt: Die hübschen >> runden Ecken mögen zwar hübsch sein > > OMG, das war doch nur ein Beispiel; hier (für dich) > substantieller vielleicht: OGL3.x malt dir das Grid > automatisch. Und sicherlich noch einiges an "Routine" > mehr... Nein, das ist für mich nicht substanzieller. Ein Gitter konnte man auch vor OpenGL schon zeichnen -- und hat das auch getan. Dass das jetzt in 1µs statt in 1ms abläuft, interessiert mich ehrlich gesagt nicht. >> Eine Bauteilbibliothek, die den Namen verdient, ist >> aber NICHT nur hübsch, sondern essenziell. > > wo kommt denn jetzt die "Bauteilebibliothek" auf > einmal her? "OMG, das ist ein Beispiel!" Und zwar ein Beispiel für eine Sache, die mir wesentlich wichtiger ist als eine geile Graphik. >> Da die Prioritäten auf "hübsch aussehen" liegen und >> nicht auf "essenziell", taugt die Software für mich >> nicht, und da Mitarbeit, die über Kosmetik hinausgeht, >> nicht gewünscht ist, muss ich mich halt anderweitig >> umsehen. > > jetzt wird's aber etwas wunderlich, finde ich - das Ding > liegt im Github, und erst wenn dein dritter brauchbarer > Pullrequest abgelehnt wird, gäbe es überhaupt mal Anlass, > über der Grad der gewünschten Mitarbeit zu spekulieren. Da muss ich nicht spekulieren. Es gibt keinen Zweifel daran, dass die Art der Mitarbeit, die ich bieten könnte, nicht gewünscht wird. > Und dann gehst du eben hin und klonst das Repo, und > stellst deine Version der Allgemeinheit zur Verfügung... Das werde ich aus dem einfachen Grund nicht tun, weil ich von C++ keine Ahnung habe. Wenn, dann ist es deutlich wahrscheinlicher, dass ich mal zu pcb-rnd Kontakt aufnehme, denn dort scheint mir die Einstiegsschwelle WESENTLICH niedriger.
W.S. schrieb: > Aber bei beiden Gründen tritt die tatsächliche > Verbreitung des Produkts in den Hintergrund - das > wäre mein Punkt, den du jedoch indirekt in Frage > gestellt hast. Ich kann Dir offen gestanden nicht folgen. Du hast weiter oben gefragt, ob es denn nicht eigenartig wäre, eine Software zu erstellen und zu publizieren, an deren Verbreitung man nicht wirklich interessiert ist. Meine Antwort war: Nein, das ist nicht eigenartig. Jetzt lieferst Du selbst Gründe dafür, warum ein Mensch genau das tut: Software erstellen, an deren Verbreitung er nicht vorrangig interessiert ist. Wo siehst Du jetzt den Widerspruch? Ich habe auch mindestens ein Projekt, bei dem ich zwar gern Feedback, gute Ideen und unbezahlte Tester hätte, aber nicht wirklich gern sehen würde, wenn andere die Software kommerziell einsetzen. Nun ja... beides gleichzeitig geht halt nicht :)
Hey, ich bin dabei alternativen für Eagle zu evaluieren und da sehen mir KiCad und Horizon interessant aus. Den aktuelle Stand bekomme ich jedoch leider nicht compiliert (Debian Stretch)
1 | src/parameter/program_polygon.hpp:8:7: error: no matching function for call to ‘horizon::ParameterProgram::ParameterProgram()’ |
2 | In file included from src/pool/padstack.hpp:9:0, |
3 | from src/package/pad.hpp:5, |
4 | from src/pool/package.hpp:14, |
5 | from src/pool/package.cpp:1: |
6 | |
7 | src/pool/padstack.cpp:13:112: error: use of deleted function ‘horizon::ParameterProgramPolygon::ParameterProgramPolygon()’ |
8 | Padstack::MyParameterProgram::MyParameterProgram(Padstack *p, const std::string &c) : ParameterProgram(c), ps(p) |
Vielleicht interessiert dies ja die Entwickler und lässt sich leicht beheben.
Malte _. schrieb: > Vielleicht interessiert dies ja die Entwickler und lässt sich leicht > beheben. Ist behoben und sollte in Zukunft auch nicht mehr so einfach passieren, da die CI jetzt auch mit debian stretch statt ubuntu artful baut.
Ein paar Worte zu OpenGL an der Stelle noch: OpenGL kommt sowohl zum Rendern von 2D-Ansichten wie Schaltplan und Board zum Einsatz, als auch für die 3D-Vorschau. Bei letzterer ergeben sich mit Geometry shadern ganz nette Möglichkeiten, so müssen z.B. für "Boden" und "Deckel" der Layer insgesamt nur ein Satz Dreieecke auf die GPU geladen werden, das Duplizieren nach oben und unten geschieht dann im geometry shader auf der GPU. Auch für die Wände wird nur die Kontur auf die GPU geladen, die macht daraus dann die Dreieecke für die Wand. In der 2D-Ansicht bekommt man Dinge wie Alpha-Transparenz quasi für Umme. Auch die Auswahl-Boxen werden weitestgehend in Shadern auf der GPU gemalt. Nun mag einer entgegnen, das ginge ja auch ohne OpenGL in Software, was grundsätzlich auch stimmt. Allerdings müsste ich mir dann mehr Gedanken darüber machen, was mit der darunter liegenden Grafik geschieht, wenn die Auswahl-Box wieder weg ist. Mit OpenGL alles kein Problem und ich kann mich auf die wirklich wichtigen Dinge konzentrieren. Zumal (viele) Computer der letzten 10 Jahre einen geeigneten Coprozessor (GPU) haben, der genau für solche Grafikaufgaben gemacht ist. Wär' ja schade, wenn der sich langweilt.
Lukas K. schrieb: > Zumal (viele) Computer der letzten 10 Jahre einen geeigneten Coprozessor > (GPU) haben, der genau für solche Grafikaufgaben gemacht ist. Wär' ja > schade, wenn der sich langweilt. Dein Ansatz ist schon richtig - Wenn W.S. für Android entwickeln würde, dann vmtl die nächsten 10 Jahre noch für Android 4 SCNR ;-)
Lukas K. schrieb: > In der 2D-Ansicht bekommt man Dinge wie Alpha-Transparenz quasi für > Umme. Darauf möchte ich auch nicht mehr verzichten müssen. :) Ohne OpenGL ist das nicht nur Aufwand in der Programmierung, sondern auch wirklich vermplemperte Rechenzeit der CPU, die sie für besseres benutzen kann.
Ich bin nochmal alle Argumente hier durchgegegangen und finde eigentlich nur eine Quintessenz daraus: Man programmiere sich sein eigenes tool zum Selbstzweck und aus Spass am Programmieren. Sinn macht es keinen. Wer ernsthaft Funktionalität verbessern will, der muss sich in ein bestehendes Programm einklinken und z.B.: * Ein ULP für EAGLE schreiben, welches die Funktionen hat * Einen alternativen Editor für KiCAD entwickeln * Einen alternativen Autorouter / Placer schreiben * Einen Checker zur Einhaltung bestimmter Regeln im Sonderplatinenbau entwickeln, der übers Design rattert * und und und Gerade KiCAD bietet uns damit alle Möglichkeiten. Die Sourcen sind mehr oder weniger frei verfügbar und auch dokumentiert. Dort würde ich einhaken, weil sich da auch sofort Unterstützer finden, die ein Projekt weiterziehen, wenn man selber nicht mehr kann.
M. W. schrieb: > Gerade KiCAD bietet uns damit alle Möglichkeiten. Ach, Mensch. Was willst du damit in diesem Thread? Hast du ihn wirklich gelesen? Lukas hatte ganz am Anfang mal geschrieben, dass er diese Idee durchaus auch hatte. Hat er zu den Akten gelegt, weil da eben vieles schon zu „verbaut“ ist, und das, was ihm wichtig war, auf diese Weise nicht oder nur außerordentlich umständlich realisierbar schien. > Sinn macht es keinen. Mag deine Meinung sein, und wir haben ja Meinungsfreiheit. Aber außer W.S. und einigen wenigen anderen werden die meisten Mitleser dieses Threads wohl diese deine Meinung eher nicht teilen.
Ich finde es ja super, was Lukas hier auf die Beine stellt. Ich verstehe auch die Beweggründe, sein eigenes Ding machen zu wollen, ohne Kompromisse einzugehen. Nur für den Anwender und die Open Source Szene ist das die übliche Katastrophe! Anstatt die Energie auf ein CAD zu bündeln, und dieses zur Perfektion zu bringen, bleiben viele Baustellen übrig, die meistens irgendwann nicht mehr gewartet werden. Jedes Programm hat ab einer gewissen Komplexität und Reife eine lange Liste von Kompromissen und Eigenheiten. Da ist Lukas CAD nicht anders. Ich würde da auch nichts ändern wollen, reine Bloatware igitigit :-) Programmierer wollen programmieren, und nicht den Code anderer verstehen und debuggen, der per Definition suboptimal ist. Aber Vielfalt ist auch schön.
udok schrieb: > Nur für den Anwender und die Open Source Szene ist das > die übliche Katastrophe! Sehe ich nicht so. Aber das ist dann halt meine Meinung. :) > Anstatt die Energie auf ein CAD zu bündeln, und > dieses zur Perfektion zu bringen, > bleiben viele Baustellen übrig, die meistens > irgendwann nicht mehr gewartet werden. Wenn du merkst, dass du das eine CAD halt nicht zur „Perfektion“ bringen kannst, weil es designmäßig ziemlich verbaut ist, dann finde ich es völlig legitim, an dieser Stelle einen Schnitt zu machen und was Neues anzufangen. Gerade in der Opensource-Szene passiert das immer wieder, und keineswegs deshalb notwendigerweise zum Schlechten (für den Anwender). Ein Beispiel, welches mir spontan einfiele, wäre hier sendmail. War mal der Mailserver schlechthin, viele seine Features waren damals durchaus wichtig, aber mittlerweile benutzt es fast niemand mehr ob der Alternativen. Es muss aber eben auch niemand mehr zwischen UUCP-, Internet-, DECnet- und was-weiß-ich-Net-Mailadressen irgendwas umschreiben, dafür sind uns andere Dinge wichtig geworden. Horizon bietet halt damit die Chance, dass es tatsächlich auch besser sein könnte als die Dinge, die Lukas sich ja durchaus angesehen hat, bevor er begonnen hat. Wenn es nicht besser wird, war's halt ein Versuch, wenn's besser wird, haben am Ende alle gewonnen.
Jörg W. schrieb: > Wenn du merkst, dass du das eine CAD halt nicht > zur „Perfektion“ bringen kannst, weil es designmäßig > ziemlich verbaut ist, dann finde ich es völlig > legitim, an dieser Stelle einen Schnitt zu machen > und was Neues anzufangen. Ja -- aber Dein Irrtum liegt in der Voraussetzung. "Das eine CAD" enthält mindestens einen Schaltplan- editor, eine Bauteildatenbank und einen Layout- editor. Es ist nicht sinnvoll, wenn jedes neue Projekt versucht, ALLE diese Komponenten neu aus dem Boden zu stampfen. Was würdest Du denn sagen, wenn IDE, Compiler, Linker, Assembler und Versionsverwaltung so miteinander verflochten wären, dass Du alles wechseln musst, wenn Du eigentlich nur ein anderes VCS benutzen willst? > Horizon bietet halt damit die Chance, dass es > tatsächlich auch besser sein könnte als die Dinge, > die Lukas sich ja durchaus angesehen hat, bevor > er begonnen hat. Wenn es nicht besser wird, war's > halt ein Versuch, wenn's besser wird, haben am Ende > alle gewonnen. Nein! Erfahrungsgemäß ist die Wahrheit VIEL ärgerlicher: Es wird einige Dinge geben, die in horizon tatsächlich SO viel besser sind, dass man eine bestimmte Komponente von horizon wirklich benutzen will. Aber da man diese eine Komponente nicht mit anderen Komponenten aus anderen Projekten kombinieren können wird, bleibt alles beim Alten: Wahl zwischen Pest und Cholera.
Egon D. schrieb: > Es ist nicht sinnvoll, wenn jedes neue Projekt versucht, ALLE diese > Komponenten neu aus dem Boden zu stampfen. Doch, aus meiner Sicht schon. Denn zumindest bei Kicad (und auch gEDA) sind diese Komponenten jeweils ziemlich getrennt voneinander entstanden und daher nur mäßig gut in ihrem Zusammenspiel. Wenn ein „integriertes Design“ es mal schafft, das besser zu bekommen, dann bin ich da vollauf mit Lukas. (Ob Eagle oder Altium oder BAE oder Target oder … das besser machen, hülfe uns ohnehin nicht viel, da nicht Opensource.) > Erfahrungsgemäß ist die Wahrheit VIEL ärgerlicher: Wir haben aber da völlig entgegengesetzte Standpunkte: für mich (und, wie ich das sehe, auch für Lukas) sind die Komponenten eines EDA-Systems eben keine eigenständigen Teile, die man völlig voneinander unabhängig bemuddeln oder gegenseitig austauschen kann. Derartige Ansätze gab's ja bereits in der Vergangenheit, sie waren eher nicht erfolgreich (gEDA) oder „so einigermaßen brauchbar“ (Kicad, aber eigentlich auch erst nach einem Jahrzehnt oder mehr an diesem Punkt angekommen, nachdem CERN da mitmischte).
Jörg W. schrieb: > Egon D. schrieb: >> Es ist nicht sinnvoll, wenn jedes neue Projekt >> versucht, ALLE diese Komponenten neu aus dem >> Boden zu stampfen. > > Doch, aus meiner Sicht schon. Denn zumindest bei > Kicad (und auch gEDA) sind diese Komponenten > jeweils ziemlich getrennt voneinander entstanden > und daher nur mäßig gut in ihrem Zusammenspiel. Da besteht aus meiner Sicht kein (zwingender) Zusammenhang. Die Frage ist aus meiner Sicht nicht, ob die Komponenten getrennt oder zusammen entstehen, sondern ob es eine tragfähige Vorstellung von der Struktur des Gesamtsystems gibt oder nicht. > Wir haben aber da völlig entgegengesetzte > Standpunkte: für mich (und, wie ich das sehe, auch > für Lukas) sind die Komponenten eines EDA-Systems > eben keine eigenständigen Teile, die man völlig > voneinander unabhängig bemuddeln oder gegenseitig > austauschen kann. Derartige Ansätze gab's ja > bereits in der Vergangenheit, Hier muss ich dann doch schmunzeln. Das liest sich wie eine Laudatio zum 100. Todestag, aber ganz so weit sind wir ja dann doch noch nicht. > sie waren eher nicht erfolgreich (gEDA) oder „so > einigermaßen brauchbar“ (Kicad, aber eigentlich > auch erst nach einem Jahrzehnt oder mehr an diesem > Punkt angekommen, nachdem CERN da mitmischte). Ich denke, Du verwechselst hier Korrelation mit Kausalität. Der modulare Ansatz beider Projekte und der begrenzte Erfolg beider Projekte lässt nicht den Rückschluss zu, beide Projekte hätten WEGEN des modularen Ansatzes nur begrenzten Erfolg. Darüberhinaus denke ich, dass die Hemmnisse in beiden Projekten jeweils andere sind. gEDA hatte nach meinem Gefühl durchaus eine nennens- werte Zeit wachsender Popularität; das lange Siechtum der letzten Jahre ist wohl auf ein sehr suboptimales Projektmanagement zurückzuführen. Dem Boss waren wohl untergeordnete technische Details wichtiger als tragfähige Kompromisse mit seinen Entwicklern. Kicad andererseits war ja wohl lange Zeit eine one-man-show. Ich kann daher den Gedanken nicht ganz unterdrücken, W.S. könnte Recht haben mit seiner Behauptung, man laboriere jetzt an der Beseitigung der Mängel, die durch die schon vor Jahren getroffenen suboptimalen Entscheidungen hervorgerufen wurden.
Egon D. schrieb: > Der modulare Ansatz beider Projekte und der begrenzte > Erfolg beider Projekte lässt nicht den Rückschluss zu, > beide Projekte hätten WEGEN des modularen Ansatzes nur > begrenzten Erfolg. Bei gEDA sehe ich das schon, das war immer nur eher eine Art Projektidee, die als Konglomerat Dinge versucht hat zu vereinen, die für sich bereits eigenständige Projekte waren. PCB kenne ich jedenfalls schon ziemlich lange, gSchem wurde dann erst später „dazu gestrickt“. gerbv ist relativ eigenständig, aber das ist eingedenk seiner Schnittstelle (Gerber-Daten) nicht weiter verwunderlich, denn die Gerberdaten sind nunmal die Schnittstelle zum Fertiger und als solche zumindest einigermaßen normiert. > Kicad andererseits war ja wohl lange Zeit eine > one-man-show. Ich kann daher den Gedanken nicht ganz > unterdrücken, W.S. könnte Recht haben mit seiner > Behauptung, man laboriere jetzt an der Beseitigung > der Mängel, Das kann durchaus sein, allerdings sind die „Mängel“, die W.S. bei Horizon sieht, einfach nur Designentscheidungen, die ihm nicht so sehr gefallen, wie eben bestimmte Mindestvoraussetzungen an die Hardware. Er hat ja nun extra „zum Beweis“ eine Hardware ausgegraben, die er zwar laut eigener Aussage nie ernsthaft für EDA benutzen würde, aber mit der er „belegen“ kann, was von vornherein so postuliert worden war. :) Du wiederum erwartest unbedingt einzeln für sich herauslösbaren und woanders integrierbare Komponenten.
M. W. schrieb: > Ich bin nochmal alle Argumente hier durchgegegangen und finde eigentlich > nur eine Quintessenz daraus: > > Man programmiere sich sein eigenes tool zum Selbstzweck und aus Spass am > Programmieren. Sinn macht es keinen. > > Wer ernsthaft Funktionalität verbessern will, der muss sich in ein > bestehendes Programm einklinken und z.B.: > > * Ein ULP für EAGLE schreiben, welches die Funktionen hat > > * Einen alternativen Editor für KiCAD entwickeln > > * Einen alternativen Autorouter / Placer schreiben > > * Einen Checker zur Einhaltung bestimmter Regeln im Sonderplatinenbau > entwickeln, der übers Design rattert > > * und und und > > Gerade KiCAD bietet uns damit alle Möglichkeiten. Die Sourcen sind mehr > oder weniger frei verfügbar und auch dokumentiert. Dort würde ich > einhaken, weil sich da auch sofort Unterstützer finden, die ein Projekt > weiterziehen, wenn man selber nicht mehr kann. Ich bin nochmal alle Deine Argumente durchgegangen und ziehe folgende Quintessenz daraus: Du bist einer von diesen typisch deutschen Jammerlappen und Nörglern, die jedem auch wirklich alles schlecht reden müssen und so lange herumnölen, bis sie was gefunden haben, über das sie sich aufregen können. Solche Menschen sind die liebsten Nachbarn im Schrebergarten! Kauf Dir verdammt nochmal einen akutellen PC und hör auf herumzujammern! Meine Güte! Jeder billige Aldi-PC erfüllt die Hardwareanforderungen und nur weil Du zu geizig bist, nach mehr als einer Dekade ein paar Euro in die Hand zu nehmen, wird hier ein Shitstorm losgetreten, der jemanden bodenlos kritisiert, der SEINE Zeit in ein Projekt investiert und netterweise hier für andere zur Verfügung stellt! Und wenn Du dafür zu geizig bist, dann bist Du hier sowieso komplett fehl am Platz! Und dann nimm halt KiCAD wenn das alles genauso oder besser kann und heul leise! Und hör auf, diesen Thread damit zuzuspammen! Das will hier keiner lesen und braucht auch keiner!
Martin S. schrieb: > Kauf Dir verdammt nochmal einen akutellen PC und hör auf herumzujammern! Nö, das war/ist eigentlich nicht sein Problem. Das war nur W.S., und auch er hat extra irgendeine hornalte Büchse ausgraben müssen um zu „beweisen“, was von vornherein klar (als Anforderung gesetzt) war. Fazit: wirklich ernsthaft diskutiert hier keiner mehr über die OpenGL-Anforderungen. Anders als vor knapp 2 Jahren, als Lukas den Thread gestartet hat, ist OpenGL 3 mittlerweile ganz offensichtlich bereits so sehr Standard geworden, dass das gar kein ernsthaftes Diskussionsthema mehr ist. Also letztlich genau das, was Lukas auch so als Annahme seinem Projekt vorangestellt hat. M.W. will zwar nicht wirklich was mitmachen, aber er möchte sich halt gern von allen Projekten am besten die Rosinen rauspicken. Daher müssen alle Projekte ihre Datenschnittstellen vereinheitlicht haben, und wenn sie das nicht haben, dann müssen jetzt alle weiteren Opensource-Programmierer daran arbeiten …
M.W. ... W.S. ... Ich sehe da kaum einen Unterschied in der Argumentation.
Martin S. schrieb: > M.W. ... W.S. ... Ich sehe da kaum einen Unterschied in der > Argumentation. W.S. braucht sowieso nichts anderes als seinen Adler, und alles, was nicht ganz genauso funktioniert wie jener, ist bei ihm zum Scheitern verdammt.
Schlage folgendes Argument für jede weitere Diskussion zum Thema OpenGL vor: "Heul doch!" Damit sollten sich weitere uninteressante Befindlichkeiten von Nörglern abdecken lassen. @J: Lieber Politik als das hier, das ist ja nur noch als jämmerlich zu bezeichnen. Gruß, Holm
Alternativ Aufteilen des Threads in * "Horizon - Erfahrungen und Probleme" * "Horizon - Diskussionen" o.ä. Ersterer dann gerne mit etwas nachdrücklicherer Moderation...
Jörg W. schrieb: > Egon D. schrieb: > >> Der modulare Ansatz beider Projekte und der begrenzte >> Erfolg beider Projekte lässt nicht den Rückschluss zu, >> beide Projekte hätten WEGEN des modularen Ansatzes nur >> begrenzten Erfolg. > > Bei gEDA sehe ich das schon, das war immer nur eher > eine Art Projektidee, die als Konglomerat Dinge > versucht hat zu vereinen, die für sich bereits > eigenständige Projekte waren. Das ist ja sachlich richtig -- ich sehe nur nicht, dass das die tiefere URSACHE für den Misserfolg ist. Nach allem, was ich (u.a. von Stefan S. und Tibor Palinkas) gehört habe, ermangelte es dem gEDA-Chef einer gewissen Führungstärke, und ich sehe DAS als das entscheidende Problem an. >> Kicad andererseits war ja wohl lange Zeit eine >> one-man-show. Ich kann daher den Gedanken nicht ganz >> unterdrücken, W.S. könnte Recht haben mit seiner >> Behauptung, man laboriere jetzt an der Beseitigung >> der Mängel, > > Das kann durchaus sein, allerdings sind die „Mängel“, > die W.S. bei Horizon sieht, einfach nur > Designentscheidungen, die ihm nicht so sehr gefallen, > wie eben bestimmte Mindestvoraussetzungen an die > Hardware. Nee, ich denke, wir missverstehen uns. Nach meinem Eindruck kämpfen nicht nur die freien, sondern auch die "kleinen" kommerziellen Systeme (Eagle, Target, ...) damit, ein ziemlich komplexes Problem mit sehr beschränkter Arbeitskraft lösen zu wollen, und der Erfolg ist ja durchaus wechselhaft. Man möge mir also nachsehen, wenn ich einen Analogieschluss ziehe und einer weiteren one-man-show etwas zweifelnd gegenüberstehe. Wenn es draußen donnert, dann gehe ich ja auch einfach von einem Gewitter aus -- und nicht davon, dass jetzt der Messias erscheint...
Jörg W. schrieb: > M.W. will zwar nicht wirklich was mitmachen, aber er > möchte sich halt gern von allen Projekten am besten > die Rosinen rauspicken. Daher müssen alle Projekte > ihre Datenschnittstellen vereinheitlicht haben, [...] Ja und? Das ist genau das, was weltweit viele Millionen Debian- oder Ubuntu-User machen. Ich sehe das Problem nicht.
Egon D. schrieb: > Man möge mir also nachsehen, wenn ich einen Analogieschluss ziehe und > einer weiteren one-man-show etwas zweifelnd gegenüberstehe. War ich anfangs auch. Allerdings überzeugt mich Lukas' Produktivität, die er mit so einer one-man-show an den Tag gelegt hat. Damit ist das Teil aus meiner Sicht zumindest schon jetzt soweit „aus dem Gröbsten heraus“, dass es fortan auch ohne ihn eine Chance hat zu bestehen. Ich hätte nicht gedacht, dass das tatsächlich jemand in annehmbarer Zeit stemmen könnte, aber es scheint zu klappen.
Jörg W. schrieb: > Ich > hätte nicht gedacht, dass das tatsächlich jemand in annehmbarer Zeit > stemmen könnte, aber es scheint zu klappen. Dem kann ich mich nur anschließen, hab wirklich den *allergrößten Respekt* vor Lukas was der da auf die Beine gestellt hat in so kurzer Zeit und mit einer solchen Motivation und Stetigkeit! Da kann man nur den Hut ziehen, müsste ich mir eine dicke Scheibe von abschneiden für meine eigenen Projekte. Ich beobachte das Projekt gerne und sehe ihm beim wachsen zu, wer weiß vielleicht wird horizon eines Tages die PCB Software, mittlerweile ist der Name auch richtig passend ;-) Aber die Designentscheidungen von Lukas teile ich nahezu alle uneingeschränkt, hätte ich genauso gemacht und die typischen Muffel hier die nur zum Nörgeln rauskommen gibt es halt leider in jedem Thread...
Julian W. schrieb: > Dem kann ich mich nur anschließen, hab wirklich den *allergrößten > Respekt* vor Lukas was der da auf die Beine gestellt hat in so kurzer > Zeit und mit einer solchen Motivation und Stetigkeit! Allerdings. Wenn man das sieht, dann fragt man sich schon, warum Eagle in einer vielfachen Zeit nur so wenig erreicht hat.
Martin S. schrieb: > Julian W. schrieb: >> Dem kann ich mich nur anschließen, hab wirklich den *allergrößten >> Respekt* vor Lukas was der da auf die Beine gestellt hat in so kurzer >> Zeit und mit einer solchen Motivation und Stetigkeit! > > Allerdings. Wenn man das sieht, dann fragt man sich schon, warum Eagle > in einer vielfachen Zeit nur so wenig erreicht hat. Man benötigt 10% der Zeit für 90% der Funktionalität ...^^ Sobald mal ein gewisses Feature-Set erreicht ist, verlagert sich der Fokus mehr auf einzelne kleine Erweiterungen, Bug-Fixing. Außerdem macht das Lukas im Prinzip im Alleingang, weshalb er da von niemanden aufgehalten wird.
Mampf F. schrieb: > Außerdem macht das Lukas im Prinzip im Alleingang, weshalb er da von > niemanden aufgehalten wird. Vor allem das ist am Anfang ein ungemeiner Vorteil, sobald 2 oder mehr Leute an einem Projekt beteiligt sind geht ein gigantischer Anteil der Zeit für Planung/Diskussionen/Absprachen/"Streiten" etc. drauf. Lukas kann die Planung etc. alles "im Kopf" machen was wesentlich schneller geht, das sollte man nicht unterschätzen.
... jetzt bitte wieder weiter ..... mit wirklich entscheidenden Fragestellungen und Problemlösungen zum Elektronik-CAD-Programm von Lukas .... Danke
Michel M. schrieb: > mit wirklich entscheidenden Fragestellungen und Problemlösungen zum > Elektronik-CAD-Programm von Lukas Gern. Hab's nun endlich mal geschafft, das Teil hier auf meinem FreeBSD wieder zum Compilieren zu bekommen, und habe mit einem simplen Test, den ich vor geraumer Zeit angefangen habe, weitergemacht. Das "Panning" im 3D-Viewer mit der mittleren Maustaste ist mir ziemlich gewöhnungsbedürftig im Vergleich mit allem anderen, was ich bislang in dieser Richtung gesehen habe (und ich dachte immer, Altiums 3D-View wäre in der Bedienung gewöhnungsbedürftig ;-). Ich schaffe es ganz fix, dass ich dort alles so sehr verschiebe, dass ich am Ende gar nichts mehr sehe … Was ich daher sehr begrüßen würde: oben, neben den Icons mit den verschiedenen Ansichten, noch eins zu haben für "fit all", d.h. das gesamte 3D-Modell wird so geschoben und gezoomt, dass man es in der aktuell gewählten Ansicht bildschirmfüllend sieht. Habe ich auch bei FreeCAD immer mal wieder gebraucht, ist eine bequeme Möglichkeit, "auf Start zurück zu gehen", wenn man sich mal völlig daneben navigiert hat. Außerdem fände ich es sehr praktisch, wenn man für gängige Funktionen nicht erst das jeweilige Element anklicken muss, also bspw. es genügt, die <DEL>-Taste über einem Leiterzug oder einer Verbindung im Schaltplaneditor zu drücken, und der wird gelöscht. (Bei Mehrdeutigkeiten müsste natürlich dann der entsprechende Dialog aufklappen, welches Element jetzt genau gemeint ist.)
Jörg W. schrieb: > Außerdem fände ich es sehr praktisch Öhm :), das nehme ich zurück. Geht jetzt, ich könnte schwören, dass es vorhin nicht ging … vielleicht habe ich mich geirrt.
Jörg W. schrieb
> Außerdem fände ich es sehr praktisch, wenn man für gängige Funktionen
nicht erst das jeweilige Element anklicken muss, also bspw. es genügt,
die <DEL>-Taste über einem Leiterzug oder einer Verbindung im
Schaltplaneditor zu drücken, und der wird gelöscht.
Unter Windows 10 funktioniert das sobald das Objekt links oben angezeigt
wird. Wenn da nichts angezeigt wird, dann ist man noch in irgend einem
anderen Modus. Dann drücke ich einmal ESC und ab da erscheint oben links
die Anzeige des Objekts über dem der Cursor steht. Ab da funktioniert
dann auch DEL(ENTF) beliebig oft.
Yup, hatte ich dann auch bemerkt. Danke für den Hinweis mit dem "heads-up display" links oben, da sollte ich wirklich häufiger mal einen Blick drauf werfen. Was mir dabei auffällt: Horizon fühlt sich sehr flink an, verglichen mit Kicad auf gleicher Hardware oder Altium auf vergleichbarer Hardware.
Angehängte Dateien:
-
poolmanager.png
140 KB
Eine Frage zum Poolmanager: Die markierte Spalte ganz rechts kann ich in der Breite nicht ändern. Damit ist das, was dort angezeigt wird, eigentlich ziemlich nutzlos (außer, dass man es mit der rechten Maustaste kopieren kann). Ist das so beabsichtigt? Die "Manufacturer"-Spalte belegt ziemlich viel Platz für eine Information, die man m.M.n. oft gar nicht braucht (generische Bauteile). Wäre gut, wenn man sie einfach kleiner ziehen könnte, um mehr Platz für die anderen Spalten zu haben.
Weil ich gerade drüber stolpere: im Package-Generator wäre es cool, wenn beim Duplizieren eines Pads, dessen Name auf eine Zahl endet, diese Zahl mit jeder Kopie automatisch eins hochgezählt werden würde. Es dürfte in den allermeisten Fällen die gewünschte Aktion sein, nicht das gleiche Pad nochmal zu erzeugen. So, wie es jetzt ist, bekommen die Duplikate alle eine fette Warnung, und man muss danach jedes einzeln editieren.
Angehängte Dateien:
-
1920-100.jpg
280 KB -
1980-125.PNG
130 KB
Jörg W. schrieb: > Eine Frage zum Poolmanager: > > Die markierte Spalte ganz rechts kann ich in der Breite nicht ändern. > Damit ist das, was dort angezeigt wird, eigentlich ziemlich nutzlos > (außer, dass man es mit der rechten Maustaste kopieren kann). Mit einer HD-Auflösung von 1920 Breite bekommt man alles angezeigt. Dabei wäre zu erwähnen, dass die Schriften/Felder größer werden, wenn man in WIN 125% eingestellt hat. > Ist das so beabsichtigt? > > Die "Manufacturer"-Spalte belegt ziemlich viel Platz für eine > Information, die man m.M.n. oft gar nicht braucht (generische Bauteile). > Wäre gut, wenn man sie einfach kleiner ziehen könnte, um mehr Platz für > die anderen Spalten zu haben. Also etwas kleiner hättest du die "Manufacturer"-Spalte machen können. Dazu "Descriptions maximal nach links schieben. Man sollte die Verwendung einer HD-Auflösung oder höher für horizon empfehlen.
Noch was, was ich cool fände (und bspw. auch bei Kicad schon vermisst habe): wenn man eine Reihe gleichartiger Objekte ausgewählt hat (hier: mehrere Linien eines Rechtecks), dann wäre es gut, wenn man diese danach nicht nur einzeln jedes für sich editieren könnte, sondern die gemeinsamen Eigenschaften auch „im Block“. Bei den Linien hier war es gerade die Breite, die ich bei allen ändern wollte, aber kann mir auch vorstellen, dass man auf diese Weise bspw. den Layer ändern könnte.
Helmut S. schrieb: > Mit einer HD-Auflösung von 1920 Breite Habe ich. > bekommt man alles angezeigt. Jetzt habe ich auch die Ecke gefunden, an der ich ziehen muss, damit ich die Tabelle insgesamt breiter bekomme. Das ist natürlich nicht Lukas' Schuld, sondern eher ein Problem im Handling von Gtk3 (dessen Default-Skin mir absolut nicht gefällt, aber irgendwie schaffe ich das auch nicht, dieses abzuändern, fehlt mir wohl irgendein dbus oder was auch immer Dämon). > Also etwas kleiner hättest du die "Manufacturer"-Spalte machen können. Nö, kleiner als im Screenshot gezeigt, habe ich sie nicht bekommen. Von mir aus sollte man die aber gern bis zur Unkenntlichkeit zusammenschieben können (wie bei "Path" oben), wenn man sie nicht braucht. > Man sollte die Verwendung einer HD-Auflösung oder höher für horizon > empfehlen. Naja, man muss es schon auch mal auf'm Laptop laufen lassen können mit eingebautem Display, auch wenn das vielleicht nicht die reguläre Arbeitsumgebung ist. Wie gesagt, wie ich Gtk3 zu einem anderen Layout überrede, ist hier noch 'ne andere Baustelle (und nicht Lukas' Problem), aber sowas wie die minimale Spaltenbreite dürfte ja doch in Horizon festgeschrieben sein.
Holm T. schrieb: > /usr/ports/cad/horizon-devel?? Nö, git clone. Hab' gerade keine freien CPU-Zyklen, da was in Richtung Port zu unternehmen.
Jörg W. schrieb: >> Also etwas kleiner hättest du die "Manufacturer"-Spalte machen können. > > Nö, kleiner als im Screenshot gezeigt, habe ich sie nicht bekommen.
1 | diff --git a/src/widgets/pool_browser_package.cpp b/src/widgets/pool_browser_package.cpp
|
2 | index ec7e332..14b1a35 100644
|
3 | --- a/src/widgets/pool_browser_package.cpp
|
4 | +++ b/src/widgets/pool_browser_package.cpp
|
5 | @@ -29,7 +29,7 @@ void PoolBrowserPackage::create_columns()
|
6 | {
|
7 | auto col = append_column("Manufacturer", list_columns.manufacturer, Pango::ELLIPSIZE_END);
|
8 | col->set_resizable(true); |
9 | - col->set_min_width(200);
|
10 | + col->set_min_width(30);
|
11 | } |
12 | treeview->append_column("Pads", list_columns.n_pads);
|
13 | {
|
Das wäre mein Vorschlag. ;) @Lukas: Willst du solche Dinge eigentlich gern hier haben oder als pull request auf Github?
Part Wizard, Funktion eines Pins: "unconnected" fehlt dort, für IC-Pins, die nicht belegt sind.
@Jörg, Lukas liest hier meinem Gefühl nach vielleicht einmal am Tag. Mach lieber gleich einen request in Github.
Genügt ja auch, ich erwarte keine 5minütigen Reaktionszeiten. ;-) War eher eine Frage, ob er solche Einzeiler auch gern als pull request haben will oder nicht.
Jörg W. schrieb: > Noch was, was ich cool fände (und bspw. auch bei Kicad schon vermisst > habe): wenn man eine Reihe gleichartiger Objekte ausgewählt hat (hier: > mehrere Linien eines Rechtecks), dann wäre es gut, wenn man diese danach > nicht nur einzeln jedes für sich editieren könnte, sondern die > gemeinsamen Eigenschaften auch „im Block“. Bei den Linien hier war es > gerade die Breite, die ich bei allen ändern wollte, aber kann mir auch > vorstellen, dass man auf diese Weise bspw. den Layer ändern könnte. Definitiv! Das regt mich im Altium auch immer extrem auf, dass das nicht so ohne weiteres geht (oder gar nicht??). Es ist ja technisch problemlos umsetzbar. Man graut halt die Elemente aus, die nicht gemeinsam sind oder lässt sie sogar aktiv, dann kann man die Eigenschafte für Objekte setzen, die diese haben. Kurzer Hinweis: "Die Eigenschaftsänderung wirkt sich nicht auf alle Objekte aus. Fortsetzen?" und man könnte sich zukünftig sehr viel nervige Klick-Arbeit sparen.
Martin S. schrieb: > Das regt mich im Altium auch immer extrem auf, dass das nicht so ohne > weiteres geht (oder gar nicht??). in Altium geht das ohne Probleme...
Martin S. schrieb: > Jörg W. schrieb: >> Noch was, was ich cool fände (und bspw. auch bei Kicad schon vermisst >> habe): wenn man eine Reihe gleichartiger Objekte ausgewählt hat (hier: >> mehrere Linien eines Rechtecks), dann wäre es gut, wenn man diese danach >> nicht nur einzeln jedes für sich editieren könnte, sondern die >> gemeinsamen Eigenschaften auch „im Block“. Bei den Linien hier war es >> gerade die Breite, die ich bei allen ändern wollte, aber kann mir auch >> vorstellen, dass man auf diese Weise bspw. den Layer ändern könnte. > > Definitiv! Das geht zumindest bei Durchkontaktierungen ... Kann man markieren, E drücken und für alle markierten zB der Drill einstellen. Das geht auch bei Leiterbahnen - inklusive Layer-wechsel. Ihr solltet mal das Manual lesen ;-) SCNR Natürlich dürft ihr nicht den veralteten legacy-Modus verwenden. Aber stimmt, für Linienbreiten im zB cutoff layer wäre das ein gutes Feature.
Re 3D Vorschau: Ehrlich gesagt ist das Pan-Verhalten (insb. die Konstanten in der Formel) das Ergebnis von Trial-And-Error bis es sich halbwegs ordentlich anfühlte: https://github.com/carrotIndustries/horizon/blob/master/src/canvas3d/canvas3d.cpp#L80 Knopf zum Zurücksetzen der Ansicht sollte einfach machbar sein. Zur Auswahl von Dingen: Es gibt den "Hover" und den "Normalen" Modus. Im Hover-Modus wird das Objekt mit der kleinsten Bounding-Box unter dem Mauszeiger ausgewählt. Wenn man dann ein Tool startet, wird das gerade ausgewählte verwendet - eben um einfach mit der Maus drauf zeigen und DEL drücken zu können. Dieses Verhalten ist Primär aus dem entstanden, wie es mir in KiCad nicht gefallen hat: 1. man weiß nicht, was man gerade ausgewählt hat, Tool starten ist dann Glücksspiel 2. Die ständigen "Clarify Selection" haben mich genervt Mit einmal klicken wird die Auswahl dann fixiert und man ist im normalen Modus. Wenn man jetzt nochmal klickt, kommt das "Clarify Selection"-Menü, allerdings ohne komischen unnützen erstem Menüeintrag. Mit Esc kommt man wieder zurück in den Hover-Modus. Mehrere Dinge auf einmal ändern: Das war eines meiner wichtigen Ziele für das Projekt und geht auch, nur ist die UI dafür wohl nicht unmittelbar ersichtlich geraten: Wenn man z.B. 4 Linien ausgewählt hat, steht rechts im Property-Editor bei den Linien 1/4, mit den links/rechts-Knöpfen kann man auswählen welche davon man nun bearbeitet. Ein Klick auf den Haken an der Property appliziert den Wert der gerade sichtbaren auf alle ausgewählten. Andere Implementierungen von solchen Editoren zeigen bei der Auswahl mehrerer Objekte dann sowas wie ???, das hat mir noch nie so recht gefallen.
Martin S. schrieb: > gjhvf schrieb: >> in Altium geht das ohne Probleme... > > Wie? wenn Du mehrere ähnliche Objekte markiert hast (z.B. über find similar objects) kannst Du in den Properties fröhlich ändern. Diese Änderungen werden für alle markierten Objekte übernommen.
Lukas K. schrieb: > Mehrere Dinge auf einmal ändern: Das war eines meiner wichtigen Ziele > für das Projekt und geht auch, nur ist die UI dafür wohl nicht > unmittelbar ersichtlich geraten: OK, schau ich mir heute abend mal an. Bei Schließen des Pool-Managers nach dem Speichern meines neu angelegten Parts habe dann einen bus error geschossen. Stacktrace:
1 | $ gdb801 horizon-eda horizon-eda.core |
2 | GNU gdb (GDB) 8.0.1 [GDB v8.0.1 for FreeBSD] |
3 | Copyright (C) 2017 Free Software Foundation, Inc. |
4 | License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> |
5 | This is free software: you are free to change and redistribute it. |
6 | There is NO WARRANTY, to the extent permitted by law. Type "show copying" |
7 | and "show warranty" for details. |
8 | This GDB was configured as "x86_64-portbld-freebsd10.4". |
9 | Type "show configuration" for configuration details. |
10 | For bug reporting instructions, please see: |
11 | <http://www.gnu.org/software/gdb/bugs/>. |
12 | Find the GDB manual and other documentation resources online at: |
13 | <http://www.gnu.org/software/gdb/documentation/>. |
14 | For help, type "help". |
15 | Type "apropos word" to search for commands related to "word"... |
16 | Reading symbols from horizon-eda...done. |
17 | [New LWP 101804] |
18 | [New LWP 100855] |
19 | [New LWP 100225] |
20 | [New LWP 100127] |
21 | [New LWP 102699] |
22 | [New LWP 102028] |
23 | [New LWP 102027] |
24 | [New LWP 102017] |
25 | [New LWP 102000] |
26 | |
27 | warning: Unexpected size of section `.reg-xstate/101804' in core file. |
28 | Core was generated by `./horizon-eda'. |
29 | Program terminated with signal SIGBUS, Bus error. |
30 | |
31 | warning: Unexpected size of section `.reg-xstate/101804' in core file. |
32 | #0 0x000000000044df95 in horizon::uuid_ptr<horizon::Package const>::operator-> (this=<optimized out>) at src/util/uuid_ptr.hpp:41 |
33 | 41 assert(ptr->get_uuid() == uuid); |
34 | [Current thread is 1 (LWP 101804)] |
35 | (gdb) bt |
36 | #0 0x000000000044df95 in horizon::uuid_ptr<horizon::Package const>::operator-> (this=<optimized out>) at src/util/uuid_ptr.hpp:41 |
37 | #1 horizon::Part::serialize (this=0x812600920) at src/pool/part.cpp:200 |
38 | #2 0x00000000005a9094 in horizon::PartWizard::finish (this=0x812600800) at src/pool-prj-mgr/pool-mgr/part_wizard/part_wizard.cpp:354 |
39 | #3 0x00000000005a4ef6 in horizon::PartWizard::handle_finish (this=0x812600800) at src/pool-prj-mgr/pool-mgr/part_wizard/part_wizard.cpp:252 |
40 | #4 0x0000000802b43e90 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from /usr/local/lib/libglibmm-2.4.so.1 |
41 | #5 0x0000000804f079a2 in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 |
42 | #6 0x0000000804f1ce94 in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
43 | #7 0x0000000804f1d918 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
44 | #8 0x0000000804f1e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
45 | #9 0x0000000802f3f47b in ?? () from /usr/local/lib/libgtk-3.so.0 |
46 | #10 0x0000000801b8a124 in Gtk::Button_Class::released_callback(_GtkButton*) () from /usr/local/lib/libgtkmm-3.0.so.1 |
47 | #11 0x0000000804f07bfa in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
48 | #12 0x0000000804f1d5f6 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
49 | #13 0x0000000804f1e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
50 | #14 0x0000000802f3df76 in ?? () from /usr/local/lib/libgtk-3.so.0 |
51 | #15 0x000000080a27236c in ffi_call_unix64 () from /usr/local/lib/libffi.so.6 |
52 | #16 0x000000080a271c3b in ffi_call () from /usr/local/lib/libffi.so.6 |
53 | #17 0x0000000804f091dc in g_cclosure_marshal_generic_va () from /usr/local/lib/libgobject-2.0.so.0 |
54 | #18 0x0000000804f07bfa in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
55 | #19 0x0000000804f1d5f6 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
56 | #20 0x0000000804f1e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
57 | #21 0x0000000802ffba12 in ?? () from /usr/local/lib/libgtk-3.so.0 |
58 | #22 0x0000000804f0afeb in g_cclosure_marshal_VOID__BOXEDv () from /usr/local/lib/libgobject-2.0.so.0 |
59 | #23 0x0000000804f07bfa in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
60 | #24 0x0000000804f1d5f6 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
61 | #25 0x0000000804f1e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
62 | #26 0x0000000802ff87ee in ?? () from /usr/local/lib/libgtk-3.so.0 |
63 | #27 0x0000000802ff9c96 in ?? () from /usr/local/lib/libgtk-3.so.0 |
64 | #28 0x0000000802ffd283 in ?? () from /usr/local/lib/libgtk-3.so.0 |
65 | #29 0x0000000802fc875b in gtk_event_controller_handle_event () from /usr/local/lib/libgtk-3.so.0 |
66 | #30 0x000000080319b58b in ?? () from /usr/local/lib/libgtk-3.so.0 |
67 | #31 0x0000000801c61373 in Gtk::Widget::on_button_release_event(_GdkEventButton*) () from /usr/local/lib/libgtkmm-3.0.so.1 |
68 | #32 0x0000000801c5a3fd in Gtk::Widget_Class::button_release_event_callback(_GtkWidget*, _GdkEventButton*) () from /usr/local/lib/libgtkmm-3.0.so.1 |
69 | #33 0x00000008030474d9 in ?? () from /usr/local/lib/libgtk-3.so.0 |
70 | #34 0x0000000804f07bfa in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
71 | #35 0x0000000804f1d5f6 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
72 | #36 0x0000000804f1e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
73 | #37 0x000000080319b1f8 in ?? () from /usr/local/lib/libgtk-3.so.0 |
74 | #38 0x00000008030460ac in ?? () from /usr/local/lib/libgtk-3.so.0 |
75 | #39 0x00000008030455f8 in gtk_main_do_event () from /usr/local/lib/libgtk-3.so.0 |
76 | #40 0x00000008036f5841 in ?? () from /usr/local/lib/libgdk-3.so.0 |
77 | #41 0x000000080372ab97 in ?? () from /usr/local/lib/libgdk-3.so.0 |
78 | #42 0x0000000805191878 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0 |
79 | #43 0x0000000805191bb3 in ?? () from /usr/local/lib/libglib-2.0.so.0 |
80 | #44 0x0000000805191c44 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.0 |
81 | #45 0x00000008042b33dd in g_application_run () from /usr/local/lib/libgio-2.0.so.0 |
82 | #46 0x000000000054c941 in main (argc=1, argv=0x7fffffffe528) at src/pool-prj-mgr/pool-prj-mgr-main.cpp:15 |
Hat ja schon fast was von den typischen Java-Stacktraces. ;-) ptr und uuid sind leider "value optimized out". Ein Level darüber kann ich mir das package ansehen:
1 | (gdb) p package |
2 | $2 = {ptr = 0x8280da330, uuid = {uu = "V\355QM;\236M<\223\320\350\275b\020\300\226"}}
|
Jörg W. schrieb: > Holm T. schrieb: >> /usr/ports/cad/horizon-devel?? > > Nö, git clone. > > Hab' gerade keine freien CPU-Zyklen, da was in Richtung Port zu > unternehmen. Achso, falls du es selbst bauen willst: Die Voraussetzungen hat Lukas irgendwo bei sich auf der Seite beschrieben, die musst du halt mit der Hand installieren (gtkmm30 zum Beispiel). Danach tut's ein einfaches
1 | gmake CXX=clang++60 |
Am besten noch ein -j<Anzahl deiner CPU-Kerne> dranhängen. :) Dauert sonst ein Weilchen.
Der Crash ist repariert, das Pasten von Pads auch. Die anderen Dinge kommen zeitnah.
Angehängte Dateien:
-
pool.png
140 KB -
selectsymbol.png
11 KB
Cool! Habe nun versucht, das Teil zu Ende zu bauen, bei dem es gestern am Ende abgestürzt ist. Sieht auf den ersten Blick komplett aus, im Partbrowser sehe ich keinen Unterschied zwischen meinem A210E und den anderen Teilen. Wenn ich es aber platzieren will, bekomme ich eine Aufforderung, ein Symbol zu wählen mit einer leeren Auswahlbox.
Lukas K. schrieb: > Mehrere Dinge auf einmal ändern: Das war eines meiner wichtigen Ziele > für das Projekt und geht auch, nur ist die UI dafür wohl nicht > unmittelbar ersichtlich geraten: Ja, da würde ich zustimmen. ;-) Der Haken sieht halt aus wie eine Checkbox, nur dass sich an dieser nichts ändert, wenn man draufdrückt … Platz ist ja eigentlich, was spräche dagegen, statt des Hakens ein "ALL" reinzuschreiben? Alternativ, das Ding wirklich als Checkbox implementieren, und man kann damit einschalten, ob die späteren Änderungen auf alle ausgewählten Objekte angewendet werden oder nur das aktuelle. Fände ich intuitiver. Selbst mit deiner Beschreibung hat es bei mir eine Weile gedauert, bis ich es verstanden habe, wie's funktioniert.
Jörg W. schrieb: > Wenn ich es aber platzieren will, bekomme ich eine Aufforderung, ein > Symbol zu wählen mit einer leeren Auswahlbox. Hm, wie sieht's denn im Pool Cache im Projekt aus? Wenn da noch was altes im Cache drin ist, dann könnte das das Verhalten erklären.
Wie ist das, Füllflächen gibt's noch nicht, oder habe ich sie nur nicht gefunden? Die vielen Tastenkürzel sind nicht so einfach im Kopf zu behalten. Jedesmal auf die Hilfe zu gehen, ist auch nervig. Irgendeine Form von Menü fände ich sinnvoll, mit der man alternativ zum jeweiligen Tastenkürzel an die entsprechende Funktion gelangen kann. Ob das nun irgendwie mit der rechten Maustaste oder eine Menüleiste ist, wäre mir egal. Auf diese Weise wird sich bei der täglichen Arbeit dann irgendwann ein Gleichgewicht einstellen zwischen den Funktionen, die man häufig braucht und per Tastaturkürzel aktiviert und den Sachen, die man nur einmal im Monat braucht und dann auch gut und gern aus einem Menü rauspopeln kann.
Lukas K. schrieb: > Jörg W. schrieb: >> Wenn ich es aber platzieren will, bekomme ich eine Aufforderung, ein >> Symbol zu wählen mit einer leeren Auswahlbox. > > Hm, wie sieht's denn im Pool Cache im Projekt aus? Wenn da noch was > altes im Cache drin ist, dann könnte das das Verhalten erklären. OK, das war's wohl. Habe ein neues Projekt begonnen, da klappt es.
Mit clang++60 bekomme ich von derartigen Meldungen übrigens ziemlich viele:
1 | In file included from src/pool/part.cpp:1: |
2 | In file included from src/pool/part.hpp:3: |
3 | In file included from src/pool/package.hpp:13: |
4 | In file included from src/package/package_rules.hpp:3: |
5 | src/package/rule_package_checks.hpp:12:17: warning: 'get_brief' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] |
6 | std::string get_brief(const class Block *block = nullptr) const; |
7 | ^ |
8 | src/rules/rule.hpp:38:25: note: overridden virtual function is here |
9 | virtual std::string get_brief(const class Block *block = nullptr) const = 0; |
10 | ^ |
11 | In file included from src/pool/part.cpp:1: |
12 | In file included from src/pool/part.hpp:3: |
13 | src/pool/package.hpp:76:10: warning: 'get_uuid' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] |
14 | UUID get_uuid() const; |
15 | ^ |
16 | src/util/uuid_provider.hpp:11:18: note: overridden virtual function is here |
17 | virtual UUID get_uuid() const = 0; |
18 | ^ |
Jörg W. schrieb: > Wie ist das, Füllflächen gibt's noch nicht, oder habe ich sie nur nicht > gefunden? Das ist ein zweistufiger Prozess: 1. Polygon in der gewünschten Lage zeichnen: Draw Polygon / Draw Polygon Rectangle 2. Das Polyon zu einer Fläche machen und dabei das Netz auswählen: Add Plane Jörg W. schrieb: > Die vielen Tastenkürzel sind nicht so einfach im Kopf zu behalten. > Jedesmal auf die Hilfe zu gehen, ist auch nervig. Irgendeine Form von > Menü fände ich sinnvoll, Menüs gibt es zweierlei: 1. Rechte Maustaste: Aktionen nur für das ausgewählte Objekt 2. Leertaste: Durchsuchbares Menü mit Aktionen für das ausgewählte Objekt sowie globalen Aktionen. Jörg W. schrieb: > Mit clang++60 bekomme ich von derartigen Meldungen übrigens ziemlich > viele: Das hier ist mein erstes wirkliches C++-Projekt, ganz am Anfang wusste ich von override noch nichts...
Lukas K. schrieb: > Das ist ein zweistufiger Prozess: > > 1. Polygon in der gewünschten Lage zeichnen: Draw Polygon / Draw Polygon > Rectangle Da war ich schon. :) > 2. Das Polyon zu einer Fläche machen und dabei das Netz auswählen: Add > Plane OK, schau ich mir morgen (heute :) an. > 2. Leertaste: Durchsuchbares Menü mit Aktionen für das ausgewählte > Objekt sowie globalen Aktionen. OK, auch das schau ich mir an. > Jörg W. schrieb: >> Mit clang++60 bekomme ich von derartigen Meldungen übrigens ziemlich >> viele: > > Das hier ist mein erstes wirkliches C++-Projekt :-)) Dafür ist es beeindruckend. Habe noch einen weiteren segfault:
1 | Program terminated with signal SIGSEGV, Segmentation fault. |
2 | |
3 | warning: Unexpected size of section `.reg-xstate/102223' in core file. |
4 | #0 p2t::Triangle::EdgeIndex (this=0x0, p1=0x815d57668, p2=0x815d57640) at 3rd_party/poly2tri/common/shapes.cpp:168 |
5 | 168 if (points_[0] == p1) {
|
6 | [Current thread is 1 (LWP 102223)] |
7 | (gdb) bt |
8 | #0 p2t::Triangle::EdgeIndex (this=0x0, p1=0x815d57668, p2=0x815d57640) at 3rd_party/poly2tri/common/shapes.cpp:168 |
9 | #1 0x0000000000668103 in p2t::Sweep::IsEdgeSideOfTriangle (triangle=..., ep=..., eq=..., this=<optimized out>) at 3rd_party/poly2tri/sweep/sweep.cpp:164 |
10 | #2 p2t::Sweep::EdgeEvent (this=0x829dba8c0, tcx=..., ep=..., eq=..., triangle=0x0, point=...) at 3rd_party/poly2tri/sweep/sweep.cpp:109 |
11 | #3 0x00000000006678b2 in p2t::Sweep::SweepPoints (this=0x829dba8c0, tcx=...) at 3rd_party/poly2tri/sweep/sweep.cpp:56 |
12 | #4 0x000000000066777e in p2t::Sweep::Triangulate (this=0x829dba8c0, tcx=...) at 3rd_party/poly2tri/sweep/sweep.cpp:45 |
13 | #5 0x00000000007fdb66 in horizon::Canvas3D::polynode_to_tris (this=0x823c6c800, node=<optimized out>, layer=<optimized out>) |
14 | at src/canvas3d/canvas3d.cpp:276 |
15 | #6 0x00000000007ffcde in horizon::Canvas3D::prepare_layer (this=<optimized out>, layer=100) at src/canvas3d/canvas3d.cpp:484 |
16 | #7 0x00000000007fef30 in horizon::Canvas3D::prepare (this=0x823c6c800) at src/canvas3d/canvas3d.cpp:356 |
17 | #8 0x00000000007f1cd9 in horizon::View3DWindow::update (this=0x823c96900, clear=false) at src/imp/3d_view.cpp:236 |
18 | #9 0x000000000061cc18 in horizon::ImpBoard::construct()::$_5::operator()() const (this=<optimized out>) at src/imp/imp_board.cpp:232 |
19 | #10 sigc::adaptor_functor<horizon::ImpBoard::construct()::$_5>::operator()() const (this=<optimized out>) |
20 | at /usr/local/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256 |
21 | #11 sigc::internal::slot_call0<horizon::ImpBoard::construct()::$_5, void>::call_it(sigc::internal::slot_rep*) (rep=<optimized out>) |
22 | at /usr/local/include/sigc++-2.0/sigc++/functors/slot.h:114 |
23 | #12 0x0000000805f43e90 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from /usr/local/lib/libglibmm-2.4.so.1 |
24 | #13 0x00000008087279a2 in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 |
25 | #14 0x000000080873ce94 in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
26 | #15 0x000000080873d918 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
27 | #16 0x000000080873e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
28 | #17 0x000000080633f47b in ?? () from /usr/local/lib/libgtk-3.so.0 |
29 | #18 0x0000000808727bfa in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
30 | #19 0x000000080873d5f6 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
31 | #20 0x000000080873e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
32 | #21 0x000000080633df76 in ?? () from /usr/local/lib/libgtk-3.so.0 |
33 | #22 0x00000008113b936c in ffi_call_unix64 () from /usr/local/lib/libffi.so.6 |
34 | #23 0x00000008113b8c3b in ffi_call () from /usr/local/lib/libffi.so.6 |
35 | #24 0x00000008087291dc in g_cclosure_marshal_generic_va () from /usr/local/lib/libgobject-2.0.so.0 |
36 | #25 0x0000000808727bfa in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
37 | #26 0x000000080873d5f6 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
38 | #27 0x000000080873e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
39 | #28 0x00000008063fba12 in ?? () from /usr/local/lib/libgtk-3.so.0 |
40 | #29 0x000000080872afeb in g_cclosure_marshal_VOID__BOXEDv () from /usr/local/lib/libgobject-2.0.so.0 |
41 | #30 0x0000000808727bfa in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
42 | #31 0x000000080873d5f6 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
43 | #32 0x000000080873e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
44 | #33 0x00000008063f87ee in ?? () from /usr/local/lib/libgtk-3.so.0 |
45 | ---Type <return> to continue, or q <return> to quit---q |
46 | Quit |
47 | (gdb) p points_ |
48 | Cannot access memory at address 0x8 |
49 | (gdb) l |
50 | 163 return -1; |
51 | 164 } |
52 | 165 |
53 | 166 int Triangle::EdgeIndex(const Point* p1, const Point* p2) |
54 | 167 {
|
55 | 168 if (points_[0] == p1) {
|
56 | 169 if (points_[1] == p2) {
|
57 | 170 return 2; |
58 | 171 } else if (points_[2] == p2) {
|
59 | 172 return 1; |
60 | (gdb) up |
61 | #1 0x0000000000668103 in p2t::Sweep::IsEdgeSideOfTriangle (triangle=..., ep=..., eq=..., this=<optimized out>) at 3rd_party/poly2tri/sweep/sweep.cpp:164 |
62 | 164 const int index = triangle.EdgeIndex(&ep, &eq); |
63 | (gdb) p ep |
64 | $1 = (p2t::Point &) @0x815d57668: {x = 19850000, y = 14850000,
|
65 | edge_list = {<std::__1::__vector_base<p2t::Edge*, std::__1::allocator<p2t::Edge*> >> = {<std::__1::__vector_base_common<true>> = {<No data fields>},
|
66 | __begin_ = 0x0, __end_ = 0x0, |
67 | __end_cap_ = {<std::__1::__libcpp_compressed_pair_imp<p2t::Edge**, std::__1::allocator<p2t::Edge*>, 2>> = {<std::__1::allocator<p2t::Edge*>> = {<No data fields>}, __first_ = 0x0}, <No data fields>}}, <No data fields>}}
|
68 | (gdb) p eq |
69 | $2 = (p2t::Point &) @0x815d57640: {x = 20000000, y = 14850000,
|
70 | edge_list = {<std::__1::__vector_base<p2t::Edge*, std::__1::allocator<p2t::Edge*> >> = {<std::__1::__vector_base_common<true>> = {<No data fields>},
|
71 | __begin_ = 0x815c3ac40, __end_ = 0x815c3ac48, |
72 | __end_cap_ = {<std::__1::__libcpp_compressed_pair_imp<p2t::Edge**, std::__1::allocator<p2t::Edge*>, 2>> = {<std::__1::allocator<p2t::Edge*>> = {<No data fields>}, __first_ = 0x815c3ac48}, <No data fields>}}, <No data fields>}}
|
Gute Nacht!
Jörg W. schrieb: >> 2. Leertaste: Durchsuchbares Menü mit Aktionen für das ausgewählte >> Objekt sowie globalen Aktionen. > > OK, auch das schau ich mir an. Ja, das ist in der Tat das, was ich mir darunter vorgestellt habe. Spricht was dagegen, das (zusätzlich) auf die rechte Maustaste zu legen? Die ist derzeit ja ohnehin ungenutzt. Ich denke, das wäre eher die Stelle, wo viele solch ein Menü erwarten würden (zumindest mir geht's so). Die Leertaste hat einen Nachteil: sie ist „asymmetrisch“. Nach dem Öffnen des Menüs befindet man sich im Suchfeld, und ein weiteres Leerzeichen landet dann dort, statt dass man damit das Menü wieder schließen könnte.
Habe übrigens einen seltsamen Effekt mit diesem Menü. Weiß nicht, ob das nun ein Problem mit dem CDE/Motif-Theme ist, welches ich mir gerade ausgewählt habe, damit das Gtk3 etwas weniger Tablet-mäßig aussieht, oder ob da irgendwelche Größen falsch festgelegt sind.
Angehängte Dateien:
-
schematic1.PNG
190 KB
Hallo Jörg, hier mal ein screenshot mit horizon in WIN10. Ich habe da keine Probleme mit dem Befehlsmenü.
Helmut S. schrieb: > Ich habe da keine Probleme mit dem Befehlsmenü. Wenn ich das ~/.config/gtk-3.0/settings.ini zur Seite räume, sodass alles wieder auf das default theme zurückfällt, sieht das bei mir auch OK aus. Allerdings macht dieses Theme auch kein "hover", wenn man über die Menüeinträge fährt, wie es das CDE/Motif-Theme macht, welches im Video zu sehen ist. In einem reinen Screenshot lässt sich das kaum zeigen, daher hatte ich den Video-Mitschnitt gezimmert.
Jörg schrieb
> Allerdings macht dieses Theme auch kein "hover", wenn man über
die Menüeinträge fährt, wie es das CDE/Motif-Theme macht, welches im
Video zu sehen ist.
OK, jetzt weiß ich was du meinst.
Sollte das ein neuer Vorschlag für das GUI sein?
Ist das in anderen CAD-Programmen üblich?
Jörg W. schrieb: > Weiß nicht, ob das nun ein Problem mit dem CDE/Motif-Theme ist, welches > ich mir gerade ausgewählt habe, Ist es, ich hab' mir das Theme gerade mal selber installiert, sieht genau so aus wie bei dir, mit Adwaita ist es OK. Auch wenn man es anders vermuten könnte sind themes nicht wirklich von Gtk3 unterstützt: https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-at-scale/ Jörg W. schrieb: > Habe noch einen weiteren segfault: Ok, kann ich reproduzieren: Wenn im Outline-Layer die Ecken von zwei Polygonen die selbe Position haben und eines davon im stumpfen Winkel ist, verschluckt's sich beim Triangulieren. Scheint wohl auch eine Anforderung zu sein... https://github.com/greenm01/poly2tri Vermutlich hast du dieses Verhalten erzeugt, als du die Outline mit einer Linie gemalt hast. Horizon unterscheidet strikt zwischen Linien und Polygonen. Dinge, die eine Fläche beschreiben, wie eben Board-Outline und Bauteil-Konturen sind als Polygon zu zeichnen. Wenn du schon ein Linienzug hast, kannst du den mit "Line loop to polygon" zum Polygon machen. Eigentlicher Zweck dieses Tools, ist aus importierten Linienzügen Polygone zu machen, um Logos und dergleichen aufs Board zu bekommen.
Lukas K. schrieb: > Jörg W. schrieb: >> Weiß nicht, ob das nun ein Problem mit dem CDE/Motif-Theme ist, welches >> ich mir gerade ausgewählt habe, > > Ist es, ich hab' mir das Theme gerade mal selber installiert, sieht > genau so aus wie bei dir, mit Adwaita ist es OK. OK, damit kann ich leben. > Auch wenn man es anders > vermuten könnte sind themes nicht wirklich von Gtk3 unterstützt: > https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-at-scale/ Naja, wenn wenigstens das default theme nicht so hässlich aussähe, dass man meint, die ganze Welt wäre nun ein Tablet … Vermutlich ist in diesem CDE/Motif-Thema die Schrift einfach zu groß. > Vermutlich hast du dieses Verhalten erzeugt, als du die Outline mit > einer Linie gemalt hast. Das ist gut möglich. > Horizon unterscheidet strikt zwischen Linien > und Polygonen. OK. Abstürzen sollte es natürlich nicht, aber zumindest ist das eine Erklärung.
@Lukas Wie ist dein Interesse an pull requests im horizon-pool? Ich könnte mir vorstellen, einige der bei mir in der Datenbank vorhandenen Bauteile mal aufzunehmen, sodass bspw. eine Anzahl an Standard-Transistoren auf diese Weise zustande käme. Ich würde mich dabei vorrangig auf SMD konzentrieren, denn anders als die THT-Bauteile verwalte ich meinen SMD-Kram in einer Datenbank, sodass ich einen ganz guten Überblick habe, was da ist.
Feature request: Es sollte eine Möglichkeit geben, Elemente des Pools im Dateisystem zu verschieben. Hatte gerade gemerkt, dass meine neu eingerichteten Unterverzeichnisse "afpoweramp" eigentlich vom Sinn her deckungsgleich mit den (teilweise) schon existierenden "afamp" waren. Manuelles Verschieben aller Teile parallel im Dateisystem und im pool.db ist doch etwas aufwändig, und ich vermute, dass ich nicht der letzte sein werde, der sowas mal ändern möchte. Die "tags" sind keine schlechte Idee, aber so wie sie jetzt sind, kaum zu überschauen. Bei der Auswahl von tags fände ich es sinnvoll, ein Dropdown-Menü zu haben, in dem alle existierenden tags aufgeführt sind. Bei der Vergabe von tags wäre das auch nicht schlecht, auf diese Weise zu wissen, was es schon gibt.
Jörg W. schrieb: > Manuelles > Verschieben aller Teile parallel im Dateisystem und im pool.db ist doch > etwas aufwändig, und ich vermute, dass ich nicht der letzte sein werde, > der sowas mal ändern möchte. Du kannst Teile frei im Pool verschieben, sofern sie in ihren jeweiligen Ordnern bleiben (Parts in "parts", etc). Beim klicken auf "Update Pool" wird die pool.db geleert und mit dem, was es an Dateien gibt, neu aufgebaut.
Lukas K. schrieb: > Beim klicken auf "Update Pool" wird die pool.db geleert und mit dem, was > es an Dateien gibt, neu aufgebaut. OK, gut zu wissen.
Lukas K. schrieb: > Ist behoben und sollte in Zukunft auch nicht mehr so einfach passieren, > da die CI jetzt auch mit debian stretch statt ubuntu artful baut. Danke, ich habe es noch mal ausprobiert und compilieren geht jetzt. Nur starten leider nicht: ./horizon-eda (horizon-eda:17562): glibmm-CRITICAL **: unhandled exception (type Glib::Error) in signal handler: domain: gtk-builder-error-quark code : 11 what : .:1071:40 Invalid property: gtkmm__GtkInfoBar.revealed Ich las irgendwo im Thread was von gtkmm und einer Mindestversion 3.2. Laut Debian Versionsnummer sollte es bei mir 3.22.0 sein. Irgendwelche Ideen?
Angehängte Dateien:
-
moving-wires.png
96 KB
Lukas K. schrieb: > Ist repariert. Das nenn ich mal schnelle Reaktionszeit. Nun startets, aber der Pool Download klappt nicht: Error: git error 12 Failed to resolve address for https: Der Name oder der Dienst ist nicht bekannt. Per Wireshark sehe ich dass die Github Url zu 192.30.253.116 aufgelöst, und dann eine https Verbindung aufgebaut wurde. Im Ordner wird auch ein .remote Ordner angelegt. Ein manuelles git clone https://github.com/carrotIndustries/horizon-pool.git funktioniert hingegen. Was mir bisher aufgefallen ist: 1. Verschiebt man Leitungen und Bauteile per Auswahl "Move" im Untermenü scheint es einen Versatz in der Rasterung zu geben (links im Schematic), bei der Auswahl über die Tastatur "m" trat dies nicht auf (rechts im PCB). 2. Ich habe nicht herausgefunden wie ich aus D? D1 mache. 3. Nachdem ich das Fenster auf volle Bildschirmhöhe gezogen hatte (ich habe die Taskleiste an der Seite), war es nicht mehr möglich die Fensterhöhe zu ändern, da ein entsprechendes Symbol bei der Maus nicht mehr eingeblendet wurde. Nur über einen Rechtsklick in der Taskleiste des Fensters und dann Auswahl "Move" konnte ich es wieder verkleinern. Aber ansonsten halte ich Horizon für vielversprechend :)
> Nun startets, aber der Pool Download klappt nicht:
Error: git error 12 Failed to resolve address for https: Der Name oder
der Dienst ist nicht bekannt.
Hast du in dem Ordner in dem horizon-eda liegt die Datei
"ca-bundle.crt"?
Wenn man unter WIN kompiliert, dann muss man diese Datei selber dort hin
kopieren. Wie das in Linux ist weiß ich nicht.
Running
....
For the pool download to work, you'll have to copy the file
/mingw64/ssl/certs/ca-bundle.crt to the directory the directory
horizon-eda.exe resides in.
Malte _. schrieb: > Nun startets, aber der Pool Download klappt nicht: > Error: git error 12 Failed to resolve address for https: Der Name oder > der Dienst ist nicht bekannt. Da darfst du dich wohl bei debian bedanken, bei denen aus lizenzpolitischen gründen libgit2 aktuell ohne TLS-Unterstützung gebaut ist: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832798 Mit dem libgit2 und -dev aus den backports tut's. Malte _. schrieb: > 1. Verschiebt man Leitungen und Bauteile per Auswahl "Move" im Untermenü > scheint es einen Versatz in der Rasterung zu geben (links im Schematic), > bei der Auswahl über die Tastatur "m" trat dies nicht auf (rechts im > PCB). In der Zoomstufe bei dir wird im schaltplan gerade nur jeder 4. Gitterpunkt angzeigt (s. ×4 rechts neben der Rastereinstellung) > 2. Ich habe nicht herausgefunden wie ich aus D? D1 mache. Hamburger-Menü → Annotate > 3. Nachdem ich das Fenster auf volle Bildschirmhöhe gezogen hatte (ich > habe die Taskleiste an der Seite), war es nicht mehr möglich die > Fensterhöhe zu ändern, da ein entsprechendes Symbol bei der Maus nicht > mehr eingeblendet wurde. Konnte ich mit xfce und compositing nachvollziehen, hängt wohl mit den client-side decorations von Gtk zusammen, da dort die Fensterschatten die Anfasser zum Größe ändern sind. Da du den screeshots nach zu urteilen kein Composting benutzt, hab ich's mal damit probiert und konnte das Problem nicht reproduzieren. Helmut S. schrieb: > Wenn man unter WIN kompiliert, dann muss man diese Datei selber dort hin > kopieren. Wie das in Linux ist weiß ich nicht. Auf Linux muss man das nicht machen, dort bedient sich curl/openssl aus den Systemzertifikaten.
Lukas schrieb
> 2. Ich habe nicht herausgefunden wie ich aus D? D1 mache.
Hamburger-Menü → Annotate
Man will doch oft manuell den "Reference designator" setzen.
Warum nicht rechts im Property-Fenster D? zu D1 ändern?
Dafür ist das eingeblendete Fenster unter anderem doch da.
guten Morgen, Ich möchte mich auch an Horizon versuchen und quäle mein C2D Laptop (lubuntu 18.04.x) mit dem Build. Der Build benötigt gute 2GB freien Plattenplatz, das sollte man im voraus wissen, bitte einen Hinweis dokumentieren. So vermisse ich ein clean-Target um nur die o-Files zu entsorgen jedoch die Executables zu behalten. Der Build lastet meine Maschine nur so 15..30% aus und geht entsprechend quälend langsam vonstatten. Die Abhängigkeiten sind im Makefile Wohl nicht vollständig erfasst: alle meine Versuche mit make -j 2 (oder anderer Zahl) bringen den Rechner zwar auf Vollast aber dafür endlos bis zum hängen =:'( auch wenn ich bloss ein Teilziel builde (z.B. horizon-pool). Gibt es eine, zumindest grobe, Übersicht zur Quellcodearchitektur? Ich würde mich daran versuchen das Makefile zu pimpen um den Build auf Trab zu bringen...
Roland schrieb: > Der Build benötigt gute 2GB freien Plattenplatz, das sollte man im > voraus wissen, bitte einen Hinweis dokumentieren. Naja, das ist ja mittlerweile "peanuts". Kann man sicher dokumentieren, aber andere (Firefox z.B. oder gar Openoffice) sind da drastisch gefräßiger. > So vermisse ich ein > clean-Target um nur die o-Files zu entsorgen jedoch die Executables zu > behalten. "mostlyclean"? > Der Build lastet meine Maschine nur so 15..30% aus und geht entsprechend > quälend langsam vonstatten. Zu wenig RAM? Diese C++-Builds sind recht speicherintensiv. > Die Abhängigkeiten sind im Makefile Wohl nicht vollständig erfasst: alle > meine Versuche mit make -j 2 (oder anderer Zahl) bringen den Rechner > zwar auf Vollast aber dafür endlos bis zum hängen =:'( auch wenn ich > bloss ein Teilziel builde (z.B. horizon-pool). Ich habe kein Problem, alles mit -j4 gebaut zu bekommen (auf 4 Kernen).
Angehängte Dateien:
-
moving-wires2.png
52 KB
Jörg W. schrieb: > Roland schrieb: > >> Der Build lastet meine Maschine nur so 15..30% aus und geht entsprechend >> quälend langsam vonstatten. > > Zu wenig RAM? Diese C++-Builds sind recht speicherintensiv. Das wird es sein, ich habs mal beobachtet, meist braucht ein einzelner Compiler bei Horizon 6-8%, teilweise aber bis zu 11% meiner 8GB RAM. Also rund 800MB. Bei 2GB RAM und 1GB fürs System, bleibt da nur RAM für einen Compileraufruf übrig. Ich war überrascht, dass auch mein System mit make -j 12 folglich anfängt zu swappen. Bauen dauert bei mir 4,5 Minuten (Ryzen 1600). Lukas K. schrieb: > ist: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832798 > Mit dem libgit2 und -dev aus den backports tut's. Danke, daran kannst du ja nicht wirklich was ändern. > Malte _. schrieb: > In der Zoomstufe bei dir wird im schaltplan gerade nur jeder 4. > Gitterpunkt angzeigt (s. ×4 rechts neben der Rastereinstellung) Hmm, ich habe da mal etwas reingezoomt (siehe Screenshot). > Hamburger-Menü → Annotate Ah, gut. > Konnte ich mit xfce und compositing nachvollziehen, hängt wohl mit den > client-side decorations von Gtk zusammen, da dort die Fensterschatten > die Anfasser zum Größe ändern sind. Ich verwende da zugegebenermaßen eine nieschen GUI - Trinity (ehemals KDE 3.5). Interessanterweise gibt es das Problem nur, wenn das Fenster vertikal den Bildschirm ausfüllt. Horizontal ist kein Problem.
Jörg W. schrieb: > Roland schrieb: : : > >> So vermisse ich ein >> clean-Target um nur die o-Files zu entsorgen jedoch die Executables zu >> behalten. > > "mostlyclean"? Gerne! Wo?
1 | .../horizon$ |
2 | .../horizon$ make mostlyclean |
3 | make: *** No rule to make target 'mostlyclean'. Stop. |
4 | .../horizon$ |
5 | .../horizon$ grep -i mostly Makefile |
6 | .../horizon$ |
7 | .../horizon$ |
8 | .../horizon$ grep PHONY Makefile |
9 | .PHONY: clean clean_router clean_oce clean_res |
10 | .../horizon$ |
11 | .../horizon$ grep clean Makefile |
12 | src/pool-prj-mgr/prj-mgr/pool_cache_cleanup_dialog.cpp\ |
13 | clean: clean_router clean_oce clean_res |
14 | clean_router: |
15 | clean_oce: |
16 | clean_res: |
17 | .PHONY: clean clean_router clean_oce clean_res |
18 | .../horizon$ |
19 | .../horizon$ |
Liege ich mit meiner Erwartung falsch wenn Maketarget clean nur
Zwischenprodukte des Builds (*.o, *.d, ...) loeschen sollte, nicht aber
die gebrauchsfertigen Executables (und fuer deren Betrieb noetigen,
generierten Hilfsdateien)?
Um ALLES komplett zu loeschen ("Kaltstart" des Buildes) dann lieber das
Maketarget clean-all
Vollstaendigkeitshalber fehlen M.M.n. folgende Maketargets: clean-imp
, clean-pool , clean-prj , clean-pool ,
clean-pool-update-parametric , clean-eda alle in Anlehnung an das
Maketarget all1 | .../horizon$ |
2 | .../horizon$ grep ^all Makefile |
3 | all: horizon-imp horizon-pool horizon-prj horizon-pool-update-parametric horizon-eda |
4 | .../horizon$ |
Auch muesste auch all noch als PHONY markiert werden.
1 | .../horizon$ |
2 | .../horizon$ grep all Makefile |
3 | all: horizon-imp horizon-pool horizon-prj horizon-pool-update-parametric horizon-eda |
4 | src/core/tool_update_all_planes.cpp\ |
5 | src/core/tool_set_nc_all.cpp\ |
6 | src/canvas3d/wall.cpp\ |
7 | CXXFLAGS =$(DEBUG) $(DEFINES) $(OPTIMIZE) $(shell pkg-config --cflags $(LIBS_ALL)) -MP -MMD -pthread -Wall -Wshadow -std=c++14 -O3 |
8 | .../horizon$ |
9 | .../horizon$ grep PHONY Makefile |
10 | .PHONY: clean clean_router clean_oce clean_res |
11 | .../horizon$ |
12 | .../horizon$ |
Alle Ausfuehrbaren Maketargets sollten in einer Variable (z.B. EXE_ALL aehlich OBJ_ALL) gelistet werden, so lassen diese sich einfach von der Loeschliste auslassen. (es gibt noch bessere "Richtlinien", aber erstma so als Minimum) ZIEL: kein rm sollte direkt mit Dateinamen operieren, sondern nur mit Variablen welche Listen von Dateien nennen. ZIEL: kein Dateinamen sollte mehrmals im Makefile erwaehnt sein --> Ausfaktorieren in Variable(n) Ist es zudem nicht auch so dass, insbesondere Plattfomuebergreifend (hier Win u Linux), die make-externen Befehle wie z.B. rm via Variablen a la $(RM) aufgerufen werden sollten, anstatt sich blind auf beliebig vorliegende Werte von PATH zu stuetzen? Die Aufteilung der Gruppe "horizon-*" <-> "clean_*" erschliesst sich mir nicht ganz: zum einen sind da die resultierenden Userprogramme horizon-imp/-pool/-prj/-pool-update-parametric/-eda aber WAS sind _router, _oce, und _res ? (router waere noch als 3rd_party/router zu finden, aber fuer keine der anderen 3rd_party-Teile gibt es separate Maketargets...)
I <3 Makefiles schrieb: >> "mostlyclean"? > > Gerne! Wo? War jetzt eher ein Implementierungsvorschlag. > Liege ich mit meiner Erwartung falsch wenn Maketarget clean nur > Zwischenprodukte des Builds (*.o, *.d, ...) loeschen sollte, nicht aber > die gebrauchsfertigen Executables (und fuer deren Betrieb noetigen, > generierten Hilfsdateien)? Ja. War vielleicht vor 25 Jahren so zuweilen gebräuchlich ("make clobber" entfernte dann alles), aber mittlerweile ist "make clean" ein Synonym für "räume alles auf, was beim normalen Build entsteht". Lediglich Dinge wie "configure"-Scripte und deren Hinterlassenschaften bleiben dann noch üblicherweise liegen, diese sind aber auch nicht durch "make all" entstanden. Den Wunsch, nur die Objektdateien aber nicht die Ergebnisse zu löschen, hat heutzutage eigentlich kaum noch jemand. Plattenplatz kost' nichts mehr.
I <3 Makefiles schrieb: > Jörg W. schrieb: >> Roland schrieb: > : > : >> >>> So vermisse ich ein >>> clean-Target um nur die o-Files zu entsorgen jedoch die Executables zu >>> behalten. >> >> "mostlyclean"? > > Gerne! Wo? da, wo du's implementierst? War ja offensichtlich als "Idee" gemeint... > Liege ich mit meiner Erwartung falsch wenn Maketarget clean nur Ja. Zumindest wenn ich mich auf knapp 30 Jahre Praxis in "configure; make" stütze, so lief das üblicherweise immer so: "make clean" - löscht Objekte und Ausführbare "make distclean" - löscht zusätzlich die Ergebnisse aus "configure" [oops, da kam ein Kaffee dazwischen :-)]
Wem' die Kompilate zu groß sind, der kann auch ohne Debug-Symbole bauen. Die Binaries werden davon z.B. um Faktor 30 kleiner. Die verschiedenen Make-Targets für router und oce gibt es, damit nicht alles andere die komischen Include-Pfade für diese Programmteile abbekommt. Wenn jemand das Makefile noch weiter verbessern will, bitte als Pull Request einreichen, aber dabei bitte Dinge die man nun wirklich nicht braucht, wie z.B. rm als Variable, sein lassen. Jörg W. schrieb: > Ich habe kein Problem, alles mit -j4 gebaut zu bekommen (auf 4 Kernen). Hat bei anderen Leuten auch mit -j8 gebaut und alle Kerne beschäftigt. Wenn sich die CPU langweilt, dann muss das wohl an Swappen oder langsamem IO liegen. Wär' schön, wenn damit die Diskussion über das Makefile sich damit erübrigt hat. Malte _. schrieb: > Hmm, ich habe da mal etwas reingezoomt (siehe Screenshot). Da scheint ja gar nichts zu passen. Wurde die Diode schon off-grid platziert, oder ist die erst durch verschieben so geraten? Jörg W. schrieb: > Die "tags" sind keine schlechte Idee, aber so wie sie jetzt sind, kaum > zu überschauen. Das musste ich auch feststellen. Vielleicht ist eine klassische Baumstruktur stattdessen doch keine so dumme Idee.
Seit kurzem ist jetzt endlich ein überaus nützliches Feature auch tatsächlich benutzbar: https://github.com/carrotIndustries/horizon/wiki/Copying-layout-and-placement Wie im Wiki beschrieben kann man damit Platzierung und Leiterbahnen von zuvor im Schaltplan definierten Gruppen kopieren, sodass man z.B. Layout und Platizerung von Spannungsreglern, die mehrfach in verschiedener Ausführung auf dem Board vorhanden sind, nur einmal machen muss.
Lukas K. schrieb: > Wie im Wiki beschrieben kann man damit Platzierung und Leiterbahnen von > zuvor im Schaltplan definierten Gruppen kopieren, sodass man z.B. Layout > und Platizerung von Spannungsreglern, die mehrfach in verschiedener > Ausführung auf dem Board vorhanden sind, nur einmal machen muss. Ui nettes Feature - das kann KiCad meines Wissens nicht.
Angehängte Dateien:
-
group_visibility.GIF
150 KB
Lukas K. schrieb: > Seit kurzem ist jetzt endlich ein überaus nützliches Feature auch > tatsächlich benutzbar: > https://github.com/carrotIndustries/horizon/wiki/Copying-layout-and-placement > > Wie im Wiki beschrieben kann man damit Platzierung und Leiterbahnen von > zuvor im Schaltplan definierten Gruppen kopieren, sodass man z.B. Layout > und Platizerung von Spannungsreglern, die mehrfach in verschiedener > Ausführung auf dem Board vorhanden sind, nur einmal machen muss. Hallo Lukas, ich habe gerade "group" und copy-layout in WIN10 versucht. Bin aber gescheitert. Dazu habe ich beide Schaltregler in eine group gepackt. Ist das so richtig oder muss sich jeden Regler in eine eigene group packen? Ein "Highlight group/tag" finde ich nicht. Dafür finde ich "Toggle grpup & tag visibility". Das Ergebnis sieht aber nicht so aus wie in dem wiki. Da gibt es rote und gelbe Umrandungen. Bei mir gibt es nur ellenlangen Text. https://github.com/carrotIndustries/horizon/wiki/Copying-layout-and-placement Was mache ich falsch? Dann dachte ich mir ich platziere und vedrahte einen Regler im Layout. Wie bekomme ich dann das Layout kopiert mit dem 2. Regler? Aus dem Text werde ich nicht schlau. To tell horizon EDA the matching components in each group, these get assigned identical tags. Since a newly-placed component will already be assigned a unique tag and groups and tags get preserved on copy/paste other instances of the same circuit will likely have the appropriate tags already set. To change the tag on a component, use the "Set tag" tool.
Hallo Lukas, nachdem ich deinen screenshot im wiki genauer angeschaut habe, denke ich dass ich das mit den groups und tags verstanden und im Schaltplan jetzt richtig gemacht habe. Layoutfenster Das Kopieren im Layout klappt aber immer noch nicht nach der Anleitung. Wie kann ich feststellen, dass das Layout etwas von den groups und tags weiß?
Helmut S. schrieb: > Hallo Lukas, > nachdem ich deinen screenshot im wiki genauer angeschaut habe, denke ich > dass ich das mit den groups und tags verstanden und im Schaltplan jetzt > richtig gemacht habe. > > Layoutfenster > Das Kopieren im Layout klappt aber immer noch nicht nach der Anleitung. > Wie kann ich feststellen, dass das Layout etwas von den groups und tags > weiß? Hallo Lukas, Ich habe jetzt den Text deiner Beschreibung noch genauer versucht zu verstehen. Jetzt klappt das kopieren der Platzierung und der Traces. Danke für diese Funktion. Gruß Helmut
Angehängte Dateien:
-
3D_board_schwarz.GIF
17 KB
Hallo Lukas, warum ist mein Board in 3D schwarz. Wo wird die Farbe dafür eingestellt? Wie wäre es mit grün als Standard? Helmut
Helmut S. schrieb: > Hallo Lukas, > warum ist mein Board in 3D schwarz. > Wo wird die Farbe dafür eingestellt? > Wie wäre es mit grün als Standard? > Helmut Asche auf mein Haupt. Ich muss blind gewesen sein, dass ich die rechteckigen Felder zur Einstellung der Boardfarbe in den Preferences der 3D-Ansicht übersehen habe.
https://github.com/carrotIndustries/horizon/commit/9614c23e2c4660c04d755b884311d66f085a3e7b repariert die Default-Farben für neue Boards. Helmut S. schrieb: > Ich habe jetzt den Text deiner Beschreibung noch genauer versucht zu > verstehen. Jetzt klappt das kopieren der Platzierung und der Traces. > Danke für diese Funktion. Was genau in der Anleitung war unklar?
Lukas K. schrieb: > https://github.com/carrotIndustries/horizon/commit/9614c23e2c4660c04d755b884311d66f085a3e7b > repariert die Default-Farben für neue Boards. > > Helmut S. schrieb: >> Ich habe jetzt den Text deiner Beschreibung noch genauer versucht zu >> verstehen. Jetzt klappt das kopieren der Platzierung und der Traces. >> Danke für diese Funktion. > > Was genau in der Anleitung war unklar? Ich hatte versucht mit dem Wissen von Xpedition das im Blindflug zu probieren.
Angehängte Dateien:
-
plane_to_fehler.GIF
190 KB
Hallo Lukas, Bei mir in WIN10 geht "Plane to trace" oder auch "plane zu sonstwas" überhaupt nicht. Bei mir sind da immer 0.1mm Abstand egal was ich in den Rules eingestellt habe. Selbst mit deinem TX-board geht es nicht. Da sind es immer 0,2mm obwohl auch dort in Rules "plane to trace 0,5mm" eingestellt ist. Im Anhang ein screenshot von einem meiner Tests.
Helmut S. schrieb: > Bei mir in WIN10 geht "Plane to trace" oder auch "plane zu sonstwas" > überhaupt nicht Guck nochmal genau hin, der Haken bei "Enable this rule" fehlt.
Lukas K. schrieb: > Helmut S. schrieb: >> Bei mir in WIN10 geht "Plane to trace" oder auch "plane zu sonstwas" >> überhaupt nicht > > Guck nochmal genau hin, der Haken bei "Enable this rule" fehlt. Hallo Lukas, danke das war. Ich glaube ich sollte mir die Menüs in Zukunft genauer anschauen. Neue Frage: Hatte ich da nicht schon mal irgendwo "thermal ties" gesehen? Ich finde nichts um das einzuschalten. Vielleicht war das aber auch in KiCad.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.