Delphi 10.2 LINUX Entwicklung

[MichaelT]

Zitat:

Zitat von Harry Stahl (Beitrag 1368939)

Und seit heute Abend gibt es eine Version 0.96a.:thumb:

Habe damit mal ein paar Demos aus meinem Buch getestet, sieht immer besser aus (vgl. anliegend ein Screenshot von meinem (FRAME) FMXBarChart-Demo als Linux-Programm).

Harry Stahl du bist ein sehr positiver Mensch. Ist mir wieder eingefallen als ich dein Foto sah.

Ich würde auch sagen, lassen wir uns überraschen. Unter dem Mac geht der FMX mittlerweile auch ganz passabel.

Wie ist der FMX für Linux vom arbeiten her? Vermisst du Linux als OS auf dem die Entwicklungsumgebung läuft.

Ich kann mich irgendwie beim Mac nicht ganz so recht gewöhnen nicht direkt am OS zu werkeln, obwohl mich unter Windows zu entwickeln nicht stört in dem Zusammenhang. Das hat sich auch wenig geändert mit den Remote Desktops.

Aber eine Frage. Greifst du Remote bspw. mit Teamviewer auf den Mac zu oder gibt es eine gute Lösung? Ich habe nämlich einen Mac mit U.S. Tastatur und hacke hier mit German-Austrian. Der Teamviewer ist die einzige mir bekannte Alternative die Keyboards soweit hinbringt, dass ich selbst im XCode rumwerklen kann.

Für das Display einer FMX App(lication) unter OS/X ist die Alternative mehr als ausreichend. Umgekehrt kann ich noch nicht, da mein Mac Book schon älter ist und ich keinen zweiten Monitor für die Delphi IDE hätte, selbst hätte ich ein deutsche Tastatur.

Kennt jemand eine bessere Alternative?

[Sherlock]

Die meisten Delphi->Mac-Entwickler dürften ihre Entwicklungsumgebung in einer VM auf dem Mac laufen haben. Das ist nochmal ein Stück besser als irgendein Remotedesktop zum Mac.

Sherlock

[Mavarik]

Zitat:

Zitat von sh17 (Beitrag 1367121)

Zitat:

Zitat von MEissing (Beitrag 1367118)

Zitat:

Zitat von Harry Stahl (Beitrag 1367115)

Unfassbar, dass Embarcadero nicht in der Lage ist, das selbst anzubieten...

Dafür ist der Markt zu gering....

Nur wenn der Markt so "einfach" zu erreichen ist, dann lässt man ihn weg? Oder ist der FMX-Application-Markt zu gering? Das wäre blöd...

Von meinen Kunden(>3000) und Bekannten hat KEINER einen Rechner mit Linux.
Wenige haben einen Mac(Macbook) < 100

2 Haben eine VM-drauf, alle anderen Booten das Macbook mit Windows 10.

Also ist für mich: Sowohl Mac als auch Linux(Desktop) total uninteressant.

Für EMBT war es sicherlich ähnlich - genau wie bei Windows-Phone (alle Emulatoren mal außen vor) oder Android nativ onIntel...

Mavarik

Wer hat im Bekanntenkreis einen Nicht-Programmierer, der einen Linux-Desktop-Rechner hat?

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1368992)

Wer hat im Bekanntenkreis einen Nicht-Programmierer, der einen Linux-Desktop-Rechner hat?

Ich! Mehrere sogar! Kann ich mich immer gut rausreden, wenn sie damit Probleme haben.

Gemeinerweise wird auch die Anzahl der Industriemaschinen-Steuerungen mit Linux immer größer. Das Problem bei denen ist dann allerdings wieder die bescheidene Grafikleistung.

[Der schöne Günther]

Also bei mir in Industriesteuerungsbereich ist alles sowas von Windows...

Manchmal kommen wilde Ideen auf mit Linux ein paar Euro Lizenzkosten zu sparen, aber ganz ehrlich...


Privat sehe ich selten ein paar mal Linux, meist auf uralten Rappelkisten.

[mensch72]

Bei unseren Kunden im sagen wir Finanzsoftwarebereich haben meist gute gestellte Personen oder Fimenkunden mit solchem Klientel den Wunsch doch sowas auch direkt für MAC oder für Linux zu bekommen. Technisch oder durch OS-Lizenzkosten begründet ist das eigentlich nie, eher haben die "gehört" das Microsoft&Windows böse sind und wollen deshalb sagen wir "koste es was es wolle" weg davon. Viele würden sicher mit MACs glücklich, nur dummerweise gibt es da zu wenig günstige Leute mit technischer Ahnung... da bekommt man dann eher den Kontakt zu einem angeheuertem meist recht jungem Linux Spezi, der es doch tatsächlich schafft alle technischen Hürden zu lösen und dann einem die Argumente aus, warum es denn nicht gehen soll die eigene quasi "nur" GUI lastige Software eben doch auch direkt auf dem Linux laufen zu lassen.

Finaziell rechnet es sich auch direkt gerade so, und perspektivisch nebenbei wird die Softwarestruktur besser, denn wenn DB-Core und BussinesCore so quasi zwangsläufig immer schön sauber getrennt und universell implementiert sind, dann ist es reine Geschmacksfrage und Fleißarbeit wenn man wie ich WindowsDesktop(EW&Debug) plus IntraWeb, FMX-Desktop und FMX-Mobile als 4xGUI parallel aber eben getrennt ohne totale AllInOne IFDEF Orgie realisiert.
Ich denke wer aktuell OSX-Desktop per FMX schon hat, für den sollte der Linux-Desktop per FMX nur sehr wenig Zusatzaufwand bedeuten.

Klar hängt es von der Zielgruppe ab. LinuxUI als kostenlose Zugabe wird es bei uns nicht geben... wie bei OSx native verlangen wir dafür richtig Geld und auch noch höhere Supportgebühren. (wer das nich will, nimmt die Windowsversion, notfalls in einer VM).
-> Auch Mavarik & Emba haben also durch aus Recht!

[Lemmy]

Zitat:

Zitat von Mavarik (Beitrag 1368992)

Wer hat im Bekanntenkreis einen Nicht-Programmierer, der einen Linux-Desktop-Rechner hat?

Ich: Meine Frau und meine Schwester. Meine Frau musste - wobei ihr der Umstieg von Windows XP auf Linux genauso schwer / leicht gefallen ist wie auf ein aktuelles WIndows.
Meine Schwester musste auf LInux zwangsweise umsteigen, weil deren Kids es schafften innerhalb eines Tages ein frisch installiertes WIndows 7 gegen die Wand zu fahren, weil überall auf "installieren" geklickt wurde. Seit 3 Jahren haben die Linux und seitdem keine Probleme mehr...

[MichaelT]

Zitat:

Zitat von Sherlock (Beitrag 1368988)

Die meisten Delphi->Mac-Entwickler dürften ihre Entwicklungsumgebung in einer VM auf dem Mac laufen haben. Das ist nochmal ein Stück besser als irgendein Remotedesktop zum Mac.

Sherlock

Danke.

Das hatte ich auch und war damit halbwegs zufrieden mit Parallels über 2 Jahre und nachher Virtualbox.

Ich bin an der Kippe zur Gleitsichtbrille und das führt dazu, dass ich wenn länge Zeit dem MacBook sitze einen Buckel mache und das führt zu Verspannungen. Weswegen ich auch oft bei längeren Texten Tippfehler drinnen habe. Da nehmen meine Augen das Geschriebene nicht mehr wirklich wahr. Wenn ich zurückkippe in den Non-Gleitsichtbrllenmodus, dann bestünde die Gefahr beim Spaziergang und die Randsteinkanten zu fallen. Das Zurückkippen ist im Falle des Spaziergangs durchaus sehr wahrscheinlich.

Die Remote Desktop ist tatsächlich nicht das Gelbe vom Ei aber mit Teamviewer kann ich sogar Remote mit dem XCode ein wenig etwas machen und der Teamviewer bügelt die Keymappings. Viele Remotelösungen schaffen eine German (Austria) am PC nicht mehr auf eine U.S. Layout am Mac umzusetzen.

Heute habe ich mittlerweile 2 * 4K Schirme und deswegen bin auch bezüglich Virtualbox eher auf RDP & Friends gegebenenfalls umgestiegen. Ich habe in der Virtualbox ein Internes Netz gemacht. Es ist zwar recht unterhaltsam wenn man sich ein NAT Netzwerk aufsetzt, aber die Verwaltung ist nicht ganz ohne.

Der Grund sind Services die hinter bspw. einer IPFire sitzen gemacht und die ihrerseits wieder auf einen DB Hobel zugreifen. Das für 2 Seiten. Die beiden Seiten kommunizieren miteinander. Je nach Bedarf 4 - 6 Boxen oder so konfiguriert, dass Appserver ausnahmsweise ins echte Netz auf eine DB herausgreifen. Damit habe ich alles auf einem Laptop.

[Harry Stahl]

Zitat:

Zitat von MichaelT (Beitrag 1368978)

Zitat:

Zitat von Harry Stahl (Beitrag 1368939)

Und seit heute Abend gibt es eine Version 0.96a.:thumb:

Habe damit mal ein paar Demos aus meinem Buch getestet, sieht immer besser aus (vgl. anliegend ein Screenshot von meinem (FRAME) FMXBarChart-Demo als Linux-Programm).

Wie ist der FMX für Linux vom arbeiten her? Vermisst du Linux als OS auf dem die Entwicklungsumgebung läuft.

Ich kann mich irgendwie beim Mac nicht ganz so recht gewöhnen nicht direkt am OS zu werkeln, obwohl mich unter Windows zu entwickeln nicht stört in dem Zusammenhang. Das hat sich auch wenig geändert mit den Remote Desktops.

Aber eine Frage. Greifst du Remote bspw. mit Teamviewer auf den Mac zu oder gibt es eine gute Lösung? Ich habe nämlich einen Mac mit U.S. Tastatur und hacke hier mit German-Austrian. Der Teamviewer ist die einzige mir bekannte Alternative die Keyboards soweit hinbringt, dass ich selbst im XCode rumwerklen kann.
Kennt jemand eine bessere Alternative?

Seit Mitte letzten Jahres ist mein Hauptentwicklungsrechner ein Linux-Rechner (Ubuntu 16.04 LTS).

Darauf habe ich Virtual-Box installiert, wo ich dann mehrere Betriebssyteme laufen haben, (weitere Linux-Systeme, verschiedene Windows). Hauptsächlich entwickle ich mit Delphi und dann logischerweise in der Virtuellen Maschine unter Windows 10. Soweit ich mit Lazarus arbeite, arbeite ich aber auch da grundsätzlich auf Windows, transferiere den Source auf die Linux- oder MAC Maschine und compiliere da und teste die OS-relevanten Besonderheiten aus.

Der Linux-Rechner ist sowohl über Kabelnetzwerk als auch über WLAN mit dem daneben stehenden iMAC verbunden. Ich nutze für das Deployment die Kabelverbindung, das geht irre schnell.

Wenn das Programm dann auf dem iMac startet, muss ich mich meinen Stuhl also nur ein wenig nach links schieben und kann dort bequem das Programm testen.

Ich bevorzuge diese Lösung gegenüber einer Virtuellen Windows-Maschine auf dem MAC sehr:

* Debuggen ist viel einfacher, denn ich kann das Programm normal nutzen und habe hier auf meinem Linux/Windows Rechner Delphi in voller Größ und kann bequem debuggen, ohne dass ich zwischen Host und Client hin und her schalten müsste.

* Ich kann (und habe) auf den beiden Entwicklungs-iMACs alle OS seit 10.5 installiert und kann bei Bedarf jedes Mac OS starten und dort meine Programme (deployen und) testen (mitunter gibt es da OS-relevante Unterschiede).

So wie Du es beschreibst, ist es ja eher mühsam. Für ca. 500,-- Euro (gebraucht deutlich weniger) kann man schon einen Mac Mini kriegen, da geht jeder handelsübliche Bildschirm dran. Da hättest Du auch eine deutsche Tastatur. Wenn das also im Budget noch drin sein sollte, würde ich mir das mal überlegen...

Und wenn man einmal die MAC-OS-Sachen laufen hat, ist es (mit FMXLinux) dann auch (so hoffe ich) schnell für Linux verfügbar...

Bei Linux ist es im Verhältnis zum MAC einfach sehr schön, dass man auf das gruselige Signieren und das ganze Apple/AppStore Management drum herum verzichten kann...

[Harry Stahl]

Zitat:

Zitat von mensch72 (Beitrag 1369014)

Ich denke wer aktuell OSX-Desktop per FMX schon hat, für den sollte der Linux-Desktop per FMX nur sehr wenig Zusatzaufwand bedeuten.

Klar hängt es von der Zielgruppe ab. LinuxUI als kostenlose Zugabe wird es bei uns nicht geben...

Das denke ich auch.

Linux-Programme gibt es bei mir auch nicht kostenlos, jede Plattform macht Arbeit und das muss natürlich bezahlt werden. Dazu sind die Leute aber auch bereit...

[hzzm]

Zitat:

Zitat von MichaelT (Beitrag 1369061)

Zitat:

Zitat von Sherlock (Beitrag 1368988)

Die meisten Delphi->Mac-Entwickler dürften ihre Entwicklungsumgebung in einer VM auf dem Mac laufen haben. Das ist nochmal ein Stück besser als irgendein Remotedesktop zum Mac.

Kennt jemand eine bessere Alternative?

Es geht auch anders, aber nicht ohne viele tausend Stunden Bastelarbeit. hackint0sh+vbox oder +qemu (noch schwerer). Klar ist, dass man damit nicht mal eben so kurz aufs neueste macOS (dadurch evtl. auch XCode) updaten kann. Des weiteren stellt sich bei macx86 immer die Frage nach Deiner Hardware und dem (nicht-)Vorhandensein der entsprechenden .kext's. Da kann man viel Zeit reinballern und am Ende kann es passieren, dass immer noch nichts sinnvolles dabei rauskommt.

Wenn Deine Zeit etwas Wert ist, kaufste einfach nen mac und benutzt VNC.

[Harry Stahl]

Version 1.0 von fmxlinux ist soeben veröffentlicht worden.:thumb:

Ich habe am Beta-Test teilgenommen und kann sagen, dass es nun sehr stabil läuft. Gehe daher davon aus, dass ich in ein paar Tagen einige schon bestehende FMX-Programme von mir nun auch für den Linux-Desktop zur Verfügung stellen kann.:)

Weitere Infos auf der Seite der Hersteller: www.fmxlinux.com

Erfreulicherweise ist es wohl jetzt so, dass man nur einmal eine Lizenz erwerben muss und dann alle weitere Updates frei erhält!!

[mensch72]

..."Es geht auch anders, aber nicht ohne viele tausend Stunden Bastelarbeit. hackint0sh+vbox oder +qemu (noch schwerer)"...
also sorry, wenn schon was "halblegales" dann doch bitte was ganz einfaches!

Eine VMwareWorkstion unter Windows oder Linux kann ganz simpel per "Unlo.." so modifiziert werden, das alle von VMwareFusion erstellten MacOSx VMs incl. aller Updates von OSx und XCode problemlos auch ohne OSx also HostOS laufen. Eine OSx VM kann man da von 10.7.x StepByStep auf jetzt 12.x.x kontinuierlich hochziehen und die OSx Installation sogar im AppleDevAccount normal regisitrieren und so auch alle Beta's bekommen. Da ist null sonstige "Bastelarbeit" nötig.
Unterwegs auf einem guten Standard-Notebook wäre es dann schon schick, wenn man "alles" per VM mit dabei hat und trotz lizenztechnischer Bauchschmerzen notfalls kurz was machen kann.


Ein physischer Mac ist nie verkehrt und rechtlich hier in D zwingend, aber auch da kaufe und installiere ich lieber "VMware Fusion" und nutze verschiedene virtuelle OSx samt passendem/unterschiedlichem Xcode.
Harry setzt ja Linux als Hauptsystem mit VirtualBox ein. Ob da auch (s)eine OSx VM ohne weitere Anpassungen starten würde, könnte er ja mal probieren.

Da wir hier aber alles rechtschaffende Leute sind und uns an die Apple und VMware Lizenzbestimmungen halten, nutzen&haben wir immer einen physischen Mac, denn nur damit kann&darf man aktuell ja alles was Delphi kann(Win,OSx,IOS,Android,Linux)+LinuxFMX auf einer einzigen Maschine entwickeln und testen.

[Harry Stahl]

Zitat:

Zitat von mensch72 (Beitrag 1371543)

Ein physischer Mac ist nie verkehrt und rechtlich hier in D zwingend, aber auch da kaufe und installiere ich lieber "VMware Fusion" und nutze verschiedene virtuelle OSx samt passendem/unterschiedlichem Xcode.
Harry setzt ja Linux als Hauptsystem mit VirtualBox ein. Ob da auch (s)eine OSx VM ohne weitere Anpassungen starten würde, könnte er ja mal probieren.

Da wir hier aber alles rechtschaffende Leute sind und uns an die Apple und VMware Lizenzbestimmungen halten, nutzen&haben wir immer einen physischen Mac, denn nur damit kann&darf man aktuell ja alles was Delphi kann(Win,OSx,IOS,Android,Linux)+LinuxFMX auf einer einzigen Maschine entwickeln und testen.

Das sehe ich natürlich genauso. Der einzige Unterschied ist, dass ich auf dem MAC bislang keine Virtualisierungs-Software nutzte, sondern verschiedene Boot-Partitionen, wo ich das benötigte OS dann halt nach Bedarf gebootet habe. Das hatte auch etwas mit dem Alter des MAC und wenig Speicherplatz zu tun. Bei meinem neuen MAC überlege ich jetzt allerdings schon, ob ich hier auch mit Virtual-Box arbeiten sollte.

[Darlo]

Hallo,

kennt jemand einen Anbieter der Virtual-Linux-Server mit Desktop anbietet?

Gruß

[mkinzler]

Nicht unbedingt notwendig. Ein lokaler X-Server reicht.

[Darlo]

Zitat:

Zitat von mkinzler (Beitrag 1371771)

Nicht unbedingt notwendig. Ein lokaler X-Server reicht.

Kannst du das näher erläutern? Meinst du x-server installieren?

[Harry Stahl]

Sieht so aus, als ob Strato das anbietet:

https://www.strato.de/server/linux-vserver/

[Darlo]

Zitat:

Zitat von Harry Stahl (Beitrag 1371790)

Sieht so aus, als ob Strato das anbietet:

https://www.strato.de/server/linux-vserver/

Hatte da schon nachgeschaut und nix gefunden. Oder überlese ich etwas? Folgendes Bild interpretiere ich so: Windows = bunte Bilder; linux = shell

https://www.strato.de/_assets_de/ima..._locked_xl.png

[mkinzler]

Zitat:

Zitat von Darlo (Beitrag 1371789)

Zitat:

Zitat von mkinzler (Beitrag 1371771)

Nicht unbedingt notwendig. Ein lokaler X-Server reicht.

Kannst du das näher erläutern? Meinst du x-server installieren?

Ja. X-Server auf Windows installieren. Diesen Server kann man dann von Linux aus verwenden

export DISPLAY=<Windowsrechner>:0.0

[sh17]

Boar, was nicht alles geht, FmxLinux-Anwendungen im Browser bedienen

https://www.youtube.com/watch?v=67xz...ature=youtu.be

Kann Emba FmxLinux nicht "nochmal" aufkaufen? Ich hätte das gern integriert ins Delphi. Separat gefällt mir das alles nicht.

[mkinzler]

Dieses Feature bekommt man quasi umsonst. Dieser "Gateway" funktioniert bei allen GTK-Programmen.

[sh17]

Zitat:

Zitat von mkinzler (Beitrag 1383939)

Dieses Feature bekommt man quasi umsonst. Dieser "Gateway" funktioniert bei allen GTK-Programmen.

Das Gateway ist klar. Ich meinte eher FmxLinux selbst und am Besten auch noch CrossVCL

[Uwe Raabe]

Zitat:

Zitat von sh17 (Beitrag 1383935)

Kann Emba FmxLinux nicht "nochmal" aufkaufen? Ich hätte das gern integriert ins Delphi. Separat gefällt mir das alles nicht.

Ich vermute allerdings, daß die rasanten Fortschritte bei FmxLinux und CrossVCL unter dem Dach von Embarcadero wohl nicht erreicht würden.

[mkinzler]

Diese schnelle Entwicklung scheint mit der "Fast Development Rules"-Strategie von Atanas Popov nicht in Einklang zu bringen sein ;) :gruebel:

[Codehunter]

Mir war CrossVCL bis dato nicht bekannt und habe erst heute davon erfahren. Habe mir die Videos angeschaut. Der erste Gedanke: Heureka! Der zweite Gedanke: Star Citizen for Business. Dritter Gedanke: Mist - Linux Compiler gibts erst ab Architekt.

Dann fing ich an darüber zu philosophieren, was hat Eugene Kryukov bewogen, ein solches Projekt anzugehen? Dass er etwas auf dem Kasten hat, das hat er ja schon bewiesen. Aber die VCL X-Plattform zu machen, das wirkt erstmal so aberwitzig. Vorallem angesichts der Entwicklungszeit, die zuvor schon in CLX und FMX geflossen ist. Gerade das Kylix-Desaster hätte eigentlich Warnung genug sein sollen.

Allerdings ist inzwischen die VCL auch nicht mehr die selbe wie sie vor gut 20 Jahren zu Kylix-Zeiten war. Die wilden API-Calls innerhalb der visuellen Komponenten sind weitgehend verschwunden. Alles wurde zentralisiert, auch oder gerade wegen der Theme Engine. Deshalb denke ich an der Stelle schon, dass es möglich ist mit der heutigen VCL sowas zu bauen. Die Entwicklungsumgebung (Delphi) an sich muss doch gar nicht auf Linux oder MacOS laufen. Das war auch so ein Fehler der damals bei Kylix gemacht wurde.

Um mal ein Beispiel aus der Praxis zu bemühen: In München wird gerade mit viel Aufwand das LiMux-Projekt beerdigt, das zuvor jahrelang mit viel Aufwand gepäppelt wurde. Gescheitert ist es dem Vernehmen nach vorallem an Fachanwendungen, die von kleinen Softwareschmieden geliefert wurden und die keine Möglichkeit hatten, diese mit vertretbarem Aufwand nach Linux zu portieren. Mit Wine läuft eben vieles, aber nicht alles.

In der Regel waren das Datenbank-Frontends mit komplexen Reportgeneratoren. Mal angenommen (ich weiß es nicht!), diese Anwendungen wären mit Delphi erstellt und Softwareschmiede XYZ hätte nur in ein Delphi Architekt und eine CrossVCL-Lizenz investieren müssen. Sagen wir mal 5000 Euro Investition, um ein Millionenprojekt zu retten. Wäre das nicht wirtschaftlich sinnvoll gewesen?

Ich finde das gerade deshalb so interessant, weil ich in letzter Zeit einige Experimente mit Linux beim Endkunden mache. Dabei geht es weniger um fallspezische Lösungen. Vielmehr hat mich interessiert, wie ganz normale Büroanwender reagieren, wenn sie statt einem Windows ein Linux (Mint 18.2) vorgesetzt bekommen. Dabei war ich ganz erstaunt, wie "änderungstolerant" die Leute geworden sind. Vor 10, 15 Jahren war das undenkbar. Bis Windows XP waren die Denkmuster festgefahren. Aber seitdem verändert sich Windows rasant, insbesondere Win10. Die Leute haben sich daran gewöhnt, dass sich Startmenü & Co. von einem Tag zum anderen verändern können, wenn über Nacht mal wieder ein großes Update eingespült wurde. Auf einmal bleibt der Kulturschock aus, wenn sie plötzlich vor einem Linux sitzen.

Viele Business-Delphi-Anwendungen sind dröge Datenbank-Frontends. Seit Jahr(zehnt)en gewachsen, am Markt etabliert und stabil. Warum bei sowas noch mal mit viel Aufwand bei 0 (oder 10) anfangen, zig hundert Stunden investieren und X-Plattform (FMX) bauen, wenn man mit überschaubaren Beträgen so etwas wie CrossVCL verwenden könnte? Die Kunden mit ganz viel Geld können die Anwendung dann nativ auf ihrem Mac laufen lassen, die Kunden mit ganz wenig Geld setzen Linux ein und alle dazwischen verwenden Windows.

Mal ehrlich, gibt es nicht viele Delphianer, die seit vielen Jahren VCL-Anwendungen schreiben und schlicht keine Lust haben, von Grund auf mit FMX noch mal neu zu lernen? Seit Jahren dreht sich diese Diskussion doch schon im Kreis. FMX ist ein tolles Framework und es funktioniert inzwischen auch recht gut. Allerdings ist eben allein schon das Benennungsschema der Properties im Objektinspektor so fundamental anders, dass man anfangs ungemein viel Zeit in der Onlinehilfe verbringt. Mein "Lieblingszitat" ist da inzwischen: "Embarcadero Technologies verfügt zurzeit über keine zusätzlichen Informationen. Bitte unterstützen Sie uns bei der Dokumentation dieses Themas, indem Sie Ihre Kommentare auf der Diskussionsseite eingeben.".

Aber auch abseits persönlicher Befindlichkeiten gibt es handfeste Argumente gegen eine Portierung bestehender Anwendungen nach FMX. Das treffendste ist immer die Geldfrage. Wenn man viele Mannstunden aufwendet, um ein Programm auf den Mac zu bekommen, nur um dann festzustellen dass es an einer bescheidenen Komponente scheitert, die mal zugekauft war und nicht mehr supportet wird. Da würde mir mein Chef mit dem nackten Arsch ins Gesicht springen. Wenn nicht Android und iOS das Ziel sind sondern ausdrücklich Desktop-Anwendungen, dann spricht nicht viel für eine FMX-Migration.

Dass die jahrelang gerade aus Richtung Redmond propagierte Konvergenz aus Mobil und Desktop gescheitert ist, das haben die Leute bei Microsoft inzwischen selbst einsehen müssen: "Of course we'll continue to support the platform.. bug fixes, security updates, etc. But building new features/hw aren't the focus." (Joe Belfiore über Windows 10 Mobile). Unter diesem Paradigma könnte man auch FMX sehen: Als Framework für mobile Anwendungen definitiv ja, als Grenzgänger zwischen Mobil und Desktop dagegen nicht. Das wollen die Nutzer schlichtweg nicht weil Maus- und Touchbedienung eben zwei völlig verschiedene Konzepte sind. Der Versuch, diese zu vereinen, wird IMHO scheitern - siehe eben Windows 10 Mobile, aber auch RemixOS (Android), Unity (Ubuntu Linux), Chrome OS oder die jüngsten iTunes-Updates. Die Zeichen stehen im Moment eher auf Trennung zwischen Mobil und Desktop statt auf Vereinigung.

In einem eng abgesteckten Rahmen finde ich das Projekt CrossVCL sehr faszinierend. Fokus ausschließlich auf den Desktop, auf Businessanwendungen, DB-Frontends usw. Dass es inzwischen einen VST-Port gibt, finde ich ja schon mal ganz toll. Nur müsste der mit dem Main-Branch gemerged werden. Sonst ist all die Müh' vergebens wenn das nächste VST-Update von JAM Software kommt. Dass z.B. UniDAC von Devart wunderbar X-Plattform funktioniert weiß ich schon aus eigener Erfahrung. Deshalb sind X-Plattform-DB-Aware-Komponenten ja so wichtig.

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1383959)

Dritter Gedanke: Mist - Linux Compiler gibts erst ab Architekt.

Ab Enterprise gibt es den bereits.

[Codehunter]

Zitat:

Zitat von jaenicke (Beitrag 1383971)

Zitat:

Zitat von Codehunter (Beitrag 1383959)

Dritter Gedanke: Mist - Linux Compiler gibts erst ab Architekt.

Ab Enterprise gibt es den bereits.

Danke für die Berichtigung. Dennoch sehe ich gut 2500 Euro Aufpreis, die nicht zu rechtfertigen sind wenn der Linux-Compiler das einzige Feature ist, das ich mehr benötigen würde im Vergleich zur Professional. Diese Preise tun ja inzwischen sogar Mittelständlern schon weh, wenn sie hauptsächlich für den Hausgebrauch entwickeln.

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1383973)

Dennoch sehe ich gut 2500 Euro Aufpreis, die nicht zu rechtfertigen sind wenn der Linux-Compiler das einzige Feature ist, das ich mehr benötigen würde im Vergleich zur Professional.

Ja, der Umstieg ist leider sehr teuer, was ich auch sehr kritisch sehe. Denn wenn man schon einige Jahre mit Wartungsvertrag unterwegs ist und dementsprechend niedrige Preise hat, verliert man in mehrerer Hinsicht...

Dann muss man nun erstens den Wechsel durch ein Update bezahlen und steigt dann auch noch deutlich teurer in den Wartungsvertrag für die höhere Edition ein.

An der Stelle bin ich froh, dass wir damals nicht den Fehler gemacht haben und die Professional genommen haben. In der Sackgasse stecken leider einige, die ich kenne.

[sh17]

Sollte sich CrossVCL als stabil in Anwendung und Support erweisen (nützt nix, wenn es nächstes Jahr wieder weg ist), würde ich auch den Schritt zu Enterprise wagen.

[Harry Stahl]

Das FMXLinux ist schon echt gut brauchbar. Probleme werden recht zügig innerhalb weniger Stunden oder weniger Tage behoben.

CrossVCL habe ich mir auch schon geholt. VCL-Anwendungen auf FMX umzustellen ist langwierig und fehleranfällig. Insofern könnte CrossVCL eine echte Alternative sein, um VCL-Anwendungen zum MAC oder zu Linux zu bringen, denn die grundsätzliche Programmlogik bleibt erhalten.

Bin gerade dabei, eine Server-Anwendung mit CrossVCL auf MAC und Linux umzustellen. Noch funktionieren eine Reihe von Dingen nicht (ist ja auch noch nicht die endgültige Version), aber dennoch ist man erstaunt, was schon alles geht.

[Codehunter]

Zitat:

Zitat von jaenicke (Beitrag 1383975)

Ja, der Umstieg ist leider sehr teuer, was ich auch sehr kritisch sehe. Denn wenn man schon einige Jahre mit Wartungsvertrag unterwegs ist und dementsprechend niedrige Preise hat, verliert man in mehrerer Hinsicht...

Dann muss man nun erstens den Wechsel durch ein Update bezahlen und steigt dann auch noch deutlich teurer in den Wartungsvertrag für die höhere Edition ein.

An der Stelle bin ich froh, dass wir damals nicht den Fehler gemacht haben und die Professional genommen haben. In der Sackgasse stecken leider einige, die ich kenne.

Interessant. Dieser Umstand war mir noch gar nicht so bewusst, da ich NIE mit Wartungsvertrag unterwegs bin sondern in ungleich größeren Abständen migriere wenn es wieder einmal ein Killerfeature gibt. FMX war z.B. mal so eins, weil ich unbedingt eine Android-Anwendung brauchte. x64 war auch so eins, weil die Anwender nach x64 schrien (obwohl das effektiv kaum einen Unterschied zu x86 macht). Inzwischen liefere ich nur noch x64 aus und bin so auch gleich ein paar lahme Uraltkisten beim Anwender los geworden.

Einfach gesagt ich kaufe statt zu leasen. Dass Emba hier aber sogar die treuen Stammkunden so ungeniert abschöpft erschreckt mich ein wenig und lässt mich eher von dem Gedanken noch weiter abrücken, jemals eine Subscription abzuschließen.

( @MEissing liest du mit? )

Den Linux-Compiler in der Oberklasse einzusortieren halte ich für einen strategischen Fehler seitens Embadera. MacOS x86 bekommt man schon ab der Pro, Linux nur ab Enterprise. Das finde ich widersprüchlich. Linux auf dem Desktop sollte man mit allen Mitteln fördern, statt mit hohen Preisen zu torpedieren. Ich glaube, Emba scheint noch gar nicht so ganz klar zu sein, was Delphi+CrossVCL bedeuten würde: Es wäre eine Alternative zu Qt, GTK und Java. Ich meine damit nicht technisch sondern eher produktstrategisch. Auf einmal ließen sich eine ganze Reihe bestehender Anwendungen mit überschaubarem Aufwand nach Linux migrieren.

Mein früheres LiMux-Beispiel kommt ja nicht von ungefähr. Viele Augen haben da auf München geschaut. In vielen Verwaltungen rumort es. Man sagt mehr oder weniger offen, dass man weg will von Microsoft und den USA. Ich kann zwar nicht für München sprechen, wohl aber für hiesige Verwaltungen. Und da sehe ich eine ganze Reihe von Fachanwendungen, die mit Delphi geschrieben sind. Eine der hakeligsten darunter ist das Kataster. Der Hersteller hat irgendwie die Entwicklung verschlafen, ist bei Windows XP hängen geblieben und werkelt seit 10 Jahren an einer Nachfolgeversion die auch unter Win7+ läuft. In der Not haben die Verwaltungen ein XP virtualisiert laufen weils nicht anders geht. Ein alternativer Anbieter steht in den Startlöchern, dessen Anwendung auch in Delphi geschrieben ist. Es hapert nur an der Datenmigration. Nun war aber auch in der Verwaltung jemand so schlau und hat mal Linux ins Pflichtenheft geschrieben. Zwar unter nice-to-have aber immerhin.

Gestern habe ich interessenhalber mal bei eben diesem Anbieter angerufen und nachgefragt, ob man denn CrossVCL auf der Agenda hätte. Denen ging es wie mir: Noch nie gehört und man merkte sofort, da war jemand vom Hocker gefallen. Ich bin dann bis zum Leiter der Entwicklung verbunden worden. Der hat mir klipp und klar gesagt: Das was Windows in den Verwaltungen hält sind Bestandsanwendungen, die sich nicht mit vertretbarem Aufwand migrieren lassen. FALLS CrossVCL mehr sein sollte als ein Sturm im Wasserglas, dann würde das in seiner Firma einiges radikal verändern. Denn er hätte inzwischen einen meterhohen Stapel an Anfragen von Stadtverwaltungen zu einem Linux-Client.

Ich hab dann interessenhalber mal gefragt, mit welcher Edition die denn arbeiten. Und siehe da: Überwiegend Professional, Architekt nur auf einer einstelligen Zahl Arbeitsplätze. Wird man auch nicht ändern, aus Kostengründen.

Also, @Emba: Packt doch bitte den Linux-Compiler in die Pro-Edition. Lasst das Kind doch erst mal groß werden und in ein paar Jahren schauen wir noch mal neu.

[bytecook]

Hmmm, ich brauch eigentlich nur die Professional Version für unsere Entwicklung, nur für den Linux Support ist mir der Aufwand "Enterprise" auch zu hoch.
Ein Linux-Addon plus Maintenance für die Pro Variante könnte ich mir hingegen gut vorstellen. Derzeit setze ich zur Linux Unterstützung Lazarus parallel zu Delphi ein.

[Codehunter]

Zitat:

Zitat von bytecook (Beitrag 1384000)

Derzeit setze ich zur Linux Unterstützung Lazarus parallel zu Delphi ein.

Ja, das habe ich mir auch angeschaut. Da kamen so nostalgische Gefühle hoch. Delphi 5 und so... ;-) Also für kleinere Projekte kann man Lazarus durchaus her nehmen. Aber eine Migration einer bestehenden Anwendung zu Lazarus/FPC ist ein ähnlich hoher Aufwand wie zu FMX. Allerdings werde ich immer mehr ein Fan neuerer Delphi-Sprachfeatures wie Generics und anonymer Methoden. Erstere gehen mittlerweile in FPC, letztere wohl noch nicht (hab aber auch nicht mehr nachgeschaut).

Bei einem neuen, großen Projekt völlig auf Lazarus zu setzen, halte ich für gewagt. Denn machen wir uns nichts vor: So toll die IDE inzwischen auch ist, es fehlen viele kommerzielle Komponenten. Die freien Alternativen können da schlicht nicht mithalten. Und für Leute die mit dem Coding Geld verdienen müssen ist es eine Pest, wenn sie ein Rad neu erfinden müssen.

[bytecook]

Zitat:

Zitat von Codehunter (Beitrag 1384003)

Zitat:

Zitat von bytecook (Beitrag 1384000)

Derzeit setze ich zur Linux Unterstützung Lazarus parallel zu Delphi ein.

*snip* Also für kleinere Projekte kann man Lazarus durchaus her nehmen. *snip*

Genauso halte ich es auch. Kleinere Projekte mit dem RPI3/Laz find ich toll :) Dafür kannst vermutlich eh kein Delphi nehmen, denke es werden nur Intel Prozessoren unterstützt.

[Harry Stahl]

Zitat:

Zitat von Codehunter (Beitrag 1384003)

Also für kleinere Projekte kann man Lazarus durchaus her nehmen. Aber eine Migration einer bestehenden Anwendung zu Lazarus/FPC ist ein ähnlich hoher Aufwand wie zu FMX. Allerdings werde ich immer mehr ein Fan neuerer Delphi-Sprachfeatures wie Generics und anonymer Methoden. Erstere gehen mittlerweile in FPC, letztere wohl noch nicht (hab aber auch nicht mehr nachgeschaut).

Nur mal als Randbemerkung, man kann nicht nur kleinere Projekte mit Lazarus machen. Meine größten und umsatzstärksten Projekte wurden für die Plattformen MAC und Linux mit Lazarus erstellt (schon vor 2011, da konnte man das mit Delphi noch nicht).

Wenn die Unterstützung für Linux mit FMXLinux nicht gekommen wäre, hätte ich mir echt überlegt, ob ich meinen Schwerpunkt der Desktop-Entwicklung zu Lazarus verlagern muss (weil mir die Linux-Plattform wichtig ist). Was ich aber in gewisser Hinsicht bedauert hätte, denn trotz Anerkennung für die Super-Leistung der Lazarus-Entwickler muss ich sagen, dass Delphi mir einfach mehr liegt (und auch mir Generics, anonyme Prozeduren und Parallel-Library gefallen). Die Lösung mit dem PAServer ist auch einfacher, als für jedes OS ein Entwicklungssystem vorzuhalten, zumal es da auf dem MAC mit Lazarus immer wieder Probleme mit dem Debuggen gibt.

Aber insofern schön, dass Linux-Entwicklung nun auch mit Delphi möglich ist. Nach meinem Verständnis gehört das allerdings auch schon in die Pro-Version rein und EMBA müsste FMXLinux aufkaufen und in Delphi fest integrieren (wobei ich es durchaus begrüßen würde, die weitere Entwicklung und Pflege bei KSDEV zu lassen, denn die wissen was Sie tun und können das deutlich schneller als EMBA).

[Codehunter]

Zitat:

Zitat von Harry Stahl (Beitrag 1384054)

Nur mal als Randbemerkung, man kann nicht nur kleinere Projekte mit Lazarus machen. Meine größten und umsatzstärksten Projekte wurden für die Plattformen MAC und Linux mit Lazarus erstellt (schon vor 2011, da konnte man das mit Delphi noch nicht).

Es stellt sich natürlich die Frage wie representativ diese Projekte sind. Ich würde es eher so sagen: Lazarus hat Emba Beine gemacht so wie AMD Ryzen Intel Beine gemacht hat. Die kleinen können die Größen durchaus ärgern.

Zitat:

Zitat von Harry Stahl (Beitrag 1384054)

Nach meinem Verständnis gehört das allerdings auch schon in die Pro-Version rein und EMBA müsste FMXLinux aufkaufen und in Delphi fest integrieren

Ähm. Nö. Lass mal so wie es jetzt ist. Jetzt kriegt man das zum gleichen Preis für alle Editions. Bei Emba würde das nur in die Ar(s)chitect-Edition gepackt. Vermutlich sind die Preise bei Emba auch wegen der ständigen Firmenaufkäufe so explodiert. Devart hat die Preise für Unidac im Vergleich zum letzten Jahr auch fast verdoppelt. Das ist eine schreckliche Unsitte geworden. Und die Frage sei erlaubt, wie lang der Markt (also wir!) das in der Form noch mit macht bzw. mitmachen kann.

[Harry Stahl]

Zitat:

Zitat von Codehunter (Beitrag 1384058)

Zitat:

Zitat von Harry Stahl (Beitrag 1384054)

Nach meinem Verständnis gehört das allerdings auch schon in die Pro-Version rein und EMBA müsste FMXLinux aufkaufen und in Delphi fest integrieren

Ähm. Nö. Lass mal so wie es jetzt ist. Jetzt kriegt man das zum gleichen Preis für alle Editions. Bei Emba würde das nur in die Ar(s)chitect-Edition gepackt. Vermutlich sind die Preise bei Emba auch wegen der ständigen Firmenaufkäufe so explodiert. Devart hat die Preise für Unidac im Vergleich zum letzten Jahr auch fast verdoppelt. Das ist eine schreckliche Unsitte geworden. Und die Frage sei erlaubt, wie lang der Markt (also wir!) das in der Form noch mit macht bzw. mitmachen kann.

OK, da könnte was dran sein. Also belassen wir es bei KSDEV. Dennoch sollte Linux-Entwicklung schon ab Prof. möglich sein (habe selber die Enterprise, aber dennoch).

Hat sich eigentlich jemand von Euch auch schon von KSDEV die Delphi-Styles, incl. FM UI Plus gezogen und kann was dazu sagen?

[Codehunter]

Fast übersehen. Auch wenns ein wenig am Thema vorbei geht:

Zitat:

Zitat von bytecook (Beitrag 1384047)

Kleinere Projekte mit dem RPI3/Laz find ich toll :) Dafür kannst vermutlich eh kein Delphi nehmen, denke es werden nur Intel Prozessoren unterstützt.

Da war mal was...

Womit sich umso mehr die Frage stellt: Will man nun mit dem Linux-Compiler die Maker-Szene ansprechen? Mit "Enter-Preisen"? Da erschließt sich mir die Logik nicht.

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1383999)

Dieser Umstand war mir noch gar nicht so bewusst, da ich NIE mit Wartungsvertrag unterwegs bin sondern in ungleich größeren Abständen migriere wenn es wieder einmal ein Killerfeature gibt.

Mich würde interessieren wie viel du dafür ungefähr über die Jahre dann ausgegeben hast. Ich kenne mehrere Beispiele, in denen für die Professional Version durch diese Strategie mehr ausgegeben wurde als mit Subscription für die Enterprise fällig gewesen wäre (von der Subscription für die Professional ganz zu schweigen)... ;-)