A possible PND-system replacement


The entire point of the description field in PND's is that it's supposed to be short. This later got abused. The main description field in .desktop entries is a short form description field.

A longer package description will reside separately, and its format decided whenever someone want to build a repo.

Regarding keys: That's outside the scope of the dbp system, at least from what I gather from your description.
 
Last edited by a moderator:
Regarding keys: That's outside the scope of the dbp system, at least from what I gather from your description.

The point is that this would allow application launchers and/or an overlayed "system" menu to display, for example, how to exit a fullscreen software. There is a substantial number of anecdotal reports of people getting "stuck" in fullscreen software on the Pandora, and then (too aggressively) killing it by holding down the Pandora button. This would be solved. (Incidentially, it's also likely that the exit path key information would often solve the problem of people sometimes being unable to return to a software's main menu.)

Also, as you may or may not know, I'm trying to solve the problem of varying gaming button layouts, with flipBX for the most typical cases, and guihints for all others. However, since not all developers are going to use one of these, and since flipBX could allow users to start relying on muscle memory on the Pyra, for software that is going to break this muscle memory, it would be good if application management and launching software could display a warning and/or the menu button information ahead of launching the software. This is in case that the specific software's gaming button usage differs from the users' set flipBX value (otherwise, no information needs to be displayed, and muscle memory can be relied upon). This would likely be a substantial usability improvement for, as I assume, a significantly large number of people.
 
Last edited by a moderator:
At this point in time I am not going to design in something like this, since the rest of the software that'd use it doesn't even exist yet.

I could however suggest a metadata key to be set by software that conforms to those guidelines, for future use?
 
At this point in time I am not going to design in something like this, since the rest of the software that'd use it doesn't even exist yet.

I could however suggest a metadata key to be set by software that conforms to those guidelines, for future use?

I'm not sure if I understood you right, or if maybe you've misunderstood me previously, could you rephrase in different words what you wanted to suggest?

My proposal is literally just to standardize a (couple of?) optional meta data parts in DBP such that software authors could say: "In this application's menus, I've put Confirm on the foo button, Back/Return on the bar button, and if you want to exit the software / get back to the menu of this software, that'd be the baz button." (plus, a way to indicate flipBX support would be needed for applications that support flipBX, unless flipBX isn't going to be a thing on the Pyra). No guidelines or anything?!?
 
Last edited by a moderator:
Since nobody has stepped up to the task yet, I'm going to start implementing a package manager subsystem soon. ED has mentioned that milkshake intends to create a repo for dbps, so most of these questions are directed at him, although general input is welcome.

The most important is the format used for detailed descriptions of packages. This shouldn't bee too fancy, it should allow for some basic formatting and that's it. Videos and simlar content should be attached separately imo, as they are not included in the package file's metadata. What are the options here? Plain HTML is probably a pain, since you need to sanitize it properly to avoid scripts and crap like that running, but milkshake has the final veto on that.

Next is documentation. Is that to be included the current PND-way (does it work well?) or should a separate system be used for it? A separate system means it'll probably be access by different means than through the program menu. Since the linux desktop is in a broken state and multi-level program menues are more or less unsupported, this might be a good thing, as a long long list of documentation could be annoying to look though. If a separate system is employed, it should probably use the same markup format as the description, to simplify codebases (and it makes sense to have it available via the repo too, I guess.) If it's just desktop launchers pointing to an html or whatever, then I guess format is whatever the dev feels like.

I am undecided about the package lists. Part of me thinks a plain format like .desktop with a different section for each package ID will be sufficient, is there an argument for a hierichal format here?

I also suggest an optional changelog to be included in the package metadata. This should be a simple plaintext format that is both human and machine readable (so it needs a defined syntax.) An argument for machine readability is to allow a package manager to present changes from the currently installed version as compared to the one that can be updated to.

If I get no input on this, I will just do whatever I feel like, because this needs to be started on rather soon if there's to be a chance of having it all in a usable state by the time prototypes starts shipping...
 
The most important is the format used for detailed descriptions of packages. This shouldn't bee too fancy, it should allow for some basic formatting and that's it. Videos and simlar content should be attached separately imo, as they are not included in the package file's metadata. What are the options here? Plain HTML is probably a pain, since you need to sanitize it properly to avoid scripts and crap like that running, but milkshake has the final veto on that.

Agreed. Videos I think could be cool, perhaps just have it being a link to Youtube or other hosting service. Preview screenshots are something I've had a hard time justifying being in the package. I hate the fact that I would need to update the whole PND to add or change screenshots. I think the DBP repository should store them separately, either a binary blob in a database or just stored in some directory on the server...
 

Next is documentation. Is that to be included the current PND-way (does it work well?) or should a separate system be used for it? A separate system means it'll probably be access by different means than through the program menu. Since the linux desktop is in a broken state and multi-level program menues are more or less unsupported, this might be a good thing, as a long long list of documentation could be annoying to look though. If a separate system is employed, it should probably use the same markup format as the description, to simplify codebases (and it makes sense to have it available via the repo too, I guess.) If it's just desktop launchers pointing to an html or whatever, then I guess format is whatever the dev feels like.
I don't necessarily think it's broken on the PND system, just an entry to point to the document file. It is a bit inflexible on what reader or type of files can be used however. I can see situations where the documentation for a game/application may be in an HTML or PDF file. The good news on Debian it seems the xdg-open command seems to be flexible for a variety of documents so that may be an option.

 

I also suggest an optional changelog to be included in the package metadata. This should be a simple plaintext format that is both human and machine readable (so it needs a defined syntax.) An argument for machine readability is to allow a package manager to present changes from the currently installed version as compared to the one that can be updated to.

I like this idea, the best we had on the PND repo is either embedding in the PXML(messy IMO) or the Additional Info section that is edible only on the repo, but only had a finite amount of characters that could be used. This could be a bit more elegant.
 
Last edited by a moderator:
The argument for screenshots inside the package is if a minimenu-like launcher was constructed, then a screenshot could be shown as a launcher was highlighted. It would also speed up viewing inside the repo client if local versions can be presented instead of new ones. On the other hand, the latter can be dealt with using caching, which I plan on implementing anyway for packages that aren't installed.
 
I'm all for dedicated fields for changelog and even usage instructions, otherwise some people just don't bother to add them (maybe forget?) and you end up having to hunt that info in the forums. The instructions could maybe be omitted if automatic data file search (mentioned in this thread) is implemented, but that may be messy for things that accept many versions of same data files (like Half-Life PND which can take both CD and steam files).

It might be even good to have "needs data files" flag, so that the repo could tell which DBPs are ready to play right away and which ones need some kind of setup. If it was up to me I'd make such flag required, otherwise people are lazy and tend to skip adding such info.

As for screenshots, I'd keep them in the repo only, but that's just me...
 
It'd be cool if we had some sort of post script that "resquashes" the dbp with the data files in it when the md5 sums are met to:

  1. Conserve Space on user SD cards for other stuff.
  2. Allow the DBP to be backed up effectively without "forgetting" about the datafiles when erasing the SD card (Been there done that)
  3. Would make it a hell of a lot easier to backup the appdata directory.
 
I'm all for dedicated fields for changelog and even usage instructions, otherwise some people just don't bother to add them (maybe forget?) and you end up having to hunt that info in the forums. The instructions could maybe be omitted if automatic data file search (mentioned in this thread) is implemented, but that may be messy for things that accept many versions of same data files (like Half-Life PND which can take both CD and steam files).

It might be even good to have "needs data files" flag, so that the repo could tell which DBPs are ready to play right away and which ones need some kind of setup. If it was up to me I'd make such flag required, otherwise people are lazy and tend to skip adding such info.

As for screenshots, I'd keep them in the repo only, but that's just me...

If this is done, please add an "in game" or "in app" instructions tag that can be used to bypass it, as some things simply don't need instructions, or have the instructions inside them already.
 
I think you always at least need a note to tell you how to exit the program.  That might be obvious from the game screen, but more often than not you have to try a few different key combinations to get out.

Of course, whether I'll read that note before starting the program is a different problem.
 
Will there be a way to add plug-in/dlc type dbps? ie. Say I release my "If... Then Do..." then somebody else wants to release a number of plugins for it - but want to keep their own dbp for maintenance. It'd be nice if there was a way a source dbp could find any "related" dbps and mount them (maybe into the same path)
 
As I rework the dependency system, I intend to make dbp:s depending on other dbp:s get mounted into the same union. You could also from the launch script get a list of all present dbp:s and mount relevant ones via dbp-cmd.
 
My proposal is literally just to standardize a (couple of?) optional meta data parts in DBP such that software authors could say: "In this application's menus, I've put Confirm on the foo button, Back/Return on the bar button, and if you want to exit the software / get back to the menu of this software, that'd be the baz button." (plus, a way to indicate flipBX support would be needed for applications that support flipBX, unless flipBX isn't going to be a thing on the Pyra). No guidelines or anything?!?

I think this should definitvely included as an optional metadata element. This bears the opportunity to "standarize" some elements even afterwards as system that exist seperately just need to pick up the information. A scenario I could think of, could be Christoph.Krns guihints in combination with pmprogs overlay - plan: if the overlay could be aware / would be able to know which application is currently active (is this possible in the linux multitasking environment we are expected to have?) it could read that info and show it, so there would be no need for game-devs/maintainers to include the functionality. Or a more realistic example: the repo-client is able to provide a "quick-hints" area/window where users can pick up the most import buttons fast and easily

The most important is the format used for detailed descriptions of packages. This shouldn't bee too fancy, it should allow for some basic formatting and that's it. Videos and simlar content should be attached separately imo, as they are not included in the package file's metadata. What are the options here? Plain HTML is probably a pain, since you need to sanitize it properly to avoid scripts and crap like that running, but milkshake has the final veto on that.
HTML does not look that far off to me - at least its a well known standard with lots and lots of documentation and software that supports it out there. There is a chance of abuse that gets more probable if the software that wants to read it utilizes more complex standard components (like a webkit library). But this could be avoided in several places: the repo could be restrictive about what is allowed (something like "if description contains <script> nag uploader") the client could filter out everything except a specific set of tags or depending on what tech the client uses, the part that renders the description can be configured to ignore "active" content. Or use the most secure method and just filter the tags out and render the plain text.

What are the alternatives ? There is tex, but that seem too complex for what "we" are aiming for - or not ?

Next is documentation. Is that to be included the current PND-way (does it work well?) or should a separate system be used for it? A separate system means it'll probably be access by different means than through the program menu. Since the linux desktop is in a broken state and multi-level program menues are more or less unsupported, this might be a good thing, as a long long list of documentation could be annoying to look though. If a separate system is employed, it should probably use the same markup format as the description, to simplify codebases (and it makes sense to have it available via the repo too, I guess.) If it's just desktop launchers pointing to an html or whatever, then I guess format is whatever the dev feels like.
I think it works well in the sense of providing an easy way to bundle information with a package. But what I did not like about it was the part that provided access to it (on the Pandora) - putting them all together in one menu "folder" cluttered things up heavily and I was often confused when they had the same title.

I also suggest an optional changelog to be included in the package metadata. This should be a simple plaintext format that is both human and machine readable (so it needs a defined syntax.) An argument for machine readability is to allow a package manager to present changes from the currently installed version as compared to the one that can be updated to.
Should definately be in there

Preview screenshots are something I've had a hard time justifying being in the package. I hate the fact that I would need to update the whole PND to add or change screenshots. I think the DBP repository should store them separately, either a binary blob in a database or just stored in some directory on the server...
I disagree, Screenshots are important if you rely on other means of "browsing" the dpbs as slaeshjag already pointed out. I would rather see the ability to override the included screenshots with ones you can upload via the maintainer (web)interface, implemented into the repo.

What about "banal" flags like "multiplayer" [yes/no] ?

Is an override ability (much like on the Pandora with .ovr files) planned ?
 
The most important is the format used for detailed descriptions of packages. This shouldn't bee too fancy, it should allow for some basic formatting and that's it. Videos and simlar content should be attached separately imo, as they are not included in the package file's metadata. What are the options here? Plain HTML is probably a pain, since you need to sanitize it properly to avoid scripts and crap like that running, but milkshake has the final veto on that.
HTML does not look that far off to me - at least its a well known standard with lots and lots of documentation and software that supports it out there. There is a chance of abuse that gets more probable if the software that wants to read it utilizes more complex standard components (like a webkit library). But this could be avoided in several places: the repo could be restrictive about what is allowed (something like "if description contains <script> nag uploader") the client could filter out everything except a specific set of tags or depending on what tech the client uses, the part that renders the description can be configured to ignore "active" content. Or use the most secure method and just filter the tags out and render the plain text.

What are the alternatives ? There is tex, but that seem too complex for what "we" are aiming for - or not ?
Well as B-ZaR already suggested,  Markdown could work well.  It also occurs to me that we could use a subset of BBCode, which was designed for the exact purpose of providing a set of formatting codes that could be used to format user provided content without having to permit the use of raw html in the content itself. There's no need to re-invent the wheel here.

- Neelix
 
I looked briefly into ReStructuredText for this the other day.  I didn't mention it because I found a way to embed raw HTML into it, which opens it up to scripting-based attacks, but on most other metrics I can think of it seems like a good fit - renders raw text as expected, works out headings and subheadings automatically.  I'm not sure if there's a way to prevent people from defining their own raw HTML role.
 
Back
Top