Die Neuerungen in Xojo 2017r2

Letzten Dienstag (den 15.8.) wurde Xojo 2017 Release 2 veröffentlicht, was genügend Anlass für einen neuerlichen Artikel in der Neuerungs-Reihe bietet. Diesmal, muss ich gestehen, fällt er nicht leicht. Die Liste der Veränderungen ist mit über 250 Punkten wirklich, wirklich groß, und auch wenn die offizielle Ankündigung von einem Schwerpunkt auf 64 Bit, Linux und iOS Launch Screens spricht: Das ist eigentlich nur die Spitze des Eisbergs.

Ich will mich trotzdem einmal dran versuchen, aber gleich mit dem Hinweis versehen, dass ich nur eine persönliche Auswahl liefern kann. Für den vollständigen Überblick hilft nur ein Blick in die Versionshinweise.

64 Bit

wäre nunmehr eigentlich völlig aus der Beta-Phase draußen, wäre da nicht der kleine Makel, dass ein Debugging unter Windows nach wie vor nur mit 32 Bit funktioniert. LLVM (jetzt in Version 4) hat zwar große Fortschritte gemacht, aber es fehlen noch ein paar wichtige Informationen für den Debugger. Nichtsdestotrotz sollten Windows-Anwendungen jetzt reibungslos funktionieren, inkl. der bisher nur mit Trick zu erhaltenden App-Icons und Versionsinfos.

Lang erhoffte Geschwindigkeitssprünge inklusive: Das String-Handling unter 64 Bit ist jetzt so fix, wie man es erwartet, inkl. Join und Split und anderen Funktionen, die vorher arg in die Knie gegangen sind. Tests ergeben hier eine Beschleunigung von über 600 %. Allerdings sollte man älteren Code genau unter die Lupe nehmen: Für ein reibungsloses Funktionieren ist es unumgänglich, Strings, die aus externen Quellen kommen (Dateien, Datenbanken …) stets das korrekte Encoding zuzuweisen. Der 32 Bit-Compiler war da etwas gnädiger, weshalb Probleme wie ein plötzlich Case-sensitives Instr in einer falschen Codierung zu suchen sind. (Der Link funktioniert nicht für alle Leser, da er auf das Prerelease-Forum verweist.)

Ein weiterer Meilenstein auf dem Weg zur 64 Bit-IDE ist mit dem Hieven von XojoScript auf 64 Bit genommen. Insbesondere Windows profitiert enorm von stark erhöhter Geschwindigkeit im Mathematik-Bereich.

 

Graphics

wurde um einige Wanzen erleichtert: RectShape und CurveShape kommen besser mit nicht-ganzzahligen Werten klar und zeichnen keine verwaschenen Linien mehr, und Clip beachtet die Antialias-Einstellungen des Graphics-Objekts.

Icon-tragende Controls berücksichtigen die passende Auflösung auch auf Retina-DiDPI-Bildschirmen, und die CellHelpTags der Listbox erscheinenden an den richtigen Plätzen – nur leider immer noch nicht unter macOS 64 Bit, wofür es aber Abhilfe gibt. Wo wir beim Thema sind: Die

Listbox

ist nun schlauer, was Drag & Drop angeht. Drop-Events besitzen eine Enumeration

DropLocations mit den Werten

  • OnRow: Es wird etwas genau auf der Zeile abgelegt.
  • AfterRow: Der Benutzer will etwas zwischen den Zeilen einfügen, nämlich nach der entsprechenden Zeile und
  • OnControl: Keine bestimmte Zeile ist angewählt. Das ist das Standard-Verhalten der früheren Drop-Events.

Außerdem kann nun festgelegt werden, ob ein Drop-Vorgang visuell von der Listbox angezeigt wird, und zwar mit der Property ShowDropIndicator.

Des weiteren gibt es neue Events, nämlich

DragOverRow(x As Integer, y As Integer, obj As DragItem, action As Integer, ByRef row As Integer, ByRef parentRow As Integer, ByRef location As DropLocations) As Boolean

Ähnlich dem DragOver-Event, wobei die Listbox in diesem Eventhandler die Zielkoordinaten für den Drop verändern kann – deshalb die ByRefs. Ein Rückgabewert True verhindert den Drop und das Feuern des DragOver-Events.

und

DropObjectOnRow(x As Integer, y As Integer, obj As DragItem, action As Integer, row As Integer, parentRow As Integer, location As DropLocations)

Feuert nach einem Drop. Row, ParentRow und Location sind die ggf. via DragOverRow veränderten Werte. Nach diesem Event kommt auch der altbekannte DropObject-Event zum Zuge.

 

Linux

ist sehr gründlich umgekrempelt worden und benutzt nun GTK+3 fürs Malen der GUI, gegenüber der Version 2, die in bisherigen Versionen in der Regel ein manuelles Installieren von GTK nötig machte. Damit ist auch Linux voll HiDPI-fähig, wenn auch nicht ganz ohne Wermutstropfen: Die Vorgabegrößen vieler Controls sind theme-abhängig, weshalb das Layout durcheinanderkommen kann, wenn dieser Umstand  nicht berücksichtigt wird. Auch hat Ubuntu 14.0.4 LTS einige Bugs in GTK+3, die zu Problemen führen können.

Eine Übersicht über die unter GTK+3 anfallenden Änderungen gibt es in diesem Blogbeitrag.

IDE-Vorgaben

Erfreulicherweise kann man die IDE selbst sehr einfach an die persönliche Linux-Distro anpassen (und auch andere Plattformen lassen sich so individualisieren):

Legt man eine Textdatei mit dem Namen <Klassenname>.defaults an und speichert diese unter <SharedDocuments>/Xojo/Overrides oder unter <Documents>/Xojo.Overrides, kann man hier individuelle Vorgabewerte für jede Standard-Klasse verändern.

Eine Datei mit dem Namen Window.Overrides und dem Inhalt

Width=800 
Height=600

etwa sorgt dafür, dass neu angelegte Fenster die entsprechenden Vorgabewerte erhalten.

Width = 800|700|600

andererseits gibt Fenstern unter macOS die Standardbreite 800, unter Windows 700 und unter Linux 600 Points.

Raspberry Pi

hat nun endlich auch einen Kommandozeilen-Remote-Debugger. Dem bequemen Entwickeln auf dem Lieblings-Desktop-System mit automatischer Übertragung auf den Raspi steht nunmehr also gar nichts mehr im Weg.

Web-Apps

versuchen nach Verbindungsabbrüchen eine automatische Wiederverbindung.

iOS

schließich hat zwei gravierende Neuerungen: Es lässt sich ein Launch Screen einbinden, ein eingeschränktes View, das automatisch während des App-Starts angezeigt wird. Damit entfällt die Notwendigkeit von Launch Images in 5000 verschiedenen Größen wie zuvor: Launch Screen integrieren, Hintergrundfarbe einstellen und ein ImageView, ggf. Labels, darauf platzieren, und das war’s! Apple empfiehlt, das Aussehen des Hauptviews anzudeuten. Wer aber mag, kann auch einen Splash Screen gestalten, auf dem das Programmlogo o.ä. angezeigt wird.

Es mag bei einigen Projekten allerdings im weiteren Verlauf zu Schwierigkeiten mit bereits definierten Views kommen. Dies liegt daran, dass die LayoutConstraints nunmehr die Priorität auch wirklich berücksichtigen. Sollte das Layout schwer gestört wirken, so bestand die Abhilfe in Tests darin, die Constraints zu überprüfen und ihre Priority auf Highest zu setzen. Damit werden diese als obligatorisch definiert. Niedrigwertigere Priorities können von der Logik des Apple-Autolayouts ggf. auch mal ignoriert werden. Der Constructor für per Code erzeugte Constraints besitzt aus diesem Grund auch einen Priority-Wert. 1000 steht dabei für „Highest“.

Soviel zur kleinen Übersicht. Aber, wie gesagt: Es gibt noch viel, viel mehr!

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s