Alles wird unscharf

Fast auf den Tag genau vor 1 Jahr habe ich in diesem Eintrag vom „unscharfen“ Text in WPF-basierten Applikationen geschrieben. Seither gehört das Wort unscharf zu den absoluten Top-Such-Begriffen, mit denen dieses Blog gefunden wird, was darauf schliessen lässt, dass die Sache einige Leute beschäftigt, wenn nicht sogar nervt.

Es sieht so aus, als wäre Microsoft unterwegs zu einer überraschenden Lösung für dieses Problem, die man als Bestandteil von Windows Vista und Windows 7 betrachten kann: Man macht einfach Text generell unscharf…

Windows 7 verwendet ClearType für Text per Default systemweit, mit nur wenigen Ausnahmen wie etwa der Shell, was eben zur angesprochenen leichten Unschärfe führt. Allerdings muss man sagen, dass Microsoft ClearType um einiges verbessert hat und auch ein eigenes Tuning-Tool dafür mitliefert, damit man auf seiner Hardware das Optimum betreffend Darstellung herausholen kann.

Es gibt in Windows 7 sogar eine etwas versteckte Option, mit der man ClearType ausschalten kann, die z.B. hier (für das englische Windows 7) beschrieben ist, aber so ganz will das nicht klappen: Vieles wird nach dem Ausschalten der Option Smooth edges of screen fonts zwar wieder pixel-scharf, aber Dinge wie die Anzeige der Uhrzeit, Tooltips oder gewisse Kolonnen-Überschriften im Explorer bleiben völlig unbeeindruckt bei der Verwendung von ClearType, und WPF-Applikationen wie etwa das neue Visual Studio 2010 sowieso.

Ich habe mich gefragt, ob die weitgehende Verwendung von ClearType auch damit zusammenhängt, dass Dinge wie der Explorer von Windows 7 als WPF-Applikationen neu geschrieben worden sind. Es ist häufig schwierig, Informationen darüber zu finden, wie genau Microsoft Windows-Interna implementiert; so auch in diesem Fall. Es scheint allerdings unter interessierten Leuten einen gewissen Konsens darüber zu geben, dass das Windows-7-GUI nicht in WPF implementiert sein kann, wie z.B. in einem Posting im Rahmen dieser Diskussion ausgeführt. WPF heisst managed code, der einen gewissen Geschwindigkeitsverlust mit sich bringen kann und für das Framework einiges an Speicher benötigt – beides Dinge, die Microsoft vermeiden musste, um Windows 7 gegenüber Vista deutlich abzuspecken und schneller zu machen, damit es z.B. Netbook-tauglich wird.

Ich denke nicht, dass man das als Votum gegen WPF deuten sollte, im Stile von „Ja, wenn nicht mal Microsoft selbst Dinge mit Hilfe von WPF implementiert…“. Normale Windows-Business-Applikationen sind nun mal nicht dasselbe wie Kern-Bestandteile von Betriebssystemen, wo ganz andere Bedingungen und Anforderungen die Wahl der Mittel erheblich einschränken.

Veröffentlicht in Keine Kategorie. Schlagwörter: , . 3 Comments »

Dynamische Forms

In Word 2003 gibt es eine Dialogbox Dokumentvorlagen und Add-Ins, die noch nicht mitbekommen hat, dass Bildschirme heute mehr Auflösung bieten als VGA von Anno Domini 1987:

Dialogbox in Word 2003

Dialogbox in Word 2003

So kommt es dann zum hier gezeigten Witz des „vollständigen Pfads“, der je nach Pfad eben gerade nicht vollständig angezeigt wird, weil schlicht der Platz dazu fehlt in der Breite der Dialogbox:

Vollständiger Pfad?

Vollständiger Pfad?

Auch wenn Word 2007 in dieser Hinsicht unterdessen dazugelernt hat, sehe ich heute mit Windows bzw. mit Windows-Programmen ein grosses Problem bei Forms aller Art, deren Grössen fix sind, mit recht kleinen Grössen notabene, um eben auch mit niedrigen Auflösungen klarzukommen. Ich schätze, dass selbst unter modernen Programmen nur etwa die Hälfte über Forms verfügt, deren Grösse man ändern kann und bei denen sich die Controls intelligent an eine neue Grösse anpassen.

Eine Zeit lang sah es ja so aus, als würde sich das Problem entschärfen, weil man als Programmierer bzw. als Designer von Forms im Laufe der Jahre von stetig grösseren Bildschirmen bei den Anwendern ausgehen durfte. So war es z.B. für die Megos sehr hilfreich, dass der Kanton Aargau um 2000 herum dafür sorgte, dass in allen Steuerämtern des Kantons Bildschirme mit mindestens 1024 mal 768 Pixeln zur Verfügung standen, so dass wir die Forms der Applikation VERANA (wie z.B. diese hier) mit dieser Annahme vergleichsweise grosszügig gestalten konnten, und deshalb irgendwelche komplexe Dynamik-Eigenschaften kein Thema waren.

Aber in letzter Zeit scheint sich das Problem wieder zu verschärfen, weil die Vielfalt unterschiedlicher Bildschirmgrössen zunimmt: Wohl ist der Trend zu grösseren Monitoren bei „normalen“ stationären PCs ungebrochen, aber mehr und mehr Leute arbeiten mit Notebooks, wo den Auflösungen natürliche Grenzen gesetzt sind. Günstige Netbooks kommen zudem zum Teil mit Auflösungen daher, die man schon fast als endgültig überwunden betrachtet hatte, und wer weiss, vielleicht gibt es bald für viele Applikationen die neue Anforderung, sie müssten auch auf Smartphones bedienbar sein, mit der erwähnten VGA-Auflösung aus der PC-Steinzeit!

Für mich stellt sich deshalb die Frage nach dynamischen Forms stärker denn je, was mich auch zu diesem Blog-Eintrag bewogen hat.

Es gibt in .NET bei den Windows Forms einige Unterstützung, die man als Programmierer nutzen kann, wenn man seine Forms „dynamisch“ betreffend Grösse machen will. Sie wissen, was ich meine: Eigenschaften wie Anchor, Dock und AutoSize bei Controls, und Container Controls wie z.B. das FlowLayoutPanel, welche ihre Kinder nach bestimmten Regeln neu anordnen können, wenn ihre Grösse ändert. Aber insgesamt würde ich sagen, dass man damit nicht allzu weit kommt, wenn Forms ein wenig komplexer werden.

Natürlich sind die Windows-Forms-Klassen flexibel genug, dass ich selber etwas programmieren kann, damit meine Forms dynamischer werden. Aber es ist doch eben gerade der Sinn eines Frameworks wie .NET, dass nicht jedermann ein so grundsätzliches Problem, mit dem man immer und überall konfrontiert ist, stets wieder neu selber lösen muss!

Als Microsoft begannt, WPF als ernstzunehmende Alternative zu Windows Forms zu positionieren, war ich deshalb sehr gespannt, ob sich die Firma in Bezug auf dynamische Forms etwas hat einfallen lassen, das deutlich über den Stand des mittlerweile 10 Jahre alten VB6 hinausgeht. So wie es aussieht, ist WPF in dieser Hinsicht eine Enttäuschung.

Wie sähe denn eine gute Standard-Lösung für dynamische Forms aus? Ich kann auch keine solche aus dem Hut zaubern, aber mir gehen Gedanken durch den Kopf, die auf einen beschreibenden Ansatz hinauslaufen. Wie wäre es, wenn man bei einem Control Bedingungen formulieren könnte, wie etwa die folgenden: „Control X in Höhe und Breite wachsen lassen, wenn die umgebenden Controls sich verschieben und das zulassen, aber nur bis zu einer Maximalbreite n, und auf alle Fälle nicht breiter als Control Y. Wenn sich unter Control Z mindestens m Millimeter Platz ergeben, dann Control X dorthin umplatzieren und an die Breite von Control Z angleichen.“

Interessant kann natürlich auch sein, was andere Leute machen, denn schliesslich bietet nicht nur Microsoft Werkzeuge an, mit denen man Forms designen kann. Insbesondere Qt scheint mir dabei einen Blick wert zu sein, weil Qt als Cross-Plattform-System von je her stärker als .NET mit Dingen wie unterschiedlichen System-Fonts und anders gezeichneten Controls konfrontiert war und damit klarkommen musste. Zudem kommen gerade jetzt zu den unterstützten Plattformen S60 für Smartphones und Maemo für Nokias „Surf Tabletts“ mit den erwähnten kleinen Auflösungen hinzu.

Ich habe erst begonnen, mich in Qt einzuarbeiten, um mich inspirieren zu lassen bei meiner Suche auf einer Lösung für dynamische Forms, aber etwas ist mir auf Anhieb ins Auge gestochen: die Spacer Controls, die man zwischen andere Controls setzen kann, die dort wie Federn wirken und die Controls soweit schieben, wie sie können:

Spacer Controls in Qt

Spacer Controls in Qt

Vielleicht bringt das gegenüber Docking plus Anchoring nur wenig mehr an grundsätzlich neuen Möglichkeiten, aber mir scheinen diese „Federn“ und ihr Verhalten etwas zu sein, mit dem ich intuitiv sofort klarkomme – für mich eine Eigenschaft eines wirklich guten Ansatzes.

Veröffentlicht in Keine Kategorie. Schlagwörter: , , . Leave a Comment »

Und wieder mal TechDays

Etwas über ein Jahr ist es her, seit ich mit einem Eintrag über die Microsoft TechDays 2008 diesen Blog eröffnen durfte. Letzte Woche war ich nun an den TechDays 2009, dieses Mal im Kursaal in Bern.

Es war eine gut besuchte, professionell durchgeführte und solide Veranstaltung. Wie schon letztes Jahr waren es für mich gut investierte 2 Tage, um zu erspüren, wo die Reise hingeht mit Microsoft und den Technologien dieser Firma.

Die für die Megos vielleicht wichtigste Information, die ich mitgenommen habe: WPF ist jetzt einsatzfähig. Dies wurde klar anhand der Preisverleihung für den .NET Swiss Innovation Award, wo eine WPF- und 2 Silverlight-Applikationen prämiert worden sind – alle 3 nicht-triviale, real existierende Applikationen, offenbar reif für den produktiven Einsatz. (Ein paar Details zum Award und den Gewinnern findet man in einem Infoweek-Artikle hier.) Auch der Stand von WPF plus entsprechender Tools ist mittlerweile um Längen besser als noch vor zwei Jahren oder so, wo Microsoft vorschlug, WPF-Applikationen ohne ein DataGrid-Control und ohne IntelliSense für XAML zu entwickeln…

Eine weitere interessante, in einem gut gemachten Vortrag präsentierte Sache sind die Parallel Extensions, mit deren Hilfe man für seine Programme unter .NET 4.0 auf relativ einfache Weise mehrere Cores bzw. Prozessoren wird nutzen können. Zunächst schien mir die Sache etwas überspitzt formuliert ein wenig paradox: Da baut man in der Form des .NET-Frameworks zuerst erst ein System, das mit seinem Pseudocode-basierten Ansatz, Garbage Collecting, aufwendigen Laufzeit-Informationen für Reflection usw. ziemlich gut geeignet ist, um Prozessorleistung abzufackeln, und dann geht man hin und baut eine Erweiterung, um das sogar noch mit mehr als einem Core gleichzeitig zu tun.

Aber es macht schon einen gewissen Sinn: Dank JIT-Compilierung und mächtigen Prozessoren spielt der .NET-Overhead mit der Zeit eine immer kleinere Rolle, aber wie man die laufend grösser werdende Zahl an Cores einfach und sinnvoll nutzen kann, wird wohl eine der grossen Fragen der Zukunft sein, und zwar eine, die sich als ziemlich harte Nuss erweisen dürfte.

Zudem sieht man, dass es auch klare Vorteile hat, sich mit dem .NET Framework auf einer relativ hohen Abstraktions-Ebene bewegen zu können: Microsoft hat es in der Hand, seine .NET-Sprachen geeignet um neue Sprachkonstrukte für paralleles Programmieren zu erweitern, und das .NET Framework ist ein geeignetes System, um möglichst viele der „schmutzigen“ Details vom Entwickler fernzuhalten und gewissermassen „hinter den Kulissen zu verstecken“.

Mehr zu diesem Thema find man auf der MSDN-Website hier.

Wie letztes Jahr besuchte ich mit grossem Genuss zwei Vorträge von Sascha P. Corti. Microsoft Schweiz soll gut Acht geben auf diesen Mann, den sollten sie unbedingt behalten.

Der für mich ganz persönlich absurdeste Moment dieser TechDays war, als stolz die Out of Browser genannte neue Fähigkeit der kommenden Version 3 von Silverlight präsentiert wurde: Damit ist es möglich, entsprechend vorbereitete Silverlight-3-Applikationen lokal zu installieren und dann komplett ausserhalb des Browsers laufen zu lassen. (Technische Details findet man z.B. hier).

Ohne Zweifel technisch gesehen eine beeindruckende Leistung, an der die Jungs und Mädels in Redmond wohl hart gearbeitet haben, um sie zu vollbringen. Aber warum fand ich das in gewisser Weise absurd? Lassen Sie es mich mit den Worten eines hypothetischen, fanatischen Web-2.0-Fans einmal so formulieren: „Wow! Ich dachte immer, man braucht einen Browser, um Applikationen laufen zu lassen. Jetzt geht das ja sogar ohne Browser!“. Ja, ja, wer hätte das gedacht, Applikationen, die lokal auf einem PC laufen.

Veröffentlicht in Keine Kategorie. Schlagwörter: , , . 1 Comment »

Die Geschichte vom unscharfen Text

Windows Presentation Foundation, kurz WPF, ist eine relativ neue Technologie von Microsoft, um für .NET-Programme grafisch anspruchsvolle Benutzeroberflächen zu bauen. Ein wie ich finde sehr gelungenes Beispiel einer mit Hilfe von WPF erstellten kommerziellen Applikation (also etwas in der Art, wie die Megos auch Software anbietet), findet man hier.

Es gibt bei WPF allerdings ein Problem, und je nach dem, wen man fragt, sogar ein ziemlich gewichtiges: WPF verwendet für sämtliche Textausgaben Anti-Aliasing, mit dem Resultat, dass Text mehr oder weniger unscharf wird, je nach Monitor, Bildschirmauflösung, Schrift und dem Sehvermögen des Betrachters. Ich habe hier zwei WPF-Buttons mit ihren Beschriftungen in fast unfairer Weise vergrössert, damit man das Phänomen in seiner ganzen Pracht sieht (in Originalgrösse sehen die Buttons brauchbar aus):

WPF Anti-Aliasing

Ein weiteres Beispiel findet man hier.

Anti-Aliasing bei Textausgabe muss nicht schlecht sein, und schon seit einiger Zeit leistet die ClearType-Fonttechnologie auf Windows XP z.B. auf gewissen Notebook-Displays gute Dienste. Aber: Man kann es bei WPF nicht ausschalten, auch in der neuesten Framework-Version 3.5 nicht, und es ist eine von ClearType unabhängige, unterschiedliche Implementation, die offenbar nicht immer gleich gut ist.

Wie man dieser Diskussion in einem MSDN-Forum entnehmen kann, bitten gewisse Entwickler Microsoft nun schon seit über 2 Jahren inständig darum, man möge doch einen Schalter einführen, um die Sache abzuschalten. Passiert ist offenbar in der ganzen Zeit – ausser einigen Erklärungsversuchen von Microsoft und Zusicherungen, man nähme das Problem ernst – nichts.

Es handelt sich um eine Sache, die vielschichtiger ist, als man nach dem ersten Blick meint. Die in der WPF verwendete Technologie ermöglicht es, Buchstaben quasi genauer als nur auf Pixel genau zu positionieren, und das kann wichtig sein bei dynamischen Layout- und Grössenänderungen, wie sie WPF unterstützen möchte.

Man kann auch relativ schnell mit einem Argument von Microsoft einig gehen, dass Anti-Aliasing auf Monitoren mit hoher Pixeldichte (Anzahl Pixel pro Distanz), also z.B. nicht mit den üblichen 96 Pixels pro Inch, sondern 200 oder noch mehr, wunderbar aussieht.

Man könnte sich trotzdem relativ einfach auf den Standpunkt stellen, dass etwaige „Nebenwirkungen“ des Abschaltens des Anti-Aliasing voll auf den Schultern des Programmierers lasten, welcher abschaltet, und ich denke, die Leute in der erwähnten Diskussion wären damit auch sofort einverstanden. Trotzdem hatte Microsoft bisher kein Einsehen.

Solche Geschichten faszinieren mich oft, weil ich mich unweigerlich frage, was wohl jeweils die Geschichte hinter der Geschichte ist. Ich spekuliere gerne über die „Wahrheit“, die oft ziemlich wenig mit Technik und ziemlich viel mit Psychologie zu tun haben dürfte. Es muss fast mehr dran sein als einfach nur ein „Informatik-Problem“, sonst wäre die Sache schon längst ausgestanden.

Darf ich also mal ein bisschen spekulieren, und ein paar Verschwörungstheorien über den nach wie vor unscharfen WPF-Text in die Welt setzen? (Und es sind Spekulationen, ich weiss nicht mehr als Sie!)

  • Irgend ein hohes Tier bei Microsoft ist Fan von Anti-Aliasing, will von Kritik einfach nichts wissen und ist so mächtig, dass er oder sie nicht überstimmt werden kann.
  • Microsoft möchte Druck ausüben auf die Hersteller von LCD-Panels, damit diese tatsächlich dazu übergehen, in Richtung hoher Pixeldichten zu entwickeln, was sie im Moment eher nicht tun – die Displays werden meistens einfach nur grösser.
  • Irgend jemand bei Microsoft mit viel Einfluss und Reputation hat sich am Anfang dermassen stark gemacht für Anti-Aliasing, dass er oder sie jetzt unmöglich eine Fehleinschätzung zugeben kann.
  • Das ungeliebte Anti-Aliasing bleibt drin sozusagen als Bestrafung für jemanden, der es zu verantworten hat. (Sobald der oder die „weggemobbt“ ist, kommt der geforderte Aus-Schalter.)
  • Microsoft spekuliert, auf die Entwickler Druck ausüben zu können, wenn man WPF-Applikationen sofort als solche erkennt, unter anderem eben am Anti-Aliasing, so in der Art von „Was, Du arbeitest noch mit Windows Forms?“
  • Wie dem auch sei, ein glückliches Ende der Geschichte vom unscharfen Text ist im Moment offenbar nicht in Sicht…

    Veröffentlicht in Keine Kategorie. Schlagwörter: , . 1 Comment »