Einzelnen Beitrag anzeigen

tommie-lie
(Gast)

n/a Beiträge
 
#47

Re: Portabilität zwischen Linux und Windows?

  Alt 14. Dez 2005, 14:47
Zitat von mh166:
Also mal nach entsprechenden Sourcen umschauen... im Prinzip also nach "Gtk# Assembly Delphi" googlen. Oder heißt das anders?
Hm, Google mag das # hinter Gtk wohl nicht, zumindest findet Google bei mir nicht viel sinnvolles. Eine Suche nach Delphi und Mono wäre vielleicht vielversprechender. Wenn du dann rausgefunden hast, wie du in Delphi eine Mono-Assembly einbindest, kannst du das mit der Gtk#-Assembly tun und die Funktionen daraus aufrufen. Die Beispiele finden sich ja in der Doku bzw den Gtk#-Tutorials, der Rest ist Übersetzungsarbeit von C# nach Delphi. Du kannst aber wie gesagt auch WinForms nehmen, ich schätze daß besonders unter Windows das die unkompliziertere Lösung ist. Wenn du von Anfang an mit Mono testest und nicht erst unter .NET, kannst du ja auch gleich sehen, welche Funktionen nicht funktionieren und dich entsprechend früh um eine Alternative kümmern.

Zitat:
Zitat:
aber "apt-get install libgtk2.0-cil" wird unter Windows wohl nicht funktionieren
In der Tat. Schade eigentlich.
Jupp, ich weiß auch nicht, warum Windows-User immer die One-Click-Installation anpreisen, unter Linux habe ich das mindestens genauso

Zitat:
Scheint aber ziemlich umfangreich, das immer zu verknüpfen. Obs da nen einfacheren Weg gibt? Also z.B. irgendne Möglichkeit Gtk# in Delphi für den Formdesigner einzubinden?
Nein, es gibt neben Glade keinen Designer für Gtk+/Gtk#. Für WinForms wird beispielsweise auf die Klassen aus System.Windows.Forms.Design zurückgegriffen, etwas derartiges existiert für Gtk# (noch) nicht.
Das Prinzip ist aber gleich, du könntest also eine WinForms-Anwendung designen und dann nachträglich die Klassen- und Methoden-Namen ändern, wo dies notwendig ist (Window in Gtk# is beispielsweise in WinForms ein Form), ob das vom Aufwand her unbedingt besser ist, darüber wage ich nicht zu urteilen

Zitat von yankee:
Btw: Gänge sowas unter dotNET? Also ich hab jetzt noch keinen Plan über die Schnittstelle, aber ist es möglich durch so ein Framework dann solche eigentlich ja direkten Hardwarezugriffe (plattformunabhängig?) zu lösen?
Hier ist ein Beispiel für COM-Ports unter Windows. Es sieht danach aus (kann die ZIP-Datei nicht ohne Anmeldung runterladen), als würde er dafür die virtuellen Dateien des HAL benutzen. Das Funktioniert mit dem devfs bzw sysfs unter Linux prinzipiell auch, allerdings werden hier die Devices anders heißen (/dev/tty0 für COM1, beispielsweise).
  Mit Zitat antworten Zitat