CrossVCL tot?

[Codehunter]

Moin!

Ich habe nach längerer Zeit mal wieder bei CrossVCL vorbei geschaut. Irgendwie kann ich keinen "Order"-Link mehr finden. Im Bugtracker gibt es viele offene Tickets. Github listet seit gut einem Jahr keine Contribs mehr für Eugene. Ist dieses vielversprechende Projekt leise verschieden?

Grüße
Cody

[Rollo62]

Wird vielleicht gerade intergiert in 10.4 :stupid:

[freimatz]

vielversprechend? Ich konnte und kann mir nicht vorstellen wie das alles zuverlässig funktionieren soll.
Vielleicht war es - wie das auf dem Bild zu sehen ist - zu steinig. ;-)

[Codehunter]

Zitat:

Zitat von freimatz (Beitrag 1457882)

vielversprechend? Ich konnte und kann mir nicht vorstellen wie das alles zuverlässig funktionieren soll.
Vielleicht war es - wie das auf dem Bild zu sehen ist - zu steinig. ;-)

Zumindest die downloadbare Demo sah vielversprechend aus. Insbesondere Virtual Treeview auf Linux lief erstaunlich gut. Da ich aber kein Enterprise-Delphi habe und Cpt. Kirk nicht mit mir spricht, konnte ich das nicht selbst kompilieren. Für MacOS hätte ich mit der CE kompilieren können, aber da habe ich wieder keinen Mäck zum ausprobieren.

Letztendlich wenn man sich die aktuellen VCL-Quellen so anschaut, wird da schon viel abstrahiert. Der Grundstein wurde wohl schon zu Kylix-Zeiten gelegt. So gesehen wäre CrossVCL "nur" die logische Fortsetzung von Kylix. Also ich denke schon dass es möglich wäre, die VCL portabel zu machen.

[jaenicke]

Hmm, seit fast einem Jahr ist Ruhe auf allen Kanälen. Er war zwar auch vorher nicht so aktiv wie andere, aber eine so lange Pause ist schon ungewöhnlich.

[Uwe Raabe]

Die letzte Version von CrossVCL habe ich am 2.11.2019 bekommen. Extrapoliert man das bisherige Release-Verhalten sollte es bald wieder eine Version geben.

[Codehunter]

Zitat:

Zitat von Uwe Raabe (Beitrag 1457895)

Die letzte Version von CrossVCL habe ich am 2.11.2019 bekommen. Extrapoliert man das bisherige Release-Verhalten sollte es bald wieder eine Version geben.

Ok immerhin ein Lebenszeichen. Nur scheint es so als gäbe es CrossVCL nur noch für Bestandskunden?

[Rollo62]

Zitat:

Zitat von Codehunter (Beitrag 1457897)

Nur scheint es so als gäbe es CrossVCL nur noch für Bestandskunden?

War man da nicht Kunde auf "Lebenszeit" ?

Welche war das wohl genau:
- Kundenlebenszeit
- Entwicklerlebenszeit
- Firmenlebenszeit
- Produktlebenszeit
- Produktversions-Lebenszeit

:gruebel:

[mkinzler]

Zitat:

War man da nicht Kunde auf "Lebenszeit" ?

Nur ganz am Anfang, dann wurde der Preis gesenkt und auf Subscription umgestellt.

Zitat:

Nur scheint es so als gäbe es CrossVCL nur noch für Bestandskunden?

Commercial suicide ...

[Bernhard Geyer]

Zitat:

Zitat von Codehunter (Beitrag 1457884)

Letztendlich wenn man sich die aktuellen VCL-Quellen so anschaut, wird da schon viel abstrahiert. Der Grundstein wurde wohl schon zu Kylix-Zeiten gelegt. So gesehen wäre CrossVCL "nur" die logische Fortsetzung von Kylix. Also ich denke schon dass es möglich wäre, die VCL portabel zu machen.

Du meinst nach zweimal Schiffbruch (1. Schiffbruch Kylix, 2. Schiffbruch VCL.NET) könnte es beim dritten mal klappen?
Und dann kann man FMX wieder in die Tonne schmeißen?

[Uwe Raabe]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1457919)

Du meinst nach zweimal Schiffbruch (1. Schiffbruch Kylix, 2. Schiffbruch VCL.NET) könnte es beim dritten mal klappen?
Und dann kann man FMX wieder in die Tonne schmeißen?

Die Tatsache, daß sowohl FMX als auch CrossVCL (und übrigens auch FMXLinux) aus derselben Feder kommen, lässt zumindest Hoffnung aufkeimen.

[mkinzler]

Und auch Turbo Cocoa

[Codehunter]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1457919)

Du meinst nach zweimal Schiffbruch (1. Schiffbruch Kylix, 2. Schiffbruch VCL.NET) könnte es beim dritten mal klappen?

Wenn ich es mal anders ausdrücken soll: FMX hat für mich zwei große Nachteile. Das eine ist die arg begrenzte Kompatibilität zu VCL-Komponenten. Man kann bestehende Projekte nur mit großen Mühen portieren. Das zweite ist die geringe Verfügbarkeit komplexer Komponenten wie z.B. Virtual Treeview. Für neue kleine Mobil-Projekte ist FMX nicht verkehrt. Jedoch damit eine große Desktop-Anwendung bauen zu wollen erinnert mich irgendwie an den microsoftschen Versuch, Windows 8 ein gekacheltes Touch-UI zu verpassen. In der Theorie klingts gut, in der Praxis scheiterts jedoch an den Anwendern.

Die CLX an sich war besser als ihr Ruf. Ich hätte sie zwar nicht auf Qt sondern auf GTK aufgebaut, aber sie werden schon ihre Gründe gehabt haben. Die Kylix-IDE dagegen wurde IMHO zu recht verrissen. Wenn ich Wine wollte, hätte ich auch D5 direkt laufen lassen können (das ging tatsächlich!), ebenso die Kompilate.

VCL.NET habe ich nicht genutzt. Ich bin mit .Net allgemein nie warm geworden. Schon zu Spotlight-Zeiten nicht. Zumindest was Delphi betrifft, hatte ich damit recht.

[DieDolly]

Vielleicht war der Kaufpreis auch einfach zu teuer und es gab nicht genug Kunden, um das alles am Laufen zu halten.
Ich finde die Preise waren oder sind jedenfalls übertrieben.

[Codehunter]

Zitat:

Zitat von DieDolly (Beitrag 1457933)

Vielleicht war der Kaufpreis auch einfach zu teuer und es gab nicht genug Kunden, um das alles am Laufen zu halten.
Ich finde die Preise waren oder sind jedenfalls übertrieben.

Das ist sicherlich Ansichtssache. Wenn man mit CrossVCL eine bestehende Anwendung mit überschaubarem Aufwand von Win auf Mac bekommt (und die dann auch für den Store zugelassen wird) dann kann sich das schnell rentieren. Für Hobbyprojekte wie in meinem Fall hätte ich vllt. mit Murren noch CrossVCL kaufen wollen, aber ein Enterprise-Delphi mit Sicherheit nicht um für Linux kompilieren zu können. Da nehm ich dann notgedrungen lieber erstmal Lazarus.

[himitsu]

Ich hoffe er baut bei CrossVCL nicht sowas ein, wie im FMX, da ist so einiges sehr besch.. eigenartig.

z.B. bei den buttons kann man einen Style angeben, aber da ist alles doppelt und dreifach drin und extrem unübersichtlich.
Warum nicht zwei eigenschaften für Style-Icon und Button-Style ... ne, da gibt es 80 Mal Pfeil nach links mit dutzenden Varianten wie die Farbe und Ecken aussehn.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1457939)

Ich hoffe er baut bei CrossVCL nicht sowas ein, wie im FMX, da ist so einiges sehr besch.. eigenartig.

Was sollte denn in CrossVCL eingebaut werden, was in VCL nicht schon drin ist? Das wäre dann ja nur in CrossVCL nutzbar und konterkariert den gesamten Ansatz einer VCL für andere Plattformen als Windows.

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1457920)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1457919)

Du meinst nach zweimal Schiffbruch (1. Schiffbruch Kylix, 2. Schiffbruch VCL.NET) könnte es beim dritten mal klappen?
Und dann kann man FMX wieder in die Tonne schmeißen?

Die Tatsache, daß sowohl FMX als auch CrossVCL (und übrigens auch FMXLinux) aus derselben Feder kommen, lässt zumindest Hoffnung aufkeimen.

Erinnern wir uns kurz: FMX ist das, was ursprünglich VGScene hieß, irgendwie schon länger ein kommerzielles Produkt von KSDev war, aber nach dem Kauf von Embarcadero über Jahre mit keine Ahnung wie vielen Entwicklern refactored wurd, bis es endlich einigermaßen tauglich war, oder?

[Codehunter]

Zitat:

Zitat von himitsu (Beitrag 1457939)

z.B. bei den buttons kann man einen Style angeben, aber da ist alles doppelt und dreifach drin und extrem unübersichtlich.

Das ist einer der Punkte, die auch mir an FMX nicht so gut gefallen. Neben der Tatsache, dass die Namen der Properties und Events mit allen Delphi-Konventionen brechen. Button-Beschriftung heißt "Text" und nicht "Caption", Events beginnen nicht mit "On..." und so weiter.

Zitat:

Zitat von Uwe Raabe (Beitrag 1457942)

Was sollte denn in CrossVCL eingebaut werden, was in VCL nicht schon drin ist? Das wäre dann ja nur in CrossVCL nutzbar und konterkariert den gesamten Ansatz einer VCL für andere Plattformen als Windows.

Ganz genau! CrossVCL war/ist ja eigentlich als Backend konstruiert, das regulär erstellte Win32/64-VCL-Anwendungen durch zusätzliche Plattform-Targets für Linux und MacOS verfügbar zu machen.

Zitat:

Zitat von Stevie (Beitrag 1457955)

Erinnern wir uns kurz: FMX ist das, was ursprünglich VGScene hieß, irgendwie schon länger ein kommerzielles Produkt von KSDev war, aber nach dem Kauf von Embarcadero über Jahre mit keine Ahnung wie vielen Entwicklern refactored wurd, bis es endlich einigermaßen tauglich war, oder?

Nur vom Refaktorieren wird aber kaum etwas besser. Ich kenne VGScene nicht, daher kann ich mir dazu kein Urteil erlauben. Prinzipiell ist es ja nicht verkehrt, eingetrampelte Pfade auch mal zu verlassen und bestimmte Dinge zu hinterfragen. Die vielen Delphi-(Vor-)Besitzerfirmen brachten jedenfalls kein funktionables Cross-Plattform-UI-Framework zustande, ein Einzelkämpfer dagegen schon. Dass am Ende Feinschliff nötig ist um es praxistauglich zu machen, ist ja nichts ungewöhnliches.

[Rollo62]

Zitat:

dass die Namen der Properties und Events mit allen Delphi-Konventionen brechen

Die paar Unterschiede ...
FMX gibt sich schon sehr viek Mühe VCL kompatibel zu sein, zumindest von dem Framework her.

Man könnte auch sagen das FMX endlich ein bischen konsistentere Bezeichner gewählt hat als VCL.
Das ist nun wirklich das kleinste Problem, und ein Scheinargument.

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1457929)

Das zweite ist die geringe Verfügbarkeit komplexer Komponenten wie z.B. Virtual Treeview.

Sagen wir mal lieber "kostenlos" dazu. Kommerziell gibt es ziemlich viele echt tolle FMX Komponenten, z.B. von TMS.

[mkinzler]

Zitat:

Kommerziell gibt es ziemlich viele ... FMX Komponenten

Leider viel zu wenig im Vergleich zu VCL. Jenseits von TMS gibt es leider recht wenig.

[sh17]

Das in FMX Caption z.B. Text heißt, ist schon ganz in Ordnung. FMX orientiert sich damit nur am "Standard" aller anderen Frameworks/Plattformen.

[Stevie]

Zitat:

Zitat von Codehunter (Beitrag 1457956)

Nur vom Refaktorieren wird aber kaum etwas besser.

Doch, genau das ist der Sinn und Zweck davon.

Zitat:

Zitat von Codehunter (Beitrag 1457956)

Ich kenne VGScene nicht, daher kann ich mir dazu kein Urteil erlauben. Prinzipiell ist es ja nicht verkehrt, eingetrampelte Pfade auch mal zu verlassen und bestimmte Dinge zu hinterfragen. Die vielen Delphi-(Vor-)Besitzerfirmen brachten jedenfalls kein funktionables Cross-Plattform-UI-Framework zustande, ein Einzelkämpfer dagegen schon. Dass am Ende Feinschliff nötig ist um es praxistauglich zu machen, ist ja nichts ungewöhnliches.

Genau das stelle ich in Frage, mMn war es ebend nicht funktionabel und hat erst Jahre des dran Rumschraubens gebraucht.

[Rollo62]

Zitat:

Zitat von mkinzler (Beitrag 1457968)

Zitat:

Kommerziell gibt es ziemlich viele ... FMX Komponenten

Leider viel zu wenig im Vergleich zu VCL. Jenseits von TMS gibt es leider recht wenig.

Welche nennenswerten visuellen Libraries gibt es denn für VCL (Tms, DevExpress).
Der Rest ist doch schon stark Geschmachssache, und ich denke da sind die meisten bei 1999 stehen geblieben.

FMX sollte ja auch diese oft unsäglichen "optischen Verbesserungen" ersetzen.
Deshalb versuch ich möglichts viel FMX-mäßig zu lösen.

Funktionale libraries sind was anderes, aber die lassen sich meist auch gut Portieren wenn
eben wenig visuelles benutzt wird.
FMX hat für visuelle Designs klar den Vorteil, noch besser wäre HTML5,
oder noch noch besser HTML5 + FMX :stupid:

[himitsu]

Hatte noch keine Gelegenheit mir CrossVCL anzusehn und weiß nicht welche Verbesserung im FMX von ihm stammen oder von Anderen.
Klar, einiges an den Property der VCL ist auch nicht optimal, aber beim FMX ... neee (Left/Top ist Position.X und .Y, Size.Hight und .Width gibt es wo anders, aber auch nochmal Widht und Hight direkt)

Die neue QuickBearbeitung ist nicht quick aufrufbar/benutzbar. :?

Das es für die selben Komponenten im FMX mehrere getrennte Versionen gibt, ist auch nicht sooooo ideal.
Willst den Rahmen des Panels ausblenden, muß die ganze Komponente getauscht werden und dass die "selben" Komponenten/Property in FMX und VCL komplett unterschiedlich heißen, macht die Suche nicht einfacher.

Zitat:

Zitat von Codehunter (Beitrag 1457956)

Button-Beschriftung heißt "Text" und nicht "Caption", Events beginnen nicht mit "On..." und so weiter.

Na gut, intern in der VCL ist Caption und Text das Selbe (TEXT von Windows) und gibt es in allen WinControls als Protected ... di kannst TLabel und TEdit gegeneinander casten (hart) und beim Anderen den Text/Caption setzen.

Aber im Color-Property ist hier vieles Doppelt (welches der 3 DarkGray soll sich da nehmen), diesen StyleLookup umstellen, da geht der Fokus des Conrols verloren und der IO ist leer ... Doppelklicks auf dieses Property und die Styles durchsapen geht nicht und in dem Popup ist kaum was erkennbar. (die Benamung/Sortierung ist so doof, dass Zusammengehöriges nicht zusammen steht)
Diese Ausrichtungshilfslinien und Hints (was für eine Komponente ist unter meiner Maus) im FormDesigner ... wo sind die?

Ich war grade erst dabei mir selbst aus einzelnen Layouts/Labels/Images/Animatoren ein Hauptmenü/PopupMenu zu bauen, weil dies Komponenten nicht platformübergreiend verwendbar sind und sie nicht auf meine Form drauf wollen.

Gut, das Nächste liegt nicht direkt am FMX, aber macht es ungemein schwerer das zu nutzen:
Die erwähnren fehlenden GridLines und Hints.
Im FormDesigner ist vieles nicht möglich, aber die Strukturansicht ist nach 20 Jahren immernoch nicht richtig nutzbar ... das was im Designer markiert ist, ist rechts nicht sichbar (außerhalb des Sichtbereichs und wenn nicht, dann mit fast garnicht erkennbarem Grau hinterlegt), klickt man der Strukturansicht oder die Propertyliste auf etwas, dann ist der Fokus plötzlich wo ganz anders.
Manchmal/Öfters ist dort was falsches angezeigt und erst beim nochmal kurz raus und wieder rein wird das richtige Property angezeigt.
Im FMX Property ändern (vorallem StyleZeugs) scheint recht den Designer komplett umzukrempel/refresch/reloaden/ooderso.
Komponentenselektierung ändern und schon ist das property nicht mehr sichbar ... Text und Style sind so weit unten, dass man jedes Mal neu runterscrollen muß, selbst wenn die Strukturansicht ausgeblendet ist.

[jziersch]

Zitat:

Zitat von Rollo62 (Beitrag 1457982)

Welche nennenswerten visuellen Libraries gibt es denn für VCL (Tms, DevExpress).
Der Rest ist doch schon stark Geschmackssache, und ich denke da sind die meisten bei 1999 stehen geblieben.

Das ist jetzt schon ein wenig pauschal, oder?

Äusserungen wie diese werden nicht gerade dazu führen, dass es neue Komponenten, insbesondere für FMX geben wird.

Ich beschäfte mich derzeit intensiv mit FMX und find es toll. Was CrossVCL anbelangt, gelang mir zwar die Compilierung eines grösseren Projektes, allerdings war ich mit der Bildschirmausgabe performance nicht zufrieden. Ganz anders FMX - das flutscht regelrecht.

[Rollo62]

Zitat:

Zitat von jziersch (Beitrag 1457985)

Zitat:

Zitat von Rollo62 (Beitrag 1457982)

Welche nennenswerten visuellen Libraries gibt es denn für VCL (Tms, DevExpress).
Der Rest ist doch schon stark Geschmackssache, und ich denke da sind die meisten bei 1999 stehen geblieben.

Das ist jetzt schon ein wenig pauschal, oder?

Das ist eins der schöneren Beispiele.
Aber wozu braucht man das ?

Kann man Alles mit Hausmitteln machen, und das worum es mit geht.
Gute Komponenten sind OK, aber der 1001te EditButton ist IMHO überflüssig.

[jziersch]

Verstehe schon, dass man durch den Einsatz von 3rdparty GUI Komponenten die Wartbarkeit von Projekten verschlechtert. Meine Komponenten wird man aber nicht so leicht mit Hausmitteln nachbauen können und sind up-to-date, auch wenn immer noch (in Grenzen) Delphi 5 unterstützt wird. Ohne die Verfügbarkeit dieser Komponenten wären viele Firmen nicht am Markt erfolgreich.

Andere Beispiele wären RichView, ImageEn, diverse Grids

[Stevie]

Zitat:

Zitat von Rollo62 (Beitrag 1457998)

Kann man Alles mit Hausmitteln machen, und das worum es mit geht.
Gute Komponenten sind OK, aber der 1001te EditButton ist IMHO überflüssig.

Konnte man aber nicht immer - was soll man dann als Drittanbieter machen, seine Komponenten einstampfen und den Kunden sagen "sorry, könnt ihr jetzt mit Hausmitteln machen"?

[Rollo62]

@jziersch:

Zitat:

Zitat von Rollo62 (Beitrag 1457982)

Funktionale Libraries sind was anderes, aber die lassen sich meist auch gut Portieren wenn
eben wenig visuelles benutzt wird ....

[Rollo62]

Zitat:

Zitat von Stevie (Beitrag 1458005)

Zitat:

Zitat von Rollo62 (Beitrag 1457998)

Kann man Alles mit Hausmitteln machen, und das worum es mit geht.
Gute Komponenten sind OK, aber der 1001te EditButton ist IMHO überflüssig.

Konnte man aber nicht immer - was soll man dann als Drittanbieter machen, seine Komponenten einstampfen und den Kunden sagen "sorry, könnt ihr jetzt mit Hausmitteln machen"?

Früher waren "Hausmittel" Win95-Stil, und leider auch die Funktionalität.
Ich meine heute können die IDE-Hausmittel (insbesondere unter FMX) wesentlich mehr bieten.
Also warum nicht nutzen ?

Ich habe nichts gegen gute 3rd Party Komponenten die etwas Spezielles machen, wie Zeitleiste/Planner/Visio/..., aber die unzählichen 3rd Party Libraries die versuchen noch ein Button und noch ein Edit besser zu bauen.
Erinnert mich an Linux, da muss wohl auch jeder seine eigene Distro haben, statt 1-3 Versionen voll zu unterstützen und an Windows/Macos vorbeizurasen.

[Stevie]

Zitat:

Zitat von Rollo62 (Beitrag 1458007)

Zitat:

Zitat von Stevie (Beitrag 1458005)

Zitat:

Zitat von Rollo62 (Beitrag 1457998)

Kann man Alles mit Hausmitteln machen, und das worum es mit geht.
Gute Komponenten sind OK, aber der 1001te EditButton ist IMHO überflüssig.

Konnte man aber nicht immer - was soll man dann als Drittanbieter machen, seine Komponenten einstampfen und den Kunden sagen "sorry, könnt ihr jetzt mit Hausmitteln machen"?

Früher waren "Hausmittel" Win95-Stil, und leider auch die Funktionalität.
Ich meine heute können die IDE-Hausmittel (insbesondere unter FMX) wesentlich mehr bieten.
Also warum nicht nutzen ?

Ich habe nichts gegen gute 3rd Party Komponenten die etwas Spezielles machen, wie Zeitleiste/Planner/Visio/..., aber die unzählichen 3rd Party Libraries die versuchen noch ein Button und noch ein Edit besser zu bauen.
Erinnert mich an Linux, da muss wohl auch jeder seine eigene Distro haben, statt 1-3 Versionen voll zu unterstützen und an Windows/Macos vorbeizurasen.

Ich finde auch, jeder sollte nur eine Programmiersprache, einen Texteditor, dasselbe OS, dieselbe Hardware, dieselbe Frisur, dieselbe Mode, dasgleiche Mobiltelefon und dieselbe Religion haben /sarcasm off :roll:

[Codehunter]

Zitat:

Zitat von Stevie (Beitrag 1458009)

Ich finde auch, jeder sollte nur eine Programmiersprache, einen Texteditor, dasselbe OS, dieselbe Hardware, dieselbe Frisur, dieselbe Mode, dasgleiche Mobiltelefon und dieselbe Religion haben /sarcasm off :roll:

Hatten wir schon mal. Gab reichlich Kraut und Kartoffeln. Nur bei den Südfrüchten musste man Vitamin B zusetzen. Zufriedenheit und Glückseligkeit aller Orten. Nur 89 am Schlagbaum nicht ^^

[Uwe Raabe]

Zitat:

Zitat von Uwe Raabe (Beitrag 1457895)

Die letzte Version von CrossVCL habe ich am 2.11.2019 bekommen. Extrapoliert man das bisherige Release-Verhalten sollte es bald wieder eine Version geben.

Na wer sagt's denn: CrossVcl 1.18 just released

[DualCoreCpu]

Zitat:

Zitat von Rollo62 (Beitrag 1458006)

@jziersch:

Zitat:

Zitat von Rollo62 (Beitrag 1457982)

Funktionale Libraries sind was anderes, aber die lassen sich meist auch gut Portieren wenn
eben wenig visuelles benutzt wird ....

Ein wesentlich besserer Weg wäre, einfach möglichst wenig Systemabhängige Bibliotheken zu verwenden. Negativbeispiel MSEGUI von Martin Schreiber! Wozu dort GDIPlus. Reicht nicht das Windows API?

Dank GDIPlus gestaltet sich die Portierung auf eine neue Plattform unnötig aufwendig. Windows API bietet doch alles was das Grefikerher begehrt.

[DualCoreCpu]

Zitat:

Zitat von Stevie (Beitrag 1458009)

Zitat:

Zitat von Rollo62 (Beitrag 1458007)

Zitat:

Zitat von Stevie (Beitrag 1458005)

Zitat:

Zitat von Rollo62 (Beitrag 1457998)

Kann man Alles mit Hausmitteln machen, und das worum es mit geht.
Gute Komponenten sind OK, aber der 1001te EditButton ist IMHO überflüssig.

Konnte man aber nicht immer - was soll man dann als Drittanbieter machen, seine Komponenten einstampfen und den Kunden sagen "sorry, könnt ihr jetzt mit Hausmitteln machen"?

Früher waren "Hausmittel" Win95-Stil, und leider auch die Funktionalität.
Ich meine heute können die IDE-Hausmittel (insbesondere unter FMX) wesentlich mehr bieten.
Also warum nicht nutzen ?

Ich habe nichts gegen gute 3rd Party Komponenten die etwas Spezielles machen, wie Zeitleiste/Planner/Visio/..., aber die unzählichen 3rd Party Libraries die versuchen noch ein Button und noch ein Edit besser zu bauen.
Erinnert mich an Linux, da muss wohl auch jeder seine eigene Distro haben, statt 1-3 Versionen voll zu unterstützen und an Windows/Macos vorbeizurasen.

Ich finde auch, jeder sollte nur eine Programmiersprache, einen Texteditor, dasselbe OS, dieselbe Hardware, dieselbe Frisur, dieselbe Mode, dasgleiche Mobiltelefon und dieselbe Religion haben /sarcasm off :roll:

Wie Religion kommt mir das Programmier- und Nutzerverhalten wirklich vor. Jede Seite beharrt auf ehernen unverrückbaren Grundsätzen, ungeachtet der Tatsache, dass die Computertechnik nicht stehen bleibt. Ob es da aber gut ist, wenn nun jeder "sein eigenes Süppchen kocht"?

[himitsu]

Nja, Grunssätzlich wäre es doch eigentlich am Besten für die einzelnen Plattformen, wenn jeweils ihre nativen Komponenten verwendet werden,
also so wie es die VCL, CLX, LCL und CrossVCL machen.
Und dafür dann im Delphi eine Schnittstelle bauen, welche die "Gemeinsamkeiten" aller/der meisten Komponenten aller Plattformen auf eine einheitliche Delphi-API (ala VCL) abbilden.



Und dann gibt es eben auch noch den Weg, wo man sich auf den Plattformen eine grundlegende Zeichengrundfunktion sucht (können auch auf den Plattformen unterschiedliche sein),
dann alles selbst malt und alle Komponenten der Systeme nachbaut, bzw. das System komplett ignoriert und einfach selbst irgendwas baut, was dann optisch garnicht in die Systeme rein passt. siehe FMX, Java usw.

Stellt dann das OS sein Erscheinungsbild in der nächsten Version um, dann muß der Style erstmal wieder neu nachgebaut/angepasst werden (die VCL sieht sofort "richtig" aus).
Darum kann man im FMX auch inzwischen mehr oder weniger gut einige Komponenten auch auf Plattform umstellen, um die Funktionen des Systems zu bekommen, die nicht nachgebaut wurden.

Auch ScreenReader und andere Techniken für z.B. blinde und sehbehinderte Menschen, funktionieren erstmal nur bei den nativen Controls, falls es nicht zusätzliche Schnittstellen gibt, wo die selbstgemalte Komponente/Form dann dem OS/System seinen Inhalt sagen kann.

Und auch eine GUI Test Automation ist mit den nativen Controls einfacher, da alles Andere erstmal eine Schnittstelle zum Inhalt benötigt, denn die Pixel der Ausgabe zu analysieren ist eine saublöde unzuverlässige Idee.

[jobo]

Zitat:

Zitat von himitsu (Beitrag 1458682)

..
dann alles selbst malt und alle Komponenten der Systeme nachbaut, bzw. das System komplett ignoriert und einfach selbst irgendwas baut, was dann optisch garnicht in die Systeme rein passt. siehe FMX, Java usw.

Stellt dann das OS sein Erscheinungsbild in der nächsten Version um, dann muß der Style erstmal wieder neu nachgebaut/angepasst werden ...

Interessiert es JAVA, ob sich am OS etwas in der Erscheinung geändert hat?

[dummzeuch]

Zitat:

Zitat von jobo (Beitrag 1458687)

Interessiert es JAVA, ob sich am OS etwas in der Erscheinung geändert hat?

Nö, JAVA Programme sehen auf allen Platformen immer gleich Sche**e aus. ;-)