Von Verwende selber Qt am Mi, 24. Mai 2017 um 12:17 #
GTK+ Sammlung von Elementen für grafische Benutzerschnittstellen (GUI-Toolkit). Die Elemente werden mit der Vektorgrafik-Bibliothek Cairo gezeichnet, das Layout von internationalisiertem Text und Schrift übernimmt hier Pango. Als Schnittstelle zur Barrierefreiheit wird ATK (Accessibility-Toolkit) verwendet.
Was ich bei der ganzen "Anpassung an hochauflösende Displays" Sache nie verstanden habe, ist warum das von "low-level" Software wie z.B. Gnome gelöst werden muss. Liegt der Fehler nicht bei den Autoren von Dokumenten bzw. GUI Software? Ich meine es ist doch klar, dass man als Größeneinheit (für Sachen wie Text oder einen Button) nicht Pixel nimmt. Bzw. nur nachdem man sich einen Umrechnungsfaktor von z.B. cm oder besser noch em geholt hat (vom OS, GUI Toolkit, Browser, Nutzer, …). Es ist doch klar, dass z.B. 10px bei dem einen Nutzer 10mm und bei dem anderen nur 1mm sind. Ich denke das ist (oder hätte sein sollen?) schon immer das übliche Vorgehen. Auch vor 20 Jahren gab es ja schon manche Bildschirme mit 800x600 Auflösung und manche mit 1024x768; und das auch verteilt auf Displays zwischen sagen wir 10 und 20 Zoll.
Nur weil es damals mal üblich war ist das keine Entschuldigung für fehlendes Vorstellungsvermögen beim Programmieren einer GUI und erst recht nicht für eine eventuelle Weigerung dies wenigstens nachträglich zu korrigieren.
Selbst bei einem Script darf man nicht von irgendwelchen Annahmen ausgehen und muss alles doppelt oder besser dreifach überprüfen bevor wirklich irgendetwas gemacht wird, also wird es bei höheren Sachen unter Garantie nicht anders sein.
Von Verwende selber Qt am Mi, 24. Mai 2017 um 13:42 #
Gehen wir mal von einer "Desktop Anwendung" aus.
Wenn die mit den alten Annahmen von 72 DPI auf dem Bildschirm optimal läuft, dann muss bei der Rasterung auf einem neuen Gerät mit höherer Auflösung nur 1 Faktor ZOOM berücksichtigt werden.
Und das macht am besten das GUI Toolkit, weil dann alle Anwendungen davon profitieren.
Finde auch das dies eigentlich die Devs der Programme lösen sollten den alles andere ist gebastel, wie man unter Windows (z.B. Checkboxen die so absurd klein sind das man sie selbst mit der Maus kaum noch trifft) nur all zu oft sehen kann.
Leider sind GTK und Qt nicht von Anfang daran ausgelegt worden, im Gegensatz z. B. zum Toolkit bei Android. Auch ist das Problem, dass auf dem Desktop die Auflösung relativ zur Bildschirmgröße ziemlich niedrig ist im Vergleich zu Smartphones. Daher fallen Rundungen sehr schnell auf und man benutzt möglichst Pixel-genaue Angaben: Ob eine Linie 2 Pixel oder 2,5 Pixel breit ist merkt man, ob 8 Pixel oder 8,5 Pixel eher kaum.
Dass viele Layouts pixel-genau sind, ist mir ehrlich gesagt neu (aber ich bin auch definitiv kein Experte). Was Linien angeht vielleicht ja, obwohl da wie bereits erwähnt worden ist, antialiasing helfen kann. Aber wenn ich an Sachen denke wie z.B. die initiale Breite der Lesenzeichen-Seitenleiste in Firefox, die sollte ein Entwickler doch nicht einfach auf 100px festlegen nur weil das beim Test auf seinem Bildschirm ganz gut aussieht. Da sollte die API eines GUI Toolkist doch entweder die Möglichkeit bieten bei Größenangaben Maßzahl und Maßeinheit anzugeben (im Sinne von `myWidget.width = "42em"`) oder eben per expliziter Umrechnung (`myWidget.width = 42 * emToPx`). 1em ist übrigens die Breite des Buchstaben "m". Z.B. bzgl. der eingestellten Standardschrift. Eine entsprechende Konfiguration erlaubt eigentlich jedes OS (oder DE) und die kann ja auch vom Nutzer angepasst werden (z.B. hinsichtlich der DPI des Displays oder des Abstands vom Display oder der Sehkraft …). @Lord Eine entsprechende `getEmToPx` Funktion sollte selbstverständlich von dem plattformunabhängigen Toolkit, das man benutzt, bereit gestellt und nicht selbst entwickelt werden. Gut wäre es natürlich auch wenn man relative Größenangaben (in % des Eltern-Widget o.Ä.) machen kann.
Jo du hast nix verstanden, daher solltest du auch keine Ratschläge geben.
Es ist kompletter Bullshit, wenn sich ein Programmierer um irgendwelche Umrechnungen/Anordnungen und sonstiges kümmern müsste, warum nicht gleich das Ganze Betriebsystem nochmal neu entwickeln, sowas sind Basis Features, die man zentral in nem Windows Manager implementiert. Sonst müsste jede App das Rad neu erfinden.
Es ist aber ganz natürlich, dass man vor 10 Jahren nicht schon den Grundstein für 4K Displays gelegt hat, es sei denn man hat wie Apple eine emeinsame HW/SW roadmap.
Jo Alter, du hast nix verstanden. Daher solltest du auch keine Ratschläge geben. Windows ist der Name eines Betriebssystems von Microsoft. Ein Window Manager malt Rahmen, Titelleisten und andere Dekorationen an Fenster. Der Inhalt im Fenster hat nichts mit dem Window Manager zu tun.
GTK+
Sammlung von Elementen für grafische Benutzerschnittstellen (GUI-Toolkit). Die Elemente werden mit der Vektorgrafik-Bibliothek Cairo gezeichnet, das Layout von internationalisiertem Text und Schrift übernimmt hier Pango. Als Schnittstelle zur Barrierefreiheit wird ATK (Accessibility-Toolkit) verwendet.
Siehe: https://de.wikipedia.org/wiki/Gnome
Wo liegt dann das Problem, bei Skalierung?
Dass an vielen Stellen noch Ganzzahlen benötigt werden und wenn man rundet, der Rundungsfehler sich fortpflanzt, was dann zu Anzeigefehlern führt.
Was ich bei der ganzen "Anpassung an hochauflösende Displays" Sache nie verstanden habe, ist warum das von "low-level" Software wie z.B. Gnome gelöst werden muss. Liegt der Fehler nicht bei den Autoren von Dokumenten bzw. GUI Software? Ich meine es ist doch klar, dass man als Größeneinheit (für Sachen wie Text oder einen Button) nicht Pixel nimmt. Bzw. nur nachdem man sich einen Umrechnungsfaktor von z.B. cm oder besser noch em geholt hat (vom OS, GUI Toolkit, Browser, Nutzer, …). Es ist doch klar, dass z.B. 10px bei dem einen Nutzer 10mm und bei dem anderen nur 1mm sind. Ich denke das ist (oder hätte sein sollen?) schon immer das übliche Vorgehen. Auch vor 20 Jahren gab es ja schon manche Bildschirme mit 800x600 Auflösung und manche mit 1024x768; und das auch verteilt auf Displays zwischen sagen wir 10 und 20 Zoll.
Es kommt auf die DPI (dots per inch an).
1 inch = 2.54 cm
Bei Bildschirmen war lange Zeit 72 DPI üblich.
Siehe z.B. Maßeinheiten bei CSS
https://www.w3.org/Style/Examples/007/units.de.html
Nur weil es damals mal üblich war ist das keine Entschuldigung für fehlendes Vorstellungsvermögen beim Programmieren einer GUI und erst recht nicht für eine eventuelle Weigerung dies wenigstens nachträglich zu korrigieren.
Mensch, wenn die dich und deine genialen Problemlösungen damals schon gekannt hätten!
Was wäre das für eine ideale Technikwelt heute.
Selbst bei einem Script darf man nicht von irgendwelchen Annahmen ausgehen und muss alles doppelt oder besser dreifach überprüfen bevor wirklich irgendetwas gemacht wird, also wird es bei höheren Sachen unter Garantie nicht anders sein.
Gehen wir mal von einer "Desktop Anwendung" aus.
Wenn die mit den alten Annahmen von 72 DPI auf dem Bildschirm optimal läuft, dann muss bei der Rasterung auf einem neuen Gerät mit höherer Auflösung nur 1 Faktor ZOOM berücksichtigt werden.
Und das macht am besten das GUI Toolkit,
weil dann alle Anwendungen davon profitieren.
Das ZOOM habe ich aber auch schon selber in Qt Anwendungen eingebaut.
Mit CTRL+MouseWheel lässt sich die GUI der Anwendung zoomen.
Finde auch das dies eigentlich die Devs der Programme lösen sollten den alles andere ist gebastel, wie man unter Windows (z.B. Checkboxen die so absurd klein sind das man sie selbst mit der Maus kaum noch trifft) nur all zu oft sehen kann.
Leider sind GTK und Qt nicht von Anfang daran ausgelegt worden, im Gegensatz z. B. zum Toolkit bei Android. Auch ist das Problem, dass auf dem Desktop die Auflösung relativ zur Bildschirmgröße ziemlich niedrig ist im Vergleich zu Smartphones. Daher fallen Rundungen sehr schnell auf und man benutzt möglichst Pixel-genaue Angaben: Ob eine Linie 2 Pixel oder 2,5 Pixel breit ist merkt man, ob 8 Pixel oder 8,5 Pixel eher kaum.
Bildschirmlayouts sind oft Pixelgenau designt.
Wenn du das um 1.4 x skalierst, dann sind z.B manche Linien 1px und manche 2 px breit, je nach Rundung.
Solche und viele andere Darstellungsfehler, die da so enstehen, sammelt man unter dem Begriff "Aliasing".
Mit Antialiasing kann man manche Probleme entschärfen, aber viele bleiben.
Aber das schaffst du ja mit links.
Schreib doch mal ein Paper dazu und veröffentliche es.
Dass viele Layouts pixel-genau sind, ist mir ehrlich gesagt neu (aber ich bin auch definitiv kein Experte). Was Linien angeht vielleicht ja, obwohl da wie bereits erwähnt worden ist, antialiasing helfen kann. Aber wenn ich an Sachen denke wie z.B. die initiale Breite der Lesenzeichen-Seitenleiste in Firefox, die sollte ein Entwickler doch nicht einfach auf 100px festlegen nur weil das beim Test auf seinem Bildschirm ganz gut aussieht. Da sollte die API eines GUI Toolkist doch entweder die Möglichkeit bieten bei Größenangaben Maßzahl und Maßeinheit anzugeben (im Sinne von `myWidget.width = "42em"`) oder eben per expliziter Umrechnung (`myWidget.width = 42 * emToPx`).
1em ist übrigens die Breite des Buchstaben "m". Z.B. bzgl. der eingestellten Standardschrift. Eine entsprechende Konfiguration erlaubt eigentlich jedes OS (oder DE) und die kann ja auch vom Nutzer angepasst werden (z.B. hinsichtlich der DPI des Displays oder des Abstands vom Display oder der Sehkraft …).
@Lord Eine entsprechende `getEmToPx` Funktion sollte selbstverständlich von dem plattformunabhängigen Toolkit, das man benutzt, bereit gestellt und nicht selbst entwickelt werden.
Gut wäre es natürlich auch wenn man relative Größenangaben (in % des Eltern-Widget o.Ä.) machen kann.
Jo du hast nix verstanden, daher solltest du auch keine Ratschläge geben.
Es ist kompletter Bullshit, wenn sich ein Programmierer um irgendwelche Umrechnungen/Anordnungen und sonstiges kümmern müsste, warum nicht gleich das Ganze Betriebsystem nochmal neu entwickeln, sowas sind Basis Features, die man zentral in nem Windows Manager implementiert. Sonst müsste jede App das Rad neu erfinden.
Es ist aber ganz natürlich, dass man vor 10 Jahren nicht schon den Grundstein für 4K Displays gelegt hat, es sei denn man hat wie Apple eine emeinsame HW/SW roadmap.
Jo Alter, du hast nix verstanden. Daher solltest du auch keine Ratschläge geben. Windows ist der Name eines Betriebssystems von Microsoft. Ein Window Manager malt Rahmen, Titelleisten und andere Dekorationen an Fenster. Der Inhalt im Fenster hat nichts mit dem Window Manager zu tun.
Ich denke mal er meint auch Compositoren. WindowManager hat sich eben bei vielen Leuten noch gehalten, wo eigentlich Compositoren gemeint sind.
Dann stimmt das nämlich auch wieder (:
Leider wird es auf absehbare Zeit HiDPI-Support nur für Anwendungen, die mindestens GTK 3.0 oder Qt 5.6 verwenden, geben
Für GTK2 und Qt4 sowieso nie, aber auch nicht für Java-, wxwidgets-, Tk-, FLTK-...Anwendungen.