Ich hab’s zwischenzeitlich wieder dran gegeben – SWT hat mir ordentlich den Nerv geraubt. Ich schrieb ja im letzten Beitrag schon:

Das Konzept bietet “Composites”. Diese können/sollten über Layouts verfügen. Man kann Composites beliebig auf einer View geschachtelt platzieren. So kann man mehrspaltige Layouts mit Einspaltigen und wiederum Mehrspalitigen kombinieren. Das bedeutet aber verschachtelte Layer-Ebenen für die Ausrichtung. Und auf diese “Composites” platziert man dann die “Controls” – also beispielsweise die Widgets für Eingaben, Label oder Listen. Die wiederum ebenfalls über Layouts verfügen sollten, damit diese auch einigermaßen angehübscht auf der View später zu sehen sind.

Grundsätzlich ist mir das Konzept nach dem Lesen dieses Artikels deutlich klarer geworden. Aber – die Klarheit hat noch reichlich trübe Stellen: Für die Darstellung einer Reihe von Label/Text Kombinationen habe ich mich – korrekterweise – für das FormLayout entschieden. Wie ich schrieb, jedes Composite wird von einem darüber .. darunter .. (whatever) liegendem Composite beschrieben.

Gut, das Gebilde – hier links zu sehen – dürfte wohl nicht das gewünschte Ergebnis meiner Gehversuche gewesen sein. Irgendwas ist dort schief gelaufen. Studenlang stellte sich mir die Frage: Was? Wenn ich nun, wo ich die Lösung kenne, auf das Gebilde schaue, dann sieht man das auch auf den ersten Blick. Aber wenn man noch im Trüben fischt, dann sieht man den Wald vor lauter Bäumen nicht. Ich war der naiven Annahme erlegen, das alle FormData Objekte sich der maximalen

Breite des äußeren Composites bemächtigen. Da verliert man dann nämlich auch den Glauben an die Prozentrechnung. Wenn ich jedem Label (also das Links) 30% der gesamten Breite zuweise, dann schaut man schon verwirrt, wenn 30% eben unterschiedlich breit sind. Der entscheidende Tipp kam dann: Schau doch mal mit SWT.BORDER, ob die Zeilen wirklich alle gleich breit sind. Das Bild belegt: Nö!

Das, was man nun rechts sieht, sieht doch entscheidend besser aus. Das war auch in etwa der Plan. Composites sind ja schön und gut. Man kann nicht zu wenig davon haben um seine Objekte zu layouten. Aber zu viel ist anscheinend auch nicht gut. Klar das jedes FormLayout unterschiedlich breit ist, wenn man dem Layout ein neues Composite zu Grunde legt. Und das dann auch noch für jede Zeile. Also merke: Alle Objekte, die in einem Form angezeigt werden sollen, propft man in ein Composite. Danke,

hab ich nun auch endlich kapiert. Vor allem die Abhängigkeit von Objekten des FormLayout zueinander waren anfangs auch etwas abstrakt. Aber wer lesen kann, der ist klar im Vorteil. Irgendwann eröffnet sich dann einem auch, das man auch Höhenabstände einbauen sollte. Sonst liegen alle Objekte direkt (auf einer Fläche) untereinander. Machte irgendwie auch keinen Sinn.

SWT ist eben nicht nur ein Try and (t)error Framework, nein – wenn man denn mal liest, versteht, liest und in sich geht, dann kann man auch schneller und mit deutlich weniger Tries an das erhoffte – erwartete – Ergebnis kommen. Dann kann ich mich ja endlich wieder angenehmen Themen der Programmierung widmen.

30. November 2010:
Im Rahmen der aktuellen Debatte:

image by tutsi.de

• heise.de
  Blog macht wegen neuem Jugendschutzgesetz dicht [Update]
• golem.de
  Jugendmedienschutzstaatsvertrag – Grüne wollen zustimmen – erste Blogs schließen
• 17 Fragen zum JMStV
  (..) Lediglich das Impressum muss um die Daten eines Jugendschutzbeauftragten ergänzt werden, weil sonst Abmahnungen drohen. (..) So kann es passieren, dass die Behörden Inhalte aktiver prüfen und vielleicht Sperrverfügungen aussprechen werden. (..) Anzeichen für beides gibt es bisher noch nicht.
• derWesten.de
  Neuer Jugendschutz im Netz ist stark umstritten
• Indiskretion Ehrensache
  (..) Tatsächlich sprechen wir von der internationalsten, ja, globalsten aller Generationen der Menschheitsgeschichte. Und die muss nicht geschützt werden – das bekommt die prima selber hin. Also, im Internet, jetzt. Geschützt werden muss sie vor regelungswütigen Politikern, für die ein Browser weiterhin so alltäglich ist wie einst Siege für Tasmania Berlin in der Bundesliga. (..)
• Arbeitskreis Zensur

Ob er – also der JMStV nun kommt (ziemlich sicher eigentlich) oder nicht – bedingt dadurch ändert sich eigentlich auch nicht viel: Außer einer weiteren rechtlichen Unsicherheit für Betreiber von Netzangeboten, die dadurch dem gemeinen Hobby “Abmahnwahn” Tür und Tor öffnet.

Zielgerichteter Schutz von Jugendlichen vor Medieninhalten wird dadurch nicht gewährleistet. Insbesondere ist es einfach an den Haaren herbei gezogen das Internet mit einer Sendeanstalten wie dem Radio oder dem Fernsehn gleichzusetzen – auch wenn es bei Streaming-Inhalten, Video-Plattformen oder ähnlichem vielleicht Überschneidungen gibt. Samt und sonders ist es aber technisch eine ganz andere Grundlage – und das will in den Kopf vieler Politiker einfach nicht rein.

Ob GEZ, GEMA, JMStV oder Stoppschilder: Ein globales Netzwerk lässt sich nicht durch bundesdeutsche Schildbürgerpolitik reglementieren. Verstehen wird es aber weder Zensursula, Schäuble 2.0, Thomas ‘der elektronische Personalausweis ist sicher’ de Maizière oder wie die ganzen grauhaarigen Gestalten in irgendwelchen Enquête-Kommissionen sonst so heißen …

via Twitter

Wenn man auf der einen Seite schon die ein oder andere Erfahrung mit InterfaceBuilder oder VisualStudio gemacht hat, dann ist man beim Layout einer graphischen Oberfläche recht verwöhnt. SWT für Java, beziehungsweise JFaces bietet diesen Komfort nicht. Klar, es gibt wohl die ein oder andere Erweiterung für eclipse um “quasi” ähnlich per Drag’n'Drop Oberflächen zu gestalten. Zielführend sind diese Erweiterung meiner bisherigen Erfahrung nach nicht.

Die Erweiterungen sind z.T. buggy, sehr hakelig in der Bedienung und zu guter Letzt blähen sie den Code unnötig auf. Daher verzichte ich nunmehr auf solche eclipse-Erweiterungen und probiere mich am Layout via Code. Bei probieren bleibt es da zur Zeit. Denn das layouten der Elemente einer View ist nervtötend.

Da ist zunächst die Hierarchie: Ganz von unten, angefangen von dem Applikations-Fenster über die Workbench zur Perspektive hin zu der eigentlichen View (das typische RCP-Konzept) ist dabei die eine Sache. Das geht noch einigermaßen von der Hand, da ich dort schon eine gewisse Vorstellungskraft für entwickeln konnte. Von da an greift aber SWT/JFaces.

Das Konzept bietet “Composites”. Diese können/sollten über Layouts verfügen. Man kann Composites beliebig auf einer View geschachtelt platzieren. So kann man mehrspaltige Layouts mit Einspaltigen und wiederum Mehrspalitigen kombinieren. Das bedeutet aber verschachtelte Layer-Ebenen für die Ausrichtung. Und auf diese “Composites” platziert man dann die “Controls” – also beispielsweise die Widgets für Eingaben, Label oder Listen. Die wiederum ebenfalls über Layouts verfügen sollten, damit diese auch einigermaßen angehübscht auf der View später zu sehen sind.

Das ist verdammt viel Flexibilität. Auf der einen Seite natürlich vorteilhaft, auf der anderen Seite, wenn man gerade versucht sich abstrakt das vermeindliche Ergebnis vorzustellen und dieses dann von dem tatsächlichen Ergebnis meilenweit entfernt ist, ist es eher frustrierend. Vor allem – gerade wenn man dort noch nicht über die notwendige Tiefe verfügt – ist das sehr zäh. Es ist dieses “Klein-Klein” mit dem ich mich eigentlich nur ungern aufhalten mag.

Es bringt einen weit weg vom eigentlichen Ziel: Also überlege ich im Moment, ob es notwendig ist, sich selber eine Art “Framework” zu entwickeln für die nun doch an einer Hand abzählbaren Widgets (aka Controls). Das drückt die Motivation doch gewaltig in den Keller, denn schon der eigentliche Controller (MVC-Design Pattern) frisst viel Hirnschmalz zur Zeit.

Aber – SWT hab ich mir ja selber ausgesucht – weil ich da schnell zu sichtbaren Erfolgen komme. Was ja auch durchaus noch richtig ist. Aber meine sehr extreme Abneigung gegenüber häßlichen Oberflächen läßt einen dieses Thema nicht mal eben zur Seite legen.

Es ist ruhig geworden hier – ruhiger als es sonst schon war. Neben einer gütigen Auslastung arbeitstechnisch habe ich meinen Beruf zum “Hobby” gemacht. Vielleicht wäre es sinnvoller gewesen, es anders herum zu gestalten.

Eigentlich sucht(e) ich seit dem Beginn meiner Ausbildung seinerzeit nach einer Idee, den eigenen Horizont in Bezug auf Programmierung mit einem eigenen “Projekt” zu erweitern. Aber wie das immer so ist: Es mangelte immer an einer Idee. Im Prinzip bietet die Software-Welt nichts, was ich im Moment für den Eigenbedarf noch großartig programmieren müsste. Auch für die aktuelle “Idee” besteht keine zwingende Notwendigkeit … aber beginnen wir einfach am Anfang:

Ich hatte mir vor Kurzem Xcode für MacOS angeschaut und hätte es auch gerne weiter verfolgt. Da diese ominöse “Idee” aber am Mangel an Frameworks für Objective-C nicht zielführend gewesen wäre, habe ich dann doch davon abgesehn. Warum nicht zielführend?

Motivationstechnisch – gerade für den Einstieg in etwas Neues – wäre es förderlich, wenn man auch Resultate sieht und nicht from scratch selbst erstmal in einer Programmiersprache, deren Syntax man nicht kennt, deren API nicht verinnerlicht ist, deren Frameworks unbekannt sind stumpf herum programmiert. Entsprechend war es naheliegend zu etwas zu greifen, was mir nicht gänzlich unbekannt war, wo ich aber noch reichlich “Aha!”-Effekte erzielen konnte.

Der Griff zu eclipse RCP auf Basis von JAVA lag beruflich bedingt nahe. Klarer Vorteil ist eben, das programmiertechnisch grundlegendes Wissen zumindest vorhanden ist – Nachteil ist, das – wenn man sich für eine GUI-Anwendung entschieden hat – solche netten Tools wie ein InterfaceBuilder nicht zur Verfügung stehen.

Nach nunmehr etwa einer Woche stellt sich durchaus heraus, das zwar konkrete Entwicklungen in RCP durch die Vorkenntnisse kein Thema sind, aber das große Ganze doch noch sehr abstrakt ist.

So fehlt doch die grundlegende Erfahrung um an der richtigen Stelle zwischen SelectionChange und PropertyChange zu unterscheiden. Dadurch hab ich sicherlich heute mehrere Stunden damit vertrödelt um einfach irgendwas, was passiert, wenn man einen einenfachen Dialog wie “Verzeichnis öffnen” ausführt, auch an der richtige Stelle im Programm abfangen zu können. Die Umsetzung ist zwar nun funktional, aber sicher nicht im Sinne des Erfinders

Aber immerhin gibt es auch einigermaßen positives zu bereichten: Obwohl mittlerweile die sichtbaren Entwicklungen sich immer mehr im “Klein-Klein” der Programmierung verlaufen, so ist es fast schon erschreckend einfach gewesen mit eclipse RCP das Projekt als Standalone-Anwendung sogar auf OSX zu exportieren. Man sollte nur nicht in die naive Annahme verfallen, das, wenn es schon unter OSX so einfach war, es unter Windows ein Kinderspiel sein müsste …

Immerhin: Die eigentliche Programmlogik existiert bereits – wenngleich nicht in besagtem “Projekt“, aber eine Zusammenführung dürfte einigermaßen überschaubar zu erledigen sein. Zur Zeit “spiele” ich schlicht und ergreifend noch mit den Möglichkeiten von RCP herum, um einfach etwas mehr zu erfahren.

Während Selections und Properties mich immernoch verzweifeln lassen, oder Windows mit seinem unsäglichen CharacterEncoding mich zur Weißglut bringen kann, so sind z.B. Benutzereinstellungen in einer RCP-Anwendungen ganz schick gelöst. Gut, man sollte natürlich nicht den Ordner löschen, in dem die Anwendung die Informationen ablegt.

Die Hoffnung stirbt natürlich zuletzt, so gesehn bin ich – noch – einigermaßen optimistisch, das zumindest die eigentliche Funktionalität die das Programm mal bieten soll, irgendwann – zeitnah – auch brauchbar umgesetzt ist. Fehlt nur noch jemand der mir beim sogenannten “Branding” hilft und mir ‘n netten Start-Bildschirm für die Anwendung “malt“.

19. November 2010:

Für “internen Gebrauch” – damit ich nicht so viele Tabs offen hab

• MP3 Tag Library Quick Start
• Example Depot
  Nette Snippet-Sammlung, z.B. File-Aktionen.
• Lars Vogel – Eclipse RCP Tutorial
• Ralf Ebert – RCP Buch
• DeveloperFusion – SWT und JFace