Forum: PC-Programmierung Welche Programmiersprache für Comports?


von Klaus S. (kseege)


Lesenswert?

Habe in der letzten Zeit immer Tcl/Tk benutzt, um meine Mikrocontroller 
über den ComPort anzusprechen. Das war zwar bequem, bei etwas 
anspruchsvolleren Operationen gabs aber Überraschungen. So hat die 
Umwandlung von Characters in 2stellige Hexadezimalzahlen im oberen 
Bereich >127 über 10 Zeichen falsch umcodiert, so daß ich das mit einem 
externen C-Programm abfangen mußte.

Ich bin deshalb auf der Suche nach einer Programmiersprache, die ähnlich 
komfortabel das Ansprechen des ComPorts erlaubt, aber weniger Fehler 
macht. Meine erste Idee war zwar, Python zu nehmen, aber meine Versuche 
damit sind (wie früher schon) nicht besonders glücklich ausgegangen. Mit 
dem Python-Download (23 MB!) war das wohl unvermeidliche "import serial" 
gar nicht zu machen, der nächste Versuch mit Thonny portable (29 MB!) 
ergab damit immerhin keinen Fehler mehr, aber ein kleiner Test mir 
"import numpy" zeigte schnell, daß es wohl doch noch bei mir an ziemlich 
viel Wissen mangelt. Offensichtlich nutzt man mit Python trotz des 
Umfangs nur eine Art Basismodell, das aber erst mit Insiderwissen 
nützlich wird, wovon aber in den per Google zahlreich auftauchenden 
Tutorials leider nichts enthalten ist. Und der Schnellkurs in pip, den 
ich gefunden habe, wirkte ziemlich abschreckend. Da kann ich auch in 
FASM programmieren, das schreckt weniger.

Gibt es überhaupt so etwas, wie einfach, komfortabel und gut für die 
ComPorts oder bin ich zu anspruchsvoll?

Mit freundlichen Grüßen
Klaus (der soundsovielte)

von Erwin (Gast)


Lesenswert?

Klaus S. schrieb:
> Gibt es überhaupt so etwas, wie einfach, komfortabel und gut für die
> ComPorts oder bin ich zu anspruchsvoll?

Du gehst falsch an das Problem heran. Anstatt etwas zu suchen, dass ohne 
Lernaufwand dein Problem löst, solltest du erst lernen, wie du es mit 
den dir zur Verfügung stehenden Mitteln lernen kannst.

Das ist ähnlich wie eine Schraube, die du versucht linksherum 
reinzudrehen. Nachdem das bei zig Versuchen nicht geklappt hast, fragst 
du, welcher Hammer am besten ist, um eine Schraube einzuschlagen...

von MaWin (Gast)


Lesenswert?

Klaus S. schrieb:
> Mit
> dem Python-Download (23 MB!) war das wohl unvermeidliche "import serial"
> gar nicht zu machen

https://pypi.org/project/pyserial/

von Zeno (Gast)


Lesenswert?

Klaus S. schrieb:
> Habe in der letzten Zeit immer Tcl/Tk benutzt, um meine Mikrocontroller
> über den ComPort anzusprechen. Das war zwar bequem, bei etwas
> anspruchsvolleren Operationen gabs aber Überraschungen. So hat die
> Umwandlung von Characters in 2stellige Hexadezimalzahlen im oberen
> Bereich >127 über 10 Zeichen falsch umcodiert, so daß ich das mit einem
> externen C-Programm abfangen mußte.
Das das falsch umcodiert wurde ist aber nicht eine Frage der 
Programmiersprache an sich, sondern eine Frage der Logik die 
letztendlich hinter der Umcodierung steckt.

Überhaupt dürfte es nicht von der Programmiersprache abhängig sein wie 
komfortabel man den COM-Port anspricht. Das Umwandeln der Zeichen von 
Char in Hexadezimal hat auch nichts mit dem COM-Port oder dessen 
Routinen zu tun, das ist eine andere Baustelle.

Du hast da wohl einfach irgendwas, in dem Fall von Tcl/Tk, übenommen, 
ohne Dir wirklich Gedanken zu machen, was da im Hintergrund passiert und 
wie die Übertragung abläuft.

Den COM-Port kann man z.B. sehr komfortabel mit Objektpascal ansprechen. 
Da gibt es für Delphi etliche Komponenten, die einem dabei viel Arbeit 
abnehmen.
Es funktioniert aber genauso gut auch mit C oder Basic. Im Endeffekt 
dürfte jede Programmiersprache funktionieren. Selbst in der Bash sollte 
es problemlos funktionieren den Port über das Gerätedevice anzusprechen. 
Die Daten zur Übertragung muß man natürlich passend aufbereiten, aber 
das wird einem bei keiner Programmiersprache abgenommen.

von Sebastian (Gast)


Lesenswert?

Klaus S. schrieb:
> So hat die Umwandlung von Characters in 2stellige Hexadezimalzahlen im
> oberen Bereich >127 über 10 Zeichen falsch umcodiert, so daß ich das mit
> einem externen C-Programm abfangen mußte.

Tcl war eine der ersten Programmiersprachen mit guter 
Unicode-Unterstützung. Wenn du für die obige Aufgabe ein externes 
C-Programm bemühen musstest, dann sind dir, so vermute ich, einige 
encoding-Feinheiten in Tcl entgangen.

Python ist diesbezüglich auch recht sauber.

Man muss halt systematisch und strikt Bytes und Glyphen 
auseinanderhalten, wenn man den ASCII-Bereich verlässt.

LG, Sebastian

von Manfred (Gast)


Lesenswert?

Sebastian schrieb:
> Wenn du für die obige Aufgabe ein externes
> C-Programm bemühen musstest,

... dann kann dieses die serielle Schnittstelle auch gleich selbst 
abfragen.

von Stefan F. (Gast)


Lesenswert?

Klaus S. schrieb:
> So hat die
> Umwandlung von Characters in 2stellige Hexadezimalzahlen im oberen
> Bereich >127 über 10 Zeichen falsch umcodiert, so daß ich das mit einem
> externen C-Programm abfangen mußte.

Das kann ich nicht glauben.

Die Umrechnung von Bytes in Hexadezimale Schreibweise ein eine ganz 
simple Basis-Operation. Niemand würde eine Programmiersprache 
veröffentlichen, die das nicht kann.

Hasst du eventuell Zeichensätze durcheinander gebracht?

von DerEinzigeBernd (Gast)


Lesenswert?

Stefan F. schrieb:
> Hasst du eventuell Zeichensätze durcheinander gebracht?

Das ist sehr wahrscheinlich. Wer ASCII kennt (oder annimmt, zu kennen) 
und unvorbereitet auf UTF-8 stößt, der kann lustige Effekte erleben.

von Andreas M. (amesser)


Lesenswert?

Klaus S. schrieb:
> Offensichtlich nutzt man mit Python trotz des
> Umfangs nur eine Art Basismodell, das aber erst mit Insiderwissen
> nützlich wird, wovon aber in den per Google zahlreich auftauchenden

Python ist modular aufgebaut und viel Funktionalität steckt in Packages, 
die erst installiert werden müssen. Unter Linux meist per Paketmanager, 
unter Windows ab besten mit pip:
1
python -m pip install pyserial

Ich empfehle Dir Visual-Code mit Python Erweiterung als Editor...

von ... (Gast)


Lesenswert?

> ... dann kann dieses die serielle Schnittstelle auch gleich selbst
> abfragen.

So sehe ich das auch. Gibt ein nettes Executable und man braucht
den ganzen grossen vollen Rucksack eines Interpreters nicht mehr
mit herumtragen.

Die Ausnahme waere, man kann aus dem Rucksack etwas wirklich
gebrauchen und moechte sich die Arbeit dafuer nicht machen...
Wenn es z.B. exotische Hardware ist, wo der Hersteller einen
Pythoninterpreter mit Interfacefunktionen dafuer schon liefert.

Ansonsten kann man fuer serielle Schnittstellen ja auch
Matlab bemuehen. Das kann das auch. :)

von ... (Gast)


Lesenswert?

Spontan faellt mir auch noch "MMBasic" ein.
Davon gibt es einen PC-Port der mit der basicartigen "Leichtigkeit"
mit seriellen Schnittstellen, Zeichen und Zeichenketten umgehen kann.
Das koennte man dann auch gewissermassen stand-alone auf einem
Maximite oder einem seiner vielen Derivate laufen lassen.
Und braucht dann keinen ganzen PC mehr dafuer.

von Dirk B. (dirkb2)


Lesenswert?

schau dircerstmal das encoding von Tcl/Tk an.

Das kann man für jeden Stream extra - auch nachträglich - einstellen.

Evtl. spielt ja schon die -translation Option eine Rolle.

: Bearbeitet durch User
von DerEinzigeBernd (Gast)


Lesenswert?

Ja, statt hektisch nach anderen Programmiersprachen zu suchen, würde ich 
versuchen, das eigentliche Verständnisproblem bei der ansonsten ja wohl 
beherrschten Programmiersprache zu lösen.


Du könntest beschreiben, welche Zeichen auf welche Weise "falsch" 
codiert wurden und was Du stattdessen erwartet hast.

von Klaus S. (kseege)


Lesenswert?

Danke für alle Zuschriften. Wenn ich aber gewußt hätte, daß mein nur als 
Beispiel gemeintes Problem mit Tcl soviel Aufmerksamkeit findet, hätte 
ich etwas mehr dazu geschrieben. Es ging ganz einfach darum, ein Hexfile 
von einem freien 8051-Assembler in einen 89S51 zu verfrachten. Da ich 
einen ganzen Tag damit verbracht hatte, das mit PonyProg oder 
avrdude/AVRISP zu bewerkstelligen und dabei kläglich gescheitert war, 
hatte ich dementsprechend schlechte Laune und habe notgedrungen ein 
eigenes Programm geschrieben. Dabei war eben das Hexfile im Wege, einen 
Interpreter des Intel-Hex-Formats zu schreiben war mir zu aufwändig und 
so habe ich mit Hexe2Bin.exe das Ganze auf binär umformatiert. Und damit 
begannen dann die Probleme mit Tcl.
Im Endeffekt habe ich die ganze Binärdatei in C in einem Rutsch in 
Hexadezimalschreibweise umformatiert, das hat die Datei einen Faktor 2 
aufgeblasen, war aber in 10 Minuten erledigt und ich konnte mit 
ASCI-Zeichen weitermachen und einen Arduino mit Komandos füttern, der 
dann die Bytes in den 89S51 klopfte.
Natürlich muß das kein Fehler von Tcl gewesen sein, sondern eher meine 
Dummheit. Aber ich empfand damals (ca 3 Jhre her) die Dokumentation über 
die Behandlung binärer Daten in Tcl als ausgesprochen schlecht, das ist 
heute erheblich besser geworden (oder ich im Dokufinden :-).

Wie Dirk B. schrieb, ist vermutlich der Unterschied von "-translating 
binary" und "-encoding binary" der Schlüssel zum Verständnis. Ich werde 
dazulernen.

Den Tipp mit MMBasic habe ich mir gemerkt. Allerdings habe ich damals, 
als der Maximite erschien, bereits bedauert, daß Geoff nicht den 725er 
eingesetzt hat, der mit Ethernet ausgestattet ist. Insofern befürchte 
ich, daß MMBasic nicht einmal UDP kann, von TCP gar nicht zu reden. Aber 
erneut anschauen werde ich es mir auf jeden Fall. Zu MS-DOS-Zeiten war 
GWBasic der Effizienzchampion für den ComPort, viel Effekt mit wenigen 
Zeilen Code.

Da ich im Moment wegen Corona zur Isolation verdonnert bin, habe ich 
Zeit zum Experimentieren und werde mir die Vorschläge der Reihe nach 
vornehmen.
Fast könnte ich sagen: Schön, daß nach 7 Tagen der Schnelltest immer 
noch zwei dicke Striche anzeigt.

Gruß Klaus (der soundsovielte)

P.S. Tcl hat aus meiner Sicht 3 Schwachpunkte:
UDP fehlt mir, Behandlung binärer Daten ist extrem ausbaufähig und der 
Aufruf externer DLLs ist (zumindest aus meiner Sicht) unterirdisch. Daß 
es degegen schnarchlangsam ist, macht es mir eher sympathisch :-)

Beitrag #7298750 wurde von einem Moderator gelöscht.
von Zeno (Gast)


Lesenswert?

DerEinzigeBernd schrieb:
> Ja, statt hektisch nach anderen Programmiersprachen zu suchen, würde ich
> versuchen, das eigentliche Verständnisproblem bei der ansonsten ja wohl
> beherrschten Programmiersprache zu lösen.
Ich frage mich warum es überhaupt nötig ist da eine Programmiersprache 
zu bemühen.
Das Ansprechen eines µC's klappt ja schon mit einem simplen 
Terminalprogramm.
Unter Linux funktioniert das Ganze sogar mit einem Bash-Script. Selbst 
unter Windows sollte es mit CMD-Befehlen (mode, echo etc.) 
funktionieren.
Einen Interpreter an dieser Stelle zu bemühen der auf dem 
Standardsystem, zumindest unter Windows, nicht verfügbar ist, halte ich 
für suboptimal.

Aber alles egal, es scheint eh nicht so wichtig zu sein, denn der TO hat 
sich seit dem Eröffnungspost nie wieder gemeldet.

von Zeno (Gast)


Lesenswert?

Update:
Oh der TO hat sich gemeldet, während ich hier getippt habe.

von DerEinzigeBernd (Gast)


Lesenswert?

Klaus S. schrieb:
> P.S. Tcl hat aus meiner Sicht 3 Schwachpunkte:
> UDP fehlt mir

Hilft vielleicht das hier?
https://wiki.tcl-lang.org/page/TclUDP

Beitrag #7298812 wurde von einem Moderator gelöscht.
Beitrag #7298831 wurde von einem Moderator gelöscht.
von Klaus S. (kseege)


Lesenswert?

Zeno schrieb:
> Ich frage mich warum es überhaupt nötig ist da eine Programmiersprache
> zu bemühen.

Nötig nicht, aber praktisch. Das 2,5 KByte große Maschinenprogramm für 
den 89S51 über ein Terminalprogramm in den Arduino zu tippen, der es 
dann über SPI weiterleitet, wäre mir zu aufwändig gewesen. Möglich wärs 
natürlich gewesen. Wie man mit Windows Bordmitteln die Synchronisation 
hinbekommt, um den Arduino bei seiner Arbeit nicht zu überfordern (nicht 
genug RAM, um den Job im Ganzen zu speichern, die ersten Zeichen nach 
Öffnen des ComPorts werden vom UNO gnadenlos verschluckt) ist mir 
allerdings unklar. Da wäre ich für Erleuchtung dankbar.

Gruß Klaus (der soundsovielte)

von Klaus S. (kseege)


Lesenswert?

DerEinzigeBernd schrieb:
> Hilft vielleicht das hier?
> https://wiki.tcl-lang.org/page/TclUDP

Danke für den Hinweis.
Sieht aber im ersten Durchsehen so aus, als bräuchte ich 3 Tage, um das 
zum Laufen zu bekommen und außerdem ist wohl nur eine 32-bit-Version für 
Windows vorhanden. Meine Lösung ist typischerweise eine Pipe zu einem 
kleinen C-Programm, das dann den UDP-Verkehr abwickelt. Pipes oder 
TCP-Kanäle zu anderen Programmen funktionieren in Tcl ganz hervorragend 
und sind auch meine Umstandslösung für das DLL-Problem. Ist zwar weniger 
elegant, aber schneller fertig.

Gruß Klaus (der soundsovielte)

von DerEinzigeBernd (Gast)


Lesenswert?

Klaus S. schrieb:
> Sieht aber im ersten Durchsehen so aus, als bräuchte ich 3 Tage, um das
> zum Laufen zu bekommen

Aha.

> und außerdem ist wohl nur eine 32-bit-Version für
> Windows vorhanden.

Und, wo ist das Problem? Brauchst Du zwingend 64-Bit-Programme?

Ansonsten liegt der Kram im Sourcecode vor, mit VS sollte es möglich 
sein, daraus auch eine 64-Bit-DLL zu machen.

Hier https://core.tcl-lang.org/tcludp/dir?ci=tip wird beschrieben, wie 
man das übersetzt; wenn man sich mit VS auskennt, sollte ein 
64-Bit-Build keine Raketenwissenschaft sein.

Aber vielleicht findest Du ja hier was anderes:

https://wiki.tcl-lang.org/page/UDP+for+Tcl

von Klaus S. (kseege)


Lesenswert?

DerEinzigeBernd schrieb:
> Hier https://core.tcl-lang.org/tcludp/dir?ci=tip wird beschrieben, wie
> man das übersetzt; wenn man sich mit VS auskennt, sollte ein
> 64-Bit-Build keine Raketenwissenschaft sein.

Danke für die Hinweise und Deine gute Meinung über mich. Ich bin aber 
vermutlich nicht einmal halb so gut im Programmieren, wie Du denkst. Ich 
beherrsche nicht einmal make und schon gar nicht VS, ich programmiere zu 
Fuß, immer eine Datei nach der Anderen. Wenn ich wüßte, wie man Tcl mit 
einem C-Programm erweitert, hätte ich längst eine eigene UDP-Erweiterung 
geschriebe. In C die Sytemlibrary mit dem Socketinterface aufzurufen 
mache ich ja, das funktioniert einwandfrei (mit Borland-C und TCC).

Ein in Tcl geschriebenes Unterprogramm für UDP würd ich wohl eingebaut 
bekommen, zu mehr langts bei mir aber nicht, weil es einfach zuviele 
andere interessante Projekte gibt und mir langsam die Lebenszeit 
davonrennt.


Gruß Klaus (der soundsovielte)

von Stefan F. (Gast)


Lesenswert?

Da du schon mit C vertraut bist, könntest du dein PC Programm ebenfalls 
in C oder vielleicht C++ schreiben. Für beide gibt es GUI Bibliotheken.

von R. M. (rmax)


Lesenswert?

Ich habe viel Erfahrung mit Tcl, aber wenig mit Tcl unter Windows. Eine 
kurze Recherche hat aber ergeben, dass es durchaus Tcl-Distributionen 
für 64Bit-Windows gibt, die TclUDP enthalten, z.B. ActiveTcl (kostenlos 
aber man muss einen Account anlegen) oder Magicsplat.

https://www.activestate.com/products/tcl/
https://www.magicsplat.com/tcl-installer/index.html

ActiveState hat bis vor einigen Jahren die Tcl-Entwicklung unterstützt, 
aber die aktiven (Wortspiel nicht beabsichtigt) Tcl-Leute sind da 
inzwischen weg und es scheint in der Firma nur noch ein Nischendarsein 
zu fristen. Magicsplat wird von einem sehr aktiven Mitglied der 
Tcl-Community gepflegt.

von Klaus S. (kseege)


Lesenswert?

Stefan F. schrieb:
> Für beide gibt es GUI Bibliotheken.

Ja, aber so bequem wie Tcl/Tk sind die bei weitem nicht. Es hat ja einen 
Grund, warum Python Tk importiert. Wenn ich mich recht erinnere, war die 
einzige bequeme GUI-Anwendung für C ein Programmpaket namens XVT, das 
hatte aber seinen Preis und rechnet sich bei mir leider nicht. Genutzt 
hätte ich es gerne :-(

Just my 2 cents

von Stefan F. (Gast)


Lesenswert?

Klaus S. schrieb:
> Ja, aber so bequem wie Tcl/Tk sind die bei weitem nicht.

Das stimmt wohl.

von DerEinzigeBernd (Gast)


Lesenswert?

Klaus S. schrieb:
> Es hat ja einen Grund, warum Python Tk importiert.

Du könntest natürlich Tk auch aus C heraus nutzen.

von Klaus S. (kseege)


Lesenswert?

R. M. schrieb:
> Eine
> kurze Recherche hat aber ergeben, dass es durchaus Tcl-Distributionen
> für 64Bit-Windows gibt, die TclUDP enthalten, z.B. ActiveTcl (kostenlos
> aber man muss einen Account anlegen) oder Magicsplat.

Das klingt interessant, danke. Allerdings kommt Magicsplat erstmal 5 
Minuten nicht auf die Hufe und durchsucht stattdessen die gesamte 
Festplatte. Das habe ich vorsichtshalber mal abgebrochen, das kommt 
erstmal auf eine Spielwiese.

Gruß Klaus (der soundsovielte)

von Klaus S. (kseege)


Lesenswert?

DerEinzigeBernd schrieb:
> Du könntest natürlich Tk auch aus C heraus nutzen.

Eigentlich war ja die Vorstellung von John Osterhout, daß sich die 
Tcl-Nutzer ihre Basisfunktionen in C selber schreiben und dazulinken. 
Das hat aber wohl nur so wenige verleitet, es auch zu machen, daß ich 
nirgendwo eine auch mir verständliche Anleitung dazu gefunden habe. 
Gehört eben wieder in das Kapitel mit den zu hoch hängenden Früchten ...

Gruß Klaus (der soundsovielte)

von Klaus S. (kseege)


Lesenswert?

Ousterhout natürlich. Soviel Rechtschreibung sollte sein.

von R. M. (rmax)


Lesenswert?

Klaus S. schrieb:

> Gehört eben wieder in das Kapitel mit den zu hoch hängenden Früchten ...

Eigentlich hängt das nicht allzu hoch. Falls Du schonmal ein 
Kommandozeilenprogramm in C geschrieben hast (argc, argv), dann kannst 
Du im Grunde auch ein Tcl-Kommando mit der ursprünglichen String-API 
implementieren.

Schau' Dir mal die Doku zu den API-Funktionen Tcl_CreateCommand() und 
Tcl_SetResult an, und/oder wirf mal einen Blick in die Implementierung 
einer kleinen C-Extension für Tcl (z.B. TclUDP. ;) ).

von R. M. (rmax)


Lesenswert?

Das hier könnte auch weiterhelfen, allerdings wird da für die Kommandos 
die modernere Objekt-API genutzt (hat nichts mit objektorientierter 
Programmierung zu tun, sondern damit, wie Tcl intern mit den Daten 
umgeht):

https://wiki.tcl-lang.org/page/Hello+World+as+a+C+extension

von Klaus S. (kseege)


Lesenswert?

R. M. schrieb:
> Das hier könnte auch weiterhelfen

Du machst mich neugierig, ich fühle mich angefixt.

Gruß Klaus (der soundsovielte)

von Zeno (Gast)


Lesenswert?

Klaus S. schrieb:
> Das 2,5 KByte große Maschinenprogramm für
> den 89S51 über ein Terminalprogramm in den Arduino zu tippen, der es
> dann über SPI weiterleitet, wäre mir zu aufwändig gewesen
Da muß man nichts eintippen. Windows Hyperterminal (zumindest bis Win7 
Standardbordmittel) kann auch ganze Dateien sowohl Text als auch Binär 
senden. Unter Windows 10 gibt es Hyperterminal nicht mehr, allerdings 
gibt es jede Menge Alternativen die das auch können. Mit Putty sollte es 
auch funktionieren.

Klaus S. schrieb:
> Wie man mit Windows Bordmitteln die Synchronisation
> hinbekommt, um den Arduino bei seiner Arbeit nicht zu überfordern (nicht
> genug RAM, um den Job im Ganzen zu speichern, die ersten Zeichen nach
> Öffnen des ComPorts werden vom UNO gnadenlos verschluckt) ist mir
> allerdings unklar.
Wenn der Arduino Zeichen verschluckt, dann kann aber der PC bzw. das 
Terminalprogramm nichts dazu. Dann wird es höchste Zeit die Software auf 
dem Arduino zu untersuchen bzw. zu optimieren. Ich habe auch schon mit 
einem "kommerziellen" Terminalprogramm und einem eigenen Programm mit 
diversen µC's kommuniziert, aber Daten werden da keine verschluckt. Das 
sollte eigentlich auch nicht passieren, wenn auf beiden Geräten die 
gleichen Übertragungsparameter eingestellt werden.

von ... (Gast)


Lesenswert?

> und einen Arduino mit Komandos füttern, der
> dann die Bytes in den 89S51 klopfte

Letztes war also das Kernproblem?

Vermutlich waere es einfacher gewesen, den "Arduino" wegzulassen.

Und einen guten alten Kandadongle an den hoffentlich vorhandenen
Parallelport zu stecken.
Wenn es fuer den 89S51 da nicht sogar schon fertige Software gibt...

Haette man das bisschen Bitwackelei mit Hilfe des Dongle,
moeglicherweise auch schon ohne, schneller hinbekommen.

Ich kann mich an einen sehr rudimentaeren JTAG-Adapter fuer
in Netzwerkprodukten verbaute 8 bit CPUs erinnern.
Der bestand eigentlich nur aus einem DB-25 Stecker und einem
4 MHz Oszillator damit der Contoller einen Takt bekam...

von Karl Käfer (Gast)


Lesenswert?

Klaus S. schrieb:
> Ja, aber so bequem wie Tcl/Tk sind die bei weitem nicht. Es hat ja einen
> Grund, warum Python Tk importiert. Wenn ich mich recht erinnere, war die
> einzige bequeme GUI-Anwendung für C ein Programmpaket namens XVT,

Naja, "angenehme GUI-Bibliothek" ist IMHO ein Widerspruch in sich. Aber 
der Grund, warum Pythons mitgelieferte Standardbibliothek seit jeher Tk 
ist, ist simpel: es war verfügbar, plattformunabhängig, und einfach 
anzubinden.

Sonderlich hübsch war es allerdings nie und ist es bis heute nicht, 
deshalb gibt es heutzutage natürlich auch Python-Libraries für andere 
gebräuchliche Libraries wie Qt, wxWidgets und GTK.

Die Python-Entwickler in meinem Umfeld und auch ich selbst bauen aber 
nicht mehr so oft Fatclient-Software mit GUI-Bibliotheken, sondern 
lieber was mit leichtgewichtigen Webapplikationen. Die muß man nur 
einmal zentral pflegen, kann viel Rechen- und Grafikaufwand auf die 
Clients verlagern (poor man's distributed computing quasi), und viele 
Dinge werden deutlich einfacher.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

Klaus S. schrieb:
> R. M. schrieb:
>> Das hier könnte auch weiterhelfen
>
> Du machst mich neugierig, ich fühle mich angefixt.

Neue Tcl-Befehle in C hinzuzufügen ist wirklich nicht schwer - dasselbe 
gilt übrigens auch für neue Tk-Widgets.

Dein ursprüngliches Problem sollte sich auch in reinem Tcl lösen lassen 
- ich halte es für wenig zielführend, das in einer anderen Sprache zu 
tun.  Einfach mal in Ruhe die Beschreibung des Encodings etc. für Tcl 
durchlesen.

Sehr empfehlenswert sind übrigens auch Bücher, unter anderem das sehr 
gute "Practical Programming in Tcl and Tk" von Welsh.

Karl Käfer schrieb:
> Sonderlich hübsch war es allerdings nie und ist es bis heute nicht,

Was aber nicht an Tk liegt sondern daran, dass viele offenbar bei Motif 
und dem ersten Widget-Set von Tk stehengeblieben sind. TTk und Styles 
gibt es nun wirklich schon einige Zeit, genauer seit Anfang der 2000er 
(da steckt sogar noch Code von mir drin :-)

> deshalb gibt es heutzutage natürlich auch Python-Libraries für andere
> gebräuchliche Libraries wie Qt, wxWidgets und GTK.

Welche sich vom Aussehen her übrigens problemlos mit ttk nachempfinden 
lassen.

Karl Käfer schrieb:
> Die Python-Entwickler in meinem Umfeld und auch ich selbst bauen aber
> nicht mehr so oft Fatclient-Software mit GUI-Bibliotheken, sondern
> lieber was mit leichtgewichtigen Webapplikationen. Die muß man nur
> einmal zentral pflegen, kann viel Rechen- und Grafikaufwand auf die
> Clients verlagern (poor man's distributed computing quasi), und viele
> Dinge werden deutlich einfacher.

Es hängt immer davon ab, was man machen möchte. Für viele Dinge sind 
Webapplikationen eine tolle Sache - für andere nicht.

Wir arbeiten hier bspw. bei Maschinen-/Gerätesteuerungen schon lange auf 
einfachen Controllern (früher AVR, jetzt STM32) unter NuttX mit einem 
angepassten Tcl-Interpreter und angepasster Tk-Bibliothek. D.h. dass 99% 
des Nutzer-Codes tatsächlich als Tcl-Code vorliegt und wir nur einige 
wenige Dinge (RT-Komponenten etc.) in C coden.

Apropos "Fat-Client-Libs": nach dem finalen Aufräumen (Code für nicht 
benötigte Widgets etc. rauswerfen etc.) steckt das komplette RTOS samt 
Tk-Oberfläche, Interpreter und User-Tcl-Code in unter 192k Flash und 
läuft bereits auf einem Atmega2560 mit 10"-Touch flüssig.

Ein weiterer Vorteil (kennt heute ja kaum noch jemand): ich schalte das 
Gerät ein und nach 0,5s ist die Oberfläche da und das Ding 
betriebsbereit - in welchem Style (Aqua, GTK, Qt, Motif etc.) auch immer 
;-)

Man kann also durchaus die Größe deutlich eindampfen, ohne 
Programmierkomfort zu verlieren: ich schreibe die Oberflächen genau so 
einfach in Tcl/Tk, wie ich es für den PC tue - wenn gewünscht sogar zur 
Laufzeit. Wobei Steuerungen dieser Art natürlich den Vorteil haben, dass 
Bildschirmgröße etc. üblicherweise unveränderlich sind, man also gut mit 
dem Placer arbeiten kann.

: Bearbeitet durch Moderator
von Klaus S. (kseege)


Lesenswert?

Chris D. schrieb:
> Dein ursprüngliches Problem sollte sich auch in reinem Tcl lösen lassen

Ja. seit Dirks Hinweis auf "fconfigure $filehandle -translation binary" 
kann ich in Tcl mit binären Daten genauso elegant umgehen wie mit 
Characterfeldern beliebiger Normierung. Die Umwandlung in Hexzahlen 
funktioniert jetzt auch einwandfrei. Damals habe ich mir einen Wolf 
gesucht im Internet, um was über binäre Daten in Tcl zu finden. Heute 
gibts ne ganze Webseite dazu mit allen Informationen, die mir damals 
gefehlt haben. Da waren die 10 Minuten für das C-Programm gut angelegte 
Zeit, ich hatte schon genug Zeit mit den angeblich funktionierenden 
Programmen Ponyprog und avrdude verballert. Manchmal hat man einfach die 
Schnauze voll und pfeift auf akademische Sortenreinheit.

Gruß Klaus (der soundsovielte)

P.S. Meine beiden Tcl-Bücher von John Ousterhout und Mark 
Harrison/Michael McLennan schweigen sich über Binärdaten aus, hinter 
"Bildschirm" kommt im Stichwortberzeichnis gleich "bind".

von Klaus S. (kseege)


Lesenswert?

... schrieb:
> Und einen guten alten Kandadongle an den hoffentlich vorhandenen
> Parallelport zu stecken.
> Wenn es fuer den 89S51 da nicht sogar schon fertige Software gibt...

Hatte ich oben beschrieben, daß ich das schon gemacht hatte. Oder ist 
Dir PonyProg unbekannt?

Gruß Klaus (der soundsovielte)

von Klaus S. (kseege)


Lesenswert?

Karl Käfer schrieb:
> Naja, "angenehme GUI-Bibliothek" ist IMHO ein Widerspruch in sich.

XVT schon einmal angeschaut?

Gruß Klaus (der soundsovielte)

von Klaus S. (kseege)


Lesenswert?

Chris D. schrieb:
> Apropos "Fat-Client-Libs": nach dem finalen Aufräumen (Code für nicht
> benötigte Widgets etc. rauswerfen etc.) steckt das komplette RTOS samt
> Tk-Oberfläche, Interpreter und User-Tcl-Code in unter 192k Flash und
> läuft bereits auf einem Atmega2560 mit 10"-Touch flüssig.

Klingt saumäßig interessant. Wenn ich nicht gerade (wie im Moment) eine 
Halcon-Bildverarbeitung brauchen würde, täte sowas für einige meiner 
Maschinen auch gut passen. Gibts dazu mehr Info oder ist das 
confidential?

Gruß Klaus (der soundsovielte)

von Karl Käfer (Gast)


Lesenswert?

Chris D. schrieb:
> Karl Käfer schrieb:
>> Sonderlich hübsch war es allerdings nie und ist es bis heute nicht,
>
> Was aber nicht an Tk liegt sondern daran, dass viele offenbar bei Motif
> und dem ersten Widget-Set von Tk stehengeblieben sind.

Ach, das war halt Motif. War noch nie besonders hübsch, tat aber immer 
sang- und klanglos seinen Dienst.

> TTk und Styles
> gibt es nun wirklich schon einige Zeit, genauer seit Anfang der 2000er
> (da steckt sogar noch Code von mir drin :-)

Vielen Dank für Deinen Beitrag dazu!

>> deshalb gibt es heutzutage natürlich auch Python-Libraries für andere
>> gebräuchliche Libraries wie Qt, wxWidgets und GTK.
>
> Welche sich vom Aussehen her übrigens problemlos mit ttk nachempfinden
> lassen.

Den Absprung zu Themed-Tk habe ich leider irgendwie verpaßt, aber ich 
habe schon einige sehr hübsch gestaltete Oberflächen damit gesehen. 
Vielleicht sollte ich mir das doch noch einmal anschauen.

> Karl Käfer schrieb:
>> Die Python-Entwickler in meinem Umfeld und auch ich selbst bauen aber
>> nicht mehr so oft Fatclient-Software mit GUI-Bibliotheken, sondern
>> lieber was mit leichtgewichtigen Webapplikationen. Die muß man nur
>> einmal zentral pflegen, kann viel Rechen- und Grafikaufwand auf die
>> Clients verlagern (poor man's distributed computing quasi), und viele
>> Dinge werden deutlich einfacher.
>
> Es hängt immer davon ab, was man machen möchte. Für viele Dinge sind
> Webapplikationen eine tolle Sache - für andere nicht.
>
> Wir arbeiten hier bspw. bei Maschinen-/Gerätesteuerungen schon lange auf
> einfachen Controllern (früher AVR, jetzt STM32) unter NuttX mit einem
> angepassten Tcl-Interpreter und angepasster Tk-Bibliothek. D.h. dass 99%
> des Nutzer-Codes tatsächlich als Tcl-Code vorliegt und wir nur einige
> wenige Dinge (RT-Komponenten etc.) in C coden.

Das ist natürlich ein anderer Anwendungsfall. Aber beim TO geht es ja um 
einen PC-Client, und da bietet sich das von mir beschriebene Vorgehen 
IMHO durchaus an. Das machen ja auch schon einige so, das neue PgAdmin4 
ist zum Beispiel eine Flask-Webapplikation. Wenn das lokal aufgerufen 
wird, dann wird sie in einem lokalen Minimal-Browser ausgeführt, aber 
man kann diese Webapplikation eben auch ganz einfach im Servermodus 
betreiben und dann netzwerkweit nutzen, ohne etwas auf die Clients 
ausrollen zu müssen.

von Karl Käfer (Gast)


Lesenswert?

Klaus S. schrieb:
> Karl Käfer schrieb:
>> Naja, "angenehme GUI-Bibliothek" ist IMHO ein Widerspruch in sich.
>
> XVT schon einmal angeschaut?

Das habe ich mir vor vielen Jahren einmal angesehen, ebenso wie einige 
andere GUI-Designer, aber wirklich überzeugt hat mich keines davon. Das 
Design und die Entwicklung von GUI-Software ist IMHO immer ein PITA, da 
beißt die Maus keinen Faden ab und auch Softwaretools helfen allenfalls 
dabei, diesen Schmerz ein wenig zu lindern. Auch das ist ein Grund warum 
ich heute lieber Webapplikationen sogar dann entwickle, wenn sie am Ende 
lokal auf einem Fatclient laufen sollen.

von Klaus S. (kseege)


Lesenswert?

Karl Käfer schrieb:
> Design und die Entwicklung von GUI-Software ist IMHO immer ein PITA

Dann wäre doch die beste Methode, das Anderen zu überlassen :-)


Karl Käfer schrieb:
> Auch das ist ein Grund warum
> ich heute lieber Webapplikationen sogar dann entwickle, wenn sie am Ende
> lokal auf einem Fatclient laufen sollen.

Welches Tool hilft Dir denn dabei, den/die "PITA" ignorieren zu können?


Gruß Klaus (der soundsovielte)

von Karl Käfer (Gast)


Lesenswert?

Klaus S. schrieb:
> Karl Käfer schrieb:
>> Design und die Entwicklung von GUI-Software ist IMHO immer ein PITA
>
> Dann wäre doch die beste Methode, das Anderen zu überlassen :-)

Nichts(!) lieber als das! :)

> Karl Käfer schrieb:
>> Auch das ist ein Grund warum
>> ich heute lieber Webapplikationen sogar dann entwickle, wenn sie am Ende
>> lokal auf einem Fatclient laufen sollen.
>
> Welches Tool hilft Dir denn dabei, den/die "PITA" ignorieren zu können?

Ein Webbrowser, der nur ein einziges, vollflächiges HTML-Widget hat, ist 
mit einem GUI-Toolkit wie wxWidgets oder Qt schnell gebaut. Für das 
Backend verwende ich Python, in einfachen Fällen mit Flask oder für 
größere Webapps auch gerne mal mit Django. Ach so, ja, und natürlich 
Python: das ist flott, ultrastabil, sehr angenehm beim Coden, dazu gibt 
es eine geradezu unendlich große Vielfalt an mitgelieferten, und erst 
Recht an externen Bibliotheken. Und in den allerdings ziemlich seltenen 
Fällen, daß etwas mal nicht schnell genug oder gar nicht erst verfügbar 
ist, läßt sich Python ganz leicht mit C- und / oder C++ erweitern.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

Klaus S. schrieb:
> Chris D. schrieb:
>> Apropos "Fat-Client-Libs": nach dem finalen Aufräumen (Code für nicht
>> benötigte Widgets etc. rauswerfen etc.) steckt das komplette RTOS samt
>> Tk-Oberfläche, Interpreter und User-Tcl-Code in unter 192k Flash und
>> läuft bereits auf einem Atmega2560 mit 10"-Touch flüssig.
>
> Klingt saumäßig interessant. Wenn ich nicht gerade (wie im Moment) eine
> Halcon-Bildverarbeitung brauchen würde, täte sowas für einige meiner
> Maschinen auch gut passen. Gibts dazu mehr Info oder ist das
> confidential?

Ja, das ist leider nur zum "internen Gebrauch" ;-)
Da hab ich/bzw. wir einfach über die Jahre viel Zeit und Arbeit 
reingesteckt, die wir uns jetzt natürlich vergüten lassen.

Karl Käfer schrieb:
> Das habe ich mir vor vielen Jahren einmal angesehen, ebenso wie einige
> andere GUI-Designer, aber wirklich überzeugt hat mich keines davon. Das
> Design und die Entwicklung von GUI-Software ist IMHO immer ein PITA, da
> beißt die Maus keinen Faden ab und auch Softwaretools helfen allenfalls
> dabei, diesen Schmerz ein wenig zu lindern. Auch das ist ein Grund warum
> ich heute lieber Webapplikationen sogar dann entwickle, wenn sie am Ende
> lokal auf einem Fatclient laufen sollen.

Hehe, da ist was dran. Es ist auch weniger die Positionierung der 
Elemente als eine vernünftige Bedienbarkeit - ist gerade bei 
Maschinensteuerungen nicht einfach, je nachdem, wer später davorsteht 
(Profi, Facharbeiter, Angelernter usw.).

Die ganzen Gui-Designer, die ich mir angeschaut habe (durchaus nicht nur 
für Tk) helfen einfach nicht wirklich, weil man letztendlich doch jedes 
Widget mit entsprechenden Attributen usw. versehen muss und das dann in 
Klickorgien ausartet. Da kann man es auch direkt im Editor coden, da ist 
man deutlich schneller. Wenn man natürlich alle halbe Jahre mal einer 
Oberfläche baut, dann kann das interessant sein, weil man schlicht viele 
Optionen etc. vergisst.

Ich handhabe das hier mit der Positionierung so, dass ich mir anfangs 
per Code alle nötigen Widgets erstelle und dann die Oberfläche starte. 
Ein Skript läuft den ganzen Widgetbaum dann ab und ergänzt die Widgets 
durch passende Bindings für Mausziehen + gehaltene Zusatztaste. Damit 
kann ich dann die Widgets einzeln dorthin schieben, wo ich sie haben 
möchte. Dann nochmal eine Tastenkombi und die Positionen werden als 
Tcl-Paket für den Placer geliefert. Dann nur noch reinkopieren und die 
Widgest sitzen schon mal dort, wo sie sein sollen. Also so ähnlich wie 
bei PCB-Programmen, wo die Gehäuse erstmal alle auf einem Haufen liegen 
und man sie dann nach und nach dorthin zieht, wo es einem günstig 
erscheint. Das funktioniert natürlich nur beim Placer, aber wie gesagt: 
Maschinensteuerungen haben eher selten veränderliche Bildschirmgrößen 
:-)

Das ist über die Jahre ein wirklich nützliches "Tool" geworden, obwohl 
ich das mal an einem Vormittag programmiert habe. Aber ich mache 
generell viele Anpassungen zur Laufzeit. geht einfach am schnellsten.

Karl Käfer schrieb:
> Den Absprung zu Themed-Tk habe ich leider irgendwie verpaßt, aber ich
> habe schon einige sehr hübsch gestaltete Oberflächen damit gesehen.
> Vielleicht sollte ich mir das doch noch einmal anschauen.

Ist eine schöne Sache - aber wenn Du mit Deinen anderen Widgetsets 
zufrieden bist, dann lohnt das wohl kaum.

Letztendlich tut es jedes Set. Man nimmt das, was man aus dem FF kennt.

von c-hater (Gast)


Lesenswert?

Chris D. schrieb:

> Die ganzen Gui-Designer, die ich mir angeschaut habe (durchaus nicht nur
> für Tk) helfen einfach nicht wirklich, weil man letztendlich doch jedes
> Widget mit entsprechenden Attributen usw. versehen muss und das dann in
> Klickorgien ausartet.

Ja klar muss man jedem Widget/Control sagen, wie es sich verhalten soll. 
Das tut aber jeder Normaldenkende doch lieber mit einer überschaubaren 
Zahl Mausklicks als mit einer Flut von Programmzeilen.

> Da kann man es auch direkt im Editor coden, da ist
> man deutlich schneller

Definitiv: NEIN. Nicht einmal näherungsweise.

> Letztendlich tut es jedes Set. Man nimmt das, was man aus dem FF kennt.

Klar, wenn man die Widgets/Controls kennt, ist das natürlich überaus 
hilfreich. Und zwar ganz unabhängig davon, ob man sie mittels Mausklicks 
oder mittels Quelltextzeilen parametriert.

von Karl Käfer (Gast)


Lesenswert?

Chris D. schrieb:
> Karl Käfer schrieb:
>> Das habe ich mir vor vielen Jahren einmal angesehen, ebenso wie einige
>> andere GUI-Designer, aber wirklich überzeugt hat mich keines davon. Das
>> Design und die Entwicklung von GUI-Software ist IMHO immer ein PITA, da
>> beißt die Maus keinen Faden ab und auch Softwaretools helfen allenfalls
>> dabei, diesen Schmerz ein wenig zu lindern. Auch das ist ein Grund warum
>> ich heute lieber Webapplikationen sogar dann entwickle, wenn sie am Ende
>> lokal auf einem Fatclient laufen sollen.
>
> Hehe, da ist was dran. Es ist auch weniger die Positionierung der
> Elemente als eine vernünftige Bedienbarkeit - ist gerade bei
> Maschinensteuerungen nicht einfach, je nachdem, wer später davorsteht
> (Profi, Facharbeiter, Angelernter usw.).

Natürlich, bitte versteh' mich nicht falsch: ich kenne die Vorzüge von 
guten Mensch-Maschine-Schnittstellen und will deren Notwendigkeit gerade 
für Menschen, die keine hauptberuflichen Computerbenutzer sind, niemals 
abstreiten. Und genau deswegen sind solche GUI-Designer auch IMHO sehr 
sinnvoll, gerade in der Kommunikation und Zusammenarbeit mit Menschen, 
die sich vornehmlich mit User Interface Design und Usability 
beschäftigen oder die aus der fachlichen Umfeld kommen. Die können mir 
nämlich mit so einem GUI-Designer gleich eine fertige Oberfläche liefern 
und ich muß die nur noch mit dem benötigten Code ergänzen. Das kommt 
meiner Eigenschaft als bekennender Faulpelz natürlich sehr entgegen.

> Die ganzen Gui-Designer, die ich mir angeschaut habe (durchaus nicht nur
> für Tk) helfen einfach nicht wirklich, weil man letztendlich doch jedes
> Widget mit entsprechenden Attributen usw. versehen muss und das dann in
> Klickorgien ausartet. Da kann man es auch direkt im Editor coden, da ist
> man deutlich schneller. Wenn man natürlich alle halbe Jahre mal einer
> Oberfläche baut, dann kann das interessant sein, weil man schlicht viele
> Optionen etc. vergisst.

Das ist (finde ich) einer der schönen Punkte an HTML: es gibt relativ 
wenige Elemente und um die Positionierung und Ausrichtung kann sich der 
Webbrowser kümmern, der das regelmäßig besser hinbekommt als viele der 
Layout-Manager, die wir von GUI-Toolkits und -Frameworks kennen. Und 
dank CSS habe ich damit auch recht große, flexible gestalterische 
Spielräume.

Erschwerend kommt in meinem Fall hinzu, daß ich ohnehin regelmäßig 
Sachen mit HTML mache, insofern ich das zu 99,9 % aus dem Kopf schreibe. 
Bei den GUI-Toolkits und -Frameworks dagegen muß ich ständig in die 
Dokumentation schauen, die ich dieses oder jenes Verhalten umsetzen 
kann.

Andererseits kann man mit GUI-Toolkits und -Frameworks viel einfacher 
eine Interaktivität in die GUI einbauen, das ist bei HTML "dank" 
ECMA-Skript ja manchmal auch kein reines Vergnügen.

> Ich handhabe das hier mit der Positionierung so, dass ich mir anfangs
> per Code alle nötigen Widgets erstelle und dann die Oberfläche starte.
> Ein Skript läuft den ganzen Widgetbaum dann ab und ergänzt die Widgets
> durch passende Bindings für Mausziehen + gehaltene Zusatztaste. Damit
> kann ich dann die Widgets einzeln dorthin schieben, wo ich sie haben
> möchte. Dann nochmal eine Tastenkombi und die Positionen werden als
> Tcl-Paket für den Placer geliefert. Dann nur noch reinkopieren und die
> Widgest sitzen schon mal dort, wo sie sein sollen.

Das hört sich spannend an und erspart einem natürlich viel von der bösen 
Boilerplate-Arbeit, die GUI-Entwicklung so nervig macht.

> Karl Käfer schrieb:
>> Den Absprung zu Themed-Tk habe ich leider irgendwie verpaßt, aber ich
>> habe schon einige sehr hübsch gestaltete Oberflächen damit gesehen.
>> Vielleicht sollte ich mir das doch noch einmal anschauen.
>
> Ist eine schöne Sache - aber wenn Du mit Deinen anderen Widgetsets
> zufrieden bist, dann lohnt das wohl kaum.

Naja, ehrlich gesagt baue ich mir GUI heute im Grunde nur noch, wenn ich 
große Datensätze fürs Supervised Learning labeln will. Dann hat das 
echte Vorteile: Datensatz laden und darstellen, ein Tastendruck, schon 
ist der Datensatz mit dem gewünschten Label versehen und die 
Veranstaltung fängt wieder von vorne an. Für sowas reicht dann auch 
Plain-Tkinter, aber wie gesagt, Themed-Tk schaue ich mir vielleicht doch 
nochmal an. Immerhin hat die Wissenschaft mittlerweile in mehreren 
Studien festgestellt, daß die Benutzer einer hübschen Software mehr 
vertrauen, und dann auch Störungen und Fehler weniger negativ 
wahrnehmen. Unter dem Gesichtspunkt wäre ttk also ein Dienst an den 
Leuten, die meine Datensätze labeln. :)

Außerdem hat Tkinter unter Python natürlich den gewaltigen Vorteil, daß 
es schon in der Standarddistribution integriert und darum überall 
vorhanden ist, wo Python installiert ist. Das vereinfacht das Deployment 
enorm.

Ach so, in den neueren Versionen (seit Python3, glaube ich) setzt 
Tkinter auch eher auf Tix, insofern sieht das mittlerweile schon 
deutlich besser als als unter Python 2.x. Aber ttk scheint ja nach 
allem, was ich in den letzten Stunden gesehen habe, ein überschaubarer 
Aufwand zu sein. Lieben Dank für Deinen Hinweis!

> Letztendlich tut es jedes Set. Man nimmt das, was man aus dem FF kennt.

Ja, keine Frage!

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

c-hater schrieb:
> Chris D. schrieb:
> Ja klar muss man jedem Widget/Control sagen, wie es sich verhalten soll.
> Das tut aber jeder Normaldenkende doch lieber mit einer überschaubaren
> Zahl Mausklicks als mit einer Flut von Programmzeilen.

Ich habe keine Ahnung, was Du benutzt, aber die "Flut von 
Programmzeilen" beschränkt sich bei Tk-Widgets auf praktisch immer nur 
eine, nicht allzu lange.

>> Da kann man es auch direkt im Editor coden, da ist
>> man deutlich schneller
>
> Definitiv: NEIN. Nicht einmal näherungsweise.

Hier definitv "Doch" - und ziemlich deutlich. Ich hab beides getestet 
und insbesondere, wenn man mit automatischer Code-Ergänzung (hat 
eigentlich jede IDE) arbeitet und sowieso Eingaben per Tastatur (Name, 
Bindings etc.) vornehmen muss. Der Wechsel zwischen Maus und Tastatur 
und scrollen durch Menüs ist einfach sehr zeitraubend.

Allerdings sollte man da sein Widget-Set auch wirklich gut kennen. Wenn 
man die entsprechenden Optionen erst nachschauen muss, dann ist ein 
GUI-Editor besser. Das ist ähnlich wie mit der Shell/Kommandozeile und 
Dateimanagern oder LibreOffice und LaTeX. Wer nur ab und zu etwas macht, 
nimmt GUIs, wer ständig damit arbeitet, nimmt das direkte Werkzeug.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

Karl Käfer schrieb:
 Das ist (finde ich) einer der schönen Punkte an HTML: es gibt relativ
> wenige Elemente und um die Positionierung und Ausrichtung kann sich der
> Webbrowser kümmern, der das regelmäßig besser hinbekommt als viele der
> Layout-Manager, die wir von GUI-Toolkits und -Frameworks kennen. Und
> dank CSS habe ich damit auch recht große, flexible gestalterische
> Spielräume.

Auf jeden Fall :-)

> Erschwerend kommt in meinem Fall hinzu, daß ich ohnehin regelmäßig
> Sachen mit HTML mache, insofern ich das zu 99,9 % aus dem Kopf schreibe.
> Bei den GUI-Toolkits und -Frameworks dagegen muß ich ständig in die
> Dokumentation schauen, die ich dieses oder jenes Verhalten umsetzen
> kann.

Exakt das meinte ich. Wenn ich etwas beherrsche, dann wäre es unsinnig, 
da etwas anderes (und sei es auch nur ein Hilfstool für GUIs) zu 
verwenden. Ich bin da einfach schneller, wenn ich es direkt so 
runterschreibe.

> Ach so, in den neueren Versionen (seit Python3, glaube ich) setzt
> Tkinter auch eher auf Tix, insofern sieht das mittlerweile schon
> deutlich besser als als unter Python 2.x. Aber ttk scheint ja nach
> allem, was ich in den letzten Stunden gesehen habe, ein überschaubarer
> Aufwand zu sein. Lieben Dank für Deinen Hinweis!

Gern :-)

von c-hater (Gast)


Lesenswert?

Chris D. schrieb:

> Ich habe keine Ahnung, was Du benutzt

Meist VS. Kenne auch vieles andere, aber der Komfort des VS 
(insbesondere für Windows.Forms) ist unerreicht.

> aber die "Flut von
> Programmzeilen" beschränkt sich bei Tk-Widgets auf praktisch immer nur
> eine, nicht allzu lange.

Dann können sie nicht sehr mächtig sein. Punkt.

Nehmen wir mal zwei Beispiele aus Windows.Forms, das DataGridView und 
das TableLayoutPanel. Durch was würdest du das in Tk ersetzen?

Ich sage dir dann, was der Tk-Kram alles NICHT kann...

von Adam P. (adamap)


Lesenswert?

Klaus S. schrieb:
> Ich bin deshalb auf der Suche nach einer Programmiersprache, die ähnlich
> komfortabel das Ansprechen des ComPorts erlaubt, aber weniger Fehler
> macht

Ich weiß nicht ob du direkt GUI support haben möchtest,
aber wenn du C nehmen würdest, könntest du das hier nutzen:

Läuft unter Windows und Linux.
https://www.teuniz.net/RS-232/

Die benötigten Funktionsaufrufe sind echt überschaubar.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.