![]() |
AW: FMX-Styles?
Sorry, aber das ist Blödsinn.
Ich kaufe doch nicht für teures Geld eine Waschmaschine, ein Auto, einen Fernseher oder was-weiß-ich-was und bin für die Fehler zuständig. Das ist nicht meine Aufgabe. Es ist schön zu sehen dass sich eine Community um Delphi drumrum bildet und wir eine Familie sind, aber wenn es bei Embarcadero mit "Wir drücken kein Auge beim SA zu" losgeht, dann geht es bei mir mit "dann findet Eure Fehler selbst" los. Geben und nehmen und nicht nur eins. Normalerweise regelt der Markt sowas selbst: Kommt Schrott auf den Markt, lebt die Firma nicht sehr lange. Delphi hat noch die alten Anhänger, deshalb lebt die Sprache noch. Unterhalte Dich mal mit einem Visual Studio'ler, die packen sich vor den Kopf mit wieviel rudimentären Bugs wir freiwillig leben. Bei Microsoft würde das niemand akzeptieren oder würdest Du auch sagen "Na dann melde die Bugs von Windows 8 doch an Microsoft, nur so wird ein Schuh draus"? |
AW: FMX-Styles?
Hi.
Delphi hat doch "RAD" eingeführt für "Schnelle Applikations Entwicklung"... ...und dieses Motto kollidiert in meinen Augen (noch) mit FMX. Der VCL-Part ist ja soweit ganz gut ausgereift, aber EMBT nimmt doch FireMonkey als Zugpferd und Technologiesprung - da müssen doch so fundementale Dinge wie Design-Guides (Hilfslinien), vollständige Tastaturunterstützung und dergleich langsam mal funktionieren. Und da hat sich seit Einführung von FM nicht viel getan, oder? Wenn man bei der Entwicklung permanent durch Unzulänglichkeiten der IDE ausgebremst wird, das hat das mit "rapider" Entwicklung nicht viel zu tun. Versteht mich nicht falsch: Ich war und bin eigentlich ein Fan von Firemonkey und hatte zuvor ja auch schon die Lifetime-Lizenz für VGScene (hihi...Lifetime...;-), nur hätten neben iOS-Support auch mal grundlegende Dinge angepackt werden können...und sooo viel Aufwand wäre das doch wohl dann auch nicht gewesen, oder? Beispiel "Anchors": Wann kamen die rein? XE3? Das hätte doch schon Standard sein müssen...oder das dutzende Parameter keinen "default"-Wert in der DFM hatten ist einfach schlampig programmiert...oder das der Stlyebook-Editor nur rudimentär bedienbar ist, der Einsatz von Resourcen (Lookup) unnötig kompliziert und fehleranfällig, usw. Und ich rede hier nur vom FM-Part. Am VCL-Part hat sich außer den Designs (Themes) auch nicht mehr viel getan...besserer Thread Support über Attribute wäre mal schön gewesen oder sowas wie LingQ, ... anderseits verstehe ich durchaus, das erstmal der Mobile-Part im Vordergrund stand...dann aber doch bitte mit ein wenig "mehr Liebe"...und hier frage ich mich auch, ob ein Entwickler dann mal ernsthaft damit gearbeitet hat. Ich als Entwickler würde - wenn auch nicht vom Kunden gefordert und bezahlt - alleine für MICH solche Dinge wie Tastaturunterstützung usw. eingebaut ;-) LG, Marc |
AW: FMX-Styles?
Das meinte ich übrigens mit "es brodelt hier".
Wer mit FMX konfrontiert ist, ist einfach mal sauer. Ich finde das wirklich traurig, weil sich so ein schlechtes Bild zu einer an sich guten Idee bildet. Die FMX iOS Geschichte läuft gut und das ist gut so, sein wir aber mal ehrlich: Wir freuen uns über etwas, was an sich schon mit XE2 verkauft wurden. Wir freuen uns also darüber, dass es endlich funktioniert. Das nenne ich mal Treue am Produkt. Wie schon an anderer Stelle gesagt wird es meiner Meinung nach Zeit, dass Embarcadero etwas für den Ruf tut. Kugelschreiber und Weingummi's für jeden! ;) |
AW: FMX-Styles?
Zitat:
Genau das können sie auch bei der seltsamen beta Politik die Emba fährt nicht. Da wird der Kreis der möglichen Tester künstlich eingeschränkt. Das ist aber Embas Problem und sollte nicht wieder zu unserem werden. Der Fokus lag auf iOS, nicht auf dem Rest? Das kannst du nicht ernst meinen. Der Fokus hat auf allem zu liegen, denn man verkauft ja auch das komplette Paket für viel Geld. Dafür, dass man den Leuten für ein umbenanntes XE3 Update nochmal €49,- aus der Tasche leiert ist das ganz schön dünn. Zum Thema QC: Hast du dort schon mal was gepostet, was schnell gefixt wurde? Ich glaube kaum. ;) Zitat:
|
AW: FMX-Styles?
Zitat:
Ich hatte mehrere QC-Einträge, die dann zum jeweils nächsten Beta-Build korrigiert wurden. Hängt natürlich auch von der Qualität des Eintrages ab. |
AW: FMX-Styles?
Zitat:
Wir sind mittlerweile bei FMX 3.0. Da sollten solche Basics funktionieren. |
AW: FMX-Styles?
In Sachen iOS muss ich ein Stück zurückrudern, die Beta kam vergleichsweise gut an und es gab einige Versionen, bis die finale da war. Soviel, dass ich am Ende nur noch jede 2te / 3te installiert habe ;)
|
AW: FMX-Styles?
Hallo zusammen,
irgendwie ist dieser Beitrag hier komplett vom Thema abgekommen. Ich muss feststellen, dass jedes Thema was mit FMX anfängt in einer Diskussion endet, was Emba wie besser machen könnte. Ich bin eher der Meinung, wir sollten hier lieber die Köpfe zusammenstecken und darüber diskutieren, wie wir eventuelle Fehler und Bugs an Emba melden und wie wir diese eventuell auch bereinigen können. Ich gebe nur als gute Beispiel voran, was Andreas Hausladen (jbg) gemacht hat mit seinem IDE Fix Pack. Einige dieser Verbesserungen wurden ja auch in neuere IDE's übernommen. Des weiteren bin ich der Meinung, dass man sich vielleicht von der Denkweise wie man eine VCL-Anwendung aufgebaut hat verabschieden sollte. Der Aufbau einer GUI im FMX ist aus meiner Sicht anders zu händeln. Ich habe zum Beispiel früher auch gerne mit den Hilfslinien in einer VCL-Form gearbeitet. Unter FMX zum Beispiel habe ich die Optionen Align und Margin, womit ich sehr gut ausgerichtet GUI's erstellen kann. Es ist klar, dass man hier etwas anders denken muss und ich habe auch noch meine Probleme damit habe. Aber wenn man sich darein kniet, sollte das etwas werden. Deshalb bitte ich darum, dass wir hier wieder zum Thema zurück kommen und stahli helfen, denn mich würde eine Lösung ebenfalls interessieren. |
AW: FMX-Styles?
Zitat:
|
AW: FMX-Styles?
Zitat:
![]() |
Alle Zeitangaben in WEZ +1. Es ist jetzt 05:58 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz