Moin Zusammen, Ich hatte gestern mal wieder das Beduerfnis etwas fuer Android zu programmieren und will das mit Qt machen. Zunaechst mal, hier gibt es eine sehr empfehlenswerte Anleitung: https://retifrav.github.io/blog/2017/12/28/qt-for-android/ Damit habe ich es letztlich hin bekommen. Aber die Installation war einige Stunden Aufwand. Mein System: Centos 7.4 Qt-Version: 5.12 Java: jdk1.8.0_181 ndk: android-ndk-r16b sdk: android-studio-ide-182.5199772 Der Haken, man bekommt sehr schnell Probleme wenn die Kombination aus Qt-Version, Java Version, ndk und sdk nicht genau passend ist. Man kann auch unter der Haube schnell Probleme bekommen. (gcc oder clang) Es ist auch keineswegs sichergestellt das man nicht noch irgendwo im System eine zu alte Libary hat. Wenn man kein SuperGuru Wissen genau fuer diese spezielle Software hat dann braucht man sehr schnell Anleitung und Hilfe aus dem Internet. Die kann aber auch schnell total falsch sein wenn sie auch nur eine Version zu alt oder neu ist. Und das Problem hat man nicht nur hier. Es ist also jetzt kein Qt Problem. Praktisch jede moderne Entwicklungsumgebung ist derart extrem fett und aufgeblaeht (Tausende von Libary im Untergrund) mit teilweise bizarren Abhaengigkeiten. Um das Problem auch nur grob in den Griff zu bekommen installieren sich da mittlerweile Gigabytes weil die Maintainer alles reinpacken. Dabei kommt natuerlich sehr viel bei er Installation aus dem Netz. Vermutlich ist es unmoeglich zwei Wochen spaeter nochmal dieselbe Entwicklungsumgebung aufzusetzen und ein identisches Binaerfile zu erzeugen. Da frag ich mich langsam wie das weitergehen soll. Es ist doch nur noch eine Frage der Zeit bis alles zusammenbricht weil es keiner mehr was hinbekommt... Jedenfalls wuenscht man sich das jede Software einen kleinen Knopf hat mit dem man dem Entwickler einen elektrischen Schlag von 1Volt versetzen kann und er mal die Summe des von ihm verursachten Unmutes alle User verspuert. :-D Olaf
Olaf schrieb: > Ich hatte gestern mal wieder das Beduerfnis etwas fuer Android zu > programmieren und will das mit Qt machen. Ungeeignetes Werkzeug. Kann man machen, gibt nur Schmerzen. Olaf schrieb: > Praktisch jede moderne Entwicklungsumgebung ist derart extrem fett und > aufgeblaeht (Tausende von Libary im Untergrund) mit teilweise bizarren > Abhaengigkeiten. Man kann Android-Programme auch mit vim schreiben und mit den Tools aus dem Android-SDK zu Fuß per Makefile bauen. Aber ob man das will, ist fraglich. Sicher ist, dass die Mehrheit der Android-Developer soetwas nicht nutzen. Dementsprechend ist das für Google keine Priorität - für andere auch nicht. Olaf schrieb: > Vermutlich ist es unmoeglich zwei Wochen spaeter nochmal dieselbe > Entwicklungsumgebung aufzusetzen und ein identisches Binaerfile zu > erzeugen. Warum sollte man das tun? Warum sollte man das wollen (für Android)? Die moderne Lösung ist, eine VM (oder ganz modern: einen Docker-Container) mit der gewünschten Version aufzusetzen und den zu benutzen. Google spezifiziert für jede Android-Version eine spezifische Ubuntu-Version und gut ist. Olaf schrieb: > Da frag ich mich langsam wie das weitergehen soll. Es ist doch nur noch > eine Frage der Zeit bis alles zusammenbricht weil es keiner mehr was > hinbekommt... Die Mobile Welt besteht aus Systemen, die für kontinuierliche Wartung gebaut sind. Es kommen Updates, die Anwendungen gehen kaputt, die Anwendungen werden aktualisiert, alles ist prima. Das Silicon Valley lebt nicht in der Vergangenheit, sondern in der Zukunft. Stabile Apps bringen nichts in einer Welt, die auf Services aufbaut. Da sich mit Software allein schlicht kein Geld mehr zuverlässig verdienen lässt und Cloud-Dienste zusätzliche Möglichkeiten bieten, geht die Welt eben da hin.
Augenblick mal – die Cloud-Dienste wollen doch permanent neue, zusätzliche Features verkaufen. Bugfixes für Probleme, die durch unsinnig hohe interne Komplexität entstanden sind, bringen doch kein Geld. Ganz im Gegenteil – die verzögern die Entwicklung neuer Features. Das war nicht so geplant. Da sind sowohl die BWLer als auch die Programmierer ganz gewaltig auf die Schnauze gefallen. Während des Hypes musste ein Cloud-Dienst ein paar Tage früher auf dem Markt sein, als die Konkurrenz. Damals hatte niemand Zeit für einen sauberen, übersichtlichen Aufbau. Dadurch ist alles dermaßen unsinnig Komplex geworden, dass wir es Heute nicht mehr aufräumen können. Den riesigen unentwirrbaren Haufen in einen Container packen und auf jede grundlegende Weiterentwicklung verzichten? Auf neue Werkzeuge verzichten, weil jede Veränderung den Mikadohaufen zum Einsturz bringt? Du widersprichst dir selbst. Dein Vorschlag beendet die Weiterentwicklung der Cloud-Dienste.
Stabile Software interessiert heute in weiten Teilen keinen mehr, Hauptsache, man kann möglichst schnell liefern. Dass dafür 100.000 Frameworks nötig sind, die Verantwortlichen interessiert das nicht. Komplexität ist der Feind jeder Sicherheit, und trotzdem bügelt man halt einfach noch schnell eine Schlangenöl-Pseudosecurity-Library drüber um das ganze "sicherer" zu machen, weil man die Software so schon nicht im Griff hat. Allgemein bekanntes Problem, v.a. im Web- und Appbereich. Kein Wunder, gerade dort müssen Programmierer in erster Linie billig sein.
Komplexität ist auch der Feind der Wirtschaftlichkeit. Billige Leute irgendwelche Schnellschüsse übereinander stapeln lassen? Das ist nur ein paar Jahre lang wirtschaftlich. Inzwischen wachsen uns die Kosten für Workarounds, Bugfixes und Sackgassen über den Kopf. Eigentlich haben wir immer wieder das selbe Problem. In den 70ern wurden die Großrechner zu komplex. Jede popelige Programmänderung dauerte Monate. Wir hatten mit PC-Netzen neu angefangen. In den 90ern wurden die PC-Netze zu komplex. In diesem Wildwuchs an inkompatiblen, undokumentierten Protokollen ging nichts mehr voran. Die Antwort waren dann die Web-Dienste. HTML Dokumenten-Browser als Applikativen-Framework nutzen - da ist uns die Komplexität ziemlich schnell über den Kopf gewachsen. Wir schreiben Apps statt Weboberflächen. Inzwischen ist in der App-Programmierung das Sammelsurium an Frameworks, Containern und Deployment-Scripten zu komplex geworden. Mal schauen, was als nächstes kommt.
Hinz und Kunz schrieb: > Billige Leute irgendwelche Schnellschüsse übereinander > stapeln lassen? Das ist nur ein paar Jahre lang wirtschaftlich. Nur, wenn du langfristig denkst. Wenn deine Lösung nur 2 Jahre halten muss, dann sind Schnellschüsse billiger als eine richtige Lösung. Wenn du deinen Kunden alle 2 Jahre eine vollständige Neuentwicklung verkaufen kannst, sind Schnellschüsse trotzdem sinnvoll. Vor allem, wenn sich die Anforderungen und Wünsche ständig ändern. Und zu guter Letzt bestehen die meisten Startups nur aus Kapital und einer Idee. Entwickelt wird maximal ein proof-of-concept, der dann produktiv eingesetzt wird und hoffentlich so lange hält, bis eine richtige Lösung mit richtigen Entwicklern entwickelt werden kann. Time-to-market ist wichtiger.
Nur mal so ein Gedanke…. Google will weg von Open Source, einen Android Nachfolger durchsetzen, bei dem Google alles unter Kontrolle hat. Deren Strategie: Sie machen die Entwicklungsumgebung so komplex, dass niemand mehr LineageOS weiter entwickeln kann. Das niemand mehr Entwicklungsumgebungen für den Android Nachfolger bauen kann. Und das niemand mehr fremde Libraries in die Google Welt einhängen kann. Traut ihr Google so eine Strategie zu? Oder entsteht die Komplexität einfach nur aus der Kurzsichtigkeit der Manager?
Hinz und Kunz schrieb: > Traut ihr Google so eine Strategie zu? Nein, das wäre Google-untypisch. Außerdem unterschätzt du die Entwickler alternativer Distributionen und überschätzt die Entwickler von Android-Hardware. Der Tod von Android wird so aussehen, dass ein alternatives, aber kompatibles Betriebssystem angekündigt wird (ChromeOS unterstützt Android-Apps, ist also machbar). Dieses System wird im Gegensatz zu Android weiterentwickelt, bis es für Entwickler zunehmend eklig wird, beides bei voller Funktionalität zu unterstützen. Irgendwann wird die Unterstützung der Google Services für Android aus technischen Gründen eingestellt und die Plattform ist damit wirtschaftlich tot. Das sehe ich auf absehbare Zeit nicht kommen. Smartphones sind schwierig und Google scheint sich nicht mit den tausend Eigenheiten der verschiedenen Märkte und Operators rumschlagen zu wollen. Das überlassen sie den Smartphone-Herstellern. Android Things ist da eine andere Hausnummer: Da gibt es zertifizierte Module und gut ist. Eigene Hardware kann man mit Android Things nicht nutzen und für das normale Android in solchen Szenarien gibt Google keine Zertifizierung. Hinz und Kunz schrieb: > Oder entsteht die Komplexität > einfach nur aus der Kurzsichtigkeit der Manager? Google ist riesig. Die Entwickler sind fähig und haben die Freiheit, das aus ihrer Sicht beste System zu bauen. Als Konsequenz hast du sehr viele Systeme, die jeweils unterschiedliche Probleme lösen. Das Zusammenspiel funktioniert "irgendwie", weil Google groß genug und fähig ist, um regelmäßig ganze Subsysteme umzuschreiben. Wenn man da von draußen draufguckt, ist das einfach nur pfui. Aber es funktioniert. Nicht, weil es elegant ist, sondern weil man da täglich tausend Commits reinstecken kann.
:
Bearbeitet durch User
Hinz und Kunz schrieb: > Komplexität ist auch der Feind der Wirtschaftlichkeit. Billige Leute > irgendwelche Schnellschüsse übereinander stapeln lassen? Das ist nur ein > paar Jahre lang wirtschaftlich. Inzwischen wachsen uns die Kosten für > Workarounds, Bugfixes und Sackgassen über den Kopf. Bin ich mir nicht sicher, irgendwie scheints zu funktionieren. Aber ja, hoffentlich implodiert das ganze mal.
Anscheinend können wir uns nur zwischen 2 Extremen entscheiden, die beide nur einige Jahre funktionieren. Wenn wir die Entscheidungen den einzelnen Handwerkern überlassen, wird das Zusammenspiel der Einzelteile zu komplex. Wollen wir das Zusammenspiel planen, bekommen wir eine unfähige Bürokratie, das alles lahmlegt. Ich bin für den ersten Weg. Während uns die Komplexität Kopf wächst, können wir einfach etwas neues aufbauen. Die Bürokraten dagegen verhindern mit aller Macht die Suche nach Auswegen. Wenn ich mir die Bürokratie in der DDR oder beim Berliner Flughafen so anschaue - da wähle ich auf jeden Fall die implodierende Komplexität.
Benutzt doch einfach iOS-basierte Systeme. Da kommt vom Chipdesign bis zu den Apps alles aus einer Hand und ist stimmig kombiniert. Dieses System ist euch zu geschlossen? Um ein einheitliches Design durchzusetzen braucht es nunmal Restriktionen.
Dr. Sommer schrieb: > Benutzt doch einfach iOS-basierte Systeme. Da kommt vom Chipdesign bis > zu den Apps alles aus einer Hand und ist stimmig kombiniert. Ja ne, is klar. Apple ist ja das perfekte Beispiel für schlanke Software ohne unnötige Komplexität. Ach, doch nicht: https://blog.fefe.de/?ts=a2be40ec Hinz und Kunz schrieb: > Ich bin für den ersten Weg. Während uns die Komplexität Kopf wächst, > können wir einfach etwas neues aufbauen. Wunderbar. Und gleichzeitig wird Software immer unsicherher, weil sie kaum noch wartbar ist, und 100000 Abhängigkeiten reingezogen werden. Gipfel ist ja das Electron-Framework, wo simple Desktopanwendungen auf einmal in Javascript geschrieben werden und eine komplette Brwoserengine im Hintergrund brauchen. Electron ist eine massiv unsichere Technologie, wie ein Webbrowser aus 2014 ohne Updates. Und der wie damals Firefox für seine Extensions APIs exponiert. Führt halt dann zu sowas: > The vulnerability allowed nodeIntegration to be re-enabled, leading to > the potential for remote code execution. [...] > Some popular applications such as Slack, Discord, Signal, Atom, > Visual Studio Code, and Github Desktop are all built using the > Electron framework. https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/cve-2018-1000136-electron-nodeintegration-bypass/ Oder sowas: > out of 98 top Electron apps, they averaged 145 known Common > Vulnerabilities & Exploits each due to unpached versions of Chromium https://twitter.com/jacobrossi/status/851992646151278592
Ich sehe in dem Zusammenhang noch eine weitere wichtige Fragestellung. Wieso wird moderne Software eigentlich nie fertig? (das war mal besser!) Schauen wir uns als Beispiel mal Internetbrowser an. Es ist klar das die erste Version von Mosaic nicht perfekt war und es da am Anfang einen gewissen Entwicklungsbedarf gab. Aber man sollte doch meinen das man da mittlerweile ein ausgereiftes Konzept/Standards hat. Man niemals mehr etwas verbessern muss, oder vielleicht alle 10Jahre mal den HTML Sprachumfang leicht verbessert und ansonsten nur alle paar Monate, später Jahre, mal ein Sicherheitsupdate raushauhen muss. Die Realitaet sieht irgendwie anders aus. Man koennte meinen Programmierer arbeiten bewusst darauf hin niemals arbeitslos zu werden. :-) Olaf
Olaf schrieb: > Man koennte meinen Programmierer arbeiten bewusst darauf hin niemals > arbeitslos zu werden. :-) Genau so ist es. Mit neuen Funktionen kann man mehr Kunden gewinnen. Da Software kein Verschleißteil ist muss man neue Versionen verkaufen anstatt immer wieder die selbe Version - irgendwann hat die jeder. Wer keine neuen Funktionen implementiert, wird von der Konkurrenz verdrängt. Ein Nebeneffekt ist dass alte Versionen auch keine Sicherheitsupdates mehr bekommen (viel zu aufwendig/teuer), sodass man auch niemandem, der moralische Probleme mit aktueller Software hat, empfehlen kann 10 Jahre alte Software (insb. Browser) zu verwenden. Oder meinst du dass Microsoft morgen alle Programmierer entlassen würde und einfach die nächsten 10 Jahre Lizenzen für die aktuellen Programmversionen verkaufen könnte?
Vor ein paar Jahren wollte ich auch mit der Android-Pogrammierung anfangen. Android-Studio runtergeladen und installiert. Waren etwa 4GB. Es wurden diverse Frameworks installiert, Java u.a.. IDE gestartet, Dateidialoge haben nicht funktioniert, "Datei nicht vorhanden" oder so aehnlich. Nach einer Neuinstallation das gleiche nochmal. Ich hab dann damit aufgegeben. Wenn so was Grundlegendes und eigentlich Einfaches schon nicht funktioniert... Aber irgendwie ist es auch sysrmtemimmanent. Nur mit komplexen Werkzeugen lassen sich komplexe Systeme erstellen. Und wirtschaftlich muss es auch noch sein. Der Kunde tut sein uebriges dazu. Er kauft den Akkuschrauber zum gleichen Preis lieber mit Schnellstoppfunktion, Selbstarretierung, Bohrfutterbeleuchtung, Display und Internetradio und nimmt dafuer mangelnde Qualitaet in Kauf.
Ich bin momentan bei Processing "hängengeblieben", damit lassen sich auch mit vorwiegend C-Kenntnissen recht einfach Apps erstellen. Dafür jetzt noch Java und OOP zu lernen, würde ich mir nicht antun wollen.
> jetzt noch Java und OOP zu lernen, würde ich mir nicht antun wollen.
Qt ist schon nicht schlecht. Das was man an Zeit investieren muss um C++
zu lernen spart man locker durch die vom System mitgebrachten Funktionen
wieder ein. Bloss die Installation muss man einmal schaffen.
Und es ist natuerlich extrem praktisch das man fast dasselbe Programm
auf dem PC wie auf dem Handy laufen lassen kann.
Olaf
Es kommt halt auf die Anwendung an. Auf dem PC bin ich bis jetzt mit GTK+ und SDL gut ausgekommen, da brauche ich nicht unbedingt C++. Ich habe jetzt auch nicht vor, professionell Apps zu programmieren, mir geht es momentan eher darum, alte Smartphones zu einer Art "zweitem Leben" zu verhelfen, indem man sie als Robotersteuerung etc. weiterverwendet. Also: Kamera, Accelerometer und GUI, der Rest wird via Bluetooth angebunden. Und selbst auf einem über 8 Jahre alten Samsung Wave, welches ich von Bada auf Cyanogen umgeflasht habe, läuft das erstaunlich flott. Jörg
Olaf schrieb: > Und es ist natuerlich extrem praktisch das man fast dasselbe Programm > auf dem PC wie auf dem Handy laufen lassen kann. Nachdem ich da auch schon durch bin (naja, noch nicht ganz): Prinzipiell stimmt das schon, insb. was den Kram hinter der GUI betrifft. Wenn man da konsequent mit den Qt-Funktionen für Netwerk, Files & Co gearbeitet hat, ist das mit nur kleinem Aufwand angepasst. Das Problem ist aber tatsächlich die GUI. Man kann den PC-Code zwar auch fast 1:1 übernehmen, leider ist er dann auf Android nahezu unbedienbar. Entweder schon rein geometrisch zu klein/unlesbar oder so an allen Android-Konventionen vorbei, dass man auch nicht glücklich wird. Also muss man mit QtQuick anfangen, wo es ja diverse Beispiele für Flickable&Co gibt. Aber dann strickt man wieder in so einer komischen Pseudosprache rum, die irgendwie vom Design her ein "moving target" ist. Und dann ist das IMO auch noch alles ziemlich (schwach|un)dokumentiert und tw. auch definitiv buggy. Auf jeden Fall ist eine mobil-taugliche GUI (wenn sie etwas komplexer und hübsch sein soll) dann schon aufwendig. Und für die mobilen System-Eigenheiten (Background-Services, Datenaustausch zwischen Apps, etc.) wirds dann richtig übel. Da brauchts dann wieder natives Zeug oder Fremdlibs (zumindest bei 5.11, 5.12 muss ich noch anschauen). Da muss man sich dann in die Niederungen begeben, die man mit Qt eigentlich vermeiden wollte. Ich habs jedenfalls noch nicht ganz verstanden.
> Also muss man mit QtQuick anfangen, Bah! > Das Problem ist aber tatsächlich die GUI. Man kann den PC-Code zwar auch > fast 1:1 übernehmen, leider ist er dann auf Android nahezu unbedienbar. > Entweder schon rein geometrisch zu klein/unlesbar oder so an allen > Android-Konventionen vorbei, dass man auch nicht glücklich wird. Ich mach einfach mehrere mainwindow.ui. Also z.B mainwindow_sonyZ.ui und mainwindow_ulefone.ui Dann binde ich einfach ein eigenes Headerfile ein wo ich umschalte. //#define SONY_Z #define ULEFONE #ifdef SONY_Z #include "ui_mainwindow_sonyZ.h" #endif #ifdef ULEFONE #include "ui_mainwindow_ulefone.h" #endif Der Nachteil ist natuerlich das man zwei ui pflegen muss. Aber soviel Aufwand ist das auch nicht. Die Ursache allen Uebels ist im uebrigen nicht so sehr die Geometrie oder die Aufloesung sondern die stark unterschiedliche dpi. Ich hab hier ein 10" Tablett und ein kleines Handy mit fast gleicher Aufloesung. Da muss man schon andere Fonts und Buttongroessen verwenden. Ich denke damit kann man auf dem PC auch viel Spass haben wenn man sich einen 4k Monitor kauft. Olaf
Olaf schrieb: > Wieso wird moderne Software eigentlich nie fertig? (das war mal besser!) Weil sich die Anforderungen ändern und es im Gegensatz zu früher einfach möglich ist, darauf einigermaßen schnell zu reagieren. Liegt die Reaktionszeit unterhalb eines vollständigen Entwicklungszyklus, ist die Software dauerhaft im Fluss. Es gibt keine Zeit mehr, um einfach mal ein halbes Jahr "Stabilisierung ohne Weiterentwicklung" zu spielen. In der Zeit würde das nämlich die Konkurrenz machen. Olaf schrieb: > Schauen wir uns als Beispiel mal Internetbrowser an. Meinst du damit den Internet Explorer 6, der ja erstaunlich lange "final" war und die Webentwickler in den Wahnsinn getrieben hat?
S. R. schrieb: > Olaf schrieb: >> Schauen wir uns als Beispiel mal Internetbrowser an. > > Meinst du damit den Internet Explorer 6, der ja erstaunlich lange > "final" war und die Webentwickler in den Wahnsinn getrieben hat? Vermutlich eher den Firefox 64.0 - ach nee, der ist schon bei 65.0. Gefühlt kommen zwei neue Major-Releases pro Woche raus.
Vieles an Ramsch auf dem Android-Markt bekommt nach spätestens 2 Jahren keine Updates mehr womit das System dann höchstwahrscheinlich auf irgendeiner kaputtgepatchten Version stehen bleibt. Der Androide ist wohlgemerkt NICHT "frei" - Updates gegen den Willen des Herstellers sind ausgeschlossen. Ansonsten finde ich die Diskussion hier eher übertrieben. Es ist nicht alles "iHandy Taschenlampe" mit einem Release-Cycle von 2 Wochen - so 2-3 Jahre muss man an unserer App z.B. schon gearbeitet haben, um überall mal vorbei gekommen zu sein. Gefühlt liefern wir mittlerweile das halbe Betriebssystem in Form von selbstkompilierten Libraries mit aus, um über ein weiteres Spektrum von Android-Versionen Support mal hier, mal dafür zu haben. Mit einer Qt-LTS-Version hätte ich schon geliebäugelt - ist frei und all inclusive, kommt für uns aber keinesfalls in Frage. Für ein paar Systemfunktionen wäre eine Sprachbrücke imho noch gerade tragbar. Als dauerhafter Zwischenzustand in Kernbereichen der App eher nicht. Schade: QML scheint mir gegenüber den Android-Views um einiges leichtfüßiger unterwegs zu sein. Die Sprache mischt sich erheblich besser mit den typischen "onClick"-Zweizeilern als die Androiden XML-Layouts, wo man kleine Codeblöcke nur in XML-Attributen(!) unter Stützung durch eine Java-Klasse einbetten kann. Vom Serverseitigen JSON direkt in den View injecten ginge nur mittels Maps als Datenstruktur und scheinbar kann man so auch nicht alle Eigenschaften setzen. Was uns zuweilen ziemlich zusetzt ist das undurchsichtige Speichermanagement. "vm_overcommit 1" hat so seine Nachteile, wenn man beliebige Mengen an Speicher gut gebrauchen könnte, sich dann aber auch mal das System verabschiedet. Das macht eine Java-VM nicht unbedingt besser: Kommt schon mal vor, dass der GC mit ein paar fetten Speicherbrocken in der Queue rumsitzt und meint "Ich bin clever und lazy" während im Untergrund der Renderloop mit "Out of Memory" aussteigt. Überhaupt bedarf das virtuelle Zeugs einiges an designtechnisch ziemlich ungesunden Verrenkungen: Da werden regelmäßig funktionslokale Variablen zu Klassenmembers, um zu verhindern, dass der GC die Animation abwürgt und strukturierte Daten, da diese Speicherallokationen benötigen, generell zugunsten von Spaghetticode vermieden: Eine temporäre Matrix manuell als "float m0, m1, ...." auszuschreiben und dann so damit zu rechnen ist in einer Androiden onDraw()-Funktion einfach nur Gosu!
> einfach nur Gosu!
Kann es sein das du dein Leben ueberwiegend mit Selbstgespraechen
verbringst weil es kaum jemanden gibt der deine Worte versteht? .-)
Olaf
Olaf schrieb: > Kann es sein das du dein Leben ueberwiegend mit Selbstgespraechen > verbringst weil es kaum jemanden gibt der deine Worte versteht? .-) Ich weiß das macht hier den Anschein ... - ist aber doch zu bezweifeln.
Was auch immer ein Gosu sein mag. Ich hab mal etwas gegoogelt und wikipediert. Es gibt/gab eine Programmiersprache, die so heißt, und im Gamer-Jargon bezeichnet man wohl jemanden mit überragend guten Fähigkeiten so. Beides passt irgendwie nicht so zu der Aussage. Dann gibt's noch eine Bibliothek für Spieleprogrammierung in Ruby mit dem Namen. Also keine Ahnung, was das sein könnte.
Rolf, natürlich ist das der Gamerjargon. Handies kommen doch alle aus Korea
Vielleicht ganz interessant das die Erkenntnis das sich was bessern sollte schon ganz oben angekommen ist. (vgl mein Ausgangsposting) https://www.youtube.com/watch?v=5PmHRSeA2c8 (6:50 bis 11:30) (31:00 bis 34) Nur Schade das es weiter unten noch nicht jedem einleuchtet. Olaf
Olaf schrieb: > Ich hatte gestern mal wieder das Beduerfnis etwas fuer Android zu > programmieren und will das mit Qt machen. Zu Zwecken der persönlichen Weiterbildung ok. Zum Beispiel um zu erkennen wie sehr man sich dann verrenken muß um Dinge zu tun die in der offiziellen Sprache, mit den offiziellen APIs ein Klacks wären. Ich hatte auch mal so eine Phase. Android Apps programmieren mit allem Möglichen, nur nicht mit den offiziellen Tools. Schmerzen, Verrenkungen, noch mehr Schmerzen. Fazit: Es ist die Mühe nicht wert. Android Studio installieren und ganz normal wie Millionen andere auch mit Java und dem offiziellen API und den offiziellen Tools arbeiten, dann kann man bei Problemen auch mal googeln und findet zutreffende Hilfestellung oder Beispiele die man nicht immer erst wieder rückübertragen muß auf den exotischen Ansatz den man selber fährt und sonst nur noch 3 andere auf der Welt.
> noch mehr Schmerzen. Fazit: Es ist die Mühe nicht wert. Android Studio > installieren und ganz normal wie Millionen andere auch mit Java und dem Mal abgesehen davon das ich mit so einem Mist nicht meine Lebenszeit verschwende, ich geniesse es das ich meine Programme sowohl unter Android wie auch Linux, ja gelegentlich sogar Windows nutzen kann. Olaf
Olaf schrieb: > ich geniesse es das ich meine Programme sowohl unter Android wie auch > Linux, ja gelegentlich sogar Windows nutzen kann. Wenigstens einer ;-) Ich kann den plattformunabhängigen Müll nicht leiden. Riesengroß, läuft auf allen Plattformen aber auf keiner richtig. Die unterschiedlichen Plattformen haben viel zu unterschiedliche Bedienkonzepte.
Olaf schrieb: > Mal abgesehen davon das ich mit so einem Mist nicht meine Lebenszeit > verschwende, ich geniesse es das ich meine Programme sowohl unter > Android wie auch Linux, ja gelegentlich sogar Windows nutzen kann. Vermutlich schreibst du halt auch Programme, die was leisten, und keine Apps.
> Die unterschiedlichen Plattformen haben viel zu unterschiedliche > Bedienkonzepte. Ich fuerchte da muss ich eine gegenteilige Position einnehmen. Die unterschiedlichen Bedienkonzepte sind oftmals dem Nutzungsprofil geschuldet. Bedien doch mal Windows (oder auch Linux) auf einem Tablett oder Laptop das sich als Tablett nutzen laesst und du wirst sehen wie bloed das ist. Jetzt moechtest du aber vermutlich weder dein Handy mit der Maus bedienen, noch zuhause am PC immer den Arm hochhalten um auf dem Monitor rumzutatschen. Was mich allerdings deutlich mehr nervt sind die grossen Unterschiede in den dpi auch innerhalb einer Geraeteklasse. Allerdings ist das wohl unvermeidlich wenn man mal ein gewisses Mass an Fortschritt erleben moechte. Olaf
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.