PXML Format aktualisiert


Und noch eine Frage:
Wenn zwei Applikationen dieselbe Dateityp-Verknüpfung im PXML deklarieren, welche hat Vorrang?
Ich check noch das Forum durch, die Frage wird hoffentlich schon irgendwo beantwortet sein.

Heute ist der 26.11., 2 Tage vor dem geplanten Release, ich schätze ihr seid ziemlich am schwitzen um die Software der Pandora überhaupt Mitte Dezember in einer guten Version zu releasen. Und das noch nebenberuflich. Respekt!! Ich vermute es wird eine Weihnachtsüberraschung werden :wink: Aber es wird das Warten wert sein!!
 
PandoraSuechtig said:
Heute ist der 26.11., 2 Tage vor dem geplanten Release, ich schätze ihr seid ziemlich am schwitzen um die Software der Pandora überhaupt Mitte Dezember in einer guten Version zu releasen. Und das noch nebenberuflich. Respekt!! Ich vermute es wird eine Weihnachtsüberraschung werden :wink: Aber es wird das Warten wert sein!!
Oo ich hoffe du hast nicht die nachricht mit den verzögerungen verpasst, es wird nur das ausgeliefert was vorhanden ist und funktioniert, alle anderren müssen weiter warten, und das was ausgeliefert wird ist sehr wenig (die glücklichen werden sich freuen^^)
 
Joar und danach wird wohl ausgeliefert was fertig/bei ED angekommen ist, so das also immer wieder ein paar ihre p&|a bekommen werden.
 
Also hab jetzt mal die Foren (de und com) durchwühlt. Es wird viel über den genauen Zweck und Umfang von PXML diskutiert. Es sind
  • Paketbeschreibung
  • Infos zum einbetten in einem Desktop (in etwas was in 'freedesktop.org's .Desktop drin ist)
Und manche wünschen sich UUID und Abhängigkeiten, um ein Paketsystem drauf aufzubauen, was aber nicht ausreicht. Primär ist das Problem, dass Pandorasoftware auf austauschbaren Medien "deployed" wird und die PXML verstreut sind (während .desktop gesammelt an fix definierten Stellen vorkommen und auf ein stabiles Dateisystem ausgelegt sind).
Zwar wären .desktop Dateien (fast) die Rettung damit Pandora Software auch auf einem z.B. Ubuntu laufen könnte, aber der Unterschied sind nun mal die verstreuten Applikationen. Jedes GUI, das die Pandora Software nutzen möchte, kommt nicht drumherum diese zusammenzusuchen da der in in einer .desktop datei definierte Pfad nicht fix definiert werden kann (Ausser ein Layer dazwischen sucht und mappt alles in fixe Verzeichnisse, on the fly .desktop files im /usr/share/.. generieren bzw. in einer ramdisk generieren und UniFS oder..., eine eher wilde und nur möglicherweise funktionierende Lösung und jede Distribution müsste dies extra implementieren, kurzum: absurd). Abgesehen davon sind .desktop Dateien nur ein Teil dessen was in PXMLs enthalten ist. Da dies also nicht "automatisch" mit anderen Linuxdistributionen laufen wird, macht es schon Sinn eine proprietäre Lösung für die Pandora zu erstellen.

Und das ganze schreit einfach nach einem Index (wie auch immer gelöst). Womit wir wieder bei unser alter Fehde sind :D

Und ich habe einen Mitstreiter: vosh64, der eine directory map (Index) haben möchte!
I was thinking that I think an interface should still be made that simply scans an SDCard and gathers all package information and a directory map, it would save alot of hassle for other GUI developers and better promote the adoption of the standard. That way, any GUI developers wouldn't have to fuss over using XML, nor would they have to worry about scanning through the SDCard(s) and extracting package information (especially from ZIP archives) and such
Wobei sein zweiter Satz mir etwas aufstösst. Das extrahieren der "package information" könnte man sich mit so einem Index nicht ersparen, denn dann müsste der Index auch gleich die ganzen Infos cachen. Das ist eine Anforderungskategorie höher. V.a. wenn die PXMLs erweiterte Infos für spezifische Apps/GUIs enthalten können und dasselbe noch in den user config xmls... Das ist zu generisch, besser nur einen Index und die GUIs/Apps suchen selber in den PXMLs. Auch wenn mich das ständige reparsing etwas stört. Natürlich könnte man die Indices erweitern um Indices für z.B. nach "Title"/"FileType assoz./Kategorien" usw. Das wär aber schon mehr Aufwand.
 
PandoraSuechtig said:
Und noch eine Frage:
Wenn zwei Applikationen dieselbe Dateityp-Verknüpfung im PXML deklarieren, welche hat Vorrang?
Ich check noch das Forum durch, die Frage wird hoffentlich schon irgendwo beantwortet sein.

Das liegt an der GUI :) Sie könnte z.B. abfragen, welche App das machen soll und sich dan die Voreinstellung merken, etc.
Das hat mit dem PXML selber nix zu tun :)
 
Danke, an sowas dachte ich auch, dass das GUI sich das merkt, die PXML gibt nur mögliche Assoziationen an.
Nur ist das trotzdem etwas viel User-activity. Jede einzelne Kollisionsabfrage zu beantworten? Und das GUI sollte sich die Antworten merken, falls die Karten wieder mal ausgetauscht werden. Dann kennt es wohl einige Applikationen pro Filetype, die dann zum Teil nicht mehr im System sind, aber das ist ein verschwindend kleines Übel bei jedem Öffnen einer Datei die "Prefärenzenliste" durchzugehen.
Lustig wär aber: Applikation A,B,C registrieren sich für JPEGs. Ich öffne ein JPEG, Abfrage: Ich wähle A. Entferne danach die Karte mit App. A und öffne wieder ein JPEG. Ups, wieder die Abfrage: B oder C? Ich wähle B. Beim wiedereinstecken sollte er dann wieder A prefärieren? Die GUI-Programmierer kriegen paar ganz neue lustige Situationen :D Man könnte auch im gleich im GUI einige Dialoge einbauen um "Präferenzenlisten" zu erstellen...
Für diese wäre eine UUID pro App wirklich ein Segen. Man will ja nicht überall Pfade ablegen als Referenzen für solche GUI-Konfigurationen, die dann nicht mehr stimmen, weil die Apps alle verschoben wurden... Autsch.
 
Nun - unsere Idee war, ein System zu schaffen, bei dem der Noob mit einem Installer alles auf die Karte kopieren kann, andere User aber einfach das ZIP-Archiv irgendwohin entpacken, aber alles automatisch richtig kategorisiert und konfiguriert ist.
Wenn man das Verzeichnis löscht, ist alles weg und es gibt auch keinen 'Restmüll' mehr.
Abhängigkeiten sind hier also nicht vonnöten.

Für die Commandline ist das aber unwichtig - denn schließlich geben da Kategorien nicht viel Sinn...
Und das ist ja der Hauptgrund fürs PXML :)
 
PandoraSuechtig said:
Und die Argumentation, dass die Programme die GUI nach dem Index abfragen könnten, greift nicht.
Wo habe ich das denn vorgeschlagen?
Auch wenn ich nicht zwei GUIs parallel laufen lasse, allein schon das Beenden einer GUI und das Starten einer anderen verzögert sich, wenn die neue GUI erneut die Disks durchsucht...
Nein. Die GUI soll ja eben nicht bei jedem Start die Disks durchsuchen. Abgesehen davon frage ich mich, wieso man überhaupt verschiedene GUIs einsetzen möchte? Wenn einem die Standard-GUI nicht gefällt, wird man die, so wie etwa beim GP2X auch, eventuell gegen eine andere GUI austauschen. Möglicherweise setzt man neben der GUI noch für manche Dinge X (zusammen mit irgend einem Window-Manager) ein. Das dürfte es dann aber auch schon gewesen sein.
Ich bezweifel, dass der ganze Suchvorgang überhaupt zu so einem großen Problem wird, wie hier behauptet. Ich denke, die meisten Benutzer werden nicht permanent neue Programme installieren. Hin und wieder sicherlich, aber das Installieren dürfte nicht der Haupteinsatzzweck der Pandora sein, sondern das Nutzen von Programmen und so lange sich nichts ändert muss auch gar nicht erneut nach Programmen gesucht werden. Also dürfte das eine eher seltene Aktion sein, für die es sich deswegen erst recht nicht lohnt einen Dienst laufen zu lassen (egal wie groß oder klein) - jeder Start eines Dienstes verzögert schließlich den Bootvorgang. Die Bootdauer schätze ich als wesentlich kritischer ein, als den Vorgang des Suchens nach neuen Programmen.

Was die anderen Verwendungsmöglichkeiten angeht, hast Du zwar einige Sachen aufgezählt, aber wirklich überzeugt, hat mich nichts davon.
Die PXML-Dateien sind in erster Linie dafür gedacht, dass eine GUI sich die "installierten" Programme zusammensuchen und sinnvoll in Kategorien einordnen kann. Man braucht aber, gerade weil man ja nicht wirklich installieren muss, kein System-Programm, dass einem die "installierten" Programme anzeigt - Programme, die man nicht mehr haben möchte, löscht man einfach von der SD-Karte. Fertig.
Wer tatsächlich seine installierten Spiele und Programme von der Shell aus starten möchte, wird sich vermutlich Symlinks ins bin-Verzeichnis packen können, um die Programme ausführen zu können, wobei selbst das ja relativ wenig Sinn macht. Auf der anderen Seite werden Programme, die man ohnehin nur von der Shell aus starten kann, gar nicht von PXML profitieren, weil eine Einordnung in Kategorien und Integration in die GUI sinnlos ist. Solche Programme wird man ohnehin im Pfad haben.
D.h. nicht, dass ich gegen das Anbieten der Einschränkung des Suchbereiches bin, sondern, dass dies ein Extra sein sollte, das man selten nutzt und schätzt und nicht dass daraus ein notwendiges Übel bei jedem Einlegen der disk wird, von der man weiss, dass sie zuviele Verzeichnisse enthält.
Was ist hier das Problem? Man muss doch nicht bei jedem Einlegen erneut die Auswahl treffen. Das kann man ein einziges Mal für die Karte tun. Ich denke nicht, dass man die Benutzer damit überfordern würde, beim ersten Einlegen der Karte EINMAL nachzufragen, was man tun möchte und ob die Karte nach Programmen durchsucht werden soll und ob man angeben möchte, wo auf der Karte Programme gesucht werden soll.

Letztendlich denke ich, dass die einfachste Lösung für das Problem wäre, einfach ein Verzeichnis vorzugeben, in dem Programme installiert werden sollen, z.B. /programs
Oder man lässt dem Benutzer die Auswahl, wie schon vorher vorgeschlagen. Gegen ein vorgegebenes Standardverzeichnis spricht aber auch nicht so viel.
Das Durchsuchen von dem einen Verzeichnis dürfte, auch mit vielen installierten Programmen, so schnell gehen, dass man sich den ganzen Aufwand sparen kann. Es bleibt ja trotzdem jedem selbst überlassen einen Index zu erstellen, wenn das jeweilige Programm davon profitiert.
Ich denke wichtiger als ein Index, ist beim Launch der Pandora, dass das PXML-Format von Beginn an durchdacht ist. Das schließt z.B. die Sache mit der UUID ein. Die kann durchaus sehr nützlich sein und wer sie nicht braucht ignoriert die Angabe einfach, aber so könnte man u.a. auch verschiedene Versionen der selben Software gruppieren, oder aber immer nur die neuste Version im Menü anzeigen, wenn mehrere auf der Karte vorhanden sind.
 
Hmm, gute Riposte, das Sparring gefällt mir :)
Wo habe ich das denn vorgeschlagen?
Nirgends, war nur eine Schlussfolgerung, daraus, dass wenn das GUI den Index hält, jedes Programm, das diese Info braucht entweder selber sucht oder "den Teil des Systems abfragt, der davon weiss", ergo das GUI.
Nein. Die GUI soll ja eben nicht bei jedem Start die Disks durchsuchen.
Wenn sie selber einen persistenten Index hält, ok, wenn sie in nur volatil hält, müsste sie bei einem Neustart wieder nachschauen. Natürlich kann jedes GUI seinen Index/Cache führen, fänds nur platzsparender, wenn das zentral passieren würde und andere Programme darauf Zugriff hätten.
Abgesehen davon frage ich mich, wieso man überhaupt verschiedene GUIs einsetzen möchte? Wenn einem die Standard-GUI nicht gefällt, wird man die, so wie etwa beim GP2X auch, eventuell gegen eine andere GUI austauschen.
Logo, ist natürlich eine Randbedingung. Bestenfalls beim Evaluieren der GUIs würde man selten mal zwischen solchen Umschalten. Sollte mehr heissen "wenn der Index vom System angeboten werden würde, könnte jedes GUI(andere Apps) darauf zugreifen". Aber ja, der Use-case ist mehr übertriebene Erbsenzählerei.
Ich bezweifel, dass der ganze Suchvorgang überhaupt zu so einem großen Problem wird, wie hier behauptet. Ich denke, die meisten Benutzer werden nicht permanent neue Programme installieren. Hin und wieder sicherlich, aber das Installieren dürfte nicht der Haupteinsatzzweck der Pandora sein, sondern das Nutzen von Programmen und so lange sich nichts ändert muss auch gar nicht erneut nach Programmen gesucht werden.
Logo, der häufigste Fall ist natürlich das "Umstecken" von Karten. Und hier muss nur der (von wem auch immer produzierte) Index/Cache einer GUI/App mit der Kartennummer assoziiert werden (bzw. der Index wird auf die Karte direkt draufgeschrieben) und nicht gleich gedrobt werden, sobald mal eine andere Karte reinkommt. Wenn das funktioniert ist eine meiner Hauptsorgen für "potentiell nervendes Verhalten" schon weg. Aber meine andere Hauptsorge ist, dass man bei einem zentralen Index einfacher Apps erstellen kann, die "installierte" Apps referenzieren wollen und nicht jede App schreibt ihren Index/Cache auf jeder Karte, die sie findet. z.B. stecke ich meine Karte in eine Pandora beim Kollegen ein, der ein anderes GUI nutzt. Dieses erstellt daher einen eigenen Index/Cache und schreibt ihn auf meine Karte. Ich stecke diese wieder bei mir ein, mein GUI findet seinen Cache/Index wieder und macht nix, hab aber sinnloserweise die Cache/Index-Datei vom anderen GUI als Restmüll drauf.
...für die es sich deswegen erst recht nicht lohnt einen Dienst laufen zu lassen (egal wie groß oder klein) - jeder Start eines Dienstes verzögert schließlich den Bootvorgang. Die Bootdauer schätze ich als wesentlich kritischer ein, als den Vorgang des Suchens nach neuen Programmen.
Dies wurde schon früher oft diskutiert: Die Bootzeit spielt bei der Pandora keine Rolle, sie ist so konzipiert, dass sie sich immer wieder schlafenlegt und nicht runtergefahren werden muss. Das macht meine obige Aussage wegen GUI-Starts noch unbedeutender, da dieses dann auch fast nie neu startet.
Ich stelle mir das ganze mehr als Erweiterung im Betriebssystem-API, also evtl Teil des Kernels im User-Space vor (Da ich den Teil von Linux nicht so genau kenne, kann die Aussage auch etwas daneben liegen). Die Apps würden nur einen Systemaufruf machen falls nötig, anstatt, dass ein Demon dafür laufen müsste. Letzteres wäre für so eine kleine Aufgabe Overkill. Geschweige denn eine Deluxe Lösung, wo dieser auch noch INotify nutzen würde um auch jede Verschiebung/Löschvorgang einer PXML Datei mitzuverfolgen und real-time den Index upzudaten...
Was die anderen Verwendungsmöglichkeiten angeht, hast Du zwar einige Sachen aufgezählt, aber wirklich überzeugt, hat mich nichts davon.
Die PXML-Dateien sind in erster Linie dafür gedacht, dass eine GUI sich die "installierten" Programme zusammensuchen und sinnvoll in Kategorien einordnen kann. Man braucht aber, gerade weil man ja nicht wirklich installieren muss, kein System-Programm, dass einem die "installierten" Programme anzeigt - Programme, die man nicht mehr haben möchte, löscht man einfach von der SD-Karte. Fertig.
Zumindest die "Wecker-App", oder generischer "das Referenzieren/Aufrufen anderer Apps aus einer App heraus" sehe ich immer noch als wichtigen Use-case und dass eine App in Paketen "installiert" werden kann. Gut letzteres kann oft (aber nicht immer) auch mit der Bedingung "Die Pakete müssen im selber Folder liegen" abgehandelt werden. z.B. würde man für Doom weitere WADs im selben Verzeichnis wie das Programm selber entpacken.
... Programme, die man ohnehin nur von der Shell aus starten kann, gar nicht von PXML profitieren, weil eine Einordnung in Kategorien und Integration in die GUI sinnlos ist.
Mein Beispiel war missverständlich, die PXML Datei steht dabei nicht im Vordergrund, sie hat in dem Kontext nur den Sinn eines "Markers", der angibt wo überall Apps sind (aber auch das zugehörige executable angibt). Wirklich wichtig ist der zentrale Index. Das KommandozeilenStarterApp würde den Index nutzen um das zu startende App zu lokalisieren und das PXML auslesen um die Executable zu finden.
Wer tatsächlich seine installierten Spiele und Programme von der Shell aus starten möchte, wird sich vermutlich Symlinks ins bin-Verzeichnis packen können, um die Programme ausführen zu können, wobei selbst das ja relativ wenig Sinn macht.
... Solche Programme wird man ohnehin im Pfad haben.
Symlinks reicht nicht, die Apps werden ja jeweils mit dem "Installationsverzeichnis" als working directory gestartet. Und im Pfad sind sie schon gar nicht, denn wir reden ja gerade von den Apps, die nur per PXML "installiert" wurden. Und es geht nicht um einfache "Kommanzeilenwerkzeugen", die würde ich schon eher in ein Verzeichnis legen und dieses im PATH ergänzen. Mir gehts wirklich um die Gesamtheit aller dieser Apps, denn bei einer Auflösung von 800x480 werden die meisten von Ihnen sowieso im Fullscreen (per Framebuffer?) laufen und einige von Ihnen grad noch die GUI abschiessen. Wozu soll ich die dann noch starten?

Klar im Normalfall wird die GUI laufen, und ich kämpf nicht drum die Pandora auf der Kommandozeile zu bedienen (auch wenns mir nicht unsympathisch ist, denn ich möchte sie v.a. als Handheld für unterwegs nutzen und das Retro-Gamen ist ein fetter Pluspunkt). Sondern einfach nur um die Aussage: Wenn es einen zentralen vom System angebotenen Index hätte, könnte auch der Zugriff für alle anderen Apps viel einfacher ablaufen und (auch) sehr einfach per Kommandozeile. Ein AppLauncher wäre superschnell geschrieben und wenn ich mal schnell alle PXMLs auf der Disks nach etwas greppen möchte, kann ich das mit dem Index beschleunigen. Noch einfacher ausgedrückt: Systemeigener Index für alle --> Kein Nachteil für GUIs, aber einfachere Erstellung von Tools und Apps, die dies nutzen können.
Bei einem "normalen" Linuxsystem ist der Zugriff auf Informationen im installierten System einfacher, ich hab die Quellen für die Informationen immer irgendwo "gebündelt" (auf ein oder wenige Verzeichnisse). Während auf der Pandora die Infos über die installierte Software auf ein ganzes Medium verstreut ist. Jeder Zugriff erfordert zuerst ein "Zusammensuchen" der Infos. Ich kann auch kein Softwarepaket "referenzieren", weil der Pfad nicht stabil ist. Mit einer Referenzierung einer UUID ist das einfacher und jedes Programm, dass so eine Referenzierung auflösen muss ist froh um einen Index.
Ich behaupte auch weiter, dass eine Implementation möglich ist, bei der die GUIs dieselben Möglichkeiten haben (Zugriff schon während dem Scan) und das ganze als Betriebssystem-API Erweiterung sogar bessere Kontrollmöglichkeiten zum Verhalten hergibt (Veto, jede API, die Suchen möchte wird so aufgehalten). Und wenn du (und auch ED) argumentierst, dass sowieso selten gescannt wird und dies schnell gehen wird, wäre sogar (vorderhand für den ersten Release) eine Suche die erst am Schluss einen Zugriff auf die Ergebnisse ermöglicht ok, was die Implementation gar massiv vereinfacht (was ich natürlich nicht präferiere).
 
Nach all dem Lobbying fuer einen zentralen Index pro (Wechsel)Medium und guten Einwaenden von wejp, werd ich meine "Forderungen" in Stufen definieren, so dass man sich irgendwo dazwischen einigen kann:
  • PXML mit UUIDs erweitern
  • Format, Name, Pfad (/ jedes Wechselmediums) festgelegt fuer die Indexdateien (UUID, Pfad pro gefundener App, die eine PXML definiert). Jede Index-erstellende/managende Software nutzt diese!
  • Zentralisierung der Indiceserstellung/verwaltung im Bestriebssystem mit API (s.u.)
Punkt 1 dürften wohl die meisten zustimmen.
Punkt 2 erfordert nur eine "Festlegung", dann kann auch das jeweils laufende GUI die Indices nach Gutduenken (bzw. User-Einstellung) erstellen/uptodate. So dass zumindest alle anderen Programme wuessten wo sie Indices finden und das Format gesichert ist. Ob Jedes GUI noch seinen eigenen Cache zusaetzlich zu den Indices faehrt ist unabhaengig davon.
Damit kann jemand immer noch eine LIb zum erstellen/managen der Indices bauen, die GUIs je nach Gutduenken einbauen koennen und wer moechte kann zusaetzlich ein dediziertes Tool bauen um Indices zu erstellen (falls man nicht extra die GUI dafuer starten moechte). Und jeder der einen Index in seiner App abfragen moechte kann dies unabhaengig von der eingesetzten GUI tun, kriegt zwar kein Notify bei Aenderungen, aber die Indices sind schon ein grosses Plus. Die zugreifenden Programme selber müssen trotzdem die Logik duplizieren wo die einzelnen Indices (pro Wechselmedium) zu finden sind. Und hoffentlich wird keines so schlecht implementiert sein, dass es das NAND abnutzt durch sinnloses Erstellen eines leeren Index auf diesem :twisted:
Mit Punkt 3 wär das ganze dann einfacher für alle nutzenden Apps und die GUIs würden den Code nicht duplizieren

Formatvorschlag (entspricht dem \etc\password):
<UUID>:<Path>
Falls jemand noch weitere Ideen fuer Felder hat, einfach jeweils mit : getrennte Eintraege. Das ist dann fuer sed/perl traumhaft einfach zu verarbeiten.. Die Erweiterungen aber bitte vor dem Release den genauen Inhalt festlegen, nicht das jedes GUI dann etwas nach Belieben anhängt, sonst werden sich einzelne GUIs gegenseitig die "erweiterten Daten" löschen...

Was das Indexgenerator API enthalten könnte:
  • isIndexAvailable(device) ohne device-Angabe wird angegeben obs für alle verfügbar ist
  • forceIndexGen(device) ohne device-Angabe alle
  • startApp(UUID)
  • getAppPath(UUID)
  • etwas um eine Liste der Apps/UUIDs/Indexeinträge und/oder Locations der Indices (da mehrere Wechselmedien) zu erhalten
  • getIndex(UpdateHandler) mit dem UpdateHandler kann man jeden neu "gefundenen" Eintrag schon während der Suche kriegen. Falls kein neuer Scan nötig, gibts alles sofort
  • forceIndexGen(device,UpdateHandler) ohne device-Angabe alle, den UpdateHandler um schon während des Suchen Resultate zu erhalten
  • setIndexGenUpdate(Policies) entspricht dem Setzen der Optionen wann gescannt werden darf.
  • setIndexGenVeto(sourceApp) i.A. ist der Parameter "this" bzw. ohne Param, falls das aufgerufene API den "caller" selber rausfinden kann. Nur wenn keine Vetos vorliegen bzw. alle Apps, die noch Vetos hatten beendet sind, darf wieder gescannt werden.
  • releaseIndexGenVeto(sourceApp)
Die Namen sind nur zum Verständnis, würden natürlich um ein Prefix erweitert für Pandoraspezifisch und können wie auch immer heissen. Genauso ist auch die Liste nicht unbedingt vollständig.

Wenn wir uns auf Punkt 1 und 2 einigen können, bin ich schon happy. Und das erfordert keine/kaum Extraarbeit für das Pandorateam! Punkt 3 ist schon abgehoben und wär nice to have. Dafür läuft dann aber nicht mehr jede Pandorasoft ohne Anpassungen auf allen Linux-Arm-Distributionen weil es Pandora-spezifische Calls hätte.

Heute trag ich Schwarz :ph34r: , denn die p&|a müsste heute released werden, wird aber (noch) nicht :(
 
Ich habe gerade nicht so viel Zeit, deswegen nur kurz etwas dazu.
PandoraSuechtig said:
Hmm, gute Riposte, das Sparring gefällt mir :)
:D
PandoraSuechtig said:
[*]Format, Name, Pfad (/ jedes Wechselmediums) festgelegt fuer die Indexdateien (UUID, Pfad pro gefundener App, die eine PXML definiert). Jede Index-erstellende/managende Software nutzt diese!
So eine Lösung wäre als Kompromiss ja gar nicht so übel. Aplikationen, die einen Index verwenden möchten, können so auf einen eventuell schon bestehenden Index zugreifen und falls nicht vorhanden, selbst einen erstellen. Falls kein Programm einen Index benutzen möchte, passiert einfach nichts. Es würde also einfach auf einen Quasi-Standard für die Index-Dateien hinauslaufen. Insbesondere wenn das Dateiformat einfach aufgebaut ist (etwa so wie vorgeschlagen), könnte das durchaus auf Akzeptanz stoßen, falls halt überhaupt solch ein Index von anderen Anwendungen verwendet wird.
 
... und falls nicht vorhanden, selbst einen erstellen.
Autsch. Hoffe nicht jeder wird so was hacken. Lieber soll einer ein kleines tool bauen (von mir aus im /usr/bin gleich mitgeliefert) um die Indices zu erstellen. Eines genuegt ja. Und egal obs das System oder die GUIs erstellen, es wird ziemlich sicher immer ein Index vorhanden sein.
falls halt überhaupt solch ein Index von anderen Anwendungen verwendet wird.
hehe, einen musstest du mir noch reindruecken, he? :D
 
PandoraSuechtig said:
... und falls nicht vorhanden, selbst einen erstellen.
Autsch. Hoffe nicht jeder wird so was hacken. Lieber soll einer ein kleines tool bauen (von mir aus im /usr/bin gleich mitgeliefert) um die Indices zu erstellen. Eines genuegt ja. Und egal obs das System oder die GUIs erstellen, es wird ziemlich sicher immer ein Index vorhanden sein.
So geht es natürlich auch. Wobei es ja das hacken jetzt so klingt, als ob alle das ganz grausam implementieren würden. Es wird aber eben nicht immer ein Index vorhanden sein. Wenn eine neue unbekanne Karte eingelegt wird, fehlt der Index ja. Irgend wer muss den dann erstellen - von mir aus auch durch ein (mitgeliefertes) Skript.
falls halt überhaupt solch ein Index von anderen Anwendungen verwendet wird.
hehe, einen musstest du mir noch reindruecken, he? :D
Na klar. :p Wobei das eigentlich so gar nicht gemeint war. Viel mehr meinte ich, dass (abgesehen von der GUI) erstmal Programme entwickelt werden müssen, die von so einem Index überhaupt einen Nutzen ziehen würden. Bis da hin bleibt das halt ein eher theoretisches Problem.
 
Wobei es ja das hacken jetzt so klingt, als ob alle das ganz grausam implementieren würden.
gemeint war die urspruengliche bedeutung von hacker, wie zu zeiten des homebrew computer club. also positiv.
Es wird aber eben nicht immer ein Index vorhanden sein. Wenn eine neue unbekanne Karte eingelegt wird, fehlt der Index ja. Irgend wer muss den dann erstellen - von mir aus auch durch ein (mitgeliefertes) Skript.
jou, skript find ich ok, und wenn das GUI den Index erstellt, dann denk ich immer noch wirds praktisch immer einen geben.
(abgesehen von der GUI) erstmal Programme entwickelt werden müssen, die von so einem Index überhaupt einen Nutzen ziehen würden. Bis da hin bleibt das halt ein eher theoretisches Problem.
Hehe, und wieder eins reingedrueckt... Die ganze Diskussion ist theoretisch, denn die Implementation steht noch aus. Es ist wie bei vielen Dingen, die in BSD, Linux usw. gehackt wurde: Zuerst hat man sich ueberlegt was nuetzlich waere, hatt es implementiert und dann nutzten es die Programme, weil es schon da war. Klar, manchmal wurde erst durch die Implementation derselben Funktionalitaet in verschiedenen Programmen klar, dass eine zentrale Implementation Sinn macht. Ich versuche nur dieser Situation vorzugreifen, dass dann viele proprietaere Varianten bestehen. Wenn der Index besteht, wird er auch Anreiz bieten ihn zu nutzen, statt proprietaer zu werden... Ein wunderbares Gegenbeispiel ist der M$ crap. Zuerst was unbrauchbares Eigenes gebastelt und dann langsam die Konzepte von Unix Stueck fuer Stueck doch kopiert. Mein Lieblinsbeispiel ist das /home Verzeichnis. Nun findet man Windows Software, die ihre Konfiguration im Windowsverzeichnis, in der Registry, ins Installationsverzeichnis oder in das "/home" Verzeichnis des Users ablegt. Totales Chaos. Lustig, wenn man die Konfiguration einen App aendern moechte, die ihre Einstellungen im Installationsverzeichnis fuehrt und der User nicht mal Schreibrechte drauf hat :lol:
Konzepte erst mit der Erfahrung einzubringen, fuehrt zwangslaeufig zum Chaos... Bin mir ziemlich sicher mit dem Index so manchen unnoetigen Code vermeiden zu koennen. Und wenn doch nicht, hats niemand geschadet :wink:
 
Noch paar Gedanken zum Format:

UUID:<relativer Pfad PXML>:<relativer Pfad exe>:<relativer Pfad Ausfuehrungsverzeichnis>

Bsp:

550e8400-e29b-11d4-a716-446655440000:pandoraProgs/doom:pandoraProgs/doom/doom:pandoraProgs/doom

Die Idee dahinter ist, dass wenn nur die ersten beiden Felder gegeben waeren, nur bekannt waer, wo das PXML zu finden ist, dann ist noch ein Parsing noetig, um weitere Infos zu kriegen. Mit dieser Aenderung kann ich z.B. ein Program starten, wenn ich seine UUID kenne, ohne das PXML anzufassen. Vielleicht kann man noch weitere Infos aus den PXML in den Index einpflegen. Titel geht leider nicht, da ein : darin vorkommen kann und wird.

Nun wuerd ich ein starterapp hacken, ein Alias-File (alias:UUID) dazu und los gehts mit Kommandozeilenbedienung :D :D :D
Bis auf den Haken, dass ich die Wechselmedien immer noch selber finden muss...
 
Wird das hier der "wer schreibt am meißten in einen Post- Contest" :lol:
Ich nehme an, die ganzen Überlegungn hier sind obsolet, solange ED sich nicht detailliert dazu äußert. Mir als Laie ist das eigentlich alles egal, hauptsache das verwalten von Programmen auf der Pandora wird übersichtlich, einfach und effizient. :)
 
Wären wir hier im heise forum wäre ich ja gewöhnt, dass hier Trolle rumlungern, die keine sinnvolle Beiträge schreiben... Sich als Laie zu deklarieren ist die Qualifikation Diskussionen als obsolet zu bezeichnen???? Auch die Wortwahl selber ist falsch, obsolet bedingt, dass es vorher von Bedeutung war. Aber bitte immer schön mit "Fremdwörtern" imprägnieren :lol:

Wenn dies wirklich "obsolet" (oder genauer "überflüssig") ist, bis sich wieder einer der Entwickler dazu äussert, können wir auch gleich das ganze Forum schliessen und ein Newsboard einrichten. Die Idee des Forums ist ja das Besprechen von Ideen und Präferenzen, die die Entwickler aufschnappen können. Und wenn man vorher sein Hirn benmüht, um sich Gedanken zu potentiellen Schwierigkeiten zu machen, kann man Folgeprobleme im Endprodukt vermeiden.
Mir als Laie ist das eigentlich alles egal, hauptsache das verwalten von Programmen auf der Pandora wird übersichtlich, einfach und effizient.
Diese Einstellung passt mehr zu den iPhone Konsumenten, Betonung auf "Konsumenten". Ich bin lieber am Produkt beteiligt, bringe konstruktive Beiträge und versuche mitzuhelfen, dass auch wirklich nichts übersehen wird.

Warum meine harsche Wortwahl? (Bin ich damit knapp an der Board Netiquette vorbeigeschrammt?)
Weil ich schon bei genug Softwareprojekten dabei war, wo Leute sich nicht die Mühe gemacht haben Entwürfe durchzudenken. Und ich spielte schon einige male die Cassandra, die dann zwar Recht behielt, aber man hat nicht viel davon, wenn das Produkt dann schon ausgeliefert ist. Meist wurden meine Argumente genau mit solchen gehaltlosen, bestenfalls grammatikalisch korrekten "Einwänden" "entkräftet".
 
Boah Jungs :)
Ich finde eure Unterhaltung sehr interessant, auch wenn ich als Laie kein Wort verstehe :), außerdem halte ich es sogar für sehr sehr wichtig sich mit Dingen auseinander zusetzen die Später dann das Arbeiten/Spielen erleichtern. Von daher kann ich schon auch verstehen das du es gelinde gesagt "doof" findest das einer der, selber gesagt, keine Ahnung davon hat meint er müsse eure Diskussion als unnütz abstempeln.
Nur ihn gleich als Troll darzustellen...

So und nun macht weiter und bitte ohne solche verbalen Tiefschläge.

:)
 
Bin schon paar Runden im Sparring mit wejb :ph34r: , wer sich da in den Ring traut muss sich auf Seitenhiebe einstellen :wink:
Solche Grundsätzliche Diskussionen über das Design sind teilweise auch schon Glaubensfragen und da gibts hitzige Gefechte... Und wer mitgelesen und verstanden hat, hat meinen "para-religösen" Eifer für die Index-Geschichte miterlebt :wacko: während wejb und (immer noch?) DE eher anders denken. Aber wenn die Kompromisslösung durchkommt, hat sich (m)ein blaues Auge gelohnt ^_^
 
Eigentlich hab ich auch geschrieben, dass es nur solange obsolet ist, bis sich ein Dev äußert...und nicht, dass der Thread allgemin überflüssig ist. ;) Das hat nix mit Trollen zu tun.
Und die "Standpauke" finde ich ehrlich gesagt ziemlich lustig. :D Ich selber hab nämlich schon seit das Pandora-Projekt öffentlich bekannt wurde ebenfalls Überlegungen in Threads geschrieben, Vorschläge gemacht und so weiter. Wie einige Andere User auch hab ich mir schon ernsthafte Gedanken über die Pandora gemacht, als es noch nicht mal diesen Namen gab und als du vermutlich noch nix von dem Projekt gehört hattest. Wir haben Tonnen an Ideen ausgeworfen, ich selbst habe auch etliche Bilder und Renderings zur Hardware gemacht und hier und da Verbesserungsvorschläge empfohlen, bin auf Details eingegangen und habe wie Du einfach meine Gedanken dargelegt. Dass es z.B. Lieferprobleme mit LCD's geben könnte hab ich glaube auch schon vor Monaten orakelt.
Am Ende aber sind es nach wie vor die Devs, die entscheiden, was sie von den Vorschlägen umsetzen. Da kannst du noch so viel schreiben, glaub mir. ;)
PandoraSuechtig said:
Mir als Laie ist das eigentlich alles egal, hauptsache das verwalten von Programmen auf der Pandora wird übersichtlich, einfach und effizient.
Diese Einstellung passt mehr zu den iPhone Konsumenten, Betonung auf "Konsumenten". Ich bin lieber am Produkt beteiligt, bringe konstruktive Beiträge und versuche mitzuhelfen, dass auch wirklich nichts übersehen wird.
Eben, genau wie ich. Selbst wenn es nur irgend ein kleiner Hinweis ist, viellleicht bringt er die Devs doch noch auf Ideen oder man spricht etwas an, das die Devs noch nicht bedacht hatten. (Ich hatte z.B. mal einiges zum Thema Tastatur-Tasten-Bedruckung "gebrainstormt" :D )
....doch nur weil man etwas einfach möchte, muss man doch nicht gleich als Ei-Fön Konsument abgestempelt werden. ;) Mal davon abgesehn, dass ich Apple hasse wie die Pest ist es doch gerad der Hauptgedanke an dem Pandora PXML Format, alles so einfach und übersichtlich für den User zu gestalten wie nur möglich. Da gabs ja auf dem GP2X noch einige Defizite in der Vergangenheit, drum hat ED sich ja das PXML Format für die Pandora ausgedacht.
 
Back
Top