vcl zu clx

[eyeless]

hallo,

ich habe gerade ein projekt in delphi fertiggestellt, allerdings mit vcl.

nun wurde angefragt, ob ich das nicht auch mit für linux machen könnte. würde ich gerne.

ich benutze unter anderem indy, jcl/jvcl, toolbar2000, ...

gibt es nun einen einfachen weg, von vcl zu clx zu konvertieren, reicht aus, wenn ich einfach ein Q davorschreibe, oder muss ich komplett neu anfangen?

ich möchte es dann in kylix bearbeiten und compilieren ...

danke schonmal im foraus ...

mfg, eyeless

[Bernhard Geyer]

Vergiss CLX. Ist von Borland eh auf Eis gelegt worden. Und ist auch nicht gerade einfach es zum laufen zu bekommen.
Du kannst aber dein VCL-Programm auch unter Linux zum laufen bekommen, wennst Du Wine installierst.

[eyeless]

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

[jbg]

Zitat:

Zitat von Bernhard Geyer

Vergiss CLX. Ist von Borland eh auf Eis gelegt worden.

Für den Zeitraum von 2002 bis 2005. Was danach ist, darüber schweigt sich Borland aus.

Zitat:

Und ist auch nicht gerade einfach es zum laufen zu bekommen.

Also ich hatte mein Software-Grundpraktikum von der Uni, das VCL ist, recht leicht nach CLX konvertieren können. Damals unterstützte die JVCL aber CLX noch offiziell. (Mit TB2000 sieht es da duster aus)

[edit=alcaeus]Zitat repariert. Mfg, alcaeus[/edit]

[Bernhard Geyer]

Zitat:

Zitat von jbg

Zitat:

Zitat von Bernhard Geyer

Vergiss CLX. Ist von Borland eh auf Eis gelegt worden.

Für den Zeitraum von 2002 bis 2005. Was danach ist, darüber schweigt sich Borland aus.

Ich würde keine Cent darauf verwetten. Aktuell stehet eher Win64 und .NET 2.0 an.
Und mit .NET ist die portablität eh viel höher, da z.B. das Mono-Projekt ziemlich aktiv ist. Und damit steht dir dann auch die Welt von MacOS offen.

Zitat:

Zitat von jbg

Zitat:

Und ist auch nicht gerade einfach es zum laufen zu bekommen.

Also ich hatte mein Software-Grundpraktikum von der Uni, das VCL ist, recht leicht nach CLX konvertieren können. Damals unterstützte die JVCL aber CLX noch offiziell. (Mit TB2000 sieht es da duster aus)

Nach CLX portieren ist relativ einfach. Aber hast du es auch auf diversen Linux-Rechnern zum laufen bekommen?
Und würde es auch mit aktuellen Kernel-Versionen auch noch laufen?

[edit=alcaeus]Zitat repariert. Mfg, alcaeus[/edit]

[FriFra]

Zitat:

Zitat von jbg

Für den Zeitraum von 2002 bis 2005. Was danach ist, darüber schweigt sich Borland aus.

Ich hab den Irrsinn ohnehin nie verstanden... Mit Kylix hätte Borland die einmalige Chance gehabt die gesamte Delphi-Gemeinde Linuxtauglich zu bekommen. Doch anstatt eine Linux-VCL zu coden (selbst virtuelle WinAPI Funktionen wären kein wirkliches Problem gewesen) kamen die mit clx :wall:
Ich dachte auch mal: "Toll, jetzt kann ich die eine oder andere Anwendung portieren", aber daraus ist nichts geworden weil der Aufwand zu groß ist. Und es gibt keinen Grund unter Linux Kylix einzusetzen, wenn man nicht seine "alten" Windows Projekte portieren kann...

[Speedmaster]

clx kann man IMHO Vergessen, entweder .NET oder SDL, oder SDL.NET( Gibts glaube ich auch ).

[Robert_G]

@FriFra
So ein Blödsinn.
Sie hätten es mit ihren paar Männeln nie geschafft die VCL komplett auf QT aufbauend hinzubekommen.
CLX ist etwas anders ja, aber es hat zum Beispiel unicode support.
Es war also gar nicht mal so dumm 2 ähnliche Frameworks zu haben, als ewig an einer QT VCL zu arbeiten.
Was übrigens ein Reinfall geworden wäre, denn Kylix war ein Reinfall. Kylix Compiler dürfte mit den neuen Kernel von Linux auch nicht mehr zurechtkommen. JBG weiß da sicher mehr?
Einfach mal in die Borland NGs schauen. Da gibt es täglich mindestens einen, der Kylix nachheult und 10 die auf ihm rumhacken...

[FriFra]

Zitat:

Zitat von Robert_G

So ein Blödsinn.
Sie hätten es mit ihren paar Männeln nie geschafft die VCL komplett auf QT aufbauend hinzubekommen.

Dann hätten sie es gleich lassen und die Resourcen sinnvoller einsetzen sollen!

Zitat:

Zitat von Robert_G

Was übrigens ein Reinfall geworden wäre, denn Kylix war ein Reinfall.

Das ist nun allerdings tatsächlich Blödsinn! 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.

[Speedmaster]

Zitat:

Zitat von FriFra

Zitat:

Zitat von Robert_G

So ein Blödsinn.
Sie hätten es mit ihren paar Männeln nie geschafft die VCL komplett auf QT aufbauend hinzubekommen.

Dann hätten sie es gleich lassen und die Resourcen sinnvoller einsetzen sollen!

Zitat:

Zitat von Robert_G

Was übrigens ein Reinfall geworden wäre, denn Kylix war ein Reinfall.

Das ist nun allerdings tatsächlich Blödsinn! 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.

Ohne vom Thema abweichen zu wollen, aber hätte erstmal ein paar Grundlegende Dinge an der Delphi Sprache ändern sollen. Und dann wäre das mit einer Qrossplatform VCL kein Problem gewesen, und auch sicher ein Erfolg geworden!

Was Borland im Moment für Probleme hat mit Delphi ist ja denke ich bekannt!

[tommie-lie]

Darf ich mal um etwas Nuhr bitten!

Zitat:

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:

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:

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:

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:

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:

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:

Zitat von tommie-lie

Zitat:

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! :warn:
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? :gruebel: )

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

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

[delphifan2004]

Hallo Ihr Streithähne!

Zitat:

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:

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 :mrgreen:

Zitat:

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:

Zitat von Robert_G

Habe ich nie gesagt! :warn:

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

[jbg]

Zitat:

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. :wall:

[tommie-lie]

Zitat:

Zitat von jbg

Zitat:

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:

Zitat von tommie-lie

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

Wolltest du auch mal? :mrgreen:

[jbg]

Zitat:

Zitat von tommie-lie

und es wird nicht davon abgeraten

Das habe ich nicht geschrieben.

Zitat:

im Gegenteil es laufen Diskussionen Mono als empfohlene Umgebung für künftige Programme zu verwenden.

Ich bin bereits auf der Mono-Seite (damit meine ich nicht die Homepage :wink: ). Es kommt mir eben von der Linux-Gemeinde so vor als ob die das nicht unbedingt wollen. (Gnome-Entwickler mal ausgeschlossen und mit Ubuntu bin ich bis auf den Namen noch nicht in kontakt gekommen)

[eyeless]

um mal zum Thema zurückzu ...

das mit dem vcl->clx weiss ich jez wie, allerding ist das für dieses Projekt etwas zu aufwendig ...

wer sich das ganze mal mit wine anschauen möchte und mir dann sagen will, warum alles verschoben ist (ICH denke mal, wegen der Schrift ... ) .. gibts hier

naja ... gibt es sonst noch irgendwelche alternativen zu kylix ... ich meine, um jez für linux zu programmieren (außer kdevelop, qt, ...), irgendwas mit pascal(/delphi)?

mfg, eyeless

[tommie-lie]

Ja, die Schriftgröße ist definitiv größer als unter einem frisch installierten Windows XP. Welchen Font verwendest du? Wie sehen die sonstigen Einstellungen der Font-Klasse aus, wenn du sie im ObjectInspector aufklappst?

Aber immerhin gibt es keine großartigen fixmes, wenn man das Programm startet, die Oberfläche und die verwendeten Komponenten funktionieren also zumindest vollständig. Einzige Ausnahme ist die Transparenz, da SetLayeresWindowAttributes() zumindest im WinE vom letzten Monat nur als Stub existiert. Ob das auch noch für die Funktionalität selbst gilt, habe ich nicht ausprobiert.

[micsie]

Zitat:

Zitat von eyeless

naja ... gibt es sonst noch irgendwelche alternativen zu kylix ... ich meine, um jez für linux zu programmieren (außer kdevelop, qt, ...), irgendwas mit pascal(/delphi)?mfg, eyeless

Wie wäre es mit Chrome für Mono?

mfg micsie

[eyeless]

@tommie-lee:also schriftart hab ich eigentlich alles so gelassen wie standart ... MS Sans Serfi (hat die linux?), größe 8, DEFAULT_CHARSET, clWindowText ...
aber ja, ansonsten läuft die anwendung super, ich kann sogar über sendmessage mit den anderen 2 anwendungen kommunizieren, indy funzt auch super .. das einzige ist noch, dass die list irgendwie nicht ajtualisiert wird, wenn ich was runterlade, erst wenn alles fertig ist ... functioniert ProcessMessages under linux nicht?

@micsie: was ist mono? und was ist dieses chrome?

mfg, eyeless

[Robert_G]

Zitat:

Zitat von eyeless

@micsie: was ist mono?

Eine Portierung des .Net Framework for Linux/Mac/Windows

Zitat:

und was ist dieses chrome?

Schaue in meine Sig oder hier. ;)

[eyeless]

hmmm .. .habs mir mal runtergeladen und angeschaut ... und hab keinen Plan, wie das funzen soll!

gibt es da irgendwo tuts oder so?

chrome für mono ist ja irgendwie nur eine commandozeilen-dinge und in mono hab ich eine glade-ide gefunden ... was mache ich damit und was hat das mit pascal zu tun?

mfg, eyeless

[Robert_G]

Sorry...
a) Ist das way OffTopic
und
b) Habe ich keine Lust dir Sachen zu erklären bei denen du zu faul zum lesen warst...

[eyeless]

mmmhh ... jaja, trotzdem danke, werz mir mal anschauen ...

[tommie-lie]

Zitat:

Zitat von eyeless

MS Sans Serfi

Hmm... die habe ich eigentlich installiert. Ich werde bei Zeiten mal schauen, was ich herausfinde. Mir fehlt nur noch ein Win32-Compiler *g*

Zitat:

Zitat von eyeless

functioniert ProcessMessages under linux nicht?

Prinzipiell schon.

[eyeless]

um nochmal auf das verschieb-problem zurückzukommen ...

jemand hat das programm für mich unter debian getestet, hat auch gefunzt, allerdings gibt die konsole folgende meldung aus:

http://img.photobucket.com/albums/v6...ll_lin_err.jpg

wohl irgendwie ein problem mit der (virtuellen?) auflösung?

und dann diese fehlermeldungen ...?

jemand ne Ahnung, was da nicht stimmt?

mfg, eyeless

[tommie-lie]

Indeed... Die Auflösung scheint bei mir nicht zu stimmen, physikalisch habe ich nur 90 statt 96 DPI (da soll doch mal einer sagen, die ALDI-CRTs seien rausgeworfenes Geld, man kriegt sogar mehr Bildfläche als üblich :mrgreen:).
Den Registry-Schlüssel kannte ich noch nicht, nachdem ich ihn auf 90DPI geändert hatte, sieht es jetzt so aus, wie im Anhang zu sehen, also normal. Das Problem bei der Checkbox in der Mitte lässt sich lösen, indem du die Komponente ein wenig breiter ziehst, die Schrift scheint nämlich immer noch größer zu sein als unter Windows.
Außerdem solltest du für Linux den Blödsinn mit dem TNA sein lassen und das Programm wie üblich in der Taskleiste anzeigen lassen, für solche Spielereien spielen GNOME (2.10 bei mir) und WinE (20050725 bei mir) noch zu schlecht zusammen.

Was für eine Message 1216 (0x4C0) ist, weiß ich nicht. WM_USER ist 0x400, was in jedem Fall niedriger ist, selbst wenn 1216 schon die hexadezimale Schreibweise ist. GetFileName95 ist keine Funktion, die ich im SDK finden kann, und beim einfachen Starten taucht der Fehler bei mir auch nicht auf. Solange nichts schlimmes passiert, kann man fixmes ignorieren, erst wenn irgendwas nicht wie erwartet funktioniert sollte man es damit versuchen, die nativen DLLs zu laden.

[eyeless]

@tommie-lie: Super, danke für deine Hilfe.

Also mache ich das mit dem TNA und andere Win-Spielereien weg.
Was muss ich nun den Benutzern dieses Programmes sagen, damit es auch bei ihnen ordentlich anzusehen ist?

"Stellt eure DPIs richtig ein!" ;) (Wie und wo?)

Nochmal Danke, mich verließ schon alle Hoffnung ;)

mfg, eyeless

[tommie-lie]

Zitat:

Zitat von eyeless

"Stellt eure DPIs richtig ein!"

Exakt das ;-)
Der Registry-Schlüssel für Wine stand ja in der Fehlermeldung, ändern kann man ihn mit dem wine-Programm "regedit", das genauso aufgemacht ist wie das gleichnamige von Windows. Dort stellt man den richtigen DPI-Wert ein, der zum verwendeten Monitor und zur verwendeten Auflösung passt. Eigenltich sollten es bei mir ebenfalls 96DPI sein, offensicthlich ist aber der Rahmen um die Röhre bei mir schmaler als üblich, deswegen habe ich eine geringere Punktdichte, wenn ich das Bild so einstelle, daß es bis zum Rand geht. Ausmessen kann man das einfach, indem man eine Seite des Bildschirms ausmisst, in Zoll (Faktor 2,54) umrechnet und durch die Anzahl der Pixel in der gemessenen Richutng teilt. Beispiel: Mein Bild ist 27cm hoch, das sind ~10,63 Zoll. Meine Vertikalauflösung beträgt 960 Pixel, 960/10,63 sind 90,3 Pixel pro Zoll.
Die anwesenden Typensetzer und Print-Spezialisten werden es mir verzeihen, wenn ich hier Punkt und Pixel gleichsetze ;-)

[eyeless]

also, ich habe jez unter HKEY_CURRENT_CONFIG/Software/Fonts/LogPixels (musste ich erst erstellen, da NUR HKEY_CURRENT_CONFIG leer existierte) ein neues dingens namens "Resolution" erstellt und 81.25 (768/(24/2.54)) eingegeben, dann wine leecher.exe und TATA ... immernoch so .. was machte ich falsch?

mfg, eyeless

[tommie-lie]

Zitat:

Zitat von eyeless

was machte ich falsch?

Wenn HKEY_CURRENT_CONFIG komplett leer war, vielleicht eine falsche Wine-Version benutzen ;-)
Oder aber mit 81.25 einen ungültigen Wert eingeben, da gehört nämlich ein Integer rein, also auf 81 runden ;-)

[eyeless]

mmhh .. wird zwar OT, aber;

habe mir das neuste wine-rpm-package runtergeladen und installiert.
wenn ich dann wine regedit.exe eingeben, ist HKEY_CURREN_CONFIG trotzdem leer, auch wenn ich dann die auflösung mit winecfg einstelle, danach immernoch leer ... was mache ich falsch?

sorry für ot ...

mfg, eyeless

[tommie-lie]

Sorry, mein Fehler, mein HKEY_CURRENT_CONFIG ist ebenfalls fast leer :mrgreen: Der einzige andere Pfad in diesem Schlüssel stammt aus den Interneteinstellungen des IE.
Geht es mit der neuen Version und bei Verwendung einer ganzen Zahl immer noch nicht?
Bei mir sieht die Registry an dieser Stelle so aus:

Code:

[System\\CurrentControlSet\\Hardware Profiles\\Current\\Software\\Fonts] 1125314402
"LogPixels"=dword:0000005a

Bei dir wären es mit 81 DPI dword:00000051 statt 51.

[eyeless]

AAAHHHHHH ... jez gez!!!

ich hatte anstatt dword einfach 81 als text eingegeben, tststs, ich dummie!

komisch nur: bei 81dpi sah es noch komisch aus, hab dan spaßenshalber mal 90 eingegeben, und es war süperb ... komisch, aber nu gez

edit: man muss die dpi wohl mit der virtuellen auflösung berechnen (bit es bei suse), somit wären es bei ca. 90/91 ...

DANKÄÄÄ, tommie-lee ...

werde nun mal schauen, wie ich es nun richtig für linux mache wohl mit cpp oder so (vorschläge für einfache ide?)

mfg, eyeless

[tommie-lie]

Zitat:

Zitat von eyeless

(vorschläge für einfache ide?)

Kommt auf deine Wünsche an.
Eierlegende Wollmilchsau -> Eclipse (Formdesigner für Gtk+-Anwendungen wäre Glade, für Qt weiß ich nichts)
Qt-Entwicklung unter KDE -> KDevelop (bin mir nicht sicher, ob der einen Form-Designer hat)
Gtk+ (bzw Gtk-- bei C++) unter Gnome -> Anjuta und Glade

(Fällt es auf, daß ich mich mit Qt noch nie beschäftigen wollte? :mrgreen:)