vcl zu clx

[tommie-lie]

Darf ich mal um etwas Nuhr bitten!

Zitat von Robert_G:

Kylix Compiler dürfte mit den neuen Kernel von Linux auch nicht mehr zurechtkommen.

Doch, der Compiler selbst schon, nur der Debugger nicht. Aber ich kenne Leute, die den Kylix-Compiler als gewöhnliches Commandozeilentool benutzen und ihren Code woanders schreiben. Ob es da noch Spaß macht, zu debuggen, wage ich aber zu bezweifeln

Zitat von Robert_G:

Einfach mal in die Borland NGs schauen. Da gibt es täglich mindestens einen, der Kylix nachheult und 10 die auf ihm rumhacken...

Wenn dem so ist, und die 10 nicht von Borland sind, darf man die 10 getrost in die Tonne treten. Borland ist der, auf dem rumgehackt werden sollte.

Zitat von FriFra:

Kylix wäre mit VCL Unterstützung eben gerade KEIN Reifall geworden, allein die clx hat doch die Mehrheit davon abgehalten es auch nur zu versuchen Projekte zu Portieren.

Was meinst du, was die CLX ist? Die VCL kannst du nicht nach Linux portieren, ohne sie komplett (in Worten: k o m p l e doppel-t) neu zu schreiben. Die CLX war etwas, was die VCL möglichst gut nachahmen sollte. Was die API an sich angeht, haben sie das bei den gebräuchlichen Komponenten auch einigermaßen hingekriegt. Letztendlich ist der Markt nicht so groß, daß es sich lohnt, da noch mehr Energie reinzustecken. Linux ist keine Umgebung, auf der man in Pascal programmiert. Für kleine Tools (für das Kylix übrigens wirklich ideal war) nimmt man unter Linux viel zu gerne Python oder Perl her, für "richtige" Programme war Kylix allein vom Compiler und der Libc-Portierung nicht zu gebrauchen. Mittlerweile ist das Projekt komplett gestorben, jeder Cent der noch in Kylix gesteckt wird, ist falsch angelegt, Mono ist da die wesentlich bessere Anlagemöglichkeit.

Zitat von eyeless:

ich habe wine und es funzt auch, nur ist alles toatal verschoben und krumm

Könntest du mir mal einen Screenshot zeigen und/oder evtl das betreffende Windows-Programm schicken? Gerne auch per eMail, die Adresse gibt's dann per PM.

Eine Portierung von reiner VCL nach CLX ist an sich nicht großartig kompliziert. Theoretisch reicht es, vor die VCL-(nicht RTL- )Units ein Q zu schreiben. Es sollten nur wenige Teile der Interfaces unterschiedlich sein. Kompliziert wird es eher bei den etwas tiefergehenden dingen, zum Beispiel Workarounds für VCL-Unzulänglichkeiten, alles was mit der API zu tun hat, Internet, sofern nicht Linux von den Indies unterstützt wird, und alles, was Windows-spezifisch ist (Komponentne für Tray-Icons, Features der Common Controls 6.0, sonstiger Kleinkram). Das wird schwierig (zu Fuß, nicht über Komponenten) bis unmöglich (einige Dinge gibt es unter Linux in der Form nicht).

[jbg]

Zitat von Robert_G:

Kylix Compiler dürfte mit den neuen Kernel von Linux auch nicht mehr zurechtkommen.

Also ich habe gerade ein Qt3CLX Programm auf SuSE 9.2 kompiliert und das läuft wunderbar. (Braucht zwar eine weile bis es geladen ist. Das liegt aber daran, dass ich die Qt3CLX .pas und wrapper-SharedObject mit vollen Debuginfos laufen habe).

Der bc++ Compiler macht bei neueren Distributionen Probleme, weil er Header-Dateien vom gcc nutzt. Und der hat sich Grundlegend geändert. Das bekommt man aber auch in den Griff, indem man einen alten Satz Header-Dateien vom gcc 2.95 einspielt.

Und dem Problem, dass der Debugger ab Kernel 2.6.11 nicht mehr geht, bin ich bereits auf der Spur. Beim 2.6.10 geht er nämlich noch. Dummerweise sind da 22 MB Patches dazwischen, die ich gerade auf 2 MB gedrückt habe (nicht i386-Platformen, Treiber, IPv6 usw. haben sicher nichts mit dem Problem zu tun).

Zitat:

Eine Portierung von reiner VCL nach CLX ist an sich nicht großartig kompliziert.

Für die JVCL hatte ich dafür bereits ein Tool geschrieben: jvcl3\devtools\JvclVclClx, dass neben dem Einfügen der "Q"s auch noch die nicht benötigten IFDEF-Blöcke entfernt. Und mittels der Unit jvcl3\qcommon\QWindows.pas und QMessages.pas wird die Portierung einier WinAPI Befehle einfacher.

Zitat:

als gewöhnliches Commandozeilentool benutzen und ihren Code woanders schreiben. Ob es da noch Spaß macht, zu debuggen, wage ich aber zu bezweifeln

Es gibt ja noch gdb, und der lässt sich mit kdbg steuern. Aber das Delphi-Feeling gibt es da nicht, da hast du recht.

Zitat:

Die CLX war etwas, was die VCL möglichst gut nachahmen sollte.

Genau das soll die Aufgabe des Kylix Community Projects sein: Die CLX mehr an die VCL heranbringen. Nur blockiert Borland da seit letzten September mit einem rechtlichen Problem. Der CLX Quellcode soll ja nicht unter GPL verbessert werden, also braucht das Team die Genehmigung den Quellcode direkt zu nutzen und nicht nur umständlich über Patchdateien zu arbeiten.

Zitat:

Linux ist keine Umgebung, auf der man in Pascal programmiert.

Wenigsten können die, die Pascal unter Linux programmieren, auch programmieren und lassen nicht zig Millionen Warnungen und Hinweise über den Bildschirm rauschen.

Zitat:

Mittlerweile ist das Projekt komplett gestorben, jeder Cent der noch in Kylix gesteckt wird, ist falsch angelegt, Mono ist da die wesentlich bessere Anlagemöglichkeit.

Dummerweise haben viele Firmen 2001 auf Kylix gesetzt und ihre Server-Anwendungen in Kylix geschrieben. Und die Programme müssen auch gewartet werden. Die werden nicht mal schnell alles neu schreiben.

Mono ist unter Linux immernoch nicht wirklich gern gesehen. Die sind eben auf ihre naivität (nativität) Versessen.

Zitat:

für "richtige" Programme war Kylix allein vom Compiler und der Libc-Portierung nicht zu gebrauchen.

Echt? Warum hat mich dann eine Firma angeheuert, dass ich deren Programm Linux-tauglich mache und das mit Kylix? (Das ist sozusagen mein Real World Application Test für meine Unofficial VisualCLX Patches.
Und warum sollte der Compiler und die Libc-Portierung dafür nicht zu gebrauchen sein? Begründe das bitte, da es mich interessieren würde.

[omata]

Moin,

was haltet ihr von CrossKylix?
Also ich finde es einfach nur genial, unter Windows CLX-Anwendungen zuschreiben/debuggen eine EXE zu erhalten und auch gleich die Linux-Anwendung compilieren zu können.

ich finde es schade, dass das Kylix-Projekt von Borland nicht weiterverfolgt wird.

...und jetzt bitte auf mir rumhacken...

MfG
Thorsten

[jbg]

Zitat von omata:

ich finde es schade, dass das Kylix-Projekt von Borland nicht weiterverfolgt wird.

Das hat Borland so nie geäußert. Die halten sich was Kylix betrifft bedeckt.

[Robert_G]

Zitat von tommie-lie:

Zitat von Robert_G:

Kylix wäre mit VCL Unterstützung eben gerade KEIN Reifall geworden, allein die clx hat doch die Mehrheit davon abgehalten es auch nur zu versuchen Projekte zu Portieren.

Habe ich nie gesagt!
Aber ich zweifle immer noch daran, dass eine reine Portierung der VCL sinnvoll gewesen wäre.
(Wäre wohl in zuviel "Wrapperei" VCL->BastelBastel->QT geendet...)

btw: CLX und Kylix wären eigentlich nur der Anfang gewesen. Hätte sich Kylix ordentlich verkauft wären auch andere Plattformen unterstützt worden. (Habe ich zumindest mal irgendwo von einem Borländer gelesen, oder war's nur einer vom TeamB? )

Sie haben aber anscheinend direkt danach den nächsten Wrapper gebaut -> VCL.Net.

Aber eigentlich interessiert mich das nicht die Bohne. Mich hat nur FriFras Rumgepupe aufgeregt...

[delphifan2004]

Hallo Ihr Streithähne!

Zitat von Bernhard Geyer:

Nach CLX portieren ist relativ einfach.

Gilt das auch für Toolbar2000?

Hab nämlich grad ein Projekt in Arbeit, das Toolbar2000 verwendet. Unter VCL. Und die Delphi Toolbar Komponenten sind in der CLX nicht so komfortabel im Funktionsumfang, wie die VCL Pendants. Habe selber schon versucht mit CLX Floating Toolbars zu programmieren. Spätestens beim Menü ist da scluss mit lustig. Unter VCL dagegen kein Problem.

Meine Erfahrung mit Portierung:

VCL->CLX :==> Keine Erfahrung.

CLX->VCL :==> Oft, eben auch in meinem Projekt, ein Cad Programm Open Source wird die Libc - Unit verwendet. Man kann mit bedingter Compilierung Libc unter Windows verbannen. So hier:

Delphi-Quellcode:

uses
{$ifdef Linux}
  Libc,
{$else}
  {$ifdef windows}
  Windows,
  {$else}
  // ... evtl. andere Systeme berücksichtigen. Keine Ahnung, wie sinnvoll das mit CLX wäre.
  {$endif}
{$endif}
  systemunabhängige_units;

Aber dann kann es Probleme geben, da ja in diesem Fall Linux-spezifische Typen und Variablen mit diesen Typen verwendet wurden. Genauso verhält es sich, wenn die Unit Qt verwendet wird. Dort sind einige Handles anders definiert, als diejenigen für den gleichen Zweck unter Windows. Dann können die erforderlichen Änderungen recht umfangreich werden.

Es grüßt

Delphifan2004

[tommie-lie]

Zitat von jbg:

Mono ist unter Linux immernoch nicht wirklich gern gesehen. Die sind eben auf ihre naivität (nativität) Versessen.

Wer "die"? Bei Gnome und vor allem Ubuntu wird Mono überaus gerne gesehen.

Zitat:

Und warum sollte der Compiler und die Libc-Portierung dafür nicht zu gebrauchen sein? Begründe das bitte, da es mich interessieren würde.

Ich habe mal angefangen etwas systemnäher zu programmieren und bin auf einige Unzulänglichkeiten bei der Namensgebung der libc gestoßen. Da wurden von Borland Unterstriche und Postfixe weggelassen und die "offizielle" GNU-Doku stimmte nicht mehr und ich habe mich gewundert, warum diese blöde Funktion nicht existiert. Außerdem bezweifle ich, daß die alten Übersetzungen kompatibel mit der aktuellen C-Bibliothek ist. "Nicht zu gebrauchen" war vielleicht falsch ausgedrückt, "nicht einfach für alles" zu gebrauchen wäre besser gewesen. Die Borland-Übersetzung ist aber immernoch um Lichtjahre besser als die von FPC

Zitat von delphifan2004:

Habe selber schon versucht mit CLX Floating Toolbars zu programmieren. Spätestens beim Menü ist da scluss mit lustig.

Beim Rumgespiele mit Glade hat sich eben ergeben: Vielleicht wirst du mit dem Gtk-Widget "handlebox" glücklich. Ob's da was für Qt gibt, weiß ich nicht.

Zitat von Robert_G:

Habe ich nie gesagt!

Jaja, isscha gut, ich darf mich doch auch mal verquotteln

[jbg]

Zitat von delphifan2004:

Gilt das auch für Toolbar2000?

Schrieb ich bereits. WindowProc Hacker-Komponenten funktionieren nicht unter der CLX, weil es keine WindowProc gibt.

Für Toolbar2000 muss die CLX erstmal ein Windows-Message-System über das Qt-Event-System stülpen. Was zu einem gewissen Grad schon möglich ist, aber einen heiden Arbeit machen würde.

Zitat:

Spätestens beim Menü ist da scluss mit lustig.

Die Qt2 Menüs kann man sowieso kicken. Da nimm ich immer eine Toolbar her und theme sie.

Zitat:

Oft [...] wird die Libc - Unit verwendet. Man kann mit bedingter Compilierung Libc unter Windows verbannen.

Funktionen, die die Windows oder Libc Unit nutzen, landen bei mir immer in einer Platform-Abhängigen Unit, die dann mit IFDEFs arbeitet. So bleibt das Hauptprogramm relativ sauber von IFDEFs. Die JVCL zum Beispiel hat eine Schicht zwischen VCL/CLX gelegt, welche die meisten IFDEFs eliminiert hat.

Zitat:

Aber dann kann es Probleme geben, da ja in diesem Fall Linux-spezifische Typen und Variablen mit diesen Typen verwendet wurden. Genauso verhält es sich, wenn die Unit Qt verwendet wird.

Bei der Libc-Unit sehe ich das noch ein. Aber die Qt-Unit besitzt bis auf (TMsg, HCURSOR, HPALETTE, HFONT, HDC, HBITMAP, HBRUSH, HPEN und HRGN) keine Unterschiede für Platformen, welche die Typen betreffen. Und wer die in einem CLX Programm einsetzt, sollte wissen was er da macht. Und bei den Qt-Funktionen sind es auch nur so Dinge wie QApplication_winEventFilter, QApplication_winVersion, ... die unter Linux nichts verloren haben und dort teilweise ihre Äquivalente haben (QApplication_x11EventFilter, ...).

[jbg]

Posting gestrichen, weil ich den kompletten Text von tommi-lie hier kopiert hatte.

[tommie-lie]

Zitat von jbg:

Zitat von tommie-lie:

Bei Gnome und vor allem Ubuntu wird Mono überaus gerne gesehen.

Und welches Programm läuft da bereits unter Mono? (Bis auf den XSP)

Spielt das eine Rolle? Mono wird nicht ungern gesehen und es wird nicht davon abgeraten, im Gegenteil es laufen Diskussionen Mono als empfohlene Umgebung für künftige Programme zu verwenden. Daß bisher kaum Anwendungen geschrieben wurden liegt unter anderem daran, daß niemand Programme aus dünner Luft zieht.

Zitat von tommie-lie:

Jaja, isscha gut, ich darf mich doch auch mal verquotteln

Wolltest du auch mal?