fischertechnik community forum

ski7777 hat geschrieben: Aber wenn der Thread ja schon so weit oben ist, wir brachen mal einen "Zeitplan" für die V1.0 oder so.

Wozu brauchen wir den? Das hier ist reines Hobby. Warum sollten wir uns da künstlich unter Druck setzen?

ski7777 hat geschrieben: Interessante Punkte sind in meinen Augen:

• Bluetooth
• Launcher mit Ordnern und Scrollen
• Ein lebendiger Store
• und was ihr noch so wollt...

Bluetooth hast Du selbst übernommen, genauso wie die Einbindung des TX und wenn ich mich recht erinnere wolltest Du auch die ALSA-Audio-Anbindung machen sowie Apps für Deinen Convention-Modelle im Store veröffentlichen. Den Zeitplan für diese Dinge bestimmst Du damit weitgehend selbst.

Der scrollende Launcher hat Euch nicht gefallen und ich plane daher nicht, ihn in die offizielle Firmware z uübernehmen.

Und einen lebendigen Store kann man nicht einfach per Zeitplan beschließen. Das ergibt sich ggf. irgendwann ...

MasterOfGizmo hat geschrieben: Wozu brauchen wir den? Das hier ist reines Hobby. Warum sollten wir uns da künstlich unter Druck setzen?

Ich weiß, trotzdem könnten wir uns mal eine Liste von Dingen machen, die in der nächsten Version sein sollen.

MasterOfGizmo hat geschrieben: Bluetooth hast Du selbst übernommen

Ich bin bereits am Werk: https://github.com/ski7777/ftcommunity- ... bluetooth2

MasterOfGizmo hat geschrieben: genauso wie die Einbindung des TX

Da auch. Ich bin im Moment dabei, mir offizielle Informationen bei fischertechnik zu besorgen.

MasterOfGizmo hat geschrieben: wenn ich mich recht erinnere wolltest Du auch die ALSA-Audio-Anbindung machen

Die Grundidee funktioniert, jedoch passt das Encoding nicht und ich konnte ich den Fehler noch nicht lokalisieren.

MasterOfGizmo hat geschrieben: sowie Apps für Deinen Convention-Modelle im Store veröffentlichen

Wenn ich die Dateien finde, werde ich das mal machen.

MasterOfGizmo hat geschrieben: Den Zeitplan für diese Dinge bestimmst Du damit weitgehend selbst.

Nur, weil ich etwas übernehme, heiß das noch lange nicht, das sich andere nicht einbringen dürfen. Ich werde keine Pull Requests grundlos ablehnen.

MasterOfGizmo hat geschrieben: Der scrollende Launcher hat Euch nicht gefallen und ich plane daher nicht, ihn in die offizielle Firmware zu übernehmen.

In meinen Augen kam da nur positives Feedback, jedoch waren uns Probleme mit der Touchgenauigkeit aufgefallen. Mit einem einfachen Timer würde sich das lösen lassen

MasterOfGizmo hat geschrieben: Und einen lebendigen Store kann man nicht einfach per Zeitplan beschließen. Das ergibt sich ggf. irgendwann ...

Ich möchte hier nichts beschließen, sondern, würde gerne haben, dass beliebt Apps wie Brickly wieder in den Store kommen.

Raphael

Hat jemand meine letzten Beitrag gesehen?
Was haltet ihr davon?

Wie schon ein paarmal geschrieben bin ich hier nicht derjenige, der bestimmt was passiert und was nicht, Dass wir hier alle etwas unterschiedliche Ziele verfolgen ist auch normal, immerhin hat da jeder so seinen persönlichen Use-Case, auf den er hin arbeitet. Aber genau dafür gibt es ja Forks. Du kannst in Deinem Zweig ungehindert Deinen Ideen nachgehen, ich in meinem. Und wenn es für irgendwas einen Konsens gibt kann man es auch in das Hauptrepository übernehmen.

Wenn Du möchtest, dass die offizielle Firmware bestimmte Funktionen erhält und sich in eine bestimmte Richtung entwickelt und Du derjenige bist, der das gerne koordinieren möchte, dann arbeite ich gerne weiter an meinem eigenen Fork und Du übernimmst die Arbeiten am offiziellen Zweig. Das habe ich mehrfach angeboten, aber auch das bestimme nicht ich einfach so. Sobald sich hier eine Mehrheit für ein "ja, bitte lasst Raphael die Koordination des Hauptrepositories übernehmen" ausspricht werde ich Dir volle Schreib- und Admin-Rechte geben.

Wenn das am Ende dazu führt, dass einer von uns nur noch an seinem eigenen Fork arbeitet ist das m.E. auch kein Problem. Dann arbeitet er entweder eh an den Wünschen der Mehrheit vorbei und die Mehrheit wird ihn ignorieren oder die Mehrheit wendet sich diesem Fork zu. Auch das wäre dann in keiner Weise ein Problem sondern gelebte Demokratie.

Aber man kann das nicht erzwingen. Das ist ein Hobby und jeder darf und soll es so machen, wie er mag. Und wenn es z.B. mir nicht gefällt, was Du mit dem Apps-Repository machst, dann ziehe ich meine Apps in ein anderes Repository um. Das ist dann halt so ...

Jungs,
als - was die fw-Entwicklung betrifft - Außenstehender wollte ich mich aus Diskussionen in dieser Richtung eigentlich raushalten, aber jetzt kann ich es mir doch nicht verkneifen...

Zunächst mal finde ich es beeindruckend, was die Community leisten kann. Wenn man die überraschten Reaktionen von TXT-Besitzern sieht, die zum ersten Mal über die cfw stolpern, dann ist das eine massive Bestätigung dafür, daß die cfw auf dem richtigen Weg ist und daß dafür auch Bedarf und Interesse weit über den Einzelnen hinaus besteht.

Und genau deshalb sollten sich die Beteiligten im Klaren sein, daß es eben nicht nur reines Hobby eines jeden Einzelnen ist, sondern daß nach außen hin die cfw als Ganzes Erwartungen weckt, was bei Enttäuschung nicht nur auf die community, sondern auf das ganze ft-Universum zurückfällt. Das erklärt sicher auch die Zurückhaltung seitens ft, wenn es um die cfw geht...

Daher denke ich, daß die cfw tatsächlich etwas mehr Planung und Koordination bräuchte. Die Frage nach einer Roadmap halte ich für absolut berechtigt. Und dazu gehört, daß festgelegt wird, welche Features enthalten sein sollen, daß für einzelne Features auch Verantwortliche auf den Zettel kommen und daß Terminvorgaben gemacht werden. Irgendwann muß man den Sack mal zumachen, sonst wird es keine stable releases mehr geben.
Es ist sicherlich eine Herausforderung, aus einem Haufen Alphatiere verschiedensten Alters ein geordnetes Rudel zu machen, daß gemeinsam in die selbe Richtung rennt, aber wenn die cfw nicht als Scherbenhaufen enden soll, ist das m.E. durchaus nötig. Leider kommen da dann - Stichwort Alphatier - wieder persönliche Befindlichkeiten ins Spiel. Das ist genauso verständlich wie problematisch, muß aber irgendwie doch überwunden werden.

Bedenkt doch bitte auch den durchaus limitierten Produktlebenszyklus des TXT. Der ist nämlich schon zur Hälfte abgelaufen. Aus diesem Grund ist es für mich absolut inakzeptabel, daß Brickly als Vorzeigeprojekt in einem bereits absolut nutzbaren Zustand NICHT Bestandteil der cfw bzw. nicht über den offiziellen App-Store erhältlich sein soll und darauf verwiesen wird, daß da ja dann "irgendwann noch" RoboBlocks kommen soll, während RoboBlocks selbst aus verständlichen Gründen bei seinem Autor wiederum u.a. auch wegen der Existenz von Brickly so niedrig priorisiert wurde, daß im Moment keine Aussagen zur Verfügbarkeit getroffen werden können.

Das Dumme dabei: Es gibt schon seit Langem Bedarf für eine solche Einsteiger-IDE. Es gibt bereits erste Interessenten, die diese IDE - Brickly - im schulischen Umfeld nutzen möchten. Es gibt Interessenten, die den Bedarf so einschätzen, daß sie durch die Erstellung von Tutorials den Einstieg erleichtern wollen, und das alles wird dann durch die Idee, Brickly "irgendwann" offiziell durch RoboBlocks zu Ersetzen, ad absurdum geführt?
Brickly ist schon viel zu weit, um es unter der Tischdecke zu halten, und es macht m.E. auch keinen Sinn, die Entwicklungsarbeit 2x zu leisten.

Meine Bitte, ganz ausdrücklich an Richard und Till:
Eure Arbeit ist spitze und extrem wertvoll, für die community, für fischertechik, für einen ganzen Haufen von Anwendern!
Wäre es vorstellbar, daß Till den Status von Brickly überdenkt und TouchUI - GERNE mit scrollendem Launcher! - und Brickly als seine Babys weiter supportet, so daß es für Dritte Sinn macht, längerfristig mit Brickly zu planen, während Richard ein klein wenig mehr Koordination - verbunden mit der dazugehörenden Kommunikation - für die cfw übernimmt und die Konkurrenzsituation Brickly-RoboBlocks nochmal überdenkt? Noch ist nicht zu viel Zeit in RoboBlocks geflossen, und m.E. wäre Richards Einsatz an anderer Stelle wesentlich wichtiger.
Mit einer sauberen CFW1.0, Brickly, Python und C als Entwicklungsumgebungen, der Möglichkeit, auch RoboPro weiter zu verwenden und einer (nach außen hin, halbwegs, im Rahmen der Möglichkeiten) geschlossen in einer Richtung agierenden community könnte man dann evtl. auch fischertechnik selbst davon überzeugen, daß ein TXT2 mit leistungsstärkerem ARM-Prozessor, evtl. mehr RAM und wertigerem Touchscreen (größer, evtl. höher auflösend, sensitiver/reaktiver) softwareseitig abwärtskompatibel zu cfw bleibt (siehe Raspberry 2 -> 3), so daß der cfw eine längere Zukunft beschieden ist und sich der Einsatz Aller dann auch über die Jahre auszahlt.

So, das wollte ICH jetzt mal gesagt haben. ICH habe den TXT nach langem Zögern ausschließlich wegen der cfw und wegen Brickly angeschafft, meine Kinder waren erst mit Brickly für die Robotik zu begeistern und ich denke, wir alle haben unsere Verbindung zu fischertechnik und möchten letztlich zum Erhalt und Ausbau des Systems beitragen, weil es uns eine Herzenssache ist. Gemeinsam.

Peter

nq30 hat geschrieben:Hat jemand meine letzten Beitrag gesehen?
Was haltet ihr davon?

Ja, gesehen und würde ich auch unterstützen. Eine zentrale Konfig-App, statt hier ein bisschen, da ein bisschen...

PHabermehl hat geschrieben:

nq30 hat geschrieben:Hat jemand meine letzten Beitrag gesehen?
Was haltet ihr davon?

Ja, gesehen und würde ich auch unterstützen. Eine zentrale Konfig-App, statt hier ein bisschen, da ein bisschen...

Das habe ich schon oft gesagt, bin da aber gegen eine Wand gerannt.

Raphael

ski7777 hat geschrieben: Das habe ich schon oft gesagt, bin da aber gegen eine Wand gerannt.

Dann auch hier die Bitte, dann aber die Verantwortung für das resultierende Tool zu übernehmen. Für mich selbst habe ich nun hierarchische Ordnerstrukturen im Launcher, damit ich eben alle Settings-Apps in einem Settings-Ordner habe. Wenn ihr stattdessen lieber eine eigene App haben wollt ist das absolut legitim. Mir persönlich ist der Audwand zur Zeit zu groß, so eine All-in-One-App zu pflegen da dort ja auch noch Bluetooth, Bluetooth-IP, USB-Netz etc ect dazu käme.

Aber wie gesagt: Wenn einer die Hand hebt und ab jetzt für so ein All-in-one-Tool verantworltich sein will, dann bekommt er entsprechenden Zugriff auf's Hauptrepository und kann loslegen. Ich selbst halte die aktuelle kleine Menge einzelner Tools für besser wartbar. Aber das liegt im Auge des Betrachters.

Wer übernimmt es?

ski7777 hat geschrieben:

PHabermehl hat geschrieben:

nq30 hat geschrieben:Hat jemand meine letzten Beitrag gesehen?
Was haltet ihr davon?

Ja, gesehen und würde ich auch unterstützen. Eine zentrale Konfig-App, statt hier ein bisschen, da ein bisschen...

Das habe ich schon oft gesagt, bin da aber gegen eine Wand gerannt.
Raphael

Ich wäre dafür dass wir einen Kompromiss finden, und uns nicht gegenseitig beleidigen, sondern eine Lösung finden, die:

1. alle Möglichkeiten die der TXT(und evtl. Nachfolger) ausnützt
2. alle User (vorallem die Community (Mehrheit)) gut findet, mit der aber auch alle leben müssen.
3. die eine sinnvolle, gleichmäßig und faire Verteilung der Aufgaben auf die Entwickler ermöglicht und die Chance gibt ungefähr nachzuvollziehen wann, was kommt.

Evtl. sollten sich sogar alle FT-CFW Entwickler an einen Tisch setzen einmal gescheit aber ordentlich diskutieren und dadurch eine für alle akzeptable Lösung finden?
Soweit meine Meinung

Hochachtungsvoll,
Lars

PHabermehl hat geschrieben: als - was die fw-Entwicklung betrifft - Außenstehender wollte ich mich aus Diskussionen in dieser Richtung eigentlich raushalten, aber jetzt kann ich es mir doch nicht verkneifen...

Wieso "als Außenstehender"? Du bist doch schon mitten drin in der CFW-Entwicklung.

PHabermehl hat geschrieben: Und genau deshalb sollten sich die Beteiligten im Klaren sein, daß es eben nicht nur reines Hobby eines jeden Einzelnen ist, sondern daß nach außen hin die cfw als Ganzes Erwartungen weckt, was bei Enttäuschung nicht nur auf die community, sondern auf das ganze ft-Universum zurückfällt.

Da muss ich jetzt allerdings sagen: Egal ob die CFW jetzt "Erwartungen weckt" oder nicht, für mich ist es trotzdem ein Hobby. Das mach ich in meiner Freizeit. Unbezahlt. Und genau deswegen mache ich das auch in dem Umfang, und zu den Zeiten, und auf die Art wie ICH das will.

Wenn das nicht so wäre, dann würde sich die Arbeit an der CFW nämlich nicht wesentlich von meinem ganz normalen Job unterscheiden. Mit dem klitzekleinen Unterschied, dass normalerweise meine Kunden einen vierstelligen Betrag pro Tag dafür bezahlen, dass ich für sie nach ihren Wünschen Software entwickle.

PHabermehl hat geschrieben: Daher denke ich, daß die cfw tatsächlich etwas mehr Planung und Koordination bräuchte. Die Frage nach einer Roadmap halte ich für absolut berechtigt. Und dazu gehört, daß festgelegt wird, welche Features enthalten sein sollen, daß für einzelne Features auch Verantwortliche auf den Zettel kommen und daß Terminvorgaben gemacht werden.

Eine Roadmap fände ich ebenfalls nicht schlecht. Von mir aus auch noch mit einer Aufstellung, wer welche Aufgaben übernehmen will. Da ist die Frage denke ich eher, wie man das im Detail organisieren will (auf Github? Hier im Forum?).

Aber ganz bestimmt keine Terminvorgaben. Um es nochmal ganz deutlich zu sagen: Das hier ist ein Hobbyprojekt, das in der Freizeit der Beteiligten erstellt wird. Da sind irgendwelche Ansprüche und Forderungen nicht wirklich angebracht.

Und damit jetzt aber auch genug Rant.

Bzw. fast, und mit einer etwas positiveren Note: Die CFW lebt vom Mitmachen. Und wer mitmacht, der kann auch beeinflussen in welche Richtung die CFW geht und wie schnell die CFW weiterentwickelt wird. Von daher: Beteiligt euch. Macht mit. Das ist der schnellste und einfachste Weg Eure Wünsche an die CFW umzusetzen.

PHabermehl hat geschrieben: Eure Arbeit ist spitze und extrem wertvoll, für die community, für fischertechik, für einen ganzen Haufen von Anwendern!
Wäre es vorstellbar, daß Till den Status von Brickly überdenkt und TouchUI - GERNE mit scrollendem Launcher! - und Brickly als seine Babys weiter supportet, so daß es für Dritte Sinn macht, längerfristig mit Brickly zu planen, während Richard ein klein wenig mehr Koordination - verbunden mit der dazugehörenden Kommunikation - für die cfw übernimmt und die Konkurrenzsituation Brickly-RoboBlocks nochmal überdenkt? Noch ist nicht zu viel Zeit in RoboBlocks geflossen, und m.E. wäre Richards Einsatz an anderer Stelle wesentlich wichtiger.

Das sehe ich ähnlich. Brickly ist auf jeden Fall gut genug um es zu verwenden (sieht man ja auch am Echo hier im Forum), und ich habe in der CFW auch noch jede Menge anderer Baustellen offen ohne jetzt unbedingt sofort RoboBlocks weiter bauen zu müssen. Und die Arbeit an Brickly ist wäre ja auch nicht umsonst auch wenn es irgendwann mal RoboBlocks gibt - das ist nämlich letztendlich auch nicht viel anderes als eine Kombination von Brickly und BrickMCP fest in die CFW eingebaut..

PHabermehl hat geschrieben:

nq30 hat geschrieben:Hat jemand meine letzten Beitrag gesehen?
Was haltet ihr davon?

Ja, gesehen und würde ich auch unterstützen. Eine zentrale Konfig-App, statt hier ein bisschen, da ein bisschen...

Ich fände es da besser, wenn es für die getrennten Aspekte der Konfiguration auch jeweils passende Konfig-Apps gibt, die man dann in einer gemeinsamen Kategorie im Launcher zusammenpackt. Vor allem angesichts der Tatsache, dass man das mit dem neuen "Launcher V2" von Till schön machen kann, und dass die App-Startzeiten (gerade für System-Apps) mit den von mir skizzierten "Apps Light" auch kein Thema mehr sind.

Bei "der einen zentralen Konfig-App" sehe ich die Gefahr, dass man da Zeug zusammenschmeißt das thematisch einfach nicht zusammengehört. Oder - um den Kram zu strukturieren - dieselbe Funktionalität wie im Launcher grade nochmal neu erfindet. Oder beides...

Sehr gute Argumente, eine "Config-"Gruppe im Launcher v2 und die Configs als App-light würde ich für eine sehr gute Lösung halten.

PHabermehl hat geschrieben:Sehr gute Argumente, eine "Config-"Gruppe im Launcher v2 und die Configs als App-light würde ich für eine sehr gute Lösung halten.

Das ist eine gute Idee.

Raphael

richard.kunze hat geschrieben:Wieso "als Außenstehender"? Du bist doch schon mitten drin in der CFW-Entwicklung.

Meine Fähigkeiten und mein Wissen reichen bei weitem nicht aus, um mir das anzumaßen. Wenn ich mal einen erfolgreichen Build auf die Reihe kriege, sehen wir weiter.

richard.kunze hat geschrieben:Da muss ich jetzt allerdings sagen: Egal ob die CFW jetzt "Erwartungen weckt" oder nicht, für mich ist es trotzdem ein Hobby. Das mach ich in meiner Freizeit. Unbezahlt. Und genau deswegen mache ich das auch in dem Umfang, und zu den Zeiten, und auf die Art wie ICH das will.

Das wollte ich auch gar nicht in Frage stellen. Ich denke mal, wir machen das alle unbezahlt und in unserer Freizeit. Was ich meinte, ist, daß wir uns TROTZDEM über die Außenwirkung im klaren sein müssen.

richard.kunze hat geschrieben:Wenn das nicht so wäre, dann würde sich die Arbeit an der CFW nämlich nicht wesentlich von meinem ganz normalen Job unterscheiden. Mit dem klitzekleinen Unterschied, dass normalerweise meine Kunden einen vierstelligen Betrag pro Tag dafür bezahlen, dass ich für sie nach ihren Wünschen Software entwickle.

Hmmmmm.... wenn ft sich solche SW-Entwickler leisten würde, hätten sie eine vorzeigbare Firmware, aber der TXT wäre nicht mehr bezahlbar. Und wenn ich solche Tagessätze bekäme, würde ich mir eine persönliche firmware in Indien erstellen lassen und in meiner Freizeit nur noch Anwender sein

richard.kunze hat geschrieben:Eine Roadmap fände ich ebenfalls nicht schlecht. Von mir aus auch noch mit einer Aufstellung, wer welche Aufgaben übernehmen will. Da ist die Frage denke ich eher, wie man das im Detail organisieren will (auf Github? Hier im Forum?).

Ich denke da im Detail an folgendes:

- einen "release candidate" branch, in dem nur noch bugfixing im Hinblick auf das release betrieben wird. Dazu gehörte dann auch eine buglist und die Nennung des Bearbeiters. Wer dann unterstützen möchte, weiß, an wen er sich wenden muß. Außerdem ließe sich dann bei Interesse zumindest ungefähr abschätzen, wie weit ein release noch entfernt ist...

- einen "stable" branch, in dem das jeweils letzte release als Quelle und als fertiger Build liegt

- einen "devel" branch, in dem die neuen features integriert werden können.
Jeweils nach einem release wird im devel ein feature freeze durchgeführt, der gefreezede Stand wandert nach "rc", der ehemalige "rc" logischerweise in "stable" und ... weiter gehts.

Davon unabhängig kann ja jeder forken, wo und was er will......

Daher -> GitHub.

richard.kunze hat geschrieben:Aber ganz bestimmt keine Terminvorgaben. Um es nochmal ganz deutlich zu sagen: Das hier ist ein Hobbyprojekt, das in der Freizeit der Beteiligten erstellt wird. Da sind irgendwelche Ansprüche und Forderungen nicht wirklich angebracht.

Wiederum Innenwirkung vs. Außenwirkung... Unter Außerachtlassung der genauen Umstände möchte ich auf eine Aussage wie "Der TXT ist so absolut unbrauchbar!" im Zusammenhang mit der cfw verweisen. Die Details spielen keine Rolle, aber wer bei einer Recherche zum TXT oder der cfw auf eine solche Aussage stößt, der wird wohl eher abgeschreckt. Also, was öffentlich zugänglich ist, sollte auch funktionieren. Evtl. ist da eine deutlichere Trennung zwischen release und development notwendig. Und was die Terminvorgaben betrifft, war ich zu unpräzise. Das soll keine Verpflichtung sein, sondern ein selbstgestecktes Ziel, daß das Abschätzen eines release-Zeitpunktes ermöglicht.

richard.kunze hat geschrieben:Und damit jetzt aber auch genug Rant.

Ich sehe das nicht als rant, es war von meiner Seite eine Reihe von Gedanken, die mich seit geraumer Zeit bewegten und die ich mal zur Diskussion stellen wollte. Wenn ich einstimmige Meinungen hören will, frage ich meine Kinder, ob Mama kochen soll oder wir lieber mal wieder gemeinsam einen Döner essen wollen

richard.kunze hat geschrieben:Bzw. fast, und mit einer etwas positiveren Note: Die CFW lebt vom Mitmachen. Und wer mitmacht, der kann auch beeinflussen in welche Richtung die CFW geht und wie schnell die CFW weiterentwickelt wird. Von daher: Beteiligt euch. Macht mit. Das ist der schnellste und einfachste Weg Eure Wünsche an die CFW umzusetzen.

Da ist es sicher oft weniger das Wollen als das Können... Sich nebenbei und unentgeltlich zum Fachinformatiker weiterzubilden, will ja auch nicht jeder.

richard.kunze hat geschrieben:Und die Arbeit an Brickly ist wäre ja auch nicht umsonst auch wenn es irgendwann mal RoboBlocks gibt - das ist nämlich letztendlich auch nicht viel anderes als eine Kombination von Brickly und BrickMCP fest in die CFW eingebaut..

Um BrickMCP ist es nicht wirklich schade, ich bitte meinen Kommentar nicht diesbezüglich falsch zu verstehen. Es geht um mit Brickly erstellte Projekte bzw. evtl. sogar auf Brickly aufbauende Lernkonzepte mit entsprechendem Lehrmaterial (->Tutorials, Dokumentationen, Beispielprogramme etc.)
Wenn man den TXT mit cfw neben vergleichbaren Lego-Produkten sehen möchte, würde ich Kontinuität über Integrationsgrad stellen. So schön die Idee einer oder mehrerer fest integrierte IDEs in der cfw auch ist, wenn der Brickly-RoboBlocks-Übergang für die Anwendermehrheit einen harten Bruch darstellen würde, wäre das ein massiver Nachteil. Brickly und RoboBlocks parallel weiterzuentwickeln bindet unnötige Ressourcen. Und dann droht ja irgendwann der ft-seitige Bruch in Form eines TXT-Nachfolgers, wobei ich mir da ja wie schon erwähnt sehr sinnvoll ein Prozessor-Upgrade unter Gewährleistung einer firmwareseitigen Abwärtskompatibilität vorstellen könnte. Ob das jemand bei ft auch so sieht, kann ich nicht beurteilen.

So, und jetzt nochmal ganz ausdrücklich DANKE AN ALLE FW-BETEILIGTEN, bitte versteht meine Äußerungen nicht als Negativ-Kritik. Meine Motivation rührt hauptsächlich daher, daß ich im Moment gerne Lokalisierung und USB-Schreibrechte hätte, und zwar so, daß auch andere ANWENDER davon profitieren, d.h., daß man die cfw nicht selber bauen muß, um die ganzen neuen features zu bekommen. Das bedingt einen 0.9.3er release, und dafür fehlen noch ein paar Kleinigkeiten, wenn ich richtig verstanden habe...

So, an dieser Stelle für mich Ende des Themas, damit das nicht zu weite Kreise zieht und am Ende wirklich noch jemand beleidigt ist.

Gruß
Peter

Also,
Vileicht ging es so: Und in der wlan.py Und?

nq30 hat geschrieben:Also,
Vileicht ging es so:

Code: Alles auswählen

from wlan import setup as wlans
from lang import setlang
from bt import setup as btsetup

Und in der wlan.py

Code: Alles auswählen

def setup():
#Code der Wifi-App

Und?

Ganz so einfach ist das auch wieder nicht
Und zum anderen haben wir ja bereits eine Lösung

PHabermehl hat geschrieben:Meine Fähigkeiten und mein Wissen reichen bei weitem nicht aus, um mir das anzumaßen.r

Na, komm. Ich finde Deine Beiträge wirklich toll. Wir übrigen kochen auch nur mit Wasser ...

Stimmt.
Als Ordner zu.machen ging auch.
Der Launcher 2 ist ja fertig.
Man könnte ihn ja einbauen.
Oder was meint ihr?

nq30 hat geschrieben:Stimmt.
Als Ordner zu.machen ging auch.
Der Launcher 2 ist ja fertig.
Man könnte ihn ja einbauen.
Oder was meint ihr?

Wenn das ganze fertig ist, wird MoG das sicher einbauen, wenn es da keine Einwände gibt. Schön wäre es, wenn die Settings Apps direkt in einem Unterordner von "System" zusammengefasst werden.

Raphael

ski7777 hat geschrieben:Schön wäre es, wenn die Settings Apps direkt in einem Unterordner von "System" zusammengefasst werden.

Fände ich auch