c++ vs delphi

[tommie-lie]

Zitat von mael:

Zitat:

Und ganz ehrlich: ich verwende lieber die String-Funktionen der libc als die der FPC-RTL...

Wenn das so ist, solltest Du sowieso FP sein lassen.

Welche andere Pascal-Implementierung soll ich denn unter Linux sonst benutzen? GPC, das nicht DelphiLanguage-kompatibel ist, weil es sich an die offenen Standards hält? Oder Kylix, dessen IDE auch nicht wesentlich besser ist und das unter einem 2.6er-Kernel nicht mehr zuverlässig läuft und mittlerweile auch veraltete Units hat?

Zitat:

System V IPC Sachen sind in Kylix libc.pas definiert, JEDI hat, bis jetzt, soweit ich weiß dafür keine Unterstützung.

Ist ja eigentlich auch nicht deren Aufgabe. Als Joint Endeavor of Delphi Innovators brauchen sie sich eignetlich nicht um IPC von anderen Betriebssystemen kümmern.

Zitat:

Die pthread.h ist aber kurz und schnell übersetzt, also kein wirkliches Hindernis. Wie wäre es: Übersetzte es und schick es auf die JEDI mailing Liste.

Wie wäre es: Ich benutze einfach die Standardbibliothek für sowas, die GNU C Library?

Zitat:

Zitat:

Qt

Wird nicht korrekt gezeichnet, die Menüs wackeln hin und her, die Shortcuts sind schlecht implementiert, Teile werden nicht gezeichnet (z.B. beim PageControl)

Ist mir in meinem (zugegebenermaßen kurzen) KDE-Leben nicht aufgefallen. Zumindest hat Gnome/GTK derartige Probleme nicht, und auch die Menüs von Knoppix oder Kanotix wackeln nicht hin und her. Um schlechte Erfahrungen mit Shortcuts zu machen hatte ich es nie lange genug in produktivem Einsatz, in Gnome funktionieren sie aber.

Zitat:

Du ignorierst einfach was ich sage. Es geht nicht was für Programme ich verwenden will, es geht darum das GTK sich nicht an Windows hält

Gtk ist auch nicht für Windows gemacht!
Schau mal, geh mal auf www.gtk.org. Im dortigen Download-bereich findest du eh nur die Quellen. Das "GTK+ for Win32"-Projekt ist nichtmal auf gtk.org gehostet, es ist Teil des GIMP-Projekts und nichtmal davon ein offizieller Teil. Es wird von Tor Lillqvist maintained und mehr oder weniger eine private Entwicklung. Und wenn du den Windows-Links auf [url}www.gimp.org[/url] folgst, wirst du sogar merken, daß der Windows-Port ein eigenständiges Sourceforge-Projekt ist, nämlich gimp-win.

Zitat:

Außerdem werden häufig auch Programme von Windows nach Linux portiert.

Was ohne wine(lib) ein unglaublicher Aufwand ist, weil kein einziger der Calls auch nur ansatzweise unter Linux existieren.

Diese ganze Diskussion lässt sich ganz einfach komprimieren: GTK hatte never ever das Ziel, Windows zu unterstützen, und dennoch bist du der Meinunng, daß es deren Aufgabe sei, native Dialoge des jeweiligen Systems zu verwenden. Für sowas war aber GTK nie gemacht worden.

Zitat:

Lies richtig, es geht um die Frameworks. Die sollen sich nach dem Standard richten, wenn sie das tun, mußt DU Dich nicht um die Details kümmern. Die Kritik ist: sie tun es nicht!

"Ich" war in diesem Fall jemand, der irgendwas auf allen Plattformen zugänglich machen will. Das sind auch die Trolltech- und GTK-Leute. Es ist und bleibt das gleiche Problem: Eine Heidenarbeit, für die niemand Zeit hat.

Zitat:

Ich habe sogar schon eines programmiert. Und X bietet auch Fensterchen, Menüs und Nachrichten, Maus, ...

Ich weiß, was es kann, aber es sieht hässlich aus, wenn man nicht erheblich mehr Arbeit in die Oberfläche steckt als in die Programmlogik.

Zitat:

Zitat:

Wenn du optisch auf das Niveau von Windows kommen willst, hast du schon fast ein fertiges TK, da kannst du auch ein fertiges (GTK, Qt, ...) nehmen.

Nicht optisch, sondern von der Komplexität der Steuerelemente her.

Wenn du Gnome oder KDE benutzt, integriert sich ein X-Programm überhaupt nicht in die bestehende Oberfläche. Ist dir das wirklich lieber als zwei verschiedene Dateidialoge?

Zitat:

Falsch, alle Crossplattform Programme sehen so aus, und das ist unakzeptabel.

Ja, das ist es, was ich sagte. Linux-Programme sehen meist wie Linux-Programme aus, und mit Windows-Programmen sieht's genauso aus. Erst was rübergeschleppt wird muss sich irgendwo in der Mitte treffen. Crossplatform-Anwendungen, die auf jeder Zielplattform wie zuhause aussehen sollen, sind keine plattformübergreifenden Anwendungen mehr, sondern Ports der kompletten GUI auf die jeweilige Zielplattform. Ein komplettes Rwrite kommt dem ganzen noch am nächsten, auch wenn man wenigstens die ganzen Backends mitbenutzen kann, wenn die Entwickler nicht gepennt haben und Backend und Frontend so miteinander verflochten haben, daß man trotzdem den kompletten Code neuschreiben darf.

Zitat:

Warum schreibt man denn Programme? Damit sie von jemanden genutzt werden können, und nicht um zu sagen "ich bin so toll, warum gefällt Dir Trottel nicht wie mein Programm funktioniert".
GUI Design ist sehr wichtig, es geht ja nicht um kleine Zeichenfehler, sondern das jedes Programm anders funktioniert und dafür gibt es BSe. Verwendet man Bordmittel beherrscht man ein Programm im Handumdrehen, sonst ist dauerend Einarbeitung nötig = unproduktiv.

ACK.
Aber wenn ich auf mehreren Hochzeiten feiern will, müsste ich für jedes Betriebssystem eine eigene Oberfläche entwickeln und maintainen. Da ich persönlich mich lieber auf die Funktionalität des Programmes konzentriere und nicht 80% meiner Arbeit in die Oberfläche stecke, nehme ich da lieber etwas, was auf allen Plattformen verfügbar ist und portiere nicht jeden Dialog rüber.
Echt Plattformunabhängigkeit gibt es bereits mit Java, dort sehen alle Programme gleich (schlecht ) aus. Und wenn ich mich nicht irre gibt es sogar für Java entsprechende Schnittstellen zum unterliegenden System, sprich native widgets.

Zitat:

Ist doch gut das sie sich die Mühe machen.

Finde ich nicht. Sie könnten schon Version 2.0 fertig haben, wenn all jene, die an den native widgets gearbeitet haben, an der Anwendung selbst entwickelt hätten.

Zitat:

(Du scheinst immer noch nicht zu verstehen, daß ich nicht verlange, daß jeder alles nochmal neu macht, aber das es ein gutes Framework geben muß.)

Du bist Programmierer, du kannst gerne anfangen. Es gibt sicherlich Leute, die sich die Finger nach sowas lecken werden. Die großen Linux-Projekte à la GIMP oder Openoffice.org werden es aber nicht sein.