![]() |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
k.A. warum, aber ![]() Es war ein Abo-Model, wo man praktisch für ein Jahr den Teil sich kaufte, den man haben wollte, oder mehrere Teile (Delphi oder C++, nur FMX und keine VCL, Windows oder Mobil oder Mac) Dank Zwangs-Wartungsvertag, ist Delphi ja nun auch ein Abo-Model, nur dass man hier nicht mal eben ein Jahr aussetzen kann (ohne dass es teuer wird). |
AW: Find out why after 22 years more developers than ever are choosing Delphi
AppMethod war aber zu teuer und war eine reines Abomodell. Bei Delphi/C++-Builder/RadStudio bezieht sich das Abomodell ja nur auf die Wartung. Nach deren Ablauf, kann man mit dem Produkt weiterarbeiten (Stand wird eingefroren)
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
Angenommen ich möchte die Architect-Version, habe mir 7000€ vom Mund abgespart. Das Abo möchte ich aber nicht bezahlen (wer bezahlt schon gerne ABOs!). Dann habe ich im Endeffekt fast 10.000€ für ein Produkt ausgegeben und bekomme nach einem Jahr keinerlei Updates mehr. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
Die Probleme mit Generics (durch den sehr starken Einsatz) sind in den aktuellen Versionen auch behoben. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Du weißt darum. Du möchtest es kaufen. Du musst nicht.
Können wir nicht lieber wieder über putzige Comic-Äffchen oder die Roadmap sprechen? Die Diskussion um den Preis hatten wir doch schon oft genug. Denn wie sagte hier einst ein schlauer Mann: Zitat:
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
Zitat:
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
C++ ist wohl eher etwas für Profis. Delphi ist doch recht "friedlich" und "stressfrei" zu erlernen. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
Aber wir hätten auch die aktuellen Features nicht. Wir hätten also den gleichen Preis nach ein paar Jahren, aber weniger Leistung. ;-) Und für mobile Plattformen geht es ohne Subscription eh nicht sinnvoll. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
Damit meine ich: die IDE ist einfach nicht modern genug. Nicht einmal Verzeichnisse kann man in der Projektverwaltung anlegen oder Dateien verschieben. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
F2 funktioniert ja nicht einmal :P
CnPack ist installiert. Lasse ich CnPack weg, funktioniert es. Eine Art CnPack (mit weniger Müll) aber fest in Delphi integriert wäre mal was Tolles. Aber auch wenn es funktioniert mit Rechtsklick > umbenennen. Für mich sind das alles dirty workarounds, mehr nicht. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Ich habe doch nicht einmal geschrieben, dass ich Emba dafür die Schuld gebe :roll:
Die "mangelnde Funktionalität" im Allgemeinen ist aber nicht auszublenden: sie ist da (oder eben auch nicht...) und E/I ändert nichts daran. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
Zitat:
Zitat:
Wäre dieser Request nicht sinnvoller an die Macher von CnPack gerichtet? Schließlich sind die es, die eine existierende Funktionalität durch ihr Plugin außer Kraft setzen. Für den Fall, daß die nichts daran ändern, stehen auch immer noch die Sourcen zur Verfügung um den Fehler selbst zu beheben. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
Ich kenne es von Visual Studio anders und dort ist es wesentlich angenehmer zu bewerkstelligen. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
Ich würde an deiner Stelle trotzdem mal den CnPackern auf die Füße treten. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Dafür ist mir meine Zeit zu schade. Denn alles was man als Antwort bekommt ist, dass der Entwickler das Problem nicht nachvollziehen kann und somit lößt sich das Problem für ihn in Luft auf.
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
mein Input zu diesem Thema, Zusammenfassung der Diskussionen im Entwicklerteam, viele mit Background Matlab, Phyton, C++, Java
a) Wenn man die Basics in Delphi mal verstanden hat, gehen viele Sachen einfach und schnell b) Cross Plattform ist super einfach Delphi ist ein Werkzeug, nicht mehr und nicht weniger |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
Das gilt für Bugs und gewünschte Features in Delphi natürlich auch. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Warum denn Bug-Reports erstellen wenn doch eh schon mehr oder weniger festgelegt ist, dass die nächste Jahre an Firemonkey und Co gearbeitet wird? :roll:
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Können wir diesen Kindergarten nicht langsam beenden?
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Es gab sogar mal neue VCL-Komponenten (Windows 8/10), in den letzten paar Jahren, und sogar ein paar knapp 10 Jahre alte Bugs wurden vor Kurzem behoben.
Auch wenn man netterweise die meisten Layout-Controls des FMX nicht auch gleich mit für die VCL umgesetzt hat. :cry: Die TGridPanel und TFlowPanel fühlen sich so alleine. Und wer im GridPanel mal versucht hat ein paar Prozent-Werte einzugeben, der weiß was Sisyphus geleistet hat. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
Aber alternative Fakten sind ja heute modern... :roll: |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Ich brauche es zum Glück nicht, da ich wirklich nur seltenst die Namen ändere. Aber jeder hat eine andere Arbeitsweise...
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Aber ich bin natürlich auch mit einigen Dingen nicht zufrieden:
- OS X 64 bit - xCode 8.3 und aktuelle iOS Unterstützung - Warum gibt es keine offene Datei der Bildfiles der styles - Performance der ersten Animation in mobil - Tokyo ist in meinen Augen für mobil nicht einsetzbar (habe die entsprechendenOC Einträge gemacht) |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
"sb" hat das Forum auf eigenen Wunsch verlassen.
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
Aber ich kann ihn verstehen. gruss |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
Falls ich dir auf den Slips getreten bin, war das nicht meine Absicht. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo Uwe,
ich habe mal ein Bild angehängt. Bei einer offenen Datei kann ich ein Objekt auswählen und einfach die Kontur, die Füllung und auch den Eckenradius bearbeiten. Bei den exportierten Dateien kann ich nur über Farbe ersetzen/ändern die Farben ändern. Das ist gerade wenn die Objekte einen Verlauf haben bisschen umständlich und führt oft dazu, dass man immer mal Pixel im alten Design übrig bleiben. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Ja genau, schln das Du verstehst wad ich meine. Wäre halt klasse wenn man wenigsten den Default-Style als offene Datei hätte. Dann könnte man sehr bequem das Design anpassen. Kann man dann ja als bmp speichern und importieren.Aktuell bin ich immer dazu verleitet im Stylenanager Rectangle über Rectangle zu legen...
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Wir wäre das denn bzgl. copyright wenn ich denn Default-Style als Vektorgrafik bereitstelle?
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zitat:
Aus Weitergabe von Embarcadero Delphi 10.2- und C++Builder 10.2-Anwendungen in radstudio_deploy_de.htm (emphasize by me): Zitat:
|
AW: Find out why after 22 years more developers than ever are choosing Delphi
Das Erstellen von Vektorgrafiken nach Vorlage ist ja eigentlich keine Bearbeitung. Selbst das direkte (automatisierte) Vektorisieren von Bitmaps fällt da nicht darunter.
Um keine Verwirrung zu stiften: Es geht mehr um die rechtliche Unterscheidung von Plagiat und Urheberrechtsverletzung. Wenn man den Faktor Zeitaufwand mal ausblendet finde ich es immer am besten, Vektorgrafiken von Grund auf neu zu erstellen. Auch wenn ich Webseiten baue sind die Grafiken immer von mir selbst erstellt und keine abgewandelten Arbeiten von anderen Leuten. Da ist man immer auf der sicheren Seite. Bisher habe ich das überwiegend mit Corel Draw gemacht, aber in letzter Zeit finde ich auch Gefallen an Inkscape. Ich meine mich zu erinnern, dass Microsoft selbst zu XP- oder Vista-Zeiten mal daran gearbeitet hat, rein vektorbasierte UI umzusetzen. Da gab es auch mal eine Roadmap die für eine (inzwischen Vergangenheit seiende) Zukunft frei skalierbare Icons vorsah. Davon scheint aber heute kaum etwas umgesetzt zu sein. Im Übrigen ist das etwas, das mir auch bei Android und iOS sauer aufstößt. Es wäre ein leichtes gewesen, die Icons als SVG zu implementieren. Aber nööööö, stattdessen darf man jetzt ganze Stapel von PNGs in unterschiedlichen Größen mitliefern. Dem ganzen das Sahnehäubchen setzt dann Google auf mit der Empfehlung, die Icons immer von einem Vektor-Original abwärts zu skalieren und als PNG zu exportieren. Ich wage es kaum das zu erwähnen, aber das hat auch Auswirkungen auf die Größe der Binaries (bzw. APKs) Um mal wieder auf das Ursprungsthema zu kommen: Durch mehrere Umfirmierungen haben sich im Laufe der Zeit meine beruflichen Mailadressen immer mal wieder geändert. Der Emba-Vertrieb hat die alle in die Newsletter-DBen gepackt. Ich war dann einmal ganz entsetzt als ich nach langer Zeit mal wieder in die nach wie vor existierenden alten Postfächer geguckt habe. Im Schnitt alle drei Tage sieben identische Mails von Embadera, zu allem möglichen Zeugs. Und von Klicks auf "Newsletter abmelden"-Links habe ich mich vor langer Zeit verabschiedet, da das allzu oft das Gegenteil bewirkt. Selbst wenn man mal die Fallspezialität der mehrfachen Mailadressen ausblendet, so ist dieses aggressive Mailmarketing mehr lästig als vertriebsförderlich. Ich persönlich finde schon monatliche Newsletter übertrieben, aber Embadera treibt es auf die Spitze. |
AW: Find out why after 22 years more developers than ever are choosing Delphi
Zumindestens hier hätte aber das Abmelden mal funktioniert.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:22 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