Aufruf: Was braucht Firemonkey

[Mavarik]

Hallo Zusammen.

Gemäß meinem Vorschlag an Embarcadero greife ich hiermit den "Return" von Matthias Eissing auf und gebe es ins Forum weiter.

Frage war: "Wann werden die fehlenden Abstraktionen in Firemonkey eingebaut, damit der gleiche Code auf IOS & Android läuft"

(Mit einer Zeile. Nein Null-Zeilen... Running Gag der Delphitage)

Angeblich würde man hier auf die Community hören...:roll: Lassen wir mal so stehen...

Es war auch so eine kleine Andeutung da, dass ggf. Code "von uns" hier in Firemonkey einfließen "könnte"... :roll: Wer's glaubt...

Trotzdem möchte ich nix unversucht lassen und daher dieser Post...

Bin gespannt auf Eure Kommentare...

Mavarik

[Darlo]

Für mich wirklich wichtig:
- FireDac sollte auch auf mobilen Geräten Verschlüsselung unterstützen
- iCL, mCL und "aCL"-System benutzen

[greenmile]

Ich will doch nur einen WebBrowser für Mac; das aber schon seit XE2. Und eine vernünftige Listview.
@Embarcadero: Schaut Euch mal die mCL von TMS an. Die sind zwar Buggy, in einigen Punkten aber sowas von vorne auf dem Mac ...

[Mavarik]

Zitat:

Zitat von Darlo (Beitrag 1229573)

Für mich wirklich wichtig:
- iCL, mCL und "aCL"-System benutzen

OK Aber das macht keinen Sinn...
Klar könnte man auf jeweils der Plattform die Nativen-Controls nutzen, aber ich denke - egal wie gut die sind - das ist nicht das Konzept was hinter Firemonkey steht...

Mavarik

[Darlo]

Zitat:

Zitat von Mavarik (Beitrag 1229577)

Zitat:

Zitat von Darlo (Beitrag 1229573)

Für mich wirklich wichtig:
- iCL, mCL und "aCL"-System benutzen

OK Aber das macht keinen Sinn...
Klar könnte man auf jeweils der Plattform die Nativen-Controls nutzen, aber ich denke - egal wie gut die sind - das ist nicht das Konzept was hinter Firemonkey steht...

Mavarik

Ja, ich weiß, trotzdem wäre eine Kind-Eigenschaft wie "really true native" und "true native" wirklich schön ;-)

[Mavarik]

Zitat:

Zitat von Darlo (Beitrag 1229578)

Ja, ich weiß, trotzdem wäre eine Kind-Eigenschaft wie "really true native" und "true native" wirklich schön ;-)

So als Boolean bei einem Button oder so?

Delphi-Quellcode:

  Button1.Usenative := true;

Mavarik

[greenmile]

Für mich macht es aber Sinn. Die Firemonkey Komponenten hatten jetzt 3 Versionen lang Zeit zu reifen, seit 3 Versionen (XE2 - XE5) sind sie aber Müll, seit 3 Versionen warte ich auf elementare Komponenten, die es sehr wohl auf der jeweiligen Plattform gibt. Gut, der Müll ist weniger geworden mit jeder Version, aber es ist und bleibt Müll. Punkt. Die mCL laufen bei mir in der ersten Version bedeutend sauberer (und rund laufen sie trotzdem nicht), da wird FMX locker bis XE8 brauchen. Das ist wirklich traurig. Oder die Chance für TMS. Deshalb die Idee: Für alle Plattformen FMX. Und für Details halt native, sowas wie mCL. Dann habe ich beides.

Auf MacOS gibt es native eine coole Listview. Einen Browser. Wieso zum Henker sind die nicht in Firemonkey drin??? Und es liegt sicherlich nicht daran, dass Embarcadero davon nichts wusste, das sind häufig gewünschte Punkte. Einfach mal als Komponente kapseln, das kann doch nicht so schwer sein.

[Mavarik]

@greenmile

Müll finde ich zu hart...

Ich nenne es verbesserungsbedürftig.

Für IOS geht es ja noch aber für Android ist es echter Müll. Absolut nicht zu gebrauchen zur Zeit...(Aussage von ME: "Wir arbeiten daran. Warte auf Update 1")
Mal abgesehen davon, dass ein für IOS designtes Formular ÜBERHAUPT nicht auf Android passt...

Gleiche Codebase mag ja noch stimmen, aber auf keinen Fall gleiches Design...

Mavarik

[greenmile]

Eine Frage, die Stahli mal gestellt hat und die alles beantwortet: Wie viele wirklich professionelle Anwendungen, die mit Firemonkey erstellt wurden und die FMX Controls verwenden, gibt es? Und ich meine nicht kleine Tools sondern etwas, mit dem man Geld verdienen kann.

Ich habe es aufgegeben. Ich froh und glücklich über den Compiler und dass ich eine Form habe. Und ich bin glücklich, dass endlich Drittanbieter wie TMS was anbieten. Die Kombi ist für mich ok und die einzig sinnvolle. Denn ich will und muss Geld damit verdienen. Ich kann dem Kunden nicht sagen "Hey, wir warten auf SP1. Oder XE6. Oder XE7. Oder geht halt nicht.". Das habe ich bei XE2 getan und mir böse die Finger verbrannt.

Wieso ich überhaupt noch mitschreibe? Weil ich echt sauer bin, dass ich einen Wartungsvertrag für Delphi UND einen für Mobile Studio brauche. Obwohl sich in Delphi selbst kaum was ändert und ich es nur brauche, weil ich sonst mit dem Mobile Studio nirgendwo aufsetzen kann. Und weil ich noch zusätzlich extern Geld ausgeben muss für etwas, was ich eigentlich vom Hersteller erwarte.

===

Also mein Wunsch an Emba:

1. Ein Wartungsvertrag für Delphi UND Mobile Studio, nicht diese Abzocke
2. Die viel versprochenen Bugfixes. Sobald eine neue Version kommt, werden alte Versionen vergessen
3. Essentielle Komponenten wie nativ Listview, Webbrowser usw.

[Union]

FireMonkey ist genau wie QC: Für die Tonne. Das muss neu aufgesetzt werden. Ich wollte heute was ganz einfaches machen. Habe es nicht hingekriegt, aber 3 QC zu einem einzigen Fall erstellt. Dabei habe ich u.a. (immer noch und schon wieder) festgestellt:

• Schlüsseleigenschaften von OS-Komponenten werden hardcodiert und nicht published
• Ganz normale Bedienung führt zu SIGxxx Problemen und Verabschiedung der gesamten App
• Die "nativen" pixel-perfect Komponenten sehen komplett anders aus als bei den im Gerät vom Hersteller mitgelieferten Apps und verhalten sich auch anders.
• Die Programmierer beherrschen keine Rechtschreibung.
• Der Source wird von Kommentaren und ToDo gestrippt damit man auch ja nichts nachvollziehen kann.
• Der Source entspricht nicht dem Auslieferungszustand des Kompilats - es stecken dort Fehler drin die zu einem Compilerabbruch führen und daher nicht der Ursprung der vorhandenen dcu und bpl sein können.

Es gibt eine Schnittmenge ca. 30 Komponenten auf den verschiedenen Plattformen. Ist das zu viel verlangt dass die auch alle funktionieren?

[Der schöne Günther]

Zitat:

Zitat von Union (Beitrag 1229596)

Der Source wird von Kommentaren und ToDo gestrippt damit man auch ja nichts nachvollziehen kann.

Oh nein, ist das immer noch so? :-(

Das verstehe ich schon bei der VCL nicht. Noch schlimmer wäre jetzt eigentlich, wenn doch nichts entfernt wurde :wink:

[jaenicke]

Zitat:

Zitat von greenmile (Beitrag 1229591)

1. Ein Wartungsvertrag für Delphi UND Mobile Studio, nicht diese Abzocke

Das gibt es ja mit der Enterprise. Wer den Preis nicht ausgeben möchte, der muss eben separat kaufen. Genau diese Modularität wurde ja mal aus der Community gefordert und rein auf die Wartung bezogen finde ich das auch nicht zu teuer (anders als den Einstiegspreis) und diese Konfiguration mit Addons usw. finde ich derzeit nicht schlecht.

ABER:
Es muss dabei auch eine Kontinuität geben. Das Hickhack mit separatem Mobile oder nicht usw. ist einfach ein No-Go, auch wenn es uns in der Firma nicht betroffen hat. Ich hoffe daher eher, dass die Produktlinie nun kontinuierlich fortgeführt wird und nicht gleich wieder etwas umgeworfen wird...

Zitat:

Zitat von greenmile (Beitrag 1229591)

2. Die viel versprochenen Bugfixes. Sobald eine neue Version kommt, werden alte Versionen vergessen

Alte Versionen nicht mehr zu pflegen wäre für mich in Ordnung, sofern es mehr Fixes zumindest in der aktuellen Version geben würde, vor und nach dem Release. Bei FireMonkey tut sich in der Hinsicht einiges und die Stabilität der IDE ist auch immer besser, aber es gibt trotzdem zu viele offene Punkte.

Deshalb verliert man leider die Lust überhaupt QC-Einträge zu schreiben, wenn man dann in vielen Fällen schon alte Einträge zu vielen Problemen findet, die schon länger offen sind. Das ist mir leider auch bei FireMonkey und XE5 allgemein schon so gegangen, auch wenn bei FireMonkey naturgemäß die Einträge jünger sind als bei diversen VCL-Problemen.

Am problematischsten finde ich dabei, dass bei FireMonkey schon wieder wie vorher bei der VCL essentielle Bestandteile der Komponenten nicht virtuell und nicht von außen beeinflussbar sind.
Was soll das? Letztlich würde ich gerne an vielen Stellen die ganze Unit kopieren und ein paar Zeilen ändern, und das nur, weil alles gekapselt ist und man es nicht einfach ändern kann. Das macht die Auswirkungen der vorhandenen Fehler umso verheerender, weil man diese außer durch dreckige Tricks immer wieder mal nicht einmal umgehen kann.

Zitat:

Zitat von greenmile (Beitrag 1229591)

3. Essentielle Komponenten wie nativ Listview, Webbrowser usw.

Ja, ein paar wichtige Komponenten fehlen mir auch.

[Mavarik]

OK Leute...

Vielleicht habe ich mich nicht korrekt ausgedrückt...
Nix gegen Eure Meinungen wie gut oder schlecht Delphi & Firemonkey sind, aber in diesem Thread geht es um eine
konstruktive Mitarbeit um das bestehende zu erweitern und zu verbessern.

Es geht darum das wir zusammen erarbeiten welche Funktionen von der RTL gekapselt werden sollten damit man unter Android und IOS den gleichen Code verwenden kann..

Thema : MapKit, Batteriestatus, Events usw.

Macht Euch doch bitte in einem anderen Thread Luft...

Mavarik

[Lemmy]

Zitat:

Zitat von jaenicke (Beitrag 1229599)

Zitat:

Zitat von greenmile (Beitrag 1229591)

1. Ein Wartungsvertrag für Delphi UND Mobile Studio, nicht diese Abzocke

Das gibt es ja mit der Enterprise.

das gibts auch bei Professional. Nennt sich dann halt RadStudio.

[Union]

Zitat:

Zitat von Mavarik (Beitrag 1229601)

OK Leute...
Nix gegen Eure Meinungen wie gut oder schlecht Delphi & Firemonkey sind, aber in diesem Thread geht es um eine
konstruktive Mitarbeit um das bestehende zu erweitern und zu verbessern.

Dann hast Du Dich unklar ausgedrückt. Oder fast alle haben es nicht richtig verstanden.

Zitat:

Frage war: "Wann werden die fehlenden Abstraktionen in Firemonkey eingebaut, damit der gleiche Code auf IOS & Android läuft"

Wenn das die Frage ist - was sollen wir dann dazu sagen? Heute? Morgen? Möglichst in 3 Monaten?

[Mavarik]

Zitat:

Zitat von Union (Beitrag 1229604)

Zitat:

Zitat von Mavarik (Beitrag 1229601)

OK Leute...
Nix gegen Eure Meinungen wie gut oder schlecht Delphi & Firemonkey sind, aber in diesem Thread geht es um eine
konstruktive Mitarbeit um das bestehende zu erweitern und zu verbessern.

Dann hast Du Dich unklar ausgedrückt. Oder fast alle haben es nicht richtig verstanden.

Zitat:

Frage war: "Wann werden die fehlenden Abstraktionen in Firemonkey eingebaut, damit der gleiche Code auf IOS & Android läuft"

Wenn das die Frage ist - was sollen wir dann dazu sagen? Heute? Morgen? Möglichst in 3 Monaten?

Das war die Frage bei den Delphi Tage an ME...

Drücke ich mich heute so blöde aus?

Mavarik

[greenmile]

Naja, ich denke es wurde hier im Forum schon genügend geschrieben über das was fehlt, was fehlerhaft ist, was man besser machen könnte. Wenn irgendjemand wirklich Interesse daran hat, Delphi / FMX zu verbessern, dann bräuchten wir diesen Thread nicht. Es steht alles an jeder Ecke hier im Forum. Darf ich auch einfach verlinken? Dann erspare ich mir das getippe. Alternativ können "diejenigen" einfach mal "Firemonkey Probleme" bei Google eintippen ...

Wobei, wenn ich ehrlich bin würde es schon einiges an Arbeit brauchen, um mich wieder von Firemonkey zu überzeugen. Soviel können die Jungs tatsächlich in einem Jahr nicht schaffen. Die Enttäuschung ist ohne Frage große.

[Union]

Ich sehe da auch keine große Chance, denn um es benutzbar zu machen wäre ein komplettes Relaunch / Redesign notwendig. Jedes Mal, wenn ich eine beliebige FMX Komponente benutze, entdecke ich schwerwiegende Fehler. Da geht es nicht darum, was da noch fehlt dass es überall gleich läuft.

[Mavarik]

Zitat:

Zitat von Union (Beitrag 1229613)

Ich sehe da auch keine große Chance, denn um es benutzbar zu machen wäre ein komplettes Relaunch / Redesign notwendig. Jedes Mal, wenn ich eine beliebige FMX Komponente benutze, entdecke ich schwerwiegende Fehler. Da geht es nicht darum, was da noch fehlt dass es überall gleich läuft.

OK! Einmal versuche ich es noch... Ansonsten @Daniel schließe diese thread bitte..

NUR wer etwas positives in Form von Source-Code oder Patchvorschläge für Firemonkey hat, möge dies hier posten...

Mavarik

[Daniel]

Leute - es ist so unglaublich simpel, sich pauschal über ein Thema auszukotzen, ohne dabei konkret zu werden. Etwas schwieriger scheint es zu mit dem Lesen zu sein.

Frank wollte ein Gefühl dafür bekommen, welche Bereiche nach den Sensoren, Telefonie-Diensten etc. im FMX-Framework als nächstes angepackt werden sollten. Potentielle Kandidaten wären der Zugriff auf das Adress-Buch, den Kalender oder die Karten-Dienste.

[greenmile]

Ok, also ich denke die Message lautet: Kaum jemand braucht neue Funktionen wie Telefonbuch usw., das ist für viele Zweitrangig. Wir brauchen zunächst eine saubere Basis. Es ist sonst wie eine supermoderne Etagenwohnung mit 60" Zoll TV, Solar und co. Nur blöderweise in Nordkorea. Bringt also nix, die Basis passt nicht.

Als nächstes anpacken: Endlich mal die Basis stabilisieren. Und sich dann Gedanken machen. Mir bringen die besten Funktionen nichts, wenn ich es nicht verwenden kann. Ich kaufe die Sachen nicht aus Hobby.

[stahli]

Schließe mich greenmile an: Kein Bedarf an mobilen Erweiterungen meinerseits aber sehr an einem vernünftigen FMX für Win + Mac.

[RWarnecke]

Mich würde im Moment hauptsächlich die Events, Bluetooth, WLAN und der Mobilteil interessieren. Wann kommen diese Dinge in Form von Komponenten oder was mir auch schon erstmal auseichen würde, wie kann ich die ganzen Sachen aus dem Objectiv-C ins Delphi übersetzen. Konkret brauche ich hier die Events von UIDevice, wie in diesem Thread angesprochen.

[Union]

Ok, jetzt habe ich das verstanden:

• Man sollte mit der Maus Text in Edits selektieren können
• Memory leaks sollten besitigt werden, damit die Anwendungen nicht ständig abschmieren bei längerer Benutzung
• Drag / Drop sollte funktionieren
• Taborder sollte nicht nach dem Zufallsprinzip funktionieren
• Copy/Paste sollte funktionieren mit allen üblichen Datentypen (Text, Image ...)
• Schreibrichtung sollte funktionieren (z.b. bei Arabisch)
• Zeichendarstellung sollte korrekt und einheitlich sein
• Events sollten richtig feuern (z.b. durch Rundungsfehler ausgelöste events wegen der Float-Werte in den FMX-Koordinaten)
• Imagepicker sollte funktionieren ohne Darstellungsfehler und DTD
• Unterstützung für Bedienung durch Sehbehinderte ("Vorlesen" klappt nicht weil die FMX-Texte alles gerenderte Grafiken sind). In einigen Ländern darf Software gar nicht so verkauft werden, auch Embarcadero musste die Bedienbarkeit der IDE dementsprechend bestätigen.
• Komponenten sollten richtig gezeichnet werden (z.b. Focusdarstellung)
• Gestensteuerung sollte funktionieren

Ich hätte da noch ein paar dreckige Dutzend in der Art. Es wäre toll wenn die meisten mit dem nächsten Patch behoben würden. Dokumentation und Beispiele dazu liegen umfangreich vor.

[Mavarik]

Zitat:

Zitat von Union (Beitrag 1229621)

Ok, jetzt habe ich das verstanden:

• Man sollte mit der Maus Text in Edits selektieren können

Maus?

Es geht um IOS & Android...

[Mavarik]

Zitat:

Zitat von stahli (Beitrag 1229619)

Schließe mich greenmile an: Kein Bedarf an mobilen Erweiterungen meinerseits aber sehr an einem vernünftigen FMX für Win + Mac.

Wenn Du keinen Bedarf hast bist Du in diesem Thread falsch!

[Mavarik]

Zitat:

Zitat von RWarnecke (Beitrag 1229620)

Mich würde im Moment hauptsächlich die Events, Bluetooth, WLAN und der Mobilteil interessieren. Wann kommen diese Dinge in Form von Komponenten oder was mir auch schon erstmal auseichen würde, wie kann ich die ganzen Sachen aus dem Objectiv-C ins Delphi übersetzen. Konkret brauche ich hier die Events von UIDevice, wie in diesem Thread angesprochen.

Danke...

Genau darum geht es...

[Union]

Zitat:

Zitat von Mavarik (Beitrag 1229624)

Zitat:

Zitat von RWarnecke (Beitrag 1229620)

Mich würde im Moment hauptsächlich die Events, Bluetooth, WLAN und der Mobilteil interessieren. Wann kommen diese Dinge in Form von Komponenten oder was mir auch schon erstmal auseichen würde, wie kann ich die ganzen Sachen aus dem Objectiv-C ins Delphi übersetzen. Konkret brauche ich hier die Events von UIDevice, wie in diesem Thread angesprochen.

Danke...
Genau darum geht es...

Das ist Zusatzfunktionalität und ist genauso zu sehen wie "Warum ist keine Comport-Library in Delphi enthalten". Wenn FMX Desktop (Win/OSX) aussen vor gelassen wird, dann eben diese rausstreichen. Aber es bleiben in der Liste noch genug Dinge übrig, die nichts mit Taborder oder Drag/Drop zu tun haben.