Hi Folks, ich versuche mal mein Problem zu beschreiben. Früher in den 80gern hatte ich verschiedene Homecomputer, mit Basic als Programmierersprache. Da konnte ich mit Befehlen wie PSET und LINE Punkte und Linien auf den Bildschirm zeichnen. Man konnte auch mit PEEK und POKE direkt in den Bildschirm schreiben. Jetzt sind mindestens 35 Jahre vergangen und ich vermisse das, die Hard- und Software von damals existiert höchstens noch in meiner Erinnerung. Heute habe ich Linux Mint und den GCC Compiler. Ich programmiere kleine Progrämmchen in C, die irgendwas ausrechnen und das mit printf() anzeigen. Wie könnte ich Grafik, z.B. eine Sinusfunktion darstellen? Brauche mal echt Hilfe. Vielen Dank :-)
Zum Plotten würde ich die Ausgabe in eine Datei umleiten, und dann für einfache Fälle mit gnuplot, für komplexere Darstellung mit Python + matplotlib visualisieren. Klar muss man sich da kurz reinlesen, aber es erzeugt sehr schöne, auf Wunsch auch interaktiv zoombare Graphen mit wenigen (~10) Zeilen Code (inkl. Einlesen der Daten). Klar kann man auch in C oder C++ Graphen malen, aber der Aufwand lohnt sich meines Erachtens nur als Teil einer größeren Desktop-Anwendung.
:
Bearbeitet durch User
Ach, da ist mir noch eingefallen, in den 90gern hatte ich QBasic, damit habe ich viel gemacht. Unter SCREEN 12 ging 640x480 in 16 Farben. Seufz...
Sven B. schrieb: > Zum Plotten würde ich die Ausgabe in eine Datei umleiten, und dann > für einfache Fälle mit gnuplot, für komplexere Darstellung mit Python + > matplotlib visualisieren. Klar muss man sich da kurz reinlesen, aber es > erzeugt sehr schöne, auf Wunsch auch interaktiv zoombare Graphen mit > wenigen (~10) Zeilen Code (inkl. Einlesen der Daten). > Wenn ich denn Workflow richtig verstehe, müsste ich da mein C Programm starten, ein paar Parameter eingeben, das Programm schreibt sowas wie HPGL in eine Datei, die ich mit Gnuplot anzeigen lassen. Hübsch, aber ich wollte wirklich wie bei einem ZX81 Grafik in Echtzeit.
Ok. Mit den C-Grafikframeworks kenne ich mich jetzt nicht so aus. Ich persönlich würde sowas wie QCustomPlot oder Qwt benutzen, was relativ stark abstrahierte Plotting-Frameworks auf Basis von Qt/C++ sind. Vielleicht passt dir aber sowas wie SDL besser, das ist sehr einfach. Hier werden z.B. mit SDL ein paar Linien gemalt: https://wiki.libsdl.org/SDL_RenderDrawLine Kompilieren lässt sich das bei mir auch recht simpel mit gcc -o test test.c -lSDL2 -I/usr/include/SDL2
Was immer du tust nimm nicht die Xlib, da ist sich jeder seit 15 Jahren einig, dass das nicht der Weg ist wie man Kram zeichnet.
Direkt auf der Linux Textkonsole geht es nicht so gut, man müsste auf framebuffer umschalten (oder geht da etwa sixel-Grafik?). Heutzutage hat man eine grafische Oberfläche auf der man ein Fenster mit Kommandozeile starten kann auf der man mit
1 | xterm -t |
ein Tektronix-Grafikterminal tek4014 emulieren kann. Das kann man zwar nicht mit poke() ansprechen, aber mit Escape-Sequenzen. Ich glaube, die echten tek4014 aus Hardware konnten damals 4096x4096 Pixel, heute muss man nehmen, was der Monitor halt hergibt :)
Nimm sowas wie Colour Maximite 2 und ähnliche Projekte. Die funktionieren im Grund noch so wie in den 80er Jahren. So ein Verhalten unter Linux, Windows, MacOS, BSD und was auch immer heutzutage hinzubekommen ist im Grunde nur als VM oder Emulation möglich.
Vielleicht ist Lua Quick Try Out was für dich: http://www.aaabbb.de/Lua-Quick-Try-Out/Lua-Quick-Try-Out.php
Schau Dir mal GLE an: >http://www.gle-graphics.org/ Beispiele hier: >http://www.gle-graphics.org/examples/index.html Fand ich komfortabler als gnuplot. Laesst sich scripten und produziert vectoroutput. j
Zappenduster schrieb: > Hi Folks, ich versuche mal mein Problem zu beschreiben. > Früher in den 80gern hatte ich verschiedene Homecomputer, > mit Basic als Programmierersprache. Da konnte ich mit > Befehlen wie PSET und LINE Punkte und Linien auf den > Bildschirm zeichnen. Man konnte auch mit PEEK und POKE > direkt in den Bildschirm schreiben. Jetzt sind mindestens > 35 Jahre vergangen und ich vermisse das, die Hard- und > Software von damals existiert höchstens noch in meiner > Erinnerung. Ich glaube, ich kenne die Situation. Um das Jahr 2000 herum war ich auf der Suche nach einer Programmiersprache, die folgende drei Kriterien erfüllt: - es sollte eine Interpretersprache ("Scriptsprache") sein, - sie sollte reguläre Ausdrücke kennen, - sie sollte einfache Graphik ermöglichen. > Heute habe ich Linux Mint und den GCC Compiler. Ich > programmiere kleine Progrämmchen in C, die irgendwas > ausrechnen und das mit printf() anzeigen. > Wie könnte ich Grafik, z.B. eine Sinusfunktion darstellen? Indem Du kein C verwendest. Ich bin damals nach einigem Suchen und Probieren bei Tcl/Tk gelandet. Wenn Du schon C kannst, wird Dir Tcl sehr leicht fallen; anders ist nur, dass es - keine Datentypen, - keine Pointer und - keine Arrays gibt, dafür kann man hemmungslos mit Strings, Listen und assoziativen Arrays herumhantieren. Tk ist hübsch, weil man damit - mausbedienbare ereignisgesteuerte GUIs bauen kann, - Graphik-Canvases anlegen und auf denen nach Herzenslust zeichnen kann, - den ganzen Graphik-Output mit einem Befehl als PostScript abspeichern kann, z.B. um es auszudrucken. Fairerweise muss ich sagen, dass Tk wichtiger ist als Tcl; es gibt nämlich auch perl/Tk, python/Tk und ruby/Tk. Eigene Erfahrungen habe ich damit aber nicht. > Brauche mal echt Hilfe. Vielen Dank :-) HTH
Zappenduster schrieb: > Homecomputer mit Basic als Programmierersprache > konnte ich mit Befehlen wie PSET und LINE Ein Pi mit RISC OS? https://de.wikipedia.org/wiki/BBC_BASIC > PEEK und POKE https://www.riscosopen.org/wiki/documentation/show/*Memory https://www.riscosopen.org/wiki/documentation/show/*MemoryA > Linux Mint und den GCC Compiler GCC gibt es auch für RISC OS. Grafik funktioniert in C genauso wie in BASIC https://www.riscos.info/index.php/GCC_for_RISC_OS
> Ich programmiere kleine Progrämmchen in C, die > irgendwas ausrechnen und das mit printf() anzeigen. Die einfachste Moeglichkeit das zu schaffen duerfte in der Tat das direkte ansprechen von xlib sein. Allerdings ist das auch so kacke das du das nicht wirklich willst. Die zweiteinfachste Loesung ist dann xforms. Das ist ebenfalls noch ziemlich schlicht, aber damit solltest du nach 1-2h deinen ersten pixel blinken sehen. Alles was darueber hinaus geht wird dann deutlich komplexer. Olaf
Zappenduster schrieb: > Man konnte auch mit PEEK und POKE direkt in den Bildschirm schreiben. Um dem aus technologischer Sicht in einer Linux-Anwendung am Nächsten zu kommen müsste man Vulkan nutzen, was es erlaubt mehr oder weniger direkt in den Grafikspeicher zu schreiben. Das ist allerdings ziemlich aufwendig und komplex. Noch näher wäre wohl nur an den Grafiktreibern rumzuhacken. Realistisch wäre z.B. Gtk+ und das GtkDrawingArea widget in welches man mittels Cairo diverse Grafikelemente zeichnen kann, oder eines der vielen anderen Toolkits wie Qt.
Wie wäre es mit Processing als Sprache/Anzeigeframework. Bietet zahlreiche gute Grafik-primitive wie einzelne Pixel setzen oder Linien Zeichen. Die Sprache ist C extrem ähnlich und kann man ohne umgewöhnung nutzen. Processing ist genau für solche Anforderungen entwickelt worden und ist um Größenordnungen einfacher als wenn man ein großen Grafik-Framework mit C bespielen möchte.
Zappenduster schrieb: > Da konnte ich mit Befehlen wie PSET und LINE Punkte und Linien auf den > Bildschirm zeichnen. Wenn du mit so wenig zufrieden bist, kannst du dir mal das da anschauen: https://www3.nd.edu/~dthain/courses/cse20211/fall2013/gfx/ Das ist sehr primitiv, dafür aber auch sehr einfach in der Anwendung. > Wie könnte ich Grafik, z.B. eine Sinusfunktion darstellen? Wenn es dir mehr um die Darstellung von Funktionsgraphen geht (mit Koordinatenachsen und -beschriftung, Legende usw.), würde ich – wie schon von anderen vorgeschlagen – Matplotlib (mit Python) oder Gnuplot nehmen. Gnuplot kann stand-alone (mit seiner eigenen Skriptsprache) verwendet werden, du kannst die Befehle und Daten aber auch von einem C-Programm hinüberpipen (bspw. mit popen). Eine Zwischendatei brauchst du nicht unbedingt.
Zappenduster schrieb: > Hi Folks, ich versuche mal mein Problem zu beschreiben. Früher in den > 80gern hatte ich verschiedene Homecomputer, mit Basic als > Programmierersprache. Da konnte ich mit Befehlen wie PSET und LINE > Punkte und Linien auf den Bildschirm zeichnen. Man konnte auch mit PEEK > und POKE direkt in den Bildschirm schreiben. Jetzt sind mindestens 35 > Jahre vergangen und ich vermisse das, die Hard- und Software von damals > existiert höchstens noch in meiner Erinnerung. Heute habe ich Linux Mint > und den GCC Compiler. Ich programmiere kleine Progrämmchen in C, die > irgendwas ausrechnen und das mit printf() anzeigen. > Wie könnte ich Grafik, z.B. eine Sinusfunktion darstellen? > Brauche mal echt Hilfe. Vielen Dank :-) Ok, hier ein einfaches Beispiel wie du einen Sinus unter Windows ausgeben kannst: https://github.com/yottaawesome/programming-windows-5th-edition/blob/master/src/Chap05/SineWave/SineWave.c Der Sinus wird mit der Funktion Polyline() in Zeile 84 in den Framebuffer geschrieben. Die x und y Werte werden in der for Schleife berechnet, und in das Punkte-Feld apt[] geschrieben.
1 | for (i = 0 ; i < NUM ; i++) |
2 | {
|
3 | apt[i].x = i * cxClient / NUM ; |
4 | apt[i].y = (int) (cyClient / 2 * (1 - sin(TWOPI * i / NUM))) ; |
5 | }
|
6 | |
7 | Polyline (hdc, apt, NUM) ; |
Das kannst du auch mit dem Mingw gcc kompilieren, oder mit dem beiliegenden VS2019 Project File unter Windows, oder einfach auf der Kommandozeile mit: cl.exe -O SineWave.c gdi32.lib user32.lib Das läuft auch problemlos im Windows Subsystem für Linux oder auf Linux mit dem Windows Emulator Wine. In dem Github Verzeichnis findest du auch viele andere einfache Beispiele, für Menüs, Rechtecke, Textausgabe und Mausinteraktion.
Schon mal gnuplot probiert? http://openbook.rheinwerk-verlag.de/shell_programmierung/shell_007_008.htm
Udo K. schrieb: > Das läuft auch problemlos im Windows Subsystem für Linux > oder auf Linux mit dem Windows Emulator Wine. Naja, also man kann unter Linux auch Linien malen, ohne die plattformabhängige Windows-API zu benutzen, dann zu cross-compilen und das Ergebnis mit Wine auszuführen. Danke für deine Mühe den Beitrag zu schreiben, aber sorry, das ist echt mal wieder eine krasse Frankenstein-Lösung.
Udo K. schrieb: > > Ok, hier ein einfaches Beispiel wie du einen Sinus unter Windows > ausgeben kannst: Buuh,Buuuuuh!!!! :-)
1 | |
2 | |
3 | #!/bin/bash
|
4 | # plotsine.sh
|
5 | # A DEMO to display a sinewave inside a standard bash terminal.
|
6 | # Issued as Public Domain, 2014, B.Walker, G0LCU.
|
7 | # Device: Macbook Pro 13", OSX 10.7.5, default bash terminal.
|
8 | # Use variables so that you can see how it works.
|
9 | angle=0 |
10 | step_angle=5 |
11 | vert_plot=0 |
12 | horiz_plot=5 |
13 | centreline=12 |
14 | amplitude=11 |
15 | PI=3.14159 |
16 | clear |
17 | # Do a single cycle, quantised graph.
|
18 | while [ $angle -le 359 ] |
19 | do
|
20 | # Create each floating point value...
|
21 | # CygWin now catered for... ;o)
|
22 | vert_plot=$(awk "BEGIN{ printf \"%.12f\", ((sin($angle*($PI/180))*$amplitude)+$centreline)}") |
23 | #vert_plot=$(bc -l <<< "{print ((s($angle*($PI/180))*$amplitude)+$centreline)}")
|
24 | # Truncate the floating point value to an integer then invert the plot to suit the x y co-ordinates inside a terminal...
|
25 | vert_plot=$((24-${vert_plot/.*})) |
26 | # Plot the point(s) and print the angle at that point...
|
27 | printf "\x1B["$vert_plot";"$horiz_plot"f*" |
28 | printf "\x1B[22;1fAngle is $angle degrees..." |
29 | sleep 0.1
|
30 | # Increment values...
|
31 | angle=$((angle+step_angle)) |
32 | horiz_plot=$((horiz_plot+1)) |
33 | done
|
34 | printf "\x1B[23;1fSinewave plotted as a quantised text mode graph.\n" |
35 | exit 0
|
Sven B. schrieb: > Naja, also man kann unter Linux auch Linien malen, ohne die > plattformabhängige Windows-API zu benutzen, dann zu cross-compilen und > das Ergebnis mit Wine auszuführen. Ja sicher - davon gehe ich aus, aber wie macht man es jetzt unter Linux? Die Windows Lösung ist für einen Menschen, der mit C in den 90'ern grossgeworden ist, einfach zu verstehen, und lässt sich leicht mit Menüs, Dialogen oder Mauseingabe erweitern. Und der Code ist effizient und knackig, so wie wir es hier gerne haben. Das Programm ist unter 3 kByte unter Windows. Die Performance dürfte selbst unter Linux x-mal schneller sein, als ein Bash Skript, oder gnuplot, die ja nicht mal interaktiv sind. Wäre doch was, wenn die Linux Nerds wenigstens die Basics vom Windows Gui Api endlich mal "native" portieren würden, so dass das Wine Geraffel unnötig wird. Ich glaube, die GDI+ Bibliothek läuft ja schon unter Mono/Cairo? Dann hätte Linux endlich eine passable Gui Bibliothek :-)
Seit HTML5 und Canvas mach ich solche kleinen Programmchen immer in JavaScript.
SVGAlib https://en.wikipedia.org/wiki/SVGALib Wobei ich aus Altersgründen heutzutage eher zu python rate: https://gertingold.github.io/pythonnawi/graphics.html
back from the future schrieb: Just kidding aber forumsfreundlich ist das schon :) > ...
1 | p450:$ ./sine.sh |
2 | |
3 | |
4 | |
5 | |
6 | ********* |
7 | *** *** |
8 | * * |
9 | ** ** |
10 | * * |
11 | * * |
12 | * * |
13 | * * |
14 | * * |
15 | * * |
16 | ** ** |
17 | * * |
18 | * * |
19 | * * |
20 | * * |
21 | * * |
22 | * * |
23 | * * |
24 | ** ** |
25 | * * |
26 | Angle is 355 degrees... *** *** |
27 | Sinewave plotted as a quantised text mode graph. ********* |
28 | box://mnt/disk2/vid-tmp |
--- Ernsthaft das tk toolkit ist immer noch gut. Mit welcher Sprache auch immer incl. C
Udo K. schrieb: > Ok, hier ein einfaches Beispiel wie du einen Sinus unter Windows > ausgeben kannst: Hier ein simples Beispiel mit dem Gtk+, welches direkt unter Linux und Windows geht. Zeigt statt des Sinus einen Kreis. Udo K. schrieb: > Die Windows Lösung ist für einen Menschen, der mit C in den 90'ern > grossgeworden ist, einfach zu verstehen, und lässt sich leicht > mit Menüs, Dialogen oder Mauseingabe erweitern. Dito. Der Code ist aber nur halb so lang wie der Win32-Api-Code. Udo K. schrieb: > Wäre doch was, wenn die Linux Nerds wenigstens die Basics vom Windows > Gui Api endlich mal "native" portieren würden, > so dass das Wine Geraffel unnötig wird. Hä, genau das ist doch Wine. Was will man mehr? Das direkt in den Kernel zu integrieren? Das wird wohl nie passieren. Wie wäre es damit, wenn Windows mal statt der kruden selbstgebastelten APIs die standardisierten POSIX-APIs unterstützten würde, genau wie Linux? Mit WSL haben sie das ja quasi bei Linux geklaut. Und das POSIX Subsystem für Windows ist ja auch keine Alternative.
Programmierer schrieb: > Wie wäre es damit, wenn Windows mal statt der kruden > selbstgebastelten APIs die standardisierten POSIX-APIs > unterstützten würde, genau wie Linux? Naja, POSIX ist jetzt aber nicht gerade grafikfähig, und wenn du dich mal bei den BSDs (oder Projekten wie Busybox/Toybox) umhörst, dann nutzen die meisten Linux-Anwendungen eben nicht POSIX-APIs, sondern verschiedene GNU- und Linux-Extensions.
Udo K. schrieb: > Sven B. schrieb: >> Naja, also man kann unter Linux auch Linien malen, ohne die >> plattformabhängige Windows-API zu benutzen, dann zu cross-compilen und >> das Ergebnis mit Wine auszuführen. > > Ja sicher - davon gehe ich aus, aber wie macht man es jetzt unter Linux? Auf dem niedrigsten Abstraktionsniveau unter X11 (mit der libX11) sieht das so aus wie im Anhang.
Programmierer schrieb: > Udo K. schrieb: >> Ok, hier ein einfaches Beispiel wie du einen Sinus unter Windows >> ausgeben kannst: > > Hier ein simples Beispiel mit dem Gtk+, welches direkt unter Linux und > Windows geht. Zeigt statt des Sinus einen Kreis. Danke! Ich sehe jetzt einen schwarzen Kreis, noch keinen Sinus. Hat mich aber 2 Stunden gekostet, das unter Windows (Cygwin) zum laufen zu bringen (Schweissausbruch wenn ich dran denke, pkg-config ist ein Arschtool) > Dito. Der Code ist aber nur halb so lang wie der Win32-Api-Code. Dafür ist das Program 30x so gross, ohne die Libs, die man noch irgendwo installieren muss, und die noch mal ein paar GB sind. OK, Windows muss man auch erst installieren. Es schaut auch irgendiwie ungewohnt aus (eher auf der hässlichen Seite). Aber ok, mein Fehler, das unter Windows zum laufen bringen zu wollen. Hier nur mal die Liste der benötigten Windows und Linux Libs: ADVAPI32.dll => /cygdrive/c/Windows/System32/ADVAPI32.dll (0x7fffbba00000) COMCTL32.dll => /cygdrive/c/Windows/WinSxS/amd64_microsoft.windows.common-controls_6595b 64144ccf1df_6.0.18362.900_none_e6beb9d913147d17/COMCTL32.dll (0x7fff91cb0000) DNSAPI.dll => /cygdrive/c/Windows/SYSTEM32/DNSAPI.dll (0x7fffb83c0000) GDI32.dll => /cygdrive/c/Windows/System32/GDI32.dll (0x7fffbb9d0000) IMM32.dll => /cygdrive/c/Windows/System32/IMM32.dll (0x7fffbb1c0000) IPHLPAPI.DLL => /cygdrive/c/Windows/SYSTEM32/IPHLPAPI.DLL (0x7fffb8380000) KERNEL32.DLL => /cygdrive/c/Windows/System32/KERNEL32.DLL (0x7fffbbce0000) KERNELBASE.dll => /cygdrive/c/Windows/System32/KERNELBASE.dll (0x7fffb9290000) MSIMG32.dll => /cygdrive/c/Windows/SYSTEM32/MSIMG32.dll (0x7fffb5a30000) NSI.dll => /cygdrive/c/Windows/System32/NSI.dll (0x7fffbb400000) OLEAUT32.dll => /cygdrive/c/Windows/System32/OLEAUT32.dll (0x7fffbb7c0000) PROPSYS.dll => /cygdrive/c/Windows/SYSTEM32/PROPSYS.dll (0x7fffb56b0000) RPCRT4.dll => /cygdrive/c/Windows/System32/RPCRT4.dll (0x7fffbab90000) SETUPAPI.dll => /cygdrive/c/Windows/System32/SETUPAPI.dll (0x7fffba030000) SHELL32.dll => /cygdrive/c/Windows/System32/SHELL32.dll (0x7fffba4a0000) SHLWAPI.dll => /cygdrive/c/Windows/System32/SHLWAPI.dll (0x7fffbb1f0000) UMPDC.dll => /cygdrive/c/Windows/System32/UMPDC.dll (0x7fffb8e40000) USER32.dll => /cygdrive/c/Windows/System32/USER32.dll (0x7fffbbda0000) USP10.dll => /cygdrive/c/Windows/SYSTEM32/USP10.dll (0x7fffb3cd0000) WINMM.dll => /cygdrive/c/Windows/SYSTEM32/WINMM.dll (0x7fff9c8f0000) WINSPOOL.DRV => /cygdrive/c/Windows/SYSTEM32/WINSPOOL.DRV (0x7fff8a660000) WS2_32.dll => /cygdrive/c/Windows/System32/WS2_32.dll (0x7fffbb750000) bcrypt.dll => /cygdrive/c/Windows/System32/bcrypt.dll (0x7fffb9fe0000) bcryptPrimitives.dll => /cygdrive/c/Windows/System32/bcryptPrimitives.dll (0x7fffb9f10000) cfgmgr32.dll => /cygdrive/c/Windows/System32/cfgmgr32.dll (0x7fffb9f90000) combase.dll => /cygdrive/c/Windows/System32/combase.dll (0x7fffbadd0000) combase.dll => /cygdrive/c/Windows/System32/combase.dll (0xe20000) comdlg32.dll => /cygdrive/c/Windows/System32/comdlg32.dll (0x7fffbb2b0000) cryptsp.dll => /cygdrive/c/Windows/System32/cryptsp.dll (0x7fffba010000) dwmapi.dll => /cygdrive/c/Windows/SYSTEM32/dwmapi.dll (0x7fffb7560000) gdi32full.dll => /cygdrive/c/Windows/System32/gdi32full.dll (0x7fffb8f40000) iconv.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/iconv.dll (0x63940000) kernel.appcore.dll => /cygdrive/c/Windows/System32/kernel.appcore.dll (0x7fffb8ec0000) libatk-1.0-0.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libatk-1.0-0.dll (0x62940000) libbz2-1.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libbz2-1.dll (0x626c0000) libcairo-2.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libcairo-2.dll (0x68dc0000) libcairo-gobject-2.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libcairo-gobject-2.dll (0x6cf40000) libepoxy-0.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libepoxy-0.dll (0x6df00000) libexpat-1.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libexpat-1.dll (0x68f40000) libffi-6.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libffi-6.dll (0x6b740000) libfontconfig-1.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libfontconfig-1.dll (0x64f80000) libfreetype-6.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libfreetype-6.dll (0x150000) libfreetype-6.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libfreetype-6.dll (0x150000) libfreetype-6.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libfreetype-6.dll (0x150000) libfreetype-6.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libfreetype-6.dll (0x150000) libfreetype-6.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libfreetype-6.dll (0x150000) libgcc_s_seh-1.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgcc_s_seh-1.dll (0x61440000) libgdk-3-0.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgdk-3-0.dll (0x70ec0000) libgdk_pixbuf-2.0-0.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgdk_pixbuf-2.0-0.dll (0x65340000) libgio-2.0-0.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgio-2.0-0.dll (0x6d580000) libglib-2.0-0.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libglib-2.0-0.dll (0x685c0000) libgmodule-2.0-0.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgmodule-2.0-0.dll (0x6dd00000) libgobject-2.0-0.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgobject-2.0-0.dll (0x63a40000) libgtk-3-0.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgtk-3-0.dll (0x66400000) libharfbuzz-0.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libharfbuzz-0.dll (0x61600000) libintl-8.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libintl-8.dll (0x61cc0000) libpango-1.0-0.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpango-1.0-0.dll (0x65580000) libpangocairo-1.0-0.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpangocairo-1.0-0.dll (0x6d4c0000) libpangoft2-1.0-0.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpangoft2-1.0-0.dll (0x6d700000) libpangowin32-1.0-0.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpangowin32-1.0-0.dll (0x6b280000) libpcre-1.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpcre-1.dll (0x69140000) libpixman-1-0.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpixman-1-0.dll (0x610000) libpng16-16.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpng16-16.dll (0x68b40000) libwinpthread-1.dll => /cygdrive/c/Microsemi/SoftConsole_v6.2/arm-none-eabi-gcc/bin/libwinpthre ad-1.dll (0x64940000) msvcp_win.dll => /cygdrive/c/Windows/System32/msvcp_win.dll (0x7fffb90e0000) msvcrt.dll => /cygdrive/c/Windows/System32/msvcrt.dll (0x7fffbacb0000) ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7fffbbf80000) ole32.dll => /cygdrive/c/Windows/System32/ole32.dll (0x7fffbbab0000) powrprof.dll => /cygdrive/c/Windows/System32/powrprof.dll (0x7fffb8e50000) profapi.dll => /cygdrive/c/Windows/System32/profapi.dll (0x7fffb8ee0000) sechost.dll => /cygdrive/c/Windows/System32/sechost.dll (0x7fffbb120000) shcore.dll => /cygdrive/c/Windows/System32/shcore.dll (0x7fffbb6a0000) ucrtbase.dll => /cygdrive/c/Windows/System32/ucrtbase.dll (0x7fffb9540000) win32u.dll => /cygdrive/c/Windows/System32/win32u.dll (0x7fffb8f10000) windows.storage.dll => /cygdrive/c/Windows/System32/windows.storage.dll (0x7fffb9640000) winmmbase.dll => /cygdrive/c/Windows/SYSTEM32/winmmbase.dll (0x7fffa8820000) winmmbase.dll => /cygdrive/c/Windows/System32/winmmbase.dll (0x180000) zlib1.dll => /cygdrive/c/Program Files (x86)/Matlab/R2007b/bin/win32/zlib1.dll (0x78620000) zlib1.dll => /cygdrive/c/Program Files (x86)/Matlab/R2007b/bin/win32/zlib1.dll (0x78620000) zlib1.dll => /usr/x86_64-w64-mingw32/sys-root/mingw/bin/zlib1.dll (0x62e80000) Hoffentlich stimmen da auch alle Versionen der Libs. Ein echtes Wunder das sowas noch läuft, und dass wir mit solcher Technik zum Mond fliegen wollen. Aber ich will nicht lästern. Es tut, was es soll. Bis auf den Sinus, der ein schwarzer Kreis ist. > Udo K. schrieb: >> Wäre doch was, wenn die Linux Nerds wenigstens die Basics vom Windows >> Gui Api endlich mal "native" portieren würden, >> so dass das Wine Geraffel unnötig wird. > > Hä, genau das ist doch Wine. Was will man mehr? Die meinsten kleinen Programme brauchen keine binäre 100% Windows Emulation, genauso, wie die meisten Linux Programme kein Cygwin bräuchten. Eine kleine feine GUI Bibliothek, und eine Standard-C Lib reicht meist aus. Zumindest, wenn der Entwickler das Programm neu übersetzt, und beim Entwickeln dran denkt (Wunschdenken). Wahrschinelich könnte man sich die relevanten 5-6 Libs irgendwie aus den Wine Sourcen rausziehen, man müsste halt die Abhängigkeiten kappen. Das direkt in den > Kernel zu integrieren? Das wird wohl nie passieren. In den Kernel muss da doch nichts integriert werden. Das sind User Libs, die auf Cairo/Pango was auch immer zugreifen. Ähnlich wie es Mono macht, nur halt für die Win32 GUI Libs.
Udo K. schrieb: > Ja sicher - davon gehe ich aus, aber wie macht man es jetzt unter Linux? Wie ich schon in Beitrag 3 oder so schrieb, zum Beispiel mit SDL, wenn man schlanker sein möchte als Qt und Konsorten. Ansonsten: Qt und Konsorten.
Udo K. schrieb: > Dafür ist das Program 30x so gross, ohne die Libs, die man noch > irgendwo installieren muss, und die noch mal ein paar GB sind. > OK, Windows muss man auch erst installieren. Genau. Außerdem hat das genau nichts mit dem Thema zu tun. Was bringt diese sinnlose Diskussion also? Ja: Windows und Linux haben unterschiedliche Konzepte, was Teil des Betriebssystems ist. Ja: das hat Konsequenzen dafür, was eine Userspace-Anwendung mitshippen muss. Ja: beide Konzepte haben Vor- und Nachteile. Und ja: das wird schon seit 30 Jahren rauf und runter diskutiert. Können wir das also bitte einfach nicht nochmal tun? Sorry, aber deine Beiträge zum Thread sind nur sinnloser Noise, der irgendwelche halbgaren Lösungen präsentiert die kein vernünftiger Mensch so jemals nutzen würde.
:
Bearbeitet durch User
Hi Folks, ich bin zurück. Ich bin ja ganz erstaunt, wie viele Antworten ich bekommen habe. Manche ganz ausführlich, andere fast schon einsilbig. Welches ist denn nun die richtige Antwort? Am liebsten hätte ich eine C Funktion, ich starte sie einmal an, sie bringt den Computer in den Grafikmode, sagen wir mal Full HD mit 24 Bit Farbauflösung. Rückgabewert dieser Funktion ist die Adresse des Bildschirmspeichers, in den ich dann in eigener Verantwortung schreiben darf. Der Speicher ist 1920 x 1080 x 3 Byte gross, das sind knapp 6 MByte. Ich würde mir dann elementare Funktionen für PSET, LINE etc. schreiben. Natürlich muss ich darauf achten, auf keinen Fall außerhalb des erlaubten Speichers zu schreiben, sonst ist alles zappenduster!!!
Yalu X. schrieb: > Udo K. schrieb: >> Sven B. schrieb: >>> Naja, also man kann unter Linux auch Linien malen, ohne die >>> plattformabhängige Windows-API zu benutzen, dann zu cross-compilen und >>> das Ergebnis mit Wine auszuführen. >> >> Ja sicher - davon gehe ich aus, aber wie macht man es jetzt unter Linux? > > Auf dem niedrigsten Abstraktionsniveau unter X11 (mit der libX11) sieht > das so aus wie im Anhang. Danke Yalu! Läuft auch unter Cygwin / Windows, und zeichnet einen sehr schönen Sinus :-) Leider habe ich es nicht geschafft, das mit Mingw "native" zu übersetzen. Das dürfte aber daran liegen, dass ich den Cygwin X11 Server verwende, nehme ich jedenfalls an. Das schaut vom Ergebnis sehr ähnlich wie der Windows Code aus (Die Fensterrahmen werden vom X-Server dazugemacht). Der Sourcecode ist praktisch 1:1 wie die Windows Version, wenn man davon absieht, dass die Funktionsnahmen anders heissen. Sehr interessant, wie ähnlich Windows und Linux unter Haube funktionieren. Die Abhängigkeiten sind auch erträglich: ldd ./sine_x11.exe ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7fffbbf80000) KERNEL32.DLL => /cygdrive/c/Windows/System32/KERNEL32.DLL (0x7fffbbce0000) KERNELBASE.dll => /cygdrive/c/Windows/System32/KERNELBASE.dll (0x7fffb9290000 ) cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000) cygX11-6.dll => /usr/bin/cygX11-6.dll (0x3f8a50000) cygxcb-1.dll => /usr/bin/cygxcb-1.dll (0x3e1250000) cygXau-6.dll => /usr/bin/cygXau-6.dll (0x3f8a20000) cygXdmcp-6.dll => /usr/bin/cygXdmcp-6.dll (0x3f8900000) Das Progarm hat auch sehr annehmbare 9 kByte. Schön, dass auch unter Linux nicht alles hoffnungslose Bloatware ist.
Zappenduster schrieb: > Hi Folks, ich bin zurück. Ich bin ja ganz erstaunt, wie viele > Antworten > ich bekommen habe. Manche ganz ausführlich, andere fast schon einsilbig. > Welches ist denn nun die richtige Antwort? > Am liebsten hätte ich eine C Funktion, ich starte sie einmal an, sie > bringt den Computer in den Grafikmode, sagen wir mal Full HD mit 24 Bit > Farbauflösung. Rückgabewert dieser Funktion ist die Adresse des > Bildschirmspeichers, in den ich dann in eigener Verantwortung schreiben > darf. Der Speicher ist 1920 x 1080 x 3 Byte gross, das sind knapp 6 > MByte. Ich würde mir dann elementare Funktionen für PSET, LINE etc. > schreiben. Natürlich muss ich darauf achten, auf keinen Fall außerhalb > des erlaubten Speichers zu schreiben, sonst ist alles zappenduster!!! Na ja, wir haben hier schon drei brauchbare Sinus Programme geschrieben... Suche dir eines aus :-)
Sven B. schrieb: > Udo K. schrieb: >> Dafür ist das Program 30x so gross, ohne die Libs, die man noch >> irgendwo installieren muss, und die noch mal ein paar GB sind. >> OK, Windows muss man auch erst installieren. > > Genau. Außerdem hat das genau nichts mit dem Thema zu tun. Was bringt > diese sinnlose Diskussion also? Ja: Windows und Linux haben > unterschiedliche Konzepte, was Teil des Betriebssystems ist. Ja: das hat > Konsequenzen dafür, was eine Userspace-Anwendung mitshippen muss. Ja: > beide Konzepte haben Vor- und Nachteile. Und ja: das wird schon seit 30 > Jahren rauf und runter diskutiert. Können wir das also bitte einfach > nicht nochmal tun? Sorry, aber deine Beiträge zum Thread sind nur > sinnloser Noise, der irgendwelche halbgaren Lösungen präsentiert die > kein vernünftiger Mensch so jemals nutzen würde. Komisch nur, das von mir ein funktionierendes Program kommt, und von dir nix.
@Zappenduster Das sollte/darf kein Betriebssystem zulassen. Dafür gibt es Treiber und Libs. Auf einem AppleII, C64 und Co. mit Singleuser Singletask geht das, aber nicht unter Windows und UNIX/Linux.
Zappenduster schrieb: > Am liebsten hätte ich eine C Funktion, ich starte sie einmal an, sie > bringt den Computer in den Grafikmode, sagen wir mal Full HD mit 24 Bit > Farbauflösung. Rückgabewert dieser Funktion ist die Adresse des > Bildschirmspeichers, in den ich dann in eigener Verantwortung schreiben > darf. Der Speicher ist 1920 x 1080 x 3 Byte gross, das sind knapp 6 > MByte. Ich würde mir dann elementare Funktionen für PSET, LINE etc. > schreiben. Natürlich muss ich darauf achten, auf keinen Fall außerhalb > des erlaubten Speichers zu schreiben, sonst ist alles zappenduster!!! Wenn du das so machen willst, dann kannst du unter Windows in ein Bitmap reinschreiben. Das Bitmap liegt im Speicher, und du hast einen Zeiger auf das erste Byte. Du kast darin nach Lust und Laune wüten. Wenn du fertig bist, mappst du das Bitmap auf dein offenes Fenster. Du kannst auch festlegen, dass dein Fenster der ganze Bildschirm ist. Im Petzold steht, wie das genau geht, oder du nimmst die Standard Funktionen zum Zeichnen von Linien etc. Das gibt es ja schon alles fertig. Hier ein Tutorial dazu (ich habe es aber nicht selber durchgearbeitet): https://www.codeproject.com/Articles/356/Bitmap-Basics-A-GDI-tutorial
Udo K. schrieb: > Komisch nur, das von mir ein funktionierendes Program kommt, > und von dir nix. Dein Programm war Unfug. Weil der Thread-Titel "Grafik unter Linux" ist und du die Windows-API benutzt hast. Ich habe auf das SDL-Wiki gelinkt, wo ein funktionierendes, sinnvolles Programm steht. In Post 3. Egal. Zum Thema -- das mit der Adresse des Bildschirmspeichers wird so nix -- der ist heutzutage nichtmal mehr addressierbar, der steht nämlich im Grafikspeicher ;) Außerdem verwaltet das Betriebssystem die Ressourcen und lässt kein Usermode-Programm da direkt dran rumpfuschen. Mit irgendeiner der genannten Lösungen wirst du dich also wohl oder übel auseinandersetzen müssen.
Udo K. schrieb: > unter Windows Kannst du bitte mal den Titel des Threads lesen? Da steht "unter Linux"!
Und du solltest dich auf Version 0.01 updaten. Die Zeiten, wo Linux Programme nicht unter Windows, oder Windows Programme nicht unter Linux laufen, sind zum Glück vorbei.
Udo K. schrieb: > Und du solltest dich auf Version 0.01 updaten. > > Die Zeiten, wo Linux Programme nicht unter Windows, > oder Windows Programme nicht unter Linux laufen, > sind zum Glück vorbei. Also das konnte man mit tcl/tk spätestens zu W98 Zeiten haben. Der vermutlich kürzeste Weg zum Kreis falls man dringend einen braucht; $wish % canvas .c -width 200 -height 200 -background white; pack .c % .c create oval 1 1 200 200 -fill red % % wm title . "Kreis in Rot" % Unter win geht/?ging? auch das Fenster transparent zu setzen ~wm . alpha 0.0 dann hat man eben einen roten Fleck auf dem Schirm. Das ist vermutlich zu einfach ;) tcl/tk macht nicht Dick!
S. R. schrieb: > Naja, POSIX ist jetzt aber nicht gerade grafikfähig Für Grafik gibt's dann halt Sachen wie X. S. R. schrieb: > dann > nutzen die meisten Linux-Anwendungen eben nicht POSIX-APIs, sondern > verschiedene GNU- und Linux-Extensions. Traue keiner Statistik... Ein ganzer Haufen GNU/Linux-Tools ist z.B. fixer Bestandteil von Mac OS X. Linux und BSDs versuchen immerhin Standards wie POSIX einzuhalten, und nicht wie Windows etwas völlig frei erfundenes absichtlich inkompatibles hinzuklatschen. Udo K. schrieb: > Ich sehe jetzt einen schwarzen Kreis, noch keinen Sinus. Die 3 Zeilen für den Sinus sind dem Leser als Übung überlassen. Udo K. schrieb: > Hat mich aber 2 Stunden gekostet, das unter Windows (Cygwin) zum > laufen zu bringen Ja unter Windows ist Gtk+ weniger spaßig. Cygwin ist aber unnötig, das geht auch "nativ" mit MinGW. Udo K. schrieb: > Dafür ist das Program 30x so gross MSVC macht kleinere Windows-Binaries, für falls deine HDD so klein ist dass es nicht passt. Udo K. schrieb: > die man noch > irgendwo installieren muss, und die noch mal ein paar GB sind. > OK, Windows muss man auch erst installieren. Unter Linux ist das meist vorinstalliert. Udo K. schrieb: > Es schaut auch irgendiwie ungewohnt aus (eher auf der hässlichen Seite). Installier das "Redmond" Theme. Unter Linux/Gnome fügt sich Gtk+ natürlich perfekt ein. b Udo K. schrieb: > Hier nur mal die Liste der benötigten Windows und Linux Libs: Gtk+ ist halt Teil eines komplexen Ökosystems, mit Unterstützung für alle möglichen Sprachen, Rechts-Nach-Links-Skripte usw. Das braucht halt viele Libs. Udo K. schrieb: > Ein echtes Wunder das sowas noch läuft, und dass wir mit solcher Technik > zum Mond fliegen wollen. Die Logik zur Darstellung von Unicode-Text dürfte um einiges komplexer sein als der Code der Apollo-Missionen. Der konnte nur Englisch... Bei Windows ist der halt in C:\Windows mitgeliefert. Gtk+ könnte dynamisch unter Windows direkt die Windows-APIs nutzen statt Pango & Co, aber das hat halt noch keiner gemacht. Udo K. schrieb: > Die meinsten kleinen Programme brauchen keine binäre 100% Windows > Emulation Für kleine Programme ist das eh müßig. Die portiert man eben fix oder benutzt direkt was portables wie Java. Udo K. schrieb: > ine kleine feine GUI Bibliothek, und eine Standard-C > Lib reicht meist aus. Zumindest, wenn der Entwickler das Programm > neu übersetzt, und beim Entwickeln dran denkt (Wunschdenken). Von der Sorte wurden ja einige genannt. Für meine Zwecke habe ich immer lieber vollwertige Bibliotheken benutzt. Udo K. schrieb: > In den Kernel muss da doch nichts integriert werden. Das sind User > Libs, die auf Cairo/Pango was auch immer zugreifen. Also die Winelib? Zappenduster schrieb: > Am liebsten hätte ich eine C Funktion, ich starte sie einmal an, sie > bringt den Computer in den Grafikmode, sagen wir mal Full HD mit 24 Bit > Farbauflösung. Rückgabewert dieser Funktion ist die Adresse des > Bildschirmspeichers, in den ich dann in eigener Verantwortung schreiben > darf. Das ist unter aktuellen Betriebssystemen wie Windows und Linux völlig unmöglich. Der Kernel abstrahiert die Hardware, und Anwendungen können nur über "High-Level" APIs drauf zugreifen. Wie sonst sollen z.B. mehrere Fenster gleichzeitig dargestellt werden können? Wie gesagt ist so etwas ähnliches über Vulkan möglich, aber der Aufwand ist in etwa das Hunderfache der anderen genannten Ansätze hier, also völlig unangemessen. Udo K. schrieb: > Wenn du das so machen willst, dann kannst du unter Windows > in ein Bitmap reinschreiben. > Das Bitmap liegt im Speicher, und du hast einen Zeiger auf das erste > Byte. Du kast darin nach Lust und Laune wüten. > Wenn du fertig bist, mappst du das Bitmap auf dein offenes Fenster. > Du kannst auch festlegen, dass dein Fenster der ganze Bildschirm ist. Genau das geht unter Linux auch, ob mit Gtk+ oder Xlib oder whatever.
Zappenduster schrieb: > Sven B. schrieb: >> Zum Plotten würde ich die Ausgabe in eine Datei umleiten, und dann >> für einfache Fälle mit gnuplot, für komplexere Darstellung mit Python + >> matplotlib visualisieren. Klar muss man sich da kurz reinlesen, aber es >> erzeugt sehr schöne, auf Wunsch auch interaktiv zoombare Graphen mit >> wenigen (~10) Zeilen Code (inkl. Einlesen der Daten). >> > Wenn ich denn Workflow richtig verstehe, müsste ich da mein C Programm > starten, ein paar Parameter eingeben, das Programm schreibt sowas wie > HPGL in eine Datei, die ich mit Gnuplot anzeigen lassen. Fast ganz richtig. Das Programm schreibt Zahlenkolonnen in die Datei, also eher wie eine Tabellenkalkulation. GnuPlot plottet den Zahlenverlauf, sorgt für die Skalierung (i.d.R. automagisch). Man kann zusätzlich GnuPlot anweisen die Skalenunterteilung, Skalenbeschriftung, Farbwahl, Titelstrings & Titelplatzierung nach eigenem Wunsch abweichend vom Default zu malen. ++++++ Die andere Variante geht natürlich auch, dann aber ohne GnuPlot. Das Programm schreibt Steuersequenzen für ein damaliges, grafikfähiges Datensichtgerät. Z.B. DEC SIXEL, Tek4014, HPGL, usw. Fügen wir sporteshalber auch noch ESC/P und PostScript hinzu, in die Datei. An die Stelle von GnuPlot treten dann Terminalemulator (z.B. XTerm) resp. Druckeremulator (z.B. GhostScript). +++++ Der dritte Weg wurde auch genannt. Das Programm schreibt HTML in die Datei. Ein Browser rendert aka visualisiert das dann. +++++ Da Du offensichtlich auf frei adressierbare Pixels bestehst: schau dir doch den Aufbau von unkomprimierten Grafik(datei)formate an (z.B. BMP) resp. deren in C formulierte Äquivalenzen an. Du lässt dein Programm in diese "virtuellen" (besser: unsichtbaren) "Grafikspeicher" malen und zum Schluss speicherst das in die Datei. Angezeigt wird die Datei von Bildbetrachtern, oder wenn nicht zu exotisches Format vom (Web)Browser. Zuwenig interaktiv? Davon war keine Rede in den Anforderungen...
> Zappenduster schrieb: >> Am liebsten hätte ich eine C Funktion, ich starte sie einmal an, sie >> bringt den Computer in den Grafikmode, sagen wir mal Full HD mit 24 Bit >> Farbauflösung. Rückgabewert dieser Funktion ist die Adresse des >> Bildschirmspeichers, in den ich dann in eigener Verantwortung schreiben >> darf. Na gut, eine Möglichkeit ist da noch: du betreibst dein Linux auf deiner HW in einem "uralt" Modus, wo weder X-11 noch ein Fenstermanager gestartet werden. Erteile deinem Programm entsprechende Privilegien und sprich die Grafikkarte im entsprechend "uralten" Mode direkt als /frame buffer/ an. Unbeschleunigt, eben wie damals. Seh zu dass du entsprechend Doku zu VGA "wie vor 30 Jahren" zur Hand hast und hoffe dass deine aktuelle Grafikkarte diese Modi auch noch beherrscht. Kann man so machen, bloss will das heute nur noch du als einzigster...
Udo K. schrieb: > Und du solltest dich auf Version 0.01 updaten. > > Die Zeiten, wo Linux Programme nicht unter Windows, > oder Windows Programme nicht unter Linux laufen, > sind zum Glück vorbei. Genauso wie die Zeiten, wo die Leute mit Xlib oder der Win32-API Grafik gemalt haben. Mann o mann. Das ist wirklich ganz schön desynchronisiert zur Realität, was du da von dir gibst.
Programmierer schrieb: > Das ist unter aktuellen Betriebssystemen wie Windows und Linux völlig > unmöglich. Der Kernel abstrahiert die Hardware, und Anwendungen können > nur über "High-Level" APIs drauf zugreifen. Wie sonst sollen z.B. > mehrere Fenster gleichzeitig dargestellt werden können? Mit dem Windows-API ist es immerhin sehr einfach möglich, den Clientbereich eines Fensters quasi zu "Poken". OK, man benutzt eine Bitmap als Buffer, aber da sei drauf geschissen... Es scheint also deutlich näher an den praktischen Erfordernissen zu sein als dein hochgelobter "POSIX-Standard"... Und natürlich kann das Windows-API noch sehr viel mehr. Was man wohl daran sieht, dass alle für das Wirtschaftsleben wesentlichen Desktop-Anwendungen nur für genau dieses Target existieren... > Genau das geht unter Linux auch, ob mit Gtk+ oder Xlib oder whatever. Genau das ist das Problem unter Linux. Man kann auf alles mögliche treffen. Oder eben auch nicht... Da muss man dann im Einzelfall mit klarkommen. Unter Windows muss man das nicht. Das Win32-API ist so konstant, dass es schon länger in kaum veränderter (allerdings erheblich erweiterter) Form existiert, als es Linux als OS überhaupt gibt... Programmierer mögen langzeitstabile APIs und ABIs. Damit haben sie nämlich am wenigsten Arbeit bei der Pflege ihrer eigenen Produkte...
Mit der Xlib hab ich 1987 schon unter HP-UX gearbeitet. Da war nix mit Win-Api. Da war eher DOS3.3.
Worggfloh schrieb: > Na gut, eine Möglichkeit ist da noch: du betreibst dein > Linux auf deiner HW in einem "uralt" Modus, wo weder X-11 > noch ein Fenstermanager gestartet werden. Alternativ drückst du "Strg+Alt+F1" und schreibst die Datenbytes nach /dev/fb0. Das ist vermutlich ziemlich genau das, was der TO will. Ausprobieren: - Strg+Alt+F1 - einloggen - dd if=/dev/urandom of=/dev/fb0 - (den Bildschirm neu zeichnen mit Strg+L)
c-hater schrieb: > Programmierer mögen langzeitstabile APIs und ABIs. Damit haben sie > nämlich am wenigsten Arbeit bei der Pflege ihrer eigenen Produkte... Außer natürlich dass du halt das ganze Produkt neu schreiben musst, wenn du es auf Android, Linux oder macOS haben willst, wenn es mit der win32-API gebaut ist ...
Im Anhang meine ersten Versuche von 1993 Grafik unter Linux mit xlib auszugeben. Zu meinem erstaunen liess es sich sogar gerade noch uebersetzen und hat etwas ausgegeben. Alles echtes pures C. :-) Ich wuerde aber trotzdem eher das hier empfehlen: http://xforms-toolkit.org/ Das ist zwar auch schon steinalt, aber ebenfalls C und funktioniert ganz gut. Aber es war schon erstaunlich das man damals ein Grafikprogramm schreiben konnte das nur wenig kb gross war und nicht der aufgeblasene Mist der heute so Standard ist. Olaf
Ich hab gerade noch was gefunden. Auch von 1993. :-) Das malt mit xlib ein Apfelmaenchen. Lies sich auch noch uebersetzen, allerding musste ich kurz noch was ins Makefile reinhacken. Da fehlte eine Libary und wer weis ob Imakefile heute noch funktioniert. Damals konnte man dem Programm noch beim malen zuschauen. Das geht heute nicht mehr. Olaf p.s Und bitte keine beschwerden ueber die Qualitaet des Codes. :-D
c-hater schrieb: > Und natürlich kann das Windows-API noch sehr viel mehr. Es kann aber das nicht, wofür X da ist: transparent Grafik übers Netz übertragen. Das war nämlich für Mainframes und Terminals erdacht. Dieser Use Case ist zwar überholt aber ist der Grund dafür. Gelegentlich ist es auch noch recht praktisch X Verbindungen über SSH Tunneln zu können. c-hater schrieb: > Und natürlich kann das Windows-API noch sehr viel mehr. Was man wohl > daran sieht, dass alle für das Wirtschaftsleben wesentlichen > Desktop-Anwendungen nur für genau dieses Target existieren... Das liegt nicht daran dass das Win32 API so toll wäre. Sondern daran dass MS' extrem clevere Strategie zur Markt-Beherrschung und Konkurrenz-Unterdrückung Windows überall hin forciert hat. Natürlich laufen auch jede Menge Business Anwendungen auch, oder nur, auf Unix Systemen. c-hater schrieb: > Das Win32-API ist so konstant, dass es schon länger in kaum veränderter > (allerdings erheblich erweiterter) Form existiert, als es Linux als OS > überhaupt gibt... Aber POSIX gibt es noch länger. Anstatt das zu implementieren hat MS was eigenes gefrickelt. Und POSIX ist selbstverständlich auch API und ABI kompatibel. karadur schrieb: > Mit der Xlib hab ich 1987 schon unter HP-UX gearbeitet. Da war nix mit > Win-Api. Da war eher DOS3.3. Genau!
SDL mit SDL_gfx kann auch direkt auf Framebuffer ausgeben. Am Programm ändert sich GAR NICHTS, nur eine Umgebungsvariable muss geändert werden. Wurde schon mehrfach genannt. Und wer meint, Xlib sei das einfachste, der hat noch nichts anderes gesehen oder trollt. Da ist VGA-register Programmierung fast noch einfacher... Neben dem sdl wiki gibt's noch wikibooks - SDL_gfx auf Deutsch.
Programmierer schrieb: > c-hater schrieb: >> Und natürlich kann das Windows-API noch sehr viel mehr. Was man wohl >> daran sieht, dass alle für das Wirtschaftsleben wesentlichen >> Desktop-Anwendungen nur für genau dieses Target existieren... > > Das liegt nicht daran dass das Win32 API so toll wäre. Sondern daran > dass MS' extrem clevere Strategie zur Markt-Beherrschung und > Konkurrenz-Unterdrückung Windows überall hin forciert hat. Natürlich > laufen auch jede Menge Business Anwendungen auch, oder nur, auf Unix > Systemen. Leg mal die Propaganda Brille ab. Zu der Zeit, als Win32 entstand, hatte Unix (3D Profi CAD, Visualisierung auf Irix) und Apple (Drucker, Postscript) die Dominanz im Grafikbereich. MS mit Windows war damals eine kleine, aufstrebende Nummer. Daher kommt es, das das Win32 Grafik Api im wesentlichen dem Postscript Standard nachempfunden ist. Windows GDI lässt sich Befehl für Befehl auf Postscript abbilden. Wie 90% aller Grafik Api's aus der Zeit. Ich glaube Postscript war von Xerox beeinflusst. Und wie man oben am Sinus Beispiel sieht, ist Xlib praktisch identisch zum Win32. Jeder musste schliesslich irgendwann mal vom Bildschirm zum Drucker laufen. Und auf dem Drucker lief Postscript. Das war gerade für die damals aufstrebenden What-you-see-is-what-you-get Office Programme, mit denen man im Profi Bereich richtig Geld machen konnte, wichtig. Aber auch für einträgliche CAD Software, die SW Hersteller forderten das von MS auch ein. Ja, damals vor der Open Source Bewegung, konnte man mit Software Anwendungen gut Geld verdienen. Von daher ist auch der Aufwand ein Program von "native" Win32 auf "native" Xlib zu portieren erstaunlich einfach. Auch wenn es nicht automatisch geht, so sind doch immer ähnliche Aufrufe vorhanden. Wenn man sich auf ein komplexes Framework wie WPF, GTK oder QT verlässt, dann ist man verlassen, wenn man das portieren muss, oder wenn es aus irgendeinem Grund mal nicht geht, oder wenn man ein Feature braucht, dass es nicht unterstützt. Gerade für den Bastler oder die 10 Mann Bude ist das ein wichtiger Punkt. Der kann nicht, wie MS oder IBM, schnell 50 Entwickler abstellen, die nichts anderes machen, als Integrationstests, die aufpassen das ein neues Feature/Update der Lib X.Y nicht die Lib A.B zerschiesst. Ein einzelner hat keine Change zu durchschauen, wie die Abhängigkeiten der Libs in einem komplexen Framework sind, gerade wenn Zeitdruck da ist. Er ist dazu verdammt, die Api immer wieder mal falsch oder suboptimal anzuwenden. Man sieht die Probleme schon schön an ven vielen DLLs, von denen das GTK Sinus Program abhängig ist: Da verwendet das GTK Sinus Program (das ich weiter oben unter Windows mit Mingw compiliert hatte, und das nebenbei nur einen schwarzen Kreis malt) doch glatt die zlib1 DLL der installierten Matlab Version 2007! Die DLLs werden aus der PATH Umgebungsvariable geladen, und dynamisch zur Laufzeit geladen. Und die Matlab zlib1 DLL kommt vor der GTK eigenen zlib DLL... Wie schon gesagt, ein Wunder das das funktioniert, bzw. Glück das sich die zlib seit 20 Jahren nicht wesentlich geändert hat.
Udo K. schrieb: > Wenn man sich auf ein komplexes Framework wie > WPF, GTK oder QT verlässt, dann ist man verlassen, wenn > man das portieren muss, oder wenn es aus irgendeinem > Grund mal nicht geht, oder wenn man ein Feature braucht, dass > es nicht unterstützt. Diese Sichtweise ist in meinen Augen total verquer. Ich habe keine Ahnung, welchem Gedankengang man folgen muss, um zur Schlussfolgerung zu kommen, dass man mit der Windows-API besser dran ist, wenn man eine Anwendung portieren muss, als mit einer Qt-Anwendung. Das ergibt einfach keinerlei Sinn. > Er ist dazu verdammt, die Api immer wieder mal falsch > oder suboptimal anzuwenden. Das würde natürlich mit der Win32-API NIEMALS passieren! > Von daher ist auch der Aufwand ein Program von "native" Win32 auf > "native" Xlib zu portieren erstaunlich einfach. Bullshit. Das gilt vielleicht für jede einzelne Zeile, aber nimm doch bitte mal sowas wie Photoshop und portiere es auf Xlib. Damit wirst du in 30 Jahren nicht fertig. Aus dem beruflichen Umfeld kenne ich Qt-Anwendungen mit Millionen Codezeilen. Die von Windows auf macOS zu portieren ist was, was ein paar einzelne Leute in ein paar Wochen machen können, weil im Wesentlichen alles schon geht und man nur ein paar Randfälle anfassen muss. Auf Linux läuft sowas eh ohne nennenswerten Zusatzaufwand, selbst wenn die meiste Entwicklung unter Windows passiert. Hast du jemals an einem größeren Softwareprojekt gearbeitet, was mehrere Plattformen unterstützt hat und auch ein paar Jahre lang gewartet und benutzt wurde?
:
Bearbeitet durch User
Sven B. schrieb: > Udo K. schrieb: >> Er ist dazu verdammt, die Api immer wieder mal falsch >> oder suboptimal anzuwenden. > > Das würde natürlich mit der Win32-API NIEMALS passieren! Natürlich passiert das. Aber das Win32 Api ist vergleichsweise einfach zu durchschauen. Zumindest das Win32 Api von Windows XP, oder auch Xlib/XForms. Für eine kleine Bude oder einen Hobbyentwickler, der sich nicht 100% mit GUI Entwicklung beschäftigt, kann das der einfachere Weg zum Ziel sein. Auch wenn das Progamm dann langweilig ausschaut, dafür aber klar strukturiert, leicht verständlich und funktional daherkommt. >> Von daher ist auch der Aufwand ein Program von "native" Win32 auf >> "native" Xlib zu portieren erstaunlich einfach. > > Bullshit. Das gilt vielleicht für jede einzelne Zeile, aber nimm doch > bitte mal sowas wie Photoshop und portiere es auf Xlib. Damit wirst du > in 30 Jahren nicht fertig. Na ja, es reicht wahrscheinlich Photoshop in einer alten Version neu für Linux zu übersetzen. Immerhin lief es mal auf Mac OS, und das war im wesentlichen Unix. > > Hast du jemals an einem größeren Softwareprojekt gearbeitet, was mehrere > Plattformen unterstützt hat und auch ein paar Jahre lang gewartet und > benutzt wurde? Ich habe mich auf einfache technisch orientierte Programme bezogen, wo max. ein paar Leute dran arbeiten, und das auch nicht 100%. Habe ich das nicht geschrieben? Da verschiebt sich der Schwerpunkt weg von Komplexität (die viel Funktionalität mit sich bringt), zu simple and stupid. Ansonsten läuft das nach 5-20 Jahren einfach nicht mehr. Wenn Programme keine wesentlichen neuen Features im Vergleich zur letzten Version bieten, oder mit bunter Werbung bezahlt werden, dann verschiebt sich der Schwerpunkt natürlich woanders hin.
Programmierer schrieb: > Und POSIX ist selbstverständlich auch API und ABI kompatibel. Nein, POSIX definiert nur eine API, keine ABI. Viele grundlegende Datenstrukturen (z.B. "struct stat") weichen auf unterschiedlichen Systemen voneinander ab und dürfen das auch. Binärkompatiblität gibt es nicht, war auch nie das Ziel. Udo K. schrieb: > Auch wenn das Progamm dann langweilig ausschaut, > dafür aber klar strukturiert, leicht verständlich > und funktional daherkommt. Eine veraltete API zu benutzen führt keineswegs automatisch zu einer klaren Struktur, leichter Verständlichkeit und Funktionalität. Vor allem dann nicht, wenn die veraltete API die benötigte Funktionalität garnicht bietet... Udo K. schrieb: > Na ja, es reicht wahrscheinlich Photoshop in einer alten Version > neu für Linux zu übersetzen. Eine antike Version für ein System kompilieren zu können ist etwas völlig anderes als ein Port des Programms auf ebendieses System. Udo K. schrieb: > Immerhing lief es mal auf Mac OS, und das war im wesentlichen Unix. Nein. Mac OS ist kein Unix, nichtmal im Ansatz. Und, wie ich bereits anmerkte, spezifiziert POSIX keinerlei grafische Funktionen und die Mac OS Toolbox unterscheidet sich deutlich von sowohl Win32 als auch X11.
Udo K. schrieb: > Na ja, es reicht wahrscheinlich Photoshop in einer alten Version > neu für Linux zu übersetzen. > Immerhin lief es mal auf Mac OS, und das war im wesentlichen Unix. Das ist halt einfach Quatsch :/ Ja, macOS ist so mehr oder weniger POSIX, aber wie du vorher schon gesagt hast hat halt POSIX mit grafischer Ausgabe nix zu tun. Es gibt einfach keinerlei Überschneidung zwischen POSIX und grafischer Ausgabe. Und das Grafik-Layer von macOS ist völlig unterschiedlich von dem was Linux üblicherweise so hat. Die "alte Version von Photoshop" wird mit Sicherheit schlicht keinen Code haben, der irgendeine der unter Linux verfügbaren APIs zur grafischen Ausgabe ansteuern kann.
Da die Arduinowelt so schön einfach ist ... man kann den Graph an GnuPlot "pipen": https://github.com/ChrisMicro/ArduinoOnPc/blob/master/examples/gnuPlot/gnuPlot.ino
Sven B. schrieb: > Was immer du tust nimm nicht die Xlib, da ist sich jeder seit 15 Jahren > einig, dass das nicht der Weg ist wie man Kram zeichnet. Ja, der designierte Nachfolger ist XCB. Das ist schlanker und effizienter. Allerdings wird das selten direkt, sondern meist nur indirekt über komfortablere GUI-Frameworks verwendet. XCB ist halt wie die GDI-Sachen eher umständlich zu benutzen. Ja, ein minimales Beispiel-Programm für einen Sinus ist damit schnell gemacht, aber mach damit mal was größeres. Udo K. schrieb: > Wäre doch was, wenn die Linux Nerds wenigstens die Basics vom Windows > Gui Api endlich mal "native" portieren würden, > so dass das Wine Geraffel unnötig wird. Ich glaube, die GDI+ Bibliothek > läuft ja schon unter Mono/Cairo? > Dann hätte Linux endlich eine passable Gui Bibliothek :-) Die gibts ungefähr so lange wie es Windows gibt - also nicht Win32, sondern Windows überhaupt. xlib und Windows 1.0 kamen beide im Jahr 1985 raus. Programmierer schrieb: > Zappenduster schrieb: >> Am liebsten hätte ich eine C Funktion, ich starte sie einmal an, sie >> bringt den Computer in den Grafikmode, sagen wir mal Full HD mit 24 Bit >> Farbauflösung. Rückgabewert dieser Funktion ist die Adresse des >> Bildschirmspeichers, in den ich dann in eigener Verantwortung schreiben >> darf. > > Das ist unter aktuellen Betriebssystemen wie Windows und Linux völlig > unmöglich. Unter Linux geht das schon. Man muss den Zugriff auf den Speicherbereich halt vom Betriebssystem anfordern und braucht die dafür nötigen Berechtigungen. > Wie gesagt ist so etwas ähnliches über Vulkan möglich, aber der Aufwand > ist in etwa das Hunderfache der anderen genannten Ansätze hier, also > völlig unangemessen. Geht auch mit OpenGL über ein PixelBuffer-Objekt. Das kann man in sein Programm mappen und bekommt dann einen Zeiger, über den man beliebig auf die Pixeldaten zugreifen kann. Das ist zwar auch etwas umständlich, aber deutlich kompakter als der ganze Code, den man bei Vulkan braucht, um überhaupt mal was angezeigt zu bekommen. c-hater schrieb: > Mit dem Windows-API ist es immerhin sehr einfach möglich, den > Clientbereich eines Fensters quasi zu "Poken". OK, man benutzt eine > Bitmap als Buffer, aber da sei drauf geschissen... Wie kommst du auf die unsinnige Idee, das ginge nur unter Windows? > Es scheint also deutlich näher an den praktischen Erfordernissen zu sein > als dein hochgelobter "POSIX-Standard"... Ich würde es heute eher als wenig praxisrelevant einstufen. Kein Mensch schreibt heute auf dem PC noch Programme, die jeden Pixel einzeln selber setzen. Das ist viel zu ineffizient. > Und natürlich kann das Windows-API noch sehr viel mehr. Was man wohl > daran sieht, dass alle für das Wirtschaftsleben wesentlichen > Desktop-Anwendungen nur für genau dieses Target existieren... Das ist mit Sicherheit nicht in der Windows-API begründet, sondern darin, dass damals ein PC einfach viel billiger war als eine Unix-Workstation. Als man dazu überging, dass jeder Mitarbeiter einen Computer haben sollte, wurde das relevant. >> Genau das geht unter Linux auch, ob mit Gtk+ oder Xlib oder whatever. > > Genau das ist das Problem unter Linux. Man kann auf alles mögliche > treffen. Oder eben auch nicht... > Da muss man dann im Einzelfall mit klarkommen. Unter Windows muss man > das nicht. Wenn man nicht drauf trifft, macht man ein "apt install libgtk3-dev", und nach 30 Sekunden ist alles fertig installiert, das man braucht, um damit eine Anwendung zu bauen. Und wie viele verschiedene GUI-APIs hat alleine Microsoft selber im Laufe der Jahre angehäuft? GDI, MFC, WPF, Windows Forms, WinUI… > Das Win32-API ist so konstant, dass es schon länger in kaum > veränderter (allerdings erheblich erweiterter) Form existiert, als es > Linux als OS überhaupt gibt... Wie oben geschrieben, gibt es die auch heute noch nutzbare xlib ziemlich genau so lange wie es Windows überhaupt gibt und damit deutlich länger als Win32. Udo K. schrieb: > Ja, damals vor der Open Source Bewegung, > konnte man mit Software Anwendungen gut Geld verdienen. Die OpenSource-Bewegung ist entstanden, weil es irgendwann auf einmal nicht mehr selbstverständlich war, dass man zu seiner gekauften Software den Sourcecode dazu bekommen hat. > Von daher ist auch der Aufwand ein Program von "native" Win32 auf > "native" Xlib zu portieren erstaunlich einfach. > Auch wenn es nicht automatisch geht, so sind doch immer ähnliche > Aufrufe vorhanden. Für ein Programm von 30 Zeilen Länge mag das gelten. Mach das aber mal mit einem Programm, das eine Million Zeilen hat. Da wirst du etliche Mannmonate, bzw. vermutlich eher im Bereich Mannjahre versenken müssen, bis das sauber läuft. > Wenn man sich auf ein komplexes Framework wie > WPF, GTK oder QT verlässt, dann ist man verlassen, wenn > man das portieren muss, oder wenn es aus irgendeinem > Grund mal nicht geht, oder wenn man ein Feature braucht, dass > es nicht unterstützt. Ich hab schon Qt-Programme, die für Linux geschrieben waren, nur durch ein paar Anpassungen an den Build-System-Einstellungen nach Windows, Andorid und WebAssembly portiert. Natürlich ist die Voraussetzung, dass das Zielsystem von Qt unterstützt wird. Ein Programm von einer API auf eine andere zu portieren, ist aber immer viel Aufwand. > Da verwendet das GTK Sinus Program > (das ich weiter oben unter Windows mit Mingw compiliert hatte, und das > nebenbei nur einen schwarzen Kreis malt) > doch glatt die zlib1 DLL der installierten Matlab Version 2007! Das Programm verwendet die, die du ihm gibst. Wenn du das System so konfiguriert hast, dass es die nimmt, dann tut es das eben. > Die DLLs werden aus der PATH Umgebungsvariable geladen, und dynamisch > zur Laufzeit geladen. > Und die Matlab zlib1 DLL kommt vor der GTK eigenen zlib DLL... > Wie schon gesagt, ein Wunder das das funktioniert, bzw. Glück das sich > die zlib seit 20 Jahren nicht wesentlich geändert hat. Das ist ein vor allem unter Windows verbreitetes Problem, auch als "DLL Hell" bekannt. Es gibt halt keinen vernünftigen Paketmanager, der die Abhängigkeiten automatisch auflöst. Sven B. schrieb: > Hast du jemals an einem größeren Softwareprojekt gearbeitet, was mehrere > Plattformen unterstützt hat und auch ein paar Jahre lang gewartet und > benutzt wurde? Ich vermute nicht. Ich glaube auch nicht, dass er jemals wirklich mit einem Framework wie z.B. Qt gearbeitet hat (zumindest nicht über irgendwelche kleinen Trivialprogrämmchen hinaus). Die Ansichten passen einfach so überhaupt nicht zur Realität.
S. R. schrieb: > Worggfloh schrieb: >> Na gut, eine Möglichkeit ist da noch: du betreibst dein >> Linux auf deiner HW in einem "uralt" Modus, wo weder X-11 >> noch ein Fenstermanager gestartet werden. > > Alternativ drückst du "Strg+Alt+F1" und schreibst die Datenbytes nach > /dev/fb0. Das ist vermutlich ziemlich genau das, was der TO will. > > Ausprobieren: > - Strg+Alt+F1 > - einloggen > - dd if=/dev/urandom of=/dev/fb0 > - (den Bildschirm neu zeichnen mit Strg+L) Also unter Debian10 geht das nicht. liegt aber evt. auch an der Grafikkarte
Udo K. schrieb: > Und wie man oben am Sinus Beispiel sieht, ist Xlib praktisch identisch > zum Win32. In diesem sehr primitiven Beispiel mag das so erscheinen. Beide Bibliotheken interagieren mit Anwendungsprogrammen über Events, die von diesem üblicherweise in einer Schleife abgefragt werden, und beide stellen die üblichen Grafikprimitive (Zeichnen von Punkten, Linien, Kreisen usw.) zur Verfügung. Das war's aber auch schon mit den Gemeinsamkeiten, und viel mehr wird von unseren Sinusprogrämmchen auch nicht genutzt. X11 hat im Gegensatz zu Windows eine Client-Server-Architektur, wobei Client und Server auf verschiedenen Rechnern laufen können. Damit verbunden ist auch das Konzept des "Displays" (die Kombination aus einem oder mehreren Bildschirmen ("Screens"), einer Tastatur und einer Maus). Auf einem Rechner oder in einem Netzwerk können beliebig viele Displays mit jeweils beliebig vielen Screens existieren. Von daher kommt auch der relativ komplizierte Ablauf, um ein Fenster zu öffnen. Überträgt man die Begriffe Display und Screen auf Windows, gibt es dort nur ein einziges Display mit einem einzigen Screen (inzwischen unterstützt Windows zwar auch mehrere Bildschirme, diese bilden aber immer noch einen einzigen logischen Screen). Dass in Win32 das Öffnen eines Fensters dennoch so kompliziert ist wie in der libX11, hat andere Gründe. Im Gegensatz zu Windows trennt X11 klar zwischen dem eigentlichen Window-System und dem Window-Manager. Der Window-Manager ist genauso wie jede andere X11-Applikation ein X11-Client und kann damit auf einem beliebigen Rechner innerhalb eines Netzwerks laufen. Aus Sicht der libX11 sind Fenster nichts weiter als rechteckige, ggf. überlappende Zeichenflächen auf einem Bildschirm. Die libX11 kennt weder Fensterrahmen noch Widgets für das Verschieben, Vergrößern und Schließen des Fensters. Das sind alles Dinge, die vom Window-Manager hinzugefügt werden. Auch sonst kennt die libX11 im Gegensatz zu Win32 keine Widgets. Diese werden von zusätzlichen Bibliotheken aus anderen Quellen bereitgestellt. In Windows bilden das Betriebssystem, das Window-System, der Window-Manager und noch vieles mehr einen monolithischen Block, der nicht auf mehrere Rechner verteilt werden kann. Mit X11 hingegen ist es möglich, eine Applikation mit grafischer Oberfläche auch auf einem schwachbrüstigen, speicherarmen Embedded-Rechner ohne Grafikhardware, Tastatur und Maus laufen zu lassen, solange er per Netzwerk mit einem externen Rechner verbunden ist, der über diese Hardware verfügt. Die libX11 bietet also viele Funktionen, die Win32 nicht hat und umgekehrt. Deswegen ist eine Portierung von nichttrivialen Anwendungen zwischen den beiden Systemen i.Allg. mit viel Aufwand verbunden. Wenn Portabilität wichtig ist, verwendet man eine GUI-Bibliothek auf höherer Abstraktionsebene, die auf allen in Frage kommenden Zielsystemen verfügbar ist. Dafür gibt es mittlerweile genügend Lösungen, so dass es nur noch wenige Gründe gibt, sich in die Niederungen von Win32 oder libX11 hinab zu begeben.
Hallo Zappenduster. Zappenduster schrieb: >> Zum Plotten würde ich die Ausgabe in eine Datei umleiten, und dann >> für einfache Fälle mit gnuplot, für komplexere Darstellung mit Python + >> matplotlib visualisieren. Klar muss man sich da kurz reinlesen, aber es >> erzeugt sehr schöne, auf Wunsch auch interaktiv zoombare Graphen mit >> wenigen (~10) Zeilen Code (inkl. Einlesen der Daten). >> > Wenn ich denn Workflow richtig verstehe, müsste ich da mein C Programm > starten, ein paar Parameter eingeben, das Programm schreibt sowas wie > HPGL in eine Datei, die ich mit Gnuplot anzeigen lassen. Das siehst Du zu kompliziert. A) Du könntest die Umlenkung der Ausgabe in Gnuplot schon im C-Programm machen. Wahlweise CSV-Datei oder gnuplot. Dann startest Du nur Dein C-Programm. Die Lenkung der Ausgabe könntest Du z.B. über Komandozeilenparameter machen, dann brauchst Du auch kein GUI. B) Du startes ein Python Skript, welches dir Dein C-Programm startet, die Ausgabe übernimmt und entweder in eine Datei oder Gnuplot weiterschiebt. Wie bei dem C-Programm kämst Du ohne GUI aus, wenn Du das Python-Skript per kommandozeilenparameter lenkst. C) Du hast ja ein C-Programm geschrieben, und weisst daher was Du machen must. Dann kannst Du das ganze auch in Python einfach neu schreiben. Mathplotlib als Bibliothek wurde ja oben schon erwähnt, ich füge noch tkinter als Bibliotheksempfehlung hinzu, wenn Du ein GUI dazu machst. Diese reine Python Lösung hätte den Charm, auf jedem OS lauffähig zu sein, das Python unterstützt. > Hübsch, aber ich wollte wirklich wie bei einem ZX81 Grafik in Echtzeit. Aktuelle Hardware ist so flott, dass "Echtzeit" nicht mehr soooo wichtig ist. ;O) Und schon gar nicht, wenn du einen menschlichen Betrachter hast Nachtrag: Wenn Du was mit Python machst, mache es in Python 3. Zwei ist wirklich veraltet (Seit über 10 Jahren schon), und zwei und drei sind "leider" inkompatibel. Leider in Anführungszeichen, weil ich mittlerweile auch zu dem Kreis von Leuten gehöre, die meinen, der harte Schnitt sei besser als Kompatibilität um jeden Preis und dafür Unmengen von Inkonsistenzen in der Sprache in kauf zu nehmen. Im April dieses Jahres wurde die Entwicklung bzw. der support von Python 2 definitiv beendet. Siehe https://de.wikipedia.org/wiki/Python_(Programmiersprache)#Ende_von_Python_2 Python (3) ist ansonsten übrigens das "neue Basic" . Einfacher in der Handhabung, wesentlich mächtiger und zusätzlich sehr portabel über einen ganzen bunten Strauß verschiedener OS. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Debian user schrieb: > Also unter Debian10 geht das nicht. > liegt aber evt. auch an der Grafikkarte Ich hab das auf meinem System unter Debian10 getestet. Funktioniert natürlich nur, wenn du auch einen Framebuffer-Treiber hast (KMS bringt einen mit), also effektiv "alles außer nvidia".
Hi Folks, hier ist mal wieder der TO. Hatte noch nicht wirklich Zeit, die ganzen Antworten zu lesen. Leider enthalten viele der Antworten so viele Begriffe, die ich nicht kenne, da habe ich Angst, da würde in meinem Fall wohl nicht mal ein Informatikstudium helfen. Ich habe wohl die letzten 30 Jahre verpennt und bin in den frühen 80gern hängengeblieben ;-) Hier im Anhang ein Beispiel, was ich schon vor einiger Zeit hinbekommen habe. Dieses System Display meine_Datei.bmp ist nicht wirklich geschmeidig. Ich muss dieses Display mit einem Tastendruck beenden. In den 80ern hätte ich diesen Farbkreis zum rotieren gebracht...
>Farbkreis1.c Also ... wenn du eine Datei schreiben willst, ist es besser, eine HTML-Datei mit SVG-Graphik zu schreiben und diese dann mit dem Browser zu öffnen. Wenn du das ganze dynamisch willst, kannst du Java-Script einbinden, da ist im Browser sogar ein Debugger eingebaut: https://www.w3schools.com/graphics/tryit.asp?filename=trysvg_polyline SVG: https://de.wikipedia.org/wiki/Scalable_Vector_Graphics
> Dafür gibt es mittlerweile genügend Lösungen, so dass es > nur noch wenige Gründe gibt, sich in die Niederungen von Win32 oder > libX11 hinab zu begeben. Das ist natuerlich richtig. Allerdings ist es vermutlich eher schwierig wenn man das in C machen will wie es der TO eigentlich vorhat! Wenn man es aber in C machen will und C++ Kenntnisse hat dann gibt es einen Trick. Ich hab vor kurzem sowas in Qt gemacht. Da habe ich ein Buffer in C++ erzeugt der von C beliebig beschrieben werden kann. Das nutze ich um eine Testumgebung fuer Mikrocontrollersoftware zu haben. Das koennte ich problemlos auf Linux oder Windows laufen lassen. So kann ich ein Program problemlos auf dem Mikrocontroller laufen lassen und durch einfach neu compilieren laeuft es auf dem PC. Olaf
>Wenn man es aber in C machen will und C++ Kenntnisse hat dann gibt es >einen Trick. Ich hab vor kurzem sowas in Qt gemacht. Da habe ich ein >Buffer in C++ erzeugt der von C beliebig beschrieben werden kann. Das >nutze ich um eine Testumgebung fuer Mikrocontrollersoftware zu haben. >Das koennte ich problemlos auf Linux oder Windows laufen lassen. So kann >ich ein Program problemlos auf dem Mikrocontroller laufen lassen und >durch einfach neu compilieren laeuft es auf dem PC. Das gleiche Prinzip habe ich für die ArduinoOnPc Simulation gemacht. Der Bildschirm und die Maus ersetzen das TFT, das an einen Arduino angeschlossen wird. Der Vorteil: Man kann die Arduino-Tutorials nutzen. https://github.com/ChrisMicro/ArduinoOnPc/blob/master/examples/Adafruit_touchpaint/Adafruit_touchpaint.ino
Zappenduster schrieb: > Wie könnte ich Grafik... darstellen? Hier ist mein Tutorial dazu: http://stefanfrings.de/qt_lernen/index.html
Zappenduster schrieb: > Hier im Anhang ein Beispiel, was ich schon vor einiger Zeit hinbekommen > habe. Dieses System Display meine_Datei.bmp ist nicht wirklich > geschmeidig. Ich muss dieses Display mit einem Tastendruck beenden. Das angehängte farbkreis-gfx.c benutzt die oben verlinkte gfx-Bibliothek und zeigt den Farbkreis direkt in einem Fenster an. Das ist allerdings ziemlich langsam, da X11 nicht darauf optimiert ist, ein Fenster pixelweise mit Inhalt zu füllen. > In den 80ern hätte ich diesen Farbkreis zum rotieren gebracht... Siehe farbkreis-cv.cpp im Anhang. Das Programm benutzt die OpenCV, was zwar ein wenig mit Kanonen auf Spatzen geschossen ist, dafür reduziert sich das Fenstergedöns auf gerade mal eine Codezeile (imshow(...)). Da die Pixeldaten des gesamten Bildes in einem Rutsch ausgegeben werden, läuft die Sache auch wesentlich schneller als mit der gfx-Bibliothek und ohne Anpassung auf Linux, Mac OS, Android und Windows. Allerdings ist das Programm in C++ geschrieben, da die OpenCV in der aktuellen Version C nicht mehr so richtig zu unterstützen scheint.
:
Bearbeitet durch Moderator
Hallo, ich häng mich mal hier mit einer Frage dran, vielleicht ist sie auch für den TO interessant. Ich habe ein C-Programm, welches aus einem Konsolenfenster gestartet wird mit ./name . Das Programm macht irgendwelche Berechnungen und verwendet die Xlib um das Ergebnis anzuzeigen. Dazu öffnet es ein Grafikfenster mit XCreateSimpleWindow und wartet auf Eingaben von der Konsole, welche die Grafik steuern und beenden mit XCloseWindow. Funktioniert auch alles. Das Problem ist, dass das Grafikfenster in der Kopfleiste einen Schließen-Knopf hat. Das Klicken auf diesen Schließen-Knopf ist nicht vorgesehen. Wenn man es dennoch tut, schließt der Window- Manager das Fenster. Es kommt eine Fehlermeldung "Fatal error", vermutlich wenn das in der Konsole laufende Programm versucht, Daten ins nicht mehr existierende Grafikfenster zu schreiben, und das Programm wird beendet. Es ist auch nicht möglich, das zu vermeiden, indem das Programm vor jeder Ausgabe abfragt ob das Grafikfenster noch geöffnet ist, weil das Schließen durch den Window-Manager asynchron erfolgt. Weiss jemand eine Lösung für das Problem? PS: Es geht um das Emulationsprogramm für mein bo8h-Projekt.
Wenn man ein Fenster öffnet, kann man normalerweise optionale Parameter angeben, die nicht nur die Größe sondern auch die verfügbaren Buttons vorgeben. Und an jeden Button kann man eventhandler hängen. Ich habe auf die Schneller aber nicht gefunden, wie man das bei xlib macht.
Josef G. schrieb: > Weiss jemand eine Lösung für das Problem? Wie ich schon oben schrieb, weiß die libX11 von Hause aus wenig bis gar nichts von Close-Buttons u.ä., weil diese zunächst einmal Sache des Window-Managers sind. Dieser sendet beim Schließen aber ein Event, das mit libX11-Funktionen verarbeitet werden kann. Hier steht wie (erste Antwort): https://stackoverflow.com/questions/1157364/intercept-wm-delete-window-on-x11
Ich möchte hier auch nochmal Javascript vorschlagen. Was mich dabei überzeugt hat, ist dieses Video: https://www.youtube.com/watch?v=xGmXxpIj6vs Da schreibt einer ein Snake-Spiel in unter 5 Minuten. Wenn man schon programmieren kann, dann lernt man halt die wichtigsten Basics für so etwas in wenigen Minuten.
Markus K. schrieb: > Ich möchte hier auch nochmal Javascript vorschlagen. JS / canvas im Browser wurde schon vorgeschlagen, ja. Kann ich nur zustimmen. leo
leo schrieb: > JS / canvas im Browser wurde schon vorgeschlagen, ja. Kann ich nur > zustimmen. Sog. "Web-Technologien" zu verwenden, ist der sicherste Weg, um Programme zu schreiben, die u.U. schon in wenigen Monaten nicht mehr funktionieren... Man braucht sich doch bloß die Geschichte eben diese Technologien und der Browser, die sie umsetzen, anzuschauen... Da wird heute die eine Kuh durch's Dorf getrieben und schon morgen ist sie obsolete... Nur Leute mit einem verdammt kleinen zeitlichen Erfahrungshorizont können sowas ernsthaft empfehlen...
c-hater schrieb: > Da wird heute die eine Kuh durch's Dorf getrieben und schon morgen ist > sie obsolete... Canvas ist jedoch so generisch, dass ich mir nicht vorstellen kann, dass es wieder abgeschafft wird. Es werden wohl eher neue Funktionen hinzugefügt.
c-hater schrieb: > Nur Leute mit einem verdammt kleinen zeitlichen Erfahrungshorizont > können sowas ernsthaft empfehlen... Der TO schrieb: > Ich programmiere kleine Progrämmchen in C, die > irgendwas ausrechnen und das mit printf() anzeigen. > Wie könnte ich Grafik, z.B. eine Sinusfunktion Ich empfehle das nicht allgemein, sondern wegen diesen Anforderungen. Und so kurzfristig ("Monate") sind Webstandards dann doch wohl auch nicht. Aber du kannst sicher eine nachhaltige Assembler-Alternative einwerfen ;-) leo
Zappenduster schrieb: > Ich habe wohl die letzten 30 Jahre verpennt > und bin in den frühen 80gern hängengeblieben ;-) Deshalb brauchst du auch kein Linux sondern einen Colour Maximite 2 kostet keine 100€ https://geoffg.net/maximite.html https://www.youtube.com/watch?v=G3wzseh3Wh0
Programmierer schrieb: > Das ist unter aktuellen Betriebssystemen wie Windows und Linux völlig > unmöglich. Endlich mal einer mit Ahnung von der Materie. ;-)
Zappenduster schrieb: > ch, da ist mir noch eingefallen, in den 90gern hatte ich QBasic, damit > habe ich viel gemacht. Unter SCREEN 12 ging 640x480 in 16 Farben. > Seufz... Wenn C: Nimm SDL2, das abstrahiert den ganzen X-Schrott weg und man hat ein paar generische Grafikfunktionen, wenn man was grundlegendes ohne viel Ballast haben will. Ansonsten nimmt man heute gleich was mit einem Canvas, jedes GUI-Toolkit bietet sowas an und bekommt auch gleich ne GUI dazu, will man in der Regel sowieso haben. Speziell um mit nur mit Grafik rumzuschmieren ist auch processing ganz nett, das gibts für Java und für den Browser (als JS-Variante) und musst dich nicht mit den Eigenheiten einer Sprache, den Libs und anderem lästigen Schrott rumplagen. Um schnell mal was auszuprobieren ideal. Der Arduino-Entwicklungsstyle ist von Processing inspiriert worden. Und gewöhn dir mal langsam ab direkt auf der Hardware in Speicher rumzufuchteln, die Zeiten sind lange vorbei. Ansonsten nimm: qb64.net freebasic.net Das tut dann so als wärs ne VGA-Karte, nutzt aber (wahlweise) OpenGL, fühlt sich aber immer noch wie das Original an, bietet aber auch moderenere Arten mit Grafik herumzuhantieren wie OpenGL-bindings,... Oder fummel in der dosbox mit den Originalen rum, da kannst du dann weiterhin mit VGA-Paletten, Registergefrickel, Timming und so nem Mist deine Zeit verplempern.
>Ansonsten nimm: >qb64.net >freebasic.net Wenn schon: Besser PureBasic https://www.purebasic.com/german/
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.