PND-GUI: Softwareverwaltung für die Pandora

[Thott Chief]

Für die Verstecken Funktion würde ich mir wünschen dieses nicht auf Dateisystem-Attributen basierend zu lösen. Ein Verschieben in einen Backup Verzeichnis wäre einfacher zu handhaben wenn die SD mal an einem anderen Lesegerät sein sollte.

Also wie du schon sagst, ich habe mir sowieso von Anfang an gedacht das ganze mithilfe von Verschieben zu realisieren.

- mehrere Repositories über getrennte Index-Dateien verwalten. Man könnte sich hier an APT halten.
- Könnte man die Ziele nicht unabhängig definieren. Quasi wie die Quicklinks von Nautilus? D. h. du bräuchtest in der Software nur die Quicklinks unterstützen und jut, somit könnte man unabhängig von deiner Software neue Install-Targets definieren und dir spart es eine Menge Programmierarbeit

Zu Erstens, Ich verstehe nicht genau was du mit Ziele meinst, sofern du mit Ziele Quellen zum Apps beziehen meinst, dann gibt es einen einfachen Grund wiso ich nicht unbedingt einfach nur die Website anzeigen möchte. Sie ist einfach zu breit, zwar ist sie auf einen vollen Pandorabildschirm zugeschnitten, aber man bedenke das links noch die Sidebar zu sehen ist, sodass man die Hälfte der Seite zu sehen bekommt. Außerdem lassen sich beim Übersetzen der Seite zur Qt-Oberfläche schöne Animationen einbauen :-D

Wie wär es gleich mit einer ROM Verwaltung für Emulatoren?

Es wäre ein Ziel, aber ein hochgestecktes Ziel, denn dann müsste man für jeden Emulator ein Profil erstellen, das angibt wie die ROMs zu handeln sind, sprich muss ich "emulator -i rom.rom" schreiben oder "emulator rom.rom" etc.
Wäre dennoch eine Idee.
(Genauso komplex bei Interpreter und Co.

Zu ashclowds Vorschlag:
Guter Vorschlag, werde ich mir auf jeden Fall vormerken und dann darauf zurückkommen.

Wie wärs denn mit einer Art Baumstruktur, z.B. gerade für Emulatoren

Auch dazu, gute Idee wenn es bis dahin nicht komplette Umstrukturierung gibt.


Insgesamt lässt sich sagen, dass hier viele Ideen zwar ziemlich gut sind, aber eigentlich grundlegende Änderungen am Standart der PXML Dateien vorraussetzen würden.
Ich kann nur sagen das sich die Infos eigentlich außschließlich in der PND-Datei befinden dürfen, denn sonst müsste man wieder ein extra Repository anlegen um die Zusatzinfos irgendwo zu speichern.


P.S. Ist in Python gecoded(Qt4) wird vielleicht später noch in C/C++ umgeschrieben


Thott

 

[Joker]

P.S. Ist in Python gecoded(Qt4) wird vielleicht später noch in C/C++ umgeschrieben

sowas in Qt umzusetzen habe ich mir auch überlegt, bloß ist meines Wissens auf der Pandora nicht standartgemäßt qt4 installiert. Die meisten überfordert es allerdings, wenn sie noch in der Konsole "install opkg install qt4" eingeben müssen.

 

[Granitehead]

P.S. Ist in Python gecoded(Qt4) wird vielleicht später noch in C/C++ umgeschrieben

sowas in Qt umzusetzen habe ich mir auch überlegt, bloß ist meines Wissens auf der Pandora nicht standartgemäßt qt4 installiert. Die meisten überfordert es allerdings, wenn sie noch in der Konsole "install opkg install qt4" eingeben müssen.

Dann macht man das halt in einen Hotfix. Das kann ED ja machen.

 

[CME]

P.S. Ist in Python gecoded(Qt4) wird vielleicht später noch in C/C++ umgeschrieben

sowas in Qt umzusetzen habe ich mir auch überlegt, bloß ist meines Wissens auf der Pandora nicht standartgemäßt qt4 installiert. Die meisten überfordert es allerdings, wenn sie noch in der Konsole "install opkg install qt4" eingeben müssen.

dann stopf die libs mit in die pnd

 

[Joker]

P.S. Ist in Python gecoded(Qt4) wird vielleicht später noch in C/C++ umgeschrieben

sowas in Qt umzusetzen habe ich mir auch überlegt, bloß ist meines Wissens auf der Pandora nicht standartgemäßt qt4 installiert. Die meisten überfordert es allerdings, wenn sie noch in der Konsole "install opkg install qt4" eingeben müssen.

dann stopf die libs mit in die pnd

jetzt macht das eh schon ein anderer also muss ich mir dafür auch keine Gedanken machen.
Helfen kann ich da auch nicht, da ich keine python kenntnisse habe außer er schreibt es gleich in C++ um.

 

[xyta]

Insgesamt lässt sich sagen, dass hier viele Ideen zwar ziemlich gut sind, aber eigentlich grundlegende Änderungen am Standart der PXML Dateien vorraussetzen würden.
Ich kann nur sagen das sich die Infos eigentlich außschließlich in der PND-Datei befinden dürfen, denn sonst müsste man wieder ein extra Repository anlegen um die Zusatzinfos irgendwo zu speichern.

Hm, ich dachte PXML wäre XML, und da könnte man beliebig Verzweigungen ind den Baum einbauen, aber bleibt abwärtskompatibel, solange man die Standardverzweigungen drin lässt! ??

Wird anscheinend Zeit für ein PXML 2.0, um ROMs und Savegames besser mitnehmen zu können.

 

[double7]

Insgesamt lässt sich sagen, dass hier viele Ideen zwar ziemlich gut sind, aber eigentlich grundlegende Änderungen am Standart der PXML Dateien vorraussetzen würden.
Ich kann nur sagen das sich die Infos eigentlich außschließlich in der PND-Datei befinden dürfen, denn sonst müsste man wieder ein extra Repository anlegen um die Zusatzinfos irgendwo zu speichern.

Du könntest gleich die von ED erwähnten PXML Overrides, die OVR Dateien, mitliefern.

Was rede ich? Wieso mitliefern? Du könntest sie automatisch erzeugen lassen. Neues PND gefunden? Gibt es schon ein OVR? Nein: Ein OVR mit den Standardvorgaben für diese Pandora erstellen. Ja: Pfade überprüfen und ggf. korrigieren.

 

[Thott Chief]

Also, wenn XML tatsächlich so funktioniert, dann wäre es kein Problem die zusätzlichen Infos in die PND zu packen. Wenn ich mir aber die aktuelle "Ausführlichkeit" der PNDs anschaue, dann muss man sich schon ein bisschen an den Kopf fassen. Mehr als Titel und 1-Satz-Beschreibung lassen sich aus den meisten PXMLs nicht auslesen. Die Überlegung wäre tatsächlich ein eigenes Repositorys für die Overlays anzulegen.(kurzer Einwurf, wer zahlt Server, wer verwaltet/aktualisiert). Zu dem Qt4-Problem, soweit ich weis liegt Minitube als PND vor und nutzt Qt4.
Zu der C++ Sache, mir ist Python eben so lieb, da ich hier meine Ideen schnell verwirklichen kann, und außerdem ein quarrst großes Repetoire an Module zur Verfügung stehen habe.

 

[RMfast]

Sowas bräuchte man auch für Emulatoren (PND-GUI: Emulatorenverwaltung)

Ich meinte das von mir auf Seite 1 geschriebene als Scherz, nicht das Thott Chief noch in Teufels Küche kommt, wen ROM`s und Isos von Shareing-Seiten automatisch auf die Pandora geladen werden und verwaltet werden.

Hört sich hier allmählich so an :nope:

 

[Christoph.Krn]

Insgesamt lässt sich sagen, dass hier viele Ideen zwar ziemlich gut sind, aber eigentlich grundlegende Änderungen am Standart der PXML Dateien vorraussetzen würden.
Ich kann nur sagen das sich die Infos eigentlich außschließlich in der PND-Datei befinden dürfen, denn sonst müsste man wieder ein extra Repository anlegen um die Zusatzinfos irgendwo zu speichern.

Du könntest gleich die von ED erwähnten PXML Overrides, die OVR Dateien, mitliefern.

Was rede ich? Wieso mitliefern? Du könntest sie automatisch erzeugen lassen. Neues PND gefunden? Gibt es schon ein OVR? Nein: Ein OVR mit den Standardvorgaben für diese Pandora erstellen. Ja: Pfade überprüfen und ggf. korrigieren.

Entspricht es der Wahrheit, dass OVR-Dateien laut Spezifikation beliebige zusätzliche Datenfelder enthalten dürfen, welche in eine PXML-Datei nicht aufgenommen werden dürfen da diese ausschließlich die spezifizierten Elemente enthalten darf? Ansonsten sind OVR-Dateien ja keine Lösung des Problems. Eine Unschöne sind sie in jedem Fall, da OVR-Dateien ja eigentlich einen ganz anderen Zweck erfüllen sollen. Oder meinen wir beide hier gerade zwei unterschiedliche Dinge?

Ansonsten könnte man sich eher zunutze machen, dass die PXML.xml ja lediglich EINE von vielen möglichen Dateien innerhalb von PND-Dateien darstellt. In sofern könnte man ashclouwds meiner Meinung nach hervorragende Idee der Verwaltungsskripte derart realisieren, indem man hierfür eine PXML-ähnliche Spezifikation kreiert. Diese könnte dann später - sofern sinnvoll - immer noch in die ja nicht finale PXML-Szezifikation übernommen werden.

Falls ich Stuss erzählt habe so korrigiert mich bitte, ich hab mich noch nicht vollständig mit dem PND-System beschäftigt.

---------------------------------------------------------------------------

Es gibt auf der Pandora bei herkömmlichen Paketverwaltungen noch ein weiteres Problem: die Pandora ist zu großem Teil ein Gerät, mit dem man Spiele spielt, d.h. der Anteil an erhältlichen Spielen ist relativ groß. Herkömmliche Paketverwaltungen sind allerdings nicht gut dafür geeignet, über sie in verfügbaren Spielen zu stöbern. Ich möchte dies verdeutlichen anhand eines Paketverwalters den ich letztes Jahr konzipiert habe:

Wer sich schon einmal in einem herkömmlichen Paketmanager (oder sogar Ubuntus "Software Center") nach potenziell interessanten Spielen umgesehen hat wird wissen, was ich meine. Ein paar wenige Bilder sind da noch das höchste der Gefühle. Dazu bekommt man dann eine Beschreibung, die einem zwar genau sagt, dass das Spiel in 3D ist oder auch welche Arten von Einheiten man zur Verfügung hat, aber das alles hilft nicht dabei, das Spiel kennenzulernen wenn man es noch nicht kennt. Dazu muss man es entweder herunterladen und ausprobieren, für später im Hinterkopf behalten (um nicht den aktuellen "Stöbervorgang" zu unterbrechen, siehe auch das hier bereits angesprochene "Vormerken") oder aber z.B. die Internetseite zum Projekt aufrufen.

Mit anderen Worten:

• Installieren, Deinstallieren und Verwalten: ja.
• Umherstöbern und neue Spiele entdecken: vergiss es lieber.

Entspanntes Stöbern in der Spielebibliothek ist so zwar theoretisch möglich, bringt einem aber so ziemlich gar keine für die Situation sinnvolle Information. Als Gegenmaßnahme kann man eine Neuerfindung der Benutzeroberfläche und Verwendungsmuster vornehmen. Videos, viele Bilder, Bewertungsfunktion. Also in etwa so wie die WWW-basierte Lösung der Pandora momentan, nur dass diese noch zu viel Interaktion für zu wenig Nutzen, sowie teilweise Geduld in Form von Wartezeit erfordert. Besser wäre eine native Anwendung die flott reagiert und so entworfen ist, dass es sich während des Stöberns anfühlt als lägen die ganzen Bilder, Videos etc. von Anfang an auf der Pandora.

Meiner Meinung nach sollte man das bei diesem Projekt bedenken. Zumindest eine zweistellige Anzahl an Screenshots pro Spiel wäre eine gute Sache (dass die Realisierung nicht unbedingt trivial ist weiß ich wohl).

 

[Granitehead]

+1


Das mit den Bildern (und Videos) ist so, da nütze ich dann meist noch am ehesten Playdeb, wenn ich ein neues Spiel suche, aber mit Synaptic ist das eigentlich nicht möglich.

 

[Thott Chief]

Sehr intessante und vorallem inovative Idee, etwas ähnliches wäre sogar umsetzbar, ich kann nachher mal eine Idee von mir als Mockup umsetzen.

 

[Gurumeditation]

Ja das ist wirklioch eine schöne idee. Vorallem wäre das angepasst an den Touchscreen.

 

[Thott Chief]

Wobei man auch irgendwie eine Möglichkeit einbauen sollte das nur mit Dpad und Co zu steuern, das man nicht gezwungen ist den Screen zu nutzen.

 

[xyta]

Entspricht es der Wahrheit, dass OVR-Dateien laut Spezifikation beliebige zusätzliche Datenfelder enthalten dürfen, welche in eine PXML-Datei nicht aufgenommen werden dürfen da diese ausschließlich die spezifizierten Elemente enthalten darf?

Dann wäre es aber kein richtiges XML. Normalerweise kannst du beliebige Äste in den Baum hinzufügen. Der Interpreter greift einfach nur auf die Elemente zu die er kennt. Die er nicht kennt, fragt er einfach nicht ab, was aber nicht heisst dass es sie nicht geben darf!
Sollte es beim Zufügen von Elementen wirklich zu Abstüzen kommen, würde ich mich fragen, wer den Interpreter verbrochen hat, da sowas mit 0815-XML-Bibliotheken (z.B. bei Freepascal) normalerweise reibungslos funktioniert.

Videos, viele Bilder, Bewertungsfunktion.

Videos und viele Bilder bekommst du theoretisch mit animierten GIFs hin...

Ansonsten wäre es womöglich eine Idee, auch Gnash zu supporten....

Bewertungsfunktion wäre auch gut.

 

[fusion_power]

Mit anderen Worten:

• Installieren, Deinstallieren und Verwalten: ja.
• Umherstöbern und neue Spiele entdecken: vergiss es lieber.

Ich lese mir immer gern vorher Infos zu Games durch, sowas hab ich bei der Pandora (mal wieder) vorrausgesetzt dass das geht, währe ja doof, wenn man erst alles installieren muss um sich ein Bild vom Programm zu machen.
Dafür haben die Archive ja ne Beschreibung, aber für meinen Geschmack könnte die viel ausführlicher sein, muss ich zugeben, das ist technisch sicher kein Problem.
Also, aktueller Screenshot und Beschreibung des Games sammt Auflistung der wichtigsten Fakten wie Genre, Anzahl Spieler, allgemeine Beschreibung usw. und eventuell noch die User-Bewertung, dann passt das.
Die Graphische Ausarbeitung in deinem Beispiel gefällt mir gut. Wenn das dann alles wirklich mit dem Touchscreen und kinetischem Scrollen funzt, währe es eine echt praktische Sache.

 

[Gurumeditation]

Naja für die Inhalte kann sich die Community kümmern, damit meine ich natürlich die Beschreibungen, Videos und Bilder der Spiele und Programme.

Wichtig ist dabei wieder das sich alle an Richtlinien halten um ein einheitliches Bild wiederzugeben.

 

[Christoph.Krn]

Ich möchte eben auf die genannten Ideen bezüglich des beauty-get-Konzepts eingehen, da ich zu einigen bereits ausführliche Kozepte erstellt hatte. Ist daher leider etwas umfangreicher.

Videos und viele Bilder bekommst du theoretisch mit animierten GIFs hin...

Ansonsten wäre es womöglich eine Idee, auch Gnash zu supporten....

Zum Thema Übertragung hatte ich mir bereits ausführlich Gedanken gemacht. GIFs sind mir zu wenig effizient komprimiert. Es soll sich ja anfühlen wie eine lokale Anwendung die nicht von einem Server abhängig ist, von daher muss es flott gehen und darf nicht zu viel Übertragungsvolumen verursachen, da ein paar Sachen vorgeladen werden müssen. Ich erstelle während des Prozesses der Ausarbeitung auch immer eine Art "Konzept-Entwurf-Schnipsel", um meine Ideen festzuhalten und diese effizienter mit anderen austauschen zu können. Hierin stehen in diesem Fall unter anderem die Konzepte zur effizienten Übertragung (u.A. Regeln für automatische Zusammenfassung von Bildern vor dem Versand, Vorladen und intelligente dauerhafte Zwischenspeicherung):

Spoiler

Thoughts on loading:
• Screenshots and videos ("showfloor items") will be cached and always displayed from cache first. Whenever a showfloor item is determined to be displayed soon (see below), its game's showfloor-whenhasitlastchanged value from the server will be compared to the locally cached version. If they don't match, all of the game's showfloor items will be deleted from cache and all of the game's showfloor items that are determined to be displayed on the screen soon (see below) will be updated in cache, every finished file will then be updated in the UI as soon as it has finished downloading.
• How to determine how many (and which) screenshots of which games should be loaded so the user has a "fluid" and "snappy" experience that feels as if there wasn't any dependence on a server: Whenever a category view is being opened by the user, beautyget should first download screenshots 0, 1, 2 and 3 ("category-view-showfloor-initial") of games 0 to 8 (one after the other in order of appearance in list) to measure the average download speed and determine how many ms it takes to download one "category-view-showfloor-initial" (this value should be kept up to date from that moment on). By using this value and the current scrolling speed (downwards of course, as the user will see the top of the list at the beginning), we can on the fly update the number of additional category-view-showfloor-initial to download (again, one after the other in order of appearance in list) so that ideally the four main screnshots of games that are entering the screen from below as the user is scrolling along the list are already loaded the moment the user scrolls to the game (whether the files are already in cache or not should not be taken into account by the calculation). There should be a buffer (size yet to be defined, what about 6? I really have no idea here) of additional game's category-view-showfloor-initial that should be loaded in advance in case the connection to the server suddenly gets slower. However, in any case not more than 40 upcoming game's category-view-showfloor-initial should be loaded at a time. (Should downloading be stopped completely in case it is being detected that the user is "going crazy" with the kinetic scrolling?)

Server-side(?):
• For every showfloor item there is for a game, the server will create a very low resolution version (202x121 Pixel, called "category view showfloor items") and compress them to further reduce traffic caused by the category view's features. Screenshots 0, 1, 2, 3 and 4 will be compressed into one file ("category-view-showfloor-initial"), with subsequent screnshots being compressed in chunks of four (or less, if there are less left) which will be called "category-view-showfloor-" followed by a number, beginning with 1(screenshots 5, 6, 7, 8 will be compressed into "category-view-showfloor-1", screenshots 9, 10, 11, 12 will be compressed into "category.view-showflor-2"...). Videos will not be compressed to chunks but instead recoded by the server (with a yet to be determined quality) in the process of scaling them down.
• "showfloor-whenhasitlastchanged": Whenever a game is updated on the server, the server will check if any screenshot or video ("showfloor items") has changed. If so, it will update the showfloor-whenhasitlastchanged value.

Bewertungsfunktion wäre auch gut.

Auch hierzu hatte ich bereits ein paar wenige Überlegungen angestellt:

Thoughts on rating:
• Tap the rating bar of an item to immediately rate it.
• Installing an item will automatically remember it as "to be rated positive (68/100) if not uninstalled within 24 hours, to be rated positive (85/200) if not uninstalled within 48 hours, to be rated positive (95/100) if not uninstalled within two weeks" if the user did not manually set any rating (50/100 == neutral rating; (< 50) == negative rating). When uninstalling an item, view "item-ratealot" wil be displayed, asking the user to rate.

Naja für die Inhalte kann sich die Community kümmern, damit meine ich natürlich die Beschreibungen, Videos und Bilder der Spiele und Programme.

Wichtig ist dabei wieder das sich alle an Richtlinien halten um ein einheitliches Bild wiederzugeben.

Solche Richtlinien hatte ich bereits während der Überlegungen als Entwurf angefertigt. Denn Bilder und Videos zu haben ist die eine Sache, wenn dann aber z.B. die Videos zu langatmig sind und die Bilder nicht wirklich zufriedenstellend transportieren, WAS man sich da eigentlich runterlädt, dann ist das gesamte Konzept wieder unterminert. Dass sich wohl nicht alle diese Richlinien zu Herzen nähmen (oder auch nur durchläsen) ist mir klar, aber ich sehe das so: Ein paar Leute, die sich an die Richlinien halten, sind besser als gar keine Richtlinien.

Hier der Entwurf der Richtlinien:

Spoiler

Guidelines for content developers:
• Ideally, screenshot 0 of your game should show a typical (usually main-) menu (if applicable), screenshots 1 and 2 should show typical ingame action (if applicable), screenshot 3 should show ingame action, either typical or uncommon (if applicable). Only EITHER screenshot 2 or 3 should show something different if necessary. (unless any of that doesn't make sense in your particular case, of course)
• Is your "game" a "utility" or some other kind of non-game? Use meaningful screenshots then. You should crop AND scale your screenshots so they reflect important "parts" of your software. Screenshots 0 and 3 should show parts which demonstrate what makes your software special (if applicable, otherwise treat them similar to screenshot 2), screenshot 2 should show a part that IN ADDITION shows the user what kind of software it is that you're giving her (text editor, emulator, media player, IDE...). Screenshot 1 should be focused solely on communicating what kind of software your software is (Any way to accomplish this is a good way in screenshot 1, as long as the user "gets the idea". Be creative and don't have fears to try out weird ideas in screenshot 1, but only do this if it's not a game or it WILL look silly!).
• Usually it is NOT a good idea to put the icon of your software in any screenshot or show it in any video over an extended period of time.
• Your game should have at least four screenshots. If there are no screenshots (or less than four), your game's entry in beautyget won't look nice. Of course, the more screenshots, the better (as long as they're not weird). There don't have to be any videos at all for your game, but having at least one video (video 0) for every game out there would be nice, wouldn't it?
• Ideally, video 0 should contain a good amount of ingame action and be no longer than 20-30 seconds to quickly demonstrate why the user may find your game interesting (unless any of that doesn't make sense in your particular case, of course).
• Any video except for video 0 should have a short description that is no longer than a yet to be determined number of characters (maybe 140 would be a good choice?). Video 0 will not have a description.
• Any game can have an unlimited number of screenshots and videos as this is not critical to traffic.
• I will create a simple, quick and visual overview of these guidelines to make it easy for developers to understand all of them so we can hopefully enjoy a mostly coherent experience throughout beautyget.

Wobei man auch irgendwie eine Möglichkeit einbauen sollte das nur mit Dpad und Co zu steuern, das man nicht gezwungen ist den Screen zu nutzen.

Dazu hatte ich mir ebenfalls bereits Gedanken gemacht. Ab dem Zeitpunkt, ab dem der linken Analognub minimal bewegt wird, wird stets der jeweils mittig auf dem Bildschirm befindliche Eintrag hervorgehoben. Linker Nub hoch/runter == scrollen hoch/runter, rechter Nub links/rechts == Bilder/Videos verschieben. Anwählen des hervorgehobenen Eintrags per Taste. Die Hervorhebung wird bei Berühren des Bildschirms aufgehoben.


Wahrscheinlich sind die Entwurfstexte alle etwas schwer lesbar, dafür muss ich mich entschuldigen. Da sie aber einen hohen Informationsgehalt haben möchte ich all diejenigen, die sie gelesen haben, bitten, mir die eigenen dazu aufkommenden Gedanken mitzuteilen, danke.

---------------------------------------------------------------------------

Dann wäre es aber kein richtiges XML. Normalerweise kannst du beliebige Äste in den Baum hinzufügen.

Für mich klang es vorhin, als sei dies bei PXML aus irgendeinem Grund explizit verboten. Gut, jetzt weiß ich es besser.

 

[Thott Chief]

Also kurze Statusmeldumg, das ganze ist jetzt C++ und Qt4.

Zu all den Ideen, zwar sind viele Bilder und Videos wunderbar, dennoch brauchen diese Platz also Server also Geld.

Hab heut auch noch ein bisschen an der Store-Qt Version rumgemacht, bin mir aber noch nicht zufrieden.
Als Videostreaming wurde ich Youtube + Phonon nutzen.

Bis auf die Sprache und ein paar eher uninteressante Dinge unter der Haube hat sich nicht viel geändert, weshalb es auch keinen Screeny gibt.


Thott

 

[Joker]

Bevor man anfängt eine GUI zu designen, sollte man erstmal sich die anforderungen ankucken, davon eine Checkliste machen und dann die Gui auf Papier konzeptieren (dabei die Checkliste abarbeiten). Daraufhin solltest du einen prototypen entwerfen (aber erst dann).