ehemaliger hat geschrieben: Mi 19. Dez 2018, 20:18
ak120 hat geschrieben: Di 18. Dez 2018, 15:51Unter Windows würde schon die Einbindung in Visual Studio genügen, welche Qt Creator begrenzt bietet.
Wenn Du Dir Qt Creator angeschaut hättest, dann wäre Dir aufgefallen, daß er
gar keine "Einbindung in Visual Studio" bietet, sondern einen Ersatz dafür darstellt. Wenn man unbedingt mit Visual Studio arbeiten will, dann kann man die "VS Integration Tools" verwenden, was aber ein völlig anderes Produkt darstellt.
Keine Ahnung wo dein Qt gekauft wurde, die Integration Tools sind beim Qt Creator mit dabei. Im Zweifelsfall sollte der jeweilige Produktmanager darüber Auskunft geben können.
Ganz einfach: Weil man nirgends eine Toolchain herbekommt, die unter den genannten Betriebssystemen läuft und OS/2-Binaries erzeugen kann.
Hier handelt es sich um gezielte Desinformation. Selbst mit den Open Source Werkzeugen von OpenWatcom oder GNU ist das problemlos möglich. Es handelt sich nicht gerade um unterschiedliche Prozessorarchitekturen.
Gäbe es eine solche, so wäre es eine einfache Übung, sie in den jeweiligen Creator einzuhängen. Genau so wie man es mit der Android-Toolchain getan hat.
Dafür gab oder gibt es auch eine Nummer im Katalog.
Quelltext erstellt man nicht auf der Konsole, sondern z.B. in Qt Creator. Dann klappt's auch mit dem UTF-8.
Das ändert nichts an der Tatsache, daß die so erstellte Konsolenanwendung UTF-8 nicht darstellen kann, wenn man nicht zusätzliche Umwandlungen in 8-bit Ausgabeformate vornimmt.
Völlige wirres Zeug. Etwas seltsames geraucht?
Dann betrachten wir doch einfach mal ein paar bunte Bildchen:
- bww-gcc.png (6.66 KiB) 9399 mal betrachtet
Der C Compiler aus der RPM-Installation scheint keine Lust zu haben.
- gnu-gcc.png (6.14 KiB) 9399 mal betrachtet
Nur um zu zeigen, daß es es nicht am Compiler liegt, und auch unter OS/2 Versionen jenseits von 2.11 getestet wurde.
Es geht nicht um Pflege irgendwelcher Oldies. Aktuelle Software erfordert aktuelle Compiler. Im Besonderen bei C++. Und da kannst Du VisualAge, OpenWatcom oder gar Borland in die Tonne treten. Momentan sind für moderne Dinge nur noch GCC, Clang und Microsoft geeignet.
Ob der per RPM ausgelieferte Compiler nun als aktuell gilt oder nicht, ist völlig nebensächlich. Für standardkonformes Verhalten ist es auch nicht das ausschlaggebende Kriterium. Da sollte man wohl eher den Hebel bei der Bibliotheksunterstützung ansetzen. Aber es scheint wohl populär zu sein das Gerümpel aus BSD 4 (oder wie hier von einigen postuliert: "aus dem letzten Jahrtausend") mitzuschleppen.
ak120 hat geschrieben: Mi 19. Dez 2018, 17:42Als eine Art Dialogeditor mit Teilfunktionalität. Zu einer etwas vollständigeren Entwicklungsumgebung gehört dann schon etwas mehr.
Wenn ich mich recht entsinne, war der OS/2 Creator eigentlich ziemlich vollständig. Inclusive Integration verschiedener Versionskontrollsysteme,[/quote]
Das kann schon sein. Wenn man das Qt wie empfohlen per RPM installiert erhält man leider nur den Designer und das Übersetzungsprogramm.
QML-Editor, Qt Designer und Hilfesystem.
Jetzt erinnere ich mich, das Hilfesystem war nicht zu gebrauchen.
Debuggen könnte ein Problem gewesen sein, was aber nicht am Creator gelegen habe dürfte, sondern eher am darunterliegenden Backend (gdb?). Für mich hat er damals auf jeden Fall gereicht...
Die Aussage ist für mich jetzt weder nachvollziehbar noch eindeutig
Dann werde ich wohl alles in eine Tonne werfen müssen.
) Zukunft tatsächlich ein voll funktiontüchtiger Browser verfügbar ist, sollte man ihn imho als kostenpflichtiges Produkt anbieten. Und ja, ich würde ihn kaufen (ohne meine Spende anrechnen zu wollen).