Search options (Page 3 of 31)

Ich will hier nemandem auf den Schlips treten ... darum geht es nicht!

Die Sache is nur die:
Der Haupt-Entwickler Joshua fällt leider für eine noch unbestimmte Zeit aus!
Er hat noch viele Ideen, QET strukturierter aufzubauen und da sollten wir ihm nicht in die Quere kommen!

Trotzdem versuche ich, so gut es geht, mich einzuarbeiten (Qt ist schon ziemlich "speziell" und das Projekt ziemlich groß!) und ein paar Dinge auszumerzen.
Die Einführung der eingebetteten Schriften gehörte zum Beispiel dazu.

In den Klemmen-Manager sollten wir nicht reingrätschen:
Der funktioniert zwar schon ziemlich gut, ist aber noch nicht ganz fertig.
Deswegen das Erstellen einer Klemmenliste vorerst mit externem Tool.

Im Moment bin ich dabei, eine schöne Ausgabe vorzubereiten, damit das auch "gefällig" aussieht.
Es wird wie bei acolomb als HTML-Code in den Quelltext-Editor eines Textfeldes eingefügt und das Ergebnis kann dann in QET problemlos nachbearbeitet werden.
Ein Beispiel hängt als Screenshot an.

Zum Thema "Klemmen neu nummerieren":
Das ist etwas, was nicht jeder Anwender braucht oder will! Das sollte eine Funktion sein, die nur auf Anfrage ausgeführt wird und hat erstmal nichts mit der Ausgabe einer Klemmenliste zu tun, finde ich.

Zum Thema "Abzweige", "Verbinder", "Splices", "Sprünge", etc.:
Aus meiner Sicht: Eine Pest!!!
Die sind als Bauteil verfügbar und als Klemmen definiert, sind aber nur für die grafische Darstellung in der Zeichnung nutzbar!
Es sind keine realen Bauteile, die auch das Erstellen eines Kabelplans total unmöglich machen: Wie soll man automatisch unterscheiden, ob das eine reale Klemme ist, oder einfach nur vergessen wurde, ein BMK zu vergeben?
Unter anderem deswegen und wegen der Möglichkeit mehr als einen Leiter an Verweis-Elementen anzubinden, habe ich die Software-Erstellung für einen Kabelplan (vorerst) verworfen: Man bekommt nicht zuverlässig heraus, von wo nach wo ein Draht gezogen werden kann, wenn im Schaltplan z.B. an einem Verweis mehr als ein Leiter angebunden ist und der Ziel-Verweis auch mit mehr als einem Leiter verbunden ist.
Das sollte meiner Meinung nach von QET unterbunden werden, dass dort mehr als ein Leiter angebunden werden kann! Aber das ist ein anderes Thema und Zukunftsmusik...

Abzweige, Splices und Sprünge sollten automatisch von QET erstellt werden und nur grafische Elemente (nicht im Sinne von "eingefügtes Bauteil"!) sein! Aber auch das ist Zukunftsmusik...!

Zurück zum Thema Klemmenliste:
Welche Informationen brauchen wir für die Liste?
Und können wir (vorerst) mit wenig manueller Nacharbeit leben?
Dann würde ich eine html-Tabelle aus den vorhandenen Klemmen erstellen, die dann manuell in ein Textfeld eingefügt werden kann. (vgl. Ansatz von acolomb)

Mit welchen Programmversionen arbeitet ihr?
Diese Info ist für das Nachstellen und Beheben eines Fehlers essentiell!

Und auch wichtig:
Was muss man tun, um das Fehlerbild nachzustellen?
(Welche Elemente? Wie verbunden? Wie verknüpft? etc. pp.)

Wir sollten uns nicht darüber streiten, an welcher Position welche Information einer Klemme stehen soll:
Das kann jeder für sich entscheiden, indem er seine Klemmen selber zeichnet und die Texte dort positioniert, wo er will!

Ich möchte lieber auf die Ausgabe einer Klemmenliste zurückkommen, um die es hier ursprünglich ging.

Das kann ja wohl nicht wahr sein:
Da machen mehrere Leute, die auch noch dieselbe Sprache sprechen, unabhängig voneinander Stand-Alone-Tools für die Erstellung von Klemmenlisten, die dann (mehr oder weniger) aufwendig wieder in QET importiert werden.
Sollte es nicht Ziel sein, das alles direkt in QET zu integrieren?
Mit dem QET_ElementScaler hat das ja auch ziemlich gut geklappt...!

Was haltet ihr davon, wenn wir drei (vier) das nun "in Angriff" nehmen und versuchen, das Erstellen einer Klemmenliste in QET einzubauen?

Programmiersprache in QElectroTech ist C++ mit Qt als GUI-Toolkit. Also sollten wir (trotz eurer Anfänge mit Python) auch C++ wählen! Da kommt es mir sehr entgegen, dass in QET_ElementScaler bereits das komplette "drumherum" für das Einlesen und Verarbeiten von XML vorhanden ist!

Das habe ich als Basis genommen, um ein einfaches Tool zu schreiben, das aus der qet-Datei alle Klemmen extrahiert, die Klemmeneigenschaften hinzufügt und die Verknüpfung zum jeweiligen Folio herstellt. Die Position auf dem Folio ist grundsätzlich auch schon verfügbar, aber noch nicht passend aufbereitet. Zusätzlich dazu stehen auch die Funktionstexte des Leiters (function, text, tension/protocol) an der Klemme zur Verfügung.

Zur Zeit sieht eine Beispiel-Ausgabe so aus:

Label | Folio | Type | LED | Function | Function | Text | Tension/Protocol
-X0:PE | 3 | ground | 0 | generic | PE | PE | PE
-X1:1 | 4 | generic | 0 | generic | CAN High | CAN_H | CAN_H
-X1:2 | 4 | generic | 0 | generic | CAN Low | CAN_L | CAN_L
-X1:3 | 4 | generic | 0 | generic | CAN Ground | CAN_GND | CAN_GND
-X1:4 | 4 | generic | 0 | generic | 24V | 24V | 24V
-X1:5 | 4 | generic | 0 | generic | 0V | 0V | 0V
-X2:1 | 7 | generic | 0 | generic |  |  | 
-X2:2 | 7 | generic | 0 | generic |  |  | 
-X2:3 | 7 | generic | 0 | generic |  |  | 
-X2:4 | 7 | generic | 0 | generic |  |  | 
-X2:5 | 7 | generic | 0 | generic |  |  | 
-X2:6 | 7 | generic | 0 | generic |  |  | 

Die nächste Aufgabe besteht nun darin, das entsprechend "schön" auszugeben!
Die Variante von acolomb mit dem Einbetten in einen Freitext gefällt mir dabei schon ganz gut! Das ist für den Normalbenutzer recht einfach mit Bordmitteln des Betriebssystems zu erledigen!

In einem weiteren Schritt muss das in QET integriert werden, damit wir von den Stand-Alone-Tools wegkommen und alles "geschmeidig" innerhalb der GUI von QElectroTech erledigt werden kann!

Hello Michael,

as far as I can see: QElectroTech does not use an authentication service.
The term “Kerberos” cannot be found in the source code and an “88” (Kerberos-Port) can only be found in some color definitions and positions and sizes of the UI.
It looks to me like you should ask your OS-manufacturer what they are trying to do ...

Ja, stimmt!

Es ist schon ein starkes Stück, daß die Leute, die Dir eine kostenlose Software zur Verfügung stellen, nicht auch noch Deine Pläne zeichnen!

Oh Mann ... Leute gibt's ...!

That's fine with me, as I see that the font-files don't change very often!

Fonts to use on all systems are available in QET:
https://qelectrotech.org/forum/viewtopi … 682#p21682

Hello everybody!

Thanks to elevatormind for his initial work on including fonts and Laurent (scorpio810) for packaging the binaries we now have a QElectroTech - Version in 0.100-dev with some included fonts:

• Liberation Mono

• Liberation Sans

• Liberation Serif

• osifont

No effort is required from the user to be able to use the fonts:
The fonts are available in QElectroTech with the installation of QElectroTech!
Of course, all other fonts of the operating system used can still be used in your elements and diagrams!
However, if you think about exchanging of the resulting work between different computers and/or systems, we recommend limiting yourself to the included fonts!

In this context, the default font in QET was set to Liberation Sans and all existing elements were revised so that Liberation fonts are now used everywhere!

With writing these lines, I noticed, that "osifont.ttf" was updated upstream.
This is by no means a problem for users, but it does lead to a question for Laurent:
(How) can we link "fonts/osifont.ttf" and "fonts/osifont-italic.ttf" to the original versions at github?
We already link pugixml and SingleApplication to their github-repos, so it may be possible to link two single files to their position in github-subdirs?
We don't need the whole directory: That would be way too much!
The two ttf-files would be enough: osifont.ttf and osifont-italic.ttf

@scorpio810:

More than five weeks with no reaction to my last post and I would like to get further with this topic!

Do you think we should upload elevatormind's source code for/with the fonts and my additions regarding the licenses in one commit? The language files can be adjusted and after that I could also upload the revised elements from my to the official QET-repository.
So: Some changes that depend on each other, but the first step is still missing.

I already prepared that combined commit in my github-repo.

What do you think, Laurent?

Tu dich doch mit dem Kollegen aus dem anderen Thread zusammen:
Dann könnt ihr gemeinsam QElectroTech lernen und hier konkrete Fragen stellen, wenn's irgendwo hakt!