Programme mit Kylix

[anda_skoa]

Hi Leute!

Wollte mal fragen, ob jemand ein oder mehrere Programme kennt, die mit Kylix entwicklet wurden.

Als Kylix angekündigt wurde, gabs einen riesigen Hype, Delphi Progs unter Windows gibts wie Sand am Meeres wurde ein wahrer Ansturm von Programmen für Linux vorhergesagt.

Von Kylix gibt es jetzt schon die zweite Version, aber Programme hab ich noch keine "in the wild" gesehen.
Woran liegt das? :confused:

In diesem Forum gehts ja ansich auch um Kylix, aber sehr viele Postings dazu gibt es nicht.

Ciao,
_

[Lin728]

Auf Sourceforge gibt eine Entwicklungsumgebung die sich DevC++ nennt, die gibts für Windows mit Delphi und seit es Kylix gibt, gibts auch ne Linux-Version.

Warums so wenige apps mit Kylix gibt:

1. Nun, bei freien Entwicklern kommt ein kommerzielles Tool nicht gut an, außerdem coden fast kein Linxu-Entwickler pascal.

3. Kylix kost was.
Unter Windows ist vieles Freeware, und das will keiner OPenSource machen. Und wenn nicht OpenSource verwendet wird, kostet Kylix was.

[anda_skoa]

Original geschrieben von ceisserer
Auf Sourceforge gibt eine Entwicklungsumgebung die sich DevC++ nennt, die gibts für Windows mit Delphi und seit es Kylix gibt, gibts auch ne Linux-Version.


Immerhin etwas.
Dem Namen nach zu urteilen aber für C++ :D



Warums so wenige apps mit Kylix gibt:

1. Nun, bei freien Entwicklern kommt ein kommerzielles Tool nicht gut an, außerdem coden fast kein Linxu-Entwickler pascal.


Hmm, möglicherweise. Aber für Pascal gibt es nicht so viele Umgebungen unter Linux wie für andere Sprachen, da sollte das Problem, dass es clsoed source ist, nicht so groß sein.
Für GPL Software ist es ja gratis, und die Component Bibliothek soll ja größtensteils LGPL sein.

Wenn es bisher wenig Pascal Programmierer unter Linux gab, sollte das doch zu einem Ansteigen führen.
Die Pascal Libs waren bisher ja nicht so umfassend (in den Libs von fpc fehlt einiges im Vergleich zu Kylix)

Also war das bisher durchaus ein Grund, eine andere Sprache zu wählen.

Mit einem Zuwachs an kleineren GUI Tools hätte ich schon gerechnet.



2. Windows-Entwickler nicht interressiert:
Viele Delphi-Entwickler sind echte computer-nieten (ich kenne genu delphi-entwickler, glaub mir), die haben mit Linux nichts am Hut. So ist es ihnen auch wurscht, was mit dieser platform passiert.


Solche Delphientwickler kenn ich auch :)



3. Kylix kost was.
Unter Windows ist vieles Freeware, und das will keiner OPenSource machen. Und wenn nicht OpenSource verwendet wird, kostet Kylix was.


Bei Shareware würd ich es eventuell noch verstehen, da besteht immerhin die mickrige Chance, dass man Geld bekommt :D
Bei Freeware versteh ich es nicht.
Außerdem haben die meisten privaten Delphitypen die ich kenne eine Professional Version.
Ich nehme mal and, dass die entweder genug Kohle dafür hatten, oder sie es sich "gratis" behshafft haben.

Bei Firmen mag das durchaus eine Rolle spielen, es wird ja auch nur von wenigen Winowsentwicklern Qt eingesetzt.

Kann natürlich sein, dass private Entwickler unter Linux einen höheren Moralwert haben :)



Stimmt, wäre echt schön, wenn mehr die chance nützen würde!


Ja, schade.
Ich dachte ebenm ich frag mal in diesem Forum.
Immerhin steht da auch Kylix in der Beschreibung.

Vielleicht kommt ja noch einer, der Kylix benutzt :cool:

Ciao,
_

[Lin728]

Ich bin derzeit noch am Überleger, was ich nach C++ und java noch so lernen soll.

[peschmae]

ich hab mal mit delphi programmiert...

aber unter linux bin ich gleich zu c++/java gekommen,
da kylix wirklich nicht das wahre ist (keine benutzbaren libs, keine komponenten, etc)

für win is delphi wirklich toll, aber für linux...
da muss sich ja jeder, der das prog im sourcecode herunterlädt die komplette entwicklungsumgebung installieren und das ist auch nicht das wahre

mfg peschmä

[Mattburger]

Ich entwickle seit Jahren auf Win mit Delphi 1-6. Zwar besitze ich die gekaufte Version von Kylix, hab diese auch schon installiert - aber leider keine Zeit für die Portierung. Die laufenden Projekte beanspruchen die meiste Zeit.

Ich denke das dürfte bei den meisten Delphi-Entwicklern der Hauptgrund sein.

Außerdem ist Delphi sehr stark an graphische Oberflächen orientiert. Die Linuxwelt ist jedoch meist mit Konsolenprogrammen oder gar Scripten zufrieden. Da ist der Einsatz eines mächtigen Entwicklungssystems einfach nicht notwendig.
Da Kylix dann auch nur für Intel/AMDs in Frage kommt ist der Umstieg auf C/C++ , oder für einfachere Aufgaben sogar Scripte, naheliegender.

Die umsonst-Mentalität der Linuxer tut da noch ein übriges. Kaum einer ist bereit für ein nützliches Tool Geld auszugeben. Da rentiert sich der Mehraufwand für die graphische Gestalltung / Internationalisierung etc. einfach nicht.

Im Laufe der Zeit werden die Linux-Anwender im Sinne des Benutzerkompforts anspruchsvoller werden. Dann wird wahrscheinlich auch die Zeit für aufwendigere graphische Software kommen und der Markt für Kylix wird wachsen. Nicht falschverstehen - es gibt bestimmt tolle Programme unter Linux - jedoch meist nur von einem Informatiker oder leidenschaftlichen Fan zu bedienen. Der Normalanwender erwartet mehr Komfort. Vergleicht einfach mal LaTeX mit Word.

Grüße Mike

[anda_skoa]

Original geschrieben von Mattburger
Ich entwickle seit Jahren auf Win mit Delphi 1-6. Zwar besitze ich die gekaufte Version von Kylix, hab diese auch schon installiert - aber leider keine Zeit für die Portierung. Die laufenden Projekte beanspruchen die meiste Zeit.

Ich denke das dürfte bei den meisten Delphi-Entwicklern der Hauptgrund sein.


Interessanter Gedanke.
Trifft halt nur auf die jenigen zu, die Windows und Linux parallel einsetzen/entwickeln.
Für Umstieger unter den Delphiprogrammieren dürfte das ja eher kein Problem sein.

Aber es wird wahrscheinlich doch einen großteil der Kylix Kunden binden.



Außerdem ist Delphi sehr stark an graphische Oberflächen orientiert. Die Linuxwelt ist jedoch meist mit Konsolenprogrammen oder gar Scripten zufrieden. Da ist der Einsatz eines mächtigen Entwicklungssystems einfach nicht notwendig.


Das lass ich dir nicht durchgehen :D
GUI Tools sind bei den Endbenutzern stark gefragt, es gäbe sonst nicht so viele KDE oder GNOME Entwickler.
Besonders wenn es schnell eine graphische Alternative geben "muss" wäre doch ein RAD wie Kylix besonders gut.
Im Moment machen halt alle Qt/GTK/KDE/GNOME Sachen in C/C++/Java/...

Das war ja auch der Grund für den Hype in der Anfangszeit, von dem ich geschrieben habe.
Das es bald von guten Applikation nur so wimmeln wird und die bisherigen GUI Entwickler sich bald mehr anstrengen müssen :)
Von ersterem hab ich aber nicht viel (gar nix) gesehen, darum auch dieser Thread.



Da Kylix dann auch nur für Intel/AMDs in Frage kommt ist der Umstieg auf C/C++ , oder für einfachere Aufgaben sogar Scripte, naheliegender.


mal ganz abgesehen davon, dass das sicher der größe Teil der Linuxdesktop user ist, hat Borland gesagt, es könnte malauf anderen Architekturen auch gehen.
Wahrscheinlich ist der Kompiler das Problem, Qt geht ja woanders auch, die GUI Componetem sollten also leicht portierbar sein.



Die umsonst-Mentalität der Linuxer tut da noch ein übriges. Kaum einer ist bereit für ein nützliches Tool Geld auszugeben. Da rentiert sich der Mehraufwand für die graphische Gestalltung / Internationalisierung etc. einfach nicht.


Bei einem freien Projekt dürfte das keine Rolle spielen.

Im kommerziellen Bereich, hätte ich halt gedacht, wird Kylix vielleicht deshalb benutzt werden, weil enteder die Windowscodebase in Delphi vorliegt, die Entwickler der Firma merh Delphi Knowhow haben, oder mit einer kürzeren Entwickungszeit gerechnet wird.

Einer Firma wäre es auch egal, wenn sie nur binaries ausliefern und auch ziemlich efgal, wenn es nur auf x86 läuft.

Außerdem dachte ich, dass speziell die graphische Seite eine stärke von Delphi ist.
Wenn das so kompiliziert ist, benutz ich gleich Qt direkt.
Wahrscheinlich ist es nur unter Windows leichter. Da wird fast kein Qt eingesetzt, und man ist sicher mit allem schneller, als mit MFC :D



Im Laufe der Zeit werden die Linux-Anwender im Sinne des Benutzerkompforts anspruchsvoller werden. Dann wird wahrscheinlich auch die Zeit für aufwendigere graphische Software kommen und der Markt für Kylix wird wachsen.


Nun, ich denke die Zeit ist schon da, sonst wäre nicht so eine große Nachfrage nach GUI Apps.
Wenn Firmen nicht genug Makrt sehen, versteh ich dass, aber Hobbyentwickelr sind davon doch nicht betroffen, oder?



Nicht falschverstehen - es gibt bestimmt tolle Programme unter Linux - jedoch meist nur von einem Informatiker oder leidenschaftlichen Fan zu bedienen. Der Normalanwender erwartet mehr Komfort.


Eben!
Darum wundere iuch mich ja, dass niemand Kylix verwendet, womit es angeblich so leicht sein soll.
(Ich hab es selber nie benutzt, aber "meine" Delphileute schwärmen von der Einfachheit)

Man findet hunderte wenn nicht tausende kleine oder mittlere Apps für Windows, die als Hobby mit Delphi privat programmiert werden.
Davon sieht man unter Linux nichts.

Ich habe diesen Thread gestartet, weil ich wissen wollte warum.
Viele regen sich auch, weil sie nicht den gewünschten Komfort haben, aber niemand scheint Delphi zu können oder so jemanden zu kennen.



Vergleicht einfach mal LaTeX mit Word.


Ich versteh was du meinst, Word ist als Textsatzsystem miserabel :)

Spaß beiseite, die beiden Programme haben ja nicht viel gemeinsam.
Man sollte vielleicht Programme vergleichen, die die selbe Aufgabe bewältigen, bzw. Zielsetzung haben.

Notepad und KEdit vielleicht.


Auf jeden Fall, danke für deinen Beitrag.
Bis auf das Architektur Problem spircht mal nichts grunsätzlich gegen Kylix.
Wahrscheinlich gibt es einfach keine Delphientiwickler untern den neuen Linuxern.

Ciao,
_

[anda_skoa]

Original geschrieben von peschmae

aber unter linux bin ich gleich zu c++/java gekommen,
da kylix wirklich nicht das wahre ist (keine benutzbaren libs, keine komponenten, etc)


Das hatte ich in Verdacht.
Hat wieder mal jemand bei der Porteurng halbe Sachen gemacht :(

Oder liegt es nicht an den Borlandkomponenten sondern am fehlen derer von Drittanbietern?



für win is delphi wirklich toll, aber für linux...
da muss sich ja jeder, der das prog im sourcecode herunterlädt die komplette entwicklungsumgebung installieren und das ist auch nicht das wahre


Naja, wenn er es selber kompilieren will.
Die meisten Desktopuser sind froh, wenn sie das nicht müssen.

Kylix zielt ja auf Desktopprogramme ab, auch wenn es in den größeren Editions Module für Serversachen gibt.

Ich hatte eben nach dem Erscheinen der Free Edition mit einem Zuwachs an Desktopprogrammen gerechnet.
So Sachen wie, mail client, news reader, Image viewer, kleine Games (Kartenspiele, Brettspiele, etc).

Kommt ja vielleicht noch.

Ciao,
_

[peschmae]

hauptsächlich liegt das am fehlen von komponenten von Drittanbietern...

aber wenn man solche verwendet, wird dann die Portierung auch komplexer:
So gibts für Delphi&Windows einige nette Komponenten zum archivieren mit zip/ace/...
Die gibts alle für Linux nicht, womit man ein kleineres Programm geradesogut neu schreiben kann (Gleiches gilt für directx, etc)

Was einfach fehlt, sind die konvertierten Headerdateien, die es unter win für fast alles gibt (z.B. lamelib.dll, etc)

MFG Peschmä

[Mattburger]

Das lass ich dir nicht durchgehen ...


War so nicht ganz gemeint. Unter Windows hat ein Programm einfach die Anforderung an die Windows Oberfläche zu erfüllen.
Unter Linux bzw. bei meinem jetzigen Kunden HP-UX tuts auch ein Script oder C-Programm welches die Ausgabe textbasiert verarbeitet oder via Pipes weiterleitet.
Hier ist die Erwartungshaltung eine andere.
- Es wäre zwar schön tut aber auch so.

Bei MFC denke ich an das Development-Studio von MS. Die MFC ist nich ganz so schlimm wie diese Umgebung. Einfach zu langsam. Das ganze geht aber auch mit dem Borland C - Compiler. schneller aber immer noch langsam.
Aber unter Linux / HP-UX hab ich auch noch keinen schnellen Compiler angetroffen.
Mit schnell meine ich 100.000 Lines in ein paar (<5) sec. Da liegt einer der Vorteile von Kylix.
Apropho Qt. Die kostet für den komerziellen Einsatz ziemlich viel Geld.



Im kommerziellen Bereich, hätte ich halt gedacht, wird Kylix vielleicht deshalb benutzt werden, weil enteder die Windowscodebase in Delphi vorliegt, die Entwickler der Firma merh Delphi Knowhow haben, oder mit einer kürzeren Entwickungszeit gerechnet wird.


Wir stossen hier aber auf ein Grundproblem bei der Softwareenwicklung.
Wurde die Darstellung sauber von der Logik und der Datenschicht getrennt, so ist eine Portierung von Delphi nach Kylix kein Problem.
Ich denke jedoch das die wenigsten Programme so geschreiben sind.
Deshalb gabs wahrscheinlich auch keine Welle an neuer Kylix Software.

Es ist wirklich sehr leicht unter Linux mit Kylix eine Applikation zusammenzuklicken.
Die stärke liegt jedoch bei managen grösserer Applikationen.
Hier vor allem der schnelle Kompiler die 2way Gestalltung also die Synchronisierung der Oberfläche mit dem Code etc. Nebenbei gibt es auch viele Komponenten für Kylix.



Wenn Firmen nicht genug Makrt sehen, versteh ich dass, aber Hobbyentwickelr sind davon doch nicht betroffen, oder?


Die meisten entwickeln privat was im Geschäft gelernt wurde. Oder man bildet sich privat weiter um es beruflich zu benutzen.
Hier liegt noch ein klarer Vorteil bei Windows.

--

Ich hab auch noch kleine Schwierigkeiten was die Umsetzung betrifft. Hier stellen sich gleich mal ein paar Fragen bei Linux:

- Wie haben die Oberflächen auszusehen? Das Aussehen und zum Teil auch die Bedienphilosophie QT und Gnome unterscheidet sich.
- welchen Standard bei den Installationsprogrammen soll ich verwenden.
- welches Drucksystem soll verwendet werden.
- Wie ersetze ich die bestehenden COM includes. (z.B. IE als HTML-Vorschau im Programm oder Fernsteuerung von Word / Excel oder Rechtschreibprüfung. etc.
- Wie erstelle ich verteilte Applikationen (DCOM hat heute schon eine starke Verbreitung).


Nach der erfolgreichen Installation von LInux / Kylix im dual-boot Betrieb (-> gleiche Maschine) habe ich dann sehr viele Nachteile im Vergleich zu Windows feststellen müssen.
Das ist natürlich sehr subjektiv und zum Teil auf meine Hardware zurückzuführen. War jedoch die Grundlage meine aktuellen Progs auf Windows weiterzuentwickeln. Später werden diese dann portiert.

- Der Debugger bei Kylix ist ca 100 mal langsamer als bei Windows. Wahrscheinlich ist das der Tribut an die Sicherheit (übergang zum Kernel).
- Der Bildschirmaufbau ist spürbar langsamer.
- Ein Teil meiner Hardware wurde nicht unterstüzt (Grafiktablett, 2 Monitorbetrieb)
- Bei wechselnder Hardware war die Umstellung sehr aufwendig. (Platte auf anderen Controller gelegt).
- Zu wenig Standards (DCOM/ Konsolenprogramme ).
- Schlechtes Drucksystem. Ghostview ist hier keine Lösung.


Grüsse Mike

[anda_skoa]

Original geschrieben von peschmae
hauptsächlich liegt das am fehlen von komponenten von Drittanbietern...

aber wenn man solche verwendet, wird dann die Portierung auch komplexer:
So gibts für Delphi&Windows einige nette Komponenten zum archivieren mit zip/ace/...


Das dachte ich mir fast. Der Vorteil komponentenbasierten Entwickelns geht natürlich flöten, wenn keine geeigneten Komponeten da sind und man sie selber schreiben muß.

Wahrscheinlich ist das der momentane Hemmschuh, der Kylix zurückhält.

Ich habe aber mal gelesen oder gehört, dass es ein Sourceforge Projekt für Kylix Komponeten gibt. MIt Kylix Komponeten mein ich jetzt solche, die eine Linux spezifische Saceh kapseln, also nur eine ObjectPascal Schnittstelle haben.

So wie die Java Classes, die mittels JNI implementiert wurden.

Hmm, ich könnte mir vorstellen, dass es für Entwickler, die C und Deplhi können, Spaß machen würde, native Komponeten zu schreiben.

Ist vom Feeling her sicher ähnlich, wie wenn es ein Modul in die KDElibs schafft :)



Was einfach fehlt, sind die konvertierten Headerdateien, die es unter win für fast alles gibt (z.B. lamelib.dll, etc)


Da muß ich mal nachfragen, umsicher zu gehen, dass ich das richtig verstanden habe:
Mit konvertierten Header meinst du, dass für diese Libs eine ObjectPascal Schnittstellen Definition verfügbar ist, richtig?
Also die C Aufrufe schon gekapselt und gemappt wurden.

Ciao,
_

[anda_skoa]

Hi Mike!

Danke für deine Beträge als Delphiprofi.
Ich freue mich, dass durch dich die Diskussion um den Bereich der professionellen Entwicklung unter Kylix bereichert wird.

Ich wollte ursprünglich eigentlich wissen, warum es noch keine Ansturm von Kylixprogrammen gibt, aber dabei eher an kleine Sachen von Privatleuten gedacht.
Ist aber interessant, wie Kylix/Linux vom Firmensektor eingestuft wird.


Original geschrieben von Mattburger


War so nicht ganz gemeint. Unter Windows hat ein Programm einfach die Anforderung an die Windows Oberfläche zu erfüllen.
Unter Linux bzw. bei meinem jetzigen Kunden HP-UX tuts auch ein Script oder C-Programm welches die Ausgabe textbasiert verarbeitet oder via Pipes weiterleitet.
Hier ist die Erwartungshaltung eine andere.
- Es wäre zwar schön tut aber auch so.


Naja, das ist mir zu verallgemeinert.
Das hängt doch von der Aufgabe des Programms ab.
Wenn es nur Daten verarbietet, dann wäre es ja Unsinn, es eng mit einer GUI zu koppeln. Das ist ja meist das Problem bei Windowssoftware.

Wenn es ein zB ein CAD Programm ist, wird das auch ein Unix Kunde gerne mit GI haben :)



Bei MFC denke ich an das Development-Studio von MS. Die MFC ist nich ganz so schlimm wie diese Umgebung. Einfach zu langsam. Das ganze geht aber auch mit dem Borland C - Compiler. schneller aber immer noch langsam.


Ich hatte eher die MFC als Classlibrary gemeint.
Da braucht man schon ware Kunstgriffe für Sachen, die bei Qt mit einem Methodenaufruf erledigt sind.
Von Erweiterbarkeit oder Sachen die gar nicht gehen ganz abgesehen.

Ein Freund von mir muß im Rahmen seiner Diplomarbeit mit MFC arbeiten.
Nur reine WindowsAPI ist schlimmer.



Apropos Qt. Die kostet für den komerziellen Einsatz ziemlich viel Geld.


"Viel" hängt davon ab, wie teuer deine Leute sind :)
Im Normalfall sind die Kosten der lib schnell herinnen, wenn man die Effektivität der Entwickler steigert.

Das ist ja auch einer der Stärken von Delphi, es reduziert die Entwicklungszeit.
Das selbe macht Qt für C++.



Deshalb gabs wahrscheinlich auch keine Welle an neuer Kylix Software.


Ich hatte ja auch eher mit neuen Sachen gerechnet, also Software, die von Leuten geschrieben wird, die von Windows auf Linux umgesteigen sind, aber bisher aus Mangel an geeigneter Entwicklersoftware nichts machen konnten.

Sind wohl keine Nur-Delphi Programmierer umgestiegen.



Die meisten entwickeln privat was im Geschäft gelernt wurde. Oder man bildet sich privat weiter um es beruflich zu benutzen.
Hier liegt noch ein klarer Vorteil bei Windows.
[/B

Das ist nur ein Vorteil, wenn deine Arbeitsplattform auch Windows ist.
Genauso könnte ich schreiben, "....bildet sich privat weiter um es beruflich zu benutzen. Hier liegt ein klarer Vorteil von Linux."

Das würde zumindest bei mir zutreffen, also so klar kann der Vorteil von Windows da nicht sein :)

Aber ich finde den Punkt ansich interessant, es sagt uns, dass es keine breuflichen Delphiprogrammierer gibt, die privat Linux einsetzen.


[B]
- Wie haben die Oberflächen auszusehen? Das Aussehen und zum Teil auch die Bedienphilosophie QT und Gnome unterscheidet sich.


Nachdem du mit Kylic ohnehin keine KDE oder GNOME Programme schreibst, muß du dich nicht an Styleguidlines halten.
GUIs sollten aber intuitiv und verständlich sein, aber das gilt für alle Plattformen.

Das Kylix für ihre Widgets Qt verwendet, wird eine Kylixapp wahrscheinlich wie ein Qt Programm aussehen, das heißt, sobald Kylix auf Qt3 portiert wurde, wird es zumindest unter KDE auch die Widgetstyles übernehmen.
(Außer Borland hat einen eigenen Style)

Vermutlich wird sich die Integration in KDE sogar noch verbessern.
Es gibt einen Vorschlag von Mattias Ettrich, eine Art Wrapperlib zu machen, gegen die QT Apps linken können, und die unter KDE dann anstatt der Qt Sachendie entsprechenden KDE Sachen benutzt (Filedialog, etc).

Aber das liegt eher in der Zukunft.

Ein Entwickler, nur eines der Basistoolkits benutzt (also GTK oder Qt) muß sich auch im irgendwelche Bedienungsphilosophien nicht so viele Gedanken machen.
Da seine App sich von den anderen abhebt, weiß ein Benutzer, dass es sich anders verhaltn kann.



- welches Drucksystem soll verwendet werden.


Das Standardsytem, PostScript.
Da Kylix ja Qt verwendet, könnte es sein, dass es Qt auch zum Drucken verwendet, weil die Applikation dann wie zB unter Windows mit den selben Befehlen auf den Drucker zeichnet, wie auf ein Widget.

Könnte aber sein, dass Borland das anders gelöst hat.
Würde mich sehr interessieren, falls das jemand hier weiß!

Wie das PS gedruckt wird, überläßt man am besten dem User. dafür braucht man ja nur einen kleinene LineEdit, damit er/sie das zu verwendende Programm angeben kann.
Zusätzlich könnte man auch versuchen festzustellen, ob man unter einem der beiden Desktopenvirnments läuft und dann eine andere Methode wählen.
Hängt davn ab, wie sehr man integrieren möchte.



- Wie ersetze ich die bestehenden COM includes. (z.B. IE als HTML-Vorschau im Programm oder Fernsteuerung von Word / Excel oder Rechtschreibprüfung. etc.
- Wie erstelle ich verteilte Applikationen (DCOM hat heute schon eine starke Verbreitung).


Damit kenne ich mich zu wenig aus.
Es gab dazu am LinuxTag2001 einen guten Vortrag von Matthias Ettrich über Universal Components. Eine Borlanderfindung, die wahrscheinlich auch von Qt mal unterstüzt wird.

Aber mit Komponeten hatte ich bisher nicht so viel zu tun, also kann ich auch die momentane Situation dazu nicht kommentieren.



- Der Debugger bei Kylix ist ca 100 mal langsamer als bei Windows. Wahrscheinlich ist das der Tribut an die Sicherheit (übergang zum Kernel).
- Der Bildschirmaufbau ist spürbar langsamer.


Das liegt sicher daran, dass Kylix selbst nicht vollständig nativ ist, sondern ein Teil davon mittels winelib portiert wurde.

Kann aber sein, dass das bei Kylix2 nicht mehr der Fall ist, aber als Nicht-Kylix User verfolge ich das nicht so :D



- Ein Teil meiner Hardware wurde nicht unterstüzt (Grafiktablett, 2 Monitorbetrieb)


Zwei Monitorbetrieb geht zumindest unter Linux im Moment sicher.
Ob es unter Kylix geht weiß ich nicht.



- Schlechtes Drucksystem. Ghostview ist hier keine Lösung.


Ich nehme an, du meinst mit Ghostview Ghostscript :)
Ist der Punkt eher von dir als Benutzer, oder von dir als Entwickler?

Ich nehme an ersteres, weil der Entwickler, wenn er nicht gerade ein neues Printsystem schreibt, ja nicht mit dem Druckertreiber zu tun hat.
Wenn die also als Benutzer die Resultate von Ghostscript nicht zusagen, könntest je nach Druckermodell eventuell mit Turboprint zufrieden sein.

Turboprint soll vorallem bei Farbdrucken sehr gut sein, sogar besser als die Treiber des jeweiligen Druckerherstellers :)

Ciao,
_

[Mattburger]

Drucken mit Kylix.

Hintergrund:
Es sollten grosse Mengen von Formularen zu Papier gebracht werden (>10.000). Hierfür habe ich eine Datenmenge welche mit einem Report-System (eigene Komponenten) die Ausgabe a) an den Bildschirm b) an den Drucker c) in spezielle Formate (PDF, PS, txt) transferieren soll.

Bei Kylix wird für die Ausgabe die qt-Library verwendet. Das hab ich schon rausgefunden. Solange die Ausgabe nur unidirektional ist geht das ganze.
Leider muss ich jedoch bei der Umwandlung in PDF z.B. die Schrittbreite jedes einzelnen Buchstabens ermitteln. Hier half mir die WIN-API (GetCharABCWidths) recht schnell weiter.
Wie mache ich das jedoch bei qt? Ganz abgesehen von Postscript.
Unter Windows lasse ich die Ausmase eines Textes bei einer Schrift von der GDI ermitteln.



Wie das PS gedruckt wird, überläßt man am besten dem User ..

Ich hätte den Preview jedoch gerne in meiner Applikation angezeigt. Der Start eines eigenen Programmes um einen Preview zu erzeugen ist hier keine Lösung. Zu langsam und es gehen zu viele Fenster auf.

Das ganze geht aber noch weiter.
Wie stelle ich z.B. den Papierschacht ein. 1. Seite Fach 1 2. und folgende Seiten über Schacht 3... Oder die Qualität des Ausdrucks farbe / sw etc.

Hier hilft die Ausgabe in Postscript nicht wirklich weiter.


Ich nehme an, du meinst mit Ghostview Ghostscript

Ich glaub da kommt meine Unerfahrenheit raus. Das meiste hab ich bisher von Büchern über Kylix /qt /gnome. Die Erfahrungswerte werden noch kommen.

Danke noch für den Tip mit Turboprint.

Grüße Mike

[anda_skoa]

Original geschrieben von Mattburger
Bei Kylix wird für die Ausgabe die qt-Library verwendet. Das hab ich schon rausgefunden.


Hab ich mir fast gedacht. Wäre ja von Borland dumm gewesen.



Solange die Ausgabe nur unidirektional ist geht das ganze.
Leider muss ich jedoch bei der Umwandlung in PDF z.B. die Schrittbreite jedes einzelnen Buchstabens ermitteln. Hier half mir die WIN-API (GetCharABCWidths) recht schnell weiter.
Wie mache ich das jedoch bei qt?


QFontMetrics.


Ganz abgesehen von Postscript.
Unter Windows lasse ich die Ausmase eines Textes bei einer Schrift von der GDI ermitteln.


Hängt wieder davon ab, wie sehr Borland die Funkiton getrennt hat.
Sonst wie oben QFontMetrics.
Postscript erzeugen wird aber unter Unix von Qt ohnehin direkt gemacht.
Ich schätze unter Windows wird in einem DeviceContext eines Druckers gezeichnet.



Ich hätte den Preview jedoch gerne in meiner Applikation angezeigt. Der Start eines eigenen Programmes um einen Preview zu erzeugen ist hier keine Lösung. Zu langsam und es gehen zu viele Fenster auf.

Ja, das versteh ich.
Da bräuchte man für Kylix noch eine Komponente. KDE Programme benutzen da eine KGhostview Komponente.



Das ganze geht aber noch weiter.
Wie stelle ich z.B. den Papierschacht ein. 1. Seite Fach 1 2. und folgende Seiten über Schacht 3... Oder die Qualität des Ausdrucks farbe / sw etc.

Hier hilft die Ausgabe in Postscript nicht wirklich weiter.


Das muß natürlich das Drucksystem unterstützen.
Wenn du sowas brauchst, mußt du CUPS nehmen.
Das kann das alles, auch remote (IPP)

Man bräuchte also eine Kylix Komponente, die libcups benutzbar macht.

Ich muß zugeben, dass ich mich programmierseitig noch nicht mit Drucken beschätigt habe.
Mir reichte es bisher zu wissen, das es unter KDE leicht zu machen ist :)

Man, so viele Möglichkeiten, was cooles zu machen :cool:
Wenn ich nicht schon ausgelastet wäre, hätte ich fast Lust mich der Kylix Komponentenentwicklung zu widmen.

Ist für mich als C++ Mensch aber wahrscheinlich nicht so einfach, eine C++ Schnittstelle hat man bei Borland glaub ich nicht, da muß man nativ code immer über C einbinden, wie bie Java JNI.

Bei C libs ja auch zielführend, aber KDE Komponenten lassen sich so schwer benutzen :(
Außerdem kranke Idee, Objektorientiert-> C -> Objetktorientiert.

Bei Qt haben die bei Borland das so gemacht. :o

Ciao,
_

[Lin728]

Doch, man kann in Kylix C-dateien einbinden.
Man braucht nur die Header-dateien und object-datein. Dazu muss man die Funktionen glaubeich mit extern definieren.
Sollte aber keine Probleme geben ,-)

[Mattburger]

Hi,

danke für die Hinweise und Tips. :)



Hängt wieder davon ab, wie sehr Borland die Funkiton getrennt hat.
Sonst wie oben QFontMetrics.
Postscript erzeugen wird aber unter Unix von Qt ohnehin direkt gemacht.
Ich schätze unter Windows wird in einem DeviceContext eines Druckers gezeichnet.


Ich glaub ich hatte da einen Dreher. Ich dachte du wolltest mir empfehlen selbst Postscript zu erzeugen und dieses dann mit Ghostscript anzuzeigen.

Ja bei Windows wird der DeviceContext des Printers verwendet. Ich nehme an bei qt wird hier QPrinter verwendet. Was ich jetzt allerdings noch nicht so ganz verstehe :
Wozu der Umweg über Postscript ?

Bleibt hier nicht viel Performance und Qualität bei der Umsetzung auf der Strecke ?

Meine Versuche mit dem HP OfficeJet G95 zeigen unter Linux durchweg schlechtere Ergebnisse. Das dauerte alles sehr Lange und sah nicht ganz so schöhn aus wie unter Windows.
Das sind natürlich nur meine persöhnlichen Erfahrungen und ich will nicht ausschliesen das es an irgendwelchen Einstellungen lag.

---

Wie sieht das denn mit den Schriften aus ? Müssen die bei Ghostscript bzw. dem ps-Umsetzer nochmal definiert werden oder kommen die aus dem KDE-System ?

Ehrlich - ich versteh die Umsetzung in Postscript nicht.

Ciao

[anda_skoa]

Original geschrieben von Mattburger
Hi,

danke für die Hinweise und Tips. :)


Bitte schön :)
Dazu ist dieses Forum ja da.



Ich glaub ich hatte da einen Dreher. Ich dachte du wolltest mir empfehlen selbst Postscript zu erzeugen und dieses dann mit Ghostscript anzuzeigen.

Ja bei Windows wird der DeviceContext des Printers verwendet. Ich nehme an bei qt wird hier QPrinter verwendet. Was ich jetzt allerdings noch nicht so ganz verstehe :
Wozu der Umweg über Postscript ?


Das hab ich missverständlich formuliert :(
Unter Qt druckt man, in dem man, wie du schon richtig vermutest, hineinzeichnet.
QPrinter ist genau so ein QPaintDevice wie ein QWidget oder ein QPixmap, amn kann also einen QPainter benutzen, um darauf zu zeichnen.

QPrinter ist jetzt vermutlich so implementiert:
Unter Windows wird ein DeviceContext des Druckers benutzt, unter X11 wird PostScript erzeugt (ob in einen stream oder in ein temp file weiß ich nicht), unter MacOSX wird vermutlich die normale UI Schnittstelle benutz um PDF zu erzeugen.



Bleibt hier nicht viel Performance und Qualität bei der Umsetzung auf der Strecke ?


Beim Generieren von PS?
Wäre interessant, das mal zu benchmarken.
Ein einfaches Qt Programm, dass ein paar Seiten in ein File druckt.
Unter Linux mit dem Qt eigenen PS Generator und unter Windows, in dem man in einem PS Printerdriver druckt.

Qualität dürfte unter der Umsetzung nicht leiden, Postscript ist schliesslich eine professiolle Seitenbeschreibunssprache, da kann alles hochgenau sein.



Meine Versuche mit dem HP OfficeJet G95 zeigen unter Linux durchweg schlechtere Ergebnisse. Das dauerte alles sehr Lange und sah nicht ganz so schöhn aus wie unter Windows.
Das sind natürlich nur meine persöhnlichen Erfahrungen und ich will nicht ausschliesen das es an irgendwelchen Einstellungen lag.


Das lag vermutlich an den Treibern.
Ich habe gelesen, dass speziell für Farbe die Turboprint Treiber erste Sahne sein sollen, außerdem könnte man auf der SourceForge Seite von HP nachsehen, ob das Modell schon von deren neuen Treibern unterstützt wird.

Treiberprobleme gibt es natürlich nur bei Nicht-PS Druckern, die PS Drucker interpretieren das PS ja selbst.



Wie sieht das denn mit den Schriften aus ? Müssen die bei Ghostscript bzw. dem ps-Umsetzer nochmal definiert werden oder kommen die aus dem KDE-System ?


Hmm, da bin ich vielleicht nicht gnaz auf dem Laufenden.
Soweit ich weiß, werden Schriften nötigenfalls in den PS output eingebettet, wenn es keine StandardPS Schrift ist.
So wie das die PS Druckertreiber unter Windows machen.

Ist aber meines Wissens erst seit Qt3 so, d.h. das bei Qt2 der PostScriptinterpreter, der dann das PS-to-Raster macht, die Schrifetn kennen mußte.



Ehrlich - ich versteh die Umsetzung in Postscript nicht.


- Garantierte Plattformunabhängigkeit.
- Unter Unix kann man immer PS drucken
- Fast alle Laserdrucker Drucker sind PS Drucker

Und vielleicht nicht einer der Gründe warum es gewählt wurde, aber ein nettes Feature:
- exportieren nach PS ist gratis :)

Ciao,
_

[peschmae]

um auf die Anfangsfrage zurückzukommen:

für mich stellt sich einfach die Frage: Wenn es gute freie Entwicklungstools gibt, wieso soll ich dann eine proprietäre Entwicklungsumgebung verwenden?

(Nicht, dass ich etwas gegen Borland hätte...)

Mit der QT lässt es sich auch in C++ komfortabel programmieren wogegen in Kylix derzeit afaik noch nicht sämtliche QT - Funktionen verfügbar sind.

MFG Peschmä

[anda_skoa]

Mir ging es mehr um Kylix als ObjectPascal Umgebung, nicht so sehr als C++ IDE.

Kann die momentane Kylixversion schon C++?
Ich dachte das wäre erst für später geplant.

Ich hatte eben mit dem Auftauchen von neuen Apps gerechnet, weil Kylix ja durch ObejctPascal praktisch eine neue Sprache zu den unter Linux verfügbaren hinzugefügt hat.

Ciao,
_

[Mattburger]

Von Borland gibt es den C++ Builder gerade in der neuen Release.
Dieser basiert auf der VCL bzw CLX.
Dies ist die Klassenbibliothek von Delphi und auch in ObjectPascal (bzw. Assembler) geschrieben.

Es stellt sich nun die Frage warum eine C++ Entwicklungsumgebung eine Pascal Bibliothek verwendet.

Nun - schlichte Performance.

Meine aktuellen Projekte umfassen ca. 60.000 - 100.000 Lines of Code. Ohne Resourcen (Formulare etc.).
Delphi und Kylix kompiliert das in ein paar Sekunden durch. Ich meine nicht 100 sec. sondern 2-5 sec. 21 - 22 - fertig. Das Ding ist kompiliert und läuft.
Vergleich das mal mit C++.

Für mich ist das ein Grund eine etwas properitäre Entwicklungsumgebung zu lernen.


Oder die Komponentenentwicklung ! Ich mache mir eine Komponente für den Zugriff zum Beispiel auf myDB.
Wenn ich das sauber programmiert habe dann ziehe ich die Komponente einfach von den Bibliotheken auf das aktuelle Formular herunter. Beim Quellcode werden die Libraries (in Pascal Units) hinzugefügt und beim Anklick auf die Methoden wird automatisch die Routine generiert. Ich entferne die Komponente wieder und der Quellcode bereinigt sich ebenfalls. Das nannten die damals (vor 4 Jahren) 2 way Tools. Da wird einfach ne menge von der Entwicklungsumgebung abgenommen.

Der andere Grund ist die Geschichte von Kylix. Angefangen von Turbo Pascal bis heute gibt es eine eingeschworene Fangemeinde. Deshalb gibt es ja auch soviele Komponenten.

Beispiel. Ich brauchte für meinen Web-Server (Indy- http Server) einen Export nach Excel. Nachdem ich die Komponenten gefunden hatte benötigte ich noch einen Abend für die Implementierung - fertig.

Da geht alles schnell und elegant.

Derzeit muss ich mit prähistorischen Werkzeugen wie vi oder dde in C hantieren.
Ich möchte nicht übertreiben aber in Delphi geht das 100 mal schneller.

Grüße Mike