mikrocontroller.net

Forum: Projekte & Code Neues, halbfertiges Elektronik-CAD-Programm


Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
9 lesenswert
nicht lesenswert
Hallo Zusammen,

nach einigen Monaten ist mein Elektronik-CAD-Programm endlich halbwegs 
vorzeigbar: https://github.com/carrotIndustries/horizon

Auch wenn es schon alles von Schaltplan bis Gerber-Export da ist, gibt 
es immer noch mehr als genug Dinge, die anders/besser werden müssen, bis 
man damit ernsthaft Platinen entwickeln kann.

Viel Spaß damit,
Lukas

: Verschoben durch Moderator
Autor: Hardy F. (hardyf)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Und du bist dir sicher, das eine Vielzahl von Leuten dein Programm 
ausprobieren, nutzen und weiterempfehlen werden, weil es sich ja so 
leicht von jedermann installieren läßt ?!?

Jeder "Electronic-CAD-Programm" - Nutzer ist ja automatisch auch ein 
fähiger Programmierer, der sich mit sowas

"For building on Windows, use MSYS2

Dependencies:

Gtkmm3
libepoxy
cairomm-pdf
librsvg
util-linux (on linux only)
yaml-cpp
sqlite "

easy

("It's as easy as make.")

auskennt ....

[Wer Ironie gefunden hat, darf sie behalten ]

: Bearbeitet durch User
Autor: il Conte (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Lukas K. schrieb:
> nach einigen Monaten ist mein Elektronik-CAD-Programm endlich halbwegs
> vorzeigbar: https://github.com/carrotIndustries/horizon

Was ist den hier los ?
Hat hier jemand den CAD-ÖTZI aus Versehen aufgetaut ? 😊

Ob er wohl checkt wie es in dieser bösen CAD-Welt zugeht.
Es bleibt zu hoffen,
dass er nicht dieser listigen Autodesk-Schlange anheimfällt :-( 🙁


----

Bitte nicht allzu ernst nehmen ;-)😉
Ich frage mich halt, ob es mit deinem Wissen nicht andere Projekte
gibt die einen weitaus größeren Nährwert versprechen,
als wie hier alte 'Suppen' aufzuwärmen.

Autor: Baendiger (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Gibt es gar keine Screenshots?

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
-9 lesenswert
nicht lesenswert
Wer was kostenloses sucht und nicht scharf auf Frust ist, der greift zu 
Kicad...

Autor: CAD (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Hallo Zusammen,
>
> nach einigen Monaten ist mein Elektronik-CAD-Programm endlich halbwegs
> vorzeigbar: https://github.com/carrotIndustries/horizon
>
> Auch wenn es schon alles von Schaltplan bis Gerber-Export da ist, gibt
> es immer noch mehr als genug Dinge, die anders/besser werden müssen, bis
> man damit ernsthaft Platinen entwickeln kann.
>
> Viel Spaß damit,
> Lukas

Nur 6 commits auf github??

Sieht auf den Screenshots aber schonmal vielversprechend aus. Werde es 
bei Gelegenheit mal ausprobieren.

@hardyf: Wenn Du erwartest, dass Dir andere Leute das Denken abnehmen, 
dann solltest Du Dir vielleicht ein anderes Hobby suchen.

Autor: Michael Bertrandt (laberkopp)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Viel Spaß damit

Schön, daß sich jemand bemüht, etwas zu erschaffen.
Aber meinst du wirklich, daß noch eines nötig war ?

https://en.wikipedia.org/wiki/Comparison_of_EDA_software
http://www.eevblog.com/forum/eda/pcbeda-software-list/

Vielleicht hätte man besser bei den anderen halbfertigen Projekten 
mithelfen können.

AutoTrax macht beispielsweise eigentlich alles richtig, schönes 
Programm, alles möglich dabei, nicht zu teuer. Und bekommt trotzdem seit 
10 Jahren keinen Fuss an den Boden.

 https://dexpcb.com/

Wenn man schon von vorne anfängt, hat man wenigstens
keine Altlasten und kann bei Standards beginnen:

 https://de.wikipedia.org/wiki/Electronic_Design_In...
 http://pcad-libs.embedders.org/rules/ref_617.pdf
  http://wiki.fed.de/index.php/Lageorientierung_von_...
 http://www.lp-akademie.de/publikationen/cad-bg/vom...

 http://www.k-state.edu/edl/docs/pubs/technical-res...

: Bearbeitet durch User
Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael B. schrieb:
> Wenn man schon von vorne anfängt, hat man wenigstens
> keine Altlasten und kann bei Standards beginnen:

Das ist zwar im Prinzip richtig, aber ein Standard nutzt wenig, wenn man 
ihn als einziger benutzt. Den firmenübergreifenden Standard für 
Leiterplatten-CAD gibt es nicht, und meiner Ansicht nach besteht auch 
wenig Hoffnung. Ich habe selbst schon Konversionsprogramme geschrieben 
und weiss, an welchen Kleinigkeiten eine 1:1 Umwandlung scheitert - nur 
als ganz einfaches Beispiel, man hat 6eckige Lötaugen und im Zielsystem 
gibt es das nicht. Von komplexeren Sachen wie differential Lines 
garnicht erst zu reden.

Georg

PS besonders "beliebt" sind grundsätzliche Unterschiede in der 
Definition von beliebigen Flächen.

Autor: Schorsch Tripeljuh (Gast)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
> @hardyf: Wenn Du erwartest, dass Dir andere Leute das Denken abnehmen,
> dann solltest Du Dir vielleicht ein anderes Hobby suchen.

Ja, und die Keramikkondensatoren töpfern wir auch selbst.

Autor: Ingenieur (Gast)
Datum:

Bewertung
-9 lesenswert
nicht lesenswert
Was Ich an Gihub überhaupt nicht leiden kann, ist das komplett 
unsoriterte und unübersichtliche Schema!

Man kriegt ein Repository hingeknallt, das weder Übersicht hat noch 
schafft! Und die Nutzer führen auch keine Übersicht ein!

Richtig wäre, mal

1) Beschreiben, WAS das ist
2) für welchen Nutzerkreis es sein soll
3) Wie es funktioniert!

Dazu braucht es ein Übersichtsdigramm, welche Module es gibt, wie man 
sie benutzt, was man dazu noch braucht  und in dem Fall, dass es nur 
sourven sind, wie man sie zusammenbaut.

Also

a) Schnittstellen zur Aussenwelt
b) Schnittstellen inten
c) Bedienerfunktionalität.

All das wäre in einigem richtigen Projekt sauber und übersichlich 
vorhanden und dokumentiert, damit es auch einer nutzen kann.

So ist das einfach nur ein großer Saustall und Chaos!

Leider gilt das auch für dieses Projekt. Das macht es unmöglich, da mit 
einzusteigen, Interesse zu wecken oder einen in die Lage zu versetzen, 
einzuschätzen, ob man es verwenden kann.

DAS IST DER GRUND; WARUM AUS SOLCHEN PROJEKTEN NIX WIRD. DA ENTWROGT 
JEMAND NUR SEINEN MÜLL; DEN ER IM KOPF HAT IN FORM VON SOFTWARE AUF 
EINEM OFFENEN SERVER.

eigentlich ist das dann nicht viel mehr, als eine Müllhalde ...

............

und wenn Ich jetzt noch etwas zu der Notwendigkeit eines CAD-Programmes 
sagen würde, wäre es ganz haarig ...

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ingenieur schrieb:
> Was Ich an Gihub überhaupt nicht leiden kann

Und was hat das mit Github zu tun?

Autor: Andreas H. (ahz)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Ingenieur schrieb:
>> Was Ich an Gihub überhaupt nicht leiden kann
>
> Und was hat das mit Github zu tun?

Nix.

Aber wenn man schon gewohnt ist alles umsonst haben zu wollen dann ist 
es doch auch egal worüber man meckert^^

Ansonsten @ingenieur: Ja, etwas mehr Effort könnte so ein Projekt sicher 
vertragen.
Wann willst Du mit was helfen? Hardy F. hat ja schon festgestellt, dass 
ein Build für Windows hilfreich wäre...


@Lukas K.: Nette Idee :-)

Aber wenn Du nicht "Alleinunterhalter" bleiben willst, dann solltest Du 
evtl. eine minimale SW Beschreibung anlegen (meist reichen die 
"normalen" Doxygen Kommentare schon aus).
DU (!) weisst ja, was Du wie implementiert hast. Alle Anderen müssten 
sich das erst zusammensuchen, was unnötiger Aufwand ist.

Hast Du schon eine Idee wie sich das Projekt weiterentwickeln soll?

/regards

Autor: 3162534373 .. (3162534373)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wenn Push&shove Routing dabei ist, dann tue ich mir sogar komplizierte 
Installation an ;)
Ohne Push&shove ist es doch sinnlos

Autor: tester (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Ich bekomms es nicht compiliert:

In file included from /usr/include/c++/5/bits/stl_algobase.h:64:0,
                 from /usr/include/c++/5/bits/char_traits.h:39,
                 from /usr/include/c++/5/ios:40,
                 from /usr/include/c++/5/ostream:38,
                 from /usr/include/c++/5/iostream:39,
                 from util/uuid.hpp:8,
                 from pool/part.hpp:2,
                 from pool/part.cpp:1:
/usr/include/c++/5/bits/stl_pair.h: In instantiation of ‘constexpr 
std::pair<_T1, _T2>::pair(_U1&&, _U2&&) [with _U1 = const 
nlohmann::basic_json<>&; _U2 = const nlohmann::basic_json<>&; 
<template-parameter-2-3> = void; _T1 = bool; _T2 = 
std::__cxx11::basic_string<char>]’:
pool/part.cpp:10:30:   required from here
/usr/include/c++/5/bits/stl_pair.h:145:64: error: call of overloaded 
‘basic_string(const nlohmann::basic_json<>&)’ is ambiguous
  : first(std::forward<_U1>(__x)), second(std::forward<_U2>(__y)) { }
                                                                ^
In file included from /usr/include/c++/5/string:52:0,
                 from /usr/include/c++/5/bits/locale_classes.h:40,
                 from /usr/include/c++/5/bits/ios_base.h:41,
                 from /usr/include/c++/5/ios:42,
                 from /usr/include/c++/5/ostream:38,
                 from /usr/include/c++/5/iostream:39,
                 from util/uuid.hpp:8,
                 from pool/part.hpp:2,
                 from pool/part.cpp:1:
/usr/include/c++/5/bits/basic_string.h:476:7: note: candidate: 
std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>&&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc 
= std::allocator<char>]
       basic_string(basic_string&& __str) noexcept
       ^
/usr/include/c++/5/bits/basic_string.h:398:7: note: candidate: 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = 
char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]
       basic_string(const basic_string& __str)
       ^
/usr/include/c++/5/bits/basic_string.h:390:7: note: candidate: 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const 
_Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = 
std::allocator<char>]
       basic_string(const _Alloc& __a)
       ^
Makefile:238: die Regel für Ziel „pool/part.o“ scheiterte
make: *** [pool/part.o] Fehler 1

Autor: Hardy F. (hardyf)
Datum:

Bewertung
-7 lesenswert
nicht lesenswert
tester schrieb:
> Ich bekomms es nicht compiliert:


Wieso ????

Ist doch easy....

Oder ?


Dann bleib ich mal lieber bei meinem Hobby  ;-)

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tester schrieb:
> Ich bekomms es nicht compiliert:

Hm, welcher GCC? Bei mir hier baut's mit GCC 6.3.1 und clang 3.9.1.

Ich hab mir die Zeile mal angesehen, versuch mal das zu ändern:

Wo vorher war:
attributes[Attribute::MPN] = {j.at("MPN").at(0),j.at("MPN").at(1)};

Das:
attributes[Attribute::MPN] = {j.at("MPN").at(0).get<bool>(),j.at("MPN").at(1).get<std::string>()};

bei den beiden Zeilen drunter analog dazu.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
3162534373 .. schrieb:
> Wenn Push&shove Routing dabei ist, dann tue ich mir sogar komplizierte
> Installation an ;)
> Ohne Push&shove ist es doch sinnlos

Push-and-shove gibt's noch nicht, aber der Router weicht immerhin schon 
den meisten Hindernissen aus. Der push-and-shove-Router von KiCAD hat 
änhlich viele lines of code wie horizon derzeit, um mal so die 
Komplexität darzustellen...

Autor: Hardy F. (hardyf)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
@ Lukas

Ich würde sehr gern dein Programm mal ausprobieren.

Ich komme aber mit Selbstcompilieren nicht klar.

Da habe ich in der Schule wohl nicht aufgepasst damals vor 5x Jahren...

Also bitte versuche einen fertigen Windows-Build mit dazuzustellen auf 
der Seite.

Es dürften sicher paar mehr Leute ganz dankbar dafür sein so wie auch 
ich.

Autor: tester (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Hm, welcher GCC? Bei mir hier baut's mit GCC 6.3.1 und clang 3.9.1.

Bei mir der Standard gcc/g++ 5.4 von Ubuntu 16.04. Aber der Patch läuft,
ich konnte part.cpp kompilieren. Jetzt hängt er bei schematic.cpp.
Die Meldung ist dieses Mal etwas länger. Ist als Anhang dabei...

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Andreas H. schrieb:
> Aber wenn Du nicht "Alleinunterhalter" bleiben willst, dann solltest Du
> evtl. eine minimale SW Beschreibung anlegen (meist reichen die
> "normalen" Doxygen Kommentare schon aus).
> DU (!) weisst ja, was Du wie implementiert hast. Alle Anderen müssten
> sich das erst zusammensuchen, was unnötiger Aufwand ist.

Als ganz groben Anhaltspunkt gibt's den Abschmitt "Theory of operation" 
in der README, damit sollte man schonmal halbwegs wissen wo vorne ist. 
Doxygen-Dokumentation hatte ich persönlich nie als wirklich hilfreich 
empfunden, da darin oft erklärt ist, was auch eine Zeile drunter im Code 
steht, aber die grobe Struktur fehlt.

> Hast Du schon eine Idee wie sich das Projekt weiterentwickeln soll?
Unabhängig von dem Programm selber:
Pool befüllen, dass man auch sinnvolle Schaltpläne und Boards machen 
kann.

Kurz/mittelfristige ziele:
 - Platzieren von Bauteilen einfacher machen
   Liste von zuletzt benutzten Bauteilen; den Dialog "Select Part"
   auch als nicht  modales Fenster zur Verfügung stellen.
 - Parametrische Suche: Die pool-parametric.db wird schon erzeugt, fehlt
   "nur noch" ne hübsche GUI drüber.
 - DRC: mit der clipper-Library ist der algorithmisch schwere Teil
   (Polygon-Operationen) schon erledigt, fehlt noch die gesamte
   Infrastruktur außenrum.
 - GUI für die constraints. Die als JSON zu bearbeiten und mit UUIDs zu
   hantieren macht derzeit gar keinen Spaß.
 - "Projekt-Manager", dass man sich nicht mehr die Argumente für
   horizon-imp selber ausdenken muss, sondern einfach Klicken kann.

Nicht vergessen: Rom wurde auch nicht an einem Tag erbaut (und auch 
nicht in einer Nacht)

Autor: Andreas H. (ahz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tester schrieb:
> Ich bekomms es nicht compiliert

Schön das Du es probierst :-)

Benutzt Du MSYS2 (<-- 2 !!!)?

Lukas K. schrieb:
> Bei mir hier baut's mit GCC 6.3.1

Unter MSYS2 ist afaik GCC5 erst seit Anfang Januar verfügbar. Vieleicht 
liegt es daran?

/regards

Autor: Robin R. (elec-lisper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael B. schrieb:
> AutoTrax macht beispielsweise eigentlich alles richtig, schönes
> Programm, alles möglich dabei, nicht zu teuer. Und bekommt trotzdem seit
> 10 Jahren keinen Fuss an den Boden.
>
>  https://dexpcb.com/

Das Programm sieht super aus. Aber die Webseite aus dem letzten 
Jahrtausend.
Vorallem mit diesen käsig eingefügten Stock-Fotos:

     https://dexpcb.com/Company

Es scheint aber alles zu haben...

Ich versteh aber auch nicht wieso es noch ein neues gibt. LibreCAD ist 
doch auch gerade durchs Forum hier gehuscht... Prinzipiell find ichs 
aber gut, man weiss ja nie, welches von den vielen Free Software 
Programmen dann letztendlich die breitere User-Basis bekommt.


Was ich aus meinen Softwareprojekten aber gelernt hatte:
Wenn man in einem Forum, in dem es nicht hauptsächlich um 
Softwareentwicklung geht, postet, dann sollte man eine ZIP oder EXE oder 
tar.gz/.deb (für Ubuntu) parat haben. Sonst bekommt man eben genau die 
Sprüche und Probleme zu lesen wie oben (been there, done that).

Es ist letztendlich immer die Frage welche Motivation hinter dem Projekt 
steckt. Wenn man nur ausprobieren will, ob man es theoretisch hinbekommt 
sowas zu programmieren, dann ist ca. ab dem jetzt erreichten Stand die 
Luft raus. Wenn man etwas schreibt, damit mans selbst benutzt, dann 
gehts meist noch weiter. Aber selbst gebastelte Lösungen, die nicht noch 
von anderen mit getragen werden, werden erfahrungsgemäß irgendwann 
abgelöst. Beispielsweise wenn man in ein paar Jahren selbst ein Feature 
braucht welches andere Programme (KiCAD, Eagle, ...) haben, aber nicht 
die Zeit hat es selbst zu implementieren, weil man das Projekt seit 5 
Monaten nicht mehr angefasst hat und zu faul ist sich wieder in den Code 
einzuarbeiten.

Prinzipiell kann ich es aber nur unterstützen und finde es absolut 
großartig, dass Entwickler weiterhin Projekte für die Allgemeinheit 
schreiben und den Quelltext veröffentlichen.

Würde aber gerne wissen wo sich Horizon und bspw. auch LibreCAD relativ 
zu KiCAD positionieren. Ein Problem bei KiCAD ist ja nachweislich die 
etwas merkwürdige Benutzerführung. Wenn man sich aber einmal zurecht 
gefunden hat, kommt man sehr gut damit klar - "eigentlich".

Autor: tester (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Andreas H. schrieb:
> Benutzt Du MSYS2 (<-- 2 !!!)?

Evtl. verstehe ich dich falsch, aber MSYS2 ist doch für Windows der 
Cygwin Posix Layer, oder? Ich versuche, das ganze unter Ubuntu 16.04 zu 
kompilieren, also brauche ich kein MSYS!

Autor: Andreas H. (ahz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tester schrieb:
> Ich versuche, das ganze unter Ubuntu 16.04 zu
> kompilieren, also brauche ich kein MSYS!

Ne,das brauchst Du dann wirklich nicht, Ich dachte dass Du unter Windows 
arbeitest :-)

/regards

Autor: Andreas H. (ahz)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Als ganz groben Anhaltspunkt gibt's den Abschmitt "Theory of operation"
> in der README, damit sollte man schonmal halbwegs wissen wo vorne ist.

Den Teil fand ich (nicht böse gemeint) eher wirr.
"Unit" ist sehr ungünstig gewählt, weil man bei CAD als Unit immer an 
eine Masseinheit denkt (typischerweise gibt es davon ja Mehrere, die der 
Benutzer nur zum Teil sieht.

Anyway. Lt. README wäre die atomare "Unit" ein Gate? Also ist ein Pin 
(des Gates) was? Und ein Pin(-typ) kann ja auch in mehreren 
unterschiedlichen "Units" vorkommen.
Du verstehst meine Verwunderung?

> Doxygen-Dokumentation hatte ich persönlich nie als wirklich hilfreich
> empfunden, da darin oft erklärt ist, was auch eine Zeile drunter im Code
> steht, aber die grobe Struktur fehlt.

Das ist leider SOOOO wahr. Aber man muss solche Fehler ja nicht 
unbedingt wiederholen^^

>
>> Hast Du schon eine Idee wie sich das Projekt weiterentwickeln soll?
> Unabhängig von dem Programm selber:
> Pool befüllen, dass man auch sinnvolle Schaltpläne und Boards machen
> kann.

Spricht etwas dagegen einen Eagle/KiCad/Whatever -> Horizon Converter zu 
basteln?
Dann füllt sich das von selbst.

>
> Kurz/mittelfristige ziele:

Ich Deinen Text etwas umsortiert schreib da mal frech meine Gedanken 
dazwischen :-D

>  - Platzieren von Bauteilen einfacher machen
>    Liste von zuletzt benutzten Bauteilen; den Dialog "Select Part"
>    auch als nicht  modales Fenster zur Verfügung stellen.
>  - Parametrische Suche: Die pool-parametric.db wird schon erzeugt, fehlt
>    "nur noch" ne hübsche GUI drüber.
>  - GUI für die constraints. Die als JSON zu bearbeiten und mit UUIDs zu
>    hantieren macht derzeit gar keinen Spaß.
>  - "Projekt-Manager", dass man sich nicht mehr die Argumente für
>    horizon-imp selber ausdenken muss, sondern einfach Klicken kann.

Wäre es nicht sinnvoller Horizon erst mal vollständig zum laufen zu 
kriegen bevor man "Comfortfkt's" einbaut? Z.B.:

>  - DRC: mit der clipper-Library ist der algorithmisch schwere Teil
>    (Polygon-Operationen) schon erledigt, fehlt noch die gesamte
>    Infrastruktur außenrum.
>
Was behandelt der DRC denn? Clearance & width sind ja die 
Minimalforderungen. Wenn der Router Necking können soll, dann muss der 
DRC aber auch Mintracewidth handhaben können, ggf. auch mit 
Längenbeschränkungen.

Ist Dein Router (if any) schon DRC aware (d.h. berücksichtigt er alle 
DRC Rules)? Ansonsten hast Du da noch eine große Baustelle.

Appropos Baustelle: Du schreibst "der Router weicht immerhin schon
den meisten Hindernissen aus".
Was für einen Router hast Du denn da am Start?
(SOWAS habe ich z.B. gesucht)

Und finally: ERC? Ich hab nur kurz in die Quellen reingeschaut aber I/O 
directions bei den Gates ist mir nicht aufgefallen.

> Nicht vergessen: Rom wurde auch nicht an einem Tag erbaut (und auch
> nicht in einer Nacht)

Du hattest doch in diesem Leben nichts anderes mehr vor (hoffe ich)?

/regards

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas H. schrieb:
> Lukas K. schrieb:
>> Als ganz groben Anhaltspunkt gibt's den Abschmitt "Theory of operation"
>> in der README, damit sollte man schonmal halbwegs wissen wo vorne ist.
>
> Den Teil fand ich (nicht böse gemeint) eher wirr.
> "Unit" ist sehr ungünstig gewählt, weil man bei CAD als Unit immer an
> eine Masseinheit denkt (typischerweise gibt es davon ja Mehrere, die der
> Benutzer nur zum Teil sieht.
>
> Anyway. Lt. README wäre die atomare "Unit" ein Gate? Also ist ein Pin
> (des Gates) was? Und ein Pin(-typ) kann ja auch in mehreren
> unterschiedlichen "Units" vorkommen.
> Du verstehst meine Verwunderung?

Bei KiCAD gibt's auch "Unit" im sinne von nicht-Maßeinheit. Schlechte 
Ausrede, aber so ist's nun eben...

Ich versuch's nochmal zu erklären, diesmal andersherum:
Das logische Bauteil (ohne Gehäuse, etc) ist in einer "Entity" 
definiert. Eine solche Enity kann mehrere Gates haben (Gatter, Opamps, 
IO-Bänke, etc).
Nun haben mehrere Entities die selben Gates, z.B. Quad- und Doppel-opamp 
haben beide vier bzw zwei Opamp-Gates. Daher bietet es sich an, die 
Gates mit ihren Pins nicht innerhalb der Entities zu definieren, sondern 
extern davon und die Gates diese Definition referenzieren zu lassen. 
Ebendiese nennt sich dann "Unit".

Ich hoffe ich habe damit nicht noch mehr Verwirrung gestiftet...

> Spricht etwas dagegen einen Eagle/KiCad/Whatever -> Horizon Converter zu
> basteln?
> Dann füllt sich das von selbst.

Wäre ein doch bedeutender Aufwand, man müsste eben gemeinsame Gates über 
Bauteile hinweg finden, daraus Units machen, etc. Die Platzierung von 
Texten ist dann wahrscheinlich vollkommens im Eimer, weil das jeder 
geringfügig anders macht.

Für einzelne Bauteile (große Mikrocontroller z.B.) kann ein solcher 
Importer durchaus sinnvoll sein. Einen Massenimport ohne 
Qualitätskontrolle wünsche ich mir allerdings nicht.

Auch ist man ohne Importer gezwungen, horizon zu benutzen und gibt dann 
hoffentlich sinnvolles Feedback, was einen nicht so gefällt...

Wenn jemand einen schreibt, der zufriedenstellend funktioniert, habe ich 
nichts dagegen :)
>
> Wäre es nicht sinnvoller Horizon erst mal vollständig zum laufen zu
> kriegen bevor man "Comfortfkt's" einbaut? Z.B.:
Durchaus, alles eine Sache der Prioritäten.

> Was behandelt der DRC denn? Clearance & width sind ja die
> Minimalforderungen. Wenn der Router Necking können soll, dann muss der
> DRC aber auch Mintracewidth handhaben können, ggf. auch mit
> Längenbeschränkungen.

Genau, das war auch so mein Gedanke.

> Ist Dein Router (if any) schon DRC aware (d.h. berücksichtigt er alle
> DRC Rules)? Ansonsten hast Du da noch eine große Baustelle.

Er legt keine Leiterbahn, so dass der Minimalabstand zu anderen Netzen 
unterschritten wird, aber schmiegt sich nicht an diese auf DRC-Abstand 
an.

> Appropos Baustelle: Du schreibst "der Router weicht immerhin schon
> den meisten Hindernissen aus".
> Was für einen Router hast Du denn da am Start?
> (SOWAS habe ich z.B. gesucht)

Ist recht primitiv: Der routet immer zwei Segmente (eines davon 
horziontal/vertikal und eines im 45°-Winkel), und versucht durch 
"umdrehen" der zwei Segmente DRC-Fehler zu vermeiden. Wenn das nicht 
klappt, bleibt der Track da stehen, wo's als letztes keinen DRC-fehler 
gab. Nicht vergleichbar mit dem was KiCAD macht, aber immerhin etwas.

> Und finally: ERC? Ich hab nur kurz in die Quellen reingeschaut aber I/O
> directions bei den Gates ist mir nicht aufgefallen.

Die gibt es, allerdings nur in der Datenstruktur:
https://github.com/carrotIndustries/horizon/blob/m...

Wenn es DRC gibt, sollte dabei als Nebenprodukt eine Infrastruktur für 
"Checks" rausfallen, in die man dann auch ERC einhängen können sollte.

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Doxygen-Dokumentation hatte ich persönlich nie als wirklich hilfreich
> empfunden, da darin oft erklärt ist, was auch eine Zeile drunter im Code
> steht, aber die grobe Struktur fehlt.

Das habe ich früher auch mal gedacht. Mittlerweile habe ich -- dank der 
freundlichen Hilfe eines großen Meisters und meiner Erfahrung -- jedoch 
festgestellt, daß doxygen & Co. hervorragende und nützliche 
Dokumentation erzeugen können, wenn der Entwickler seinen Code sauber 
dokumentiert hat.

Ganz unabhängig davon, ob Du doxygen oder ähnliche Werkzeuge magst oder 
nicht: wenn Du andere Entwickler dazu animieren willst, bei Deinem 
Projekt mitzuhelfen, solltest Du ihnen den Einstieg so einfach wie 
möglich machen. Und das beginnt nun einmal mit einer ordentlichen 
Dokumentation.

Solche Werkzeuge können einem natürlich nicht die Arbeit abnehmen, 
seinen Code ordentlich und verständlich zu dokumentieren. Aber wenn man 
das macht, also: Klassen, Methoden, Variablen und vor allem die Konzepte 
und Schichten der Software vernünftig dokumentiert, dann können doxygen 
& Co. daraus eine sehr gute Dokumentation erzeugen. Und mit dieser 
Dokumentation können dann die vorhandenen und neuen Entwickler viel 
schneller verstehen, was gemacht wird, wo es gemacht wird, wie es 
gemacht wird und warum.

Klar, so wie Dein Code bisher dokumentiert ist -- nämlich gar nicht, wie 
ein zugegeben oberflächlicher Blick zeigt -- wird kein Werkzeug der Welt 
daraus etwas Sinnvolles machen können. Keine Software kann Informationen 
aus dem Nichts generieren. Nicht einmal doxygen. ;-)

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
tester schrieb:
> Lukas K. schrieb:
>> Hm, welcher GCC? Bei mir hier baut's mit GCC 6.3.1 und clang 3.9.1.
>
> Bei mir der Standard gcc/g++ 5.4 von Ubuntu 16.04. Aber der Patch läuft,
> ich konnte part.cpp kompilieren. Jetzt hängt er bei schematic.cpp.
> Die Meldung ist dieses Mal etwas länger. Ist als Anhang dabei...

Ubuntu im Allgemeinen ist wohl ne mittelgroße Baustelle, da auch in 
Ubuntu 16.10 nur Gtk 3.20 dabei ist, ich aber Funktionen von Gtk 
benutze, die es erst seit 3.22 gibt. Nichts was unbedingt notwendig ist, 
aber die #if GTK_CHECK_VERSION() kommen auch nicht von alleine...

Schaut also aus, als liefe horizon derzeit nur auf Arch Linux und Fedora 
25. Hoppla.

Autor: Cyborg (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Baendiger schrieb:
> Gibt es gar keine Screenshots?

Ich finde auch, dass fehlende Scennshots abschreckend wirken.
Wer weiß, was man sich da im Worst-Case-Fall einfängt und nicht
alles findet der Virenscanner. Vielleicht lernst der TO noch, sonst
kann er sein Projekt gleich begraben.

Autor: Andreas H. (ahz)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Cyborg schrieb:
> Baendiger schrieb:
>> Gibt es gar keine Screenshots?
>
> Ich finde auch, dass fehlende Scennshots abschreckend wirken.
> Wer weiß, was man sich da im Worst-Case-Fall einfängt und nicht
> alles findet der Virenscanner. Vielleicht lernst der TO noch, sonst
> kann er sein Projekt gleich begraben.

EDA Sw für Leute die nicht lesen können wäre bestimmt eine Marktlücke.

Der lesekundige Teil der Menschheit wird dann damit abgespeist:
https://github.com/carrotIndustries/horizon/tree/m...

/regads

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tester schrieb:
> Lukas K. schrieb:
>> Hm, welcher GCC? Bei mir hier baut's mit GCC 6.3.1 und clang 3.9.1.
>
> Bei mir der Standard gcc/g++ 5.4 von Ubuntu 16.04. Aber der Patch läuft,
> ich konnte part.cpp kompilieren. Jetzt hängt er bei schematic.cpp.
> Die Meldung ist dieses Mal etwas länger. Ist als Anhang dabei...

War nun doch weniger aufwändig als gedacht: 
https://github.com/carrotIndustries/horizon/commit...

Baut nun auf Ubuntu 16.04, der Part-Editor tut auch, ob der interaktive 
Manipulator funktioniert, konnte ich nicht testen, da meine VM kein 
OpenGL 3 kann.

Autor: Andreas H. (ahz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Bei KiCAD gibt's auch "Unit" im sinne von nicht-Maßeinheit. Schlechte
> Ausrede, aber so ist's nun eben...

Genau das. Schlechte Ausrede :-)

>
> Ich versuch's nochmal zu erklären, diesmal andersherum:
> Das logische Bauteil (ohne Gehäuse, etc) ist in einer "Entity"
> definiert. Eine solche Enity kann mehrere Gates haben (Gatter, Opamps,
> IO-Bänke, etc).
> Nun haben mehrere Entities die selben Gates, z.B. Quad- und Doppel-opamp
> haben beide vier bzw zwei Opamp-Gates. Daher bietet es sich an, die
> Gates mit ihren Pins nicht innerhalb der Entities zu definieren, sondern
> extern davon und die Gates diese Definition referenzieren zu lassen.
> Ebendiese nennt sich dann "Unit".
>
> Ich hoffe ich habe damit nicht noch mehr Verwirrung gestiftet...
>

Nö, leider nicht. Ein "logisches Bauteil" ist doch nur eine Funktion 
(ggf mit einem Symbol). Den Parametern muss man, genau wie dem Result 
einen Namen geben (Ports). Die vergibt man pro Funktion (z.B. Q = A & 
B). Mehr kann man jetzt noch nicht zuordnen.

Erst wenn das Ganze in ein Device wandert, dann ist die Art & Anzahl der 
Funktionen definiert. Und erst jetzt kann (und muss) man den Ports 
eindeutic Pins zuordnen (Pin == das wo Du Dich raufsetzen und pieksen 
kannst, zumindest bei z.B. THT Bauteilen). Dann hätten Deine Funktionen 
endlich unterschiedliche "Namen" für die Pors der jeweiligen Funktionen 
(Q1 = A1 & B1, Q2 = A2 & B2 usw).

Du hast also ZWEI Sachen. Die "Ports" an der "Funktion" und die "Pins" 
am Gehäuse. Ports haben z.B. elektrische Parameter (z.B In-/Output), 
Pins eher Mechanische (Fläche, evtl. Drill usw.).
Ob es wirklich sinnvoll ist, dem jetzt nochmal "frei gewählte" 
Bezeichnungen zuzuordnen? Ich sehe da wenig Sinn.



>> Spricht etwas dagegen einen Eagle/KiCad/Whatever -> Horizon Converter zu
>> basteln?
>> Dann füllt sich das von selbst.
>
> Wäre ein doch bedeutender Aufwand, man müsste eben gemeinsame Gates über
> Bauteile hinweg finden, daraus Units machen, etc. Die Platzierung von
> Texten ist dann wahrscheinlich vollkommens im Eimer, weil das jeder
> geringfügig anders macht.
>
> Für einzelne Bauteile (große Mikrocontroller z.B.) kann ein solcher
> Importer durchaus sinnvoll sein. Einen Massenimport ohne
> Qualitätskontrolle wünsche ich mir allerdings nicht.
>

Checken muss man das sowieso. Ich kenne auch kaum Leute, die die Libs 
der Tools benutzen, ohne vorher die Bauteile, die sie benutzen, mal 
geprüft zu haben. Auch EDA Hersteller machen Fehler^^

> Auch ist man ohne Importer gezwungen, horizon zu benutzen und gibt dann
> hoffentlich sinnvolles Feedback, was einen nicht so gefällt...

Das ist Mutig. Denn niemand ist GEZWUNGEN horizon für irgendetwas zu 
benutzen. Im Gegenteil. Ich würde meine eigenen Libs ungern nochmal 
einhacken müssen.

>> Was behandelt der DRC denn? Clearance & width sind ja die
>> Minimalforderungen. Wenn der Router Necking können soll, dann muss der
>> DRC aber auch Mintracewidth handhaben können, ggf. auch mit
>> Längenbeschränkungen.
>
> Genau, das war auch so mein Gedanke.
>

Ich habe beim Überfliegen auch nirgens irgendwelche Grids gefunden 
(übersehen?) Man kann ja gridless routen. Aber wenn Du Gridless Placen 
willst, dann hast Du evtl. interessante Diskussionen mit dem Bestücker 
(zumindest ältere PicknPlace Automaten hatten da Limits).


>> Ist Dein Router (if any) schon DRC aware (d.h. berücksichtigt er alle
>> DRC Rules)? Ansonsten hast Du da noch eine große Baustelle.
>
> Er legt keine Leiterbahn, so dass der Minimalabstand zu anderen Netzen
> unterschritten wird, aber schmiegt sich nicht an diese auf DRC-Abstand
> an.
>

Muss er auch nicht unbedingt (Diff-Pairs mal ausgenommen).

>> Und finally: ERC? Ich hab nur kurz in die Quellen reingeschaut aber I/O
>> directions bei den Gates ist mir nicht aufgefallen.
>
> Die gibt es, allerdings nur in der Datenstruktur:
> https://github.com/carrotIndustries/horizon/blob/m...
>
> Wenn es DRC gibt, sollte dabei als Nebenprodukt eine Infrastruktur für
> "Checks" rausfallen, in die man dann auch ERC einhängen können sollte.

Nö. Das sind zwei (fast) komplett unterschiedliche Baustellen. Ob da 
zwei Pins geneinander treiben ist dem Router genauso egal, wie die 
Tatsache, das ein Netz nur Eingänge als Pins hat.
Andersherum interessiert es den ERC nicht wenn Du 20A über eine 6mil 
Leitung jagst oder 20KV mit 10mil clearance routest.

/regards

Autor: Andreas H. (ahz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Schaut also aus, als liefe horizon derzeit nur auf Arch Linux und Fedora
> 25.

Lukas K. schrieb:
> konnte ich nicht testen, da meine VM kein
> OpenGL 3 kann.

Wäre vielleicht sinnvoll, die Anforderungen (compiler, HW) etwas zu 
reduzieren. Ansonsten fallen viele potentielle Tester schon mal weg, 
selbst wenn du es Dir antust für diverse OS Packages zu bauen. 
Spätestens bei Graphikkarten kanns eng werden.

KiCad hat z.B. eine ganze Zeit mit einem Problem von WxWidgets mit GTK3 
gekämpft. Und da konnte KiCad garnichts dafür.

Was spricht denn gegen eine "konservative" Toolchain (bei Linux z.B. 
Debian Jessie oder RH/CentOs6, bei Windows Win7, bei Mac k.A.^^)?
Das Ganze mit AutoConf oder cMake erleichtert auch das Portieren.

Auch GTK3 erfreut sich ja anscheinend zunehmender Unbeliebtheit, wenn 
man so einigen Foren glauben darf.

/regards

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
7 lesenswert
nicht lesenswert
Hardy F. schrieb:
> Also bitte versuche einen fertigen Windows-Build mit dazuzustellen auf
> der Seite.

Hardy: wenn sich ein Programm selbst noch als „halbfertig“ bezeichnet,
dann sind Leute, die es sich nicht selbst compilieren können oder
wollen ohnehin keine sinnvollen Alpha-Tester.  Falls da wirklich
„was abgeht“, dann musst du damit rechnen, dass du das täglich oder
aller zwei Tage neu bauen musst, damit du nicht die Bugs nochmal
versuchst zu finden, die seither schon beseitigt sind.  In dieser Phase
kann man sowas einfach nicht durch vorgekochte Builds erschlagen.

Ich weiß auch nicht, inwiefern es wirklich Sinn hat, das x-te
Programm dieser Art anzufangen, aber das wird die Zeit sicher zeigen.
Solange es Lukas erstmal nur aus Spaß an der Freude gemacht hat, ist
es doch nur fair, wenn er anderen die Möglichkeit einräumt, es
ebenfalls zu testen und ggf. Verbesserungen vorzuschlagen.  Aus eigener
Erfahrung kann ich natürlich sagen, dass solche Vorschläge am besten
die Form eines "diff" annehmen :) (oder bei github wahrscheinlich eines
pull requests).

Autor: Michael X. (Firma: vyuxc) (der-michl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht orientiert ihr euch an bereits bestehenden Workflows. Kicad 
erinnert mich an OrCad und lässt sich so von mir fast intuitiv bedienen. 
Vielleicht springt ihr in die Bresche und macht nen Adler-Kompatiblen 
Workflow. Da dürfte dann für viele User der Grund zum Wechsel werden.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas H. schrieb:
> Erst wenn das Ganze in ein Device wandert, dann ist die Art & Anzahl der
> Funktionen definiert.

Da liegt der Hund begraben. In horizon gibt es da noch den 
Zwischenschritt "Entity". Für die Netzliste ist ein Quad-Nand-Gatter in 
CMOS-4000er Logik in DIP Gleichwertig mit einem 74HC in (theoretisch 
BGA). Wenn man sich mitten im Design-Prozess anders entscheidet, ist es 
problemlos bei einem Component (instantiierte Entity) das Part 
auszutauschen, ohne dass die Netzliste was davon mitbekommt.

Andreas H. schrieb:
> Ich habe beim Überfliegen auch nirgens irgendwelche Grids gefunden
> (übersehen?) Man kann ja gridless routen. Aber wenn Du Gridless Placen
> willst, dann hast Du evtl. interessante Diskussionen mit dem Bestücker
> (zumindest ältere PicknPlace Automaten hatten da Limits).
Das Raster kommt daher, dass der Cursor auf's grid einschnappt.

Andreas H. schrieb:
>> Wenn es DRC gibt, sollte dabei als Nebenprodukt eine Infrastruktur für
>> "Checks" rausfallen, in die man dann auch ERC einhängen können sollte.
>
> Nö. Das sind zwei (fast) komplett unterschiedliche Baustellen.
Klar, die Implementierung der Checks ist vollständig verschieden, am 
Ende vom Tag können beide aber die gleiche Infrastruktur zur 
Konfiguration und Darstellung der Ergebnisse nutzen.

Was Toolchains, etc anbetrifft: Mittlerweile baut's ja auf Ubuntu 16.04 
und kommt auch mit Gtk 3.18 zurecht.

OpenGL 3.2 ist leider Pflicht, da zum Rendern u.A. geometry shader 
verwendet werden. Mag zwar erstmal unnütz klingen, ist voraussichtlich 
bei großen Boards von Vorteil. Ist jetzt auch schon über 7 Jahre her, 
dass das wirklich neu war.

Andreas H. schrieb:
> Auch GTK3 erfreut sich ja anscheinend zunehmender Unbeliebtheit, wenn
> man so einigen Foren glauben darf.

War absehbar, dass das kommt ;) Ich persönlich kann das Gejammer nicht 
nachvollziehen, works for me.

Jörg W. schrieb:
> Hardy: wenn sich ein Programm selbst noch als „halbfertig“ bezeichnet,
> dann sind Leute, die es sich nicht selbst compilieren können oder
> wollen ohnehin keine sinnvollen Alpha-Tester.

Da ist was wahres dran. Rein technisch sind windows-Builds kein Problem 
[1], nur erwarten viele Windows-user, dass dann eine Exe rausfällt, auf 
die sie doppelklicken können und was sinnvolles passiert - so weit ist 
horizon nun noch nicht. Auch wünsche ich mir, dass von den Anwendern 
backtraces, etc kommen. "horizon-imp.exe funktioniert nicht mehr" ist da 
nicht wirklich hilfreich.

Auch bräuchte ich für die Windows-Builds sowas wie nen buildbot, denn 
ich will nicht nach jedem commit meine Windows-VM anwerfen müssen.

[1] 
https://github.com/carrotIndustries/horizon/blob/m...

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Auch bräuchte ich für die Windows-Builds sowas wie nen buildbot, denn
> ich will nicht nach jedem commit meine Windows-VM anwerfen müssen.

ich würd jetzt in dieser frühen Phase erstmal primär kein Gewicht auf 
zeitnahe Windows-Builds (oder andere Exotenplatformen) legen sondern auf 
das System konzentrieren unter dem auch primär die Entwicklung 
stattfindet, und da brauchst Du auch keine Binaries zu bauen, das machen 
die Tester und Mitentwickler eh selbst. Früher oder später wirst Du dann 
jemanden finden der genug Interesse an Windows hat daß der sich um die 
Windows-Builds kümmert.

: Bearbeitet durch User
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Früher oder später wirst Du dann jemanden finden der genug Interesse an
> Windows hat daß der sich um die Windows-Builds kümmert.

Oder man kann sich dann auch wirklich die Infrastruktur selbst mal
aufsetzen.  Ich habe mittlerweile (bei AVRDUDE) lernen müssen, dass
das am Ende schneller geht als zu hoffen, dass sich einer der
Windowsianer zu sowas freiwillig hinreißen lässt. :(  Das hat dann
das Kuriosum, dass dabei Windows-Builds enstehen, die selbst beim
Bauen nie ein Windows gesehen haben. :-)

Autor: Georg (Gast)
Datum:

Bewertung
-10 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Früher oder später wirst Du dann
> jemanden finden der genug Interesse an Windows hat

Es ist allerdings fragwürdig, die überwiegende Mehrheit der CAD-Benutzer 
von vornherein vom Testen auszuschliessen. Aber für Linux-Fanatiker ist 
das natürlich konsequent.

Der grundlegende Irrtum ist wohl, dass man eine abgeschottete 
Linux-Brüderschaft als "Kunden" sieht, und nicht Leute, die 
Leiterplatten entwerfen. Muss aber jeder Entwickler selber wissen. Nur 
nicht später wundern, wenn keiner das Programm benutzt.

Georg

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
11 lesenswert
nicht lesenswert
Georg schrieb:
> Der grundlegende Irrtum ist wohl, dass man eine abgeschottete
> Linux-Brüderschaft als "Kunden" sieht,

Wieso Linux?

Das Ding compiliert ja offenbar unter Windows.  Vermutlich bekommt
man es auch unter anderen Systemen zum Laufen.  Es sind also nicht
Windows-Nutzer per se ausgeschlossen, wie du das unterschwellig
darstellst.

> und nicht Leute, die
> Leiterplatten entwerfen.

Das ist erstmal völlig unabhängig vom OS: in solch einer frühen
Entwicklungsphase wirst du so oder so keine Platinendesigner groß
finden, die da ernsthaft gewillt wären mitzuentwickeln.  Es wurde
ja schon dargelegt, dass „Kunden“, die als Feedback dann lediglich
„horizon.exe hat einen Fehler verursacht und wurde beendet“ oder
„ich hätte gern Feature XYZ, bevor ich mir das ansehe“ in so einer
Entwicklunsphase sowieso nicht zielführend sind.  In dieser Phase
braucht man Leute, die Bugs nicht nur melden, sondern zumindest
analysieren, oder die eben auch mal anfangen, wenigstens über die
Implementierung eines Features nachzudenken.

Opensource kennt in diesem Sinne erstmal keine „Kunden“, sondern
eher „Macher“ (auch wenn dieser Begriff mittlerweile anderweitig
verzerrt worden ist).  Das ist ein sehr grundlegender Unterschied
zu Bezahlsoftware.

Übrigens ignorierst du geflissentlich, dass ein großer Teil der
CAD-Szene im IC-Design, das ja durchaus mit Platinendesign verwandt
ist, historisch auf großen UNIXen und heute nach wie vor massiv auf
Linux abläuft.  Ist also keineswegs so, dass es da keine Anwender
gäbe.  Aber das wissen natürlich Leute, die in ihrer abgeschotteten
Windows-Brüderschaft herumwerkeln, vermutlich gar nicht (um mal
deine Worte zu gebrauchen).

: Bearbeitet durch Moderator
Autor: Stefan (Gast)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
was ist an Autotrax nicht gut?
Nutze selber Target, aber AT sieht gut aus auch die Aufmachung der Seite

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
7 lesenswert
nicht lesenswert
Stefan schrieb:
> was ist an Autotrax nicht gut?

Das sollte ihr bitte in einem eigenen Thread diskutieren.

Den hier hat Lukas angefangen, um über horizon zu diskutieren.

Autor: Stefan (Gast)
Datum:

Bewertung
-19 lesenswert
nicht lesenswert
das wird noch sowieso nie einer benutzen also völlig wertlos

Autor: Cyblord ---- (cyblord)
Datum:

Bewertung
12 lesenswert
nicht lesenswert
Stefan schrieb:
> das wird noch sowieso nie einer benutzen also völlig wertlos

Also ich mache als Hobby auch viele Dinge die niemand benutzt. Beim 
Hobby ist der Weg das Ziel. Solange es Spaß macht spricht nichts 
dagegen.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
7 lesenswert
nicht lesenswert
Wer sich ins Abenteuer stürzen will, und auf Windows bauen möchte: 
https://github.com/carrotIndustries/horizon/blob/m...

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Wer sich ins Abenteuer stürzen will..

Nun ja, so ganz im Prinzip ist es allemal lobenswert, wenn jemand 
anfängt, sich mit so einem Projekt eine Mühe zu geben. Aber wer soll 
sich da zusätzlich ins Abenteuer stürzen?

Eigentlich müßte man mMn so ein Projekt völlig anders angehen, nämlich 
mit einem Dokument, PDF oder LibreOffice oder so, wo die Grundprinzipien 
entwickelt und dargestellt sind. Dort gehört also hinein, wie das ganze 
Programm von seiner ineren Logik her funktionieren soll, wie die Daten 
gehalten werden sollen, wie das Userinterface funktionieren soll, also 
wie man mit dem Programm später umgehen kann.

So etwas ist tausendmal wichtiger als sofort in die Tasten zu hauen. Es 
ist aber nötig vor jeglichen Programmieranstrengungen - zum einen 
damit man selber sowie eventuelle Mitarbeiter wissen, wie das Ganze 
zusammenspielen soll und zum anderen, damit interessierte Anwender ihre 
Sicht auf die Dinge einbringen können. Sonst wird das Ganze mal wieder 
ein Ding, das nur aus Sicht der Programmierer konstruiert wurde und an 
den tatsächlichen Bedürfnissen der Benutzer vorbeigeht.

Man mag sowas ein Pflichtenheft nennen, ich würde das zunächst nur ein 
Papier zur Ideen-konsolidierung nennen. Wenn sich das dann entwickelt, 
kommen interne Schnittstellen-Definitionen hinzu, damit verschiedene 
Leute an verschiedenen Teilen arbeiten können ohne sich gegenseitig zu 
hakeln.

Aber so, wie es vorliegt? Wer soll sich da hineinknien, um mühselig 
herauszufinden, wie hier was funktionieren soll? Nee, ich selber bin da 
außen vor, ich mache nix in cpp, sondern allenfalls mit Delphi oder 
Lazarus. Aber die Wahl einer Programmiersprache oder einer Toolchain ist 
mMn zweitrangig. Zuerst geht es um den tatsächlichen Systementwurf - und 
den vermisse ich hier.

W.S.

Autor: Andreas H. (ahz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Andreas H. schrieb:
>> Erst wenn das Ganze in ein Device wandert, dann ist die Art & Anzahl der
>> Funktionen definiert.
>
> Da liegt der Hund begraben. In horizon gibt es da noch den
> Zwischenschritt "Entity". Für die Netzliste ist ein Quad-Nand-Gatter in
> CMOS-4000er Logik in DIP Gleichwertig mit einem 74HC in (theoretisch
> BGA). Wenn man sich mitten im Design-Prozess anders entscheidet, ist es
> problemlos bei einem Component (instantiierte Entity) das Part
> auszutauschen, ohne dass die Netzliste was davon mitbekommt.

Was bringt das? Eine Netzliste ist doch on-the-fly erzeugt und ändert 
sich während des Schematic entrys laufend (bei Backanotation ja auch 
noch).

Der Sinn will sich mir nicht erschliessen, sry. Ich sehe da z.Z. nur 
potentielle Fehlerquellen.


>
> Andreas H. schrieb:
>> Ich habe beim Überfliegen auch nirgens irgendwelche Grids gefunden
>> (übersehen?) Man kann ja gridless routen. Aber wenn Du Gridless Placen
>> willst, dann hast Du evtl. interessante Diskussionen mit dem Bestücker
>> (zumindest ältere PicknPlace Automaten hatten da Limits).

> Das Raster kommt daher, dass der Cursor auf's grid einschnappt.
>

Das Raster IST das Grid. Und das ist ja nicht nur dort wo der Cursor 
ist.
Ich entnehme Deiner Aussage mal, dass es mindestens ein Grid gibt :-)


> Andreas H. schrieb:
>>> Wenn es DRC gibt, sollte dabei als Nebenprodukt eine Infrastruktur für
>>> "Checks" rausfallen, in die man dann auch ERC einhängen können sollte.

>>
>> Nö. Das sind zwei (fast) komplett unterschiedliche Baustellen.

> Klar, die Implementierung der Checks ist vollständig verschieden, am
> Ende vom Tag können beide aber die gleiche Infrastruktur zur
> Konfiguration und Darstellung der Ergebnisse nutzen.

Never. DRC geht auf geometische Daten, dem ERC reicht eine "annotierte" 
Netzliste (annotiert meint hier, das die Pins noch die "Direction" 
Attribute brauchen).
Ansonsten könntest Du keinen ERC machen, bevor das Layout steht^

(Ok, theoretisch könntest Du Parasitics aus dem Layout extrahieren & 
prüfen. Aber das ist eine GAAANZ andere Geschichte.)


>> Auch GTK3 erfreut sich ja anscheinend zunehmender Unbeliebtheit, wenn
>> man so einigen Foren glauben darf.
>
> War absehbar, dass das kommt ;) Ich persönlich kann das Gejammer nicht
> nachvollziehen, works for me.

Nimm was Dir Spass macht. Aber wenn es nachher nur bei 30% der Leute 
läuft dann macht es auch wenig Sinn, oder?
Und einen kleinen Vorgeschmack hast Du ja gestern schon bei tester 
mitbekommen. Das Ganze dann *100^^

/regards

Autor: Andreas H. (ahz)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Georg schrieb:
> Der grundlegende Irrtum ist wohl, dass man eine abgeschottete
> Linux-Brüderschaft als "Kunden" sieht, und nicht Leute, die
> Leiterplatten entwerfen.

DEIN grundlegender Irrtum ist, dass OSS Entwickler soviel Zeit haben, 
dass sie neben der Weiterentwicklung auch noch Unmengen an Hilferufen 
bearbeiten können.

Das wird meist noch nerviger wenn die "Kunden", wie Du sie nennst, meist 
nicht mal vernünftige Fehler-/Environmentbeschreibungen liefern.

Und das findest Du bei Linux/Windows/Mac "Kunden" gleichermassen.

Autor: Andreas H. (ahz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Eigentlich müßte man mMn so ein Projekt völlig anders angehen, nämlich
> mit einem Dokument, PDF oder LibreOffice oder so, wo die Grundprinzipien
> entwickelt und dargestellt sind.

Im Prinzip schon. Aber das kann man auch im Forum diskutieren. Gerade am 
Anfang fliessen dann auch Erfahrungn von Anderen ein ohne das erst mal 
viel "Papier" gemacht wird.

Mir würde es auch nur bedingt Spass machen, erst mal eine komplette Spec 
zu schreiben (das V-Modell nervt auf Arbeit schon genug).


> Aber so, wie es vorliegt? Wer soll sich da hineinknien, um mühselig
> herauszufinden, wie hier was funktionieren soll?

Da gibts aber einige Hinweise auf der Projektseite.

/regards


P.S:

W.S. schrieb:
> Nee, ich selber bin da außen vor, ich mache nix in cpp, sondern
> allenfalls mit Delphi oder Lazarus.

Ich leiste mir meist nicht den Luxus mich auf eine Programmiersprache 
festzubeissen. Aber bei Lazarus wäre ich dabei (Delphi geht ja leider 
nur unter Windows). Dann wäre man z.B. schon einen Großteil des 
"Buildwahns" los.

Autor: tester (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> OpenGL 3.2 ist leider Pflicht

Tja, das ist z.Zt. das Problem. Nach dem letzet git pull ist die 
Compilierung durchgelaufen, danke dafür. Aber starten kann ich es nicht:

xxxxx@HPi7:~/src/horizon$ ./horizon-imp -c sch.json block.json 
constr.json
(horizon-imp:5550): GLib-GObject-CRITICAL **: g_value_take_object: 
assertion 'G_IS_OBJECT (v_object)' failed
horizon-imp: Couldn't find current GLX or EGL context.

Mein X.org Server scheint nur OpenGL 3.0 zu haben:

xxxxx@HPi7:~/src/horizon$ glmark2
=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     X.Org
    GL_RENDERER:   Gallium 0.4 on AMD TURKS (DRM 2.43.0, LLVM 3.8.0)
    GL_VERSION:    3.0 Mesa 11.2.0
=======================================================

Hm... eingebaut ist eine Radeon HD6570, die sollte das eigentlich 
können.
Nach https://wiki.ubuntuusers.de/Grafikkarten/AMD/radeon/ sogar 
OpenGL4.1, aber mindestens OpenGL3.3. Mal sehen...

Autor: tester (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, prüfst du irgendwo im Quelltext die OpenGL Version? Die 
Grafikkarte sollte Shader 3.3 können, der Treiber scheint aber nach 
außen hin
nur die 3.0 zu melden. Den Error-String "Couldn't find current GLX or 
EGL context" habe ich im Quelltext nicht gefunden, um die Stelle zu 
lokalisieren...

xxxxx@HPi7:~/src/horizon$ glxinfo | grep version
#server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.2.0
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.0 Mesa 11.2.0
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.2.0
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 
3.00

Autor: tester (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fehler hatte wohl doch nichts mit OpenGL zu tun. Aus 
imp/main_window.cpp:

[...] x->add_from_resource("/net/carrotIndustries/horizon/window.ui");

Wie viele hardcodierte Pfade sind denn da drin?

xxxxx@HPi7:~/src/horizon$ grep -r -i "/net/carrotIndustries/horizon" | 
wc
     36     151    4173

Autor: tester (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, habe jetzt mal einen Symlink angelegt. Recht viel weiter komme ich 
leider nicht:

xxxxx@HPi7:/net/carrotIndustries/horizon$ ./horizon-imp -c sch.json 
block.json constr.json
terminate called after throwing an instance of 'Gio::ResourceError'
Abgebrochen (Speicherabzug geschrieben)

Gut für heute...

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das OpenGL-Problem sollte nun behoben sein, hatte mal wieder mit älteren 
Gtk-versionen zu tun: 
https://github.com/carrotIndustries/horizon/commit...

Die Pfade da sind keine Pfade im engeren Sinne: 
https://developer.gnome.org/gio/stable/GResource.html

Mit den "resources" können Dateien, die das Programm zur Laufzeit 
benötigt mit in die Binary gebacken werden.

Autor: W.S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Andreas H. schrieb:
> Aber das kann man auch im Forum diskutieren.

Im Prinzip - ja. Aber so ganz blank - ohne wenigstens ein Anfangspapier? 
Nee. geht nicht.

Du siehst ja an den Beiträgen kurz unter deinem, was da losgeht.

Ärger mit OpenGL ist doch eigentlich etwas, das so unendlich lowlevel 
ist, daß es die eigentliche Funktionalität garnicht berührt. Also MUSS 
man eine Trennung einziehen zwischen der CAD-Funktionalität und solch 
niederen Dingen wie Betriebssystem, GraKa und so weiter - versteh das 
richtig: es ist beides vonnöten, aber es muß strikt auseinander gehalten 
werden.

Womit wir wieder beim Papier mit der Grundsatzrede (a la Honecker.. oder 
lieber nicht) sind. Es hat wirklich keinen Zweck, draufloszucoden, 
solange kein "Honecker"-Papier existiert, das wenigstens einigermaßen 
ausdiskutiert ist.

Beruflich kenne ich das so, daß im Gremium ein Papier im Word-Format 
existiert, wo reihum jeder seinen Senf reinschreibt - und das wird dann 
beim nächsten Treffen diskutiert. Dann geht die nächste Runde los.. eben 
so lange, bis alle abgenickt haben.

W.S.

Autor: Georg (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
W.S. schrieb:
> das wird dann
> beim nächsten Treffen diskutiert. Dann geht die nächste Runde los.. eben
> so lange, bis alle abgenickt haben.

Da hast du die Zeichen der Zeit nicht erkannt - in Zukunft zählt nur 
noch die Methode Trump, Abweichler werden sofort standrechtlich 
erschossen und technische Fragen werden durch alternative Fakten gelöst.

Im Ernst, Konsens ist sowas von gestrig.

Georg

Autor: Stefan S. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Lukas K. schrieb:
> mein Elektronik-CAD-Programm endlich halbwegs
> vorzeigbar:

Hallo Lukas!

Ja was soll ich sagen? Zunächst sollte ich Dir wohl mal meine 
Anerkennung aussprechen -- Du bist einer der wenigen hier, die mal etwas 
zustande bringen, statt immer nur rumzumosern.

Du kennst ja sicher meinen Schaltplaneditor, den ich vor einigen Jahren 
mal in Ruby programmiert hatte (http://ssalewski.de/PetEd.html.en), und 
auch meinen Toporouter(http://ssalewski.de/Router.html.en). Da war das 
Interesse ja praktisch null. Oder den Schaltplaneditor, den hier jemand 
vor etwa einem jahr in Jawa präsentiert hatte -- auch null Interesse.

Aber du wirst wohl eh nicht erwarten, dass sich jemand an Deinem Projekt 
beteiligt.

Was mich doch etwas wundert: Wenn Du schon in C++ programmieren magst, 
warum hast Du dann nicht gleich Qt verwendet? Die Kombination ist doch 
eigentlich ganz gut. Und GTK ist ja momentan extrem unbeliebt bei 
Anwendern. Manch mal denke ich, dass ich der Einzige bin, der es noch 
verwendet. Community ist ja auch so gut wie tod. Aber gut, einige wenige 
arbeiten im stillen Kämmerlein wohl doch noch an GTK4, vielleicht wird 
GTK dann wieder populärer. Es soll ja immerhin ein Vulkan Backend geben!

Und wenn schon GTK, dann hätte man ja auch eine moderne und schönere 
Sprache nehmen können. Language Bindings gibt es ja reichlich, vom mir 
für GTK3, aber auch für Rust oder Crystal hatte ich welche gesehen. Oder 
aber, man hätte das ganze eher Web-basiert aufziehen können -- davon 
schwärmen ja einige (ich selber weniger). Also Java-Script, HTLM5 oder 
so. Tablet Support.

Du hast OpenCL verwendet -- alle Achtung, dass hatte ich mir damals 
nicht zugetraut. Aber Cairo ist eigentlich auch noch schnell genug -- na 
ja gerade so.

Ja ich werde mir Dein Projekt wahrscheinlich mal ansehen. Falls Du es 
tatsächlich fortführst, künnte ich ja drüber nachdenken, Dein 
Dateiformat zu übernehmen. Momentan verwende ich das gEDA Format, aber 
das gEDA Projekt ist ja wohl auch recht tod. Allerdings, wenn ich 
irgendwann mal daran weiterarbeite, werde ich von Ruby wohl auf Nim 
umsteigen. Abernatürlich gibt es genügend andere interessante Aufgaben.

Autor: Lukas K. (carrotindustries)
Datum:
Angehängte Dateien:

Bewertung
8 lesenswert
nicht lesenswert
Stefan S. schrieb:
> Ja was soll ich sagen? Zunächst sollte ich Dir wohl mal meine
> Anerkennung aussprechen -- Du bist einer der wenigen hier, die mal etwas
> zustande bringen, statt immer nur rumzumosern.

Freut mich sehr auch mal das zu lesen :)

In gewisser maßen kann man horizon als "opinionated software" 
bezeichnen. Horizon ist die Materialisierung eines EDA-Programms, so wie 
ich es mit meiner Erfahrung für richtig und sinnvoll erachte. Dass das 
andere Leute nicht so sehen, ist dann eben so. Allen kann man's eh nie 
recht machen.

Stefan S. schrieb:
> Du kennst ja sicher meinen Schaltplaneditor, den ich vor einigen Jahren
> mal in Ruby programmiert hatte (http://ssalewski.de/PetEd.html.en), und
> auch meinen Toporouter(http://ssalewski.de/Router.html.en). Da war das
> Interesse ja praktisch null.

Leider nicht, aber in der Tat scheint das Interesse der Leute hier an 
nicht-mainstream EDA-Tools im allgemeinen eher gering zu sein. Vor 
einiger Zeit hatte ich hier mal (keine Ahnung warum im Forum "Markt") 
auf PCB elegance aufmerksam gemacht: 
Beitrag "PCB Elegance" Hat genau niemanden 
interessiert.
Ähnlich mit librepcb: Beitrag "librepcb Free Schematic und PCB Editor Erfahrungen Leistungsvergleich" Auf 
das Projekt wurde ich auch erst zufällig auf dem 33C3 aufmerksam.

Stefan S. schrieb:
> Was mich doch etwas wundert: Wenn Du schon in C++ programmieren magst,
> warum hast Du dann nicht gleich Qt verwendet?

Historisch gewachsen. Ich hatte schon seit ca. 5 Jahren GUIs mit Gtk 
programmiert, praktisch nur mit Python und hab hab damit sehr gute 
Erfahrungen gemacht. Horizon hatte ursprünglich als eine Kombination von 
C und python angefangen, wurd' mir dann irgendwann zu doof und ich hab' 
dann C genommen. Das ging gut, bis ich UUIDs durch GObject schieben 
wollte und mir der GObject-Krams zu umständlich erschien.

Dann hatte ich mir mal C++ und Gtkmm angesehen und die Kombination für 
perfekt befunden. Mit Qt hatte ich noch nie wirklich was am Hut, hatte 
aber auch nie das Gefühl, dass mir als Entwickler was bei Gtkmm fehlt. 
Vielleicht auch eine Mischung aus Vendor-Lockin und Stockholm-Syndrom... 
Die Gtk-Entwickler sind im IRC und in bugreports auch durchaus 
hilfreich, kann mich diesbezüglich nicht beschweren.

Persönlich gefallen mir auch die Client-Side decorations von Gtk nach 
anfänglicher Skepsis gut, als Beispiel der Footprint-Generator aus 
horizon im Anhang.

Stefan S. schrieb:
> Language Bindings gibt es ja reichlich, vom mir
> für GTK3, aber auch für Rust oder Crystal hatte ich welche gesehen.
C++ mag zwar ein wenig altbacken wirken, aber mit C++ hat man noch die 
größte Chance Leute zu finden die das auch können. Außerdem ist die 
Nutzerbasis von Gtk-Bindings zu z.B. Rust nochmal geringer, als die von 
Gtkmm.

>Oder
> aber, man hätte das ganze eher Web-basiert aufziehen können -- davon
> schwärmen ja einige (ich selber weniger). Also Java-Script, HTLM5 oder
> so. Tablet Support.
Bloß nicht. Die Frameworks im Web-bereich haben eine gefühlte 
Haltbarkeitszeit von 3 Monaten, danach ist schon wieder das nächste hip. 
Gtk und C++ sind da deutlich gemächlicher.

Stefan S. schrieb:
> Du hast OpenCL verwendet -- alle Achtung, dass hatte ich mir damals
> nicht zugetraut. Aber Cairo ist eigentlich auch noch schnell genug -- na
> ja gerade so.

Eben. OpenGL war mehr so nen Angstreflex, dass später auch mal größere 
Boards halbwegs schnell rendern. Auch dreht die GPU eh größtenteils 
Däumchen, warum die nicht mit Malen vom Grid, Linien mit runden Enden 
und schraffierten Dreiecken beauftragen? Schaden kann's ja nicht und das 
OpenGL-programmieren mit shadern und so macht auch Spaß.

Autor: il Conte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> aber in der Tat scheint das Interesse der Leute hier an
> nicht-mainstream EDA-Tools im allgemeinen eher gering zu sein.

Stefan S. schrieb:
> Du kennst ja sicher meinen Schaltplaneditor, den ich vor einigen Jahren
> mal in Ruby programmiert hatte (http://ssalewski.de/PetEd.html.en), und
> auch meinen Toporouter(http://ssalewski.de/Router.html.en). Da war das
> Interesse ja praktisch null. Oder den Schaltplaneditor, den hier jemand
> vor etwa einem jahr in Jawa präsentiert hatte -- auch null Interesse.

Ihr solltet mal eure Scheukappen bei Seite schieben und mal überlegen
warum das so ist.
Euer Wissen, das ja anscheinend vorhanden ist, könnte man sicherlich
'gewinnbringender' an den Mann bringen.

Autor: Hardy F. (hardyf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
il Conte schrieb:
> Ihr solltet mal eure Scheukappen bei Seite schieben und mal überlegen
> warum das so ist.



... wenn  die Fähigkeit, das Programmieren zu beherrschen, nur mit 
Gleichgesinnten geteilt wird, dann darf man sich nicht beklagen, wenn 
die "Übriggebliebenen" sich leider mangels ebendieser Fähigkeiten 
abwenden...

Wenn man jemandem etwas hinstellt, mit dem er nicht umgehen kann, wird 
er sich damit nicht beschäftigen.

Autor: Michael X. (Firma: vyuxc) (der-michl)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Lukas K. schrieb:

> Leider nicht, aber in der Tat scheint das Interesse der Leute hier an
> nicht-mainstream EDA-Tools im allgemeinen eher gering zu sein. Vor
> einiger Zeit hatte ich hier mal (keine Ahnung warum im Forum "Markt")
> auf PCB elegance aufmerksam gemacht:
> Beitrag "PCB Elegance" Hat genau niemanden
> interessiert.

Doch. Nur ist ein EDA-Tool einfach nur dazu da seine Schaltung mit einer 
Leiterplatte zu verheiraten. Es muß schon einen Grund geben sein bisher 
verwendetes Tool ersetzen zu wollen, da die Einarbeitung bis man mit was 
Neuem produktiv arbeiten kann ganz schön lange dauert. Und Leute die 
wirklich gut programmieren können und richtig gut 
Entwickeln/Entflechten können sind wirklich rar.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Michael X. schrieb:
> Und Leute die wirklich gut programmieren können und richtig gut
> Entwickeln/Entflechten können sind wirklich rar.

Wobei ich die Idee des Toporouters schon mal nett fände.  Weiß ja
nicht, inwiefern man den vielleicht auch mit KiCad verheiraten
könnte?

Ist aber 'ne andere Baustelle, hier geht's um horizon.  Auch, wenn ich
selbst keine Ressourcen frei habe, finde ich die Diskussion darum
allemal interessant und werde hier weiter mitlesen.

Autor: Georg (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Michael X. schrieb:
> Es muß schon einen Grund geben sein bisher
> verwendetes Tool ersetzen zu wollen, da die Einarbeitung bis man mit was
> Neuem produktiv arbeiten kann ganz schön lange dauert.

Das ist nur ein Teil des Problems, wichtiger ist meist die Tatsache, 
dass zahlreiche, u.U. hunderte fertige Layouts existieren, die weiter 
gepflegt werden müssen. Für Elektronik-Firmen ist CAD-Layout eine 
strategische Software, die die Existenz der Firma beeinflussen kann. Es 
kann schon zur Katastophe werden, wenn die BWLer entscheiden, dass die 
Entwickler plötzlich mit anderer Software arbeiten müssen.

Es ist also vernünftig, bei solchen Fragen sehr konservativ zu sein.

Georg

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Georg schrieb:
> Das ist nur ein Teil des Problems, wichtiger ist meist die Tatsache,
> dass zahlreiche, u.U. hunderte fertige Layouts existieren, die weiter
> gepflegt werden müssen.

Kein großes Argument: die Benutzung einer neuen Software zwingt doch
keinen dazu, die alte deswegen gleich zu verschrotten.

Aber Georg, für derartige Entscheidungsfragen ist es bei horizon ganz
gewiss zu früh, ich schätze mal wenigstens 5 Jahre zu früh.  Das ist
jetzt keine Missachtung von Lukas' Leistung, aber er nennt es ja selbst
„halbfertig“.  Erst müsste es also mal fertig werden, und dann noch so
interessant für Platinendesigner werden, dass sie überhaupt drüber
nachdenken, sich in eine weitere Software einzuarbeiten.

Wenn Lukas ein wenig eher damit fertig geworden wäre, hätte er jetzt
vielleicht ein paar angep***ste Adler-Nutzer als willige Betatester
haben können, aber dazu hätte horizon erstmal Beta-Charakter haben
müssen.  So weit ist es wohl noch nicht.

Autor: Stefan S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Wenn Lukas ein wenig eher damit fertig geworden wäre, hätte er jetzt
> vielleicht ein paar angep***ste Adler-Nutzer als willige Betatester
> haben können, aber dazu hätte horizon erstmal Beta-Charakter haben
> müssen.  So weit ist es wohl noch nicht.

Was Du da schreibst gilt aber eher für kommerzielle Software, und ich 
glaube nicht, dass Lukas ersthaft hofft, sein Programm mal teuer 
verkaufen zu können.

Bei EDA-CAD wäre gerade in der frühen Phase, wenn etwa 30 % fertig sind, 
die Mitwirkung anderer sinnvoll und hilfreich -- etwa durch gut 
durchdachte Vorschläge, Problemlösungen, oder womöglich sogar durch 
Programmcode. Wenn alles schon fast fertig ist, dann kann man nicht mehr 
viel ändern, und es bleibt im wesentlichen nur das Mosern.

Aber die breite Masse postet heute eben lieber Fotos von ihrem 
Mittagessen auf Fakebook, sucht Pokemons oder guckt Videos. Und das ist 
auch völlig OK.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan S. schrieb:
> Aber die breite Masse postet heute eben lieber Fotos von ihrem
> Mittagessen auf Fakebook, sucht Pokemons oder guckt Videos.

Jetzt erinnerst du an Sokrates.

> Bei EDA-CAD wäre gerade in der frühen Phase, wenn etwa 30 % fertig sind,
> die Mitwirkung anderer sinnvoll und hilfreich

Nur, dass du in dieser Phase eben noch niemanden da bekommen wirst,
der das wenigstens halbwegs produktiv benutzen will.  Diese Leute
hatte ich als Eagle-Umsteiger im Blick, von denen es gerade ein paar
mehr geben dürfte als zuvor.

Autor: Stefan S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Entwickeln und "produktiv benutzen" sind bei einem größeren 
Softwareprojekt schon sehr verschiedene Sachen. In der Anfangsphase kann 
man Ideen und Problemlösungen einbringen, die Software damit aktiv 
mitgestalten und womöglich Freude daran haben. Produktiv nutzen kann man 
so ein Programm in dieser Phase aber eher nicht, schon gar nicht wenn 
man wirklich Platinen herstellen lässt und auf deren Funktionsfähigkeit 
angewiesen ist. Später, wenn das Programm weitgehend fertig ist, kann 
man es hoffentlich produktiv nutzen, aber dann wird man sich auf 
Fehlerberichte beschränken und hoffen das sie irgendwann behoben werden. 
Letzteres hatte ich lange Jahre bei gEDA beobachtet -- fast alle neuen 
Ideen oder größeren Erweiterungen wurden von einigen Altusern abgelehnt, 
und selbst ohne diese Ablehnung wäre es für Neulinge schwer diese ohne 
Hilfe der ursprünglichen Entwickler zu implementieren.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach Lukas, was mir gerade noch einfällt...

Wie machst Du das mit der Textausgabe in den Gerber-Dateien? Am 
Bildschirm hat man ja zunächst hochwertige Fonts, etwa Truetype oder was 
auch immer, bei mir wäre das Pango-Rendering. Gerber hat ja aber keine 
wirklichen Fonts, man muss also alles durch Linien und Kreisbögen 
darstellen. gEDA/PCB verwendet auch am Bildschirm primitive Fonts, die 
aus Kreisbögen und Linien bestehen, darunter leidet aber die 
Darstellungsqualität. Mein Ansatz wäre gewesen, zunächst echte Fonts zu 
verwenden und die dann in Linien/Kreisbögen für Gerber zu wandeln.

Und noch eine andere Bemerkung: Wenn ich ein C++ Freund wäre, hätte ich 
womoglich auf Qucs mit Qt aufgebaut -- da hätte man Schaltplan- und 
Simulation schon mal, und müsste dann nur noch den Platinenteil machen. 
Hast Du schon über Simulations-Anbindung nachgedacht?

Dein Git-Reposity werde ich mir demnächst ansehen, ich bin mir 
eigentlich sicher dass es sich lohnt, blos momentan ist die Zeit etwas 
knapp...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Salewski schrieb:
> Mein Ansatz wäre gewesen, zunächst echte Fonts zu verwenden und die dann
> in Linien/Kreisbögen für Gerber zu wandeln.

Den Vorteil dieses Ansatzes sehe ich darin, dass man schon alles
für den Bildschirm fix & fertig hat und dass die Geschwindigkeit
dafür optimiert ist.  Der Nachteil ist, dass man eine deutlich
höhere Genauigkeit vorgegaukelt bekommt, als sich am Ende erzielen
lässt.  Man neigt meiner Erfahrung nach dann dazu, viel zu kleine
Schriften zu benutzen.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das ist richtig.

Ergänzung: Vielleicht möchte man ja auf der Platine chinesische oder 
kyrillische Schrift haben. Deshalb denke ich, dass man tatsächlich die 
Wandlung von einer echten hochwertigen Unicode-Schrift am Bildschirm zu 
Linien/Bögen auf Gerber machen sollte. Vielleicht kennt ja jemand eine 
Bibliothek die so etwas schon gut macht?

Ist extended Gerber eigentlich immer noch "State of the Art"? Vor ca. 5 
Jahren war das noch so, ich glaube ich hatte dazu sogar hier mal 
gefragt. Neueres weiß ich dazu aber nicht, aber ich errinnere mich 
dunkel, dass es zwei "modernere" Alternativ-Formate gab.

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Salewski schrieb:
> aber ich errinnere mich
> dunkel, dass es zwei "modernere" Alternativ-Formate gab

Modern muss nicht besser heissen. ODB++ löst zwar manche Probleme, 
andere aber nicht, auch weil sie garnicht lösbar sind - es gibt nun mal 
keine Norm für Lagenbezeichnungen, das macht jeder wie er will, und 
neben üblichen wie "Top" oder "Bestückungsseite" gibt es ungefähr so 
viele wie Layouter. Ausserdem, was heisst bei einer heutigen Schaltung 
überhaupt "BS" oder "Oben"? Und ist die Lage 1 die obere oder die erste 
innen??

Folglich muss der CAD-Mann beim Hersteller selber interpretieren, welche 
Datei im Layerstack wohin gehört, genau wie bei Gerber auch, das ist die 
Hauptarbeit den ganzen Tag über.

Dazu ist ODB++ eine traditioneller Unix-Albtraum, für jedes Objekt wird 
eine eigene Datei in einem bestimmten Verzeichnis angelegt, so dass ein 
Layout mit ODB++ leicht aus tausend kleinen Dateien besteht, 
selbstverständlich ohne Dateiendung, von denen auch unzählige den 
gleichen Dateinamen haben, reisst das mal auseinander, sind alle Daten 
verloren.

Aber du kannst dich ja mal im Netz über ODB++ einlesen.

Georg

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Salewski schrieb:
> Ist extended Gerber eigentlich immer noch "State of the Art"?

An sich schon, es gibt aber eine neuere Spec von Ucamco, die sich
Gerber X2 nennt.

Autor: Alex W. (a20q90)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Sehe ich das richtig das ich zum Testen erst ein mal das Zeug 
compillieren muss?

Autor: Entwiggler (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
So schaut es wohl aus. Das dürfte wohl die beste Abschreckung sein.

Autor: C lover (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan Salewski
Kannst du den Toporouter Algorithmus beschreiben,
so dass man ihn in C nachbauen kann?

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan.

Stefan Salewski schrieb:

> Ergänzung: Vielleicht möchte man ja auf der Platine chinesische oder
> kyrillische Schrift haben. Deshalb denke ich, dass man tatsächlich die
> Wandlung von einer echten hochwertigen Unicode-Schrift am Bildschirm zu
> Linien/Bögen auf Gerber machen sollte. Vielleicht kennt ja jemand eine
> Bibliothek die so etwas schon gut macht?

Schau mal nach dem Cenon Projekt. Die bearbeiten allgemein Vektor 
Formate und darunter auch SVG und Gerber. Die könnten passende 
Bibliotheken entwickelt haben.
http://www.cenon.info

> Ist extended Gerber eigentlich immer noch "State of the Art"?

Grundsätzlich ja. Es gibt zwar mittlerweile ein "X2", aber das ist voll 
rückwärtskompatibel zu extended Gerber. Die einzige Ergänzung sind 
"Attribute"
Desweiteren taucht bei vielen Gerber Elementen in der Ucamco 
Dokumentation der Hinweis auf, dass sie nach Möglichkeit nicht mehr 
verwendet werden sollen. Damit soll Gerber weiter vereinfacht werden.
Trozdem bleiben sie bestehen, damit auf diesen Unterlagen basierende 
Gerber Software immer noch mit alten Daten umgehen kann.

FAQ zu Gerber X2: 
https://www.ucamco.com/files/downloads/file/131/th...
Die z.Z. aktuelle Spezifikation von Gerber X2 Revision 2016.12 ist hier: 
https://www.ucamco.com/files/downloads/file/81/the...


> Vor ca. 5
> Jahren war das noch so, ich glaube ich hatte dazu sogar hier mal
> gefragt. Neueres weiß ich dazu aber nicht, aber ich errinnere mich
> dunkel, dass es zwei "modernere" Alternativ-Formate gab.

Ja, OBD++ und IPC-2581. Ersteres ist aber nicht offen, und zweiteres nur 
halb, was für Austauschformate ein "No-Go" ist.
Desweiteren sind auf XML basierende Verfahren wie IPC-2581 schon wieder 
deutlich komplizierter als Gerber.

Gerber schlägt halt so leicht keiner. Und wenn ich mir unbedingt eine 
Alternative ausdenken müsste, würde ich z.B. eher zu einer Art Lisp 
Notation greifen. ;O)

http://www.mikrocontroller.net/articles/Gerber-Too...

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo C lover.

C lover schrieb:
> @Stefan Salewski
> Kannst du den Toporouter Algorithmus beschreiben,
> so dass man ihn in C nachbauen kann?

Bis er soweit ist, hast Du hier was Lesefutter:

https://pdfs.semanticscholar.org/1003/57a8a958587b...
https://pdfs.semanticscholar.org/91ce/7726d0b103db...
http://citeseerx.ist.psu.edu/viewdoc/download?doi=...

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

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C lover schrieb:
> @Stefan Salewski
> Kannst du den Toporouter Algorithmus beschreiben,
> so dass man ihn in C nachbauen kann?

Besser wohl in C++, weil CGAL benutzt wird, aber mit etwas Mühe geht es 
sicher auch in C.

Du guckst am Besten zunächst mal kurz in die zugrunde liegende 
Doktorarbeit, zumindest in die ersten Kapitel. 
Constrained-Delaunay-Triangulation und Appolonius Graph von CGAL. Und 
der Rest ist eben der Ruby Code, der sollte mit minimalen 
Ruby-Kenntnissen lesbar sein und ist eigentlich schon die vollständige 
Dokumentation, mehr braucht man wirklich nicht. Ich glaube es waren rund 
2k lines of code Ruby, alles recht einfach. Gut bis auf das Sortieren 
der Bahnen von innen nach aussen, das ist so als ob man solche 
Aussteckformen für Kuchenteig sortiert, so dass sie ineinander passen. 
Da habe ich mir wirklich einen abgebrochen, mein räumliches 
Vorstellungsvermögen ist wohl nicht so gut. Mit C wird es natürlich 
etwas mehr Code, die Doktorarbeit sprach von 14k, aber die hatten wohl 
auch nicht CGAL als Grundlage. Übrigens, wenn ich das gleich von Anfang 
an in C probiert hätte, hätte ich das nie in annehmbarer Zeit 
hinbekommen. Aber jetzt die Übertragung von Ruby nach C sollte schon 
möglich sein. Die Frage wäre ob man es gleich komplett portiert, oder in 
Teilen. Weiss ich nicht. Nach Nim würde ich es komplett Portieren, ich 
kenne mich mit Ruby und Nim etwas aus, da ist das keine große Sache. 
Blos ich müsste die Bindings für Nim zu CGAL machen, auch keine große 
Sache, aber ich habe keine Lust momentan. Das sparst Du Dir mit C oder 
C++.

Noch eine Warnung: Der Toporouter verträgt sich ganz schlecht mit 
bereits manuell gerouteten Bahnen. Das war der Haupt-Kritikpunkt der 
gEDA-Leute. Deshabl macht es auch nicht viel Sinn den Router als 
externes Programm einzusetzten, man müsste ihn schon in ein PCB-Programm 
einbinden, so dass man dann interaktiv Bauteile verschieben kann, so 
dass der Router alles fertig bekommt. Ein paar weitere Gedanken mag man 
auf der gEDA Mailingliste im Archiv finden, ich habe viele Details schon 
wieder etwas vergessen und errinnere mich gerade so Stück für Stück 
wieder...

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo Georg.

Georg schrieb:

> Es ist allerdings fragwürdig, die überwiegende Mehrheit der CAD-Benutzer
> von vornherein vom Testen auszuschliessen. Aber für Linux-Fanatiker ist
> das natürlich konsequent.

Der Grund, dafür Linux zu nehmen ist wohl eher der, dass sich dort 
leichter etwas entwickeln lässt.

Und in dem Stadium können das eigentlich auch nur Leute testen, die weit 
genug wären, selber daran zu programmieren.

>
> Der grundlegende Irrtum ist wohl, dass man eine abgeschottete
> Linux-Brüderschaft als "Kunden" sieht, und nicht Leute, die
> Leiterplatten entwerfen. Muss aber jeder Entwickler selber wissen. Nur
> nicht später wundern, wenn keiner das Programm benutzt.

Wer open source macht, hat in dem Sinne keine "Kunden". Und bei open 
source Nutzern sind viele mit Linux Kenntnissen. ;O)

Und bei ser viel kommerzieller Software sehe ich, dass als "Kunde" der 
Entscheider betrachtet wird, der das Zeug kauft, und nicht der, der 
damit umgehen muss. ;O)

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

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd W. schrieb:
> Lesefutter

Die erste Arbeit kannte ich gar nicht.

Aber das entscheidende Werk ist die Arbeit von Tal Dayan von 1997. 
Übrigens, ich habe nicht wirklich alles verstanden, insbesondere nicht 
wie das Ripup and Retry funktionieren könnte.

Übrigens, einen alternativen Toporouter gab es ja in gEDA/PCB, war als 
Google Summer als Code Project um 2008 gemacht, gleich in C. Hat 
Ansatzweise funktioniert, hat aber niemand verstanden, und der Autor war 
dann schnell wieder weg. Der Code ist wohl noch in gEDA/PCB, soll aber 
entfernt werden, da damit niemend zurecht kommt.

Autor: Helmut S. (helmuts)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Der entscheidende Teil damit ein neues Layoutprogramm überhaupt 
angenommen wird ist garantiert nicht der Autorouter egal ob das Ding 
Topo, Gridless,  "Freestyle" oder sonstwas heißt bzw. kann. Mir scheint, 
dass die Programmierer lieber so einen Autorouter schreiben da man da 
viel weniger Schnittstellen zur Außenwelt hat und sich nicht mit den 
Wünschen der Anwender auseinandersetzen muss.


Viel wichtiger sind die folgenden Punkte die leicht erlernbar und 
bedienbar sein müssen.

Schaltplansymbole erstellen; Bibliotheken

Schaltplaneingabe

Bauteile für das Layout aufsetzen (pads, drills, ...); Bibliotheken

Bauteile platzieren

Verdrahten: Leitungen ziehen, schieben abknicken, 45°; Flächen zeichnen, 
Flächen füllen;  online DRC,....

Gerber Ausgabe

Autor: Georg (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Bernd W. schrieb:
> Und bei ser viel kommerzieller Software sehe ich, dass als "Kunde" der
> Entscheider betrachtet wird, der das Zeug kauft

Aber das ist doch auch genau richtig - ich habe es schon erlebt, dass 
die Entwickler sich vollkommen eindeutig nach sorgfältiger Evaluation 
für eine bestimmte Software entschieden haben, aber eine ganz andere 
gekauft wurde, weil die Geschäftsführer mit den Managern des Herstellers 
zusammen Golf spielten. Das war in dem speziellen Fall nicht nur sowieso 
eine Katastrophe, sondern die Software wurde im folgenden Jahr 
eingestellt und so waren einige Millionen in den Sand gesetzt.

Aber egal was man davon hält, man muss sich danach richten, wie beim 
Kunden die Entscheidungen getroffen werden, auch wenn das absurd oder 
auch völlig korrupt ist. Dem Ingenieur kann man nichts verkaufen.

Georg

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut S. schrieb:
> Mir scheint,
> dass die Programmierer lieber so einen Autorouter schreiben da man da
> viel weniger Schnittstellen zur Außenwelt hat und sich nicht mit den
> Wünschen der Anwender auseinandersetzen muss.

Ja sicher. Man macht halt das, womit man seinen Lebensunterhalt 
verdient, oder das, was interessant ist und was man sich noch halbwegs 
zutraut. Nur selten fällt beides zusammen. Manchmal macht man auch öde 
Dinge unentgeltlich, weil man denkt dass sie für die Allgemeinheit 
nützlich sind oder Leute danach fragen -- aber letzteres trifft auf den 
EDA-Bereich weniger zu, Eagle oder KiCad ist den meisten gut genug.

Autor: C lover (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich würde es in ein bestehendes PCB Programm einfügen,
programmiert in C++, 82% ist aber C mit gplv2 Lizenz, nur v2, keine v2+ 
.

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Georg.

Georg schrieb:

>> Und bei ser viel kommerzieller Software sehe ich, dass als "Kunde" der
>> Entscheider betrachtet wird, der das Zeug kauft, und nicht der, der
>> damit umgehen muss. ;O)

> Aber das ist doch auch genau richtig -
~~~~
~~~
~~
~
> Aber egal was man davon hält, man muss sich danach richten, wie beim
> Kunden die Entscheidungen getroffen werden, auch wenn das absurd oder
> auch völlig korrupt ist.

Eben. Und open Source hat in dem Sinne halt keine "Kunden". Ser viel 
open Source wird aus Spass geschrieben, weil man es mal endlich so 
machen möchte, wie man es selber für richtig hält, oder open Source wird 
aus Verzweiflung und mit einem "dicken Hals" geschrieben, weil man sich 
über den gekauften Kram geärgert hat oder man einfach nichts passendes 
findet.

Letzteres kann durchaus der Fall sein, wenn die Anwendung so speziell 
ist, das kein Markt existiert. Das kommt öfter vor als man denkt.

Letztendlich ist man damit selber sein eigener "Kunde" und Entscheider. 
;O)

Und aus allen den Gründen ist die Funktionalität von kommerzieller 
Software nur sehr bedingt ein Masstab für open Source, auch wenn vieles 
halt ähnlich ist.

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

: Bearbeitet durch User
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut S. schrieb:
> Mir scheint,
> dass die Programmierer lieber so einen Autorouter schreiben da man da
> viel weniger Schnittstellen zur Außenwelt hat und sich nicht mit den
> Wünschen der Anwender auseinandersetzen muss.

Was soll diese Bemerkung denn eigentlich im Kontext dieses Threads
bedeuten?  Hier geht's um "horizon", und dafür ist dein Kommentar
wohl völlig daneben.  Das kümmert sich just um die Dinge, die du
da genannt hast, zumindest bereits zu einem großen Teil (und nennt
sich ja selbst nur „halbfertig“).

Der Topo-Router würde mich als externe Engine für ein KiCad wohl
schon interessieren, da könnte einem auch die Programmiersprache
egal sein – aber das gehört dann nicht mehr in diesen Thread.

BTT: habe mir mal einen GCC 5.x installiert und versucht, das Teil auf
meinem FreeBSD zu compilieren.  Allerdings kommen da nicht nur
Warnungen, sondern an vielen Stellen noch Fehlermeldungen des Compilers.
Meine C++-Kenntnisse sind vermutlich nicht gut genug um einzuschätzen,
ob dabei das eigentliche Problem in meiner Umgebung zu suchen ist oder
im Code von "horizon".  Lukas, wenn es dich interessiert, kann ich das
Buildlog mal hochladen.

Ein Beispiel, welches ich jetzt schon mehrmals gesehen habe:
./json.hpp:10455:51: error: 'to_string' is not a member of 'std'
                             {"path", path + "/" + std::to_string(i)},

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Was soll diese Bemerkung denn eigentlich im Kontext dieses Threads
bedeuten?  Hier geht's um "horizon", und dafür ist dein Kommentar
wohl völlig daneben.

Der Thread gleitet hier im Moment in Richtung Autorouter. Hier geht es 
aber nicht um einen Autorouter sonder um Horizon, ein neues 
Layout-Programm. Da ist der Autorouter nur ein kleiner Teil davon und 
der wird erst interessant, wenn alles andere fertig ist und Anhänger 
gefunden hat. Macht doch einen Extra-Thread auf mit dem Thema ich 
schreibe einen Autorouter.

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> BTT: habe mir mal einen GCC 5.x installiert und versucht, das Teil auf
> meinem FreeBSD zu compilieren.  Allerdings kommen da nicht nur
> Warnungen, sondern an vielen Stellen noch Fehlermeldungen des Compilers.
> Meine C++-Kenntnisse sind vermutlich nicht gut genug um einzuschätzen,
> ob dabei das eigentliche Problem in meiner Umgebung zu suchen ist oder
> im Code von "horizon".
>
> Ein Beispiel, welches ich jetzt schon mehrmals gesehen habe:
>
>
> ./json.hpp:10455:51: error: 'to_string' is not a member of 'std'
>                              {"path", path + "/" + std::to_string(i)},
> 

Eigentlich gehört die Funktion to_string() seit C++11 zum Namensraum 
std:

  http://de.cppreference.com/w/cpp/string/basic_stri...

Da das Makefile allerdings "-std=c++14" vorgibt, ist der Fehler 
zumindest etwas merkwürdig. Wie sieht denn der Compileraufruf vor dem 
Fehler aus?

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne jetzt die einzelnen Leute zu zitieren:

Als Font nehme ich die Hershey-Fonts: 
http://paulbourke.net/dataformats/hershey/ Da sind durchaus auch 
nicht-ASCII Zeichen drin, nur sind die älter als Unicode, d.h. man muss 
die Zuordnung von Codepoint zu index manuell machen: 
https://github.com/carrotIndustries/horizon/blob/m... 
Truetype-Fonts mache ich aus von Jörg angesprochenen Gründen nicht.

Autorouter sind gleichauf mit Simulation "out of scope" für mich, stehen 
also auf keinerlei (imaginären) Roadmap. Bevor man an sowas überhaupt 
denkt, braucht man wichtigere Dinge wie, ERC, DRC oder mehr GUI.


Bauen auf Freebsd: Man hat mir gesagt, dass das mit der libc++ von 
FreeBSD zusammenhängt. Probier mal 
http://stackoverflow.com/questions/35869206/freebs...

Wenn's das repariert, bau ich das so in die Makefile ein.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Als Font nehme ich die Hershey-Fonts:

Das ist ein interessanter Kompromiss!

Ich vermute mal, für den übrigen Text, der nicht auf der Leiterplatte 
erscheinen wird, benutzt Du einen echten Font?

DRC hast Du also noch nicht? Für Liniensegmente ist das ja wohl noch 
einfach, aber ich wüsste so spontan nicht, wie man das für Kreisbögen 
effizient macht, insbesondere wenn die Bogensegmente auch noch unter 
einem beliebigen Winkel gedreht sind.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Stefan Salewski schrieb:
> Lukas K. schrieb:
>> Als Font nehme ich die Hershey-Fonts:
>
> Das ist ein interessanter Kompromiss!
>
> Ich vermute mal, für den übrigen Text, der nicht auf der Leiterplatte
> erscheinen wird, benutzt Du einen echten Font?
Nein. Truetype=Fonts machen unter Umständen Probleme bei der Skalierung 
und sind schwerer zu rendern. Und so unansehnlich sind die Hershey-Fonts 
nun auch nicht.

> DRC hast Du also noch nicht? Für Liniensegmente ist das ja wohl noch
> einfach, aber ich wüsste so spontan nicht, wie man das für Kreisbögen
> effizient macht, insbesondere wenn die Bogensegmente auch noch unter
> einem beliebigen Winkel gedreht sind.

Bögen hab' ich derzeit nicht. Für Polygon-Operationen (online-drc) 
verwende ich http://www.angusj.com/delphi/clipper.php.

Eigentlich ist DRC ganz einfach: Alles Kupfer auf einem Layer 
einsammeln, nach Netzen gruppieren, das zu testende Netz um die 
Clearance expandieren und mit den übrigen Netzen schneiden. Der ganze 
algorithmisch schwere teil ist schon in clipper gelöst.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:

> Eigentlich gehört die Funktion to_string() seit C++11 zum Namensraum
> std:
>
>   http://de.cppreference.com/w/cpp/string/basic_stri...
>
> Da das Makefile allerdings "-std=c++14" vorgibt, ist der Fehler
> zumindest etwas merkwürdig. Wie sieht denn der Compileraufruf vor dem
> Fehler aus?
g++5 -c -I. -Iblock -Iboard -Icommon -Iimp -Ipackage -Ipool -Ischematic -Iutil -Iconstraints -g3 -D_USE_MATH_DEFINES -fdata-sections -ffunction-sections -I/usr/local/include -I/usr/local/include/uuid -I/usr/local/include/gtkmm-3.0 -I/usr/local/lib/gtkmm-3.0/include -I/usr/local/include/atkmm-1.6 -I/usr/local/include/atk-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/glibmm-2.4 -I/usr/local/lib/glibmm-2.4/include -I/usr/local/include/sigc++-2.0 -I/usr/local/lib/sigc++-2.0/include -I/usr/local/include/giomm-2.4 -I/usr/local/lib/giomm-2.4/include -I/usr/local/include/pangomm-1.4  -I/usr/local/lib/pangomm-1.4/include -I/usr/local/include/cairomm-1.0 -I/usr/local/lib/cairomm-1.0/include -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2    -I/usr/local/include/freetype2 -I/usr/local/include/libdrm -I/usr/local/include/libpng16 -I/usr/local/include/pango-1.0 -I/usr/local/include/harfbuzz -I/usr/local/include/gtk-3.0 -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/gio-unix-2.0/ -I/usr/local/include/at-spi2-atk/2.0 -I/usr/local/include/at-spi-2.0 -I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include -I/usr/local/include/gtk-3.0/unix-print -I/usr/local/include/gdkmm-3.0 -I/usr/local/lib/gdkmm-3.0/include -I/usr/local/include/librsvg-2.0 -pthread -D_THREAD_SAFE   -MP -MMD -pthread -Wall -Wshadow -std=c++14 pool/unit.cpp -o pool/unit.o
In file included from pool/unit.cpp:3:0:
./json.hpp: In member function 'nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::at(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::size_type)':
./json.hpp:3163:58: error: 'to_string' is not a member of 'std'
                 throw std::out_of_range("array index " + std::to_string(idx) + " is out of range");
                                                          ^
./json.hpp: In member function 'const value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::at(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::size_type) const':
./json.hpp:3206:58: error: 'to_string' is not a member of 'std'
                 throw std::out_of_range("array index " + std::to_string(idx) + " is out of range");
                                                          ^
./json.hpp: In member function 'void nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::erase(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::size_type)':
./json.hpp:4176:58: error: 'to_string' is not a member of 'std'
                 throw std::out_of_range("array index " + std::to_string(idx) + " is out of range");
                                                          ^
./json.hpp: In member function 'nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::string_t nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::iteration_proxy<IteratorType>::iteration_proxy_internal::key() const':
./json.hpp:6649:32: error: 'to_string' is not a member of 'std'
                         return std::to_string(array_index);
                                ^
./json.hpp: In member function 'long double nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::lexer::str_to_float_t(long double*, char**) const':
./json.hpp:8820:20: error: 'strtold' is not a member of 'std'
             return std::strtold(reinterpret_cast<typename string_t::const_pointer>(m_start), endptr);
                    ^
./json.hpp:8820:20: note: suggested alternative:
In file included from /usr/local/lib/gcc5/include/c++/cstdlib:72:0,
                 from /usr/local/include/boost/assert.hpp:83,
                 from /usr/local/include/boost/smart_ptr/shared_ptr.hpp:29,
                 from /usr/local/include/boost/shared_ptr.hpp:17,
                 from /usr/local/include/yaml-cpp/node/ptr.h:11,
                 from /usr/local/include/yaml-cpp/node/node.h:17,
                 from /usr/local/include/yaml-cpp/yaml.h:16,
                 from pool/unit.hpp:5,
                 from pool/unit.cpp:1:
/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd10.0/5.3.0/include-fixed/stdlib.h:127:3: note:   'strtold'
   strtold(const char * __restrict, char ** __restrict);
   ^
In file included from pool/unit.cpp:3:0:
./json.hpp: In member function 'float nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::lexer::str_to_float_t(float*, char**) const':
./json.hpp:8860:20: error: 'strtof' is not a member of 'std'
             return std::strtof(reinterpret_cast<typename string_t::const_pointer>(m_start), endptr);
                    ^
./json.hpp:8860:20: note: suggested alternative:
In file included from /usr/local/lib/gcc5/include/c++/cstdlib:72:0,
                 from /usr/local/include/boost/assert.hpp:83,
                 from /usr/local/include/boost/smart_ptr/shared_ptr.hpp:29,
                 from /usr/local/include/boost/shared_ptr.hpp:17,
                 from /usr/local/include/yaml-cpp/node/ptr.h:11,
                 from /usr/local/include/yaml-cpp/node/node.h:17,
                 from /usr/local/include/yaml-cpp/yaml.h:16,
                 from pool/unit.hpp:5,
                 from pool/unit.cpp:1:
/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd10.0/5.3.0/include-fixed/stdlib.h:124:8: note:   'strtof'
 float  strtof(const char * __restrict, char ** __restrict);
        ^
In file included from pool/unit.cpp:3:0:
./json.hpp: In member function 'nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::get_and_create(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::reference) const':
./json.hpp:9419:77: error: 'stoi' is not a member of 'std'
                         result = &result->operator[](static_cast<size_type>(std::stoi(reference_token)));
                                                                             ^
./json.hpp: In member function 'nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::get_unchecked(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::pointer) const':
./json.hpp:9511:75: error: 'stoi' is not a member of 'std'
                             ptr = &ptr->operator[](static_cast<size_type>(std::stoi(reference_token)));
                                                                           ^
./json.hpp: In member function 'nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::get_checked(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::pointer) const':
./json.hpp:9545:53: error: 'to_string' is not a member of 'std'
                                                     std::to_string(ptr->m_value.array->size()) +
                                                     ^
./json.hpp:9556:63: error: 'stoi' is not a member of 'std'
                         ptr = &ptr->at(static_cast<size_type>(std::stoi(reference_token)));
                                                               ^
./json.hpp: In member function 'const value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::get_unchecked(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::const_pointer) const':
./json.hpp:9597:53: error: 'to_string' is not a member of 'std'
                                                     std::to_string(ptr->m_value.array->size()) +
                                                     ^
./json.hpp:9608:71: error: 'stoi' is not a member of 'std'
                         ptr = &ptr->operator[](static_cast<size_type>(std::stoi(reference_token)));
                                                                       ^
./json.hpp: In member function 'const value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::get_checked(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::const_pointer) const':
./json.hpp:9641:53: error: 'to_string' is not a member of 'std'
                                                     std::to_string(ptr->m_value.array->size()) +
                                                     ^
./json.hpp:9652:63: error: 'stoi' is not a member of 'std'
                         ptr = &ptr->at(static_cast<size_type>(std::stoi(reference_token)));
                                                               ^
./json.hpp: In static member function 'static void nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::flatten(const string&, const nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>&, nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>&)':
./json.hpp:9799:62: error: 'to_string' is not a member of 'std'
                             flatten(reference_string + "/" + std::to_string(i),
                                                              ^
./json.hpp: In lambda function:
./json.hpp:10178:46: error: 'stoi' is not a member of 'std'
                             const auto idx = std::stoi(last_path);
                                              ^
./json.hpp:10182:74: error: 'to_string' is not a member of 'std'
                                 throw std::out_of_range("array index " + std::to_string(idx) + " is out of range");
                                                                          ^
./json.hpp: In lambda function:
./json.hpp:10226:53: error: 'stoi' is not a member of 'std'
                 parent.erase(static_cast<size_type>(std::stoi(last_path)));
                                                     ^
./json.hpp: In static member function 'static nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType> nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::diff(const nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>&, const nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>&, const string&)':
./json.hpp:10427:82: error: 'to_string' is not a member of 'std'
                         auto temp_diff = diff(source[i], target[i], path + "/" + std::to_string(i));
                                                                                  ^
./json.hpp:10444:51: error: 'to_string' is not a member of 'std'
                             {"path", path + "/" + std::to_string(i)}
                                                   ^
./json.hpp:10455:51: error: 'to_string' is not a member of 'std'
                             {"path", path + "/" + std::to_string(i)},
                                                   ^

Das wäre der erste Fehler, bei dem "make" anhält.  Bei "make -k" rennt
er zwar insgesamt weiter, stolpert aber immer wieder über sowas.

: Bearbeitet durch Moderator
Autor: Hardy F. (hardyf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Eigentlich gehört das Thema in die Programmiererecke verschoben.

So richtig sehe ich hier nichts mehr von "Platinen".....

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hardy F. schrieb:
> Eigentlich gehört das Thema in die Programmiererecke verschoben.

Man könnte es auch nach "Projekte & Code" schieben.

Gibt es Meinungen, wo es sinnvoller wäre?

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Man könnte es auch nach "Projekte & Code" schieben.

Das wollte ich auch schon anmerken. Nachdem ich diesen Thread zum ersten 
mal gesehen hatte, hatte ich ein paar Tage später Probleme ihn zu 
finden, ich hatte mir schon gedacht, Lukas hätte ihn ob blöder 
Kommentare wieder gelöscht!

Übrigens, den Thread mit dem Java Schaltplaneditor kann ich auch nicht 
wieder finden, muss gut ein jahr her sein. An den Namen des Tools kann 
ich mich nicht errinnern.

Eigentlich müsste man solche Projekte im Wiki sammeln!

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Salewski schrieb:
> Eigentlich müsste man solche Projekte im Wiki sammeln!

Es gibt doch einen Artikel Schaltplaneditoren.  Da spräche doch
nichts dagegen, am Ende eine Liste mit Links auf entsprechende
Threads einzufügen.

Edit: Habe mit einem Link auf diesen Thread begonnen.  Wer noch weitere
Threads kennt, möge sie einfach einfügen.

: Bearbeitet durch Moderator
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Eigentlich gehört die Funktion to_string() seit C++11 zum Namensraum
> std:

OK, nachdem ich das hier ergugelt habe:

http://www.bsdforen.de/threads/problem-gcc-and-std...

sieht es mir mittlerweile einfach so aus, als wäre GCC völlig
glibc-zentrisch geworden.  Die vielen _GLIBCXX_VISIBILITY() in den
vom GCC installierten Headern weisen auch alle in diese Richtung.

Daher habe ich mir clang 3.8 installiert und benutzt.  Nun kommen
wenigstens keine Trivialitäten mehr als Fehler raus.  Anbei das
Buildlog eines "gmake -k".

Es sind eine ganze Reihe davon dabei:
In file included from util/uuid.hpp:8:
In file included from /usr/include/c++/v1/iostream:38:
In file included from /usr/include/c++/v1/ios:216:
In file included from /usr/include/c++/v1/__locale:15:
In file included from /usr/include/c++/v1/string:439:
In file included from /usr/include/c++/v1/algorithm:626:
/usr/include/c++/v1/utility:294:15: error: no viable overloaded '='
        first = __p.first;
        ~~~~~ ^ ~~~~~~~~~

Da sind Verweise auf die FreeBSD-Headers drin, möglicherweise sind
diese zu alt?  Vielleicht ließe sich aber auch ein Workaround finden?

Es gibt aber auch eine Reihe anderer Dinge, die mir schon Probleme in
horizon zu sein scheinen.  Vielleicht will Lukas ja mal einen Blick
reinwerfen.  Kann mir vorstellen, dass ein clang unter Linux die
genauso anmeckern würde.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese Fehler kommen Wohl daher, dass einige der in der map gespeicherten 
Felder const sind.

Unabhängig davon braucht horizon mindestens Gtkmm 3.18. Aus 
unerfindlichen Gründen ist Gtk 3.18 zwar in den Freebsd-ports, Gtkmm 
aber nur in 3.16...

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das Java-Tool dann doch noch mit google gefunden:

Beitrag "HobbyCi Schaltplan Entwicklungsprogramm"

Ist doch schon zwei Jahre her, und war wohl, wie ich bereits vermutet 
hatte, eher ein Osterferienprojekt.

Aber wer mag kann es ja auch im Wiki eintragen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Diese Fehler kommen Wohl daher, dass einige der in der map gespeicherten
> Felder const sind.

Siehst du da eine Abhilfe?

> Unabhängig davon braucht horizon mindestens Gtkmm 3.18. Aus
> unerfindlichen Gründen ist Gtk 3.18 zwar in den Freebsd-ports, Gtkmm
> aber nur in 3.16...

Der Port wird vom gnome-Team bei FreeBSD gepflegt.  Ich kann mir
vorstellen, dass man da mit Upgrades vorsichtig ist, um nicht das
gesamte Gnome komplett nachziehen zu müssen.

Da ich Gnome nicht als Desktop-Umgebung benutze, riskiere ich nicht
sehr viel, wenn ich mal einen Upgrade von gtkmm versuche.

Edit: naja, man hätte es sich denken können:
Package dependency requirement 'giomm-2.4 >= 2.46.1' could not be satisfied.
Package 'giomm-2.4' has version '2.44.0', required version is '>= 2.46.1'
Package dependency requirement 'pangomm-1.4 >= 2.38.1' could not be satisfied.
Package 'pangomm-1.4' has version '2.36.0', required version is '>= 2.38.1'
Package dependency requirement 'cairomm-1.0 >= 1.12.0' could not be satisfied.
Package 'cairomm-1.0' has version '1.10.0', required version is '>= 1.12.0'

Das zöge dann eine größere Update-Orgie nach sich, da habe ich gerade
nicht die Zeit dafür.

Eventuell kann ich das mal in einem Jail probieren (lightweight VM).

: Bearbeitet durch Moderator
Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Siehst du da eine Abhilfe?

Die Felder nicht-const machen. Tut der Anwendung als solcher keinen 
Abbruch, ist aber unschön.

Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael B. schrieb:
> AutoTrax macht beispielsweise eigentlich alles richtig, schönes
> Programm, alles möglich dabei, nicht zu teuer. Und bekommt trotzdem seit
> 10 Jahren keinen Fuss an den Boden.
>
>  https://dexpcb.com/

Hmm.

Download kostenlos ... alles außer Gerber Export ...
Kompatibel mit Windows (Liste von Windows-Versionen)

Das ist die komischste Variante von "macht beispielsweise eigentlich 
alles richtig" die ich seit langem gesehen habe. Wenn ich bereit wäre, 
für EDA auf Windows zurück zu gehen, dann hätte ich aber ganz andere 
Auswahl. Will ich aber gar nicht. Genauso wenig, wie ich die Postkutsche 
als Alternative zum ICE in Betracht ziehe ...


Ach so, zurück zum Thema ...

OpenGL zwingend für ein EDA? GTK und & Freunde in einer "blutige Kante" 
Version? Nein, danke.

Wirklich. Ich brauche meine Kiste hier zum arbeiten. Sind die bleeding 
edge features von GTK & Co wirklich notwendig? Kann ich mir irgendwie 
nicht so recht vorstellen. Und andererseits ist mein Leidensdruck gar 
nicht mal besonders hoch. pcb funktioniert prima für meine Bedürfnisse.

Versteh mich recht: ich bin Neuem gegenüber eigentlich recht 
aufgeschlossen. Aber das Problem ist nicht so sehr ein Mangel an 
EDA-Systemen, als vielmehr die Unzahl an (selbstredend zueinander 
inkompatiblen) Nischenlösungen. Ein weiteres Produkt in einer weiteren 
Nische erscheint mir daher wenig verlockend.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:

> OpenGL zwingend für ein EDA?

Ist bei KiCad am Ende auch so.  Naja, man kann dort auch den
Cairo-Renderer noch nehmen, aber der ist langsamer.

Ich stecke da nicht drin, aber OpenGL scheint außer 3D eben auch im
2D-Bereich einige Nettigkeiten gegenüber Standard-X11 zu bieten zu
haben (shading und dergleichen).

> GTK und & Freunde in einer "blutige Kante"
> Version?

Vielleicht könnte Lukas ja hier ein bisschen erzählen, was seine
Motivation ist.

Aber: das ist ja im Moment (bezüglich der Anwender) noch reiner
Entwicklungs-Vorlauf.  Dahingehend finde ich es nicht grundsätzlich
daneben, mit vergleichsweise „moderner Technik“ ins Rennen zu gehen,
denn man kann getrost davon ausgehen, dass das in zwei, drei Jahren
dann bei den potenziellen Anwendern in der Tat Standard sein wird.
CAD/EDA macht man ja nun seit jeher nicht gerade auf der letzten
Kiste, die gerade noch irgendwo in der Ecke zu finden ist.

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es auch eine downloadbare ausführbare Datei für Win und Linux? Ich 
will nicht anfangen zu compilieren, nur um es zu testen!

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Alex W. schrieb:
> Gibt es auch eine downloadbare ausführbare Datei für Win und Linux? Ich
> will nicht anfangen zu compilieren, nur um es zu testen!
Geduld, mein lieber. Ich bin gerade am Projekt-Manager, wenn der 
halbwegs fertig ist, gibt es auch eine Executable auf die man 
doppelklicken kann und was sinnvolles geschieht. Für Windows sollt's 
dann sogar für 'ne mit NSIS zusammengeklickte setup.exe reichen.
Binaries für Linux gibt's von mir nicht, da solche unüblich sind und eh 
immer gegen die falschen Bibliotheken linken. Git pull und make sollten 
nun für den durchschnittlichen Linux-user auch keine schwarze Magie 
sein...

Betreffend OpenGL und Gtk:

Kicad verwendet im Gegensatz zu horizon die veraltete OpenGL API mit 
glBegin/glEnd. Funktioniert zwar überall, wird dies auch auf absehbare 
Zeit tun, aber ist eben obsolet und wird auch von Gtk nicht unterstützt. 
OpenGL in Version 3 haben wir nun auch schon seit über 5 Jahren, wird 
Zeit, dass das auch eingesetzt wird. Bleeding edge wär's wenn ich Vulkan 
verlangen würde...
Warum nicht auf der CPU mit cairo oder so malen? In jedem Computer 
steckt eine Grafikkarte die genau für so Dinge wie Polygone malen, etc 
da ist. Wär' ja schade, wenn die sich langweilt.

Gtk 3.18 gibt's auch schon seit über einem Jahr, auch nicht mehr 
bleeding edge. Wie auch schon von Jörg angesprochen, horizon ist ein 
Projekt für die Zukunft, insofern ist es nur richtig mit nicht-obsoleter 
Technik anzufangen.

Warum Gtk und nicht Qt? (alles andere muss nicht wirklich sein) Mir 
gefällt die Art, wie die Entwickler von Gtk (und Gnome) über UI-Schemata 
von Windows 95 hinausdenken und dabei einen gelungene Kombination aus 
Konzepten aus dem Mobile- und Desktop-Umfeld finden.
Mag nicht jedermanns Geschmack sein, ich mag's.

Autor: Max G. (l0wside) Benutzerseite
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Mag sein. Das stört Lukas aber nicht, und es ist sein Projekt. Wer 
bleeding edge haben will (und das ist sein Projekt), sollte sich daran 
nicht stören.
Es verbietet übrigens m.W. niemand, .deb- oder .rpm-Packages zu bauen 
und zur Verfügung zu stellen. Nein, ich tue es nicht, keine Zeit.

Autor: Robin R. (elec-lisper)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Git pull und make sollten
> nun für den durchschnittlichen Linux-user auch keine schwarze Magie
> sein...

Als Softwareentwickler sollte ich dem eigentlich nur zustimmen können.
Aber es ist eben nicht nur "git pull" und dann einfach "make"
in das Terminal kloppen. Man muss schon wissen was man tut wenn es
Probleme gibt. Meine Frau würde ich als "durschnittlichen" Linux-user
bezeichnen. Sie hat Linux gute 10 Jahre als Anwender benutzt
(sie hat es sogar selbstständig ohne mein Wissen installiert).
Ein Tutorial für einen trivialen Build-Prozess hätte sie auch ohne
Probleme durchgearbeitet bekommen. Aber sobald da Abhängigkeiten
dazu kommen, die man installieren muss, und wissen muss,
dass Gtk1 != Gtk2 != Gtk3 != Qt begibt man sich als "durchschnittlicher"
doch schnell aufs Glatteis. Und wenn dann noch ein Compiler-Fehler dazu
kommt, und man mangels Verständnis rätselraten muss woher das Problem
wohl kommen mag, dann ist auch dem letzten 0815-Anwender die Laune 
vergangen.
Unter Anleitung ist das alles kein Problem, aber wenn man sonst 
niemanden
hat den man direkt fragen kann und der die Zeit hat sich mit einem 
hinzusetzen,
ist das alles nix.

Als fortgeschrittener Softwareentwickler überschätzt man meist auch 
seine
Kollegen. Ich seh doch schon wie meine Kollegen auf Arbeit von 
weitergehenden
Funktionalitäten von SVN (Also bspw. mal das Tortoise-Diff-Tool 
aufrufen,
oder ein Tag setzen, oder ein Update auf eine spezifische Revision 
machen)
überfordert sind. Das betrifft nicht nur meine 50+ Kollegen, sondern 
auch
den einen frischen Uni-Abgänger. Das ist breit gestreut, viele unserer
FH/Uni-Praktikanten sind extrem fähig. Die kennen sich zum Teil auch 
bestens
mit Github aus und können sich fix in neues einarbeiten. Ist aber alles
meiner Erfahrung nach sehr individuell und breit gestreut.

: Bearbeitet durch User
Autor: Cyblord ---- (cyblord)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Binaries für Linux gibt's von mir nicht, da solche unüblich sind und eh
> immer gegen die falschen Bibliotheken linken. Git pull und make sollten
> nun für den durchschnittlichen Linux-user auch keine schwarze Magie
> sein...

Völlig korrekt. Bin ganz deiner Meinung. Ich finde es bei Linux grade so 
gut dass es da nicht überall Binaries gibt sondern man immer selber 
bauen kann.

Autor: Nop (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Zwei Hinweise:

a) sollte -Wall enabled sein, das ist lobenswerterweise im Makefile der 
Fall. Ich würde aber ruhig noch -Werror dazusetzen.

b) check den Source mal mit CppCheck. Da kommen Tonnen von Warnungen. 
Idealerweise sollte da gar nichts kommen, und bei den Dingen, die 
wirklich so gehören, sollte in der Projektdokumentation (später!) 
begründet werden, wieso diese Warnungen trotzdem OK sind.

c) das sind eine Menge an Abhängigkeiten von verschiedenen Autoren. Das 
wird noch viel Arbeit mit Build, Troubleshooting und Wartung werden, 
wenn es mehr als "auf meinem Rechner läuft's ja" werden soll. Da sollte 
man sich frühzeitig Gedanken um die Versionsverwaltung der Gesamtkette 
machen.

d) Doku: wenn ich im Readme lese: "To explain horizon's operation it's 
best to start with the library structure:", ist das ein Warnzeichen. 
Klar, die Erklärung, wie das Programm intern arbeitet, geht 
logischerweise über Interna.

Aber man muß da aufpassen, darüber nicht den Nutzer aus den Augen zu 
verlieren - und statt eines Designs für einen Workflow dann haufenweise 
Interna zu exportieren und dem Benutzer um die Ohren zu hauen. Das 
passiert schnell mal, wenn kein UI-Design stattfindet bzw. dies als 
nachrangig betrachtet wird, bis es zu spät ist.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Zwei Hinweise:

Doppelhinweise. ;-)

Autor: Nop (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ach ja.. mal Sourcemonitor drüberlaufen lassen. Scheint gut aufgeteilt 
zu sein, keine extremen Monsterfunktionen - Kompliment.

Besonders json.hpp könnte ein Kandidat für etwas Refactoring werden, 
aber in geringerem Maße sollte man auch clipper.cpp, tool_delete.cpp, 
schematic.cpp und polypartition.cpp im Auge behalten.

Was aber die Code-Doku angeht, es sind insgesamt gesehen arg wenig 
Kommentare drin. Man kann das auch als undokumentierten Code ansehen.

Solange Du das Projekt eh alleine machen willst, mag es noch halbwegs 
angehen, obwohl ich persönlich bei so undokumentiertem Code ja schon 
nach 6 Monaten Probleme hätte zu erinnern, was ich mir dabei gedacht 
hatte.

Das kann die spätere Fehlersuche schwierig machen, weil Du dann aus dem 
Code entnehmen mußt, was er hätte tun sollen, was er stattdessen tut, 
und wie der Bug aussieht.

Mit "was er hätte tun sollen" meine ich natürlich keine 
Redundanzkommentare wie "i++; // increment i by 1", sondern welche, die 
den Sinn dahinter erläutern, denn der ist nicht im Quelltext. Quelltext 
sagt, WAS denn WIE implementiert ist, aber nicht WARUM und WOZU.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Solange Du das Projekt eh alleine machen willst, mag es noch halbwegs
> angehen, obwohl ich persönlich bei so undokumentiertem Code ja schon
> nach 6 Monaten Probleme hätte zu erinnern, was ich mir dabei gedacht
> hatte.

Ich bin also nicht allein ;-)

> Das kann die spätere Fehlersuche schwierig machen, weil Du dann aus dem
> Code entnehmen mußt, was er hätte tun sollen, was er stattdessen tut,
> und wie der Bug aussieht.
>
> Mit "was er hätte tun sollen" meine ich natürlich keine
> Redundanzkommentare wie "i++; // increment i by 1", sondern welche, die
> den Sinn dahinter erläutern, denn der ist nicht im Quelltext. Quelltext
> sagt, WAS denn WIE implementiert ist, aber nicht WARUM und WOZU.

Ja. Es muss noch nicht einmal jede Funktion extra kommentiert werden.

Es ist wichtiger, bspw. zu jedem Modul wirklich einen richtigen 
ausführlichen Text zu schreiben, in dem erklärt wird, was das Modul 
überhaupt macht und wie dessen einzelne Funktionen zusammenspielen.

Dann kann man sich viel besser in die Denkweise dessen hineinversetzen, 
der das Modul geschrieben hat.

Nach sechs Monaten (und noch mehr nach ein paar Jahren) sind diese Texte 
mehr als Gold wert :-}

: Bearbeitet durch Moderator
Autor: Robin R. (elec-lisper)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Nop schrieb:
> Besonders json.hpp könnte ein Kandidat für etwas Refactoring werden,

Ja, Code von dritten immer refaktorieren! Stabiler Code ist toter Code.

Autor: Robin R. (elec-lisper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein weiterer Tip: Nicht das Projekt über-organisieren. Im frühen
Stadium ist es glaub ich wichtiger, dass es gut genug funktioniert
um bei anderen Entwicklern erstmal Interesse auszulösen.
Bekomm die Grundfunktionalität so früh wie möglich stabil.
Bau ein paar automatisierte Tests, damit du noch effektiv refaktorieren
kannst ohne zuviel kaputt zu machen. Genug Tests dass du dich sicher
fühlst, und nicht soviele dass sie dich nerven wenn du eine API
mal änderst. Das ist so meine Pi*Daumen-Regel dabei.

Hier sind viele gute Tipps, auch Code-Doku die von "Nop" erwähnt wird
ist nicht allzu unwichtig. Aber übertreibs nicht, wenn jemand wirklich
einen nenneswerten Beitrag liefern will, dann lässt er sich auch nicht
von fehlenden Kommentaren aufhalten. Wichtig ist da eher, dass du
zur Kommunikation da bist. Bspw. ein IRC-Channel oder ein
nicht zugespammtes E-Mail-Verzeichnis.

Autor: Cyblord ---- (cyblord)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Robin R. schrieb:
> Nop schrieb:
>> Besonders json.hpp könnte ein Kandidat für etwas Refactoring werden,
>
> Ja, Code von dritten immer refaktorieren! Stabiler Code ist toter Code.

Den Spruch werd ich ausdrucken und in Großformat an den Eingang zu 
unserem Entwickler-Keller hängen.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin R. schrieb:

> Ja, Code von dritten immer refaktorieren! Stabiler Code ist toter Code.

Muß man abwägen. Wenn der Code von jenen Dritten noch aktiv 
weiterentwickelt wird, hat Refactoring keinen Sinn, weil es das Updaten 
unnötig schwierig macht.

Andererseits habe ich auch schon Code übernommen - zigtausend Zeilen mit 
diversen Funktionalitäten in einer einzigen Datei. Wenn ich die Funktion 
"alle Vorkommnisse in der aktiven Datei suchen" regelmäßig brauche, um 
die Definition einer Funktion überhaupt noch zu finden, dann weiß ich, 
daß ein Refactoring überfällig ist.

> wenn jemand wirklich einen nenneswerten Beitrag liefern will,
>dann lässt er sich auch nicht von fehlenden Kommentaren aufhalten

Doch, denn sinnvolle Kommentare setzen hätte den Entwickler wenig Zeit 
gekostet - das so herauszufinden würde mich als Nachfolger die fünffache 
Zeit kosten. Wer so mit meiner Zeit umgeht, bekommt davon einfach keine.


Chris D. schrieb:

> Ich bin also nicht allein ;-)

So ziemlich jeder, der schonmal seinen eigenen Senf drei Jahre danach 
nochmal anfassen mußte, hat sich entweder über gute Kommentierung 
gefreut, oder in dem Moment verstanden, wieso sie gut gewesen wäre. :-)

Autor: Peter (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Mal für Dumme Windows User wie mich, gibt es auch einen fertigen 
Installer?

VG, Peter

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Mal für Dumme Windows User wie mich, gibt es auch einen fertigen
> Installer?

Nein, wurde doch schon geschrieben.  Einfach mal den ganzen Thread
lesen …

Das ist im Moment eher Entwickler-Baustelle, also was für Leute, die
wirklich in irgendeiner Weise mitmachen wollen.  „Mitmachen“ heißt
dabei nicht notwendigerweise, eigenen Code beizutragen, aber wenn
man als Tester mitmachen will, muss man in so einer frühen Phase
damit rechnen, in kürzeren Abständen (immer, wenn sich wesentlich
was getan hat) neu zu bauen, ansonsten testet man Dinge, die so schon
gar nicht mehr aktuell sind.

Alternative: die Tests in einer VM machen, allerdings muss die VM dann
die gewünschte OpenGL-Funktionalität unterstützen.

: Bearbeitet durch Moderator
Autor: Peter (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Das habe ich dann wohl überlesen, dabei hatte ich mich recht gut von 
oben bis unten durch gekämpft.

Auch ein 2 Tage alter Intaller würde mir zeigen ob ich dem Projekt 
weiter folgen sollte.

Vg, Peter

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Peter schrieb:
> Auch ein 2 Tage alter Intaller würde mir zeigen ob ich dem Projekt
> weiter folgen sollte.

Das mag ich dir glauben, aber sowas zu pflegen bindet einiges an
Energie beim Entwickler, die er in dieser Phase wohl lieber in die
Sache selbst steckt.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Nop schrieb:
> Zwei Hinweise:
>
> a) sollte -Wall enabled sein, das ist lobenswerterweise im Makefile der
> Fall. Ich würde aber ruhig noch -Werror dazusetzen.

Hm, einige Warnungen könnte ich in der Tat noch ausbügeln, war bis jetzt 
bloß zu faul dafür. Werror muss jetzt nicht unbedingt sein, je nach 
Compiler und dessen Version können schon mal Warnings dazu kommen

> b) check den Source mal mit CppCheck.

Danke für den Tip, mit welchen Optionen hast du cppcheck laufen lassen? 
Vieles scheinen ja implizite Konstruktoren zu sein, manchmal war das 
auch so gewünscht.

Horizon ist mein erstes C++-Projekt, wenn jemand Tipps zu C++14 hat, her 
damit.

> c) das sind eine Menge an Abhängigkeiten von verschiedenen Autoren.

Meinst du mit Abhänigkeiten, die die im Repository selber drin sind 
(json, clipper, etc) oder das ganze externe (Gtk, etc)? Viele von den 
externen Abhängigkeiten sind Projekte mit recht guten "Track record", 
denke mal, daran wird's nicht scheitern.

> d) Doku: wenn ich im Readme lese: "To explain horizon's operation it's...
Vielleicht habe ich hier eine etwas verzerrte sich auf die Dinge, aber 
Units, Entitites, etc. Sind Begriffe die auch in der GUI auftauchen, 
insofern sollte man als Anwender schon wissen, was damit gemeint ist.

Die Tools sind ein anderes Beispiel dafür: Alle Änderungen am Dokument 
(Schaltplan, Board, etc) müssen durch ein Tool (oder property editor) 
stattfinden: von Verschieben über löschen bis zum einfügen aus der 
Zwischenablage. Andere Programme mögen das intern vielleicht ähnlich 
lösen, bei horizon wird das so direkt an den Anwender durchgereicht. Ich 
bevorzuge es Dinge, die ich benutze halbwegs zu verstehen. Wenn das 
mentale Modell mit dem Tatsächlichen Aufbau der Anwendung übereinstimmt, 
umso besser.


Nop schrieb:
> Ach ja.. mal Sourcemonitor drüberlaufen lassen. Scheint gut aufgeteilt
> zu sein, keine extremen Monsterfunktionen - Kompliment.

Hätte ich anders erwartet, insb. die expand()-Methoden von Board und 
Schematic sind doch ein wenig ausufernd...

> Besonders json.hpp könnte ein Kandidat für etwas Refactoring werden,
> aber in geringerem Maße sollte man auch clipper.cpp, tool_delete.cpp,
> schematic.cpp und polypartition.cpp im Auge behalten.

json, clipper und polypartition sind externe Libraries, die damit 
angepriesen werden nur aus 1...2 Dateien zu bestehen. Solang die 
funktionieren ist mir's egal, ob die 10kLOC haben.
Das tool_delete ist leider der Architektur geschuldet. Da der 
interaktive manipulator der selbe für alles von Symbol bis Board ist, 
sind auch die tools die selben - das Tool zum Löschen von einem Symbol 
ist das selbe wie zum Löschen von einem Track. Einiges aus dem Tool 
könnte man allerdings in's Schematic/Board/etc verschieben.

> Was aber die Code-Doku angeht, es sind insgesamt gesehen arg wenig
> Kommentare drin. Man kann das auch als undokumentierten Code ansehen.

Das stimmt in der Tat, vielleicht wird's bald besser...

Robin R. schrieb:
> Wichtig ist da eher, dass du
> zur Kommunikation da bist. Bspw. ein IRC-Channel oder ein
> nicht zugespammtes E-Mail-Verzeichnis.

Dazu sind der Thread hier und issues auf github vorgesehen.

Autor: Nop (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Lukas K. schrieb:

> Werror muss jetzt nicht unbedingt sein, je nach
> Compiler und dessen Version können schon mal Warnings dazu kommen

Stimmt, aber im Moment sind die Versionen ja ohnehin festgezogen, auch 
bei den Libraries. Für "später", wenn Du ins richtige Release gehst, 
kann's sinnvoll sein, das wieder rauszunehmen.

Vorteil: Du kriegst bei den jetztigen pre-alpha-Testern keine 
Bugreports, die letztlich an Dingen lagen, welche der Compiler schon 
bemerkt hatte.

> Danke für den Tip, mit welchen Optionen hast du cppcheck laufen lassen?

Einfach Defaults und alles an, inklusive Stilwarnungen. Ich nehm aber 
auch Windows und die GUI dafür - auch wenn ich dann u.a. mit Cygwin 
entwickele. Stilwarnungen kann man aber auch kollektiv wegklicken, wenn 
sie so gar nicht zum eigenen Stil passen.

> Vieles scheinen ja implizite Konstruktoren zu sein, manchmal war das
> auch so gewünscht.

Ich vermeide Warnungen wegen Implizitheit, damit der nachfolgende 
Programmierer sieht, daß ich da nichts vergessen habe, sondern das genau 
so gewollt habe.

> Meinst du mit Abhänigkeiten, die die im Repository selber drin sind
> (json, clipper, etc) oder das ganze externe (Gtk, etc)?

Die im Repo sind noch unkritisch, weil Du selber derjenige bist, der da 
mögliche Updates zentral einpflegen und testen wird.

> Viele von den
> externen Abhängigkeiten sind Projekte mit recht guten "Track record",
> denke mal, daran wird's nicht scheitern.

Ich denke dabei gar nicht mal an Bugs, sondern an Änderungen, die 
bestehende Funktionalität unabsichtlich zerbrechen. Sowas wie neulich 
bei Cryptkeeper plus Enc_FS. Allein schon die Bugreports später werden 
schwer auszuwerten: Geht mit Lib X in Version Y, aber nicht mit Version 
Z.

Dummerweise kann man auch nicht dem Anwender sagen, er soll halt nur Lib 
X bis maximal Version Y installieren, weil ein anderes Programm dann 
garantiert Version Y+1 als Mindestanforderung hat.

> Vielleicht habe ich hier eine etwas verzerrte sich auf die Dinge, aber
> Units, Entitites, etc. Sind Begriffe die auch in der GUI auftauchen,
> insofern sollte man als Anwender schon wissen, was damit gemeint ist.

Ich würde die Anleitung für den Endnutzer strikt getrennt von der Doku 
für andere Programmierer halten, und auch das technische Niveau sollte 
ein ganz anderes sein. Beim Endnutzer geht es letztlich als 
Grundanliegen nicht darum, das Programm selber zu verstehen, sondern 
darum, wie man mit dem Programm die Aufgaben löst, zu denen es da ist. 
Ganz andere Mentalität.

Ein epic fail in der Nutzerführung ist es, wenn man das Programm dazu 
verstehen muß. Daß man die Materie an sich verstehen muß bei so einer 
Software, ist hingegen klar - wer nicht weiß, was ein Layout überhaupt 
ist, zählt aber auch nicht zur Zielgruppe.

> Andere Programme mögen das intern vielleicht ähnlich
> lösen, bei horizon wird das so direkt an den Anwender durchgereicht.

Autsch. Das ist Offenlegung von Interna und Vermeidung von 
Designentscheidungen, was letztlich beim Anwender abgeladen wird.

Ist nicht verkehrt, wenn man diese Möglichkeit eröffnet, aber dann als 
Fallback, den man zum Troubleshooting nehmen kann, wenn das Programm 
nicht geht wie gewünscht. An sich sollte das Programm aber selber das 
tun, was es tun muß, um die gewünschte Aufgabe zu erreichen, ohne daß 
man ihm das alles erst manuell sagen muß.

Das macht Nutzerführung schwieriger, als es aussieht, und deswegen ist 
es nicht damit getan, am Ende einen GUI-Wrapper drüberzulegen. Der 
Schlüssel als Entwickler ist es, nicht feature-orientiert zu denken, 
sondern Workflow-oriientiert.

> Ich  bevorzuge es Dinge, die ich benutze halbwegs zu verstehen.

Da geht das Programmiererdenken los, und wenn es das Grunddesign der 
Anwendung ist, werden Anwender damit nie glücklich. Das bleibt ein Tool 
von Programmierern für Programmierer.

Wenn ich in Word einen Text schreibe, mache ich mir ja auch keine 
Gedanken über die internen Datenstrukturen von Word.

> Hätte ich anders erwartet, insb. die expand()-Methoden von Board und
> Schematic sind doch ein wenig ausufernd...

Sourcemonitor mißt Komplexität, nicht Zeilenlänge. Viele einfache Zeilen 
sind gut zu verstehen, wenige komplexe auch, aber viele komplexe 
(lokaler Spaghetticode) nicht.

> json, clipper und polypartition sind externe Libraries, die damit
> angepriesen werden nur aus 1...2 Dateien zu bestehen.

OK, dann ist das ein Feature. Wobei Refactoring auch nicht unbedingt 
heißt, die Dateien zu zerlegen, sondern auch einzelne Funktionen, die in 
der Komplexität nach oben gehen. Aber wenn's eh externe Dinge sind, die 
aktiv gepflegt werden, ergibt ein Fork keinen Sinn.

> Dazu sind der Thread hier und issues auf github vorgesehen.

Ich würde vor allem auf Dauer kein synchrones Kommunikationsmedium wie 
IRC empfehlen. Das kostet nämlich aasig Zeit. Es ist effizienter, die 
Fragen zu sammeln, und wenn 10 Leute mehr oder weniger dasselbe wissen 
wollen, das in der Online-FAQ einmal zu beantworten. Deine Zeit als 
Entwickler ist schließlich kostbar.

Auf jeden Fall wünsche ich bei dem Projekt gutes Gelingen!

Autor: Michael L. (michaelx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Doxygen-Dokumentation hatte ich persönlich nie als wirklich hilfreich
> empfunden, da darin oft erklärt ist, was auch eine Zeile drunter im Code
> steht, aber die grobe Struktur fehlt.

Du siehst das Problem, aber ziehst den falschen Schluss daraus!

Es wird häufig falsch dokumentiert. Aber das ist nicht Doxygen 
anzulasten, sondern dem, der falsch dokumentiert.

Ich benutze Doxygen fast von Anfang an, und mache damit (und graphviz) 
nicht nur meine Codedokumentation, sondern erstelle nebenbei auch noch 
die Onlinehilfe zum Programm als html + chm, und für Papierfetischisten 
alles auch als pdf zum selberausdrucken.

Autor: W.S. (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Michael L. schrieb:
> Ich benutze Doxygen fast von Anfang an, und mache damit (und graphviz)
> nicht nur meine Codedokumentation, sondern erstelle nebenbei auch noch
> die Onlinehilfe zum Programm als html + chm, und für Papierfetischisten
> alles auch als pdf zum selberausdrucken.

Ja und?

Dann steht auf dem Ausgedruckten auch bloß das, was im Quelltext zwei 
Zeilen drunter auch bloß steht - sowas ist keine Dokumentation! Egal ob 
im chm oder pdf Format.

Merke dir mal, daß eine Dokumentation - wenn sie gut ist - eine Menge 
Informationen beinhaltet, die eben NICHT aus anderen Quellen auf dem PC 
zusammengesammelt werden können, sondern aus dem Vermögen eines 
menschlichen Autors kommen, Dinge sinnvoll und erhellend erklären zu 
können.

Ein Programm hingegen kann immer nur aus Maschinentext einen anderen 
Maschinentext erzeugen - es fehlt einfach die menschliche Kreativität 
und der menschliche Geistes-Horizont.

W.S.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
W.S. schrieb:
> Ein Programm hingegen kann immer nur aus Maschinentext einen anderen
> Maschinentext erzeugen - es fehlt einfach die menschliche Kreativität
> und der menschliche Geistes-Horizont.

Die Doku ist natürlich immer nur so gut wie deren Autor.

Doxygen kann deutlich mehr als nur wiederzukäuen, was zwei Zeilen
darunter im Code steht …  Kreative Inhalte muss jedoch natürlich
immer noch der Mensch liefern, das ist bei Doxygen nicht anders als
bei Word, LibreOffice, DocBook oder LaTeX.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gute Doku zu schreiben braucht auch Erfahrung, ganz besonders mit den 
WTF-Momenten bei schlecht dokumentierten Projekten. Außerdem noch den 
Willen, es besser zu machen.

Viele Opensource-Projekte kranken entweder daran, daß der Entwickler von 
Doku keine Ahnung hat, weder von technischer Doku noch von Userdoku (und 
von Usability auch nicht), oder an der "scratch-my-itch"-Einstellung. 
Letztere führt im Wesentlichen dazu, totalen Müll zusammenzustoppeln, 
aber sich dank der Ausrede "Opensource" dabei auch noch großartig 
vorzukommen. Ganz nach dem Motto "sobald ich kein Geld bekomme, kann ich 
auch endlich mal Mist machen".

Autor: Max G. (l0wside) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael L. schrieb:
> Es wird häufig falsch dokumentiert. Aber das ist nicht Doxygen anzulasten, 
sondern dem, der falsch dokumentiert.

Hast du einen Vorschlag, wie man in Doxygen sinnvoll dokumentiert? Ich 
setze Doxygen ein, lerne aber gerne dazu.

EDIT: gibt es für SourceMonitor eine grobe Richtlinie, welche 
Komplexität noch ok ist und wo man was tun sollte?

Gruß von Max, der in diesem Thread schon eine Menge gelernt hat

: Bearbeitet durch User
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Max G. schrieb:
> Hast du einen Vorschlag, wie man in Doxygen sinnvoll dokumentiert?

Es gehört halt nicht nur ein Stück Beschreibung vor jedem Funktionskopf
dazu, die möglichst mehr als nur die Parameter erklärt, sondern jede
logische Einheit (kann eine Datei sein, muss nicht) sollte oben einen
größeren Textblock haben, der zum „Großen Ganzen“ dieser Einheit eine
Beschreibung enthält.  Man kann auch logische Gruppen über mehrere
Dateien bilden.

Für Dinge, die nicht in den normalen Sourcecode passen, kann man immer
noch „Additional Pages“ hinterlegen.  Es hat sich eingebürgert, dass
man dafür Dateien mit der Endung .dox schreibt, die inhaltlich einfach
Doxygen-Sourcecode sind (also wie ein einziger großer /** ... */
Kommentar aussehen).  Weiß nicht, mittlerweile kann Doxygen wohl auch
Markdown verarbeiten, damit habe ich noch keine Erfahrung, vielleicht
sieht das ja besser aus.

Was sich auch bewährt hat ist, dass man zu „verknispelte“ Dinge vor
dem Leser der Doku verbirgt, so in etwa:
/**
 * This function implements some foo bar.
 */
#ifdef DOXYGEN
void foobar(int mumble);
#else
static inline void foobar(int mumble) {
  __asm__ ("foo bar\n"
           : mumble);
#endif

Der Makro „DOXYGEN“ wird dann im doxygen.conf gesetzt.  Ohne das #ifdef
würde Doxygen den Nutzer mit dem gesamten inline-Asm überfallen, mit
dem #ifdef dagegen hinterlegt man etwas Lesbareres.

p.s.: Natürlich ist und bleibt Doxygen ein Tool in erster Linie für
Programmierer-Dokumentation.  Eine Anwenderdoku würde ich damit nicht
schreiben, aber so weit dürfte „horizon“ noch nicht sein.

: Bearbeitet durch Moderator
Autor: Robin R. (elec-lisper)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Max G. schrieb:
> Hast du einen Vorschlag, wie man in Doxygen sinnvoll dokumentiert? Ich
> setze Doxygen ein, lerne aber gerne dazu.

Es geht bei der Dokumentation von Klassen, Funktionen und Methoden
weniger darum den Inhalt des Namens der Jeweiligen Abstraktion zu
wiederholen alla:
int countAnswers; // Antworten-Zähler der die Antworten zählt

Es geht darum, dass du dem nächsten sinnvolle Tips für die Verwendung
mit gibst. Meine Daumenregel heisst: "Wenn du nichts sinnvolles 
schreiben kannst, schreib wenigstens ein Beispiel wie man es Verwendet."

Ein Beispiel aus einem meiner Projekte:
        /// Setzt den Datenbank-Cursor auf die nächste Ergebnis-Zeile und liest die Zeile aus.
        /// Es ist notwendig beim ersten Zugriff auf die Ergebnisse auch Result::next
        /// aufzurufen, daher ergibt sich folgendes Idiom um über die Zeilen eines
        /// SQL-Ergebnisses zu iterieren:
        ///
        ///~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        /// ResultPtr r = db.execute(...);
        /// for (r->next(); r->available(); r->next())
        /// {
        ///     // ... r->row() ...
        /// }
        ///~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        /// @return true wenn eine Ergebnis-Zeile verfügbar ist und nicht das Ende der Datenmenge erreicht wurde.
        ///         (das selbe wie available() zurückgeben würde)
        /// @sa available()
        bool next();

Und wie Jörg schon schrieb, genau das selbe gilt auch für die
gesamte Klasse. Sag dem Leser, wie er die Klasse benutzt, was er für
andere Klassen braucht, welche Methoden in welcher Reihenfolge
aufgerufen werden müssen und wie sie im Zusammenhang stehen.
Bei der Dokumentation von bisher undokumentiertem Code sehe ich auch
immer zu, dass mindestens die "äußeren" APIs dokumentiert sind.
Also die High-Level APIs die für einen Anwender wichtig sind.
Komplett internen code der den kram nur implementiert versehe ich
meist nur mit API-Dokumentation wenn ich die Zeit und Muße dazu habe.
In den Internas ist es mir meist wichtiger komplizierte Code-Teile
mit hilfreichen Kommentaren zu versehen, damit der nächste weiß wieso
etwas so komisch implementiert ist, oder wo die Fallstricke sind bei
der Modifikation.

PS: Ich schreib die Doku auch häufig für mich selbst. Weil ich nach 2 
Wochen auch nicht mehr ganz genau weiss wie man eine API benutzt. Darum 
sind mir Beispiel so wichtig. Da kann ich schnell Copy&Paste machen wenn 
ich faul bin und anpassen. Die Doxygen-Doku ist auch meistens schneller 
aufgerufen als die Tests der jeweiligen Bibliothek, in welchen die API 
ja meist nochmal Beispielhaft niedergeschrieben ist. Achja, und für 
generische Komponenten kann ich wirklich automatisierte Tests empfehlen. 
Ich persönlich nutze booost::test - aber das Setup davon kann manchmal 
etwas kompliziert sein.

: Bearbeitet durch User
Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt endlich Binaries! 
https://github.com/carrotIndustries/horizon#quicks... 
Für nen Installer war ich noch zu faul, ist aber auch noch zu früh 
dafür.

Abgesehen vom initialen Einrichten des Pools braucht man nun zum 
Erzeugen und Bearbeiten eines Projektes keine Kommandozeile mehr.

Autor: Robin R. (elec-lisper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läuft bei mir unter Windows 10. Hab leider keine Komponenten sichtbar 
platziert bekommen im Schematic. Konnte sie auswählen und hatte dann son 
Magenta-Farbenen Marker aufm Plan. Reinzoomen ging nicht, liegt aber 
vermutlich eher dran, dass ich keine Maus zur Hand hatte?

Der Tool-Popover reagiert teilweise sehr langsam. Bspw hab ich versucht
"zoom" zu tippen, aber er hat sehr träge reagiert. Konnte aber aufm
ersten Blick nix am Code erkennen, was das Verhalten erklärt.

Zum Code habe ich nur folgende, vollkommen subjektive und auf
Geschmack basierende Gedanken, die sich hauptsächlich um
die Formatierung drehen: Ich rücke lieber mit Spaces ein.
Die Zeilen sind ´relativ unlesbar, weil 152 Zeichen lange Zeilen mit
dem Auge schwer zu lesen sind (Das Auge muss die Höhe ja bei jedem
horizontalen Sprung justieren).
Manche Methoden sind recht lang. bspw. Schematic::expand.
Und ich bin ein Freund von Leerräumen beim Formatieren.
Also "if (a == b)" statt "if(a == b)" und mehr Leerzeilen.

Die Kopplung der Klassen untereinander ist relativ hoch. Bspw. muss
Schematic offenbar sehr genau wissen, wie ein Symbol genau funktioniert
und aufgebaut ist: "sym->component->entity->prefix" - das koppelt
die Implementierung vom Symbol sehr stark an Schematic.

Autor: Robin R. (elec-lisper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bzgl. meines letzten Posts: Das sind natürlich zum Teil auch
Stil-/Geschmacks-Fragen. Aber meiner Erfahrung nach ist gut lesbarer
Code auch einfach zu wartender Code.
Dass Schematic etwas über die Komponenten mit denen es hantiert ist
auch kein gravierendes Problem, aber man sollte ein Auge drauf haben
wenn der Code anfängt (stark) zu wachsen.

Unter Windows 7 öffnet sich leider weder der Schematic noch das Board, 
es kommt nur ein weißer Kasten - und es scheinen unsichtbare 
Bedienelemente
vorhanden zu sein, der Cursor ändert nämlich seine Form an bestimmten
Positionen und der Kasten lässt sich auch größer/kleiner ziehen.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin R. schrieb:
> Läuft bei mir unter Windows 10. Hab leider keine Komponenten sichtbar
> platziert bekommen im Schematic. Konnte sie auswählen und hatte dann son
> Magenta-Farbenen Marker aufm Plan. Reinzoomen ging nicht, liegt aber
> vermutlich eher dran, dass ich keine Maus zur Hand hatte?

Hört sich nach OpenGL-Problem an (Shader für den Inhalt konnten nicht 
kompiliert werden). Was für eine Grafikkarte hast du? CAD ohne Maus 
macht natürlich nur wenig Sinn..
Wenn du debuggen willst, musst du wohl selber Bauen und den imp direkt 
auf mingw starten: 
https://github.com/carrotIndustries/horizon/blob/m... 
Dann kommt auch sinnvolle Ausgabe, was schief gelaufen ist.

Robin R. schrieb:
> Der Tool-Popover reagiert teilweise sehr langsam.
Keine Ahnung was 'sehr' heißt, eine gewisse Verzögerung ist aber drin: 
https://developer.gnome.org/gtk3/stable/GtkSearchEntry.html

Robin R. schrieb:
> Unter Windows 7 öffnet sich leider weder der Schematic noch das Board,
> es kommt nur ein weißer Kasten - und es scheinen unsichtbare
> Bedienelemente
> vorhanden zu sein, der Cursor ändert nämlich seine Form an bestimmten
> Positionen und der Kasten lässt sich auch größer/kleiner ziehen.

Der Projektmanager tut aber? Hört sich wieder nach OpenGL-Problem an...

Autor: Robin R. (elec-lisper)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Windows 7: Intel HD Graphics 4000, GPU Caps Viewer liefert folgende 
Infos:

    OpenGL 3.3 (Intel(R) HD Graphics 4000 with 132 ext.)
    OpenCL 1.1, Intel(R) HD Graphics 4000 compute units:16@350MHz

Report hab ich hier hochgeladen (gpu_caps_viewer_report_win7.txt)

Windows 10: Nvidia GeForce 840M

    OpenGL 4.5 (GeForce 840M/PCIe/SSE2 with 360 ext.)
    OpenCL 1.2, GeForce 840M compute units:3@1124MHz

Report hab ich auch hochgeladen (gpu_caps_viewer_report_win10.txt)

PS: Die Intel-Karte scheint offenbar keine Geometry Shader Texture Units 
zu haben. Daher kann da natürlich auch der Shader nicht laufen.

: Bearbeitet durch User
Autor: Robin R. (elec-lisper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Robin R. schrieb:
>> Läuft bei mir unter Windows 10. Hab leider keine Komponenten sichtbar
[.snip.]
> Was für eine Grafikkarte hast du? CAD ohne Maus
> macht natürlich nur wenig Sinn..

Habs jetzt nochmal mit Maus (via VNC nach Hause) probiert, das Problem
ist nur der initiale Zoom. Wenn ich weiter rein Zoome (mit Mausrad)
sehe ich die Komponente auch richtig, und nicht nur den 
mangenta-farbenen
Selektionsmarker. Touch-Pad-Support is auch ersmtal nicht wichtig,
bei KiCAD bleibt mir auch nur F2/F3 zum Zoomen übrig. Morgens/Abends
im Bett hab ich halt keine Maus zur Hand ;-)

Finds übrigens super, dass Undo/Redo bereits in so früher Phase
eingebaut ist - sowas nachträglich einbauen is immer ein Krampf...

OpenGL-Mäßig ist die NVidia-Karte halt eher aufm aktuellen Stand.
Ist auch ein Lenovo-Consumer-Laptop, die Windows 7 Kiste ist
ein 3-4 Jahre alter Büro-Dell-Rechner.

Ich kann gut verstehen, dass man aktuelle OpenGL-Features nutzen will.
Aber sollte es nicht schon ausreichen wenn man mit vertext buffer 
objects
arbeitet?

PS: Auf dem Windows 7 Rechner bekomme ich folgende Fehlerausgabe (mit
einer selbst-compilierten Version ausm Git):
    (horizon-imp.exe:2356): Gdk-WARNING **: Compile failure in fragment shader:
    ERROR: 0:10: 'texture2D' : no matching overloaded function found (using implicit conversion)
    ERROR: 0:10: 'assign' :  cannot convert from 'const float' to 'FragUserData 4-component vector of float'

: Bearbeitet durch User
Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin R. schrieb:

> PS: Auf dem Windows 7 Rechner bekomme ich folgende Fehlerausgabe (mit
> einer selbst-compilierten Version ausm Git):
>
>
     (horizon-imp.exe:2356): Gdk-WARNING **: Compile failure in fragment 
 shader:
     ERROR: 0:10: 'texture2D' : no matching overloaded function found 
 (using implicit conversion)
     ERROR: 0:10: 'assign' :  cannot convert from 'const float' to 
 'FragUserData 4-component vector of float'

Oh, das schaut nach einem Bug in Gtk/Gdk bzw. dem Intel-Treiber aus. Ist 
der aktuell? Passt auch dazu, dass das Fenster komplett leer ist. Zum 
Test, starte mal gtk3-demo aus der mingw-Konsole und öffne die 
OpenGL-Demo. Die sollte dann auch kaputt sein.

Schnapp' dir nen Hexeditor und mach die libgdk-3-0.dll aus dem 
mingw-Verzeichnis auf. Nach Offset 0x87340 texture2D durch texture 
ersezten (2D durch zwei Leerzeichen ersetzen) Schau mal nach, ob's dann 
klappt.

Autor: Robin R. (elec-lisper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Oh, das schaut nach einem Bug in Gtk/Gdk bzw. dem Intel-Treiber aus. Ist
> der aktuell? Passt auch dazu, dass das Fenster komplett leer ist. Zum
> Test, starte mal gtk3-demo aus der mingw-Konsole und öffne die
> OpenGL-Demo. Die sollte dann auch kaputt sein.

Jo, die OpenGL-Demo is auch kaputt, selbe Symptome.
Bzgl. der Treiber hab ich keine Ahnung.

>
> Schnapp' dir nen Hexeditor und mach die libgdk-3-0.dll aus dem
> mingw-Verzeichnis auf. Nach Offset 0x87340 texture2D durch texture
> ersezten (2D durch zwei Leerzeichen ersetzen) Schau mal nach, ob's dann
> klappt.

Hmm, damit hab ich bei mir die gtk3-demo nur komplett kaputt bekommen.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In dem von dir Angehängten Report steht was von
- Driver: 8.15.10.2639 (2-1-2012) - GL:ig7icd64.dll
bei Intel gibt's einen von 2016 
https://downloadcenter.intel.com/download/25977/In...

Wenn du magst, kannst du mal mit dem dein Glück versuchen.

Robin R. schrieb:
> Touch-Pad-Support is auch ersmtal nicht wichtig,
> bei KiCAD bleibt mir auch nur F2/F3 zum Zoomen übrig. Morgens/Abends
> im Bett hab ich halt keine Maus zur Hand ;-)
Auf X11 und Wayland erkennt das Canvas-Widget, wenn ein Input-Event von 
'nem Trackpoint kam und "pannt" dann, anstatt zu scrollen. Zum zoomen 
dann ctrl festhalten. Damit ist horizon auch recht brauchbar ohne Maus 
zu bedienen.

Robin R. schrieb:
> Ich kann gut verstehen, dass man aktuelle OpenGL-Features nutzen will.
> Aber sollte es nicht schon ausreichen wenn man mit vertext buffer
> objects arbeitet?
Mit geometry shadern macht's eben mehr Spaß ;) Lästiger Kram, wie z.B. 
Linien mit abgerundeten Ecken malen geht recht bequem im Zusammenspiel 
von Geometry- und Fragment-Shader.

Autor: Robin R. (elec-lisper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> In dem von dir Angehängten Report steht was von
> - Driver: 8.15.10.2639 (2-1-2012) - GL:ig7icd64.dll
> bei Intel gibt's einen von 2016
> 
https://downloadcenter.intel.com/download/25977/In...
>
> Wenn du magst, kannst du mal mit dem dein Glück versuchen.

Die Intel-Treiber wollen leider nicht direkt auf diesem Dell-Rechner,
aber die Treiber von der Dell-Webseite haben dann zumindest das
Fehlerbild geändert. Jetzt bekomme ich immerhin ein Fenster,
aber der Canvas ist nicht zu sehen (nur der graue Gtk-Hintergrund).
Selbes Bild auch mit gtk3-demo.
Immerhin gehts unter Win10 auf dem neueren Rechner.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Auch wenn's hier die letzten Monate doch eher still geworden ist, ist 
die Entwicklung von horizon nicht stehen geblieben.

Neben Annehmlichkeiten wie GUI zum Verwalten von Bauteilen und Projeken 
sind Funktionen wie interaktives regelbasiertes Routing und DRC 
hinzugekommen.

Seht selbst: 
https://github.com/carrotIndustries/horizon#horizo...

Autor: Stefan S. (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Ja, ich hatte vor einigen Tagen auch mal kurz hineingeschaut.

Mitstreiter haben sich ja wohl sogut wie keine gefunden, und hier in dem 
Thread gab es soweit ich mich errinnere nur gemecker --war ja auch nicht 
anders zu erwarten.

Ich werde mir demnächst mal dein Dateiformat und dein Vorgehen beim 
Bauteilentwurf ansehen. Denn mein high level GTK3 Nim wrapper ist nun 
endlich weitgehend fertig, so dass ich auch mal wieder etwas an meinen 
Programmen arbeiten könnte. Die kompatibilität mit gEDA werde ich wohl 
aufgeben, das scheint ja eh keiner mehr zu benutzen.

Hast Du eigentlich mal probiert, wie viel schneller Dein GL Zeichnen im 
Vergleich zu Cairo's CPU Backend ist? Denn Cairo's GL Backend ist ja 
seltsamerweise langsamer als das CPU Backend. Kürzlich fand ich Intels

 https://github.com/intel/fastuidraw

Das ist schon ganz interessant, aber wohl noch unfertig. 9 mal schneller 
als cairo CPU.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan S. schrieb:
> Hast Du eigentlich mal probiert, wie viel schneller Dein GL Zeichnen im
> Vergleich zu Cairo's CPU Backend ist? Denn Cairo's GL Backend ist ja
> seltsamerweise langsamer als das CPU Backend.

Ausprobiert habe ich da noch nichts, wenn man sich aber mal ansieht wie 
furchtbar langsam Kicads Cairo-GAL canvas ist... Cairo mit OpenGL zu 
beschleunigen halte ich auch für nur mäßig zielführend, da cairos 
Zeichenmodell nicht so wirklich zu dem von OpenGL passt.

Autor: Stefan S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja das ist richtig.

Nach

https://www.x.org/wiki/Events/XDC2016/Program/rogo...

ist SkiaGL ja auch nicht wesentlich schneller als Cairo.

Aber wenn man schon mit OpenGL zeichnet sollte man schon geglättete 
diagonale Linien, Bezier-Kurven und auch hochwerttige Fonts haben. Und 
dann wird es leider schon wieder aufwendiger und langsamer.

Hast Du Deine GL Zeichenroutinen auf dem GL-Area Demo mit dem Dreieck 
aufgebaut?

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan S. schrieb:
> Ja das ist richtig.
>
> Nach
>
> https://www.x.org/wiki/Events/XDC2016/Program/rogo...
>
> ist SkiaGL ja auch nicht wesentlich schneller als Cairo.
>
> Aber wenn man schon mit OpenGL zeichnet sollte man schon geglättete
> diagonale Linien, Bezier-Kurven und auch hochwerttige Fonts haben. Und
> dann wird es leider schon wieder aufwendiger und langsamer.
MSAA wäre in der Tat machbar, ist halt Aufwand: 
https://www.khronos.org/opengl/wiki/Multisampling#... Für die 
anderen Methoden müsste der GdkGLContext MSAA können, was nicht der Fall 
ist.

Was Fonts anbetrifft: Die derzeit verwendeten Hershey-Fonts sind mir 
hübsch genug. Andere Programme, die echte Truetype-Schriften verwenden 
haben mitunter Probleme damit, diese entsprechend dem Rest drum herum zu 
skalieren. Text, der bei einer Zoomstufe passt, ragt dann bei einer 
anderen schon ins Symbol nebendran...

> Hast Du Deine GL Zeichenroutinen auf dem GL-Area Demo mit dem Dreieck
> aufgebaut?

Jep, hauptsächlich der Boilerplate-Code zum Shader aufsetzen ist 
größtenteils aus der Demo übernommen. Irgendwo muss man ja mal anfangen 
;)

Autor: Possetitjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan S. schrieb:

> Mitstreiter haben sich ja wohl sogut wie keine gefunden,

Naja, interessieren würde es mich schon, aber ich denke,
ich bin technisch und mental nicht mit euch kompatibel.

Mein normales Desktop Environment ist der fvwm2, und
übliche Projekte umfassen bei mir 1000 Zeilen tcl/tk-Code
(eher weniger als mehr).

> [...] so dass ich auch mal wieder etwas an meinen Programmen
> arbeiten könnte.

Du bist der Stefan S., der die psychedelischen Bilder, die
der topologische Router produziert hat, auf der Homepage
zeigt!?

> Die kompatibilität mit gEDA werde ich wohl aufgeben,

Sehr schade.


> das scheint ja eh keiner mehr zu benutzen.

Ich spiele gelegentlich damit herum. -- Das Projekt scheint
sich totgelaufen zu haben. Kennt jemand Hintergründe?
Ich habe den diffusen Eindruck, dass sich die Entwickler auf
faule Kompromisse "geeinigt" haben, die dann doch niemand
wirklich wollte.

Im Vergleich zum nächsten, (n+1)ten All-in-one-Klotz fände
ich es WIRKLICH wichtig, eine Software zu haben, die eine
klare Aufgabenteilung ermöglicht.
Generell scheint meine persönliche Vorstellung von Software-
ergonomie mit der der Programmierer absolut inkompatibel zu
sein. Ideen gäbe es schon -- allein, ich bin programmier-
technisch nicht versiert genug, sie umzusetzen.

Autor: Stefan S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Possetitjel schrieb:
> Du bist der Stefan S., der die psychedelischen Bilder, die
> der topologische Router produziert hat, auf der Homepage
> zeigt!?

Ja sicher.
>
>> Die kompatibilität mit gEDA werde ich wohl aufgeben,
>
> Sehr schade.
>
>> das scheint ja eh keiner mehr zu benutzen.
>
> Ich spiele gelegentlich damit herum. -- Das Projekt scheint
> sich totgelaufen zu haben. Kennt jemand Hintergründe?

Da gibt es eine vielzahl von Gründen. Der ursprüngliche Hauptentwickler 
und auch auch viele andere Entwickler haben sich nach und nach 
zurückgezogen. Neue Ideen oder größere Veränderungen wurden von den 
wenigen alten Usern stets abgelehnt. Dann war gEDA/PCB ja nur mit Mühe 
unter Windows zum Laufen zu bringen. GTK ist eh nicht mehr so beliebt, 
und die Entwicklung mit plain C ist eben auch sehr zäh. Und Scheme als 
Script- und Konfigurationssprache ist auch nicht jedermanns Sache.

Wobei es seit gut einem Jahr wohl ein neues Project PCB-RND bzw. 
gEDA-RND gibt. Ich hatte aber nur die Ankündigung gesehen, u.a. C89 und 
soll auch mit reinem X11 funktionieren, also auch ohne GTK. So macht man 
sich das Leben wieder sehr schwer.

>
> Im Vergleich zum nächsten, (n+1)ten All-in-one-Klotz fände
> ich es WIRKLICH wichtig, eine Software zu haben, die eine
> klare Aufgabenteilung ermöglicht.

Das war gEDA/PCB ja, und gerade das wurde aber sehr viel kritisiert. Die 
meisten wollten lieber alles in einem Programm und sind dann zum Teil zu 
KiCad abgewandert.

> Generell scheint meine persönliche Vorstellung von Software-
> ergonomie mit der der Programmierer absolut inkompatibel zu
> sein. Ideen gäbe es schon -- allein, ich bin programmier-
> technisch nicht versiert genug, sie umzusetzen.

Man muss ja nicht unbedingt C++ verwenden. Und auch nicht Haskell oder 
Rust. Es gibt ja heute eine Reihe von recht einfachen aber doch sehr 
leistungsfähigen Sprachen, da kann schon jeder, der etwas denken kann 
auch programmieren. Mit den GUI's sieht es natürlich noch immer 
schlechter aus, für Qt kommt wohl im wesentlichen nur C++ in frage, oder 
eventuell Python. Für GTK gibt es Bindings für viele Sprachen, mit 
unterschiedlicher Qualität. Aber Programmieren kann man ja auch Dinge 
die keine GUI benötigen. Oder man macht Webanwendungen, Java-Script und 
Konsorten scheinten ja immer beliebter zu werden. Oder C# oder Android 
Apps.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Possetitjel schrieb:
> Mein normales Desktop Environment ist der fvwm2

Willkommen im Club. :)

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wird hier eigentlich das selbe Programm vorgestellt, über das hier 
diskutiert wird?
https://www.youtube.com/watch?v=OpwMhz_3Tbs

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Davon würde ich angesichts des Programmnamens und des Namens "lukas"
ausgehen. :)

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich schrieb:
> Wird hier eigentlich das selbe Programm vorgestellt, über das hier
> diskutiert wird?
> https://www.youtube.com/watch?v=OpwMhz_3Tbs

Ja. In dem Video präsentiert Lukas sein Projekt.

Man findet die Videoaufzeichnung auch hier.
https://media.ccc.de/v/gpn17-8592-neues_ecad-progr...

: Bearbeitet durch User
Autor: Leute, Leute (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
ich schrieb:
> Wird hier eigentlich das selbe Programm vorgestellt, über das hier
> diskutiert wird?
> Youtube-Video "Neues ECAD-Programm horizon (GPN17)"

Mein Gott, diese abhackte Sprechweise ist für mein Gehör einfach nicht 
kompatibel. Für mich wieder mal ein Beispiel für die vielen nahezu 
unzumutbaren "Tutorials" (um es mal so zu nennen) die eher abschrecken 
als motivieren.

Abgesehen davon, brauchbare EDA-Software zu schreiben gehört nach meiner 
Erfahrung (als Nutzer) mit zum Schwierigsten was man sich vornehmen kann 
und ist unmöglich als One-Man-Show erfolgreich umzusetzen. Wieviel 
Mann-Jahre developer time beispielsweise wurden bisher an eagle 
ver(sch)wendet und bis heute hat eagle quirks, die manch einen zur 
Verzweiflung oder zur Konkurrenz treiben.

Das Problem bei EDA ist nämlich, dass es extrem um die Feinheiten, d.h. 
das Zusammenspiel zwischen Schaltplan, Layout und Bibliothekshandling 
(schnelle Erstellung, Pflege, hohe Vollständigkeit, 3D etc.) geht und 
schon Kleinigkeiten einem das Leben schwer machen können. Für ein 
Ein-Mann-Projekt ist das in absehbarer Zeit (wir reden über JAHRE!!) 
viel zu schwierig umzusetzen und alle die hier falsche Hoffnung und 
Schulterklopf befördern werden selber so eine halbgare Software NIEMALS 
einsetzen. Was bleibt ist später eines der unzähligen angefangenen und 
verwaisten Projekte, bei denen der Ersteller schlicht die Lust daran 
verloren hat.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Leute, Leute schrieb:

> Mein Gott, diese abhackte Sprechweise ist für mein Gehör einfach nicht
> kompatibel.

Hast du mal ein Video (oder Audio) von einem Konferenzvortrag, den
du gehalten hast?  Klingt er denn viel besser?

> Für mich wieder mal ein Beispiel für die vielen nahezu
> unzumutbaren "Tutorials" (um es mal so zu nennen) die eher abschrecken
> als motivieren.

Thread nicht gelesen, aber rummaulen.

Das Teil ist absolut noch nichts, was irgendwie Nutzern derzeit
zugemutet werden soll.  Folglich ist das Video auch kein „Tutorial“,
sondern eine Darstellung des Arbeitsstandes.

Wenn du hier nur als Nutzer daherkommen willst, bist du wohl mehr
als ein Jahr zu früh.

> Abgesehen davon, brauchbare EDA-Software zu schreiben gehört nach meiner
> Erfahrung (als Nutzer) mit zum Schwierigsten was man sich vornehmen kann
> und ist unmöglich als One-Man-Show erfolgreich umzusetzen.

Aha.  Du erklärst, dass du selbst nur Nutzer bist, weißt aber dabei
sofort, dass das als One-Man-Show nicht zu machen ist.

Das leuchtet sofort ein.  Deine Erfahrungen als Nutzer ermöglichen
dir natürlich einen grundlegenden Rundumblick dafür, wie ein Entwickler
in diesem Bereich so arbeiten muss …

Autor: Miesepeter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute, Leute schrieb:
> Was bleibt ist später eines der unzähligen angefangenen und
> verwaisten Projekte, bei denen der Ersteller schlicht die Lust daran
> verloren hat.

Na und? Selbst wenn es so kommen würde, was gibts daran auszusetzen? Wer 
was macht hat recht, wie man in der Szene sagt. Ich meine die Kritik war 
ja nicht mal konstruktiv... man hätte ja zum Beispiel das was gut ist 
herausstellen und vorschlagen können seine Mann-Jahre in ein vorhandenes 
Projekt wie KiCad einzubringen?

Whatever - dem TO viel Erfolg und hört nicht auf Miesepeter. Wer macht, 
hat recht!

Autor: Leute, Leute (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Leute, Leute schrieb:
>
>> Mein Gott, diese abhackte Sprechweise ist für mein Gehör einfach nicht
>> kompatibel.
>
> Hast du mal ein Video (oder Audio) von einem Konferenzvortrag, den
> du gehalten hast?  Klingt er denn viel besser?
>
>> Für mich wieder mal ein Beispiel für die vielen nahezu
>> unzumutbaren "Tutorials" (um es mal so zu nennen) die eher abschrecken
>> als motivieren.
>
> Thread nicht gelesen, aber rummaulen.

Kannst es ja überlesen wenn es dir nicht passt.

> Das Teil ist absolut noch nichts, was irgendwie Nutzern derzeit
> zugemutet werden soll.  Folglich ist das Video auch kein „Tutorial“,
> sondern eine Darstellung des Arbeitsstandes.

Es wird auch später niemandem nutzen, weil der Ersteller bereits mit dem 
Vortrag selbst überfordert ist. Sorry, aber so wirkt das nun mal auf 
mich.

> Wenn du hier nur als Nutzer daherkommen willst, bist du wohl mehr
> als ein Jahr zu früh.

Man sein, aber auch in einem Jahr wird sich daran nichts ändern. Ist 
meine Prognose. Du brauchst sie nicht zu teilen.

>> Abgesehen davon, brauchbare EDA-Software zu schreiben gehört nach meiner
>> Erfahrung (als Nutzer) mit zum Schwierigsten was man sich vornehmen kann
>> und ist unmöglich als One-Man-Show erfolgreich umzusetzen.
>
> Aha.  Du erklärst, dass du selbst nur Nutzer bist, weißt aber dabei
> sofort, dass das als One-Man-Show nicht zu machen ist.

Ja, ich schreibe keine EDA SW. So verrückt kann ich gar nicht sein. 
Schau dir doch mal an was z.B. Abacom als EDA so anbietet. Wieviele 
Leute haben an deren SW nun seit wie vielen Jahren geschrieben und noch 
immer wird deren SW mehr als "Platinenmaler" angesehen, als als echte 
EDA-SW. Glaubst du der Threadersteller wird es jemals schaffen auch nur 
auf deren Niveau aufzuschließen?

> Das leuchtet sofort ein.  Deine Erfahrungen als Nutzer ermöglichen
> dir natürlich einen grundlegenden Rundumblick dafür, wie ein Entwickler
> in diesem Bereich so arbeiten muss …

Darum geht es nicht. Es geht darum zu erkennen, wann man sich mit einer 
Aufgabe übernimmt. Hier werden womöglich falsche Hoffnungen geweckt oder 
warum wurde dieser Thread hier eröffnet? Irgendwann soll die SW hier 
doch mal benutzbar sein oder etwa nicht? Schau dir doch nur mal den Mist 
bei gEDA an. Wer will denn sowas benutzen? Das Netz strotzt nur so von 
halbgaren Projekten, gerade im Bereich der SW-Entwicklung. Wer will denn 
seine Platinen mit einer SW layouten, deren Möglichkeiten extrem 
beschnitten sind und Schicksal ungewiss ist?

Mir reichen übrigens meine Quirks bei Diptrace. Mit denen kann ich 
einigermaßen leben.

Autor: Leute, Leute (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Miesepeter schrieb:
> Leute, Leute schrieb:
>> Was bleibt ist später eines der unzähligen angefangenen und
>> verwaisten Projekte, bei denen der Ersteller schlicht die Lust daran
>> verloren hat.
>
> Na und? Selbst wenn es so kommen würde, was gibts daran auszusetzen?

Anscheinend bist du noch nie auf schlechte SW hereingefallen.

> Wer
> was macht hat recht, wie man in der Szene sagt.

"Die Szene"? Was soll das sein? Leute die auf die schnelle was 
zusammencodieren und meinen dann das Ei des Kolumbus neu erfunden zu 
haben? Davon gibt es mehr als genug. Nach ein paar Jahren ist die Lust 
dann weg und zurück bleibt eine Baustelle, die keiner mehr braucht bzw. 
verprellte Nutzer.

> Ich meine die Kritik war
> ja nicht mal konstruktiv...

Doch ist sie. Lass es sein! Verbessere meinetwegen lieber KiCAD aber 
versuche die nicht an Dingen die in die Hose gehen müssen.

> Whatever - dem TO viel Erfolg und hört nicht auf Miesepeter. Wer macht,
> hat recht!

Wer das falsche macht gerät in seine Sackgasse. Wer das überdies nicht 
erkennt ist doof. Sorry, aber so ist es. Wer einfach mal ein bisschen 
herumcodieren möchte darf das natürlich tun. Aber dann den Ball flach 
halten und nicht falsche Hoffnungen wecken.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Das Teil ist absolut noch nichts, was irgendwie Nutzern derzeit
> zugemutet werden soll.

Hast du dir's in der aktuellen Version mal angesehen? Inzwischen hat's 
einige Annehmlichkeiten, die man so in anderer EDA-Software (z.B. KiCad) 
doch sehr vermisst:
 - Schaltplaneditor, der mehr als nur ein Malprogramm ist
 - Sinnvolles Bauteilmanagement
 - Flexible Regeln für Abstände, Leiterbahnbreite, etc.

Im Gegensatz zu vor 9 Monaten kann man nun auch alles aus der GUI machen 
und muss keine Shell mehr anfassen. (Für dich wahrscheinlich weniger ein 
Problem)

https://github.com/carrotIndustries/horizon/wiki/F...

: Bearbeitet durch User
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Leute, Leute schrieb:
> Kannst es ja überlesen wenn es dir nicht passt.

Genauso gut könntest du deinen Beitrag zu Thema auch bleiben lassen.

In der dargebotenen Form mag dein Beitrag deinem Ego vielleicht helfen,
mehr auch nicht.  Vom TE haben wir im Gegensatz zumindest durchaus
verwertbare Dinge sehen können, einschließlich des Auftritts auf einer
Konferenz.  Er hat eine Software geschaffen, die zumindest in gar nicht
so kleinen Teilen das tut, was sie soll.  Das ist deutlich mehr als
die Miesmacherei, die du hier ablässt.  (Dabei bestreite ich keineswegs,
dass es noch ein langer Weg bis zum fertigen "Produkt" ist,

> Es geht darum zu erkennen, wann man sich mit einer Aufgabe übernimmt.

Wer bist du denn, dass ausgerechnet du dazu berufen sein mögst, das
zu erkennen?

Im Gegensatz zum TE bist du einfach nur ein anonymer Forenposter. Wenn
es an der Substanz fehlt, muss man sich dann an Äußerlichkeiten
aufziehen („Mein Gott, diese abhackte [sic] Sprechweise …“).

Geh bitte wieder zurück irgendwo hin, wo du produktiver wirken kannst,
aber verschon diesen Thread einfach mit deiner Miesepeterei.

Autor: Possetitjel (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Jörg W. schrieb:

>> Abgesehen davon, brauchbare EDA-Software zu schreiben
>> gehört nach meiner Erfahrung (als Nutzer) mit zum
>> Schwierigsten was man sich vornehmen kann und ist
>> unmöglich als One-Man-Show erfolgreich umzusetzen.
>
> Aha.  Du erklärst, dass du selbst nur Nutzer bist, weißt
> aber dabei sofort, dass das als One-Man-Show nicht zu
> machen ist.

Das ist ein Umkehrschluss, der naheligend -- und meiner
Meinung nach auch zutreffend -- ist: Wäre es als One-Man-Show
machbar, dann hätte es schon jemand gemacht. EDA-Software
gibt es schließlich reichlich.

Was mich verzweifeln lässt, das ist der Eindruck, dass
niemand -- wirklich NIEMAND -- Interesse daran hat, eine
echt modularisierte Software auf die Beine zu stellen. Mit
"modularisiert" meine ich nicht "Quelltext besteht aus
mehreren Teilen", sondern: alle missionskritischen Interfaces
(Dateiformate, ggf. auch APIs) sind offengelegt und werden
aktiv gepflegt.

Das würde natürlich voraussetzen, dass reichlich Arbeit in das
Entwickeln eines tragfähigen Datenmodelles geht, und diese Zeit
steht dann natürlich nicht mehr dafür zur Verfügung, sich über
die "modernste" Grafik-Bibliothek die Köpfe einzuschlagen...

Der Vorteil dieser Modularisierung liegt auf der Hand: Es sind
alle Abstufungen von All-in-one-Mammutsoftware bis hin zu
einzelnen Werkzeugen für jeden Zweck machbar, und der Anwender
müsste keine exclusive Entscheidung für EIN Werkzeug treffen,
die dann alle anderen ausschließt.

Das kommerzielle Anbieter das nicht wollen (weil es den "Vendor-
lock-in" verhindert), ist mir ohne weiteres klar. Warum aber die
FOSS-Gemeinde nicht in der Lage ist, das hinzubekommen, wird mir
auf Dauer ein Rätsel bleiben.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Hast du dir's in der aktuellen Version mal angesehen?

Nein, sorry, ich fürchte, dass ich schon auf zu vielen Hochzeiten
selbst tanze. :)  Ich wünsche dir aber auf jeden Fall viel Erfolg
damit, und es würde mich durchaus freuen, wenn das Projekt an Fahrt
aufnimmt (einschließlich weiterer Mitwirkender).

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Possetitjel schrieb:
> Mit "modularisiert" meine ich nicht "Quelltext besteht aus mehreren
> Teilen", sondern: alle missionskritischen Interfaces (Dateiformate, ggf.
> auch APIs) sind offengelegt und werden aktiv gepflegt.

Leute, die Opensource Datenmodelle abstrahieren, sind halt noch
deutlich dünner geseht als Opensource-Programmierer.  Programmieren
macht Spaß, diejenigen, denen das Pflegen von Datenmodellen so viel
Spaß macht, dass sie dies auch noch in ihrer Freizeit tun, dürfte es
nur wenige geben.

Autor: Possetitjel (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Leute, Leute schrieb:

> Wer das falsche macht gerät in seine Sackgasse. Wer das
> überdies nicht erkennt ist doof. Sorry, aber so ist es.
> Wer einfach mal ein bisschen herumcodieren möchte darf
> das natürlich tun. Aber dann den Ball flach halten und
> nicht falsche Hoffnungen wecken.

Könnte es sein, dass Du Deine Prioritäten etwas merkwürdig
setzt?

Ist Dir das Diffamieren fremder Leistungen tatsächlich SO
wichtig, dass am Ende keine Energie mehr über bleibt, ein
Sachargument zu formulieren?

Autor: Leute, Leute (Gast)
Datum:

Bewertung
-7 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Leute, Leute schrieb:
>> Kannst es ja überlesen wenn es dir nicht passt.
>
> Genauso gut könntest du deinen Beitrag zu Thema auch bleiben lassen.

Und das bestimmst du also?

> In der dargebotenen Form mag dein Beitrag deinem Ego vielleicht helfen,
> mehr auch nicht.

Ach Gott, spar dir deine persönliche Agitation.

> Vom TE haben wir im Gegensatz zumindest durchaus
> verwertbare Dinge sehen können, einschließlich des Auftritts auf einer
> Konferenz.

Die ziemlich unerträglich ist. Für meine Ohren jedenfalls.

> Er hat eine Software geschaffen,

Nö. Er hat mal was zusammencodiert, das niemand braucht und auch niemand 
benutzen wird. Ginge das alles so einfach hätten wird zig gute EDA 
Pakete. Haben wird aber nicht. Warum wohl?!

> die zumindest in gar nicht
> so kleinen Teilen das tut, was sie soll.

Das reicht nicht. Nicht mal ansatzweise.

> Das ist deutlich mehr als
> die Miesmacherei, die du hier ablässt.  (Dabei bestreite ich keineswegs,
> dass es noch ein langer Weg bis zum fertigen "Produkt" ist,

DU Bist es der auf Mies macht mein lieber. Nur mal zu deiner Erinnerung. 
Hier hat jemand einen Thread aufgemacht und zum BENUTZEN seines 
Programms aufgefordert. Zitat

"Viel Spaß damit,"

Welcher Spaß??? Wer Platinen erstellt braucht keine Spaßbaustelle, 
sondern ein ZUVERLÄSSIGES Programm. Alles andere ist Mumpitz. Und Beta 
Tester einer Pre-Alpha-Software spielen ist auch kein Spaß.

>> Es geht darum zu erkennen, wann man sich mit einer Aufgabe übernimmt.
>
> Wer bist du denn, dass ausgerechnet du dazu berufen sein mögst, das
> zu erkennen?

Das ist inhärent mit der ausgesuchten Aufgabe verknüpft. Dazu brauche 
ich keine Berufung um das zu erkennen. Mir genügt meine Erfahrung 
bisheriger EDA-SW, um zu beurteilen, wie viel wichtige aber oft schlecht 
umgesetzte Details einen zur Weißglut bringen können. Es braucht nicht 
noch mehr halbgare EDA. Gerade Leiterplattenprojekte sind wenig geeignet 
um mit SW gepflegt zu werden, die das Schicksal verwaister Projekte in 
wenigen Jahren teilen werden. Besser man bedenkt das vorher als 
hinterher dumm dazustehen.

> Im Gegensatz zum TE bist du einfach nur ein anonymer Forenposter. Wenn
> es an der Substanz fehlt, muss man sich dann an Äußerlichkeiten
> aufziehen („Mein Gott, diese abhackte [sic] Sprechweise …“).

Ja, ich bin es leid auf diese YouTube Videos hereinzufallen, die keinen 
Mehrwert beeinhalten, weil sie ziemlich unerträglich sind. Wenn ich 
nicht tanzen kann gehe ich auch nicht auf die Bühne zum vortanzen.

> Geh bitte wieder zurück irgendwo hin, wo du produktiver wirken kannst,
> aber verschon diesen Thread einfach mit deiner Miesepeterei.

Spare dir diese billige Polemik. Mit falschem Schulterklopf erweist du 
dem TE nur einen Bärendienst.

Autor: Leute, Leute (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Possetitjel schrieb:
> Ist Dir das Diffamieren fremder Leistungen tatsächlich SO
> wichtig, dass am Ende keine Energie mehr über bleibt, ein
> Sachargument zu formulieren?

Ich diffamiere hier niemandem. Hier wird aber wie schon im Mittelalter 
der Überbringer der Nachricht mal wieder gesteinigt und somit ein Forum 
wie des Öfteren ad absurdum geführt.

Mal abgesehen davon, was erwartest du? Das ich meine Zeit damit 
verbringe eine SW zu testen, die ich nie benutzen werde? Wozu? Ich gab 
meine Meinung dazu ab und Meinungsfreiheit besteht doch hoffentlich noch 
oder etwa nicht mehr?!

Speichere den Thread hier ab, hole ihn in 5 Jahren wieder heraus und 
schaue, ob die SW dann beispielsweise KiCAD überholt hat. Ich sage dir 
voraus, in 5 Jahren (oder deutlich früher) wird diese SW in der 
Versenkung verschwunden sein und mit sowas verschwende ich nicht meine 
kostbare Zeit.

Vergleiche einfach mal mit der Verbesserung über die Zeit bei anderer 
EDA SW, wie wenig wirklich neues hinzukommt und wieviel Bugs ausgeräumt 
werden müssen, die die Anwender nerven. Das willst du dir nicht 
freiwillig antun.

Und achte mal darauf, wer welche Ausreden benutzt, um die SW des TE erst 
gar nicht anzufassen.

Autor: Possetitjel (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Jörg W. schrieb:

> Possetitjel schrieb:
>> Mit "modularisiert" meine ich nicht "Quelltext besteht
>> aus mehreren Teilen", sondern: alle missionskritischen
>> Interfaces (Dateiformate, ggf. auch APIs) sind offengelegt
>> und werden aktiv gepflegt.
>
> Leute, die Opensource Datenmodelle abstrahieren, sind halt
> noch deutlich dünner geseht als Opensource-Programmierer.
> Programmieren macht Spaß, diejenigen, denen das Pflegen
> von Datenmodellen so viel Spaß macht, dass sie dies auch
> noch in ihrer Freizeit tun, dürfte es nur wenige geben.

Das ist eine sehr interessante Antwort.

Bitte korrigiere mich, wenn ich Dich missverstehe. -- Ich
lese aus Deiner Anwort drei Gedanken heraus (oder inter-
pretiere sie hinein -- wie man will):

1. Du bietest eine Erklärung für den von mir geschilderten
Sachverhalt an. Das bedeutet implizit, dass Du meine
Darstellung (dass sich nämlich niemand wirklich um die
Interoperabilität über Projektgrenzen hinweg schert) im Kern
für zutreffend hältst.

2. Du widersprichst meinem Wunsch nach mehr Interoperabilität
nicht. Das heißt für mich: Hier spricht nicht (nur) meine
subjektive, völlig fehlgeleitete Wahrnehmung, sondern hier
steckt möglicherweise ein WIRKLICHES Problem, mit dem noch
andere Leute außer mir kämpfen.

3. Im Grunde hast Du ja nur die Binsenweisheit "FOSS-
Programmierer programmieren genau das, was sie selbst haben
und benutzen wollen" auf den konkreten Fall angewendet. (Die
Formel scheint mir im Großen und Ganzen auch zuzutreffen;
sie erklärt zumindest, warum es deutlich mehr Compiler als
fehlerfreie WYSIWYG-Bürosoftware gibt.)
Daraus ergibt sich: Die Chancen, Mitglieder des Kernteams
eines Projektes zu mehr Interoperabilität zu überreden,
sind begrenzt. Dinge, die fehlen, werden eher ins eigene
Projekt aufgenommen, als die Möglichkeit zu schaffen, sie
"außerhalb" zu erledigen.

Man müsste also von außen her, d.h. als Nicht-Projektmitglied
sehen, was man tun kann.

Autor: Possetitjel (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Leute, Leute schrieb:

> Possetitjel schrieb:
>> Ist Dir das Diffamieren fremder Leistungen tatsächlich SO
>> wichtig, dass am Ende keine Energie mehr über bleibt, ein
>> Sachargument zu formulieren?
>
> Ich diffamiere hier niemandem.

Hmm.

Lass mich bitte als Vorrede folgendes feststellen: Ich
bin infolge gewisser Akkumulation von Lebenserfahrung
inzwischen ein Verfechter des Prinzips "Erkläre nichts
durch bösen Willen, was durch Blödheit hinreichend erklärt
ist".

Daher bemühe ich mich weiterhin, Dir keine pure Lust an
der Beleidigung zu unterstellen, sondern gehen davon aus,
dass Du TATSÄCHLICH NICHT MERKST, dass jeder zweite Satz
von Dir eine Unverschämtheit ist.

> Mal abgesehen davon, was erwartest du?

Reden wir mal nicht von "erwarten", bleiben wir bei "wünschen":

Ich wünsche mir, dass Du beginnst, zwischen Deinem persönlichen
Frust auf der einen und den Sachargumenten auf der anderen
Seite zu unterscheiden.

> Ich gab meine Meinung dazu ab und Meinungsfreiheit besteht
> doch hoffentlich noch oder etwa nicht mehr?!

Die Meinungsfreiheit besteht aber "leider" auch für die
Leute, die Dich für einen Rüpel und Pöbelmeier halten und
dies auch deutlich zum Ausdruck bringen.

> Vergleiche einfach mal mit der Verbesserung über die Zeit
> bei anderer EDA SW, wie wenig wirklich neues hinzukommt und
> wieviel Bugs ausgeräumt werden müssen, die die Anwender
> nerven. Das willst du dir nicht freiwillig antun.

Das ist ja eine durchaus zutreffende Beobachtung. Auch wenn
ich den Frust (vermutlich besser, als Du glaubst) verstehen
kann -- bist Du WIRKLICH der Meinung, Lukas hört Dir zu, wenn
Du ihn im Wesentlichen mit Beleidigungen überschüttest?

Vergessen wir nicht: Er hat diesen Faden aufgemacht, um sein
Projekt vorzustellen.

> Und achte mal darauf, wer welche Ausreden benutzt, um die
> SW des TE erst gar nicht anzufassen.

Schon wieder: "Ausreden".

Du unterstellst SOFORT Unredlichkeit, ohne auch nur den
Versuch zu unternehmen, den Gegenüber zu verstehen (nein,
ich meine nicht "auf nette Weise Verständnis heucheln", ich
meine: Echtes Verstehen. Ganz altmodisch.)


So -- abseits der Formfragen: Du machst meiner Meinung nach
einen Fehler, wenn Du kommerzielle und freie Software in
einen Topf wirfst.
Natürlich sind die Probleme für den Anwender in beiden
Fällen dieselben -- nämlich mangelnde Interoperabilität
unterschiedlicher Produkte. Die Ursachen sind aber verschieden:
Bei kommerzieller Software ist der "Vendor-lock-in" gewolltes
und erklärtes Ziel; man umschreibt das höflich als "Kunden-
bindung".
Bei freier Software ist es lediglich die Folge der Mentalität
der Programmierer.

Ich halte diesen kleinen, aber feinen Unterschied für wichtig:

Es ist eine Sache, wenn Programmierer nicht unbedingt von
sich aus auf Interoperabilität hinarbeiten -- wer in einem
Projektteam mitarbeitet, will ja DIESES Projekt voranbringen,
und nicht dafür sorgen, dass der Anwender ebensogut auch eine
andere Software benutzen kann :)

Eine völlig andere Geschichte wäre es aber, sich der Zusammen-
arbeit mit dem "EDA Interoperability Project" zu verweigern,
wenn es denn ein solches gäbe.
Das ist meiner Meinung nach der Punkt, an dem man ansetzen
muss.

Autor: Possetitjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan S. schrieb:

> Possetitjel schrieb:
>> Ich spiele gelegentlich damit herum. -- Das Projekt [gEDA]
>> scheint sich totgelaufen zu haben. Kennt jemand Hintergründe?
>
> Da gibt es eine vielzahl von Gründen. [...]

Danke; ungefähr so etwas hatte ich vermutet.

> Wobei es seit gut einem Jahr wohl ein neues Project PCB-RND
> bzw. gEDA-RND gibt.

Tausend Dank für diesen Hinweis.

Es scheint so zu sein, dass es das Projekt faktisch seit
ungefähr 2013 gibt, nur "offiziell" ist der Fork erst seit
Kurzem.

Verblüffend: Für pcb-rnd gibt's ein Debian-Paket (ab 9.x).

Das Kernteam ist zwar mit 8 Leuten ziemlich klein, scheint
aber aktiv zu sein. Noch ist also nicht alles verloren :)

Mal schauen.

Autor: Leute, Leute (Gast)
Datum:

Bewertung
-8 lesenswert
nicht lesenswert
Possetitjel schrieb:
> Lass mich bitte als Vorrede folgendes feststellen: Ich
> bin infolge gewisser Akkumulation von Lebenserfahrung
> inzwischen ein Verfechter des Prinzips "Erkläre nichts
> durch bösen Willen, was durch Blödheit hinreichend erklärt
> ist".

Deine Lebensweisheiten behalte bitte für dich.

> Daher bemühe ich mich weiterhin, Dir keine pure Lust an
> der Beleidigung zu unterstellen, sondern gehen davon aus,
> dass Du TATSÄCHLICH NICHT MERKST, dass jeder zweite Satz
> von Dir eine Unverschämtheit ist.

Deine Unterstellung ist eine Unverschämtheit. Greife dir bitte mal an 
die eigene Nase.

>> Mal abgesehen davon, was erwartest du?

Hier in diesem Forum erwarte ich absolut nichts mehr. Ich gebe hier dann 
und wann nur noch meine Meinung zum besten.

> Reden wir mal nicht von "erwarten", bleiben wir bei "wünschen":
>
> Ich wünsche mir, dass Du beginnst, zwischen Deinem persönlichen
> Frust auf der einen und den Sachargumenten auf der anderen
> Seite zu unterscheiden.

Schon wieder eine Unterstellung. Merkst du eigentlich, dass du hier 
anderen den Umgangston anmahnst und selber zu Unverschämtheiten greifst?

>> Ich gab meine Meinung dazu ab und Meinungsfreiheit besteht
>> doch hoffentlich noch oder etwa nicht mehr?!
>
> Die Meinungsfreiheit besteht aber "leider" auch für die
> Leute, die Dich für einen Rüpel und Pöbelmeier halten und
> dies auch deutlich zum Ausdruck bringen.

Ich will dir mal was sagen, wenn man hier nicht mal mehr feststellen 
kann, dass gewisse YouTube Videos einfach eine Zumutung sind, dann ist 
es traurig um uns alle bestellt. Seid ihr inzwischen so vergutmenschelt, 
so empfindlich geworden, dass man euch das nicht mehr sagen darf? Ist 
dieses Land mittlerweile total verweichlicht? Auf der anderen Seite 
reagieren Gutmenschen wie ihr bei jeder kleinen Kritik dann sofort mit 
Schaum vorm Mund und Beleidigungen. Wie reagierst du denn 
beispielsweise, wenn ein talentloser Sänger auf der Bühne meint er sei 
ein toller Hecht. In Wahrheit aber ist der Kerl nur eine akustische 
Zumutung. Lobst du ihn dann vor deinen Kumpels über Klee, weil er's 
"doch irgendwie probiert hat und dafür Anerkennung verdient"? Meinst du, 
du tust so einem Menschen damit einen Gefallen?

> bist Du WIRKLICH der Meinung, Lukas hört Dir zu, wenn
> Du ihn im Wesentlichen mit Beleidigungen überschüttest?

Nochmal zum Mitschreiben für dich, ich habe hier niemanden beleidigt. 
Ich habe bloß zwei Dinge angemerkt, nämlich

1. der Vortrag tut mir in den Ohren weh (zu deinem Trost, die meisten 
Youtuber können keine gescheiten Vorträge abliefern)

2. ein 1-Mann-EDA-Projekt wird NIEMANLS was werden. Dazu ist 
EDA-Software einfach zu komplex.

Wo ist da bitte jetzt die Beleidigung?

> Vergessen wir nicht: Er hat diesen Faden aufgemacht, um sein
> Projekt vorzustellen.

Und wozu dann, wenn ihn Kommentare nicht interessieren? Geht's ihm dann 
um Lobhudelei?

Wir sind hier nun mal nicht auf bzw. in der Walldorfschule. Zwischen gut 
gemeint und gut gemacht liegt oftmals ein großer und entscheidender 
Unterschied. Wer so viel Zeit und Power über hat sollte die besser für 
sinnvolleres einsetzen (was er natürlich darf, aber ich muss es ja nicht 
gut finden oder?!).

Da es aber wie meistens völlig sinnlos ist hier weiter zu kommentieren 
beenden wir das Thema halt. Die Zeit wird zeigen wer recht behält. Hier 
ist übrigens schon mal einer erschienen der (angeblich) eine EDA SW 
erstellen wollte. Daraus wurde auch nix.

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Leute, Leute schrieb:

>> Lass mich bitte als Vorrede folgendes feststellen: Ich
>> bin infolge gewisser Akkumulation von Lebenserfahrung
>> inzwischen ein Verfechter des Prinzips "Erkläre nichts
>> durch bösen Willen, was durch Blödheit hinreichend erklärt
>> ist".
>
> Deine Lebensweisheiten behalte bitte für dich.

Aber Deine eigene Lebenserfahrung soll hier als guter Rat taugen?
Warum nur Deine, aber nicht die von Possetitjel oder Jörg?
Doppelmoral?

> Deine Unterstellung ist eine Unverschämtheit. Greife dir bitte mal an
> die eigene Nase.

Der Ton macht die Musik, und Du hast den Ton zuerst angeschlagen.

> 1. der Vortrag tut mir in den Ohren weh (zu deinem Trost, die meisten
> Youtuber können keine gescheiten Vorträge abliefern)

Ich tue mir Videos nur im Notfall an. Text/Grafik ist mir lieber.
Videos erfordern eine zu hohe Konzentration.

> 2. ein 1-Mann-EDA-Projekt wird NIEMANLS was werden. Dazu ist
> EDA-Software einfach zu komplex.

Als Projekt sicher nicht. Trozdem wird derjenige, der sich in dieser 
Form damit befasst, eine Menge lernen.
1) Über Programmieren
2) Darüber, wie Schaltungen entwickelt werden, und wie man Platinen 
layoutet.
3) Wie Platinen in der Fabrik hergestellt werden
4) Über sich selber.

Unter diesen Aspekten sehr sinnvoll.

> Wo ist da bitte jetzt die Beleidigung?

Die steckt im Tonfall und in Deiner Missachtung der Tatsache, dass es 
noch andere als die von Dir angeführten Gründe gibt. ;O)

> Wir sind hier nun mal nicht auf bzw. in der Walldorfschule.

Und das ist auch gut so <grusel> ....trozdem macht auch hier der Ton die 
Musik, und wenn Du halt als testosteronschwangerer Vollmacho rumtrötest, 
musst Du Dich wegen des Zurücktrötens nicht wundern.
Wenn ein Hirsch im Wald röhrt, wird schon ein anderer antworten. ;O)

Nicht das mich der Krach stört, aber konstruktiv ist halt was anderes.

> Wer so viel Zeit und Power über hat sollte die besser für
> sinnvolleres einsetzen (was er natürlich darf, aber ich muss es ja nicht
> gut finden oder?!).

Es steht Dir nicht an, darüber zu Urteilen, wie andere Leute ihr Leben 
einrichten. Abgesehen davon, das es viele verschiedene gleichberechtigte
Ansichten geben wird, spielt da viel zu viel Zufall und Kompromiss 
hinein, um ein Hineinreden zu rechtfertigen. Wir alle kennen die Deteils 
der Hintergründe und Randbedingungen des TO nicht. Dein Rat könnte zwar 
möglicherweise willkommen sein, aber wer in diesem Tonfall rät, will in 
wirklichkeit Kommandieren.
Persönlich sehe ich es eher als Hybris, wenn man den Versuch macht, sein 
Leben zu planen.

> Die Zeit wird zeigen wer recht behält. Hier
> ist übrigens schon mal einer erschienen der (angeblich) eine EDA SW
> erstellen wollte. Daraus wurde auch nix.

Na und? Ich habe auch mal mit sowas herumgespielt. Ist stecken 
geblieben. War aber lehrreich und hat Spass gemacht.
Jetzt habe ich es auch seit Jahren nicht mehr angefasst, obwohl es mich 
hin und wieder kitzelt.
Und, wenn die Umstände günstiger (oder ungünstiger, 
interpretationsfrage) sind, mache ich das vieleicht auch wieder. Ich 
habe aber auch nie erwartet, dass etwas grossartiges dabei heraus 
kommt.**)
Damit Du nicht meinst, ich wüsste nicht, wovon ich spreche, hier der 
Link darauf: 
https://www.mikrocontroller.net/wikifiles/5/5a/PyG...

Leute, Leute schrieb:

> Mir reichen übrigens meine Quirks bei Diptrace. Mit denen kann ich
> einigermaßen leben.

Liegt hier der Hase im Pfeffer? Machst Du in Wirklichkeit Werbung auf 
eine unterschwellige Art und Weise? ;O)
Irgendwie habe ich aber den Verdacht, als Werbung ist das auch ein 
Schuss in den Ofen. ;O)

**) Immerhin hätte ich durch die Beschäftigung damit zweimal fast eine 
Stelle bekommen. ;O)

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

: Bearbeitet durch User
Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Lukas,

Ich habe mit WIN7 und WIN10 getestet.

Ich wollte in Rules -> Copper Clearance die 0,1mm ändern. Seit dem 
Versuch sind da nur noch 0.000mmm egal welche Zahl ich eintippe. Im 
Layout werden dadurch pads und traces in planes nicht mehr ausgespart. 
Übrigens scheint die eingebaute Abstandsfunktion fälschlicher Weise die 
Mitte der Traces zu nehmen statt deren Rand.

Das ist jetzt für mich nicht tragisch, weil ich eh nur die Bedienung 
teste. Gibt es eine Liste welche Funktionen nicht gehen aber bereits ein 
Fenster öffnen?

Dein Demo-Projekt funktioniert nicht in WIN7,10. Da kommt die 
Fehlermeldung:
Error opening project
parse error - unexpected '<'
OK

Gruß
Helmut

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich wollte in Rules -> Copper Clearance die 0,1mm ändern. Seit dem
Versuch sind da nur noch 0.000mmm egal welche Zahl ich eintippe.

Hab mal nochmals versucht den Wert zu ändern. Ergebins: Man kann nur 
ganze Millimeter eingeben, z. B. 1, 2... bis 100mm. 1mm will ich 
natürlich da nie haben. Scheint ein echter Bug zu sein.

: Bearbeitet durch User
Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ins Blaue gefragt: Könnte das ein Dezimalpunkt ./. Dezimalkomma-Problem 
sein? Versuch mal, statt "0.1" "0,1" einzugeben, oder umgekehrt.

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Ins Blaue gefragt: Könnte das ein Dezimalpunkt ./. Dezimalkomma-Problem
> sein? Versuch mal, statt "0.1" "0,1" einzugeben, oder umgekehrt.

Hallo Rufus,
danke, das hat geholfen. Wenn ich 0,2 eintippe statt 0.2, dann 
funktioniert es. Angezeigt wird dann 0.200.

Autor: Helmut S. (helmuts)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
1.

> Übrigens scheint die eingebaute Abstandsfunktion fälschlicher Weise die
Mitte der Traces zu nehmen statt deren Rand.


Diese Aussage ziehe ich zurück. Der Abstand wird richtig berechnet.

Dafür habe ich ein anderes Problem. Wenn ich in dem Fall im angehängten 
screenshot ein Update Planes mache, dann bleibt von dem gefüllten 
Polygon nur noch eine einzige vertikale Linie an dessen ursprünglich 
linkem Rand übrig. Auch ein erhöhen der Priorität hat da nicht geholfen. 
Was mache ich da falsch?


2.

> KiCad's awesome push'n shove router

Bei mir schiebt wird da nichts geschoben.
Wo schaltet man den in horizon ein?

: Bearbeitet durch User
Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit den Dezimaltrenner ist nun repariert.

Helmut S. schrieb:
> 1.
>
>> Übrigens scheint die eingebaute Abstandsfunktion fälschlicher Weise die
> Mitte der Traces zu nehmen statt deren Rand.
>
>
> Diese Aussage ziehe ich zurück. Der Abstand wird richtig berechnet.
>
> Dafür habe ich ein anderes Problem. Wenn ich in dem Fall im angehängten
> screenshot ein Update Planes mache, dann bleibt von dem gefüllten
> Polygon nur noch eine einzige vertikale Linie an dessen ursprünglich
> linkem Rand übrig. Auch ein erhöhen der Priorität hat da nicht geholfen.
> Was mache ich da falsch?
>

Ich kann jetzt auf dem Bild nicht erkennen, zu welchen Netzen der Track 
da rechts und die Plane gehören. Gehören die zum selben Netz? Wenn ja, 
muss die Mittellinie das Tracks (derzeit) innerhalb (nicht auf der 
Kante) des Polygons liegen, damit die als verbunden erkannt werden. Wenn 
die Plane sonst nirgendwo angeschlossen ist, wird die nicht gefüllt, 
wenn orphans deaktiviert sind.

> 2.
>
>> KiCad's awesome push'n shove router
>
> Bei mir schiebt wird da nichts geschoben.
> Wo schaltet man den in horizon ein?
Die Shove-Funktionalität wird derzeit von horizon noch nicht 
unterstützt, ich hab' mal die Doku angepasst...

Helmut S. schrieb:
> Dein Demo-Projekt funktioniert nicht in WIN7,10. Da kommt die
> Fehlermeldung:
> Error opening project
> parse error - unexpected '<'

Seltsam, in der Projektdatei ist kein '<' enthalten: 
https://github.com/carrotIndustries/horizon-test-p... 
Hast du auch das Zip heruntergeladen und entpackt? Das '<' sieht mir 
doch nach einer HTML-Datei aus.

Autor: Frank K. (frank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

welche Abhängigkeit bringt die profile.h Datei mit?
[  118s] router/router/pns_shove.cpp:44:10: fatal error: profile.h: No such file or directory
[  118s]  #include <profile.h>
[  118s]           ^~~~~~~~~~~

Gruß,
Frank

: Bearbeitet durch User
Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> Hallo,
>
> welche Abhängigkeit bringt die profile.h Datei mit?
>
>
> [  118s] router/router/pns_shove.cpp:44:10: fatal error: profile.h: No 
> such file or directory
> [  118s]  #include <profile.h>
> [  118s]           ^~~~~~~~~~~
> 
>
> Gruß,
> Frank

Ist entfernt, war ein Überbleibsel aus dem KiCad-Tree, der auf meinem 
System dann wohl von Kerberos bereitgestellt wurde...

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Lukas,

1.
Das mit dem Update Planes funktioniert jetzt auch mit den traces entlang 
und in der plane. Am Anfang ging es nicht. Vielleicht habe ich einfach 
etwas falsch bedient.


2.
> Seltsam, in der Projektdatei ist kein '<' enthalten:
https://github.com/carrotIndustries/horizon-test-p...
Hast du auch das Zip heruntergeladen und entpackt? Das '<' sieht mir
doch nach einer HTML-Datei aus.


Ich habe das Demo-Projekt als Einzeldateien heruntergeladen.
Wo gibt es da einen zip-file?


2.
Wo ist eigentlich das GND-Symbol im Schaltplaneditor? Ich finde es 
nicht.

: Bearbeitet durch User
Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut S. schrieb:
> Hallo Lukas,
>
> 1.
> Das mit den Update Planes funktioniert jetzt auch mit den traces entlang
> und in der Plane. Am Anfang ging es nicht. Vielleicht habe ich einfach
> etwas falsch bedient.

Ist in der aktuellsten Version auch repariert ;)

>
> 2.
>> Seltsam, in der Projektdatei ist kein '<' enthalten:
> https://github.com/carrotIndustries/horizon-test-p...
> Hast du auch das Zip heruntergeladen und entpackt? Das '<' sieht mir
> doch nach einer HTML-Datei aus.
>
>
> Ich habe das Demo-Projekt als Einzeldateien heruntergeladen.
> Wo gibt es da einen zip-file?

https://github.com/carrotIndustries/horizon-test-project

Bei dem grünen Knopf "Clone or Download" gibt es die Option "Download 
ZIP".

>
> 2.
> Wo ist eigentlich das GND-Symbol im Schaltplaneditor? Ich finde es
> nicht.
Die GND-Symbole sind deutlich anders gelöst als in anderen 
Applikationen: 
https://github.com/carrotIndustries/horizon/wiki/S...

Autor: Frank K. (frank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Compilieren geht soweit, jedoch weigert sich rpmbuild ein Package zu 
erstellen da noch ein paar Warnings im Code sind:
[  313s] I: Program is using uninitialized variables.              
[  313s]    Note the difference between "is used" and "may be used"                                                                   
[  313s] W: horizon uninitialized-variable dxflib/dl_entities.h:1449                                                                  
[  313s]                         
[  313s] I: Program returns random data in a function              
[  313s] E: horizon no-return-in-nonvoid-function rules/rule_match.cpp:90                                                             
[  313s]                         
[  313s] I: Program returns random data in a function              
[  313s] E: horizon no-return-in-nonvoid-function rules/rule_match.cpp:90

Gruß,
Frank

Autor: W.S. (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Horizon is a free EDA package ...

Nach Monaten des Schweigens kommt dieses Horizon wieder in die 
Diskussion. Na fein, sagt unsereiner sich...

..aber wenn man sich mal die zugehörige Seite
"https://github.com/carrotIndustries/horizon";
anschaut, dann landet man in einer hoffnungslos mit LowLevel-Details 
überfrachteten Seite.

Wo ist da der Anfang?
Wo ist da die nötige Struktur?
Erwartet der Autor, daß man sich als eventueller Interessent durch alle 
Details (block, board, canvas, canvas3d, clipper, ...) durchwühlt?
Nee, Leute. So wird das nix bis ewig.
Ein simples blinky.c kann jeder auch ohne jegliche Projektplanung 
schreiben, aber bei einem Projekt wie ein komplettes EDA-System es 
darstellt, braucht es ganz am Anfang ein gut durchdachtes und 
schriftlich fixiertes Konzept und die Struktur des Ganzen. Wer das nicht 
formulieren will oder kann, der wird unweigerlich scheitern.

Und wenn man dann sowas lesen darf:
"Seems like people really want to have Windows binaries, so I made 
some: horizon-zip"
...dann vergeht einem die Lust, die 34 MB herunterzuladen und eventuell 
sogar auch noch auszuprobieren.

Also: Es fehlt das Konzept. Mal wieder. Ich hatte dies ja bereits bei 
Diptrace angemahnt, später ebenfalls bei Kicad. Aber es ist wohl immer 
so bei hochambitionierten Programmierern, daß sie ihr Baby nur nach 
ihren eigenen Gesichtspunkten bepflegen, keinen wirklichen Blick für die 
eventuellen Anwender haben und auf die Frage nach ihrem Konzept mit 
persönlicher Beleidigtheit reagieren.

Also Horizon ist offenbar dediziert NICHT für Windows-Benutzer gedacht.

Auch eine echte Darstellung, wie Horizon denn überhaupt funktioniert, 
also wie das Zusammenspiel zwischen Schematics, Layout und anderen 
Teilen wie Bibliotheken, Rulechecks (erc, drc, hf, therm, usw.) 
organisiert ist, glänzt durch vollständige Abwesenheit. Von einem 
User-Manual will ich erst garnicht reden.

Auch von angedachten Interfaces zu Dingen, die über den gewöhnlichen 
Kram hinausgehen, wie z.B. distributed elements, Feldanalysen usw. kann 
man nichts lesen. Jaja, unsereiner wäre durchaus an einem ECAD 
interessiert, das wenigstens ansatzweise die Dinge, die man mit Ansoft 
oder Sonnet sich gestalten kann, importieren oder wenigstens nachbilden 
kann. Aber das wären ja wieder Dinge aus der vernachlässigbaren 
Windows-Ecke...

Nein, Horizon ist keineswegs "a free EDA package", sondern bislang nur 
ne Art Fingerübung die so tut, als ob sie sowas wäre. Der einzigen Rat, 
den ich hier geben könnte würde lauten: der/die Autoren täten besser, 
wenn sie ihre Arbeitskraft einsetzen würden, um Kicad vom Kopf auf die 
Füße zu stellen, also dessen Geburtsfehler ausmerzen. Das wäre 
zielführender.

W.S.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> Compilieren geht soweit, jedoch weigert sich rpmbuild ein Package zu
> erstellen da noch ein paar Warnings im Code sind:

Sind repariert.

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Lukas,

mit dem zip-download funktioniert das Demo-design.

Das Power-Symbol für GND bekomme ich jetzt auch hin nach deinem letzten 
Hinweis.

Die clearance rules werden jetzt mit',' angezeigt.

Ich möchte bei einigen traces die Breite ändern.
Warum ist eigentlich im Layout das Feld für Track->width grau(nicht 
änderbar)?

Gruß
Helmut

: Bearbeitet durch User
Autor: Lukas K. (carrotindustries)
Datum:

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

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

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Helmut S. schrieb:
>> Warum ist eigentlich im Layout das Feld für Track->width grau(nicht
>> änderbar)?
>
> Das liegt daran, dass der Schalter "Width from rules" an ist. Damit
> werden die Leiterbahnbreiten entsprechend der Regeln unter "Track Width"
> gesetzt. Wie bei allen anderen Regeln auch wird die angewendet, die als
> erstes zutrifft.

Danke, darauf hätte ich selber kommen sollen. :-)

Das Kupfer geht ja bis zur Boardkante bei dem Demoboard. Das solltest 
mal ändern und z. B. 0,8mm Abstand einbauen. Muss dazu die GND-plane 
verkleinert werden oder gibt es eine "routing outline"?

: Bearbeitet durch User
Autor: Helmut S. (helmuts)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Für Windows-Benutzer

Hier loslegen
https://github.com/carrotIndustries/horizon

Ganz unten auf der Seite
"Getting Started" > See the "wiki"
Dann ist man hier.
https://github.com/carrotIndustries/horizon/wiki/G...

"Get Horizon"
Windows -> "here" -> horizon.zip -> neueste Version nehmen.
Die zip-Datei in einem beliebigen Verzeichnis entpacken, z. B. 
C:\horizon


Wieder auf diese Seite gehen:
https://github.com/carrotIndustries/horizon/wiki/G...
Get the pool -> download the zipped pool
Auch in C:\horizon speichern und dort entpacken.

https://github.com/carrotIndustries/horizon/wiki/G...
"Open the project manager"
C:\horizon\horizon\horizon-prj-mgr.exe starten.
Siehe Wiki wie man den "pool" anlegt.
Dabei dort pool.json in C:\horizon\horizon-pool-master wählen.
C:\horizon\horizon-pool-master

Jetzt kann man entweder mit einem Schaltplan starten.

Am besten erst noch das Demo-Design laden.

Den Link zum Demo-Design gibt es unter "Example project".
https://github.com/carrotIndustries/horizon-test-project
"Clone or download" wählen -> Download zip
Den in C:\horizon speichern und auspacken.

Open Project -> C:\horizon\horizon-test-project-master\pic32-eth.hprj

Jetzt auf Top Schematic und/oder Board klicken.

: Bearbeitet durch User
Autor: Possetitjel (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
W.S. schrieb:

> Ein simples blinky.c kann jeder auch ohne jegliche
> Projektplanung schreiben, aber bei einem Projekt wie
> ein komplettes EDA-System es darstellt, braucht es
> ganz am Anfang ein gut durchdachtes und schriftlich
> fixiertes Konzept und die Struktur des Ganzen.

Naja, was hältst Du von folgender Interpretation:

Du brauchst (genauso wie ich) für alles, was komplizierter
als blinky.c ist, ein durchdachtes Konzept.

Lukas hat (nach eigener Aussage) bisher 26'000 Zeilen Code
geschrieben (und brauchte offenbar kein Konzept).

Also ist "horizon" für Lukas nicht komplizierter als für
uns blinky.c.

Betrüblich für uns, aber erfreulich für Lukas :)

> Also: Es fehlt das Konzept. Mal wieder. Ich hatte dies ja
> bereits bei Diptrace angemahnt, später ebenfalls bei Kicad.

Niemand will Probleme. Alle wollen Lösungen. Gilt auch für
Programmierer.
Und im Hobby will man sich ganz sicher von niemandem mahnen
lassen.

> Aber es ist wohl immer so bei hochambitionierten
> Programmierern, daß sie ihr Baby nur nach ihren eigenen
> Gesichtspunkten bepflegen, keinen wirklichen Blick für
> die eventuellen Anwender haben

Entschuldigung: Hat Lukas IRGENDWO zugesichert, dass er Dich,
mich oder die Welt mit seinem Programm glücklich machen will?

Ich wüsste nicht, wo.

Er sagt in seinem Vortragsvideo nur: Er sei mit den vorhandenen
EDA-Programmen nicht zufrieden gewesen und hätte daher begonnen,
sein eigenes zu schreiben. Genau das tut er.

Jetzt braucht er Tester, und deswegen bittet er darum, das
Programm zu testen.

> Auch eine echte Darstellung, wie Horizon denn überhaupt
> funktioniert,

Wozu?
Hat Lukas IRGENDWO um Hilfe beim Programmieren gebeten?

> Nein, Horizon ist keineswegs "a free EDA package", sondern
> bislang nur ne Art Fingerübung die so tut, als ob sie sowas
> wäre.

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

> Der einzigen Rat, den ich hier geben könnte würde lauten:
> der/die Autoren täten besser, wenn sie ihre Arbeitskraft
> einsetzen würden, um Kicad vom Kopf auf die Füße zu stellen,
> also dessen Geburtsfehler ausmerzen. Das wäre zielführender.

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

Nee, also ganz ehrlich: Für die Software, die DU gerne haben
willst, musst schon DU SELBST das Projekt auf die Beine stellen.
(Das bedeutet nicht zwingend, dass Du auch alles selbst
programmieren musst.)

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut S. schrieb:
> Das Kupfer geht ja bis zur Boardkante bei dem Demoboard. Das solltest
> mal ändern und z. B. 0,8mm Abstand einbauen. Muss dazu die GND-plane
> verkleinert werden oder gibt es eine "routing outline"?

Genau da bin ich gerade dran ;) Aus der "Clearance Copper - NPTH"-Regel 
wird eine "Copper - Non copper Regel", die dann den Abstand von 
Kupferdingen, wie Track, Plane, etc. zu Nicht-Kupferdingen wie 
NPTH-Löchern und eben Boardkante beschreibt.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Possetitjel schrieb:

> Lukas hat (nach eigener Aussage) bisher 26'000 Zeilen Code
> geschrieben (und brauchte offenbar kein Konzept).

Wer sagt denn, dass er kein Konzept hat?

Ein solches muss ja nicht zwingend irgendwo aufgeschrieben sein,
vor allem dann nicht, wenn man es als One-Man-Show startet.  Dafür
reicht ein Konzept im Kopf völlig aus.

Auch KiCad ist mal als One-Man-Show gestartet worden …

Wenn ich mal mein OS (und damit auch den Compiler) aktualisiert habe,
schau ich mir Horizon auf jeden Fall auch mal an.  Vermutlich wird
Lukas dann von mir als erstes einen Satz Patches für FreeBSD erhalten. 
:-)

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Auch KiCad ist mal als One-Man-Show gestartet worden …

Das wollte ich gerade schreiben. Bis auf sehr wenige Teile, die von 
seinen Studenten beigesteuert wurden, hat der gute Jean-Pierre das bis 
2006 ganz alleine aus dem Boden gestampft.

Und 2006 war es definitiv benutzbar, denn zu dem Zeitpunkt bin ich 
damals von Eagle zu Kicad gewechselt (u.a. wegen fehlender 
Hierarchie-Möglichkeiten) und habe nicht wirklich etwas vermisst - 
insbesondere nicht die Einschränkungen bei Eagle ;-)

Es ist wie immer: viele reden und haben überall Bedenken - und die 
anderen fangen einfach mal an.

Also: dass man für eine brauchbare ECAD-Software ein vielköpfiges, 
permanentes Entwicklerteam benötigt, ist offenbar falsch.

> Wenn ich mal mein OS (und damit auch den Compiler) aktualisiert habe,
> schau ich mir Horizon auf jeden Fall auch mal an.  Vermutlich wird
> Lukas dann von mir als erstes einen Satz Patches für FreeBSD erhalten.
> :-)

Wir sind mit Kicad zufrieden, aber trotzdem ist das ein tolles Projekt.

Hut ab vor Deiner Leistung, Lukas!

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Wer sagt denn, dass er kein Konzept hat?
>
> Ein solches muss ja nicht zwingend irgendwo aufgeschrieben sein,
> vor allem dann nicht, wenn man es als One-Man-Show startet.  Dafür
> reicht ein Konzept im Kopf völlig aus.

Genau so ist's. Das "Konzept" ist ja auch nichts feststehendes, sondern 
mehr etwas, das sich im Laufe der Zeit an neue Gegebenheiten und 
Gelerntes anpasst. Was aufgeschriebenes wäre derzeit eh nach kürzester 
Zeit veraltet. Führt halt dazu, dass man einige Dinge mehrfach 
grundlegend überarbeiten muss. Ganz ohne Plan läuft die Entwicklung auch 
nicht ab, siehe eine der letzten Folien aus dem Vortrag:

Aktuelle / Zeitnahe Entwicklungen
=================================

• DRC, Verbesserung des Routers
Insb. ersteres ist geschehen. Ohne mir jetzt alle Opensource-EDA 
Applikationen im Detail angesehen zu haben, behaupte ich mal, 
mittlerweile, das leistungsfähigste und flexibelste Regelsystem zu 
haben.

• Netzklassen aufräumen
Ist geschen.

• Layer erweitern
Ebnefalls.

• Kupferflächen füllen
Auch.

Zukunft
=======

• ERC
Gibt's noch nicht wirklich, ist auch mehr Arbeit als kompliziert zu 
implementieren.


• 3D-Export/Darstellung
3D-Darstellung (ohne Bauteile) gibt's. Seit gestern auch mit Innenlagen. 
3D-Export wird darauf hinauslaufen kicad2step zu portieren: 
https://github.com/KiCad/kicad-source-mirror/tree/...

• GUI für Pool, Entities, etc.
Gibt's.

• Parametrische Suche
War noch nicht wichtig genug, ist aber auch mehr ein nice-to-have.

• Integration des KiCAD-Routers
Ist geschehen, wenn auch noch Dinge wie Routen von diffpairs und 
length-tuning noch nicht unterstützt werden. (Shove ist so gut wie 
fertig)

Chris D. schrieb:
> Hut ab vor Deiner Leistung, Lukas!

Danke an dich und einige andere für die netten Worte!

Autor: Possetitjel (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:

> Possetitjel schrieb:
>
>> Lukas hat (nach eigener Aussage) bisher 26'000 Zeilen
>> Code geschrieben (und brauchte offenbar kein Konzept).
>
> Wer sagt denn, dass er kein Konzept hat?

Och, Menno.

Das sagt niemand -- das war nur eine notwendige Annahme,
damit mein boshafter Vergleich funktioniert.

Autor: Helmut S. (helmuts)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Lukas,

in deiner neuesten Version für WIN stürzt horizon-imp.exe bei "Update 
Planes" ab. Bitte wieder lauffähig machen.

Version: horizon-2017-10-23-1433.zip


Gruß
Helmut

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut S. schrieb:
> in deiner neuesten Version für WIN stürzt horizon-imp.exe bei "Update
> Planes" ab. Bitte wieder lauffähig machen.

Bis die neue Version kompiliert ist, reicht's wenn du in den Rules bei 
Copper - Non-Copper Clearance was einträgst. Ohnehin sollte da was drin 
stehen, damit auch was sinnvolles verwendet wird.

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Helmut S. schrieb:
>> in deiner neuesten Version für WIN stürzt horizon-imp.exe bei "Update
>> Planes" ab. Bitte wieder lauffähig machen.
>
> Bis die neue Version kompiliert ist, reicht's wenn du in den Rules bei
> Copper - Non-Copper Clearance was einträgst. Ohnehin sollte da was drin
> stehen, damit auch was sinnvolles verwendet wird.

Hallo Lukas,

danke. Damit funktioniert "Update Planes" wieder.

Gruß
Helmut

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Horizon is a free EDA package ...
>
> Nach Monaten des Schweigens kommt dieses Horizon wieder in die
> Diskussion. Na fein, sagt unsereiner sich...
>
> ..aber wenn man sich mal die zugehörige Seite
> "https://github.com/carrotIndustries/horizon";
> anschaut, dann landet man in einer hoffnungslos mit LowLevel-Details
> überfrachteten Seite.

Links oben auf der Seite gibt's den Punkt Issues...

> ... bei einem Projekt wie ein komplettes EDA-System es
> darstellt, braucht es ganz am Anfang ein gut durchdachtes und
> schriftlich fixiertes Konzept und die Struktur des Ganzen. Wer das nicht
> formulieren will oder kann, der wird unweigerlich scheitern.

Allumfassende, am besten noch perfekte Konzepte? Viel Spaß in der 
Realität...
Im besten Fall gibt's genügend Zeit/Geld, um mehrere Iterationen zu 
machen, die sich dem annähern

> Also: Es fehlt das Konzept. Mal wieder. Ich hatte dies ja bereits bei
> Diptrace angemahnt, später ebenfalls bei Kicad. Aber es ist wohl immer
> so bei hochambitionierten Programmierern, daß sie ihr Baby nur nach
> ihren eigenen Gesichtspunkten bepflegen, keinen wirklichen Blick für die
> eventuellen Anwender haben und auf die Frage nach ihrem Konzept mit
> persönlicher Beleidigtheit reagieren.

1. Muss jemand die genannten Programme verwenden?
2. Gibt's Alternativen?
3. Wo ist dann das Problem?

> Also Horizon ist offenbar dediziert NICHT für Windows-Benutzer gedacht.

s.o.

> ...
> Auch von angedachten Interfaces zu Dingen, die über den gewöhnlichen
> Kram hinausgehen, wie z.B. distributed elements, Feldanalysen usw. kann
> man nichts lesen. Jaja, unsereiner wäre durchaus an einem ECAD
> interessiert, das wenigstens ansatzweise die Dinge, die man mit Ansoft
> oder Sonnet sich gestalten kann, importieren oder wenigstens nachbilden
> kann. Aber das wären ja wieder Dinge aus der vernachlässigbaren
> Windows-Ecke...

1. Seit wann sind Ansys bzw. Ansoft oder Sonnet Windows-only?
2. "It's far from finished" heißt, zumindest für mich, vielleicht 
Alpha-Version. Ob man noch Alpha dazuschreiben muss? Vielleicht gar 
nicht so verkehrt...
3. Ist das ganze Open Source und etwas Hilfe bspw. mit Links zu den 
Dateiformaten der genannten Systeme oder zu Libraries/Kovertierern, die 
damit umgehen können, wären vielleicht nicht schlecht.
4. In einer Alpha-Version würde ich so was nicht implementieren, da 
gibt's wichtigeres. Ansonsten siehe 3. und vielleicht einen netten 
Feature Request schreiben.

> Nein, Horizon ist keineswegs "a free EDA package", sondern bislang nur
> ne Art Fingerübung die so tut, als ob sie sowas wäre. Der einzigen Rat,
> den ich hier geben könnte würde lauten: der/die Autoren täten besser,
> wenn sie ihre Arbeitskraft einsetzen würden, um Kicad vom Kopf auf die
> Füße zu stellen, also dessen Geburtsfehler ausmerzen. Das wäre
> zielführender.

Warum? Wenn einem Kicad bspw. nicht gefällt, warum sollte man dann dort 
Zeit investieren?

Autor: Possetitjel (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Arc N. schrieb:

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

Den allerwenigsten gefällt GAR NICHTS an KiCAD.

Wer aber den Schaltplaneditor von gEDA, den Layouteditor
von KiCAD und die Bauteilverwaltung von Horizon verwenden
will, ist angeschissen.

Autor: Stefan S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sag mal Lukas, hast Du eigentlich schon eine Idee bezüglich Simulation?

Ich habe da leider überhaupt nichts -- das ist auch einer der Gründe 
warum ich in den letzten Jahren an meinen Programmen nicht 
weitergearbeitet habe.

Mit gEDA war Simulation mit Spice oder GnuCap ja sehr zäh. Ich vermute 
mal KiCad und sämtliche kommerziellen Programme unterstützen jetzt 
Simulation. Tina-Ti hatte ich mal kurz  verwendet, das war schon recht 
gut nutzbar. (Leider war das Ergebnis völlig falsch, weil das Modell 
eines OP falsch war.)

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

Autor: Mar. Wa. (elektrowagi78) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Das ist ein gutes Argument. Ich bin auch ehe dafür die Simulation mit 
KiCAD weiterzutreiben und dort zu investieren, als noch ein neues 
Programm aufzuziehen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ich würde das nicht zu sehr in den Vordergrund stellen. Es wäre
natürlich nett, wenn man einen Simulator andocken könnte, aber mal
ehrlich, sowie da ein Mikrocontroller oder sowas im Spiel ist, kannst
du sowieso nie mehr alles simulieren, weil die Gesamtfunktion der
Schaltung massiv von der Software abhängt.  Dafür müsste man dann
jeweils wieder Modelle in die Simulation einklinken können.

Da hat es eher Sinn, einzelne Teilbaugruppen gelegentlich zu simulieren.

Simulation ist ohnehin ein weites Feld.  Der Anfänger will seinen
Colpitts-Oszillator simulieren, der UHF-Entwickler dagegen wird das
fertige Layout auf einem HF-Material simulieren wollen …

Autor: Julian W. (julian-w) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan S. schrieb:
> Sag mal Lukas, hast Du eigentlich schon eine Idee bezüglich
> Simulation?

Simulation ist wohl nicht geplant, siehe Vortrag:

Youtube-Video "Neues ECAD-Programm horizon (GPN17)"

18:35

Autor: Possetitjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan S. schrieb:

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

Worauf zielt die Frage?

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

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

Was bedeutet das?

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

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

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

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Possetitjel schrieb:
> Wenn ich simulieren will, starte ich einen Simulator.

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

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

Autor: Hans (Gast)
Datum:

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

full ack!

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

73

Autor: Possetitjel (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Jörg W. schrieb:

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

Na klar.

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

Aber genau DAS ist ja offensichtlich nicht gegeben.

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

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

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

Autor: Mar. Wa. (elektrowagi78) Benutzerseite
Datum:

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

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

Autor: Possetitjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans schrieb:

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

Ja.

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

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

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

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

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

Autor: Possetitjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mar. W. schrieb:

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

Genau mein Reden.

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

Jeder Koch hat einerseits Bratpfannen und andererseits das
Schnitzel.

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Possetitjel schrieb:
> notfalls tut's ein funktionierender Export/Import.

Darauf wird's hinauslaufen.

Autor: Lukas K. (carrotindustries)
Datum:

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

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

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

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

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

Geht schon: 
https://github.com/carrotIndustries/horizon/wiki/W...

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

Autor: Possetitjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:

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

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

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

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

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

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

??? Warum nicht?

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

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

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

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

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

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

Richtig: Wie im Mittelalter.

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

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

Richtig.

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

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

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

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

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

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

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

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

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

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

Autor: tester (Gast)
Datum:

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

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

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

Autor: tester (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm... das Problem ist wohl, dass
context_menu->popup_at_pointer((GdkEvent*)button_event);

erst ab libgtkmm 3.22 dabei ist.

Ich hab' nur libgtkmm3.18.

Autor: Frank K. (frank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Selbes Problem habe ich auch, ich versuche es auf openSUSE Leap42.3 zu 
bauen.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hoppla, hab ich das wohl übersehen. Sollte nun funktionieren.

Autor: tester (Gast)
Datum: