MSEide+MSEgui 2.2 für FPC 2.4

[mse]

MSEide+MSEgui Version 2.2 für FPC 2.4 wurde freigegeben:
http://sourceforge.net/projects/mseide-msegui/files/" onclick="window.open(this.href);return false;

Neu gibt es auch eine experimentelle Version für x86_64-linux.

Viel Spass!

Martin

[mschnell]

WOW !!!!
FPC 2.4 ist doch gerade erst ein paar Tage 'raus....

Wann wohl Lazarus damit "offiziell" läuft ?

(Wie) benutzt MSEGUI die neuem Unicode-tauglichen, dynmaischen Strings ? (laut FPC-Wiki sind die doch noch nicht ganz fertig) ?

Gruß und viel Erfolg in 2010 !
-Michael

[mse]

WOW !!!!
FPC 2.4 ist doch gerade erst ein paar Tage 'raus....

Es gibt die SVN fixes_* branches, da kann man sich schön auf ein neues release vorbereiten.

(Wie) benutzt MSEGUI die neuem Unicode-tauglichen, dynmaischen Strings ? (laut FPC-Wiki sind die doch noch nicht ganz fertig) ?

MSEgui benützt für Unicode widestrings, welche in FPC schon seit Jahren funktionieren. Neu steht nun in FPC 2.4 der UnicodeString Typ zur Verfügung, ein auf allen Plattformen Referenz-gezählter widestring. MSEgui 2.2 hat standardmässig msestring = UnicodeString definiert. Eine Zeit lang war war in FPC für Windows kein Referenz-gezählter widestring vorhanden, was zu einer gewissen Performance-Einbusse unter Windows führte, dieses Manko ist nun behoben.

[Socke]

WOW !!!!
FPC 2.4 ist doch gerade erst ein paar Tage 'raus....

Wann wohl Lazarus damit "offiziell" läuft ?

(Wie) benutzt MSEGUI die neuem Unicode-tauglichen, dynmaischen Strings ? (laut FPC-Wiki sind die doch noch nicht ganz fertig) ?

Gruß und viel Erfolg in 2010 !
-Michael

Lazarus wird wohl mit der nächsten Release-Version den FPC 2.4 als Standard empfehlen (und in den Packages mitliefern). Aber schon jetzt besitzt die svn-Trunk-Version die Möglichkeit in den Projekt-Optionen unter "Diverses" auf die "FPC resources" umzustellen (anstatt Lazarus-resources).

Inwiefern werden denn von MSEgui die neuen resourcen benutzt? Und werden die Formulare auch nach jeder Änderung gespeichert und neu in Resourcen-Dateien übersetzt (Lazarus vergisst das derzeit immer)?

[mschnell]

Neu steht nun in FPC 2.4 der UnicodeString Typ zur Verfügung, ein auf allen Plattformen Referenz-gezählter widestring. MSEgui 2.2 hat standardmässig msestring = UnicodeString definiert.

Gut !

D.h. der dynamisch typisierte String-Type (mit "Bytes/character" Byte und "code" Word, wie beim aktuellen Delphi) wird momentan nicht benutzt...

-Michael

[mse]

Inwiefern werden denn von MSEgui die neuen resourcen benutzt? Und werden die Formulare auch nach jeder Änderung gespeichert und neu in Resourcen-Dateien übersetzt (Lazarus vergisst das derzeit immer)?

MSEgui benutzt ein eigenes Ressourcen-System. Fomulare werden als *.mfm Dateien im Text-Objekt-Format gespeichert, diese entsprechen den Delphi *.dfm und den Lazarus *.lfm Dateien. MSEide erzeugt daraus spezielle Pascal units die von FPC kompiliert werden. Beispiel:

Code: Alles auswählen

unit main_mfm;
{$ifdef FPC}{$mode objfpc}{$h+}{$endif}
 
interface
 
implementation
uses
 mseclasses,main;
 
const
 objdata: record size: integer; data: array[0..35323] of byte end =
      (size: 35324; data: (
  84,80,70,48,7,116,109,97,105,110,102,111,6,109,97,105,110,102,111,13,
  111,112,116,105,111,110,115,119,105,100,103,101,116,11,13,111,119,95,97,114,
  114,111,119,102,111,99,117,115,11,111,119,95,115,117,98,102,111,99,117,115,
[...]
  112,114,111,99,100,105,101,100,4,108,101,102,116,2,16,3,116,111,112,2,
  88,0,0,0)
 );
 
initialization
 registerobjectdata(@objdata,tmainfo,'');
end.

Wobei objdata die von tcomponent.writestate() erzeugten binären Daten enthält.

[mse]

D.h. der dynamisch typisierte String-Type (mit "Bytes/character" Byte und "code" Word, wie beim aktuellen Delphi) wird momentan nicht benutzt...

Die Grundform dieses strings ist ebenfalls der referenzgezählte widestring, alle Code-Konvertierungen laufen über widestring. 8-Bit strings der form String<Codepage> oder AnsiString sollten nach Möglichkeit aus Performancegründen vermieden werden, da sie mehr Overhead benötigen, speziell im Zusammenhang mit RawByteString. Dies gilt leider auch für UTF8String. Für das Ergebnis einiger Experimente siehe
http://www.mail-archive.com/fpc-devel@l ... 15579.html

Zu beachten ist noch der Speicherbedarf, 'a' benötigt auf 64 Bit Systemen bereits 25 Bytes:
http://www.mail-archive.com/fpc-devel@l ... 15500.html

Dazu kommen noch weitere Bytes zum memory alignment und im memory manager.
Schöne Neue Welt.

[mschnell]

Das Heißt, MSEGUI würde die volle Funktionalität der dynamisch codierten Strings auch nicht verwenden, wenn sie in FPC vollständig implementiert wären, sondern defaultmäßig generell UTF16 codierten Strings definieren.

Richtig ?

Und wenn unter Linux eine UTF8 API zu GTK 2 (oder wie das Ding heißt) verwendet wird gibt das tatsächlich keine Performance-Probleme, obwohl jede GUI Aktion eine Konvertierung fordert ?

-Michael

[Hitman]

Und wenn unter Linux eine UTF8 API zu GTK 2 (oder wie das Ding heißt) verwendet wird gibt das tatsächlich keine Performance-Probleme, obwohl jede GUI Aktion eine Konvertierung fordert ?

MSEgui ist ja ein eigenes "Widgetset" ... was willst du da mit GTK2?

[mse]

Das Heißt, MSEGUI würde die volle Funktionalität der dynamisch codierten Strings auch nicht verwenden, wenn sie in FPC vollständig implementiert wären, sondern defaultmäßig generell bei UTF16 codierten Strings definieren.

MSEgui würde vermutlich UnicodeString (die Grundform der "dynamisch codierten Strings") verwenden. Die Grundcodierung dieser Strings ist utf-16. Noch besser wäre natürlich die Beibehaltung des jetzigen FPC UnicodeString ohne den nicht benötigten Laufzeit-overhead.

Und wenn unter Linux eine UTF8 API zu GTK 2 (oder wie das Ding heißt) verwendet wird gibt das tatsächlich keine Performance-Probleme, obwohl jede GUI Aktion eine Konvertierung fordert ?

MSEgui verwendet unter Linux keine utf-8 API sondern die utf-16 X11/xft API.
Meines Wissens ist GTK2 übrigens die einzige utf-8 API. Windows, Qt und MAC verwenden utf-16. Bitte korrigiert mich, falls ich falsch liegen sollte.

Martin

[mschnell]

MSEgui verwendet unter Linux keine utf-8 API sondern die utf-16 X11/xft API.

Ich wusste nicht, dass GTK2 überhaupt eine utf-16 API zur Verfügung stellt. Aus anderen Diskussionen hier im Lazarus-Forum hatte die militanten utf-8-Fraktion bei mir den Eindruck GTK2 (und eigentlich jede Linux GUI) kann nur utf-8. Wenn es eine UTF-8 und eine UTF-16 API gibt, wäre die Frage, ob die Performance vergleichbar ist.

Meines Wissens ist GTK2 übrigens die einzige utf-8 API. Windows, Qt und MAC verwenden utf-16. Bitte korrigiert mich, falls ich falsch liegen sollte.

Ich habe da keine weitergehenden Informationen

-Michael

[mse]

Ich wusste nicht, dass GTK2 überhaupt eine utf-16 API zur Verfügung stellt. Aus anderen Diskussionen hier im Lazarus-Forum hatte die militanten utf-8-Fraktion bei mir den Eindruck GTK2 (und eigentlich jede Linux GUI) kann nur utf-8. Wenn es eine UTF-8 und eine UTF-16 API gibt, wäre die Frage, ob die Performance vergleichbar ist.

Die "Linux GUI-Schnittstelle" ist X11/xft welche beide sowohl utf-8 als auch utf-16 API's haben. GTK2 hat damit nichts zu tun. Häufig wird irgendwo in der Funktions-Kette sowieso auf UCS4 gewandelt, ob utf-8 oder utf-16 verwendet wird, ist daher zweitrangig. utf-16 <-> UCS4 dürfte etwas schneller sein.
Die Standard Codierung heutiger Linux-Distributionen ist meist utf-8. Dateinamen sind unter Linux nicht unbedingt utf-8 sondern ein array of bytes ohne Codierung. Auch hier bringt utf-8 keine grossen Vorteile, das Theater mit ungültigen utf-8 Sequenzen in Dateinamen hat man in beiden Fällen.

[mschnell]

Die Standard Codierung heutiger Linux-Distributionen ist meist utf-8.

Was soll das heißen ? Die Codierung von welchen Daten ? Was hat die Distribution damit zu tun ?

-Michael

[mse]

Die Standard Codierung heutiger Linux-Distributionen ist meist utf-8.

Was soll das heißen ? Die Codierung von welchen Daten ?

Die LC_LANG Einstellungen, Codierung der script, man und info files, die Standard-Codierung in Terminals und Filesystem, was weiss ich...

Was hat die Distribution damit zu tun ?

Sie gibt die entsprechenden Einstellungen vor.

[hotzenplotz]

Ihr seids wirklich verdamt schnell! Ich werd mir dieses Projekt genauer anschaun.