Servus allerseits In einem anderen Beitrag ( Beitrag "QT-Designer: Felder linksbündig plazieren" ) kam es zur Aussage, dass Dialoge in ihrer Grösse nicht fix sein dürften. Ich persönlich fixiere meine Dialoge. Und hatte bis anhin noch nie irgendwelche Reklamationen erhalten. Worauf ich prompt "Die meisten Leute sind es eben gewohnt, mit schlecht designten GUIs zu arbeiten" als Antwort erhielt. Okay, war ein Smiley hinten angefügt, aber tat trozdem weh :) Nachdem mein gekraenktes Ego sich vom Ohnmachtsanfall erholt hatte :) begann ich darüber zu grübeln, ob ich all die Jahre etwas falsch gemacht hatte. Und bin der Meinung: nein. Bei meinen Dialogen gehe ich stets von einer Bildschirmgrösse von 1024 x 768 aus. Erst wenn die Form diese Grösse überschreiten muss, expandiere ich die Form entsprechend der Bildschirmgrösse, bzw, versehe sie mit vertikalen und/oder horizontalen Scrollbars. Okay, ein Argument mit Zahlen (soviele Kunden benutzen meine Programme) ist sicherlich kein Argument. Aber dasselbe Programm laeuft auf einem 14" Bildschirm genauso (aus meiner Sicht: aestetisch) wie auf einem 22" Bildschirm. Okay, ich bin von meiner Meinung nicht 100% überzeugt. Denn dann würde ich ja diese Frage nicht in die Runde werfen. So also meine Frage: Grösse fixieren oder nicht fixieren?
:
Bearbeitet durch User
Dialoge zu fixieren ist eine ganz schlechte Idee. Du setzt nämlich nicht nur eine bestimmte Monitorgröße voraus, sondern auch eine bestimmte Auflösung in dpi. Ein Dialog, der auf 1024x768 und 100dpi passabel aussieht, ist aber auf enem Monitor mit höherer Pixelzahe und 200dpi unlesbar - denn mit Sicherheit hat der Nutzer dann einen Zeichensatz, der mehr Pixel beansprucht, also müßten auch alle Widgets ein wenig größer sein. Weil aber der Dialog eine feste Größe hat, passen die Elemente nicht mehr drauf bzw überschneiden sich. Texte in Buttons werden abgehackt usw. War zu Windows95-Zeiten ein beliebter Programmiererfehler.
Dialog haben ja einen (von dir) definierten Inhalt, also kann man ihre Grösse fest vorgeben. Es macht keinerlei Sinn, wenn der Anwender den Dialog kleiner oder grösser machen kann, weil die Elemente ja dann entweder nicht mehr alle zu sehen sind oder ungenutzer Platz daneben wäre. ABER: Die Grösse sollte man nie in Pixeln fest vorgeben, sondern in Enheiten der Schriftgrösse mit der der Dialog gezeichnet wird, und dann entsprechend umrechnen. Sonst bekäme man auf hochauflösenden Bildschirmen (iPhone retina etc.) winzige nicht mal mit der Lupe erkennbare Dialoge. Auch darf man NIEMALS 1024 x 768 als Bildschirmmindestgrösse annehmen (es sei denn, man liefert die Computerbildschirme gleich mit), denn es gibt genügend Anwender, die weniger haben. Aber du baust ja Scrollbars wenn es kleiner wäre, also ist das ok. Noch besser wäre natürlich, den Inhalt auf die reale Breite umzubrechnen und nur einen vertikelen Scrollbar anzufügen.
Irgendwie habe ich das Gefühl, dass wir nicht über dasselbe reden. Nachdem, was Ihr schreibt, dürfte ja keines meiner Programme visuell korrekt daherkommen. Tut es aber. Sowohl auf 14", als auch auf 22" Bildschirmen. Reden wir tatsaechlich über dasselbe, wenn wir über "fixierte Dialoge" reden? Nachtrag: Wenn ich fixiert schreibe, meine ich, dass wenn der User mit der Mouse an die untere rechte Ecke der Form kommt, der Cursor nicht zum diagonalen Doppel-Pfeil wechselt.
:
Bearbeitet durch User
Mal anders herum gefragt: Hätte es irgendeinen Nachteil, wenn du die Dialogfenster resizable machst? Wer den Dialog nicht resizen will, muss es ja nicht tun. Solange der Dialog nur ein paar Buttons und sonstige Widgets fester größe enthält, braucht man das nicht unbedingt. Sobald der Dialog aber variable Inhalte in Form von (evtl. editierbarem) Text, Listen o.ä. enthält, bin ich schon oft froh, wenn man das Fenster einfach etwas größer machen kann, um mehr Überblick zu erhalten. Scrollbars als Ersatz sind nervig, solange der Bildschirm groß genug ist, um bei vergrößertem Dialogfenster den Inhalt auch vollständig anzuzeigen.
:
Bearbeitet durch Moderator
Angehängte Dateien:
-
dialog.png
13 KB
J. L. schrieb: > denn mit Sicherheit hat der Nutzer dann einen Zeichensatz, > der mehr Pixel beansprucht, also müßten auch alle Widgets ein wenig > größer sein. Weil aber der Dialog eine feste Größe hat, passen die > Elemente nicht mehr drauf bzw überschneiden sich. Texte in Buttons > werden abgehackt usw. > > War zu Windows95-Zeiten ein beliebter Programmiererfehler. Das ist es auch heute noch. Während bei Fernsehern und Mobiltelefonen die Display-Auflösungen stetig steigen, hat sich bei PC-Monitoren in der Hinsicht über etliche Jahre gar nichts getan. Ich glaube, daß das vor allem daran liegt, daß ein Großteil der PC-Programme einfach nicht mit höheren Auflösungen klargekommen ist und einige das bis heute nicht tun. MaWin schrieb: > Dialog haben ja einen (von dir) definierten Inhalt, also kann man ihre > Grösse fest vorgeben. Das kommt auf den Dialog an. Außerdem sind Programme heute mehrsprachig. Was in der Sprache, in der der Programmierer die Größe festlegt, passt, kann in einer anderen Sprache zu klein sein. Dabei kommt dann sowas raus wie das Beispiel im Anhang aus Windows XP. Dieser Dialog belegt ca. 20% meiner Bildschirmbreite, und dank fixer Fenstergröße darf ich dann horizontal scrollen, um den Text zu lesen und vertikal, um alle Einträge zu sehen. Könnte ich den Dialog vergrößern, würde locker alles rein passen, ohne daß man überhaupt scrollen müßte, und das ist noch ein vergleichsweise harmloses Exemplar. Bei sowas könnt ich jedesmal ausrasten. > Es macht keinerlei Sinn, wenn der Anwender den Dialog kleiner oder > grösser machen kann, weil die Elemente ja dann entweder nicht mehr alle > zu sehen sind oder ungenutzer Platz daneben wäre. Lass das doch bitte den Anwender entscheiden. Wenn er die Größe nicht ändern will, muß er das ja nicht. Ich find's immer blöd, wenn der Programmierer meint, dem Benutzt Dinge vorschreiben zu müssen, nur weil er meint, daß dieser nichts anderes zu wollen hat. Wenn man ein gescheites Toolkit hat, gibt's gar keinen Grund, eine fixe Größe zu erzwingen. Früher hat man das halt oft gemacht, weil viele Toolkits keine automatischen Layouts hatten und man somit alle Positionen selbst im Code ausrechnen mußte. Mehmet Kendi schrieb: > Irgendwie habe ich das Gefühl, dass wir nicht über dasselbe reden. > Nachdem, was Ihr schreibt, dürfte ja keines meiner Programme visuell > korrekt daherkommen. > Tut es aber. Sowohl auf 14", als auch auf 22" Bildschirmen. Es geht nicht um die Bildschirmgröße, sondern um die Auflösung. Stell doch mal einen größeren Font ein und probiere mal, wie's dann aussieht. > Reden wir tatsaechlich über dasselbe, wenn wir über "fixierte Dialoge" > reden? Ja.
Mehmet Kendi schrieb: > Irgendwie habe ich das Gefühl, dass wir nicht über dasselbe reden. > Nachdem, was Ihr schreibt, dürfte ja keines meiner Programme visuell > korrekt daherkommen. > Tut es aber. Sowohl auf 14", als auch auf 22" Bildschirmen. > Reden wir tatsaechlich über dasselbe, wenn wir über "fixierte Dialoge" > reden? > > Nachtrag: Wenn ich fixiert schreibe, meine ich, dass wenn der User mit > der Mouse an die untere rechte Ecke der Form kommt, der Cursor nicht zum > diagonalen Doppel-Pfeil wechselt. Frage: welche Auflösung (in dpi) hat denn der 22-Zöller? Noch eine Frage: Wenn Du ein Notebook nimmst, das 240dpi hat , wie sieht's dann aus? Wie sehen Dialoge aus, wenn die Sprache sich ändert, also andere (längere) Texte in den Buttons stehen? Wenn Deine Dialoge in der Größe nicht änderbar sind, wer legt die Größe fest - Du oder das Toolkit basierend auf dem Inhalt? Beim letzteren sind die Dialoge ja nicht "fix", sie werden ja dynamisch vom Programm angepasst. Trotzdem. Als Nutzer möchte ich den Dialog doch verschieben, vergrößern oder verkleinern können, z.B. um mal kurz Platz auf dem Bildschirm zu schaffen, weil ich in ein anderes Fenster sehen möchte.
Hmm, langsam verstehe ich vorauf Ihr zeigt. Das Argument "mehrsprachig" ist in der Tat stichhaltig; aber da ich nur national programmiere, faellt das bei mir nicht ins Gewicht. Auch das Beispiel dialog.png von Magnus ist einleuchtend. Aber beim Design achte ich eben, dass sowas nicht vorkommt. Bleibt noch der Punkt mit der Dpi. Darüber muss ich etwas recherchieren und nachdenken.
Feste/starre Fensterlayouts sind vom letzten Jahrhundert. Heute spricht effektiv nichts mehr dagegen, einen gescheiten Layoutmanager (wie bei QT) zu verwenden.
Ich habe jetzt mal etwas rumexperimentiert. In einer sqlite Datenbank wird Position und Grösse der Dialoge ablegt, bevor die Fenster geschlossen werden. Okay, keine grosse Sache. Rolf Magnus schrieb: > Es geht nicht um die Bildschirmgröße, sondern um die Auflösung. Stell > doch mal einen größeren Font ein und probiere mal, wie's dann aussieht. Control-Panel -> Appearance -> Display: Larger 150% Okay, sieht beschissen aus. Aber das Program wurde dadurch nicht unbenutzbar. Wo der Platz nicht ausreichte, kamen automatisch horizontale Scrollbars hinzu. Und einige Icons wurden etwas verzerrt dargestellt. Ich frage mich aber nur: wieso sollte jemand sowas tun. Sehbehinderung? <Sarkasmus> Okay, ein Argument. Nur haben wir hier in der Türkei - seit die religöse AKP an der Macht ist - einen sehr unmenschlichen Kapitalismus. Da keine Firma jemanden mit einer solchen Sehbehinderung einstellen würde, waere eine solche Implementierung für die Katz. </Sarkasmus> Aber im Prinzip habt Ihr natürlich recht. Werde in Zukunft darauf achten, Dialoge nicht mehr zu fixieren.
Mehmet Kendi schrieb: > Ich frage mich aber nur: wieso sollte jemand sowas tun. > Sehbehinderung? Man hat einen von diesen neumodischen Laptops mit 3K-Auflösung auf 15".
Nase schrieb: > Feste/starre Fensterlayouts sind vom letzten Jahrhundert. Heute spricht > effektiv nichts mehr dagegen, einen gescheiten Layoutmanager (wie bei > QT) zu verwenden. Das ist kein Argument, sondern eine inhaltslose Aussage. Da könnte ich genausogut auf meine x-tausend Benutzer hinweisen, die bis anhin keine Probleme mit meinem Design hatten und vermutlich auch nie haben werden. Tu' ich aber nicht. Weil dies auch kein Argument, sondern eine leere Aussage waere.
Programmierst du in in kleinen Fenstern die man alle Nase lang mit Scrollbars hin und herschieben muss?
J. L. schrieb: > Dialoge zu fixieren ist eine ganz schlechte Idee. Du setzt nämlich nicht > nur eine bestimmte Monitorgröße voraus, sondern auch eine bestimmte > Auflösung in dpi. ...und zudem auch, daß der Leser mindestens so gute Augen hat wie du. Was Barrierefreiheit angeht, ist es nicht so toll,alles fix zu machen. Entweder, der Anwender kann die Schriftgröße nicht verändern, bzw. die Systemeinstellungen werden ignoriert. Oder es verschwindet was hinterm Rand. Schon mal nen Text gelesen, wo man für jede Zeile immer wieder links-rechts rollen muß?
Insbesondere bei Rente mit 67 kann es sein dass in den letzten Arbeitsjahre die Schriftgröße ansteigt.
Also wenn man das tut dann so das alle Dialogteile gleichmäßig skalieren. D.h. nicht nur die Schrift wird größer oder kleiner, sondern auch alle Buttons, Scrollbars usw. usf. Nehmen wir mal an Du hast einen Dialog für 1024x768 auf 300x200 designed und Text, Buttons usw. passen schön hinein und sind bei 1024x768 gut les- und bedienbar. Nun hat Oberfinanzhai "Habenalleswasgibt" einen 7680×4320 Monitor um seine "Lieblingstierfilme" in 8k sehen zu können, mit allen einzelnen Haaren vom Fell. Rechne selber aus welches Fernglas der braucht um Deinen Dialog überhaupt sinnvoll als selbigen erkennen zu können ? Wenn man es "automatisch" machen will holt man sich zuerst die aktuelle Auflösung und baut den Dialog danach so zusammen das man bei 640x480 genauso viel vom Bildschirm verbraucht wie bei 7680×4320. Ob man danach noch skalieren durch den Anwender zuläßt ist geschmackssache ;-)
Mehmet Kendi schrieb: > Ich habe jetzt mal etwas rumexperimentiert. In einer sqlite Datenbank > wird Position und Grösse der Dialoge ablegt, bevor die Fenster > geschlossen werden. > Okay, keine grosse Sache. Eine SQL-Datenbank ist aber etwas übertrieben. Ich würde da im Konstruktor des Dialogs sowas machen:
1 | QRect geom = QSettings().value("MyDialog/Geometry").toRect()); |
2 | if (geom.isValid()) |
3 | setGeometry(geom); |
und im Destruktor dann:
1 | QSettings().setValue("MyDialog/Geometry", geometry()); |
"MyDialog" halt ersetzt durch den Namen des Dialogs. Der Code ist so nicht getestet, müßte aber in der Art funktionieren, wenn man vorher in seiner QCoreApplication die Organization und den ApplicationName gesetzt hat. Über QSettings kann man sich auch relativ einfach das letzte Verzeichnis eines Filedialogs merken. Hier ein Ausschnitt aus einem Programm, wo ich das tue:
1 | QSettings settings; |
2 | QString lastDir = settings.value("lastDir", QDir::homePath()).toString(); |
3 | qDebug() << "Last dir = " << lastDir; |
4 | QString dir; |
5 | dir = QFileDialog::getExistingDirectory(this, tr("Open Directory"), lastDir); |
6 | if (!dir.isEmpty()) |
7 | {
|
8 | settings.setValue("lastDir", dir); |
9 | qDebug() << "New dir = " << dir; |
10 | slotOpenDir(dir); |
11 | }
|
> Rolf Magnus schrieb: >> Es geht nicht um die Bildschirmgröße, sondern um die Auflösung. Stell >> doch mal einen größeren Font ein und probiere mal, wie's dann aussieht. > > Control-Panel -> Appearance -> Display: Larger 150% > Okay, sieht beschissen aus. Aber das Program wurde dadurch nicht > unbenutzbar. Wo der Platz nicht ausreichte, kamen automatisch > horizontale Scrollbars hinzu. Und einige Icons wurden etwas verzerrt > dargestellt. > > Ich frage mich aber nur: wieso sollte jemand sowas tun. > Sehbehinderung? Es gibt heute auch 4k-Monitore, und es gibt 13"-Monitore mit 2880*1800 Pixeln. Auf denen will man aber vielleicht auch ohne Lupe arbeiten. Genau das war ja mein Punkt: Ich warte schon lange auf höherauflösenden Monitore, und diese hätte es schon viel früher geben können, aber da sehr viel Software nicht damit klar kommt, hätte die keiner gekauft. Nur deshalb hat heute der Standard-24"-Monitor weniger Auflösung als so manches 7"-Tablet. Mehmet Kendi schrieb: > Nase schrieb: >> Feste/starre Fensterlayouts sind vom letzten Jahrhundert. Heute spricht >> effektiv nichts mehr dagegen, einen gescheiten Layoutmanager (wie bei >> QT) zu verwenden. > > Das ist kein Argument, sondern eine inhaltslose Aussage. Da könnte ich > genausogut auf meine x-tausend Benutzer hinweisen, die bis anhin keine > Probleme mit meinem Design hatten und vermutlich auch nie haben werden. > Tu' ich aber nicht. Weil dies auch kein Argument, sondern eine leere > Aussage waere. Du scheinst halt von einem anderen Ausgangszustand auszugehen als wir. Für mich ist ein Dialog erstmal resizable, wie es auch von der Qt vorgesehen ist. Wenn ich keinen guten Grund habe, das zu ändern, tue ich das auch nicht. Du erzwingst dagegen "per Default" erstmal eine feste Größe und willst davon nur abweichen, wenn du einen Grund dazu findest. Einen in der Größe änderbaren Dialog zu bauen, ist aber kaum mehr Aufwand als einen mit fester Größe, zumindest bei Qt. Es gibt eigentlich keinen Nachteil, wenn die Größe änderbar ist, aber es gibt potenzielle Nachteile, wenn sie fix ist.
Mehmet Kendi schrieb: > Nase schrieb: >> Feste/starre Fensterlayouts sind vom letzten Jahrhundert. Heute spricht >> effektiv nichts mehr dagegen, einen gescheiten Layoutmanager (wie bei >> QT) zu verwenden. > > Das ist kein Argument, sondern eine inhaltslose Aussage. Da könnte ich > genausogut auf meine x-tausend Benutzer hinweisen, die bis anhin keine > Probleme mit meinem Design hatten und vermutlich auch nie haben werden. > Tu' ich aber nicht. Weil dies auch kein Argument, sondern eine leere > Aussage waere. Typischer Fall von völlig aneinander vorbeireden aus Mangel an Kenntnissen. Unter Windows gibt es garkeine "fixierten" Dialoge wie bei Android oder HTML, die Dialoge werden schon immer in "Dialogeinheiten" definiert, und deren Grösse hängt von der Schriftgrösse ab, ändert man die, so ändern auch die Dialoge mitsamt Buttons usw. ihre Grösse. Daher funktioniert Windows ziemlich zufriedenstellend auch ohne grossen Programmieraufwand für Resizing. Georg
Rolf Magnus schrieb: > QRect geom = QSettings().value("MyDialog/Geometry").toRect()); > if (geom.isValid()) > setGeometry(geom); Wenn die Geometrie-Daten beim Speichern auf dem Zweit-Monitor lagen und man nur mit dem Notebook unterwegs ist, dann reicht das noch nicht aus. Wie geht man bei einem virtuellen Bildschirm mit Koordinaten um, die nicht im aktuell dargestellten Bereich liegen? Wie ist das Verhalten, wenn die Applikation nicht im aktiven Workspace läuft? Fragen, die sich aus der Beobachtung existierender (auch kommerzieller) Software ergeben. :-/
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.