Hi, ich programmiere nun schon seit einiger Zeit unter Linux mit c++/gtk. Nun möchte ich mich im Rahmen einer Jugend Forscht Arbeit an ein etwas größeres Projekt heranwagen(es soll ein Schaltplaneditor werden). Nur weiß ich leider nicht wie ich den grafischen teil( das zusammensetzen aller Bauteile) realisieren soll. Kennt jemand ein OpenSource Projekt, oder hat eine gute Idee, wie man das möglichst einfach Realisieren kann? Ich bin für jeden Vorschlag dankbar:) Mfg Daniel
OpenSource, C++, aber kein gtk: KiCAD.
Daniel Stein schrieb: > größeres Projekt heranwagen(es soll ein Schaltplaneditor werden). Nur > weiß ich leider nicht wie ich den grafischen teil( das zusammensetzen > aller Bauteile) realisieren soll. Mit einem Bauteileditor, den du natürlich schreiben musst. Wie sieht denn bei dir ein Bauteil aus? Je nachdem ob du zb eni Bauteil aus Linien / Bögen zusammensetzen willst oder ob ein Bauteil zb einfach nur eine Bitmap ist, ist dann der interne Aufbau eines Bauteils ein anderer. Folgt aber alles daraus, wie du grundsätzlich ein Bauteil graphisch repräsentieren willst. Linien/Bögen: hat Vorteile beim Zoomen/Drucken. Dafür ist es aufwändig graphisch ansprechende Bauteile zu zeichnen Bitmaps: da kann man sich mit einem Malprogramm austoben, sitz aber dann beim Zoomen vor Dingen, die wie Stonehenge von oben aussehen.
Am Anfang muß es vielleicht nicht gleich ein Bauteile-Editor sein. Die ersten Symbole können auch vergleichsweise leicht von Hand entworfen und die nötigen Linien- und Bogenlisten dann per Texteditor angelegt werden. Wenn GTK verwendet werden soll, ist das GtkDrawingArea(?) in Verbindung mit Cairo zu empfehlen. Für Anregungen bezüglich des Dateiformats oder Implementierung, kann neben KiCAD vielleicht auch ein Blick auf gschem oder oregano geworfen werden. Letztes basiert möglicherweise sogar auf GTK.
Erstmal vielen Dank für die Hilfe. Erfahrung mit Cairo habe ich, bin aber nur bei dem zeichnen von Linien geblieben(hab keine Ahnung, wie man Bögen zeichnen soll).Mein Problem war eher, wenn man jetzt ein Bauteil hat, wie stellt man es an, das der User es beliebig mit der Maus positionieren kann? Mit cairo müsste man für jede Bewegung doch das komplette Fenster neu zeichnen:( Daniel
Clown schrieb: > Am Anfang muß es vielleicht nicht gleich ein Bauteile-Editor sein. Die > ersten Symbole können auch vergleichsweise leicht von Hand entworfen und > die nötigen Linien- und Bogenlisten dann per Texteditor angelegt werden. :-) Genau so ziehe ich meine Editoren meistens hoch. Zur Bauteilbeschreibung erst mal ein Text File. Denn: Da kommt noch mehr dazu! Ein Schaltplaneditor muss natürlich auch noch wissen, wo Anschlusspunkte sind; ob es sich bei diesem Anschluss um einen Ein- oder Ausgang handelt; ein Beschriftungstext für das Bauteil wär nicht schlecht; Bauteilwert (samt möglicher Einheiten), etc. etc. Da kommt im Laufe der Zeit noch so einiges zusammen. Das alles erst mal für ein paar Bauteile in ein paar ASCII Dateien von Hand pflegen und erst dann wenn sich alles ein wenig stabilisiert hat, wird ein Bauteileditor dafür gemacht. In letzter Zeit nehm ich dafür auch ganz gerne XML Files, weil man sie auch im Nachhinein noch gut erweitern kann, ohne in die Kompatibilitätsfalle zu laufen.
Kennt einer von euch "eXact"? Ich finde die Idee mit dem Raster und dem Drag&Drop sehr schön, möchte es dennoch anders lösen. Ich finde Cairo eine gute wahl, doch wie macht man das mit dem Positionieren? Daniel
Möglicherweise wäre es sinnvoll, das Zeichnen mit OpenGL zu machen, dann ist es hardwarebeschleunigt und man könnte ggf. hübsche 3D-Spässchen einbauen. GtkGLExt ( http://projects.gnome.org/gtkglext/ ) ist eine Bibliothek, mit der man OpenGL in normale Gtk+ Programme einbinden kann. Auf der Seite gibt's auch ein C++ Binding. PS: Wenn du mit C++ programmierst, könntest du das C++ Binding für Gtk+ namens gtkmm (http://www.gtkmm.org/) verwenden, das spart einiges an Tipparbeit.
Ok, mein Plan sieht wie folgt aus: Alle Positionen der Linien und Bauelemente, werden in Arrays gespeichert, so kann man sie später abfragen und verknüpfen(Simulation, Speichern, etc.). Kann man in Cairo mehrere DrawWidgets übereinander machen? Dann könnte man das obere für das Positionieren einzelner Bauteile nehmen, und wenn man zufrieden ist, wird es einfach zum unteren hinzugefügt.
>größeres Projekt heranwagen(es soll ein Schaltplaneditor werden gschem verwendet C und GTK, aber sich da hineinzufinden ist mit Arbeit verbunden. Zeichnen geht mit Cairo und GTK recht einfach, ich habe mal etwas mit Ruby herumgespielt, http://www.ssalewski.de/PetEd-Demo.html.en Cairo ist aber etwas langsam, wenn es schnell sein muss ist wohl OpenGL besser.
Daniel Stein schrieb: > Ich finde die Idee mit dem Raster und dem > Drag&Drop sehr schön, möchte es dennoch anders lösen. Ich finde Cairo > eine gute wahl, doch wie macht man das mit dem Positionieren? Gehs erst mal langsam an. Sieh erst mal zu, dass du eine Klasse "Bauteil" hast, die einen Member "Grafik" beinhaltet, in dem wiederrum eine Liste von Graphikelementen existiert, die Linien oder Bögen sein können (von Grafikelement abgeleitete Klassen für Grafik-Linie bzw. Grafik-Bogen bzw. Grafik-Kreis). Sieh zu, dass du das an eine Position/Orientierung (welche sagt dir das Bauteil) malen kannst. In diesem Zusammenhang wird zb eine Punktklasse zur Speicherung eines x/y Koordinatenpärchens interessant sein. Da in einem Schaltplaneditor keine allgemeinen Rotationen vorkommen werden, sondern nur vielfache von 90°, würde es ausreichen die Position einfach nur als Punkt und eine von 4 Lagen zu beschreiben. Wenn da nicht noch die Spiegelung wäre. Im Moment schwanke ist noch ob man da nicht der Einfachheit halber eine vollständige 2D-Transformationsmatrix benutzen sollte. Mit der kann man das alles mit Leichtigkeit beschreiben. Dazu laden von einem File auf Anforderung des Benutzers und Positionieren, in dem dir der Benutzer die Position zeigt (Mausklick), wo er das Teil hin haben möchte. Ein entsprechendes Bauteil Objekt erzeugen und zu der Liste der im Dokument (dem Schaltplan) vorhandenen Bauteile hinzufügen. Danach Bnachrichtigung aller Views, dass sich das Dokument geändert hat und ein Bauteil hinzugekommen ist woraufhin der entsprechende View das Bauteil gemäss seiner (des Views) Bestimmung anzeigt. Dann ...... hast du immer noch einen Haufen Arbeit vor dir, unter anderem einen Mausklick identifizieren, welches Bauteil am nächsten am Mausklick drann ist, überlegen wie du Undo/Redo machen möchtest (diese Entscheidung muss bald getroffen werden) und und und und Und erst dann ..... kommt die Kür mit Drag&Drop. Aber erst mal ist die Pflicht drann. Und das ganze natürlich schön sauber objektorientiert aufbauen. Der Grafikteil selber macht in grafischen Editoren noch nicht einmal 10% aus. Der Rest ist Datenhaltung, Datenverwaltung, allgemeine Organisation.
> werden in Arrays gespeichert
Ich hoffe mal zu deinen Gunsten, dass das ein leichtfertig dahergesagter
Schnellschussfehler war. Mit Arrays willst du nicht rumhantieren.
std::vector bzw std::list ist dein Freund. Leider wirst du zumindest im
Grafikteil einen std::vector von Pointern machen müssen (damit du
Inheritance nutzen kannst). Da würde es sich dann anbieten diesen in
einer Klasse zu verstecken, wie zb der Grafikklasse und sich dort um das
Datenmanagement (Allokieren bzw. Freigeben bzw. Kopien erzeugen) zu
kümmern. Vollständigen Satz an
Konstruktoren/Destruktor/Zuweisungsoperator nicht vergessen!
@Buchegger >Mausklick drann ist Dran bitte mit nur einem n. >überlegen wie du Undo/Redo machen möchtest Ja, wie denn nun? Für jede Benutzeraktion die Inverse generieren und speichern? Hört sich nicht ganz einfach an, aber ist wohl die sauberste Lösung. Oder bei jeder Benutzeraktion eine Kopie aller Datenstrukturen anlegen? Würde mich nicht wundern, wenn es teils so gemacht wird. Oder ganz weglassen -- mein Auto hat auch kein Undo!
Stefan Salewski schrieb: > @Buchegger > >>Mausklick drann ist > > Dran bitte mit nur einem n. > >>überlegen wie du Undo/Redo machen möchtest > > Ja, wie denn nun? Für jede Benutzeraktion die Inverse generieren und > speichern? Ja kann man machen. Meine Editoren machen das nach diesem Prinzip. Alle Operationen sind in Klassen gekapselt die von einer gemeinsamen Basisklasse abgeleitet sind. Jede Operation implementiert eine Do/Undo/Redo/Finalize Member Funktion. Dazu existiert im Dokument ein Undo Manager, der die Operationen sammelt und bei Bedarf den Auftrag zum Rückgängig machen erteilt. Woraufhin die Operation von der Undo-Liste auf die Redo Liste wandert. Wird eine neue Operation hinzugefügt, wird die Redo Liste verworfen und vorher natürlich alle Operationen darin benachrichtig, dass sie einen eventuelle Undo jetzt finalisieren dürfen. Eine Delete Operation löscht dann erst tatsächlich das von ihm gehaltene 'gelöschte' Datenobjekt. Vorher geht nicht, denn ein Redo könnte ja den Delete wieder aufheben und dann muss die Delete Operation das Datenobjekt wieder zum Dokument hinzufügen. Die Do bzw. Undo Funktionalität einer Delete Operation macht daher nichts anderes, als das Datenobjekt aus dem Dokument auszuketten und bei sich selber einen Pointer darauf zu installieren. Gelöscht wird das Datenobjekt erst, wenn die entsprechende Delete-Operation finalisiert wird. Aber Achtung: Bei den Operationen handelt es nur um die ausführenden Objekte, die eine Operation implementieren. Das hat nichts mit GUI oder Benutzerinteraktion zu tun! Das sind bei mir wieder andere Klassen - ich nenne sie Tools. Ein Add-Tool, welches ein Bauteil hinzufügt, kümmert sich darum, mit dem Benutzer zu interagieren. Ist alles soweit klar, dann erzeugt sie eine Add-Operation mit den entsprechenden Daten, lässt die Operation ihre Arbeit machen und übergibt die Operation an den Undo-Manager. Ein Intersect-Tool, welches alle Schnittpunkte zwischen 2 geometrischen Elementen bestimmt, lässt sich vom Benutzer die Elemente zeigen, befragt dann eines der Elemente nach allen Schnittpunkten mit dem anderen und erzugt für jeden Schnittpunkt wieder eine Add-Operation, die den Schnittpunkt zur Datenbasis hinzufügt (die einzelnen Add-Operationen werden vorher noch in eine Gruppen-Operation gesteckt, damit sie für den Undo-Manager eine untrennbare Einheit sind). etc. etc. Auf die Art ist Benutzerinteraktion und tatsächliche Manipulation der Datenstruktur sauber getrennt. Bei ansonsten gleicher Funktionalität ist es ein Kinderspiel die Benutzerinteraktion durch ein ganz anderes GUI-Konzept auszutauschen. Lediglich die Tool-Klassen müssen neu gemacht werden. Datenstruktur und Operationen auf die Datenstruktur bleiben wie gehabt. (Und unter uns: so viele Operationen sind das gar nicht, die implementiert werden müssen) > Hört sich nicht ganz einfach an, aber ist wohl die sauberste > Lösung. Oder bei jeder Benutzeraktion eine Kopie aller Datenstrukturen > anlegen? Würde mich nicht wundern, wenn es teils so gemacht wird. Auch das wird gemacht. Vorteil: In der Kopie sind ganz von alleine immer alle Daten vorhanden, auch bei Erweiterungen. Nachteil: Die Datenmengen sind enorm. Weiterer Nachteil: Da Kopien der Daten erzeugt werden müssen, muss man acht geben, wenn Datenobjekte untereinander verpointert sind. D.h. Der Mechanismus, der die Kopie erzeugt, muss eng mit den Datenobjekten zusammenarbeiten, damit die Kopie der Daten nachher auch wieder die gleiche funktionale Verpointerung beinhaltet. Das kann unter Umständen schon tricky sein. Allerdings kommt man um so einen Mechanismus sowieso nicht herum, denn spätestens beim Speichern in eine Datei benötigt man ihn, um die Datenstruktur beim nächsten Einlesen wieder korrekt aufbauen zu können. Im Falle eines Schaltplan-Editors ist das zb die Wire-Information: Welcher Ausgang eines Bauteils ist mit welchem Eingang eines anderen Bauteils verbunden. > Oder > ganz weglassen -- mein Auto hat auch kein Undo! Ein grafischer Editor ohne Undo ist in der Praxis unbrauchbar.
Ähem! Mal im ernst, wenn ich hier Begriffe lese wie funktionale Verpointerung ??? Intersect-Tool ??? Datenobjekt aus dem Dokument auszuketten ??? Undo Manager Finalize Member Funktion ja und dann auch noch Opengl und XML und 3D-Spässchen und warum nicht auch noch Spice gleich noch mit einbauen, Exel-Charts generieren und und und .. Dabei hat der Fragesteller einen erleuchteten Satz seines aktuellen Kenntnisstandes wiedergegeben, der kaum Beachtung fand und lautete Zitat "bin aber nur bei dem zeichnen von Linien geblieben(hab keine Ahnung, wie man Bögen zeichnen soll)" oder mit anderen Worten ausgedrückt: "ich hab so gut wie keinen blassen Schimmer, von alle dem, was da auf mich zukommt." Vielleicht sollte er erst mal eine geeignete Bauteilstruktur bzw. Klasse formulieren und sich dabei mal überlegen, dass jedes Bauteil aus beliebig vielen primitiven eigenen Objekten wie Linien (Polygonen), Bögen, Kreisen, Punkten jeweils mit eigenen relativen Koordinaten besteht, die sich an einem (verändebaren) Raster orientieren. Die Primitiven können verschiedene Strichstärken, Farben (Füllungen) etc. aufweisen, verschiedene "Hot-Spots" beim überfahren der Maus besitzen (in der Mitte, am Rand, an den Anschlusspunkten), je nachdem welche Aktion bevorsteht (verschieben, drehen, skalieren, anschließen, kombinieren, gruppieren etc.) Textobjekte gehören auch dazu und dieses Bauteil sich selbst auf Befehl zeichnen können muss. Dann hat er zwar erst einen kleinen Bruchteil von allem geschafft, aber dennoch mal eine Grundlage (in Anbetracht des sperrlichen Kenntnisstandes). PS: ich wüsste auch nicht auf Anhieb welche Codezeilen hierfür geeignet wären, würde aber wie gezeigt vorgehen. "Undo" macht mir Kopfzerbrechen, habe aber auch nur kurz überlegt (ist ja nicht meine Aufgabe, gelle). Ich halte das ganze für eine sehr anspruchsvolle Aufgabe, auch und vor allem in anbetracht, dass es bei TinyCad (ist ein Schaltplaneditor) nur sehr schleppend Fortschritte in der Entwicklung der SW gibt (und da arbeiten einige dran). Installiere dir das mal (falls du einen Windowsrechner hast). Eigentlich hat das Programm bereits alles was du machen möchtest und ist zudem noch überschaubar und quelloffen. Ich würde es in C# programmieren. Das geht mir eher ein wie C++. (ich meine echtes C++ "Klassengedöns" ;) und nicht C-Code). Viel Glück!
@Daniel Stein Wahrscheinlich bist Du eh schon abgetaucht, aber was man vielleicht noch erwähnen sollte: Man könnte auch daran denken ein Canvas Framework zu verwenden: http://live.gnome.org/ProjectRidley/CanvasOverview http://live.gnome.org/GooCanvas Oder man macht einen "Schematic-Mode" für ein CAD-Programm, etwa für InkScape oder kivio/dia.
Fragesteller schrieb: > Ähem! Mal im ernst, wenn ich hier Begriffe lese wie > > funktionale Verpointerung ??? > Intersect-Tool ??? > Datenobjekt aus dem Dokument auszuketten ??? > Undo Manager > Finalize Member Funktion > Das war für Stefan gedacht und nicht für den Fragesteller. Ich hatte schon den Eindruck, dass Stefan damit was anfangen kann, wenn ich ihm einen kurzen Abriss darüber gebe, wie bei mir Undo funktioniert. > Dabei hat der Fragesteller einen erleuchteten Satz seines aktuellen > Kenntnisstandes wiedergegeben, der kaum Beachtung fand und lautete > > Zitat "bin aber nur bei dem zeichnen von Linien > geblieben(hab keine Ahnung, wie man Bögen zeichnen soll)" > > oder mit anderen Worten ausgedrückt: "ich hab so gut wie keinen blassen > Schimmer, von alle dem, was da auf mich zukommt." Und wenn du hochscrollst, hab ich genau darauf Rücksicht genommen und ihm erst mal geraten mit einer einfachen Datenstruktur zu beginnen. Genauso wie du auch :-) Denn ich hatte den Eindruck dass er denkt, das kriegt er alles gratis und umsonst und mit der Installation von GTK (oder was auch immer) wäre der teil dann schon erledigt.
>Das war für Stefan gedacht und nicht für den Fragesteller. >Ich hatte schon den Eindruck, dass Stefan damit was anfangen kann, wenn >ich ihm einen kurzen Abriss darüber gebe, wie bei mir Undo funktioniert. Da sicher, danke. Aber den Daniel Stein haben wir wohl nun doch verschreckt, wie viele andere auch, u.a. auch den Kai G. Ein einfacher Schaltplaneditor ist sicher kein Hexenwerk und eine schöne Übung für grafische, objektorientierte Programmierung. Aber etwas Aufwand ist es eben doch. Wobei das Layout-Tool dann noch wesentlich aufwendiger wird -- DRC, Gerber-Export, Polygon-Operationen...
Stefan Salewski schrieb: > andere auch, u.a. auch den Kai G. Ein einfacher Schaltplaneditor ist > sicher kein Hexenwerk und eine schöne Übung für grafische, > objektorientierte Programmierung. Eine wunderbare Übung! > Aber etwas Aufwand ist es eben doch. Du sagst es. Die Leute unterschätzen das. Von einem Malprogramm ala Paint, bei dem ein paar Pixel in einer Bitmap manipuliert werden zu einem kleinen CAD (ist ja egal was es dann macht) ist es eine schöne Wegstrecke auch wenn es auf den ersten Blick so ähnlich aussieht. Aber es ist machbar und es lauern einige Stolpersteine, aber so ein Hexenwerk ist es dann auch wieder nicht. Die größte Überraschung: Man benötigt im Speicher eine Repräsentierung der Grafik in der Datenstruktur. Die größte Enttäuschung ist meistens, dass man von den ach so tollen Bibliotheken erst mal wenig bis gar nichts brauchen kann. Zeichenfläche, Linien ausgeben, Mausposition erfahren. Das wars dann schon. Alles andere muss man mehr oder weniger selber machen. Wobei einem OpenGL mit den Display Listen und der Art und Weise wie Mausklicks auf das Primtiv zurückführen einem da schon einiges an Arbeit abnimmt. Aber auch das muss man erst mal lernen.
Karl heinz Buchegger schrieb: > Die größte Enttäuschung ist meistens, dass man von den ach so tollen > Bibliotheken erst mal wenig bis gar nichts brauchen kann. Zeichenfläche, > Linien ausgeben, Mausposition erfahren. Das wars dann schon. Alles > andere muss man mehr oder weniger selber machen. Heutzutage bringen doch GUI-Bibliotheken meisten ein "Canvas" mit oder bieten als Zusatz-Bibliothek eins an. Das nimmt einem große Teile der Arbeit ab. Bei Qt z.B. gibt es QGraphicsScene. Da kann man dann einfach Kreise, Linien, Text, aber z.B. auch Widgets, Pixmaps oder ganze SVGs reinstecken, und das kümmert sich schon ums Positionieren, Drehen, Zoomen, Mausinteraktion u.s.w.
>Heutzutage bringen doch GUI-Bibliotheken meisten ein "Canvas" mit Hatte ich doch oben schon erwähnt: Beitrag "Re: elektrisches CAD Programm Quellcode in c++/gtk" Müsste man sich mal ansehen...
"Oder man macht einen "Schematic-Mode" für ein CAD-Programm, etwa für InkScape oder kivio/dia" Auf jeden Fall würde ich es sehr begrüßen, wenn es endlich mal einen Schaltbildeditor geben würde, der SVG-Dateien ausgeben kann. Damit man sie mit den enormen Möglichkeiten von Inkscape weiterbearbeiten kann oder sie auch mit einfachen Textprogrammen automatisch abändern. Mit der Qt-Canvas dürfte das eigentlich nicht schwer sein, die hat die SVG-Ausgabe mit eingebaut. Ich würde es auch gerne selber machen, doch mir fehlt die Zeit.
Jobst Q. schrieb: > "Oder man macht einen "Schematic-Mode" für ein CAD-Programm, etwa für > InkScape oder kivio/dia" > > Auf jeden Fall würde ich es sehr begrüßen, wenn es endlich mal einen > Schaltbildeditor geben würde, der SVG-Dateien ausgeben kann. Damit man > sie mit den enormen Möglichkeiten von Inkscape weiterbearbeiten kann > oder sie auch mit einfachen Textprogrammen automatisch abändern. > Bei Cairo bekommt man die Backends PDF, SVG usw. ja praktisch geschenkt, das ist einer der Vorteile. gschem verwendet ab 1.6 bereits Cairo, da sollte man SVG-Export einbauen können. Mein oben erwähntes Progrämmchen wird SVG natürlich auch unterstützen. > Mit der Qt-Canvas dürfte das eigentlich nicht schwer sein, die hat die > SVG-Ausgabe mit eingebaut. Ich würde es auch gerne selber machen, doch > mir fehlt die Zeit. Dann musst Du halt warten, oder den Umweg über PDF/PostScript probieren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.