minimaler Abstand von Text, Buttons, ... zu einem Rechteck mit abgerundeten Ecken

[hofk]

Hallo,

bin ganz frisch bei Python 3.13/Tkinter, programmiere allerdings seit 56 Jahren, Start mit Maschinencode und Assembler, nie hauptberuflich aber immer Projekte nebenher und als Hobby in verschiedensten Umgebungen.

Ich hatte, seit der erste Microprozessor entwickelt wurde, immer die Idee die Simulation eines absolut minimalen Prozessors zu schreiben. Hat gedauert, aber 2014 habe ich es mit XProfan realisiert und später eine web Variante erstellt.

Jetzt portiere ich nach Python/Tkinter und habe ein Tkinter Problem.

Ich möchte das user interface so weit wie möglich identisch zur XProfan Variante gestalten. In XProfan habe ich Text, Buttons usw. ganz einfach sehr eng an Umrandungen (Rechteck mit abgerundeten Ecken) platzieren können. Es sind lediglich die passenden Koordinaten anzugeben. Bei Tkinter sieht mir das eher ähnlich wie bei HTML/CSS aus und ich erhalte größere Abstände. Müsste also das gesamte Fenster vergrößern. Mache ich etwas falsch, oder geht es nicht dichter ran Verkleinere ich padding, wird die Rundung angeknabbert.

Code: Alles auswählen

    #  .....  CPU  .....
    x1, y1, x2, y2, r = 500, 125, 876, 450, 12
    draw_round_rect(c, x1, y1, x2, y2, r, fill=chipc, outline="black")
    # innerer Frame um Widgets zu platzieren
    padding = 4
    inner_w = (x2 - x1) - 2*padding
    inner_h = (y2 - y1) - 2*padding
    inner_frame = tk.Frame(root, bg=chipc, bd=0, highlightthickness=0, relief="flat")
    c.create_window(x1 + padding + inner_w/2, y1 + padding + inner_h/2,
                window=inner_frame, width=inner_w, height=inner_h)
    tk.Label(inner_frame, text="Data register", bg=chipc).place(x=10, y=0)
    tk.Label(inner_frame, text="D0", bg=chipc).place(x=0, y=17) 

Bei Interesse:
Der gesamte Python Code, bisher fast nur GUI Entwurf:
https://hofk.de/cpusimulation/python/de ... 680.py.txt

Die ursprünglichen Versionen
https://hofk.github.io/ (unten)
https://hofk.de/ ( Link unten, Seite mit allen Materialien)

[__blackjack__]

@hofk: Das wird nicht funktionieren. Man platziert keine Elemente an pixelgenaue Positionen mit pixelgenauen Grössen und man gibt auch keine Fenstergrösse vor. Die Positionen und Grössen ergeben sich aus den jeweiligen Inhalten. Pixelgenau ist grundsätzlich ein Problem weil es so viele verschiedene Monitorauflösungen und -grössen gibt. Zusammen mit Schriftgrössen die abhängig von der Bildschirmauflösung angegeben werden, also eine je nach System/Konfiguration andere Pixelgrössen haben, ist das einfach nur kaputt.

Du versuchst XProfan in Tk rein zu prügeln, und soweit man das sehen kann auch das Programm nicht in Python sondern in XProfan, das sich als Python verkleidet, zu schreiben. Passend zum Monat — ist ja bald Halloween.

Das sollte man neu entwickeln. Ordentlich, mit den Sprachmöglichkeiten, und einem GUI-Rahmenwerk das so verwendet wird wie vorgesehen und nicht einfach nur als Fläche für eine schlecht/kaputt selbst programmierte Benutzerschnittstelle dient. Das Original hat alleine in dem „global variables for the simulation“-Block 108 globale Variablen. Und so wie's aussieht scheinst Du das alles in die `main()`-Funktion verschieben zu wollen, mit den Prozeduren aus dem Original als verschachtelte Funktionen und so gruseligen Hacks wie Wörterbuch mit einem Schlüssel, damit die Funktion dieser ehemals globalen Variablen einen neuen Wert zuweisen kann. Das ist kein Python!

Die GUI ist auch das ungünstigste Ende mit dem ganzen anzufangen. Das Original hat GUI und Programmlogik komplett vermischt. Wenn man das sauber trennen will, dann sollte man mit der Programmlogik anfangen, und danach dann dort die GUI drauf setzen. Damit vermeidet man am effektivsten nicht doch irgendwo GUI-Wissen in die Programmlogik zu schreiben.

[grubenfox]

Die GUI ist auch das ungünstigste Ende mit dem ganzen anzufangen. Das Original hat GUI und Programmlogik komplett vermischt. Wenn man das sauber trennen will, dann sollte man mit der Programmlogik anfangen, und danach dann dort die GUI drauf setzen. Damit vermeidet man am effektivsten nicht doch irgendwo GUI-Wissen in die Programmlogik zu schreiben.

... und die Programmlogik läßt sich dann (wenn sie keine GUI-Anteile enthält) auch am einfachsten testen.

[DeaD_EyE]

Manche fangen lieber mit der GUI zuerst an. Kann man ja machen, wenn man z.B. den QT-Designer nutzt und dann via PySide6 die XML-Datei lädt.

[grubenfox]

dann sollte man aber auch weiterhin die GUI-Logik schön in dem GUI-Code lassen (nur die GUI-Logik!) und die Programm-Logik in einem davon getrennten Modul.

[__blackjack__]

@DeaD_EyE: Ja die reine GUI ohne Funktionalität oder mit ein bisschen ”mockup”-Code um zu sehen wie die Oberfläche aussieht und welche Operationen die Porgrammlogik dann anbieten muss. Aber wenn man dann anfängt Code für die GUI-Rückrufe zu schreiben, ohne dass man eine ohne GUI entwickelte und getestete Programmlogik hat, verleitet sehr leicht dazu hier nicht sauber zu trennen.

Im Original verändern die Prozeduren zur CPU-Emulation direkt die GUI. Müssen sie sogar weil die ganze Datenhaltung in den GUI-Elementen passiert. Überwiegend 8 Bitwerte als Zeichenketten in Binärdarstellung. Viele Prozeduren der Emulation sind auch keine echten Prozeduren, sondern eher Sprungmarken, denn die operieren alle auf den 108+ globalen Variablen ohne Parameter zu bekommen.

Habe mal kurz über die XProfan-Dokumentation geschaut — es gibt nicht nur ``Struct`` sondern sogar ``Class``. Ich vermute dass muss man nicht so machen wie das im Original aussieht. Allerdings scheint es auch so interessante Einschränkungen zu geben wie das keine Arrays als Argumente übergeben werden können.

[hofk]

Vielen Dank
für die ausführliche Antwort @__blackjack__
und die Beiträge der anderen user

Du versuchst XProfan in Tk rein zu prügeln, und soweit man das sehen kann auch das Programm nicht in Python sondern in XProfan, das sich als Python verkleidet, zu schreiben.

Genau das war die Idee. Warum? XProfan wird nicht mehr weiterentwickelt und ich möchte auf eine gängige Desktop Sprache portieren. Die Web Version mit Zugabe von three.js 3D Grafik entsprang meinem Wunsch es online verfügbar zu machen und dabei three.js zu benutzen, was ich seit ca. 8 Jahren intensiver beackere, siehe https://github.com/hofk
Wäre auch ohne 3D gegangen. Dabei musste ich durch das Ereignismodell zwangsläufig die Struktur des Originals umkrempeln und einiges an Zeit investieren. Die Portierung ist aber nicht vollständig.

Habe also versucht, aus der Masse an Sprachen eine geeignete herauszufischen, in der Hoffnung es mit minimalem Aufwand zu portieren. Dabei ist mir der entstehende Code eigentlich egal, hätte auch BASIC Spaghetticode sein können, wenn es funktioniert. Die Sache ist keine sich entwickelnde Geschäftssoftware wo es entsprechende Anforderungen gibt. Hier geht es einzig und allein darum, dass der Anwender lernen kann wie so ein primitiver Prozessor "tickt". Als ausführbare Datei ist der Code nicht einmal sichtbar.

Nach kurzer Recherche habe ich Python ausgewählt, da es auf verschiedenen Plattformen läuft. Erst dann habe ich bemerkt, dass Python allein nicht hilft, da das GUI ein Extra benötigt und es mehrere gibt. Tkinter soll das Einfachste für den Einstieg sein - oder?

Da der RAM (mit Anbindung an die Assembler Programmierung) der komplexeste Teil ist, habe ich mit KI Hilfe probiert, ob das umsetzbar ist. Etwas ernüchtert war ich schon, das aus dem kompakten create("gridBox", ... mit voller Funktionalität die class GridBox mit knapp 300 Zeilen dann ansatzweise aber noch unvollständig das macht, was ich brauche. Auch ein Rechteck mit abgerundeten Ecken ist zusammenzupusseln.

Dann stieß ich auf das Abstandsproblem und daher meine Anfrage hier.

Über Pixel, Schriften und Auflösungen möchte ich nicht diskutieren, darüber könnte ich eine Abhandlung über die letzten ca. 45 Jahre schreiben - habe ich nicht vor. Ein sinngemäßes, uraltes Zitat eines damals anerkannten Experten: "Grafikdarstellung braucht man nicht in der wirtschaftlichen Nutzung"

Gehe jetzt in mich und überlege, wie ich weiter vorgehe. Eventuell noch einmal andere Sprachen in Erwägung ziehen und antesten, mit einigen habe ich vor Jahren, jeweils als sie aufkamen, experimentiert.

[__blackjack__]

@hofk: Portieren heisst doch aber, dass man das Programm dann in der anderen Sprache schreibt, mit deren Sprachmitteln, und nicht versucht das alles möglichst so wie die Ausgangssprache aussehen zu lassen, auch wenn das so gar kein idiomatischer Code wird. Das Originalprogramm ist ja schon ein Albtraum, und das willst Du übernehmen *und* das dann auch noch in einer Sprache die sich zum Beispiel was globale Variablen angeht, dagegen wehrt‽ Das macht doch keinen Sinn.

Naja, bei Python ist der Quelltext halt schon sichtbar.

Das Ereignismodell hat man bei GUIs in Python auch, also da muss man auch umkrempeln. Man kann da keine eigene Ereignisschleife schreiben. Die Hauptschleife läuft im Tkinter-Code, man kann nur auf Ereignisse in Rückruffunktionen beziehungsweise Methoden reagieren, und der Code darf auch nur kurz etwas machen und muss dann die Kontrolle an die GUI-Hauptschleife zurückgeben. Sonst blockiert die GUI und es gibt Betriebssysteme die dann dem Benutzer ein Fenster präsentieren, dass die Anwendung nicht mehr reagiert, und ob sie beendet werden soll. Dieses Ereignismodell trifft auf die allermeisten gängigen GUI-Rahmenwerke zu, die in der Regel auch nicht an eine Sprache gebunden sind. Anbindungen an Gtk, Qt, Tk, und wxWidgets gibt es für viele Programmiersprachen.

Im Grunde hilft Python “allein“ schon, denn `tkinter` ist Bestandteil der Python-Standardbibliothek. Tk mag das einfachste für den Einstieg sein, aber man trifft dort halt auch am ehesten auf die Grenzen. Ist halt alles ein bisschen alt und primitiv. Es gibt kaum etwas, wenn man das mal mit den anderen, moderneren GUI-Rahmenwerken vergleicht. Wenn man so etwas braucht, muss man bei Tk anfangen selber zu basteln. Fängt ja schon bei Tooltips an.

Bei der `Gridbox`-Klasse bin ich dann irgendwo erstaunt warum das sein muss sich das mit ~300 Zeilen zu basteln, statt einfach etwas zu nehmen was das verwendete GUI-Rahmenwerk schon an Bord hat.

Keine Ahnung was Du da über 45 Jahre schreiben könntest und was das Zitat sagen soll, Fakt ist, dass *heute* ein Programm, dass jeder einfach benutzen können soll, keine Positions- und Grössenangaben in hart kodierten Pixeln verwenden darf. Monitorgrössen und Auflösungen variieren einfach zu stark, als das man auf die Weise eine GUI schreiben könnte, die nicht für einen Teil der Nutzer zu klein und einen anderen Teil der Nutzer zu gross ist. Und wenn dann noch Schriften in psyikalischen Grössen angibt, und die GUI wo die Texte drin sind in Pixeln, dann wird das bei Systemen mit hoher physikalischer Punktdichte unbenutzbar werden, weil die Texte da mit dem verfügbaren Platz so gar nicht auskommen werden.

Es wäre einfacher und IMHO auch deutlich sinnvoller einfach mal mit dem anzufangen was das GUI-Rahmenwerk bietet, und wie man das normal/idiomatisch verwendet. Ich denke es geht darum eine funktionierende Anwendung zu haben, also sehe ich nicht warum man sich so etwas wie ein Tabellenwidget mit 300 Zeilen Code bastelt, wenn es so etwas schon fertig gibt. Ja, das hat sicher eine andere API, als die XProfan-Gridbox, aber rechtfertigt das den Aufwand? Du verzettelst Dich da IMHO.

Ich würde wie gesagt mit der CPU anfangen, unabhängig von der GUI. Das ist ja das Kernstück, egal welches GUI-Rahmenwerk man dann letztendlich benutzt. Mit einer Methode die genau einen Schritt ausführt. Analog zur Taktleitung die eine echte CPU hat. Ein einfaches Ladeprogramm, dass die Datenspalte von vorhandenen HC680-*.txt-Dateien in den Speicher laden kann. Und dann kann man damit schon mal das Ganze in einer einfachen Schleife laufen lassen und testen, mit `print()`-Ausgaben. Als nächstes könnte man eine Funktion schreiben, die ein Byte disassembliert. Dann kann man bei jedem Schritt den Code ausgeben, der gerade ausgeführt wird. *Darauf* könnte man dann schon mal eine GUI setzen.

[sparrow]

"Grafikdarstellung braucht man nicht in der wirtschaftlichen Nutzung"

Diese Aussage ist auf sehr vielen Ebenen falsch.


Bei Emulator und Prozessor musste ich sofort an Jens und das hier denken: viewtopic.php?t=32089

[kbr]

Ein sinngemäßes, uraltes Zitat eines damals anerkannten Experten: "Grafikdarstellung braucht man nicht in der wirtschaftlichen Nutzung"

Diese Meinung wurde sicher eine Weile von einigen vertreten, obgleich zu dem Zeitpunkt die Einschätzung, es gäbe weltweit einen Markt für vielleicht 7 Computer, schon völlig überholt war. Tatsächlich sind Grafiken *das* Interface für die meisten Benutzer in der Business-Welt (und nicht nur dort) und damit heute sehr relevant für die wirtschaftliche Nutzung.

[grubenfox]

Bei Emulator und Prozessor musste ich sofort an Jens und das hier denken: viewtopic.php?t=32089

Faszinierend was es so alles gibt...
ich habe da noch so was gefunden:
https://github.com/Medo-ID/CPU_Simulator_using-pytyhon
https://github.com/dominikoetiker/virtual_cpu_python
https://github.com/redfast00/RCPU

Der erste Link ist schön einfach gehalten, beim zweiten ist die CPU deutlich komplexer und das dritte Projekt sieht relativ tot aus. Wobei alles ohne GUI, nur mit 'print' bzw. Konsoslenausgaben...